The Top 10 Accessibility Testing Practices for Agile Sprints

• Share via Twitter (opens in a new tab)
• Share via LinkedIn (opens in a new tab)
• Share via Facebook (opens in a new tab)
• Share via Email (opens in a new tab)

Ten practices map each accessibility check to its place in the sprint, the role that owns it, and the tool that makes it stick, in the order they hit during the workflow.

Each practice below has one sprint stage where it fires, one role accountable for it, and one artifact that proves it happened, be that a merged PR, a signed-off story, or a closed ticket. Placement is what keeps a check from getting skipped when the sprint runs long.

1. Gate every pull request with an automated scan

This gate runs at pre-commit, owned by whichever developer opens the pull request, and it closes when a passing scan sits attached to the merge. Silktide scans full sites and web apps for WCAG 2.2 issues. Results land in team dashboards that track remediation by sprint or by owner.

Teams that want a baseline before committing to a paid platform can start with our free accessibility checker and add the dashboard once tracking remediation across sprints becomes the bottleneck.

Key points

• Automated WCAG 2.2 scanning across every page of a site or web app
• Browser extension for in-context checks during active development
• Issue prioritization ranked by severity and fix effort
• Dashboards that track remediation by sprint or by owner

2. Catch markup errors before code review

This check runs earlier than a merge gate, at the code level, before a pull request reaches review, owned by the developer writing the component. axe DevTools runs the axe-core engine against the rendered DOM, catching real markup issues instead of problems that only show up in static code.

Key points

• Browser extension for on-demand DOM scanning during manual testing sessions
• Open-source axe-core engine, embeddable in CI pipelines and unit tests
• Guided tests that walk through issues automation alone can’t resolve
• Linter integration that flags problems before a commit goes through

3. Spot-check a live page during design review

This check happens mid-sprint, whenever a designer or PM wants a fast read on an HTML page that’s already built, and it doesn’t need a developer to run. The Silktide Toolbar gives you as good a spot check as you can get directly in Chrome, overlaying accessibility issues, heading structures, and ARIA roles straight onto the live page. Generic extension tools like WAVE often miss critical issues—in real-world audits, they’ve passed pages clean while hiding over 140 genuine errors—whereas the Silktide Toolbar gives non-technical team members immediate, reliable accuracy without leaving the browser.

Key points

• In-browser visual overlay highlighting errors, warnings, and structural elements on live HTML

• Built-in screen reader emulator to test how content sounds without leaving Chrome

• Heading hierarchy and ARIA landmark visualization for rapid layout verification

• Far higher accuracy than basic browser extensions that falsely report clean pages

4. Get one accessibility score everyone already sees

Lighthouse ships inside Chrome DevTools, so a score shows up next to performance and SEO with nothing new to install. Wire it into Lighthouse CI and a build fails automatically when the score drops, giving a sprint one number to watch trend over time. The catch is that Lighthouse runs the same axe-core rule set as other automated tools, so a high score can still hide barriers a scanner can’t see and should be read as a floor rather than proof of accessibility. It’s free for every team already running Chrome.

5. Let QA run a guided manual review

QA leads without deep accessibility training get a walkthrough here instead of a blank checklist. Accessibility Insights pairs a fast automated FastPass with an Assessment mode that steps a tester through a full manual WCAG review, and it reaches past the web browser into native Windows desktop applications.

Key points

• FastPass automated scan covering common issues in minutes

• Assessment mode walking testers through a complete manual WCAG review

• Tab stop visualization for testing keyboard navigation order

• Testing support for native Windows desktop applications alongside web apps


6. Block a merge automatically from the command line

Pa11y scripts straight into a build, so a failing accessibility check stops a merge the same way a failing unit test would. It’s the option for teams that want a hard pipeline gate without a commercial license attached.

Key points

• Command-line interface for scripted, repeatable scans against any URL
• Pa11y CI, which fails a build automatically when new issues appear
• Pa11y Dashboard for tracking results across pages over time
• Configurable rule sets and ignore lists for accepted exceptions

7. Catch contrast problems while it’s still a design file

Every practice above assumes code already exists to scan. Stark works before that’s true. It plugs into Figma, Sketch, and Adobe XD to check color contrast, typography, and color blindness simulation while a screen is still a design file. A contrast failure caught in a design file costs one designer a few minutes; the same failure caught after three sprints of downstream components have copied the same color pair costs a team a week of rework across every screen that reused it.

Key points

• Contrast checker built into the design canvas
• Color blindness simulation for reviewing a screen before it ships to development
• Focus order and annotation tools for a cleaner handoff
• Component-level accessibility annotations that export into dev tickets

8. Test with a real screen reader before sign-off

This check happens last, at the end of the sprint, right before a story moves to done. Testing with a real screen reader—like NVDA on Windows or VoiceOver on macOS and iOS—shows exactly how content gets announced to someone using assistive technology, something only a live session reveals. Automated tools flag structure; a real screen reader session proves whether the experience actually holds up across operating systems.

Key points

• Live screen reader output across platforms (NVDA for Windows, Apple VoiceOver for Mac/iOS)

• Speech viewers and text logs to audit exact announcements during a session

