What Is Accessibility Testing?

Accessibility testing checks whether people with disabilities can use a website, application, or digital product without unnecessary barriers.

Those barriers may prevent someone from reading content, navigating with a keyboard, understanding a form, hearing important information, or completing a task.

For example, a checkout button may look completely normal but have no accessible name. A screen reader could announce only "button", leaving the user unsure what it does.

Accessibility testing helps teams find problems like this before they affect real users.

Why Is Accessibility Testing Important?

Accessibility is not only about passing a technical standard. The real question is whether people can use the product successfully.

People may rely on:

• Screen readers

• Keyboard-only navigation

• Voice control

• Screen magnification

• Captions and transcripts

• Switch devices

• Larger text

Accessibility improvements often help other users too. Better contrast helps someone using a phone outdoors, captions work in noisy environments, and clear form labels make interfaces easier for everyone.

Accessibility can also be tied to requirements such as WCAG, ADA, Section 508, EN 301 549, and the European Accessibility Act.

Finding issues early is usually easier than fixing the same inaccessible component after it has been reused across an entire product.

Who Does Accessibility Testing Consider?

Accessibility covers much more than screen reader users. Different disabilities can affect how people see content, hear information, move through an interface, understand instructions, or complete a task.

Visual Disabilities

Blindness, low vision, and colour vision deficiencies can affect how users read and navigate digital content. Important areas include screen reader support, useful alt text, sufficient colour contrast, zoom and text resizing, visible focus states, and a clear semantic page structure.

Hearing Disabilities

Users who are deaf or hard of hearing may miss information delivered only through audio. Captions, transcripts, visual alerts, and accessible media controls help make important information available without relying on sound alone.

Motor Disabilities

Some users cannot rely on a mouse, precise touch movements, or complex gestures. Keyboard access, clear focus indicators, suitable target sizes, enough spacing between controls, and alternatives to dragging or multi-step gestures can make interactions easier to complete.

Cognitive and Learning Disabilities

Attention, memory, reading, comprehension, and information processing can affect how someone uses a product. Clear instructions, predictable navigation, consistent layouts, understandable errors, and simpler authentication can reduce confusion.

Temporary or situational limits, such as an injured arm, bright sunlight, a noisy environment, or one-handed use, can create similar barriers.

What Does Accessibility Testing Check?

A useful accessibility review looks at both the technical implementation and how someone actually moves through the product. The goal is to find barriers that can interrupt navigation, understanding, interaction, or task completion.

Keyboard Navigation and Focus

Some users navigate entirely with a keyboard or another input device instead of a mouse. Every important control should remain reachable, understandable, and usable throughout the journey.

Look for:

• Logical Tab order

• Clearly visible focus

• Keyboard-accessible buttons, menus, and links

• Working skip links

• No keyboard traps

• Correct focus behaviour inside modals and dialogs

Focus should also move predictably when new content appears or an interaction changes the page.

Screen Reader Compatibility

Screen readers use the page structure, accessible names, roles, and other programmatic information to describe an interface.

Important areas include:

• Accessible names

• Headings and landmarks

• Form labels

• Button and link names

• Logical reading order

• Dynamic announcements

• Correct ARIA implementation

A page can look perfectly usable visually while becoming confusing when content is announced in the wrong order or controls have unclear names.

Images and Page Structure

Informative images need alternative text that communicates their purpose. Decorative images should usually be ignored by assistive technologies so they do not add unnecessary noise.

Page structure matters just as much. Headings, landmarks, lists, tables, links, and semantic HTML should reflect how the content is actually organised.

Colour and Visual Behaviour

Visual information should remain understandable for users with low vision or colour vision deficiencies.

Testing should include:

• Text contrast

• Interface contrast

• Information communicated only through colour

• Zoom and text resizing

• Content reflow

• Visible focus indicators

For example, marking an invalid field only with a red border can leave some users without enough information to understand the error.

Forms and Errors

Forms can quickly become inaccessible when fields, instructions, or errors are not clearly connected.

Users should be able to understand:

• What information each field requires

• Which fields are mandatory

• That an error occurred

• Which field caused the error

• Why the entered value is incorrect

• How to fix the problem

Relevant errors and status messages should also be available to screen readers rather than appearing only visually.

Multimedia and Motion

Audio and video content may need captions, transcripts, audio descriptions, or accessible playback controls depending on what information they contain.

Motion also needs attention. Rapid flashing can create seizure risks, while uncontrolled animations or moving content can make a page difficult to use for some people. Where required, users should be able to pause, stop, or hide moving content.

Accessibility Testing Standards

WCAG, or Web Content Accessibility Guidelines, is the main technical reference used for web accessibility. It gives teams a common framework for evaluating whether digital content can be used by people with different accessibility needs.

WCAG Principles

WCAG is organised around four core principles:

• Perceivable: Information must be available in forms users can perceive.

• Operable: Users must be able to navigate and interact with the interface.

• Understandable: Content, instructions, and interactions should be clear and predictable.

• Robust: Content should work reliably across browsers, devices, and assistive technologies.

