Accessibility
Most websites aren't accessible. That's now a legal problem.
95.9% of home pages had detected WCAG 2 failures when WebAIM scanned the top million in February 2026. The European Accessibility Act is in effect, and federal website accessibility filings rose again in 2025 after two years of decline. We audit against WCAG 2.1 AA, fix what's broken, and monitor for regressions so your site stays compliant as it evolves.
The Problem
The European Accessibility Act took effect in June 2025. It covers e-commerce and a named list of other consumer services sold into the EU, wherever the seller is based, though microenterprises providing services are exempt. ADA Title II requires state and local government websites to meet WCAG 2.1 AA. The compliance deadline was extended in April 2026 and now falls in April 2027 for larger entities, April 2028 for smaller ones. The DOJ treats websites as "places of public accommodation" under the ADA, and enforcement actions against private businesses have followed. Federal website accessibility filings rose 27% in 2025, to 3,117, after two years of decline, when they made up 36% of all federal ADA Title III filings. Defending one of them costs more than fixing the site, whatever the outcome.
Which of these rules apply to your site, and by whenCompliance aside, the business case is straightforward. An estimated 1.3 billion people, 1 in 6 worldwide, live with significant disability, and in the US more than 1 in 4 adults report a disability of some type, which is a broader measure than the global one. Inaccessible sites exclude that audience entirely. Accessible sites see measurably more organic traffic because the things search engines reward (semantic HTML, heading structure, descriptive link text, alt text) are accessibility fundamentals. Clearer navigation, better contrast, and logical structure improve conversion for every user, not just those using assistive technology.
Already monitoring performance? See how accessibility fits into ongoing maintenanceWhat We Audit
83.9% of home pages have insufficient color contrast. 53.1% have missing alt text on images. These are the most common violations and the most straightforward to fix, but they make content invisible to users with low vision or screen readers.
Every foreground/background color combination gets checked against AA thresholds (and AAA where practical). Alt text is reviewed for accuracy and context, not just presence.
If a site only works with a mouse, it doesn't work for a significant portion of users: people using keyboards, switch devices, voice control, and screen readers. This is the area where automated tools are weakest and manual testing matters most.
Every interactive element gets tested for keyboard access: tab order, visible focus indicators, touch target sizes, and no keyboard traps.
Heading hierarchy that jumps from h1 to h4. Form inputs without labels. Error messages that don't explain what went wrong. These issues hurt usability for everyone, but they make a site genuinely unusable for people who rely on assistive technology to parse page structure.
Audits cover heading order, form labeling, error handling, and navigation consistency. Well-structured pages are easier for search engines to index and essential for screen reader users to navigate.
Semantic HTML, correct ARIA usage, and screen reader compatibility are the foundation. Sites built on
<div> soup with decorative
ARIA attributes often test worse than sites with no ARIA at all. Proper semantics do most of the heavy
lifting.
Markup is validated against WCAG success criteria and tested with real assistive technology (NVDA, VoiceOver) to verify content is announced correctly and in logical order.
How It Works
Automated tools settle a minority of the WCAG success criteria, roughly 30% in the audits we run: contrast ratios, missing alt text, broken ARIA attributes, duplicate IDs, missing form labels. This surfaces the obvious issues and produces a starting inventory. What a clean scan still misses covers where that number comes from and what it leaves.
The other 70%. Keyboard navigation paths, screen reader behavior, logical reading order, focus management on dynamic elements. Most sites that "pass" automated scans fail here, because nobody tested with actual assistive technology.
Issues ranked by severity and user impact, not alphabetical WCAG criteria. Critical barriers first (keyboard traps, inaccessible login forms), then high-impact violations, then incremental improvements.
Each issue gets fixed and validated against the relevant WCAG success criterion. Automated checks confirm the technical fix. Manual testing confirms the user experience.
Accessibility built into the component library and color system. Contrast ratios checked across every combination. Focus styles, touch targets, and ARIA patterns defined at the component level so future development doesn't reintroduce violations. This site is built the same way, and its accessibility statement records the standard and how it is tested.
Content changes, new features, and dependency updates can all reintroduce violations. Recurring audits catch regressions before they accumulate.
The Audit on Its Own
Not every team needs us to do the fixes. Some have developers in house, and some need a report for a procurement team or a legal review before anything else happens. The audit is sold on its own, with a fixed scope agreed before it starts and a written report at the end that your developers or ours can work from.
Every page in the sample gets an automated scan and a manual pass with a keyboard and a screen reader (NVDA and VoiceOver). The standard is WCAG 2.1 AA, with anything that fails the newer WCAG 2.2 criteria reported beside it.
A site with hundreds of pages is mostly a handful of templates, repeated. We test every template and page type, plus each step of the processes people complete, like checkout, sign-up, and contact forms, because WCAG only counts a process as conforming when every step in it does. The report lists the exact pages tested, so you can see what “audited” covered.
A written report. Each finding names the WCAG success criterion it fails, where it happens, how severe it is for the people it blocks, and what the fix is. The findings are ordered as a fix roadmap, with anything that stops someone finishing a task at the top.
Most audits take one to two weeks. Tell us the site and roughly how many pages it has, and you get the sample, the timeline, and a price back before any work starts. Fixing is quoted separately, from the findings.
Get an accessibility auditCase Studies
An operations platform had been built without accessibility as a requirement. A compliance review flagged over 200 WCAG violations: unlabeled form inputs, missing landmark roles, color contrast failures across the entire UI, no keyboard navigation support. Prioritized by severity. Critical violations fixed first, then systematic work through AA compliance.
Full WCAG 2.1 AA compliance. Accessibility checks integrated into the development workflow so violations get caught before they ship.
A developer tool that generates a full contrast ratio matrix for any color palette, testing every foreground/background combination against AA and AAA thresholds. Used by other developers to audit design systems before implementation.
An entire palette audited in seconds instead of checking individual pairs manually.
Dealing with accessibility issues on an existing site?
Let's talkWhen to Fix vs. Rebuild
Missing alt text, contrast failures, form labels, heading structure: these are HTML attribute changes, CSS updates, and content adjustments. A site built with reasonable markup and a standard framework usually has a clear path to compliance.
The calculus changes when the front-end is built entirely without semantic structure. If the markup is
nested
<div>
elements with click handlers instead of buttons,
<span>
tags instead of headings, and no landmark roles anywhere, patching individual violations becomes more expensive
than rebuilding the affected components properly.
For most sites, fixing in place takes weeks. A full component rebuild takes months. The assessment covers the codebase first, then the recommendation goes with whichever approach reaches compliance faster and costs less to maintain long-term.
AA is the right compliance target. It covers the violations that affect the most users and aligns with legal requirements. AAA adds stricter thresholds (higher contrast ratios, more detailed text alternatives, stricter timing controls) that can conflict with design requirements. AAA gets applied where it fits naturally and doesn't get forced where it creates tradeoffs that hurt usability.
FAQ
AA is the level. The version is the part worth understanding: the regulations that name a standard, including ADA Title II, still point at WCAG 2.1, while WCAG 2.2 was approved as ISO/IEC 40500:2025 and adds nine success criteria on top of 2.1, among them minimum target sizes, focus appearance and accessible authentication. We audit against 2.1 AA because that is what the law asks for, and report 2.2 findings alongside it so a later deadline is not a second project. AAA gets applied where it does not compromise design or functionality.
When each standard and deadline landsMost sites, yes. The majority of violations are fixable with HTML changes, CSS updates, and content adjustments. The codebase gets assessed first, and the work is scoped based on what's there. If specific components need rebuilding, that gets scoped separately.
It depends on size and complexity. A 10-page marketing site is a different scope than a 200-screen SaaS platform. Expect one to two weeks for the audit, with fix timelines scoped separately based on findings.
It depends on what you sell. The European Accessibility Act covers e-commerce and a named list of other consumer services sold into the EU, regardless of where the seller is headquartered, and it exempts microenterprises providing services, meaning fewer than 10 staff and either turnover or a balance sheet total no higher than EUR 2 million. If you sell online to EU consumers, work on the basis that it applies until you have checked your category against the list.
Which rules apply to your site, and by whenAutomated tools settle roughly 30% of the WCAG success criteria in the audits we run: missing alt text, contrast failures, broken ARIA attributes. The rest needs human testing with real assistive technology, so a passing automated scan does not mean a site is accessible.
What automated scans miss, and how to test for itNo. Overlay widgets try to patch accessibility at runtime with JavaScript, but they don't fix the source code, miss the roughly 70% of WCAG issues that require human judgment, and have been rejected by accessibility professionals and federal enforcement (the FTC fined accessiBe $1 million in 2025 over deceptive compliance claims).
Why accessibility overlays don't countRarely. Most fixes are invisible: semantic HTML changes, ARIA attributes, focus management. Where visual changes are needed (contrast adjustments, larger touch targets), they typically improve the design for everyone.
It depends on scope. A marketing site audit is a different project than full compliance for a SaaS platform. You get a clear estimate before work starts.
Send us a URL. We run a baseline accessibility scan and tell you what needs attention.