How to Do Accessibility Testing: A Practical Step-by-Step Guide

Accessibility testing is not something software teams should treat as an optional extra. In many markets, digital accessibility is connected to legal requirements, but compliance is only part of the reason it matters.

Accessible software is often easier to use, easier to understand and available to a wider group of people.

A product may technically work while still creating unnecessary barriers for users who rely on keyboard navigation, screen readers, larger text, high-contrast settings or other assistive technologies.

Accessibility testing helps teams find those barriers before they become part of the normal product experience.

This guide looks at accessibility testing from a practical QA perspective. It is not intended to replace a complete accessibility strategy or legal review. Instead, it gives software teams a structured starting point for planning and carrying out manual accessibility testing.

1. Understand the accessibility standards that apply

Before testing starts, the team needs to understand what accessibility actually means for the product being tested.

Randomly checking whether text looks readable or whether the keyboard works on a few pages is not enough.

One of the main references for digital accessibility is the Web Content Accessibility Guidelines, usually referred to as WCAG.

The guidelines are built around four principles commonly known as POUR:

• Perceivable: Users need to be able to access the information presented by the product.
• Operable: The interface needs to work through the necessary input methods.
• Understandable: Content and behaviour should make sense to users.
• Robust: The software should continue working with different technologies and assistive tools.

WCAG also defines different levels of conformance. Level A addresses basic accessibility barriers. Level AA covers a broader range of requirements and is commonly used as a practical target. Level AAA contains stricter requirements and may be relevant for certain products or user groups.

The exact accessibility requirements may also depend on the markets where the product operates. Different countries and regions have their own legislation and regulatory frameworks.

For global products, it can be useful to create a simple compliance matrix showing which standards and legal requirements apply to each market.

The important point from a QA perspective is that accessibility testing needs a reference. The tester should understand which requirements are being verified and why.

2. Define the accessibility testing scope

Accessibility is a large area, and trying to test everything at once usually creates an unmanageable amount of work.

The better approach is to define the scope before testing begins.

Start by identifying which parts of the product need assessment. This may include the public website, customer portal, mobile application, internal tools or specific high-risk user flows.

The next step is deciding what level of accessibility the team is aiming for. If WCAG AA is the target, that should be clearly documented so testing can be planned around the relevant requirements.

Critical user journeys should normally receive the most attention first:

• Can a user create an account?
• Can they sign in?
• Can they complete a purchase or payment?
• Can they submit an important form?
• Can they recover from an error?

This is the same risk-based thinking used in other areas of QA. A decorative page and a payment flow do not necessarily deserve the same testing depth.

It is also useful to understand the current state of the product before setting improvement goals. An initial accessibility review can provide a baseline and show where the most serious problems are concentrated.

A clear scope helps prevent accessibility work from becoming a vague task called “make the product accessible.”

The team should know what is being tested, which standards apply and which areas matter most.

3. Make accessibility a shared product responsibility

Accessibility testing may sit within QA, but accessibility itself should not belong only to the QA engineer.

Design decisions can create accessibility problems before development begins. Developers can introduce or prevent technical barriers through implementation choices. Product teams decide which requirements receive priority. QA then brings structured testing, risk assessment and verification into the process.

Designers should consider contrast, focus states, component behaviour and readable layouts while creating interfaces. Developers should understand accessible patterns and use appropriate semantic structures. Product managers should include accessibility requirements when defining product behaviour.

QA has an important role in connecting these areas.

A tester may review requirements, question unclear behaviour, identify accessibility risks and verify the final implementation. When accessibility issues are reported clearly, QA can also help developers understand the user impact rather than only pointing to a technical rule.

For example, saying that an input is missing a programmatically associated label is technically correct. Explaining that a screen reader user may not understand what information needs to be entered makes the issue much clearer.

Accessibility becomes easier to manage when the whole team understands why these problems matter.

4. Include accessibility throughout the development process

Accessibility testing is much more effective when it happens continuously instead of being treated as a one-time audit before launch.

