Web accessibility and SEO: what WCAG 2.2 asks for, where it overlaps with Google, and what EU law requires

Web accessibility means anyone can use your website, including with a screen reader, with zoom or with a keyboard alone. Google does not present it as a ranking factor, but it uses the same building blocks: alt text, titles, descriptive links and semantic HTML. And since 28 June 2025, European law has required it of many online shops.

To check it on your own site: SEO audit

This guide covers where accessibility and SEO overlap, what fails most often according to public data, and how to check it without paying for an audit. It is not legal advice: if your business may be covered, check with a lawyer.

What is WCAG 2.2?

WCAG (Web Content Accessibility Guidelines) are the W3C's accessibility guidelines for web content, the technical reference used by laws and standards around the world. Version 2.2 has been a W3C Recommendation since 5 October 20231, and the current edition of the document is dated 12 December 20242.

They are built on four principles: content must be perceivable, operable, understandable and robust. Each success criterion has a level, A, AA or AAA, and AA is the one standards usually require. WCAG 2.2 adds nine new criteria, such as a minimum size for touch targets and keeping keyboard focus from being hidden, and removes one, 4.1.1 Parsing, as obsolete1.

These are the criteria that overlap most with SEO and with the way a machine reads your page2:

Is accessibility a ranking factor?

Google does not list it as a ranking factor in its documentation. What it does document is that it uses several pieces accessibility also requires, so fixing one tends to fix the other:

The last row is a good reminder that not everything overlaps. Declaring the language with <html lang="en-GB"> is required for accessibility and changes nothing for Google. Do it anyway: without it, a screen reader may read your English text with the pronunciation of another language.

What fails most often?

The broadest public data set is the WebAIM Million, an annual analysis of the home pages of the top million websites. Its 2026 edition, with data from February, detected WCAG failures on 95.9 % of home pages, with an average of 56.1 errors per page6. The six most common:

These are automated detections, so they measure what a tool can see, not everything that is wrong. But all six are fixed in templates, and four of them (alt text, links, buttons and language) are also what a machine needs to understand the page.

How to fix the most common failures

1. Meaningful alt text. Describe what the image contributes in that context. Google's own example: "Dalmatian puppy playing fetch" is better than "puppy", and keyword lists are out3. Decorative images get alt="", empty but present, so screen readers skip them. More in the guide to image SEO.
2. Enough contrast. Grey #767676 on white gives 4.54:1 and passes AA for normal text; #999999, very common for secondary text, gives 2.85:1 and fails. We calculated both with the WCAG relative luminance formula.
3. A name for every button and link. A button that only contains an icon needs text that names it. And if the button has visible text, its accessible name should include it (criterion 2.5.3).
4. The language declared on the html element, plus lang on passages in another language.
5. Zoom allowed. MDN warns that user-scalable=no stops people with low vision from reading the page7.
6. Touch targets of at least 24 × 24 CSS pixels, or with enough space around them1.

This snippet sums up points 3 to 5, with what not to do and what to do instead:

<!-- Bad: no language and zoom blocked -->
<html>
<meta name="viewport" content="width=device-width, initial-scale=1, user-scalable=no">

<!-- Good: language declared and zoom allowed -->
<html lang="en-GB">
<meta name="viewport" content="width=device-width, initial-scale=1">

<!-- Bad: empty button and a "link" Google does not crawl -->
<button><svg aria-hidden="true">…</svg></button>
<span onclick="location.href='/quote/'">Get a quote</span>

<!-- Good: button with an accessible name and a real link with descriptive text -->
<button aria-label="Open the menu"><svg aria-hidden="true">…</svg></button>
<a href="/quote/">Get a quote for your new kitchen</a>

Accessibility and AI agents

There is a new reason to name your controls properly. OpenAI explains in its publisher FAQ that ChatGPT agent in Atlas understands accessible websites better, because it uses ARIA tags, the same labels and roles screen readers rely on, to interpret page structure and interactive elements. It recommends adding descriptive roles, labels and states to buttons, menus and forms8.

