Website Accessibility: What to Fix First, and Why a Widget Will Not Do It

Where do you start when a scan reports hundreds of accessibility errors and a vendor offers to fix them with one line of code? Here is the order we work in, by what stops people and what costs little: what the US law asks, what scanners miss, why overlay widgets do not solve it, and a 20-minute test any manager can run.

IN SHORT

What to fix first

Fix whatever stops a person on the path to money, then whatever repeats on every page and costs little. In practice that means page language, names on links and buttons, text contrast, image alt text, form labels and error messages, then keyboard access, visible focus, target size and sign-in. Test by hand, because a scanner finds only part of the problem, and do not count on an overlay widget.

The reason for this order sits in one study. WebAIM's scan of the top million home pages found detectable WCAG failures on 95.9% of them, 56.1 errors per page on average, and six error types made up 96% of everything it detected: low contrast, missing alt text, missing form labels, empty links, empty buttons and missing page language (WebAIM, data of February 2026). Most of those live in shared templates and styles, so one fix can clear the same error from thousands of pages.

Our article on how much testing a website needs before launch gives accessibility one chapter inside a launch plan. This one goes through the work itself, for owners, CTOs and the developers they hand it to. It is a technical guide and not legal advice; for a demand letter or a contract question, talk to a lawyer in your market.

A scan tells you where to start, never that you have finished.

THE LAW

What the law asks in the US

ADA Title III prohibits discrimination by businesses open to the public. The Justice Department's guidance says those businesses must make what they offer online accessible, leaves them flexibility in how, and names the barriers it has in mind: poor color contrast, images without text alternatives, forms without labels and mouse-only navigation (ADA.gov, March 2022). It sets no technical standard and points to WCAG as helpful guidance, and Seyfarth Shaw, the law firm that tracks these cases, expects no new Title III regulation (March 2026). So WCAG 2.2 Level AA, the current W3C Recommendation, is the working yardstick and the one we check against.

Federal filings are only the visible part. Seyfarth counted 3,117 website suits in federal court in 2025, up 27%, or 36% of all Title III suits. In 2025 New York had 1,021, Florida 961, Illinois 585 and California 4. That last number does not mean California is safe. Appellate courts there have held that online-only businesses are not covered, and plaintiffs seeking damages under California's Unruh Act have moved to state court, where the statute sets a minimum of $4,000 per offense. New York's federal judges have become stricter about standing, and plaintiffs have followed the same road into state courts. For the first half of 2026 Seyfarth counted 5,006 Title III suits of every kind; a website-only figure comes with its final tally in early 2027.

UsableNet, a vendor that counts federal and state cases together, projects about 6,176 digital accessibility suits for 2026. In its data 79% are against e-commerce, 36% of sued companies have revenue above $25 million, so most are smaller than that, and about a quarter of suits target a company that has already faced a similar claim (UsableNet, July 2026).

If you sell to consumers in the EU, there is a statute with a date. The European Accessibility Act covers e-commerce services provided to consumers after 28 June 2025 and exempts service microenterprises: fewer than 10 people and no more than €2 million in turnover or balance sheet. On 4 June 2026 a court in Caen ruled on an interim basis against Carrefour: its own audit showing 71.21% conformity was not enough, and the site "cannot be merely a little accessible". The barriers it named were alt text, contrast, poorly labelled links, assistive technology support and HTML semantics. Carrefour has six months before a penalty of €500 a day (Taylor Wessing, June 2026). That list is close to the list in this article.

THE ORDER

The order we fix things in

We start from the journeys that bring money: from a landing page to a paid order, or from a service page to a sent request. Each finding on them gets three questions. Does it stop the person completely? How many pages share it? How much work does it take?

A complete block on the money path goes first whatever it costs: a checkout that cannot be reached from the keyboard outranks hundreds of contrast errors on the blog. After blockers come cheap fixes that repeat everywhere, because they clear the largest share of errors for the least money. This ranking is our working judgement, and WCAG does not prescribe it. It also moves with the business: on a lead site the form leads, in a large catalog the filters do, in a client portal the sign-in does. The usual starting order, with frequency figures from WebAIM's 2026 data:

Other items wait unless they sit on your money path. Prerecorded video needs captions (1.2.2, level A), so if video is how you sell, move it up. Text should still work at 200% zoom (1.4.4, level AA). Heavy motion deserves a switch: our own 3D first screen, the subject of our three.js experiment, falls back to a light version for visitors who ask for reduced motion.

CHEAP FIXES

Language, names, contrast, alt text

Language. One attribute on the html element tells assistive technology which voice to use. On a multilingual website each version declares its own, and a shared template that hard-codes one value makes every other version wrong.