WCAG Conformance Levels

WCAG has three conformance levels:

• Level A: Covers basic accessibility requirements.

• Level AA: Adds broader requirements and is a common target for many organisations.

• Level AAA: Includes the most demanding criteria and may not be practical for every type of content.

The right target depends on legal, contractual, product, and organisational requirements.

WCAG 2.2

WCAG 2.2 introduces additional requirements around areas such as:

• Focus visibility

• Target sizes

• Dragging interactions

• Repeated data entry

• Consistent help

• Accessible authentication

These additions address common barriers that appear in modern interfaces and user flows.

Other Accessibility Laws and Standards

WCAG is not the only requirement teams may need to consider. Depending on the product and region, other relevant standards or regulations can include:

• ADA

• Section 508

• EN 301 549

• European Accessibility Act

The exact requirements depend on where the product is used, who it serves, and which regulations apply.

Types of Accessibility Testing

No single method can uncover every accessibility barrier. A stronger approach combines automated tools, manual review, and assistive technology testing. Accessibility fits within the broader landscape of types of software testing, alongside functional, performance, and security testing, but it needs a dedicated approach because many accessibility barriers are not covered by standard functional testing.

Automated Testing

Automated tools can scan pages and components for accessibility issues that can be detected programmatically.

Common tools include:

• axe

• WAVE

• Lighthouse

• Accessibility Insights

They can help find issues such as:

• Missing accessible names

• Some colour contrast failures

• Invalid ARIA attributes

• Missing form labels

• Certain structural problems

Automation is especially useful for quick checks, repeated scans, and regression testing. However, it cannot judge whether the overall experience is actually understandable or usable.

Manual Testing

Human review is needed for areas that automated tools cannot reliably interpret.

This includes:

• Logical focus order

• Keyboard usability

• Meaningful alternative text

• Clear error messages

• Complex forms

• Custom components

• Complete user journeys

For example, an automated tool may detect that an image has alt text, but it cannot always tell whether that text accurately explains the image's purpose.

Assistive Technology Testing

Real workflows should also be tested using the technologies people rely on to access digital products.

Common examples include:

• NVDA

• JAWS

• VoiceOver

• TalkBack

• Screen magnifiers

• Voice control

• Switch devices

The important part is testing complete tasks, not individual elements. A form field may work correctly on its own but still become difficult to use when combined with validation, dynamic content, or other controls.

Where possible, involving people who regularly use assistive technologies can also reveal usability barriers that automated and manual technical checks may miss.

How to Perform Accessibility Testing

A good accessibility testing process combines automated checks with real user interactions to find both technical issues and practical barriers.

Step 1: Define the Accessibility Requirements

Set the target WCAG version, conformance level, supported platforms, assistive technologies, and any legal or contractual requirements. This gives the team a clear testing baseline.

Step 2: Identify Critical User Journeys

Focus on complete tasks such as registration, login, search, checkout, form submission, and password recovery. Testing full journeys helps reveal barriers that isolated page checks may miss.

Step 3: Run Automated Accessibility Scans

Use tools such as axe, WAVE, Lighthouse, or Accessibility Insights to find issues like missing labels, contrast failures, ARIA problems, and structural errors. Treat automation as a starting point, not a complete accessibility review.

Step 4: Test Using Only a Keyboard

Complete important workflows without a mouse. Check focus order, visible focus, unreachable controls, keyboard traps, menus, buttons, and modal behaviour.

Step 5: Test With a Screen Reader

Use NVDA, JAWS, VoiceOver, or TalkBack to review headings, links, buttons, forms, instructions, errors, and dynamic updates. The entire journey should remain understandable.

Step 6: Check Visual Accessibility

Review contrast, zoom, text resizing, reflow, focus visibility, and information that relies only on colour. Content should remain usable when enlarged or visually adjusted.

Step 7: Test Interactive Components

Pay extra attention to forms, modals, dropdowns, date pickers, tabs, menus, autocomplete fields, and other custom controls. Check keyboard access, focus movement, labels, states, and screen reader behaviour.

Step 8: Test Errors and Dynamic Content

Review validation errors, loading messages, notifications, dialogs, live updates, and authentication errors. Important changes should be communicated clearly to all users.

Step 9: Report Accessibility Issues

Document the affected component, WCAG criterion, user impact, browser, assistive technology, reproduction steps, actual behaviour, and expected behaviour so developers can reproduce the problem.

Step 10: Retest the Fix

Repeat the original interaction after the fix. Confirm that the barrier is removed and that keyboard, focus, screen reader, and related functionality still work correctly.

Accessibility Testing Example: Registration Flow

A registration form is a simple example of why page-level scans alone are not enough. The complete journey needs to work across different ways of interacting with the interface.

A form may pass several individual accessibility checks and still fail if someone cannot complete registration from start to finish.

Common Accessibility Issues

Certain accessibility problems appear repeatedly across websites and applications.

Common examples include:

• Missing or unclear alt text

• Low colour contrast

• Form fields without accessible labels

• Incorrect heading structure

