Services · By framework
A React Accessibility Audit, Because Components Have Consequences
For the React team that wants findings written in their own language, so which component, which pattern, and the fix that fits the codebase they already have.
What We Keep Finding
React does not make apps inaccessible. Component habits do. The div with an onClick that never became a button. The modal rendered in a portal that forgot to move focus with it. The custom select that looks like a select and announces as nothing. Then multiply each one by every place the component gets used.
The div-button is worth slowing down on, because it is the failure everybody assumes a scanner catches. It does not, and not because the scanner is weak. A div with a click handler and no role has no role in the accessibility tree at all, so the automated rules that check buttons never look at it. It is not passing them. It is invisible to them. And that one habit breaks three separate rules, because the thing has no role, cannot be reached by keyboard, and shows no focus ring on the rare occasion somebody gets to it anyway.
The multiplying is also the payoff, which is why we write findings the way we do. Fix the component once and every usage inherits the fix. So a finding names the component by its behavior and its visible identity rather than by the one page it happened to be caught on, because that is the unit a React team actually works in. And where the platform already solved the problem we say so instead of prescribing more code. A modal built on the browser's own dialog element moves focus in, holds the tab sequence, closes on Escape, makes the background inert, and puts focus back where it came from. None of that is code you write.
What We Check
- Test interactive components for a real role, a real name, and a keyboard path to reach them
- Check portal-rendered modals and menus for focus in, escape out, and focus return
- Verify what actually gets announced, so form errors, async results, and optimistic updates
- Audit client-side routing for focus movement and title changes on navigation
- Name the pattern to copy, and say where its reference code stops being production code
What You Get
Every service on this site runs the same three-pass engine: an automated scan, an expert review of all 55 WCAG 2.2 A and AA rules, and a hands-on session with a professional blind screen-reader user. You get one report with every finding screenshotted, ranked by user impact, and linked to its fix. Your team fixes, we verify: the re-audit is half price within 3 months.
The format is not a mystery either. Read the sample report before you spend anything.
The Honest Limit
One honest limit. We audit the rendered app, never your source, so findings point at components by behavior and visible identity rather than by file path. Mapping them back takes your team minutes, and the report is built to make those minutes easy. One thing worth knowing about the patterns we point you at. The published reference implementations carry their own warning that the example code is not written for production and deliberately does not work around gaps in browser and screen-reader support. So the pattern tells you the shape, and testing tells you it landed.
What It Costs
Rapid Audit: $499, up to 10 pages you pick, report in 5 business days. Standard Audit: $1,499, up to 25 pages in 10 business days. Flat rates, no discovery calls, and a real blind screen-reader user on every engagement. Pick your pages. We bring the humans.
Worth Reading Next
Related on this site
Guides, checklists, tools, and terms that go with this service.