Names. A cart icon, a slider arrow and a social link often have no text, so a screen reader announces "button" or reads out a file address. Visually hidden text or an aria-label fixes it. Prefer real HTML elements while you are there: a real button gets keyboard behavior from the browser, ARIA roles add none of it, and W3C's guidance opens by warning that bad ARIA is worse than none. WebAIM found 59.1 errors on pages using ARIA against 42 on pages without, though those pages are also more complex, so the gap does not prove ARIA caused them.

Contrast. Normal text needs at least 4.5:1 against its background, large text 3:1, and buttons, field borders and meaningful icons 3:1 (1.4.3 and 1.4.11). A light grey for small print is usually one variable used in hundreds of places. A brand color that fails on white can stay as an accent, with a darker shade taken for text. This touches the look, so a designer has to make the call; contrast is one of the things people feel without naming, as we wrote in Design You Don't Notice.

Alt text. Describe what the picture does on that page. On a product page, say what a buyer needs to know ("black leather tote, front view"); on a case page, what the picture proves. Purely decorative images get an empty alt so they are skipped. Make the field required in your admin panel for each language, or the same error returns with the next upload.

One color token can fix hundreds of contrast errors at once.

FORMS AND KEYS

Forms, keyboard, focus and sign-in

Labels and errors. Each field needs a visible label tied to it in code. W3C's forms tutorial says plainly that placeholder text does not replace one, and screen readers do not treat it as a label. An error has to be identified in text (3.3.1, level A), not only by a red border, and should suggest the fix where one is known (3.3.3, level AA): "Enter the date as 12/31/2026", not "Invalid input". Fields for personal details should declare their purpose (1.3.5, level AA), so browsers can fill them in, which helps every customer on a phone.

Keyboard. Everything a mouse can do must work from the keyboard, and focus must never get stuck (2.1.1 and 2.1.2, level A). This takes real front-end hours, because the failures sit in custom components: a menu that opens only on hover, a filter built from div elements, a size selector, a date picker, a cart drawer. In WebAIM's survey of screen reader users, menus, tabs and dialogs that misbehave came second among problems (1,539 respondents, December 2023 to January 2024). For popups, W3C's dialog pattern fits in a ticket: focus moves in when it opens, Tab stays inside, Escape closes it, focus returns to the control that opened it. Test cookie banners, sign-up windows and chat widgets against those four lines.

Focus and targets. Focus has to be visible (2.4.7, level AA). The usual cause of failure is one line in a CSS reset, outline: none, with nothing put in its place; a :focus-visible style in your brand color solves it and changes nothing for mouse users. WCAG 2.2 adds that your own content must not entirely hide the focused element (2.4.11, level AA), and W3C names sticky headers and cookie banners as typical causes; CSS scroll padding handles most of it. Pointer targets must be at least 24 by 24 CSS pixels or have enough space around them (2.5.8, level AA). Close buttons, pagination and language switchers are the usual offenders, and padding fixes them without changing the design.

Sign-in. The accessible authentication criterion (3.3.8, level AA) means no memory or puzzle test without an alternative. W3C's explanation is practical: blocking paste into a password field or stopping a password manager fails it, and an email link is a listed way to pass. CAPTCHA was the most problematic item in the same WebAIM survey, by a notable margin. Details already given in the same process should not have to be typed again (3.3.7, level A), which is also plain good checkout design.

SCANS

What a scan finds and what it misses

W3C is plain about this: evaluation tools can assist a human evaluator and cannot determine that a site is accessible. Published figures on how much they find look contradictory until you see what each one counts.

The UK Government Digital Service built a page with 143 barriers and ran ten tools on it in 2017. All ten together missed 29% of them, and the best single tool found 41%. Deque, which makes axe and sells these tools, analysed nearly 300,000 issues from its own audits and states that axe-core rules found 57.38% of them, while only 16 of the 50 Level AA criteria in WCAG 2.1 produced automated findings at all. Both can be true: a few common kinds of error repeat thousands of times, so a scanner catches much of the volume and few of the kinds. Lighthouse needs the same care. Its accessibility score is a weighted average of pass or fail audits, and manual checks do not count toward it (Chrome for Developers, November 2026), so a score of 100 means only that the automated rules found nothing.

A scanner still earns its place. Run axe or Lighthouse in the build pipeline as an alarm, so a release that adds new errors stops before it ships, next to the manual checks in a QA and software testing plan.

OVERLAYS

Why an overlay widget does not solve it

An overlay is a script that promises to detect and repair accessibility problems as the page loads, often with a toolbar for font size and contrast: one line of code, a monthly fee and a badge.

In April 2025 the US Federal Trade Commission approved a final order requiring accessiBe to pay $1 million. The company had said its accessWidget plug-in could make any website compliant with WCAG; the complaint alleged those claims were false, misleading or unsubstantiated. The order bars such claims without evidence. Read it precisely: it concerns one company's advertising, and it neither bans widgets nor settles the legal position of a site that uses one.

