Web Accessibility: The 6 Errors Behind 96% of Failures

Accessibility work tends to get pushed to “later” until a complaint or a failed audit forces the issue, and by then the problems are baked into every template. The yardstick is WCAG 2.2 from the W3C, which splits the job into testable success criteria graded at Levels A, AA, and AAA.

The US ADA Title II web rule and the EU’s European Accessibility Act both lean on WCAG-based requirements, so the standard is the legal benchmark as well as the technical one.

The scale of the problem is easy to underestimate. WebAIM’s 2026 analysis of the top 1,000,000 home pages detected an accessibility error on 1 in every 26 page elements.

What Is Web Accessibility?

Building websites and web applications so people with visual, auditory, physical, speech, cognitive, and neurological disabilities can perceive, understand, use, and contribute to them is what the term covers.

The technical benchmark is WCAG, the Web Content Accessibility Guidelines, published by the W3C Web Accessibility Initiative (WAI).

A page does not become accessible through content alone. The W3C looks at the content itself, meaning the text, images, sound, and the markup that structures them. Browsers, media players, and assistive technology (the user agents) have to do their part, and so do the authoring tools, meaning the editors, site builders, and CMS platforms that produce the content in the first place.

That last part matters more than people expect. A site builder that outputs unlabeled form fields repeats the error on every page it generates.

General usability overlaps with all this, though the testing is different. A checkout can feel smooth with a mouse and fall apart completely from a keyboard.

Screen readers are only part of the picture. The Department of Justice’s list (ADA.gov, 2022) also covers captions for deaf users and voice recognition software for people who can’t use a mouse, next to the screen readers blind users depend on.

WCAG 2.0 came out on 11 December 2008. WCAG 2.2 followed on 5 October 2023, and according to the W3C it is now also the international standard ISO/IEC 40500:2025.

Who Web Accessibility Serves and Which Assistive Technology They Use

Anyone with a visual, hearing, motor, or cognitive disability benefits, along with people temporarily limited by injury or circumstance.

The numbers are large. The World Health Organization estimates that 1.3 billion people, or 16% of the global population, live with a significant disability (WHO fact sheet, March 2023).

Disability types and the barriers they meet

The Department of Justice’s web guidance (ADA.gov, 2022) and WCAG 2.2 between them cover most of the common barriers.

Blind and low-vision users run into images with no text alternatives and text that fails contrast, and color-blind users miss anything that relies on color alone. Deaf and hard-of-hearing users lose the content of any video without captions. People who can’t control a mouse get shut out by mouse-only interfaces and tiny click targets.

For cognitive and neurological disabilities, WCAG 2.2 added rules against making people memorize passwords or retype information they already entered.

Temporary and situational limits count too. Think of a broken wrist, or trying to read a phone in glare on a loud commute. Inclusive design treats those cases as normal use and not as edge cases.

Assistive technology in daily use

Screen readers turn page structure into speech or Braille, and which one someone uses depends on the device. NVDA and JAWS run on Windows. VoiceOver covers iPhone and Mac, and TalkBack is the one on Android.

Other people rely on screen magnifiers or voice recognition software, and some use switch devices instead of a mouse and keyboard.

In practice, markup is the interface. If the code never says an element is a button, a screen reader user never hears that it is one.

What Does WCAG 2.2 Require?

Web content has to meet testable success criteria, which WCAG 2.2 groups under 13 guidelines and 4 principles at conformance levels A, AA, and AAA. Most laws that cite WCAG name Level AA.

The W3C published WCAG 2.2 as a Recommendation on 5 October 2023 and issued an update on 12 December 2024. Content that conforms to 2.2 also conforms to 2.1 and 2.0.

The principles behind the criteria

Every success criterion sits under one principle, and failing any of them locks some users out (W3C, Understanding WCAG 2.2).

Perceivable content means text alternatives for images, captions for video, and things users can actually see and hear. Anything operable has to work from a keyboard, give people enough time, and avoid seizure triggers. Understandable covers readable text, predictable behavior, and help with input errors. Robust is the technical one, meaning markup that browsers and assistive technology interpret reliably.

Conformance levels

Level A is the floor. Two of the new 2.2 criteria sit here. Consistent Help (3.2.6) keeps help links in the same place across pages, and Redundant Entry (3.3.7) stops forms from asking twice for the same information.

Laws and procurement checklists mostly land on Level AA. It includes Target Size (Minimum), which asks for a pointer target of at least 24 by 24 CSS pixels, and Accessible Authentication (Minimum), which bars login steps built on memory or puzzles unless an alternative or helper exists.

