Assistive Technologies and User Interaction
The tool families
- Screen readers: JAWS, NVDA, VoiceOver, TalkBack, Narrator. Output is speech and/or braille; users navigate by headings, landmarks, lists, and form controls, not by scanning pixels.
- Screen magnifiers: ZoomText, OS magnifiers; users see a small viewport and rely on focus tracking.
- Speech input: Dragon, OS dictation - depends on visible, correctly labeled controls.
- Switch access, eye gaze, head pointers, sip-and-puff, alternative and one-handed keyboards.
- Refreshable braille displays - a tactile subset of screen reader output.
- Hearing: captions, hearing loops and telecoils, FM/remote microphone systems, amplified handsets.
How AT connects
AT does not read the screen; it reads the accessibility tree exposed through platform APIs - UIA, MSAA/IAccessible2 on Windows, the macOS/iOS AX APIs, and Android's accessibility framework. Missing names, wrong roles, and offscreen focus break that tree even when the page looks right.
Interaction patterns that matter
Logical focus order, visible focus, keyboard operability, skip links, landmarks, no keyboard traps, adequate time limits, and status messages announced politely.
Traps: equating "screen reader user" with "blind user who reads braille"; assuming a WCAG-conformant page is automatically usable with every AT and version combination; forgetting that browser/AT pairings and user settings change behavior; assuming magnification users benefit from more on-screen content rather than reflow.
Worked example
A modal dialog: focus should move into the dialog on open, be trapped within it, return to the trigger on close, and the dialog should expose role="dialog" with an accessible name. Without this, a screen reader user may remain in the background content and never find the dialog.
Rule of thumb
Test with at least one screen reader, keyboard only, and 200–400% zoom. Semantic correctness beats clever workarounds.