Perspective

Accessibility testing: where do I actually start?

A practical testing order for people who need more than an automated scan but do not know where to begin.

Accessibility testing can become overwhelming quickly. WCAG is large, assistive technology is unfamiliar to many testers, and no single tool can tell you whether a product is accessible.

You do not need to test everything simultaneously.

Start by building layers of evidence.

1. Understand the task before testing the interface

Choose a real user journey: create an account, find information, submit a form, change a setting, buy something.

Write down what successful completion requires.

This stops accessibility testing becoming a hunt for isolated technical violations while a major workflow remains unusable.

2. Check the structure

Before reaching for ARIA, inspect what the product is already communicating.

For a web experience, look at:

• page title and language;
• landmarks;
• heading structure;
• links and buttons;
• labels and instructions;
• images and alternatives;
• errors and status messages.

Ask whether the underlying semantics match what the interface appears to mean.

3. Use only the keyboard

Put the pointer aside.

Can you reach every interactive element? Can you see where focus is? Is the order sensible? Can you operate controls and escape components such as dialogs and menus?

Keyboard testing is inexpensive and exposes important failures, but a keyboard pass does not prove screen-reader accessibility.

4. Run automated checks

Now use automation.

This ordering is intentional: automation is evidence, not the definition of the task.

Record what the tool found, fix genuine failures, and understand which rules were actually evaluated. Do not convert a clean result into “100% accessible.”

5. Test zoom, reflow and text changes

Increase zoom and narrow the viewport. Where relevant, test platform text sizing and text-spacing changes.

Look for clipped, overlapping or missing content and controls that become unreachable.

6. Test with a screen reader

Choose a supported, representative screen-reader/browser or platform combination.

Do not merely swipe or tab through the page listening for strange announcements. Attempt the same real task you defined at the beginning.

Pay attention to structure, names, states, instructions, errors, changes of context and what happens after actions.

7. Look beyond conformance

Ask questions that are harder to encode as binary checks:

• Is the hierarchy understandable?
• Are instructions unnecessarily complicated?
• Does the interface demand memory it could avoid demanding?
• Is error recovery clear?
• Are there unnecessary time limits or interruptions?
• Does completing the task require substantially more effort through one interaction mode?

8. Know what you still do not know

At the end, write down the limits of your testing.

Which assistive technologies did you not test? Which disabilities or interaction modes are not represented? Was disabled-user testing conducted? Were only selected flows covered?

A useful accessibility report describes uncertainty rather than hiding it.

A simple evidence record

For each test, record:

Task → method → environment → result → evidence → limitation → follow-up.

That is much more informative than a single accessibility score.

Next: try one barrier

See A control has no useful accessible name for an example of how No Default connects a barrier to testing, automation limits and WCAG.