Level AAA is stricter. Focus Appearance (2.4.13), for example, requires a keyboard focus indicator of a minimum size with a 3:1 contrast change. Most policies stop at AA, as the laws below show.

What changed in 2.2

WCAG 2.2 adds 9 success criteria to 2.1 and retires one, 4.1.1 Parsing, as obsolete (W3C WAI).

• Level A gets two, Consistent Help and Redundant Entry
• Level AA gets four: Focus Not Obscured (Minimum), Dragging Movements, Target Size (Minimum), and Accessible Authentication (Minimum)
• Level AAA picks up Focus Not Obscured (Enhanced), Focus Appearance, and Accessible Authentication (Enhanced)

Most of the additions help keyboard users and people with motor impairments or cognitive disabilities.

Web Accessibility Laws by Region and Compliance Dates

US state and local governments, US federal agencies, and EU public sector bodies all have to meet web accessibility rules. Since 28 June 2025, so does a broad set of EU consumer services that includes e-commerce.

Businesses open to the public in the US fall under ADA Title III, which has no fixed technical rule. The table below sets out who has to meet which standard, and by when.

Sources: ADA.gov, Section508.gov, the European Commission, and W3C WAI.

United States

The Department of Justice published an interim final rule on April 20, 2026 that pushed every Title II web compliance date back one year. Governments serving 50,000 or more people now have until April 26, 2027, and smaller entities and special districts until April 26, 2028 (ADA.gov, Federal Register).

Many explainers still print the original April 2026 and April 2027 dates, so check any date against ADA.gov before quoting it. The standard itself did not move, and WCAG 2.1 AA still applies.

Title III works differently. The DOJ has held since 1996 that the ADA covers web content, and its guidance lists WCAG and the Section 508 Standards as technical references instead of setting a rule of its own.

Enforcement shows up as settlements. The DOJ reached agreements with H&R Block over website coding for screen readers and keyboard use, and with Rite Aid over its COVID-19 vaccine registration portal.

Section 508 binds federal agencies. The US Access Board’s 2017 refresh took effect on January 18, 2018 and harmonized the standards with WCAG 2.0 (Section508.gov).

European Union

The European Accessibility Act (Directive (EU) 2019/882) has applied since 28 June 2025. It covers consumer-facing services such as e-commerce and banking, and exempts microenterprises with fewer than 10 people and turnover or a balance sheet of 2 million euro or less from the service requirements.

The Web Accessibility Directive (Directive (EU) 2016/2102) binds public sector bodies and requires them to publish accessibility statements.

EN 301 549 is the European standard behind both. Version 3.2.1, harmonized on 18 August 2021 under the Web Accessibility Directive, draws on WCAG 2.1. No version has been cited in the Official Journal for the European Accessibility Act yet, so it does not yet give a presumption of conformity under that law. Version 4.1.1, published on 2 September 2026, moves to WCAG 2.2, and its citation is expected around the end of November 2026.

The European Commission points out that EN 301 549 goes beyond WCAG. Meeting every WCAG 2.1 success criterion alone does not create a presumption of conformity with the Web Accessibility Directive.

Which WCAG version to build to

Build to WCAG 2.2 AA.

Content that meets 2.2 also meets 2.1 and 2.0, and the W3C recommends the latest version. As of September 2026, the W3C reports that the 2026 version of EN 301 549 uses WCAG 2.2, while the US Title II rule still names 2.1.

Going from 2.1 to 2.2 adds 6 criteria at Levels A and AA. A US municipality measured only against the Title II rule is legally bound to 2.1 AA, so the 2.2 work beyond that is voluntary. I’d still build to 2.2 anyway, since the EU standard is already heading there.

Where Websites Fail Most Often

Detected failures pile up in a short list of places: low-contrast text, missing image alt text, missing form labels, empty links, empty buttons, and a missing document language.

WebAIM’s analysis of the top 1,000,000 home pages (WAVE, February 2026) puts numbers on them.

• 95.9% of home pages had detected WCAG 2 failures
• 96% of all detected errors fall into the six types above
• 83.9% had low-contrast text
• 53.1% had images with no alternative text

The trend is worse than the snapshot. In 2019 the failure rate was 97.8%, so the web moved less than 2 points in seven years, and the 2026 report reversed six years of small gains.

WebAIM ties the reversal to heavier pages, more ARIA code, third-party frameworks and libraries, and AI-assisted coding. Add the DOJ’s caution that a clean automated report does not prove a site is accessible, and the data points at process more than tooling.

