Accessibility Testing in Scrum: Making It Part of Every Sprint
Approximately 15 to 20 percent of the population lives with a disability that affects how they interact with digital products. Accessibility law in Canada, the United States, and the European Union increasingly requires conformance to WCAG 2.1 AA or equivalent standards. Beyond compliance, accessible products are better products: accessibility constraints produce cleaner keyboard navigation, clearer labels, and better colour contrast that benefit all users. Despite this, accessibility testing in most Scrum teams remains a late-project activity performed by a specialist rather than a built-in discipline performed by the whole team.
Accessibility testing methods
Automated scanning tools. Tools such as axe, WAVE, and Lighthouse can scan a page or component automatically and report accessibility violations against WCAG criteria. They are fast, free or low-cost, and easy to integrate into a development workflow. They are also limited: automated tools catch approximately 30 to 40 percent of WCAG violations. They are very good at detecting missing alt text, insufficient colour contrast ratios, missing form labels, and incorrect ARIA roles. They cannot detect whether alt text is meaningful, whether the keyboard navigation sequence makes sense, or whether a screen reader user can actually accomplish a task. Automated scanning is the starting point, not the destination.
Manual keyboard navigation testing. Every function available to a mouse user must be available to a keyboard user. Keyboard testing requires a human to navigate the product using only Tab, Shift+Tab, arrow keys, Enter, and Escape — no mouse, no touchpad. The tester checks that focus is visible at all times, that the focus order is logical, that interactive elements are reachable, that modals and overlays trap focus correctly and release it on close, and that no keyboard traps exist (states the user cannot escape from). Keyboard testing takes 30 to 60 minutes per page or flow for an experienced tester and catches a category of issues that automated tools miss entirely.
Screen reader testing. Screen readers convert digital content to audio or Braille output for users who are blind or have severe visual impairments. The major screen readers are NVDA and JAWS on Windows, VoiceOver on macOS and iOS, and TalkBack on Android. Screen reader testing requires understanding how each screen reader interacts with HTML semantics, ARIA attributes, and browser rendering. The same page can behave very differently across NVDA and VoiceOver on different browsers. Testing with at least two screen reader and browser combinations — NVDA with Chrome, VoiceOver with Safari — is considered minimum coverage. Screen reader testing is the most specialised accessibility testing method and the one most likely to require dedicated expertise within or outside the Scrum team.
Colour contrast checking. WCAG 2.1 AA requires a contrast ratio of at least 4.5:1 between text and background for normal text and 3:1 for large text (18pt or 14pt bold and above). Colour contrast checking is straightforward: tools such as the Colour Contrast Analyser, the axe browser extension, or the built-in contrast checker in Figma provide immediate pass/fail feedback. Contrast checking should happen at the design stage, before components are built, not at the testing stage after the design system is established. Retrofitting colour contrast across a large application is a significant remediation effort that is entirely preventable with design-stage checks.
User testing with people who use assistive technology. Automated tools and expert walkthroughs find technical violations. They cannot reliably predict whether a real user can accomplish the tasks your product is designed to support. Testing with participants who use screen readers, switch access, or voice control provides qualitative evidence no technical audit can replicate. For products with accessibility compliance requirements, this should be a recurring component of the research programme, not a one-time event.
Setting up an accessibility regression suite in CI
The axe-core library integrates into Jest, Cypress, and Playwright. A component-level test catches missing labels, contrast failures, and ARIA errors on every build — before a change reaches review — with no specialised accessibility expertise required to write the test. Lighthouse CI configured to audit pull requests and flag scores below a target adds page-level coverage automatically. Neither replaces manual testing, but together they prevent automated catches from accumulating silently and establish a shared expectation that accessibility is a quality attribute the build system enforces.
Who is responsible for accessibility in a Scrum team
The answer is everyone — in the same way everyone is responsible for quality. The Product Owner owns accessibility in acceptance criteria and the Definition of Done. Designers own correct contrast ratios, sufficient target sizes, and logical focus order. Developers own semantic HTML, ARIA attributes, and keyboard interaction patterns. Testers run automated and manual checks before stories are accepted. The Scrum Master removes impediments when accessibility expertise is lacking. Distributing responsibility this way prevents the pattern where one specialist is perpetually behind because the rest of the team never built it in.
If your Scrum team is working to integrate accessibility into every Sprint rather than treating it as a launch-gate audit, XNM's program and project delivery advisory can help you build the Definition of Done criteria, testing practices, and team capability that make accessibility a built-in quality standard rather than an afterthought.