Test with keyboard and assistive technology

Start from the behavior you can observe. The release matrix covers keyboard-only, high zoom, one desktop screen reader and browser pair, and one mobile pair.

Compatibility varies, so test the combinations important to your audience without claiming one setup represents everyone. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

It is tempting to perform random screen-reader exploration without tasks or expected outcomes. That trades a clear decision for an assumption you will eventually have to debug. The stronger move is to define tasks, supported combinations, expected announcements, and evidence before running the test. Make the boundary explicit in code and in the project notes.

Tie the decision back to the larger job: Turn the repaired page into a repeatable accessibility practice rather than a one-time cleanup. Record enough evidence that another developer can repeat the result without relying on your memory.

Register, find errors, correct them, and confirm success in each chosen combination. Repeat it once with an invalid or hostile condition and write down the boundary the failure revealed.