Faster to Build, Harder to Use? Write Web Accessibility into Acceptance Before Custom Development
AI has made building a website several times faster, but it has not made websites easier to use. Each year the nonprofit WebAIM tests the home pages of the top one million sites, and the 2026 result is the first step backward in six years: 95.9% of home pages had detectable accessibility errors, averaging 56.1 per page. The report's conclusion names one of the causes directly: growing reliance on third-party frameworks and AI-assisted coding. Web accessibility can sound like a concern for large enterprises or government sites. In practice it decides whether older customers, people with low vision, keyboard-only users and anyone reading a phone in bright sunlight can understand your site and complete an order. This article covers the latest data and four things to write into acceptance before you commission custom development.
The Numbers: Web Accessibility Slips for the First Time in Six Years
Key points from the 2026 WebAIM Million (tested in February 2026):
- 95.9% of home pages had detected WCAG 2 failures, up from 94.8% a year earlier.
- Pages averaged 56.1 errors, a 10.1% increase from 51.
- The average home page had 1,437 elements, up 14.3%. The more complex a page, the harder it is to get every detail right.
WCAG is the international standard for accessible web content, and most regulations and lawsuits refer to it. WebAIM links the rise in errors to shifts in how the web is built, including heavier use of third-party frameworks and libraries and AI-assisted coding, often called "vibe coding." It also found that most of the popular JavaScript libraries it examined were associated with more detected errors.
That does not mean AI-written code is inherently worse. It means that when output gets faster and pages get more complex while nobody puts accessibility on the checklist, errors are mass-produced along with everything else.
More Tools Have Not Meant Fewer Lawsuits
In the United States, accessibility is a legal risk as well as an experience issue. Data from UsableNet, which tracks filings, shows:
- 4,928 web accessibility lawsuits were filed in 2025, and more than 4,000 have been filed every year since 2021.
- September 2026 alone added 360. Of those defendants, 91 already had a third-party accessibility widget on their site when they were sued, and 78 had been sued before.
- Equidox, summarizing UsableNet's research on filings through mid-June, reports that 2026 is on track to exceed 6,000, nearly 20% above 2025.
The most affected industries are retail and e-commerce, restaurants, travel and hospitality, healthcare, banking and entertainment: businesses that serve consumers directly.
Two points are worth remembering. First, installing a widget is not compliance; the problem lives in the site's own code and design. Second, companies that have been sued get sued again, which suggests that handling one complaint without building accessibility into daily work lets the problem return.
Laws differ by country, and whether they apply to you is a question for a lawyer. But if your site serves consumers in the US or Europe, this is not a topic to ignore.
The Six Most Common Errors Are Not Hard to Fix
WebAIM lists the six most common failures on home pages:
- Low contrast text (83.9%). Light gray on white looks elegant and is hard to read.
- Missing alternative text for images (53.1%). Screen readers cannot describe the image, and AI search cannot read it either.
- Missing form input labels (51%). Users cannot tell what a field is for.
- Empty links (46.3%). Links that are only an icon, with no text description.
- Empty buttons (30.6%). Buttons with no readable name.
- Missing document language (13.5%). Speech tools may pronounce the page in the wrong language.
None of these require advanced engineering or a rebuild. They stay on the list every year because nobody is assigned to own them and they are not written into acceptance criteria.
Four Things to Write into Acceptance Before Custom Development
1. Name the standard instead of writing "must be accessible"
State the level in your requirements, such as WCAG 2.1 AA or 2.2 AA. The US Department of Justice rule for state and local government websites uses WCAG 2.1 AA. Although the earliest deadline was pushed back in April to April 2027, that level remains the benchmark cited most often in practice.
2. Combine automated scans with manual testing
Automated tools find only part of the problem. At acceptance, ask the development team to demonstrate two things: completing an order or submitting a form from the home page using only a keyboard, and understanding every button and field with a screen reader. For more on how to review AI-written code, see AI Writes Code Fast. Who Checks It?.
3. Start at the design stage
Contrast, type size, button size and how error messages appear are design decisions. Fixing them after development costs far more. Good brand design and accessibility do not conflict; clear hierarchy and sufficient contrast are fundamentals of good design.
4. Assign an owner after launch
Accessibility degrades as content changes. The colleagues who upload products and write articles need to know that images need alt text and link text should say where it leads, and every redesign or new feature needs another check. If people inside your company build tools or pages with AI, those need the same check before going live, which we discussed in When Should Employee-Built AI Tools Go to Professional Development?.
Conclusion: AI Handles Speed, People Make Sure Everyone Can Use It
AI can draft alt text, check contrast and find unlabeled fields, and it is good at all of that. But "this site must work for everyone" is a decision people have to make and write into the contract. However fast and polished a site is, if some customers cannot use it, part of the brand is missing. That is what TitApeX means by "AI delivers perfection; people make it moving."
If you are planning a new website or system and want accessibility built into design and development from day one, take a look at our services or get in touch.
Comments