Scanners already flag all six types, yet these types have topped the list for 7 years.

Low contrast stays first because it is a design decision and not a code bug. Fixing color contrast at the palette level repairs it everywhere that palette is used.

The failures are fixable at scale. JSTOR reported zero automatically detected errors on its home page in the 2026 report.

Zero detected errors still does not mean conformant. WebAIM states that the absence of detected errors does not indicate an accessible or conformant page, because automated tools miss some failures.

How to Fix the Most Common Accessibility Barriers

Work through barriers in the order the failure data ranks them: contrast, text alternatives, form labels, link and button names, keyboard access, captions, and ARIA last. Native HTML elements already carry roles and keyboard behavior, so most fixes are markup and style changes and not scripts.

1. Raise text contrast to the WCAG minimums.
2. Give informative images a text alternative, and decorative images an empty alt attribute.
3. Attach a visible label to every form field.
4. Name every link and button so it makes sense out of context.
5. Make every function work from a keyboard, with a visible focus indicator.
6. Caption prerecorded video and offer a transcript.
7. Add ARIA only where native HTML cannot express the role.

Text alternatives and contrast

Both fixes top the list because they are cheap to make. The details decide whether they pass.

On contrast, WCAG 1.4.3 sets 4.5:1 for normal text and 3:1 for large text, meaning at least 18 point or 14 point bold, which is about 24 px and 18.66 px (W3C). Those ratios are hard thresholds, so 4.499:1 fails.

Brand guidelines do not exempt text. Only logotypes do, and placeholder text plus text shown on hover or focus must pass too.

For alt text, write the function and not a description. A search button’s alternative is “search”, not “magnifying glass”, and decorative images take alt=”” so screen readers skip them (W3C WAI).

Complex charts need a short alt text plus the full data in a table or nearby text. Words like “image of” add nothing, since screen readers already announce the element.

Keyboard access and focus

A keyboard user needs to reach every control, leave it again, and see where focus sits at each step.

• Tab order follows reading order, top to bottom and left to right in left-to-right languages
• No keyboard traps, so focus can leave embedded players and widgets
• A visible focus indicator on every focusable element
• Hover-only functions get a keyboard equivalent
• A skip link lets users jump past repeated navigation

WCAG 2.2 added Focus Not Obscured (Minimum) for sticky headers and footers that cover the element holding focus. The W3C’s own examples include a sticky footer fixed to the bottom of the viewport that hides items as a keyboard user tabs down the page, and a cookie banner that covers the control holding focus.

The failure I’d check first is a CSS reset that removes the outline and replaces it with nothing. A custom div styled as a button fails here too, because it never takes focus unless someone adds tabindex and key handlers.

Forms, links and buttons

Every field, link, and button needs a name a screen reader can announce.

Fields need a label element tied to the input through matching for and id values. Required fields should be marked in text, such as the word “required”, never by red color alone (ADA.gov). Error messages should say what went wrong and how to fix it, ideally above the form, and keep the data already entered where possible.

For links and buttons, “Download the 2026 report” beats “click here”, and an icon-only button needs a text name.

Beyond labels, accessible forms let people paste into password fields. The W3C names paste and password managers as qualifying mechanisms under Accessible Authentication (Minimum).

Semantic HTML and ARIA

WebAIM’s 2026 data shows home pages with ARIA averaging 59.1 errors, against 42 on pages without it.

WebAIM cautions that ARIA does not necessarily cause those errors, because pages with more ARIA are also more complex. The pattern still points one way, and ARIA roles and attributes add failure modes whenever they replace native markup.

The W3C’s rule of thumb is that a role is a promise. A div with role=”button” promises keyboard focus and Enter and Space handling, plus a name, and the browser provides none of it.

Native HTML is the right call whenever a button, link, checkbox, select, or heading element already exists for the job, and whenever the control needs keyboard behavior for free. ARIA earns its place when no native element covers the widget, such as a tab panel or tree view, or when a state needs announcing, such as aria-pressed on a toggle button.

Misapplied ARIA also overrides content. An aria-label on a link hides the visible link text from assistive technology, and role=”log” on a table stops it being announced as a table (W3C ARIA Authoring Practices Guide).

Captions and transcripts

Prerecorded video needs synchronized captions under WCAG 1.2.2 (Captions, Prerecorded). Good captions carry speaker names and meaningful sounds such as a door closing, not just dialogue.