During design, the team can review wireframes and prototypes for obvious accessibility risks. Colour contrast, interaction patterns, focus behaviour and reusable components can all be considered before code exists.

During development, accessibility checks can be included in code reviews and automated tooling. Developers can also maintain documentation for common accessible patterns used across the product.

During QA, testers can include accessibility checks in feature testing, regression coverage and release checks. Important fixes should be retested, and more complex interfaces may need deeper manual investigation.

After release, accessibility should still be monitored. User feedback, support requests and periodic audits can show where new problems have appeared.

The earlier an accessibility problem is identified, the easier it is usually to address.

Fixing a design pattern before it is reused across twenty pages is much simpler than correcting every page after release.

Accessibility should be part of the normal product lifecycle rather than a separate cleanup project.

5. Prepare the testing environment

Accessibility testing requires more than opening the application in a browser and clicking through the main flow.

The testing environment should reflect different ways users interact with software. This may include:

• Screen readers
• Keyboard-only navigation
• Increased text size
• High-contrast settings
• Forced colours
• Reduced motion preferences

Mobile accessibility testing may require different device settings and assistive features. Screen orientation, zoom behaviour, touch targets and gesture alternatives can all affect whether a product is usable.

The exact environment depends on the product and target users. A public web application may need browser and screen reader combinations, while a mobile application may require testing with the accessibility tools built into Android and iOS.

A simple testing matrix can help manage these combinations. The matrix might include user needs, browser or device, assistive technology and feature priority.

Not every possible combination needs the same level of coverage. Critical user flows can be tested with several representative configurations, while lower-risk areas may receive more focused checks.

The goal is useful coverage without turning accessibility testing into an endless browser and device matrix.

6. Prepare useful test data and reusable testing resources

Like other forms of QA, accessibility testing becomes slower when the tester repeatedly needs to create the same product state.

If an important workflow requires a specific user role, completed transaction or failed payment state, prepared test data can save significant time.

Test accounts should make it possible to reach the area being tested without repeatedly rebuilding the same setup.

Teams can also build reusable accessibility testing resources over time.

A component library can document accessibility expectations for buttons, dialogs, forms and other shared interface elements. An issue library can record common accessibility problems and examples of how they appear in the product.

Testing procedures can also be written for complex flows that require specific screen reader or keyboard checks.

These materials help keep testing consistent and make accessibility knowledge easier to share across the team.

The purpose is not to create documentation for everything. The purpose is to avoid repeating the same investigation every time a familiar component or flow needs testing.

7. Write accessibility-focused test documentation

Accessibility testing documentation should describe what is actually being checked.

A test case such as “Test login form” is too broad. It says almost nothing about the accessibility requirement.

A better check might be:

• Verify the login form can be completed using keyboard navigation only.
• Verify validation errors are announced correctly by the screen reader.

This makes the purpose of the test clear.

Teams can use either detailed test cases or practical accessibility checklists depending on the product and testing process. There is no requirement to create both simply for the sake of documentation.

The important thing is specificity.

A visual accessibility check should not simply say “Verify content is readable.” It could instead verify that text maintains the required contrast ratio or that content remains usable when zoomed to 200%.

Bug reports also need to explain both the technical problem and the user impact.

• Issue: The payment amount input does not have an associated form label.
• Impact: Screen reader users may not understand what information the field expects.

That context helps the development team understand why the problem matters and often makes prioritisation easier.

8. Start with keyboard navigation

Keyboard testing is one of the most practical places to begin.

A user should be able to reach interactive elements using the keyboard. Focus should move through the interface in a logical order, and the current focus position should be clearly visible.

Buttons, links, form controls and other actions should work without requiring a mouse.

The tester should also check for keyboard traps. A user should not enter a dialog, menu or component and become unable to move focus away from it.

Skip navigation links may also be important on pages with repeated navigation or long layouts.

Keyboard testing often reveals problems quickly because it changes the way the tester interacts with the interface.

A product that feels simple with a mouse may become extremely difficult when every action depends on logical focus movement.

