Accessible Delivery: Tools, Practices, and Outcomes

Why This Matters

Building accessible digital services is a core delivery requirement and practice. It supports:

• Legal and policy compliance with applicable accessibility obligations.
• Business access so everyone can use public services effectively.
• Quality because accessible experiences are typically more robust, predictable, and usable for everyone.
• Equity by helping ensure all users have meaningful access.

This guidance helps teams understand what accessible delivery looks like, where tools fit into that process, and how to choose tools that support the way the team works.

What "Done" Looks Like

Before choosing tools, align on the outcomes the team is expected to produce. Work should be considered complete when:

• The experience works without a mouse and supports keyboard-only interaction.
• Native, semantic HTML is used wherever possible, with ARIA used only when needed and implemented correctly.
• Code is reviewed and tested through appropriate unit, integration, and regression tests.
• Tests cover critical user journeys, keyboard-operable flows, form validation and error handling, focus behavior, semantic structure, and known regression risks.
• Functionality is manually validated by multiple people, including people who use assistive technology where feasible.
• Error states and edge cases behave predictably and are communicated accessibly.
• Accessibility issues are not introduced or are addressed promptly and appropriately when found. These are the outcomes tools should help teams achieve; tools should not be treated as the outcome themselves.

Embedding Accessibility as a Practice

Accessible delivery requires more than a toolset.

It depends on:

• Shared accountability across roles.
• Early and ongoing collaboration among product, design, engineering, content, QA, and accessibility specialists.
• Consultation with accessibility experts when needed.
• Continuous learning and improvement.
• Planning that accounts for the time and cost needed to meet accessibility standards. All team members should have a baseline understanding of accessibility for their role. Teams should define this baseline consistently, such as through curated training by role for product managers, designers, developers, QA, and content contributors, and link to the approved training resources when available.

How Tools Support Accessible Delivery

Tools are most effective when they are used at the right time and for the right purpose. Rather than prescribing one fixed toolset, teams should think about accessibility support across the delivery lifecycle: exploration, implementation, testing, validation, release, and production monitoring.

Exploration and Early Decisions

Exploration happens at the start of an initiative, when teams evaluate ideas, technologies, platforms, or vendors. Early decisions can introduce accessibility issues that become costly and time-consuming to fix later.

What to focus on:

• Evaluating third-party tools, platforms, and vendor claims.
• Identifying potential accessibility risks before implementation.
• Consulting accessibility expertise when decisions could affect core user flows.

Example tools and practices:

• Automated and manual review using browser tools.
• Early prototyping with assistive technology.
• Keyboard testing, code inspection, and tools such as ANDI to help inspect accessible names, roles, and structure. Development and Implementation Implementation is when teams build features and write code. This is also when many accessibility issues are introduced, making it the best time to catch them quickly.

What to focus on:

• Writing semantic, standards-based code.
• Testing during development rather than waiting until the end.
• Preventing regressions through repeatable checks.
• Using accessible design patterns and components.

Example tools and practices:

• Browser-based accessibility testing tools such as Axe DevTools and ANDI.
• Linters and static analysis tools.
• Component libraries with accessible defaults and documented usage guidance.
• Pull request checks that include accessibility considerations.

Continuous Integration and Automated Testing

Continuous integration and automated testing can save time over the long run. When these checks are built into the development and deployment pipeline, they run alongside feature work and continue supporting the product after launch. Automation helps ensure accessibility is enforced consistently rather than relying only on individual effort.

What to focus on:

• Running automated checks on every meaningful change.
• Preventing new issues from being introduced.
• Supporting repeatable, reliable testing across releases.
• Tracking trends in accessibility defects over time.

Example tools and practices:

• Automated accessibility testing in CI, such as Axe CLI or Pa11y.
• Integration with CI platforms such as GitHub Actions or Jenkins.
• Regression testing tools for critical user flows.
• Reports that teams can review and act on during delivery.

Validation and Pre-Release Review

Validation happens before releasing work to users. It confirms that the finished product works as intended and is separate from ongoing testing of individual work items or components. The goal is to validate the full experience end to end. View examples of pre-release validation

What to focus on:

• Manual testing of real user flows.
• Keyboard-only interaction and visible focus behavior.
• Assistive technology usage for representative flows.
• Independent validation by another team member.
• Use of the approved web and application accessibility testing checklist as the single source of truth when available.

Example tools and practices:

• Keyboard navigation testing.
• Screen reader review for key workflows.
• Structured test reports or checklists.
• Documented defects, severity, owners, and resolution plans.

Post-Release Monitoring

Accessibility work continues after launch. Real-world usage can reveal issues that were not caught earlier, and tools or technologies may change over time. Automation infrastructure can help, but teams should also maintain manual feedback and review processes.

What to focus on:

• Monitoring user-reported issues.
• Addressing critical and serious accessibility issues quickly.
• Maintaining accessibility as products, content, and dependencies change.
• Reviewing recurring issues to improve upstream design and development practices.

Example tools and practices:

• Error monitoring tools.
• Feedback channels and support intake processes.
• Analytics to identify friction points.
• Recurring accessibility reviews for high-impact services.

Choosing the Right Tools

There is no single correct toolset. When selecting tools, consider:

• How well the tools fit the team’s workflow and delivery process.
• Whether the tools integrate with the team’s technology stack.
• The balance of automation and manual testing needed.
• Team familiarity, training needs, and support requirements.
• Coverage gaps, since no single tool catches every accessibility issue.
• How results will be triaged, tracked, and remediated. Tools should support the team’s process, not define it.

Suggested Tools and Resources

Teams should maintain a short, approved list of tools and resources that reflects current standards and procurement guidance. Suggested categories include:

• Browser inspection and automated accessibility tools, such as Axe DevTools and ANDI.

• CI-based accessibility checks, such as Axe CLI or Pa11y, where appropriate for the technology stack.

• Accessible component libraries and design system guidance.

• Role-based baseline accessibility training and refresher training.

• Web and application accessibility testing checklists.

• Project manager accessibility guidance and planning resources once published. Keep this list current, identify owners for each resource, and remove tools or links that are no longer supported.