Testing Accessibility with Assistive Technology: From Individual Checks to Complete Tasks

A reviewer checks a website’s contact form. Every field has a label, and the automated accessibility report looks reassuring. The reviewer then opens the page with a screen reader and attempts to send a message.

Can they find the instructions, recognize which information is required, correct an error, and tell whether the message was sent?

The review might confirm that these interactions work well, or it might reveal a barrier that needs investigation. A clear field name is useful evidence. Completing the task also depends on how navigation, instructions, controls, validation, and feedback work together.

Accessibility testing with assistive technology examines whether information and interactions remain understandable and operable through a particular technology and setup. This article follows an illustrative contact-form review from preparation to retesting. It describes a testing method, not results from a verified website or implementation.

Define the task and its outcome

Start with something a visitor needs to accomplish, rather than a collection of elements to inspect. For the contact form, the task is to find the form, understand what information to provide, send a message, and receive understandable confirmation.

Write down the intended outcome before testing. For example:

A visitor can submit a general inquiry, recover from a missing required email address, and determine whether the website accepted the submission.

This gives the review a beginning, a recovery path, and an ending. It also keeps the expected outcome precise: a website’s submission confirmation does not necessarily prove that an email reached someone’s inbox or that a staff member read it.

Choose a small set of meaningful conditions

For an initial review, use a valid submission path and one planned, recoverable error. Leaving a required field empty may be sufficient to examine how validation affects the task. More complex forms may justify additional conditions, such as a rejected file upload or an expired session.

You do not need every possible input combination to begin. Choose conditions that reflect important interactions and likely consequences. Record what remains outside the review.

Use a test environment or an authorized testing route if submission would send messages, create bookings, charge money, or change records. Prepare non-sensitive test data and agree on how test submissions will be identified or removed. Do not rely on reaching the final button and then deciding whether it is safe to activate.

Let the website’s purpose guide other tasks

Forms are only one starting point. Other representative tasks might include:

Finding a service’s opening hours and eligibility requirements.
Searching for a document and opening the relevant result.
Selecting an available appointment and reviewing its details.
Changing an account preference and confirming that it was saved.

Select tasks that cover important visitor needs and distinct interface patterns. The broader approach in reviewing a web form from start to finish provides a foundation; assistive-technology testing adds questions about setup, interaction, and the evidence needed to interpret what happens.

Prepare the testing setup

Assistive technology is a varied category. Screen readers, magnification software, speech-input systems, and other technologies support different ways of using a website. A screen-reader review provides useful depth, but it is not a substitute for examining those other interactions.

For a concrete starting point, this illustrative review can be planned around NVDA with Firefox on Windows. That is one bounded setup, not a universal recommendation or a claim that the combination represents all users. Choose an appropriate setup according to the site’s audience, support requirements, available expertise, and current product documentation.

Before running the task, record:

The operating system and version.
The browser and version.
The assistive technology and version.
Relevant settings, language, extensions, or customizations.
The website environment, page, and application state.
The interaction method or mode used where it affects the result.

Use the versions actually installed when the review takes place. These details help another reviewer reproduce the sequence and help developers distinguish an implementation problem from behavior specific to an environment.

Learn the interactions needed for this task

Screen readers provide ways to read content, navigate by structure, and interact with controls. These are not identical to moving through a page with the Tab key. Depending on the tool and its current mode, a key may perform a screen-reader command rather than the action someone expects from ordinary keyboard use.

Before interpreting an unfamiliar page, practice the necessary interactions on a simple example whose structure you understand. Learn how to read instructions, navigate headings and controls, enter and edit text, activate buttons, and return to nearby content.

For the proposed NVDA setup, consult the official NVDA User Guide and documentation appropriate to the installed version. Confirm commands and mode behavior rather than transferring assumptions from a different screen reader.

Preparation does not require mastering the entire tool. It requires enough familiarity to recognize when an unexpected result needs investigation—and when you need help understanding the tool itself.

Keep related checks distinct

Several review methods contribute different evidence:

Automated checks can identify programmatically detectable issues and support repeatable regression checks.
Keyboard-only review examines operation without a pointer, including focus visibility, order, and access to controls.
Assistive-technology testing examines how content and interactions are presented and operated through a chosen setup.
Evaluation with disabled participants brings evidence from people’s actual strategies, experience, and use.

Keep the automated report as part of the evidence. Conduct a separate keyboard navigation review rather than treating screen-reader use as proof of keyboard-only behavior.

Follow the form from entry to confirmation

Return to the contact page and begin at the agreed entry point. Starting with focus already inside the first field would bypass the question of whether someone can locate and understand the form.

Find the form and understand its purpose

Use the screen reader’s reading and navigation methods to locate the contact content. Observe whether the page’s headings and other structure provide a useful route.

Read the surrounding instructions. Can someone determine what the form is for, what information they need, and whether this is the appropriate route for their inquiry? If the instructions contain a restriction or an important privacy warning, include it in the review.

The task is not simply to encounter some text. It is to obtain the information needed to proceed.

Move through the controls and enter information

As you reach each control, consider what is available at that moment:

Does its name communicate what information or action is expected?
Is the type of control understandable?
Can required fields be identified?
Are relevant instructions available in context?
Are grouped choices and their shared question understandable?
Can the current value, selection, or state be determined?

These questions connect element-level evidence to use. A field may have a clear name while a separate formatting requirement remains difficult to discover. Conversely, the review may confirm that the name, instructions, and required state provide enough information to enter a valid response.

If a finding points toward implementation, accessible form structure provides deeper context for labels, instructions, grouping, and errors. Keep the task moving where possible; save detailed inspection for the investigation step.

Trigger the planned error and attempt recovery

Leave the agreed required field empty and attempt submission through the authorized test route. Observe what happens next, including changes in focus and any feedback presented through the screen reader.

Determine whether the sequence makes it possible to:

Recognize that submission did not complete.
Discover which field needs attention.
Understand the correction required.
Reach and correct the field.
Continue without unnecessarily re-entering valid information.

Do not make one exact announcement or focus destination the universal requirement. Different implementations can support recovery successfully. The question is whether the error and correction path are understandable and reachable, with behavior appropriate to the interface.

Correct the error and complete submission

Enter the missing information and submit again. If processing takes time, examine whether the interface communicates enough for someone to understand that their action is being processed and whether they need to wait.

Then examine the completion state. Can the reviewer determine that the submission was accepted? Are any next steps clear? If the form is replaced or the page changes, does navigation still make sense?

A visible success banner is evidence about the visual presentation. It does not, by itself, establish that someone using a screen reader can discover and understand the result. Equally, do not assume that every successful outcome requires the same announcement mechanism. Evaluate the complete interface feedback in its context.

Investigate unexpected behavior

Separate the observed result from the explanation you suspect.

“The error was not encountered during this sequence” describes an observation. “The page needs a live region” proposes a particular implementation change. The first may justify investigation without yet supporting the second.

When behavior is unexpected:

Repeat the sequence. Restore the relevant starting state and determine whether the behavior recurs.
Confirm tool operation. Check whether the command, interaction mode, and settings were appropriate.
Inspect the implementation. Examine relevant markup, focus changes, exposed relationships, and dynamic updates.
Compare selectively. Where useful, repeat the sequence in another appropriate setup to narrow the scope.

The accessibility tree can help explain which names, roles, states, and relationships the browser exposes. It is supporting evidence, not a replacement for observing the interaction.

A different result in another environment may help locate an interoperability issue. It does not automatically make the original barrier unimportant. Preserve the original finding and document where it does and does not reproduce.

Record tool-learning difficulties separately. Needing help with a navigation command is not the same finding as discovering a control that cannot be operated. Neither calls for blame; they call for different next steps.

Record reproducible findings

A useful finding connects a sequence of actions with its effect on the task. It gives another person enough context to investigate without requiring them to reconstruct the whole review.

The following is a hypothetical reporting example, not a finding from a tested website. In an actual report, replace the environment placeholders with recorded details.