9. Test with a screen reader

Screen reader testing requires the tester to understand the page through its structure and announced information rather than only through the visual interface.

Page titles should describe the page clearly. Heading levels should follow a logical hierarchy. Links should make sense when announced without the surrounding paragraph.

Images should have useful alternative text when they communicate information. Decorative images should not create unnecessary noise.

Form controls need clear labels, and validation messages should be connected to the correct field. Dynamic changes may need to be announced so the user understands what happened after an action.

Tables should also have the correct structure so relationships between headers and data remain understandable.

One important part of screen reader testing is listening to the entire experience rather than only checking individual technical requirements.

A page may technically expose every element to the screen reader while still presenting the information in a confusing order.

That is where manual testing becomes particularly important.

10. Review visual accessibility

Accessibility testing also needs to consider how information is presented visually.

Text contrast should meet the relevant accessibility requirement. Information should not depend only on colour.

If an error is shown only by turning a border red, some users may not understand what changed.

The interface should remain usable when text is enlarged or the browser is zoomed. Content should not disappear, overlap or become impossible to interact with.

Focus indicators also need to remain visible against the surrounding interface.

Motion and animation should be reviewed carefully. Users may need a way to pause or disable certain types of motion, and flashing content can create serious accessibility concerns.

Responsive layouts should also be tested at different screen sizes and orientations. Accessibility issues are not limited to desktop interfaces.

The important question is whether the user can still understand and operate the product when the visual environment changes.

11. Check multimedia content

Products that include video or audio have additional accessibility requirements.

Videos may need synchronised captions. Audio content may require transcripts. Important visual information shown in video may need an audio description or another way to access the same information.

Media controls should also work with keyboard navigation and assistive technologies.

Autoplaying content can create usability problems, especially when the user cannot easily pause or stop it.

The media itself may be accessible while the player controls are not.

Both parts need to be tested.

12. Include mobile-specific accessibility checks

Mobile accessibility has its own set of problems.

The application should remain usable in portrait and landscape orientations where both are supported. Content should reflow correctly, and zoom should not be unnecessarily disabled.

Complex gestures may need simpler alternatives. A user who cannot perform a multi-finger gesture should still be able to access the same functionality through another interaction.

Touch targets should be large enough and separated well enough to reduce accidental actions.

Hover-based information also needs special attention because touch devices do not behave like desktop interfaces.

Buttons and controls should be labelled consistently, especially when assistive technologies announce the element differently from the visible interface.

Mobile accessibility testing should use actual accessibility features where possible.

Simply shrinking the desktop browser does not recreate the real mobile experience.

13. Test content and instructions

Accessibility is not only technical. Content can also create barriers.

Instructions should not depend only on visual descriptions such as “click the green button on the right.” A user may not see the colour or may be using a layout where the button is no longer on the right.

Unusual terms and abbreviations should be explained where necessary. Long pages should use useful headings so users can move through the content more easily.

Icons that communicate important information should have a text equivalent or another accessible way to understand their meaning.

Clear language can also make the product easier to use for people with different cognitive needs, language abilities or levels of technical knowledge.

An interface can pass technical accessibility checks while still being unnecessarily difficult to understand.

14. Carry out manual accessibility testing

Once the scope, environment and documentation are ready, the actual testing process becomes more structured.

The tester works through the defined checks and records the result. Passed checks can be marked accordingly, while failures should become proper defect reports.

A failed accessibility check needs enough information for somebody else to reproduce and understand the problem.

Include:

• Affected page or component
• Testing environment
• Assistive technology where relevant
• Steps to reproduce
• Expected behaviour
• Actual behaviour

Screenshots and screen recordings can be useful, but accessibility bugs often require additional context.

A screenshot cannot show what a screen reader announces or how focus moves through the page.

The bug report should explain the behaviour clearly.

Human judgement remains an important part of this process. A form may technically expose all fields to a screen reader, but the navigation order may make the form confusing to complete.

An automated scanner may not fully understand that experience.

Manual testing helps find those problems.