• Keyboard traps

• Missing or difficult-to-see focus indicators

• Buttons without accessible names

• Missing captions or transcripts

• Inaccessible modals and menus

• Unclear error messages

• Content breaking when zoomed

• Dynamic updates not announced to screen readers

The severity of an issue depends on its effect on the user. A missing label on an optional field may cause confusion, while an inaccessible checkout button can prevent someone from completing the entire task.

Accessibility Testing for Web and Mobile Apps

Web accessibility often centres on semantic HTML, keyboard behaviour, screen readers, responsive layouts, zoom, ARIA, and browser behaviour.

Native mobile testing adds areas such as:

• VoiceOver and TalkBack

• Touch exploration

• Dynamic text

• Orientation

• Target sizes

• Gesture alternatives

Apple and Android also publish platform-specific accessibility guidance that should be considered alongside relevant WCAG requirements.

Different tools support different parts of accessibility testing, so teams usually need more than one.

Automated Scanners

Tools such as axe, WAVE, Lighthouse, and Accessibility Insights can quickly identify issues that are detectable through code or page structure.

They are useful for finding problems such as:

• Missing accessible names

• Some contrast failures

• Invalid ARIA usage

• Missing form labels

• Certain structural issues

Automated scans are useful for fast feedback and regression testing, but they cannot judge the full user experience.

Screen Readers

Screen readers show how content and controls are presented to users who rely on assistive technology.

Common options include:

• NVDA

• JAWS

• VoiceOver

• TalkBack

They are especially useful for checking headings, links, buttons, forms, error messages, and dynamic content.

Visual Accessibility Tools

Contrast analysers and colour-vision simulators help review how the interface appears to users with low vision or colour vision deficiencies.

They can help identify:

• Low text contrast

• Low interface contrast

• Information that depends only on colour

• Difficult-to-see focus indicators

No single tool can establish that a product is accessible. Automated scans work best when combined with keyboard testing, screen reader testing, visual checks, and complete user journeys.

How to Report an Accessibility Bug

An accessibility defect should make the barrier easy to reproduce and explain how it affects the user.

Include:

• Affected page or component

• Relevant WCAG criterion

• User impact

• Browser and operating system

• Assistive technology used

• Steps to reproduce

• Actual behaviour

• Expected behaviour

• Screenshot or recording when useful

Accessibility testing can miss important barriers when the process is too narrow or depends too heavily on tools.

Relying Only on Automation

Automated scanners are useful for finding technical issues, but they cannot judge whether a real user can understand and complete a task.

Problems with focus order, confusing labels, complex interactions, or poor error recovery often need manual review.

Testing Only the Homepage

A clean homepage does not mean the rest of the product is accessible.

Important journeys such as registration, checkout, search, form submission, and password recovery can contain completely different issues.

Focusing Only on Screen Readers

Screen reader testing is important, but accessibility covers many other needs too.

Motor, hearing, cognitive, low-vision, colour-vision, and temporary limitations should also be considered during testing.

Testing Only Before Release

Late testing can uncover structural issues after the same inaccessible component has already been reused across multiple pages.

Including accessibility earlier in design, development, and QA usually makes problems easier to fix.

Ignoring Dynamic States

Many accessibility problems appear only after interaction.

Test areas such as:

• Error messages

• Modals

• Menus

• Loading states

• Notifications

• Expanded content

• Live updates

These states often need correct focus management and clear screen reader announcements.

Accessibility Testing Checklist

Before completing an accessibility review, check that:

• Interactive controls work with a keyboard

• Focus is visible and logical

• No keyboard traps exist

• Images have appropriate alt text

• Headings and landmarks are meaningful

• Forms have accessible labels

• Errors are clear and announced correctly

• Links and buttons have useful names

• Contrast is sufficient

• Information does not depend only on colour

• Content works when zoomed or resized

• Multimedia has suitable alternatives

• Dynamic content works with assistive technology

• Important workflows can be completed successfully

Conclusion

Accessibility testing helps teams find barriers that prevent people from using digital products effectively.

The strongest approach doesn't depend on a single scanner or a final compliance audit. It combines automated checks, manual testing, assistive technology, realistic user journeys, and regular regression testing.

Testing a page for technical violations is useful. Testing whether a person can actually complete the task is what makes accessibility testing meaningful.

FAQs

What is accessibility testing in simple terms?

It checks whether people with disabilities can use a website, application, or digital product without unnecessary barriers.

Is accessibility testing manual or automated?

Both. Automated tools identify certain technical problems, while manual testing handles keyboard behaviour, screen reader interaction, user journeys, and issues requiring human judgement.

What is WCAG in accessibility testing?

A set of accessibility guidelines used to evaluate whether digital content is perceivable, operable, understandable, and robust.

Which WCAG level should you test against?

Level AA is a common organisational target, but the right requirement depends on applicable laws, contracts, industry expectations, and internal policies.

Can accessibility testing be automated?

Only partially. Automated tools catch many rule-based problems, but they can't determine whether the entire experience is genuinely usable.