Automatic captions alone do not count. The W3C Easy Checks page treats a video that lists only auto-generated captions as lacking sufficient captions, because their accuracy is too low.

A transcript is best practice rather than a requirement. A descriptive transcript that includes meaningful visual information is one accepted way to cover what blind users cannot see.

How to Test a Website for Accessibility

A scanner gives fast, repeatable rule checks. A manual keyboard and zoom pass covers operability, and screen reader testing shows what the page actually sounds like. Each method misses what the others catch, so they get layered.

Automated scanners

Most setups can get by with WAVE, axe DevTools, Lighthouse, or Pa11y.

• WAVE comes from WebAIM and is the evaluation engine behind the WebAIM Million analysis
• Deque’s axe DevTools is a browser extension built on the open-source axe-core rules library
• Google’s Lighthouse weights each accessibility audit by axe impact ratings (Chrome for Developers)
• Pa11y is free and open source, with a command-line tool for one-off runs and Pa11y CI for build pipelines

How much a scanner catches depends on how you count. Deque, which sells axe tools, analyzed nearly 300,000 issues from first-time audits and found that automated rules produced 57.38% of them (Deque, Automated Accessibility Coverage Report).

Counted by success criteria instead, automation found issues for only 16 of the 50 Level A and AA criteria in WCAG 2.1. Both numbers are correct, because a handful of criteria, led by contrast, generate most of the issues.

According to Deque, practitioners who quote much lower coverage are usually counting criteria. Deque also says its engine leaves out any finding that needs manual verification, so the figure is not padded with guesses.

Manual and keyboard checks

Put the mouse aside. A keyboard-only pass looks like this:

• Tab to every link, field, button, and media control
• Tab away from each one, so no widget traps focus
• Confirm the focus indicator is visible at every stop
• Zoom text to 200% and confirm nothing overlaps or disappears
• Turn off styles to check that the content still reads in a sensible order

Keep the results in a written accessibility checklist so every release gets the same pass.

This is where scanners go blind. In Deque’s audit data, 97.51% of keyboard issues came from manual testing.

The W3C adds its own caveat. A page can pass these quick checks and still carry significant barriers, so treat them as a first review.

Screen reader testing

Screen reader testing shows what the accessibility tree says, not what the screen shows. Test the browser and assistive technology combinations your audience uses, because ARIA support gaps exist on both sides (W3C ARIA Authoring Practices Guide).

Listen for a name and role on every control, announced states such as expanded or pressed, and headings a user can jump between.

A quick developer pass is a start, but the W3C recommends involving testers who understand how people with different disabilities use the web.

Do Accessibility Overlays Make a Site Compliant?

No. Overlays are third-party scripts, usually JavaScript, that change a page in the visitor’s browser, and none of them can repair every failure WCAG conformance counts against a site.

The Overlay Fact Sheet, an open letter signed by accessibility practitioners, states that an overlay can improve a handful of provisions but cannot reach full compliance.

The European Commission goes further. It says overlays, and any tool that leaves the site short of the detailed EN 301 549 criteria, are not an appropriate solution, and that issues are best fixed at their source.

Authorities do not speak in one voice. The Department of Justice’s 2022 guidance calls automated checkers and overlays helpful tools if used carefully, while the Commission rejects them as a solution.

Regulators have acted on the marketing side. accessiBe told customers its accessWidget plug-in could make any website WCAG-compliant, and the FTC’s final order requires it to pay $1 million and bars the claim unless the company has evidence.

Several blogs date the penalty to January 2025. The FTC announced the proposed order then and approved it as final in April 2025, by a 3-0 vote.

The Fact Sheet also lists where automated repair is unreliable.

• Text alternatives for images
• Form labels, error handling, and focus control
• Keyboard access
• Interfaces built with React, Angular, or Vue, which change page state independently of the overlay
• PDF, canvas, SVG, and media files, which overlays do not repair

The one defensible case is narrow. The W3C lists a contrast-switch control as a sufficient technique for 1.4.3 (G174) when the control itself meets contrast, so a widget can satisfy one criterion while the rest of the site still has to pass.

Privacy adds a second risk. Overlays that detect a screen reader to flip a mode expose that a visitor has a disability, which the Fact Sheet flags as GDPR and CCPA exposure.

My verdict is that an overlay is no basis for a compliance claim or legal cover. Fix the source markup, and treat any widget as an optional extra.

Which Documents Prove Web Accessibility Conformance?