Page, task, and state: Contact page on the test environment. Submit a general inquiry while recovering from an empty required email field. Begin with a freshly loaded form.
Environment: Windows [version], Firefox [version], NVDA [version]. Include relevant settings and the interaction mode used during the sequence.
Steps to reproduce: Enter approved test content in the other required fields. Leave Email empty. Activate Send. Record the resulting focus location, speech output, and subsequent navigation used to look for feedback.
Observed result: In this hypothetical case, submission is blocked and a visual email error appears. No error feedback is heard following activation. Returning to the Email field provides its name and required state but not the displayed correction message.
Expected task outcome: The reviewer can recognize that submission failed, identify the field needing attention, and obtain sufficient information to correct it. Equivalent wording or presentation may satisfy this outcome.
Effect on the task: The tested sequence does not communicate why the message was not sent. Recovery requires additional exploration or inference.
Evidence and open questions: Attach a sanitized recording or transcript, relevant markup, and focus observations. Investigate how the error is exposed and associated with the field. Record whether other reading routes or setups make it discoverable.

Captured speech is evidence from the recorded setup, settings, and sequence—not a prediction of what every screen reader will say. Preserve enough surrounding context to make a transcript meaningful, and remove real names, email addresses, message contents, and other sensitive information.

Where a finding relates to an accessibility requirement, document that relationship separately from the observation. A technical diagnosis or conformance judgment should explain its reasoning rather than rely on the fact that something sounded unexpected.

Correct the problem and repeat the task

Route the finding to the people responsible for its cause. Missing guidance may require a content change. An absent relationship may belong in a shared form component. Lost input or poorly timed feedback may involve application behavior.

Choose the correction after investigation. Adding an attribute or changing an announcement mechanism is not, by itself, proof that the task now works.

After the change:

Repeat the original sequence in the setup where the finding occurred.
Check that the error can be understood and corrected.
Continue through successful submission and confirmation.
Check adjacent behavior that the change could affect, such as focus order, duplicate announcements, or preserved input.
Repeat relevant automated and keyboard-only checks.

If the correction changes a reusable component, examine other representative places that use it. Keep follow-up proportionate to the change, its reach, and the remaining uncertainty.

Record the retest date, environment, result, and unresolved questions. This turns a one-time observation into maintainable evidence within ongoing accessibility engineering.

Include people who use assistive technology

A technical reviewer learning a screen reader can gather useful evidence. Turning on the software does not reproduce another person’s disability, experience, or established way of navigating.

People who use assistive technology in everyday life bring familiar strategies, preferences, and practical knowledge. Their participation can reveal difficulties or effective interaction paths that a technical review did not anticipate.

Plan that evaluation respectfully:

Explain the purpose, tasks, expected time, and any recording arrangements.
Provide accessible scheduling, consent, and session materials.
Arrange appropriate compensation for participants’ time and expertise.
Where feasible, support familiar devices, software, and settings.
Allow participants to use their own strategies instead of coaching them through a preferred route.

If assistance becomes necessary, record when and why it was provided. A task completed after someone points out an otherwise undiscovered error is different evidence from independent completion.

One participant’s success does not establish that everyone can use the website. An individual difficulty also deserves careful investigation rather than dismissal as personal preference or unfamiliarity. The W3C WAI guidance on involving users in evaluating web accessibility provides further planning context.

State what the review supports

Close the contact-form review with a bounded account of what was examined. A useful summary identifies:

The task and its starting and completion states.
The environments and interaction methods used.
The successful and error-recovery paths examined.
The findings, corrections, and retest results.
Conditions and questions that remain untested.

If the task succeeds after retesting, say that it succeeded under those recorded conditions. Avoid turning that result into “the website is accessible” or “the site conforms to WCAG.” A broader evaluation requires a defined scope, appropriate sampling, and assessment against the applicable requirements. W3C WAI’s accessibility evaluation guidance explains the wider evaluation landscape.

Further review may involve other pages, more complex recovery paths, or different assistive technologies. Magnification may bring layout and orientation into focus; speech input may call for examining how controls can be identified and activated. The next task should follow the site’s needs and the evidence already gathered.

The value of a label check remains. So does the value of an automated report. Following a complete task connects those individual findings to what someone can understand and do—from finding the form, through correcting a mistake, to knowing what happened after submission.