The 2026 WebAIM Million report ended a six-year run of slow improvement. For the first time since the survey started, web accessibility got measurably worse.

WebAIM scanned the top one million home pages and counted 56.1 accessibility errors per page on average, up 10.1% from 51 in 2025. Of those pages, 95.9% had at least one detectable WCAG 2 failure, against 94.8% the year before, and the errors add up to 56,114,377 across the sample. Those are only the failures an automated scanner can see. The report puts full WCAG 2 A/AA conformance somewhere below 4.1%, and that ceiling is optimistic, because a scanner cannot hear what a screen reader hears or follow what a keyboard does.

95.9% of the top one million home pages have detectable WCAG 2 failures. The six most common failure types have not changed in seven years.

Most of the enterprise storefronts we look at are not failing because someone decided accessibility did not matter. They fail because accessibility was never built into the component library, the checkout flow, or the release checklist. It was treated as a remediation project with a finish line, and remediation projects do not hold.

Three separate clocks are now running at the same time. None of them reset when the page ships.

The European Accessibility Act is already in force

The European Accessibility Act applied in full on 28 June 2025, and it does not care where the seller is based. If a business sells goods or services online to consumers in the EU, its website and mobile app are in scope, whether that business operates from Brampton, Austin, or Berlin. The Act defines e-commerce broadly: any sale concluded at a distance, through a website or mobile service, at the individual request of a consumer.

The only meaningful exemption is for microenterprises, defined as fewer than 10 employees with annual turnover or a balance sheet total under EUR 2 million. Everyone above that line is covered. Existing services get a longer runway, out to 2030, but newly launched services had to comply from the start, and EU member states have been staffing up their enforcement bodies through 2026.

The Act does not name WCAG as the single sanctioned method. It defines outcomes instead: services must be perceivable, operable, understandable, and robust, the same four principles WCAG is built on. The harmonised technical standard behind it, EN 301 549, incorporates WCAG 2.1 Level AA. That makes WCAG 2.1 AA the operative benchmark for compliance today, even though WCAG 2.2 has been a published W3C Recommendation since October 2023. Building to 2.2 AA costs little more and covers the 2.1 criteria as a subset, which is the more durable choice.

The Act also imposes obligations that have nothing to do with markup. Companies have to publish accessibility information, pass along manufacturer accessibility data for the products they sell, and provide support channels that are themselves accessible. A help desk that only answers by phone is a gap.

ADA deadlines moved, and the litigation did not

In April 2026 the US Department of Justice issued an Interim Final Rule extending the ADA Title II web and mobile app compliance dates by one year. State and local government entities serving 50,000 or more people now have until 26 April 2027. Smaller entities and special districts have until 26 April 2028. The technical standard did not change. WCAG 2.1 Level AA is still the requirement, and the scope of covered content is unchanged.

If you supply software, platforms, or services to public sector clients, those dates are now part of your own roadmap. Public entities that need to be conformant by 2027 are writing accessibility requirements into procurement documents today, and vendors who cannot evidence conformance get filtered out early.

Private-sector litigation never slowed down enough to need a deadline extension. Plaintiffs filed 3,117 website accessibility lawsuits in US federal court in 2025, a 27% increase over 2,452 in 2024, and the second-highest annual total on record. Website claims made up 36% of all ADA Title III federal filings that year, up from 28%. Add state court actions and the combined figure runs past 5,000. New York led with 1,021 federal filings, Florida followed at 961, and Illinois at 585.

One number from the mid-year analysis deserves more attention than it gets. Roughly 22.6% of the suits filed in the first half of 2025 targeted sites that already had an accessibility widget installed. The overlay was running. The complaint got filed anyway.

Why overlays keep losing

Accessibility overlays and widgets work by loading JavaScript over an existing page and patching what they can detect: adding ARIA attributes, adjusting contrast, inserting skip links. That is a real but narrow slice of the problem.

An overlay cannot reorder the tab sequence in a custom checkout. It cannot give a keyboard user a focus trap that releases correctly, or make a sticky header stop covering the field the user just tabbed into. It cannot write alt text that describes the product. It cannot fix an error message that appears visually but is never announced. And when an overlay injects roles and labels into a document that already has its own semantics, it can make the experience worse for the people it claims to serve.

The regulatory attitude toward overlays has hardened. In 2025 the US Federal Trade Commission reached a $1 million settlement with accessiBe over claims that its widget could deliver automatic compliance. The message to buyers is direct: a vendor's promise is not a defense, and the underlying site is still the site that gets audited.

An overlay is a subscription that reduces the visible error count. It does not remove the barrier, and it does not move the liability.

What WCAG 2.2 asks for that enterprises keep missing

WCAG 2.2 added nine success criteria to 2.1 and removed one (4.1.1 Parsing, now obsolete). Several of the new criteria land exactly where e-commerce interfaces are weakest.