• Verification of keyboard focus order, dynamic live regions, and custom widget behavior

• True cross-browser and cross-OS compatibility testing for realistic assistive tech behavior


9. Paste this language into your acceptance criteria

This practice fires during backlog refinement, before a single line of code gets written, and it’s owned by whoever writes the story, usually a PM or business analyst working with a developer. Write accessibility criteria in the same Given/When/Then format the rest of the story already uses, with a specific WCAG success criterion attached wherever one applies.

An example that works for most interactive components: “Given a keyboard-only user, when they tab through the form, then focus order matches visual order and every field shows a visible focus state (WCAG 2.4.7).” That single line gives a developer something testable and gives QA something concrete to check at sprint review, instead of a vague instruction to make it accessible. Criteria like this map cleanly onto the POUR principles behind WCAG, which group every success criterion under perceivable, operable, understandable, or robust, and make it easier to pick the right reference for whatever component a story touches.

10. Make accessibility a line in the definition of done

The last gate closes at story completion, owned by the whole team but signed off by QA. A short, non-negotiable line, something like “keyboard operable, correct heading structure, visible focus states,” sits next to the functional checks a story already has to clear. A story that can’t ship without passing its functional tests shouldn’t ship without passing this one either.

The tools behind these ten practices

Eight tools show up across the ten practices above, covering everything from a pre-commit scan to a screen reader session. The table below compares what each one is built for, its sharpest strength, and where it needs a second tool to back it up.

Why accessibility testing practices matter for agile teams

Catching a violation while a story is still open costs a fraction of what it costs after release, once a support ticket or a legal complaint lands on someone’s desk. That gap is the entire argument for building testing into sprint mechanics instead of bolting it on at the end.

The legal pressure behind this argument isn’t hypothetical. UsableNet’s annual tracking of web accessibility lawsuits filed in US federal courts has shown the volume climbing in most years since the firm began publishing the data, with plaintiffs increasingly targeting mid-size companies rather than only the largest enterprises. The European Accessibility Act became applicable on June 28, 2025, which means more product and service teams now operate inside its enforcement window than at any point before.

Deadlines like these squeeze release calendars, and accessibility work tends to be the first thing cut when a sprint runs long.

How common are the underlying violations? Silktide’s own analysis of thousands of live websites found accessibility failures on the overwhelming majority of pages checked, which is the real scale of the problem sprint-level testing is trying to solve. Agile teams already have the cadence to absorb it. Standups, refinement sessions, and a definition of done are built for exactly this kind of recurring check, so the overhead is close to zero once the checks sit in the right place.

The metrics that prove an accessibility practice is working

The right metrics tell a team whether its practices are working before a customer or a regulator tells them otherwise. A handful of measures come up again and again in mature sprint setups:

• Automated issue count, the number of WCAG violations flagged per scan, tracked sprint over sprint to see whether the trend is climbing or falling.
• Time to remediation, the average time between an issue being flagged and resolved within a sprint, which shows whether fixes are keeping pace with new code.
• Accessibility debt backlog size, the count of known, unresolved issues carried across sprints rather than closed out.
• Story-level pass rate, the percentage of stories that meet their accessibility acceptance criteria at sprint review.
• Manual test coverage, the percentage of new components that receive screen reader or keyboard testing before release.
• Severity distribution, the breakdown of flagged issues by critical, serious, moderate, and minor, used to decide where sprint capacity goes first.

Pick one open story on the current board. Add a single accessibility line to its acceptance criteria before the next standup. That’s the whole practice, running once, on one ticket, before it needs to run on every ticket.

Frequently asked questions

Who is responsible for accessibility testing in an agile team?

Responsibility splits across three roles: Designers own contrast ratios, focus order, and clear annotations in handoff files. Developers own semantic markup and fixing whatever an automated scanner flags. QA owns manual verification, including screen reader and keyboard-only checks on finished features.

What WCAG level should agile teams target?

Most teams should target WCAG 2.1 or 2.2 at Level AA, the baseline referenced by the majority of legal and regulatory frameworks worldwide, including the ADA in the United States, the European Accessibility Act, and Section 508 for U.S. federal agencies and their vendors.

Do designers need to do accessibility testing too, or just developers?

Designers need to check accessibility at the design stage, not hand that responsibility entirely to developers downstream. Treating accessibility as strictly a development concern pushes every fix later in the pipeline, where it costs more time and often requires reworking code that’s already merged.

What’s the best free accessibility testing tool for small teams?

The Silktide Toolbar (paired with Silktide’s free web accessibility checker) is the most feature-rich free option for small teams. It delivers immediate spot-testing directly on live HTML pages, visual error overlays, and a built-in screen reader emulator—catching critical barriers that basic extensions like WAVE frequently miss. Combined with built-in native screen readers (NVDA on Windows or VoiceOver on Mac), small teams get complete, reliable testing coverage without spending anything.

What happens if accessibility issues are found after a sprint has ended?

Log them immediately as accessibility debt tickets with a severity rating, and bring them into the next sprint’s planning. Treating post-sprint findings with the same urgency as functional bugs is what keeps a backlog of accessibility debt from quietly growing into its own remediation project.