Update, April 2026: the US Department of Justice extended the ADA Title II deadlines by one year. Public entities serving 50,000 or more people now have until April 26, 2027, and smaller entities and special district governments until April 26, 2028. The technical standard, WCAG 2.1 AA, did not change.
Website accessibility has been a legal topic for years, mostly through lawsuits and general anti-discrimination rules. In 2025 and 2026 it becomes much more concrete. Two rules with specific deadlines and specific technical standards are arriving, one in the European Union and one in the United States.
This post explains who each one covers and what they ask for. It is a practical overview from a development team, not legal advice. If you are unsure whether a rule applies to you, ask a lawyer who works in this area.
The European Accessibility Act
The European Accessibility Act (EAA) is an EU directive that applies from June 28, 2025. Each member state has written it into national law, and national authorities enforce it.
Who it covers
The EAA covers a defined list of products and services sold to consumers in the EU. For websites and apps, the most relevant categories are:
- E-commerce: online shops and other services that sell to consumers.
- Consumer banking services.
- E-books and the software used to read them.
- Passenger transport services, including booking and ticketing.
- Electronic communications services.
It applies based on where your customers are, not where your company is based. A US company selling online to consumers in the EU can be in scope.
There is an exemption for microenterprises providing services, defined as businesses with fewer than 10 employees and annual turnover or balance sheet total of no more than 2 million euros.
What it requires
The EAA itself describes accessibility requirements in general terms. In practice, the harmonized European standard EN 301 549 is used to show compliance, and for web content it points to WCAG 2.1 at level AA.
Beyond the technical work, businesses in scope are expected to publish information about how their service meets the accessibility requirements.
ADA Title II
In April 2024 the US Department of Justice published a final rule under Title II of the Americans with Disabilities Act. Title II covers state and local governments, and the new rule sets a specific technical standard for their websites and mobile apps.
Who it covers
The rule applies to public entities: states, counties, cities, public schools and universities, transit agencies, public hospitals and similar bodies. It does not directly apply to private businesses. It does matter to private vendors that build or run websites, apps and online services for public entities, because those public entities now need their vendors to deliver accessible work.
What it requires
Web content and mobile apps must meet WCAG 2.1 level AA, with some defined exceptions such as certain archived content and some third-party content.
Deadlines
- April 24, 2026 for public entities serving a population of 50,000 or more.
- April 26, 2027 for public entities serving fewer than 50,000 people, and for special district governments.
What about private businesses in the US?
Private businesses fall under Title III of the ADA, which does not yet have a regulation with a specific web standard. That has not stopped legal action. Web accessibility lawsuits against private businesses are common, and WCAG is the standard that courts, plaintiffs and settlements usually refer to.
So even if neither rule above applies to you directly, WCAG 2.1 AA is the reasonable target. WCAG 2.2, published in October 2023, adds a few further criteria and is a sensible goal for new work.
What WCAG 2.1 AA means in practice
WCAG is long, but most real-world failures come from a short list:
- Images without meaningful alternative text.
- Text with too little contrast against its background.
- Forms with missing labels or error messages that are not announced to screen readers.
- Menus, modals and custom widgets that cannot be used with a keyboard.
- Missing or illogical heading structure.
- Videos without captions.
- Focus indicators that were removed for visual reasons.
- Content that breaks when zoomed to 200 percent or viewed on a narrow screen.
Automated tools catch some of these. Others, like keyboard traps and confusing screen reader output, only show up in manual testing.
How to prepare
- Work out which rules apply to you. Map where your customers are and what services you provide, or whether you supply public entities.
- Audit your key user journeys, not just the home page. Checkout, account creation, booking and contact forms matter most.
- Combine automated and manual testing. Run an automated checker across the site, then test the main flows with a keyboard and a screen reader.
- Fix the shared components first. Fixing a header, form component or modal once fixes it on every page that uses it.
- Check third-party tools. Chat widgets, cookie banners, booking systems and embedded forms are often the least accessible parts of a site, and they are still your responsibility to the user.
- Build accessibility into the process. Add checks to design reviews and development so new features do not undo the work.
- Write an accessibility statement that honestly describes the current state and how people can report problems.
Accessibility work also tends to improve the site for everyone. Clear forms, readable text and predictable navigation help every visitor, and they usually help search engines understand the page too.
Need an accessibility audit or help fixing what it finds? Contact us and we will help you plan the work.