Assistive Technology Vocabulary | Accessibility Exercises

1 / 5

The developer is testing with NVDA + Firefox.

What type of assistive technology is NVDA?

NVDA (NonVisual Desktop Access) is a free, open-source Windows screen reader. Screen readers are among the most widely used assistive technologies:

Screen reader	Platform	Best paired browser
NVDA	Windows (free)	Firefox / Chrome
JAWS	Windows (enterprise)	Chrome / Firefox
VoiceOver	macOS / iOS (built-in)	Safari
TalkBack	Android (built-in)	Chrome

Key vocabulary: "screen reader", "speech output", "Braille display", "browse mode vs. forms mode", "virtual buffer".

2 / 5

An accessibility test plan includes "keyboard-only navigation testing".

What does this mean?

Keyboard-only testing validates SC 2.1.1 Keyboard (Level A) — all functionality must be operable without a mouse:

Key	Action
Tab	Move focus to the next interactive element
Shift+Tab	Move focus to the previous interactive element
Enter / Space	Activate focused button or control
Arrow keys	Navigate within widgets (menus, radios, tabs)
Escape	Close modals, dismissing overlays

Common fails: focus traps, mouse-only event handlers (onmouseover with no keyboard equivalent), invisible focus. Key vocabulary: "Tab order", "keyboard trap", "focus management", "keyboard operability (SC 2.1.1)".

3 / 5

The video has captions but no audio description.

What is the difference between captions and audio description?

Captions and audio descriptions serve different disability groups and are governed by separate WCAG success criteria:

Feature	Serves	WCAG criterion
Captions	Deaf / hard-of-hearing users	SC 1.2.2 — Level A
Audio description	Blind / low-vision users	SC 1.2.5 — Level AA

Captions ≠ subtitles: captions include non-speech audio cues (e.g., "[door slams]", "[music playing]"). Audio description narrates visual content not conveyed by existing audio. Key vocabulary: "closed vs. open captions", "SDH (Subtitles for Deaf and Hard-of-hearing)", "extended audio description".

4 / 5

The mobile app should be tested with an increased text size setting.

Which disability does large text accommodation primarily support?

Low vision users need enlarged content but typically interact visually — they are not the same as blind screen reader users:

User	Primary tool	WCAG criterion
Blind	Screen reader (NVDA, JAWS)	SC 1.3.1, 4.1.2 etc.
Low vision	Screen magnification, large text, high contrast	SC 1.4.4 Text Resize (200%)

SC 1.4.4: text must resize up to 200% without loss of content or functionality. Use relative font units (rem/em) not px. Key vocabulary: "low vision", "Dynamic Type (iOS)", "text resize (200%)", "relative font units", "zoom vs. text resize".

5 / 5

The engineering team was told to avoid using accesskey attributes.

Why are access keys problematic?

The accesskey HTML attribute assigns single-keystroke shortcuts to elements. The conflicts make them harmful rather than helpful:

Conflict type	Example
Screen reader shortcuts	NVDA uses single letter keys (H for headings, L for links)
Browser shortcuts	Alt+F opens File menu in some browsers
OS shortcuts	System-level key bindings override page-level accesskeys

WCAG 2.1 SC 2.1.4 (Character Key Shortcuts, AA): single-character shortcuts must be remappable, disabled, or only active on focus. Key vocabulary: "access key conflict", "keyboard shortcut remapping", "SC 2.1.4".