Accessibility for business websites: why 83.9% of home pages still fail the easiest criterion
The WebAIM Million 2026 report found low-contrast text on 83.9% of home pages — the single easiest WCAG criterion to check by machine — and the six most common failures haven't changed in seven years. This isn't a knowledge problem. It's a measurement problem.
Every March, WebAIM scans the home pages of the million most popular websites and publishes what it finds. The 2026 report recorded 56,114,377 errors across those million pages — an average of 56.1 per page, up 10.1% from 51 in 2025. Low-contrast text alone appeared on 83.9% of pages, up from 79.1% the year before, with an average of 34 distinct instances on each affected page.
The more revealing number is elsewhere: **the six most common failure types have not changed in seven years**, and together they account for 96% of every error detected. All six have well-understood fixes requiring no new research. If the problem were a lack of knowledge, seven years would have been enough to move the numbers. They didn't move — they got worse. That points somewhere else: most teams never actually **measure** their product's accessibility. They run a scanner and trust the output.
Why businesses outside the EU and US can't file this under "later"
Inside Vietnam, the current legal framework binds mainly the public sector. Circular 26/2020/TT-BTTTT sets out the standards for supporting people with disabilities in accessing information and communication products, referencing WCAG 2.0 for the portals of government agencies, public-service units, and press organisations. Purely domestic private companies are not currently bound to an equivalent standard — worth saying plainly rather than overstating.
The picture changes the moment you have customers abroad:
- **The European Accessibility Act (EAA)** became enforceable on 28 June 2025 across all 27 member states. The part that matters most for a Vietnamese exporter: the obligations apply to **any provider offering e-commerce services to consumers in the EU, regardless of where that provider is established**. The exemption threshold is fewer than 10 employees plus turnover or balance sheet under €2M. Beyond meeting WCAG level AA, providers must publish an accessibility statement. Bird & Bird's guide covers the scope in detail.
- **The US market** enforces through litigation rather than inspection. Per EcomBack's 2025 annual report, 3,948 federal website-accessibility lawsuits were filed in 2025, up 23.84% from 3,188 in 2024; counting state courts pushes the total past 5,000. Roughly 70% targeted e-commerce, and 35.8% of the top 500 online retailers received at least one claim.
One detail that's easy to miss: 1,427 of the 5,000-plus suits filed in 2025 targeted companies that **had already been sued before**. Fixing once and moving on solves nothing — every feature you ship afterwards is a chance to reintroduce the same failure.
There's also a reason that has nothing to do with law: most of the work accessibility requires overlaps with the work SEO and general usability require. A correct heading hierarchy, `alt` text that describes what the image actually conveys, clear accessible names on buttons and links, semantic HTML instead of nested `div`s — these are the same signals search engines and AI models use to understand a page.
Six failure types, 96% of all errors
From the 2026 report, the share of home pages carrying each type:
- **Low-contrast text** — 83.9%
- **Images missing alternative text** — 53.1%
- **Form inputs missing labels** — 51.0%
- **Empty links** (an `a` element with no accessible content) — 46.3%
- **Empty buttons** (usually icon-only buttons with no accessible name)
- **Missing document language** (`<html lang>`)
Not one of these needs new architecture or a new library. The last two take minutes to fix. That they persist across hundreds of thousands of sites says they are **not being seen**, not that they can't be fixed.
Trap one: an overlay widget is not compliance
There's a category of product with a very attractive promise: drop in one script tag and your site becomes compliant. The evidence does not support the promise. In 2025, 456 lawsuits — 22.6% of the total — targeted sites that were running exactly these overlays and widgets. In April 2025 the US Federal Trade Commission ordered a major overlay vendor to pay $1 million for falsely claiming its AI tool could make any website WCAG compliant. Case round-ups show several suits ending in orders to remove the overlay and commit to code-level remediation.
The technical reason is straightforward. An overlay runs after the page has loaded and tries to infer meaning from the outside. It doesn't know what a given image depicts, it doesn't know what an icon button does, and in many cases it interferes with the assistive software the user is already running — turning a latent barrier into a demonstrable one that can be recorded and attached to a complaint.
Trap two: believing the scanner sees everything
This trap is subtler, because scanners are genuinely useful. The problem is that their limit is rarely stated: **no automated tool detects much more than about 40% of WCAG issues**. The rest requires judgement about meaning — whether the `alt` text conveys what the image means in this context, whether focus order matches reading order, whether an error message actually reaches the screen reader.
Worse, even inside that machine-checkable 40% there are systematic blind spots. These four are where we most often see mainstream tooling miss contrast problems:
Four blind spots in contrast measurement
- **The effective background, not the design background.** A text colour token is usually tuned against the page background. The same text on a card surface, on an alternating section band, or under a semi-transparent layer has a materially different ratio. Correct measurement composites the entire ancestor background chain first — a colour that reaches 4.7:1 on the page background can land at 3.9:1 on a card surface in dark mode.
- **Text inside SVG.** Scanners read the CSS `color` property. SVG text is painted with `fill`. The result is that every label inside a diagram, chart, or infographic — typically the smallest text on the page, 7–11px — sits outside the tool's field of view. For a technical site or a product page full of diagrams, this can be the largest group of failures nobody knows about.
- **Backgrounds drawn inside the graphic.** When a label sits on a tinted panel drawn inside a diagram, you cannot derive the backdrop by reading the DOM: you have to account for `opacity`, `fill-opacity`, and the opacity of every ancestor group. The reliable approach is to hide the text layer, screenshot the page, and sample the real pixels beneath the glyphs. DOM-based modelling errs in both directions with equal ease.
- **The non-text group (SC 1.4.11).** This is a separate criterion with a 3:1 threshold, covering the borders and fills that identify UI components, focus indicators, and the parts of a graphic needed to understand it. Plenty of design systems reuse a single hairline token for both decorative rules and control borders — sensible aesthetically, but it can leave a button border at barely over 1:1, so a low-vision user can't tell where the hit area is.
Knowing what is *not* a failure matters as much as knowing what is
This part is rarely discussed, and it decides whether your fix wrecks the design. WCAG has explicit exemptions, and applying the criteria mechanically damages the product without helping anyone:
- A component **identified by its own text** — a borderless, background-less accordion button with only a text label — falls under the text-contrast criterion and is exempt from the non-text one. Adding a border does nothing for anyone.
- **Decorative** rules — dividers between blocks, faint background grids — are not UI components. Darkening them to "reach 3:1" only makes the page heavier.
- A stroke **drawn over an already-filled shape** in a diagram: if the fill alone delineates the shape, the overlapping stroke doesn't cost anyone their understanding of the content.
A practical rule: for each reported failure, ask "if this element vanished entirely, would a user lose information or lose the ability to act?" If not, it's decoration. That question separates real failures from noise and saves most of the effort.
A roadmap for a business site already in production
You don't need to rebuild. This order yields the most result per hour spent:
- **Week 1 — measure and classify.** Run the automated scan for the easy group, then add manual measurement for the four blind spots above. The output you want is a list grouped by *root cause*, not by location: 400 reported failures usually reduce to five or six colour tokens.
- **Week 2 — fix in the design system.** Adjust the tokens, add text-specific colour variants where a brand hue can't both read as words and hold its identity, and record the reasoning in the source so the next person doesn't quietly restore the old value.
- **Week 3 — keyboard and semantics.** Walk the primary flows with the keyboard alone, fix focus order, give icon buttons accessible names, label every input, and make sure form errors are announced to screen readers.
- **Ongoing — lock it into the process.** Add a contrast check to CI so the next feature doesn't reintroduce the old failure. This is the difference between "fixed once" and "compliant" — and it's why 1,427 companies were sued again in 2025.
For complex interface components, picking a library with real support built in is far cheaper than handling ARIA and keyboard navigation yourself. That is one reason we built Forge Select with full ARIA and keyboard navigation from the start, and released it under the MIT license on our Community page.
Conclusion
The six failure types have held their positions for seven years not because they're hard — they're among the easiest things to fix. They persist because most teams have never seen them: one automated pass returns a green table, and nobody checks what the tool skipped. For a business with customers in the EU or the US, the gap between "looks fine" and "measured fine" now has a price in money. For everyone else, it's still the gap between a site everyone can use and a site most people can use. See KonexForge's Development capability, or get in touch if you want an accessibility assessment measured against a real build rather than an automated scorecard.
Related articles
Technology solutions for private clinics and doctors: from e-invoicing to electronic medical records
Within an 18-month window, Vietnam's private clinics and independent doctors face three new compliance obligations at once: e-invoicing under Decree 70/2025, the end of presumptive tax from Jan 1, 2026, and a Dec 31, 2026 deadline for electronic medical records under Circular 13/2025/TT-BYT — while most still run on paper logs, Excel, and Zalo. The minimal-footprint architecture we propose, and why a scaled-down hospital system isn't the answer.
Why digital transformation leads to 5-6 disconnected systems and data duplicated everywhere
Many companies and government agencies don't lack technology — they have too many systems. After a few years of piecemeal digital transformation, an organization typically ends up running 5-6 systems that don't talk to each other, with the same customer or employee existing under several different data versions. This post breaks down why that happens and the consolidation architecture KonexForge applies to fix it — not by buying a seventh system.
Forge Select: a zero-dependency, framework-agnostic open-source replacement for Select2
Select2 has served the web community for years, but it's built on jQuery — a dependency that's increasingly hard to justify on a modern stack. Forge Select is the select/combobox component we built ourselves: a 5-file core, zero runtime dependencies, yet full-featured enough for real products — virtual scroll, tree select, tags, and full accessibility.