• Target size (2.5.8, AA) requires pointer targets to be at least 24 by 24 CSS pixels. Filter chips, quantity steppers, carousel dots, and close buttons on a product gallery are frequent offenders, especially in mobile layouts built to fit dense grids.
• Focus not obscured (2.4.11, AA) requires that a component receiving keyboard focus is not hidden by author content. Sticky headers, sticky add-to-cart bars, and cookie banners are the usual cause.
• Dragging movements (2.5.7, AA) requires a single-pointer alternative to any drag operation. Drag-to-rotate product images and drag-based sliders need buttons or a text input alongside them.
• Accessible authentication (3.3.8, AA) forbids requiring a cognitive function test, like remembering a password or solving a puzzle, unless an alternative is offered. Password managers, paste, and one-time codes have to work.
• Consistent help (3.2.6, A) requires help mechanisms to appear in the same relative order across pages.
• Redundant entry (3.3.7, A) requires that information already provided in a process not be asked for again, unless it is essential or a security measure.

None of this is exotic. It is the ordinary friction of a checkout flow someone built in a hurry.

Accessibility is an engineering problem, not a QA phase

The enterprises that hold conformance treat accessibility the way they treat performance: as a property of the system, owned by the team that builds it.

Fix the component library, not the pages

The component library is the highest-leverage place to work. Fix contrast tokens once and every page inherits the change. Make the button, input, modal, and menu components handle focus, labels, and error states correctly, and the majority of recurring defects stop being written in the first place. This is also where the accessibility work pays for itself, because a component that announces itself properly to a screen reader tends to be a component with cleaner props and fewer edge cases.

Prefer native elements. A button element arrives with keyboard activation, focus handling, and role already correct. Rebuilding it from a div means reimplementing all of that, usually partially. ARIA patches gaps that HTML does not have.

Make the keyboard path a first-class route

Search, filter, open a product, add to cart, apply a coupon, complete checkout, create an account, submit a return. If any of those cannot be finished with the keyboard alone, the flow is broken for people using switch access, screen readers, and voice control. The same path is the fastest manual test available, and it takes minutes, not days.

Get the content right

Alt text that describes the product rather than the filename. Heading levels that reflect structure rather than font size. Link text that says where the link goes. Error messages that are associated programmatically with the field they belong to and announced when they appear.

Test in layers

Automated checks belong in the pipeline, but for one job: stopping regressions. Run axe or an equivalent in CI on the component library and the critical templates, and fail the build when a known rule breaks. A clean scan is not evidence of conformance. The WebAIM data makes the point on its own, since a page with zero detected errors simply means the scanner found nothing, not that a person with a disability can use the page.

Manual testing covers the rest. A keyboard-only pass and a screen reader pass, run on the revenue-critical journeys, will surface the problems automation misses: focus order, announced names, live region behavior, and whether the modal can be dismissed. Testing with actual assistive technology users catches what no checklist will.

Publish an accessibility statement and a conformance report. The EU framework expects documented evidence, and enterprise procurement teams increasingly ask for a VPAT or ACR. A statement that names the standard, the conformance level, the known gaps, and a contact route for reporting barriers does more for a business than a widget badge.

Do it before the launch, not after the complaint

Accessibility work is cheapest at design time and most expensive after a demand letter arrives. The cost curve is not close.

The market is not a rounding error either. The World Health Organization estimates 1.3 billion people live with a significant disability. In the United States, the CDC puts that at roughly 61 million adults, about one in four. Americans with disabilities hold an estimated $490 billion in disposable income. Those customers abandon carts for the same reasons everyone else does, and inaccessible interfaces give them more reasons.

There is a second return that rarely gets mentioned. Semantic HTML, real labels, sensible heading structure, and working keyboard navigation are the same signals that search engines and AI crawlers parse when they try to understand a page. Accessibility work is usually an SEO improvement with better documentation.

A 90-day sequence that holds

• Inventory the estate. List the customer-facing web properties and apps, and mark which ones fall under the EAA, which support public sector clients, and which carry the most transaction volume.
• Audit the money path first. Search, product detail, cart, checkout, account, and returns. Score them against WCAG 2.1 AA and note where 2.2 adds a criterion.
• Fix the component library, not the pages. Every defect corrected at the source prevents the same defect on the next feature.
• Add automated checks to CI as a regression guard, and wire accessibility criteria into the definition of done and the design review.
• Run manual keyboard and screen reader passes before each major release, with real users involved at least once a year.
• Put accessibility requirements into vendor contracts and RFPs, and require a current ACR or VPAT from platform and agency partners.
• Publish the accessibility statement and keep it honest, including the gaps you have not closed yet.

The 2026 numbers went the wrong way because the industry spent a decade buying overlays and writing policies instead of fixing components. Enterprise teams that build accessibility into the pipeline skip that whole cycle. They also ship faster, because a component that handles focus and labels correctly is a component nobody has to revisit under a deadline.

If you are unsure where your storefront or platform stands, Tech Hub Services runs accessibility audits against WCAG 2.1 and 2.2 AA, maps the gaps to your revenue-critical journeys, and does the remediation work in the codebase rather than on top of it. Reach us at info@techhubservices.ca or +1-416-477-6087 to schedule an assessment.