The mechanism is the bigger problem, since the script runs on top of the page and your templates stay as they were. The Overlay Fact Sheet, signed by accessibility specialists including contributors to the WCAG, ARIA and HTML specifications, sets out why: conformance means meeting all requirements of the standard, overlays cannot repair everything, and they do not touch PDF, canvas, SVG or media files. It also cites WebAIM's practitioner survey, where 72% of respondents with disabilities rated these tools as not at all or not very effective.

It does not work as a shield either. UsableNet, which sells accessibility services, reports that about 20% of companies sued in 2026 had a widget or overlay installed (July 2026), and the Carrefour court assessed the site criterion by criterion. The budget is better spent on the shared templates, where the same money removes errors for good.

A widget changes the page after it loads. The template stays broken.

20 MINUTES

A 20-minute test for a manager

You need no developer. Pick your main path, say from the home page to a sent request or a filled cart, and record the screen while you go.

1. Minutes 0 to 7: keyboard only. Put the mouse aside and use Tab, Shift+Tab, Enter, Space, the arrow keys and Escape. Can you always see where you are? Can you open the menu and choose a filter? Does a popup let you out?
2. Minutes 7 to 9: zoom. Set the browser to 200%. Is any text cut off, and can you still reach the button?
3. Minutes 9 to 16: screen reader. On a Mac press Command-F5 for VoiceOver, then VO-U for the rotor with its lists of headings and links. On Windows press Ctrl + Windows + Enter for Narrator, then the Narrator key + S twice to see headings, links and landmarks. On an iPhone go to Settings, Accessibility, VoiceOver. Do the headings read like an outline? Do links say where they lead? Does the form tell you what each field is and what went wrong?
4. Minutes 16 to 18: a scan. Run Lighthouse from Chrome DevTools on the page with your form and note what fails.
5. Minutes 18 to 20: the tree. In DevTools open Elements, then Accessibility, then Show accessibility tree. Open your popup. Are the price and the main button still there?

Do not skip the phone: 91.3% of surveyed screen reader users also use one on a mobile device (WebAIM, December 2023 to January 2024, an uncontrolled survey, so read it as direction).

Some of what you struggle with will be your own inexperience with these tools. The test finds obvious breakage on one path and proves nothing about conformance, but it tells you whether you have a problem and gives a developer a recording of it. A formal conformance report needs an accessibility specialist and people who use these tools every day, and when a product needs that, we say so.

THE SAME TREE

The same tree serves AI agents

The browser builds an accessibility tree from each page, a subset of the DOM holding what matters for assistive technology, and screen readers rely on it (Chrome for Developers, November 2026). Software now reads it too: Microsoft's Playwright MCP server, which lets AI models drive a browser, states that it works from the accessibility tree and not from pixels.

We saw the result directly. When we sent an AI shopping agent to 15 US online stores in October 2026, in two of them a sign-up popup left nothing in the accessibility tree but an iframe, so an agent reading the page through that tree saw no price, no sizes and no button until the window closed.

We would not sell accessibility as an AI tactic. Not every agent reads pages this way, and we have no data tying these fixes to more sales through agents. The practical point is narrower: named buttons, real labels and clean headings serve people and software at once.

COST AND UPKEEP

What it costs and how it stays fixed

Accessibility regresses without anyone deciding it should. A new banner, a plugin update or an image uploaded without alt text brings errors back, so you need a habit more than a project: a scanner in the pipeline, a keyboard pass over the critical paths before each release, required alt fields for every language, contrast held in the color tokens.

There are three ways to buy this work from us, with all prices published:

• To find out where you stand: a usability audit, from $1,500, takes one to two weeks and checks the WCAG 2.2 basics on the journeys that bring money, alongside behavior data and speed. It is a review of the basics, not a conformance audit or legal advice, and fixes are priced separately once they are known.
• To check every release: QA and software testing, from $30 an hour, with these checks in the test plan. Paid tools are billed separately, and fixing what is found is development work.
• To keep it fixed: website maintenance and support, from $1,000 a month, where small fixes fall within the plan's hours.

The price moves less with the number of errors than with how many templates produce them. A site with one clean template can clear thousands of errors in a few changes; one built from years of layered themes may need its technical debt paid first. When we build a product ourselves, none of this is a separate purchase: contrast sits in design, names and labels in the components, keyboard checks in QA, all shaped around how your customers actually reach you, and the code and test materials are handed over to you under the contract.

FAQ

Sources

• WebAIM: The WebAIM Million 2026
• W3C: WCAG 2.2
• Seyfarth Shaw: Website lawsuit filings in 2025
• FTC: Final order against accessiBe
• Deque: Automated accessibility coverage report