Embedding manual accessibility testing in frontend development teams

Posted: Monday, 2 June 2025

Often when discussing accessibility testing, the focus is on technical accessibility audits, testing processes or the requirements of individual WCAG success criteria. While these things are important, they are require a certain level of technical knowledge, often from people whose day to day role is accessibility testing. There are many parts to an effective accessibility strategy, but one sometimes overlooked part is having your frontend developers, not just those working on design systems and component libraries, directly involved in accessibility testing as part of day to day features development and bug fixes.

Involving developers in accessibility has several benefits:

• increases the teams level of accessibility awareness and knowledge
• catches issues or prevents them outright before the testing phase
• reduces testing time
• ties in with a "shift-left" or "accessibility-first" approach

Here are steps I use when working with frontend teams.

First steps

Define basic manual tests

These are basic tests that can be documented in a checklist and require little accessibility knowledge. They should be quick and easy to perform.

Example tests:

• Keyboard: using the keyboard only, tab through the page, making sure all interactive elements can be navigated to and interacted with solely via the keyboard
• Focus indicator: check the keyboard focus indicator is visible against all background and does not disappear, or get completely hidden by other elements, at any time when tabbing through the page or interacting with elements via the keyboard
• Focus order: check the order that items gain keyboard focus is logical
• Focus traps: check keyboard focus doesn't get trapped within an area of page without a clear method of escaping the trap
• Content on hover/focus: check any content displayed on hover or keyboard focus can be hovered over, dismissed without moving the pointer and doesn't disappear after a few seconds

See my basic accessibility tests for developers guide for more suggestions.

Use an accessibility browser extension

Install an accessibility focused browser extension such as AXE or ARC Toolkit. These are quick and easy to run (typically one click) and generally provide enough detail to identify issues and the related fixes.

Use an accessibility linter

Linters are commonly used by developers to analyse and identify code issues. Linting code is very common for development teams wanting to ensure code meets team standards and quality. Many configurable accessibility focused linters also exist for different languages and frameworks that can catch potential issues at the code stage, for example AXE Accessibility Linter.

Most linters include a configuration file that can be committed to a project and used by all developers involved, providing a uniform set of checks. This requires little setup and fits in easily with what is likely already a standard team process.

Basic screen reader tests

Check:

• All interactive elements have descriptive labels (accessible names)
• No parts of the page is skipped by the screen reader
• Images have meaningful alt text (unless they are purely decorative)
• The visual order of the page is the same or similar to the reading order

These are basic checks. I cover more indepth tests in my how to test with a screen reader guide. Full screen reader testing should be handled by trained testers.

Developers using Windows can use the free, open source NVDA screen reader. VoiceOver comes preinstalled on macOS.

Tip: run a workshop

Run a "screen reader basics" workshop with the team before getting them involved with screen reader testing. Using a screen reader for the first time can be confusing as there is little to no UI.

Consider accessibility in code reviews

Code reviews often focus on standards, patterns and potential bugs. Add accessibility to the list of considerations. This works well if accessibility is included in your internal coding standards.

Example checks could include:

• enforcing semantic HTML e.g. using <button> rather than <div role="button">
• ensuring correct use of ARIA e.g. flagging the use of aria-label on a generic element such as <div>
• ensuring accessibility tests have been written for a new feature

This does require that developers have some level of accessibility knowledge. Role specific training can help with this.

Build checks into acceptance criteria

Most developer teams have either acceptance criteria or a definition of done. Incorporate these checks to set expectations and make it a part of everyday processes.

Longer-term improvements

Provide accessibility resources

Having a centralised accessibility knowledge base that provide guides, patterns and component examples for developers to consult can go a long way into both increasing team accessibility knowledge and confidence while also reducing the amount of accessibility issues that make it into the test phase.

Training

In my current role, I regularly run accessibility training for developers. Both "Introduction to web accessibility" training sessions as part of new starter inductions and periodic role specific training for designers, developers and testers. We run the role specific training sessions at least twice a year to help in maintaining and refresh knowledge. If you don't have an internal accessibility lead or specialist that can run these for you, consider bringing in external trainers. If you're in the UK I recommend AbilityNet and Shaw Trust Accessibility Services.

Monitor issues found at test

Actively monitor the accessibility issues found in the test phase and feed this back to developers so that, where appropriate, developer tests can be expanded to include any common issues.

CI/CD pipeline

Many development teams use some form of Continuous Integration (CI) and Continuous Delivery/Deployment (CD). These typically run tests (unit, regression, integration etc) as part of the process. Automated accessibility tests can also be run at this stage. Various tools exists such as Cypress-AXE.

In addition to other tests, have developers write accessibility tests that run at build time, as part of feature/story development and bug fixes.

Have a dedicated accessibility champion on the team

Accessibility champions promote accessibility and supports others on the team. They advocate for and advise on accessibility. In addition to any internal knowledge base or accessibility team, they can serve as the initial "go-to" for accessibility related advice and knowledge.

Creating and maintaining a network of accessibility champions across your organisation is a big subject which I'll cover in another post.