Updated August 14, 2026 to reflect the extended ADA Title II and HHS Section 504 deadlines, and the 2026 WebAIM data.
Three separate rules now point at the same technical standard, WCAG 2.1 Level AA, and two of them moved their deadlines in 2026. State and local government sites fall under ADA Title II, healthcare organizations receiving federal funding fall under Section 504, and anyone selling to EU consumers falls under the European Accessibility Act.
Businesses outside those three categories are not exempt from the underlying risk. The DOJ has treated websites as places of public accommodation under the ADA for years, and federal website accessibility filings rebounded in 2025 after two years of decline.
The baseline is also moving the wrong way. 95.9% of home pages have detectable WCAG failures, up from 94.8% a year earlier, which reversed six consecutive years of gradual improvement. Detected errors rose roughly 10% over the same period, to an average of 56 per page. If you have not checked your site recently, the odds that it fails are higher now than the last time you looked.
Which rules apply to you, and when
Three regimes, three sets of dates, one technical standard.
ADA Title II covers state and local government entities. The DOJ’s Interim Final Rule in April 2026 extended the original date by a year, so entities serving populations of 50,000 or more have until April 26, 2027, and smaller entities and special district governments have until April 26, 2028. Neither the standard nor the scope of covered content changed, and the DOJ has said it expects to enforce at the new dates.
Section 504 covers organizations that receive federal financial assistance through HHS, which reaches well past government into private healthcare. Hospitals, clinics, community health centers, and individual practices are in scope, and the requirement extends beyond the marketing site to patient portals, telehealth platforms, mobile apps, and kiosks. HHS extended these dates in May 2026 as well: recipients with 15 or more employees have until May 11, 2027, and recipients with fewer than 15 have until May 10, 2028. This is the first federal rule to put enforceable digital accessibility standards on private healthcare providers, so a small practice that takes federal funding is covered the same way a hospital system is.
The European Accessibility Act has been in force since June 2025 and applies to businesses selling to EU consumers regardless of where they are based, with one carve-out: service providers with fewer than 10 employees and under EUR 2 million in turnover are exempt. The technical standard is EN 301 549, which incorporates WCAG 2.1 AA in full. It also carries an obligation that is easy to miss: under Article 13 and Annex V, a published description of how your service meets the accessibility requirements, kept available for as long as the service runs, with a duty to tell the national authority and fix it if it falls out of conformance. Some member states go further, so check the local transposition. That is separate from the technical work, and it is the fastest gap to close.
If none of the three applies to you, Title III of the ADA still might. It covers places of public accommodation, and it is the basis for most private-sector web accessibility litigation.
What WCAG 2.1 AA means in plain language
WCAG stands for Web Content Accessibility Guidelines. It’s the standard that defines what an accessible website looks like. The “2.1” is the version. “AA” is the conformance level.
There are three levels: A (minimum), AA (the accepted standard), and AAA (strictest). AA is what compliance frameworks reference and what the courts apply, which makes it the right target.
The standard organizes requirements around four principles. Your site must be:
- Perceivable: content can be seen, heard, or read by everyone, including users with visual or hearing impairments. This covers color contrast, alt text on images, captions on video, and text alternatives for non-text content.
- Operable: every function works with a keyboard, not just a mouse. Links, buttons, forms, and menus must be navigable without a pointing device. Nothing should flash in a way that could trigger seizures.
- Understandable: content is readable and the interface behaves predictably. Forms explain what’s expected. Error messages say what went wrong and how to fix it. Navigation is consistent across pages.
- Robust: content works with assistive technologies like screen readers. This means semantic HTML, correct use of ARIA attributes, and valid markup that assistive technology can reliably parse.
There is no mystery to it. The violations that trip up most sites are straightforward to identify and, in most cases, straightforward to fix.
The five issues to fix first
These cover the majority of real-world violations. If your site passes on these five, you’ve addressed the most common failures.
1. Color contrast
83.9% of home pages have insufficient contrast between text and background. WCAG AA requires a 4.5:1 ratio for normal text and 3:1 for large text. Light gray text on a white background, thin fonts on busy images, placeholder text in form fields: these are the most common failures.
What to check: Run your brand colors through a contrast checker. Check body text, headings, link text, button text, and form placeholders against their backgrounds. Don’t forget hover states and focus states.
2. Missing or generic alt text
53.1% of home pages have images with missing alt text. A screen reader reads the alt attribute aloud. If it says “image1.jpg” or nothing at all, the user gets no information. If every image says “photo,” that’s not much better.
What to check: Every informational image needs alt text that describes what the image communicates, not what it looks like. Decorative images (visual flourishes, background patterns) should have empty alt attributes so screen readers skip them entirely.
3. Keyboard navigation
If your site only works with a mouse, it doesn’t work for users on keyboards, switch devices, voice control, or screen readers. Every link, button, form field, dropdown, and modal needs to be reachable and operable with the Tab key and Enter/Space.
What to check: Put your mouse away. Tab through your entire site. Can you reach every interactive element? Can you see where focus is (a visible outline or highlight)? Can you open and close menus, submit forms, and navigate without getting stuck? If you get trapped in a widget with no way to tab out, that’s a keyboard trap: one of the most severe violations.
4. Form labels and errors
Form inputs without associated labels are one of the most common accessibility failures. A screen reader user tabbing into an unlabeled input field has no idea what to type. Placeholder text doesn’t count as a label because it disappears when the user starts typing.
What to check: Every input field should have a visible label linked to it. Required fields should be clearly marked. Error messages should explain what went wrong and which field needs attention, not just “There was an error.”
5. Heading structure
Headings aren’t just visual styling. Screen reader users navigate by headings the way sighted users scan a page visually. If your heading hierarchy jumps from h1 to h4, or uses headings purely for font size, the page structure is broken for assistive technology.
What to check: Every page should have one h1. Headings should follow a logical order (h1, h2, h3) without skipping levels. If something looks like a heading but isn’t marked up as one, it’s invisible to screen readers.
How to run a basic audit yourself
You don’t need to hire someone to find out where you stand. A few free tools will surface the most obvious issues:
- Browser DevTools Accessibility Panel: built into Chrome and Firefox. Inspect any element and check its accessibility properties, roles, and labels.
- axe DevTools: a free browser extension that scans the current page and lists WCAG violations with explanations and fix suggestions.
- WAVE: a web-based tool that overlays accessibility errors and warnings directly on your page. Good for visual learners.
- Lighthouse: built into Chrome DevTools. Run an accessibility audit and get a scored report with specific issues.
These tools catch the violations that can be detected programmatically: contrast failures, missing alt text, broken ARIA attributes, missing form labels. What they cannot catch is anything needing a person to judge meaning, sequence, or context, which is a larger share of the standard than a clean report suggests. What automated scans miss covers that gap and the manual pass that finds it. What a scan will tell you is whether you have obvious problems.
Run one of these tools on your homepage. If it flags more than a handful of issues, the rest of your site likely has similar problems.
Why accessibility overlays don’t work
If you’ve seen a widget that promises one-click WCAG compliance (a small icon in the corner of a site that opens an accessibility menu), know that these don’t meet compliance requirements. In 2025 the FTC fined accessiBe $1 million for claiming its widget could make any website WCAG-compliant.
Overlays attempt to fix issues client-side with JavaScript. They can’t fix missing alt text because they don’t know what the image represents. They can’t fix heading structure because they don’t understand the content hierarchy. They can’t fix keyboard traps because they don’t control the site’s interaction patterns. What they can do is add another layer of JavaScript that sometimes conflicts with the assistive technology users already have.
The Overlay Fact Sheet, a public statement against overlay products, has been signed by accessibility professionals including contributors to the WCAG, ARIA, and HTML specifications and accessibility engineers at Google, Microsoft, Apple, and the BBC. Lawsuits have named overlay-equipped sites as non-compliant for years, and 2025 filings increasingly referenced accessibility widgets directly while alleging that code-level barriers remained. For a full breakdown of why overlays fail audits, users, and courts, see Why Accessibility Overlays Don’t Count as WCAG Compliance.
When to bring in a professional
If your audit surfaces a handful of contrast issues and missing alt text, you can probably fix those internally. These are HTML and CSS changes that don’t require deep accessibility expertise.
Bring in a professional when:
- Your site is large or complex (dozens of pages, dynamic content, authenticated sections)
- Automated tools show widespread issues across multiple categories
- You need to test with actual assistive technology (screen readers, switch devices)
- The codebase has structural problems (non-semantic markup, missing landmarks, JavaScript-heavy interactions)
- You’re facing a compliance deadline and need a clear scope, timeline, and verification process
The difference between automated scanning and a professional audit is everything a scan cannot decide on its own. A professional tests with real assistive technology, evaluates the user experience (not just the markup), and prioritizes fixes by severity so the highest-impact issues get resolved first. Here’s what that process looks like in practice.
Accessibility isn’t a one-time fix
Compliance is the floor rather than the ceiling. The WHO estimates that 1.3 billion people, around 1 in 6 globally, experience significant disability, and the CDC puts the share of US adults reporting a disability at 1 in 4. An inaccessible site excludes that audience entirely. The things that make a site accessible (semantic HTML, clear heading structure, descriptive link text, sufficient contrast) are also what search engines parse and what AI assistants need in order to cite your site.
Compliance also decays. Every content change, feature addition, and CMS edit is a chance to reintroduce violations, which is why the sites that stay compliant build accessibility into their process rather than their launch checklist. A recurring conformance check is one of the four areas ongoing website maintenance covers, alongside performance, dependency health, and structural drift. Treat the dates above as checkpoints in that process, not as the finish line.
Not sure where your site stands against any of the three? Send us a URL and we’ll audit it against WCAG 2.1 AA and come back with what’s failing, in priority order.