Manual vs automated accessibility testing

Accessibility testing can be supported by automation, but automated tools do not replace manual testing.

Automated checks are useful for repeatable technical rules. They can find certain contrast issues, missing attributes and structural problems quickly. They can also be included in CI/CD pipelines to catch familiar problems earlier.

The limitation is context.

An automated tool may confirm that a button has an accessible name. It cannot always determine whether that name actually makes sense to the user in the surrounding workflow.

It may confirm that page headings exist while missing the fact that the page becomes confusing when navigated through them.

The same principle applies here as in other areas of QA. Automation is valuable when the testing problem matches what the tool can reliably verify.

Manual testing remains necessary for user experience, logical navigation and situations that require judgement.

The better question is not whether accessibility testing should be manual or automated.

In most cases, the stronger approach is understanding where each method provides useful coverage.

15. Monitor accessibility over time

Accessibility testing should not end after the first audit.

Products change. New components are added. Existing flows are redesigned. A previously accessible interface can become difficult to use after a seemingly small update.

Teams should monitor accessibility issues and look for patterns.

Useful information may include:

• Number of open accessibility issues
• Issue severity
• Affected product areas
• How quickly important problems are fixed

User feedback is equally important. Support requests and customer reports can reveal barriers that internal testing did not find.

Accessibility-related feedback should be easy to identify and track. Teams may use support ticket labels or another simple classification system so repeated issues become visible.

Regular retrospectives can also help the team understand why accessibility defects are appearing.

If the same type of keyboard problem keeps returning, the root cause may be a shared component. If accessibility issues increase after large releases, the release process may need stronger checks.

The goal is not only to find individual defects. It is to understand why they keep appearing.

Accessibility testing checklist example

Every accessibility checklist should be adapted to the product and the standards that apply.

Still, the following areas provide a useful starting point.

Keyboard navigation

• Check that interactive elements can be reached with the Tab key.
• Verify focus moves in a logical sequence.
• Check that focus indicators are clearly visible.
• Verify important functionality works without a mouse.
• Make sure users cannot become trapped inside a component.

Screen reader compatibility

• Verify page titles and heading structure.
• Check useful alternative text.
• Review descriptive link text.
• Verify form labels and error announcements.
• Check that dynamic content changes are understandable.
• Verify tables expose useful structure.

Visual design

• Review contrast.
• Test zoom behaviour and text resizing.
• Check information communicated through colour.
• Verify focus visibility.
• Test different screen sizes.
• Review motion and animation behaviour.

Multimedia

• Check captions, transcripts and descriptions where required.
• Verify media players are keyboard accessible.
• Check that audio and video can be paused or controlled.

Mobile accessibility

• Test orientation changes.
• Verify zoom and content reflow.
• Review touch target size.
• Check gesture alternatives.
• Verify consistent control labels.
• Check important hover interactions have a touch-friendly alternative.

Content readability

• Review instructions and abbreviations.
• Check heading and landmark structure.
• Verify important icons can be understood accessibly.
• Make sure instructions do not rely only on colour, shape or screen position.

This is not a complete accessibility test suite.

The actual coverage should reflect the product, target users and requirements that apply.

Final thoughts

Accessibility testing is not a single test session that makes a product permanently accessible. It is an ongoing part of software quality.

The strongest approach is to understand the standards that apply, focus on important user journeys and bring accessibility into the normal development process.

Prepare realistic testing environments, write accessibility-specific checks and use both manual testing and automation where they provide useful coverage.

Most importantly, accessibility testing should look at whether people can actually use the product.

A technical requirement matters because there is a user behind it.

Keyboard navigation helps users who cannot rely on a mouse, but it can also make software faster for experienced keyboard users. Clear language supports users with different cognitive needs, but it also makes products easier for everyone to understand. Captions support people with hearing impairments, but they are also useful when somebody is watching a video in a noisy place.

Good accessibility work often improves the product beyond the original accessibility requirement.

The goal is not only to pass a checklist.

It is to remove unnecessary barriers from the software people are trying to use.