I85PREP
⌘ K
AHWD study materials
AHWD study resources

AHWD: Assistive Technology and User Agents

AHWD · Work through your exam, one topic at a time.

All guide sections

Assistive Technology and User Agents

What to know

Assistive technology (AT) spans screen readers (JAWS, NVDA, VoiceOver, TalkBack), screen magnifiers, speech input (Dragon, voice control), switch access, refreshable braille displays, alternative keyboards, and cognitive aids. AT interacts with the accessibility tree, which browsers and operating systems derive from the DOM and ARIA. The accessibility tree exposes roles, names, states, and relationships - not visual styling.

Candidates should know ARIA basics: roles, states, and properties; the first rule of ARIA (use native HTML where possible); and the pattern for custom widgets (e.g., a tablist needs roles, keyboard interaction, and state). Live regions (aria-live, role="alert", role="status") announce dynamic changes; aria-live="assertive" interrupts, "polite" waits. Focus management matters in single-page apps and modals: move focus into the dialog and trap it, then restore on close.

Traps

  • Assuming aria-label overrides visible text; accessible name computation prioritizes aria-labelledby, then aria-label, then native content.
  • Using role="button" on a div without keyboard handlers - role alone doesn't add behavior.
  • Forgetting that screen readers announce based on the accessibility tree, so visually hidden (.sr-only) content is still read.

Rule of thumb

If native HTML provides the semantics and keyboard behavior, use it. Add ARIA only to fill genuine gaps, and always test keyboard interaction alongside screen reader output.

Worked example

A custom dropdown built from divs with role="combobox" lacks keyboard support. The fix: add Arrow/Enter/Escape handling, aria-expanded, and aria-activedescendant - or replace with a native <select>.