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.

A structured review of a product against accessibility standards, combining automated scans (axe, Lighthouse), manual checks, and assistive-technology testing. Automated tools catch roughly a third of issues; the rest need human judgement.

The discipline of verifying that software meets accessibility standards and can be used by people with disabilities — including users who rely on screen readers, keyboard-only navigation, voice control, switch access, or high-contrast modes. Testing strategy has three layers: automated scanning (axe, Lighthouse, Accessibility Scanner) catches structural issues such as missing labels, poor contrast, and incorrect ARIA roles — roughly 30–40% of all accessibility issues; manual keyboard-only testing validates focus order, interactive element reachability, and visible focus indicators; assistive-technology testing with VoiceOver, NVDA, TalkBack, or JAWS catches the remaining issues that automated tools cannot see. WCAG 2.1 Level AA is the most common legal compliance target. Integrating axe into Playwright or Cypress pipelines provides a regression gate against structural regressions.

The label a screen reader announces for an element — computed from a priority order of sources: `aria-labelledby`, then `aria-label`, then native content (a button's text, an input's `<label>`), then `title`. Two buttons that look identical can have different (or missing) accessible names, which is exactly what assistive-tech users experience.

A text description provided via the HTML alt attribute on img elements that conveys the meaning or function of an image to users who cannot see it — including screen-reader users and users with images disabled. Meaningful images require descriptive alt text that communicates the content or purpose of the image, not its appearance. Decorative images (pure visual embellishment) should use an empty alt attribute (alt="") so screen readers skip them entirely. QA testers check that every meaningful image has accurate, concise alt text, decorative images are marked correctly, and complex images (charts, infographics) have extended descriptions.

A W3C specification that adds roles, states, and properties to HTML elements to expose semantics to assistive technologies when native HTML alone is insufficient. The first rule of ARIA is: do not use ARIA — prefer native HTML elements (button, input, nav) that carry the correct semantics implicitly. Incorrect ARIA can make an interface less accessible than no ARIA at all. QA testers check that ARIA roles match the component's actual behaviour, required states (aria-expanded, aria-selected, aria-checked) update dynamically, and aria-label or aria-labelledby provides meaningful names for elements that lack visible text.

HTML attributes (role, aria-label, aria-describedby, aria-live) that expose semantics and state to assistive technologies. The first rule of ARIA is: don't use ARIA — prefer native HTML elements when they convey the same meaning.

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.

The difference in perceived luminance between a foreground colour (typically text or an icon) and its background, expressed as a ratio from 1:1 (no contrast) to 21:1 (black on white). WCAG 2.1 Level AA requires a minimum ratio of 4.5:1 for normal text and 3:1 for large text (18pt or 14pt bold) and for UI component boundaries. QA testers verify contrast using browser DevTools, the axe extension, or dedicated contrast-checking tools; failing contrast is one of the most common and automatable accessibility defects.

The luminance ratio between text and background, expressed as 1:1 to 21:1. WCAG AA requires 4.5:1 for normal text and 3:1 for large text. Easily measured by automated tools and a frequent fail on marketing sites.

The practice of programmatically controlling which element receives keyboard focus in response to user interaction or content changes — particularly when opening and closing dynamic UI components such as modals, drawers, toast messages, and single-page navigation. Correct focus management ensures that keyboard and screen-reader users are always aware of their position in the interface. QA testers verify that opening a modal moves focus into it, focus is constrained within the modal while it is open (a deliberate focus trap), closing the modal returns focus to the triggering element, and client-side navigation moves focus to the new page heading or a skip target.

Deliberately confining keyboard focus within a region — correct inside an open modal (Tab should cycle within it, not escape to the page behind), but a serious bug anywhere else (a user who can't Tab out is stuck). The accessible pattern: trap focus while a modal is open, restore it to the trigger on close.

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.

An ARIA region role (or native HTML5 element) that maps the major areas of a page — `banner`/`<header>`, `navigation`/`<nav>`, `main`/`<main>`, `contentinfo`/`<footer>`. Screen-reader users jump between landmarks to navigate a page structurally, the way a sighted user scans layout. Native semantic elements provide them implicitly.

A page area marked with `aria-live` so screen readers announce changes to it without the user moving focus there — used for toasts, form-validation errors, search-result counts, and status messages. `aria-live="polite"` waits for a pause; `assertive` interrupts. It's how dynamic updates reach screen-reader users at all.

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.

Verifying an interface works with assistive technology that reads content aloud — VoiceOver, NVDA, JAWS, TalkBack. Catches missing labels, broken focus order, and content visible only to sighted users.

The practice of using HTML elements according to their intended meaning — heading elements (h1–h6) for headings, button for interactive controls, nav for navigation regions, main for the primary content area — rather than using generic div and span elements for everything. Semantic elements convey role, structure, and sometimes state to browsers, search engines, and assistive technologies without requiring additional ARIA attributes. QA testers check that pages use a logical heading hierarchy, landmark regions are present, and interactive controls use native elements rather than div or span with click handlers.

A link — usually the first focusable element, visually hidden until focused — that lets keyboard and screen-reader users jump straight past repeated navigation to the main content. "Skip to main content" appears on the first Tab press and, when activated, moves focus to `<main>`.

Web Content Accessibility Guidelines — the international standard for accessible web content, organised into four principles (Perceivable, Operable, Understandable, Robust). Levels A, AA, and AAA define increasing conformance. Most regulations target WCAG 2.1 or 2.2 Level AA.