Accessibility · Build
Accessibility fixes, kept in place by checks in the build
We fix names, focus and semantics in React and React Native, then add build checks. Our own review found 9 of 75 components with labels screen readers skipped.
EngagementHourly · remote
Hours9–18 CET · 4 h overlap
StackReact · React Native · TypeScript
Proof0 case studies
The service in 4 parts
01 · Who it’s for
A team with a component library or product where someone worked on accessibility once, and nobody knows whether that work still holds.
02 · What we’ve built
- We reviewed all 75 components our design system had at the time. Nine had a label no screen reader would announce, because the label sat on a node with no role. The build now rejects any label without a role.Blog post →
- We rebuilt our marketing page in the same system and checked it in a headless browser: 29 links with correct accessible names and a clean heading hierarchy.Blog post →
- On that page, the decorative dot at the end of a heading was being read as part of the heading’s accessible name. We found it only when we measured the name.Blog post →
All three examples come from our own design system rather than a client audit, and its aria-label and tabindex coverage is still incomplete.
03 · How we work
01 · RULES AND MANUAL CHECKSNo tool flagged the nine labels in our design system that screen readers never announced. A review of the code found the problem, and only then did we write the build rule that catches it. We review your code the same way: we read it first, then add a rule for everything a machine can verify.
02 · BOTH PLATFORMSOn the web, a label works only on an element with a role. In React Native, a label is read only when the element has the accessible prop. Each platform has its own check.
04 · Stack
ReactReact NativeTypeScriptARIAcustom verification rulesESLint
Proof
Where we’ve done this before
WritingThree kinds of design system bug that TypeScript and ESLint missWe reviewed all 75 components our design system had at the time. Nine had a label no screen reader would announce, because the label sat on a node with no role. The build now rejects any label without a role.Read the post →WritingTesting a design system on a real page: 7 components and 8 gapsWe rebuilt our marketing page in the same system and checked it in a headless browser: 29 links with correct accessible names and a clean heading hierarchy.Read the post →
FAQ
Questions about this service
No. We fix names, roles, focus and semantics in your code and add the checks that keep them fixed. We don’t issue compliance certificates.
Because the code is valid. An aria-label on a bare div is spelled correctly and has the right type, so TypeScript and ESLint accept it, yet the ARIA specification says it is ignored.
Yes. We look for a component in your library that already gets it right, then search for the places that break the same pattern. In our design system, Icon always paired its label with a role, so a search of the code found all nine broken components.
Next step
Describe the problem and we’ll come back with three options.
The first call takes 30 minutes, and you’re under no obligation.