Assistive Technology
// Definition
The umbrella term for hardware and software that helps people with disabilities use computers and digital devices — including screen readers (NVDA, VoiceOver, JAWS, TalkBack), screen magnifiers, switch-access devices, voice-control software (Dragon NaturallySpeaking), refreshable Braille displays, and eye-tracking systems. In QA, assistive technology testing means verifying that the product works with the specific AT combinations most relevant to the target user base, since behaviour can vary significantly across AT and browser pairings. Automated accessibility tools do not replicate AT behaviour; manual testing with real AT remains essential.
// Related terms
Screen Reader
Assistive technology software that converts on-screen content into synthesised speech or Braille output, enabling users who are blind or have low vision to navigate and interact with digital interfaces. Common screen readers include NVDA and JAWS (Windows), VoiceOver (macOS and iOS), and TalkBack (Android). QA testers use screen readers to verify that interactive elements have meaningful names, heading and landmark structure is navigable, dynamic content changes are announced, and no information is conveyed visually only.
Accessibility
The practice of designing and testing software so it is usable by people with a wide range of abilities — including users who rely on screen readers, keyboard navigation, voice control, switch access, or high-contrast display modes. In QA, accessibility testing involves both automated scanning and manual verification. Automated tools (axe, Lighthouse, Accessibility Scanner for Android, Accessibility Inspector for iOS) catch structural issues such as missing labels, insufficient colour contrast, and incorrect ARIA roles — typically around a third of all accessibility issues. The remaining two-thirds require testing with actual assistive technologies: VoiceOver on iOS, TalkBack on Android, NVDA or JAWS on Windows. WCAG 2.1 AA is the most widely referenced standard; Level AA compliance is required by law in many jurisdictions (ADA, EN 301 549, AODA). Integrating accessibility checks into CI — for example, running axe as part of a Playwright or Selenium test suite — prevents regressions from being merged undetected.
Keyboard Navigation
The ability to operate all interactive elements of a user interface using only a keyboard — Tab to move between focusable elements, Enter/Space to activate controls, arrow keys within composite widgets, and Escape to dismiss overlays. WCAG 2.1 Success Criterion 2.1.1 requires that all functionality is operable via keyboard. QA testers verify keyboard navigation by tabbing through a page without a mouse, confirming a visible focus indicator appears on every focusable element, the tab order follows the logical reading order, and no keyboard trap prevents a user from moving forward or escaping a component.