ARIA is not a patch to apply over everything. The W3C's ARIA Authoring Practices Guide warns that incorrect ARIA misrepresents what a person sees, and that ARIA roles do not give the browser the keyboard behaviour that native elements come with9. So the order is: first real <button>, <a href>, <label> and heading elements; ARIA only where HTML falls short. What makes an assistant cite you, beyond understanding the page, is covered in how to get cited by AI.

Who does the European Accessibility Act cover?

Directive (EU) 2019/882, known as the European Accessibility Act, sets accessibility requirements for a list of products and services, e-commerce among them10. Each member state transposes it into national law. Spain's transposition, Ley 11/2023 of 8 May, shows the points that matter most for a website11:

• From when: the requirements apply from 28 June 2025.
• Which services: among others, e-commerce services (article 2.2.f), consumer banking and parts of passenger transport services.
• Who is exempt: microenterprises providing services (article 3.3). A microenterprise employs fewer than 10 people and has an annual turnover or balance sheet total of no more than 2 million euros.
• Which content is out of scope: among other things, pre-recorded audio and video and office documents published before 28 June 2025, and third-party content you do not control.
• Transition period: until 28 June 2030 to keep providing the service with products already in lawful use, and service contracts signed before 28 June 2025 can continue until they expire, for at most five years.

The UK is not an EU member state, so the directive does not apply there as law; if you sell to consumers in the EU, ask a lawyer whether your service is in scope. The usual technical reference is the European standard EN 301 549, which, according to the W3C Web Accessibility Initiative, includes WCAG 2.1 level AA verbatim for web content12. WCAG 2.2 keeps those criteria essentially unchanged and adds more1, so working to 2.2 AA covers you from above.

How to check it

1. Lighthouse or PageSpeed Insights. The accessibility category runs automated audits, each one pass or fail, and weights the result by user impact13. A single unnamed button fails the whole button-name audit.
2. The keyboard. Tab through the page: can you always see where the focus is? Can you reach every menu and button? Can you close a pop-up?
3. Zoom. Zoom to 200 % on a desktop browser and check that no text is cut off and no horizontal scrolling appears.
4. A screen reader. NVDA on Windows or VoiceOver on Mac and iPhone, for five minutes on your home page, will teach you more than any report.

An automated tool cannot tell whether an alt describes the image well or whether the reading order makes sense. That is why steps 2 to 4 cannot be skipped.

What SmoothSeen checks

Declaration of interest: this blog belongs to SmoothSeen, a web audit tool. In the mobile and accessibility section of its SEO analysis, it checks image alt text, colour contrast, whether buttons and controls have accessible names, the declared language, the viewport tag and whether zoom is allowed, text size on mobile and touch target size. These are automated checks: they do not replace testing with a keyboard and a screen reader, and they do not tell you whether you comply with the law.

What to do this week

Run your home page and one product or service page through PageSpeed Insights, note the accessibility failures and tab through both pages with the keyboard. Start with contrast and unnamed buttons, which can usually be fixed in a single template. To see them alongside the rest of the technical analysis, run a free SEO audit.

Frequently asked questions

Does improving accessibility improve SEO?

Not directly: Google does not document accessibility as a ranking factor. But many fixes overlap with what Google does use: alt text to understand images, the page title, descriptive link text and links built with a elements. When you fix those pieces for people, you also hand them to search engines.

Which WCAG level do I need to meet?

Level AA is the usual benchmark in standards and laws. The European standard EN 301 549 includes WCAG 2.1 AA for web content, and WCAG 2.2 keeps those criteria and adds others, such as a minimum size for touch targets. Working to WCAG 2.2 AA is the safest choice if you are starting today.

Does the European Accessibility Act apply to my online shop?

In EU member states it covers e-commerce services from 28 June 2025, but microenterprises providing services are exempt: fewer than 10 employees and no more than 2 million euros of annual turnover or balance sheet. A UK shop selling to EU consumers may also be affected. If you are above those figures or unsure about your case, check with a lawyer.

Is an accessibility plugin or overlay enough?

An overlay added on top does not fix the page's HTML: an unnamed button or a link built with a span is still there for screen readers and for crawlers. What works is fixing the templates: alt text, contrast, control names, language and real links. Then check the result with a keyboard and a screen reader.