Next month marks one of the most significant accessibility deadlines in web history. On April 24, 2026, the US Department of Justice’s ADA Title II rule requires all public entities serving populations of 50,000 or more to achieve full WCAG 2.1 Level AA conformance. Across the Atlantic, the European Accessibility Act (EAA) is already in effect, setting binding requirements for digital products and services sold in the EU.
If your web application isn’t accessible, you’re not just excluding users. You’re increasingly exposed to legal risk. Here’s what development teams need to know and do.
TL;DR
- The ADA Title II deadline (April 24, 2026) makes WCAG 2.1 Level AA a legal requirement for US public entities and their partners
- The European Accessibility Act is already enforceable, covering private sector digital products and services
- Web accessibility lawsuits have increased year-on-year, with over 4,000 filed in the US in 2025 alone
- Accessibility isn’t just compliance. It improves SEO, widens your audience, and produces better-structured code
- Retrofitting accessibility is expensive. Building it in from the start costs almost nothing extra
What’s Actually Changing?
Web accessibility isn’t new. The Web Content Accessibility Guidelines (WCAG) have existed since 1999. What’s new is enforcement teeth.
United States: ADA Title II
The DOJ’s final rule, published in 2024, establishes WCAG 2.1 Level AA as the technical standard for state and local government websites and mobile applications. The April 2026 deadline applies to entities serving populations of 50,000 or more, with smaller entities getting until 2027.
This doesn’t only affect government agencies directly. If your company builds websites or applications for public entities, or provides digital services that integrate with government platforms, these requirements flow down to you. Procurement contracts are already being updated to mandate WCAG compliance from vendors and development partners.
European Union: The European Accessibility Act
The EAA (Directive 2019/882) took effect on June 28, 2025, and applies to the private sector. It covers e-commerce websites, banking services, e-books, transport ticketing, and a wide range of digital products and services. Unlike the ADA approach, the EAA targets businesses directly, not just public entities.
For companies serving EU customers, including Irish and Dublin-based businesses, compliance is not optional. Member states have transposed the directive into national law, and enforcement mechanisms vary but include fines and market withdrawal orders.
The Real Cost of Inaccessibility
Accessibility lawsuits in the United States have grown consistently. Over 4,000 ADA-related web accessibility cases were filed in 2025, covering everything from missing alt text to inaccessible checkout flows. The legal landscape in Europe is less litigious but increasingly regulated, with market surveillance authorities empowered to act.
Beyond legal exposure, inaccessible websites exclude roughly 15-20% of the global population who live with some form of disability. That’s not a niche market. It’s a substantial portion of your potential user base, often with significant spending power.
Then there’s the reputational dimension. In 2026, shipping an inaccessible product looks like shipping a product that doesn’t work on mobile looked in 2016. It signals a lack of professionalism and care.
WCAG 2.1 Level AA: What It Actually Requires
WCAG can feel overwhelming when you read the full specification. In practice, Level AA conformance centres on four principles, known by the acronym POUR:
Perceivable: Users must be able to perceive all content. This means text alternatives for images, captions for video, sufficient colour contrast (at least 4.5:1 for normal text), and content that works when zoomed to 200%.
Operable: All functionality must be available via keyboard. Focus indicators must be visible. Users need enough time to read and interact with content. Nothing should flash more than three times per second.
Understandable: Text should be readable and predictable. Forms need clear labels, useful error messages, and consistent navigation patterns. The interface shouldn’t behave in unexpected ways.
Robust: Content must work with assistive technologies, including screen readers, switch devices, and voice control. This largely comes down to proper semantic HTML and valid ARIA attributes.
Practical Steps for Development Teams
Start With an Audit
You can’t fix what you haven’t measured. Run your application through automated tools like axe DevTools, Lighthouse, or WAVE to identify the low-hanging fruit. Automated testing catches roughly 30-40% of accessibility issues, covering things like missing alt text, colour contrast failures, and missing form labels.
For the remaining 60-70%, you need manual testing. Navigate your entire application using only a keyboard. Test with a screen reader (NVDA on Windows, VoiceOver on macOS). Check that focus order is logical. Verify that custom components announce their state correctly.
Fix the Foundation First
The most impactful accessibility improvements are often the simplest:
- Use semantic HTML elements (
<nav>,<main>,<button>,<heading>) instead of generic<div>elements with click handlers - Add descriptive alt text to all meaningful images
- Ensure every form input has a properly associated
<label> - Check colour contrast ratios across your entire design system
- Make sure interactive elements have visible focus styles
These changes are straightforward but collectively address a huge percentage of real-world accessibility barriers.
Build It Into Your Process
Retrofitting accessibility onto a finished product is expensive and frustrating. Building it in from the design phase costs almost nothing extra. At REPTILEHAUS, we integrate accessibility checks into our development workflow at multiple stages:
- Design: Colour contrast and touch target sizes checked in Figma before a line of code is written
- Development: ESLint plugins (eslint-plugin-jsx-a11y) catch common mistakes at code time
- CI/CD: Automated accessibility tests run in the pipeline alongside unit and integration tests
- QA: Manual screen reader and keyboard testing on key user journeys
This approach catches issues early when they’re cheap to fix, rather than late when they require architectural changes.
Don’t Rely on Overlays
A word of caution: accessibility overlay widgets (those toolbar icons promising one-click compliance) don’t work. They’ve been widely criticised by the accessibility community, rejected by advocacy organisations, and have even been the subject of their own lawsuits. There is no shortcut. Genuine accessibility requires building it into your code, not layering a widget on top.
The Upside Nobody Talks About
Accessibility work isn’t just a compliance burden. It produces genuinely better applications:
Better SEO. Semantic HTML, proper heading hierarchy, descriptive link text, and image alt text are exactly what search engines reward. Accessible sites tend to rank better because they’re better structured.
Better for everyone. Captions help people in noisy environments. High contrast helps users in bright sunlight. Keyboard navigation helps power users. Good error messages help everyone. Accessibility features benefit all users, not just those with disabilities.
Better code quality. Accessible code is semantic, well-structured, and standards-compliant. It’s easier to maintain, easier to test, and more resilient across browsers and devices.
AI readiness. We’ve written before about LLM optimisation. Well-structured, semantically rich HTML is exactly what AI models parse most effectively. Accessibility and AI discoverability go hand in hand.
What Happens If You Don’t Act
After April 2026, non-compliant US public entities face potential DOJ enforcement actions. Private sector companies face a growing wave of demand letters and lawsuits from plaintiffs’ firms that specifically target accessibility failures. In the EU, market surveillance authorities can require remediation, impose fines, or restrict market access for non-compliant digital products.
More practically, accessibility debt compounds. The longer you wait, the more inaccessible patterns become embedded in your codebase, your design system, and your team’s habits. Starting now, even incrementally, is dramatically cheaper than starting after a lawsuit lands.
Moving Forward
Web accessibility has moved from nice-to-have to legal requirement in both the US and EU. The technical bar, WCAG 2.1 Level AA, is well-defined and achievable. The tools are mature. The knowledge is widely available. What’s needed is commitment to making it part of how you build, not an afterthought.
If your web application or digital product needs an accessibility audit or you’re looking to build accessibility into your next project from day one, talk to our team. We build inclusive, compliant, and high-performing web applications.
📷 Photo by Erik Mclean on Unsplash
