EngineeringScoreAccessibility Small
Keep accessibility standards up
Accessibility is easy to regress a component at a time: a new button built without a screen-reader pass, an image added without alt text, a color chosen without checking contrast; each one small, each one a real barrier for someone relying on assistive technology, and none of them break the build.
Why it matters
Accessibility is easy to regress when new components or content are added without the same scrutiny as the initial build, quietly locking out users who rely on assistive tech.
How to fix
- 1 Include an accessibility check in the review process for new pages and components.
- 2 Periodically re-test with a screen reader and automated tooling.
Common mistakes
- Testing accessibility once during an initial build and treating it as done, rather than as an ongoing property of every new page or component.
- Reviewing new components visually but skipping a keyboard-only or screen-reader pass before shipping them.
- Reusing a design token (a color, a component variant) that fails contrast in one place, which then propagates the same failure everywhere else it is used.
How to verify
- 1 Include an automated accessibility check (e.g. axe) in the review process for new pages and components, not just the initial build.
- 2 Periodically re-test key flows with a screen reader and keyboard-only navigation.
- 3 When a shared component or design token fails a check, treat the fix as covering every place that token is used, not just the one instance flagged.
Related checks
Ready to see where you stand?
Scan your site and get your Engineering Score with a prioritized roadmap in under a minute, no signup required.