Procurement teams ask for an Accessibility Conformance Report built on a VPAT. Public sector bodies in the EU also owe the public an accessibility statement under the Web Accessibility Directive, and an evaluation report that names the pages and criteria tested backs up either one.

The Voluntary Product Accessibility Template (VPAT) from the Information Technology Industry Council (ITI) is free, and a completed VPAT is called an Accessibility Conformance Report (ACR).

The April 2025 release (version 2.5Rev) comes in several editions.

• 508 edition, for the Revised Section 508 standards (with WCAG 2.0)
• EU edition, built on EN 301 549 with WCAG 2.1
• WCAG edition, covering WCAG 2.0, 2.1, and 2.2
• INT edition, which combines all three standards

Each criterion is rated as supports, partially supports, does not support, or not applicable, and Level AAA criteria can also be marked not evaluated. The EU edition incorporates WCAG 2.1, while the W3C says the 2026 EN 301 549 revision uses 2.2, so check which edition a buyer expects.

A VPAT is not a certification. ITI does not review or approve the reports, and a government solicitation can still demand a third-party audit, so follow the solicitation’s own wording.

The W3C’s WCAG-EM methodology and its WCAG-EM Report Tool structure a conformance evaluation across a site’s pages. A dated report like this gives a statement or an ACR something to rest on.

For each website and mobile app, the Web Accessibility Directive requires a statement naming the non-accessible content along with alternatives and contacts, plus a feedback mechanism for reporting problems (European Commission). Implementing Decision (EU) 2018/1523 sets the model.

The European External Action Service publishes its site as partially compliant with EN 301 549 V3.2.1 and WCAG 2.1 Level AA, and states that the claim rests on a self-assessment plus testing with WAVE and Lighthouse.

The weak spot is a statement that claims full Level AA conformance with no dated evaluation behind it. A “partially compliant” label with a named list of gaps is the more defensible position.

Web Accessibility FAQ

Does web accessibility help SEO?

Partly. Google’s SEO Starter Guide says alt text and descriptive link text help search engines understand a page, and both are accessibility fixes.

The same guide says heading order does not matter for Google Search, though it matters for screen readers.

Is web accessibility the same as ADA compliance?

No. WCAG is the technical standard and accessibility is the practice of meeting it, while the ADA is the law that makes it mandatory for certain organizations.

The ADA also carries duties beyond WCAG. Even where content falls under a rule exception, a public entity must in many circumstances provide it to a person with a disability in an accessible format (ADA.gov).

Do PDFs have to meet accessibility rules too?

Yes. WCAG reaches documents through WCAG2ICT, and the US Title II rule covers PDFs posted after the compliance deadline.

Preexisting PDFs posted before that date are exempt, unless residents currently use them to apply for or access a service (ADA.gov).

Does web accessibility apply to mobile apps?

Yes. WCAG addresses web content on mobile devices, and the W3C applies it to native apps through WCAG2ICT.

The US Title II rule names mobile apps provided by state and local governments and sets WCAG 2.1 Level AA as the standard.

How much does an accessibility audit or remediation project cost?

Cost tracks scope, not a fixed rate. Issues on shared templates such as headers and footers get fixed once for every page that uses them, so template count and issue volume drive effort more than page count (Deque).

Start with a scoped audit, because testing takes time and planning.

Sustaining Web Accessibility Between Audits

Audits go stale fast. Checks have to run on every release, because every new page or component, and every added script, can introduce failures the last audit never tested.

The cheapest feedback comes first.

• Automated rule checks on every build
• A keyboard and zoom pass on each new component before merge
• A dated full evaluation after each major redesign

The cost is slower merges. Each component carries a manual pass, and a failing rule blocks the release until a developer fixes it. Tested accessible UI components cut that cost, since each release adds fewer new patterns to check.

Checked on October 11, 2026: WCAG 3.0 is still a W3C Working Draft (10 September 2026) that W3C says will not supersede WCAG 2, so this sequence stands until a law or procurement rule adopts it.

• Author
• Recent Posts

Bogdan Sandu

Bogdan Sandu specializes in web and graphic design, focusing on creating user-friendly websites, innovative UI kits, and unique fonts.

Many of his resources are available on various design marketplaces. Over the years, he's worked with a range of clients and contributed to design publications like Designmodo, WebDesignerDepot, and Speckyboy, Slider Revolution among others.

Latest posts by Bogdan Sandu (see all)

• What is Backend in Web Development? - September 13, 2026
• What is Frontend Development? - September 11, 2026
• How to Make a Button in Figma: Design Best Practices - September 10, 2026