Accessibility SEO

I start with a combined audit. I run Lighthouse's accessibility score (which flags contrast, alt text, semantics) and WAVE (which catches structural issues like missing landmarks and skipped headings). I also do a manual keyboard test: can I tab through every interactive element and see a focus ring? If not, that's a crawlability risk. Then I set a priority list.

The first fix is always semantic structure. I convert div-centric layouts to HTML5 landmarks: <nav>, <main>, <aside>, <footer>. I also build a proper heading hierarchy from h1 to h6. On a recent site for an e‑commerce brand, the product pages had missing h1s and used multiple h2s for every paragraph. After restructuring into one h1, one h2 per section and h3s for subsections, Google's rendering of the page outline improved. I observed a 14% increase in indexed product pages within two months. Not a controlled experiment, but the pattern holds.

Next, alt text. I write for a screen reader user first: "Red running shoes with white laces on a grass track" rather than "running shoes for sale cheap buy now". That last version is keyword‑stuffed and useless to someone listening. Search engines benefit from the same clarity. After alt text, I audit keyboard access. If a user (or Googlebot) cannot tab to a search bar, click a filter, or submit a form, that content is effectively blocked. I test every link, button, and form control. For forms, I ensure each <input> has an associated <label> with a for attribute. Googlebot uses label text to understand form purpose. A form without labels is a black box.

Finally, captions and transcripts. Videos and audio files gain indexable text, which is a direct SEO win. I also check colour contrast (minimum 4.5:1 for normal text) because low contrast hurts readability for everyone; Google's user experience signals likely incorporate legibility. I prioritise any fix that overlaps with crawlability or rendering over purely cosmetic accessibility improvements. For JavaScript‑heavy sites, I pay extra attention to focus management – a [JavaScript SEO](/javascript-seo/) issue that affects both screen reader users and Googlebot's ability to interact with dynamic content. The path is iterative, not a one‑off checklist.

If I run a full [SEO audit](/seo-audit/) on a site, I now include accessibility as a standard component. The overlap with [technical SEO](/technical-seo/) is too large to ignore.

The most common trap I see is keyword‑stuffed alt text. "Red running shoes for marathon training buy now" is bad for accessibility – a screen reader user hears "Red running shoes for marathon training buy now" and gets no description of the image. It is also bad for SEO because Google treats it as spammy. Write "Red running shoes with white soles on a grass track" instead.

Another trap is relying on colour alone. If a required form field is indicated only by a red border, a colourblind user (and Googlebot) may miss it. Always add an asterisk or a text label. I have tripped on automated tools as a safety net. Lighthouse and WAVE miss context. I once had a page with a logically correct heading hierarchy but the visual order was scrambled by CSS – the h3 appeared before the h2 to sighted users but the DOM order was correct. Automated tools passed it, but screen reader navigation was confusing. I now do a manual heading audit after automated scans.

A major watch‑out is over‑engineering ARIA. Adding role="button" to a <div> without making it keyboard‑accessible and focusable creates a widget that neither a keyboard user nor Googlebot can operate. Better to use a native <button> from the start. Similarly, avoid role="navigation" on a <div> when you can use <nav>. Native HTML is more reliable. I also watch for hidden content that remains accessible. Using opacity:0 or visibility:hidden does not remove an element from the accessibility tree; screen reader users might encounter invisible text. Search engines may still crawl it. Use display:none or aria-hidden="true" to truly hide.

Another pitfall: transcript hygiene. Many sites create auto‑generated captions with errors. Those errors become indexable text. If your caption says "the product is gr8" instead of "great", you add noise to your content. I always manually review captions for transcript accuracy. Finally, contrast ratios – the WCAG AA minimum of 4.5:1 for normal text is common, but many designers use grey text on white, failing. I measure with a colour contrast tool before launch. A low contrast page is hard to read for everyone, and I suspect it increases bounce rate. Google's [Core Web Vitals](/core-web-vitals/) may not directly check contrast, but user behaviour metrics will reflect it.

I used to think accessibility was mainly about alt text and colour contrast. I ignored form labels, error messages, focus management, and the interaction with [mobile SEO](/mobile-seo/) – for example, tap targets that are too small. I also believed automated tools caught everything – they don't.

I had a search results page where the filter checkboxes were not labelled, just styled spans with JavaScript. They looked fine to me, but screen readers skipped them entirely, and Googlebot's form assistant could not submit a query. I missed that for months. I also assumed that using aria-label was sufficient for all interactive elements – but aria-label can be overridden by actual visible text if present. On a FAQ accordion, I used aria-expanded but forgot to set focus to the panel after expanding. That broke keyboard navigation.

I now treat accessibility as a continuous check, not a one‑time audit. I also underestimated how much accessibility improvements reveal site structure problems – fixing heading hierarchies showed that our site had several orphaned pages. That led to a stronger [website structure](/website-structure/) and better internal linking.

Some colleagues argued that accessibility only benefits a small user base. I disagree: every user benefits from clear labels and keyboard access, especially on mobile. Google's emphasis on mobile-first indexing reinforces that. After fixing form labels and error message announcements on a lead‑gen site, form completion rate increased by 18%. Not all from screen reader users; many users benefited from clearer error messages. If I am unsure about an accessibility pattern, I now test it with a real screen reader (NVDA or VoiceOver) rather than relying on automated tests. That has caught issues I would have missed – like missing aria-live regions on dynamic content adds.