“Accessibility is good for SEO” gets repeated because it’s half true. Screen readers and search engines both depend on a page’s underlying code, not just how it looks, so much of the work on accessibility and SEO is the same work. But accessibility isn’t a ranking signal in its own right, and some well-worn SEO habits make pages harder for disabled visitors to use.
Here’s what pays off twice, what search won’t reward, and which SEO habits to drop.
The short answer
Accessibility and SEO overlap in the foundations, not in the rankings.
- Accessibility isn’t a ranking factor in its own right, and Google Search doesn’t use Lighthouse accessibility scores.
- Many foundations serve both: descriptive page titles, a real heading hierarchy, semantic HTML, meaningful link text, alt text written for people, and transcripts.
- Some SEO habits hurt accessibility: keyword-stuffed alt text, “click here” links and headings chosen for keywords.
- Some work serves one side only. Keyboard access won’t move rankings; hreflang does nothing for screen reader users.
Is accessibility a ranking factor?
No, not in its own right. Google’s page experience documentation asks about Core Web Vitals, HTTPS, how pages display on mobile, intrusive ads and interstitials, and whether the main content is easy to pick out. Conformance with WCAG (the Web Content Accessibility Guidelines) isn’t on that list, and Google’s Search documentation doesn’t present it as a ranking signal.
A perfect Lighthouse score won’t lift rankings
Lighthouse is a lab tool: it loads a page, runs automated checks built on the axe-core engine and weights the pass-or-fail results into a score out of 100. Google Search doesn’t rank on Lighthouse scores. Even the Core Web Vitals it does use come from real Chrome users, through the Chrome UX Report.
The score also says less about accessibility than it seems. A check can confirm an image has alt text, but not that the text is accurate or whether a keyboard user gets trapped in a pop-up. That’s why automated checkers are only one part of an accessibility audit.
Where accessibility and SEO overlap
A screen reader doesn’t see your design. It reads the accessibility tree: the map of headings, links, buttons and fields the browser builds from your HTML. Search engines parse and render that same HTML. Bold 24-pixel text that isn’t marked up as a heading is just more text to a screen reader; a <div> with a click handler isn’t a link to it or to Google’s crawler.
The numbers are WCAG 2.2 success criteria, which WCAG 2.2 explained walks through.
| Foundation | For accessibility | For search |
|---|---|---|
Descriptive <title> |
Announced when the page loads (2.4.2) | The first source Google lists for title links |
| Headings marked up as headings | Lets users jump between sections (1.3.1, 2.4.6) | Makes each section’s topic clear |
Links as <a href> with clear text |
Focusable, with a clear destination (2.4.4) | Crawlable, with descriptive anchor text |
| Alt text on meaningful images | Read aloud in place of the image (1.1.1) | Helps Google understand the image |
| Transcripts and captions | Spoken content as text (1.2.1, 1.2.2) | A transcript on the page is indexable text |
| Content that reflows | Usable at 320 CSS pixels wide (1.4.10) | Google indexes the mobile version of pages |
Descriptive, unique page titles
The <title> is the first thing a screen reader announces on a new page, and the name on the browser tab. Google lists it first among the sources for title links, though it can rewrite them. Lead with the subject, end with the brand, never repeat a title: “Services | Acme” helps nobody; “Office fit-out and refurbishment | Acme” does both jobs.
A heading hierarchy that outlines the page
WebAIM’s surveys of screen reader users have repeatedly found that moving through headings is the most common way they look for information on a long page. Google’s SEO Starter Guide says heading order matters to screen readers rather than to Search, so get it right for people: one H1 that states what the page is about, H2s for main sections, H3s within them, no skipped levels.
Check it yourself. Read the headings alone, in a screen reader’s headings list or an outline extension: they should work as a table of contents. The on-page SEO guide shows how that outline supports the rest of the page.
Semantic HTML and links that are really links
Native elements carry their meaning. A <button> works from the keyboard and is announced as a button; an <a href> is announced as a link and tells the browser where it goes. Google says it can only crawl links that are <a> elements with an href attribute, so a “link” built from a <span> and JavaScript can hide a page from search engines and keyboard users at once.
Links for going somewhere, buttons for doing something, ARIA only where HTML has no native element. And keep text as text: a headline baked into a banner can’t be resized, translated or reliably read by search engines (1.4.5).
Link text that makes sense on its own
Screen reader users often pull up a list of every link on a page, where ten links saying “Read more” give them nothing to choose between. Google says anchor text tells it something about the page being linked to. One fix serves both: “See our warehouse projects”, with those words as the link.
If a design needs short buttons on cards, make the whole card one link named by its heading, or add visually hidden text so it reads “Read more about warehouse design”. Internal linking and site structure covers anchor text across a whole site.
Alt text written for the person who can’t see the image
Google says it uses alt text, with computer vision and the page’s content, to understand images. Both audiences want a short, accurate description of what the image contributes in that spot.
- Photos: “Steel frame of a two-storey warehouse with the roof trusses in place.”
- Linked images: describe the destination, such as the product name on a thumbnail.
- Charts: give the takeaway, with the detail in nearby text or a table.
- Decorative images: an empty
alt="", so screen readers skip them.
Leave out “image of”: screen readers already say it’s an image.
Captions and transcripts for video and audio
Captions serve people who are deaf or hard of hearing and anyone watching on mute; transcripts do the same for podcasts and suit skimmers. For search, the transcript counts most: don’t assume captions inside a player count as page content, but a transcript on the page is text search engines can index and quote.
Edit automatic captions, especially names and technical terms. Where a video’s visuals carry information, level AA also asks for audio description (1.2.5); narration that describes what’s on screen avoids most of that work.
The same structure serves AI agents
Some AI browsing agents, which click through sites on someone’s behalf, read the accessibility tree as well as screenshots, so an unlabelled icon button stumps them as it does a screen reader. At the time of writing (August 2026), agents differ in how they read pages; semantic HTML is the safe bet either way. AI browsing agents and your website goes into the detail.
SEO habits that hurt accessibility
Most of these were never good SEO either. They survive because they look like optimisation.
Keyword-stuffed alt text
“Warehouse construction contractor industrial building” is read aloud word for word, and stuffing decorative images turns pictures that should be skipped into interruptions. Google’s image guidance warns that keyword-filled alt attributes may cause a site to be seen as spam.
“Click here”, and exact-match anchors everywhere
Generic link text fails both audiences. So does the opposite: the same keyword phrase as anchor text on every link to a page sounds like a stuck record through a screen reader.
Headings chosen for keywords, not structure
Heading tags on taglines and footer blurbs to “get the keyword into an H2”, bullets promoted to H3s, a keyword-heavy H1 hidden off screen: each clutters the outline screen reader users navigate by. Style text with CSS; choose heading levels for structure.
Hidden text and ARIA used as a keyword store
Google’s spam policies target text hidden to manipulate rankings, and explicitly accept text meant only for screen reader users. The trouble starts when visually hidden text or aria-label becomes a keyword store. Screen reader users hear every word. And because an aria-label replaces a link’s visible text for assistive technology, a voice control user saying the visible words may not be able to activate it; WCAG requires the accessible name to contain the visible label (2.5.3).
Where accessibility and SEO don’t overlap
The lang attribute and hreflang
The lang attribute tells screen readers which pronunciation rules to use, for the page (3.1.1) and for passages in another language (3.1.2). Google says it doesn’t use code-level language information such as lang; it works from the visible content. Hreflang links equivalent pages in different languages for search, and screen readers ignore it. A multilingual site needs both on every language version, as the multilingual SEO guide explains.
Accessibility work search won’t reward
Keyboard access, visible focus, colour contrast, text that works at 200% zoom, labelled fields, clear error messages. Search won’t reward any of them directly, yet each can decide whether a disabled visitor finishes an enquiry. Sell accessibility internally as an SEO project and this is the work that gets cut first. The business case for accessibility makes the argument on its own terms, and the web accessibility guide sets out where to start.
Search work screen readers never see
Meta descriptions, structured data, canonical tags and sitemaps shape how search engines crawl and present pages, and none of it is read out on the page. The guide to SEO-friendly websites covers those foundations.
One pass that checks both
Start with your key templates (home, service, article, contact), then the pages edited most often.
How to check. A site crawler reports titles, H1s, missing alt text and uncrawlable links site-wide; the Accessibility pane in Chrome DevTools shows any element’s computed name and role. Then tab through a page and spend ten minutes with a screen reader (VoiceOver on Macs and iPhones, the free NVDA on Windows). If its headings and links lists don’t make sense on their own, the structure needs work.
Frequently asked questions
Does accessibility help SEO?
Indirectly. The markup that makes a page work with a screen reader also helps search engines understand it, but accessibility itself isn’t a ranking factor.
Can an accessibility overlay improve SEO?
Nothing Google has published suggests an overlay helps rankings, and it adds a third-party script to every page. It also can’t reliably repair the underlying markup that screen readers, keyboards and search engines depend on.
Should alt text include keywords?
Only when the keyword is genuinely part of an accurate description. If the photo shows an office fit-out, “office fit-out” may belong in the alt text; a list of search phrases doesn’t.
What to do next
Fix the shared foundations first: one piece of work with two audiences, cheapest done once in templates and content guidelines. Then do the accessibility-only work, because people need it.
For an outside view of the search side, our free website audit checks Google visibility (titles, indexing and page structure) alongside speed, mobile, security and enquiry paths. It isn’t an accessibility test: WCAG conformance, keyboard access and screen reader use are what an accessibility audit is for. And if a website redesign is coming, that’s the moment to build both in from the first line of code.