Live Region
// Definition
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.
// Why it matters
Dynamic content that updates silently is invisible to screen-reader users — a toast saying "saved" or an error "email is invalid" simply never reaches them without a live region. QA cares because SPAs are full of these silent updates, and it's a subtle failure: the page works perfectly for sighted users while announcing nothing to others.
// How to test
// The status container must be a live region so updates are announced
cy.get('[data-cy=form-status]').should('have.attr', 'aria-live', 'polite')
cy.get('[data-cy=submit]').click()
cy.get('[data-cy=form-status]').should('contain', /saved/i)
// Full confidence needs a real screen-reader pass — axe can't HEAR the announcement// Common mistakes
- Toasts/errors/validation that update with no live region (silent to AT)
assertiveeverywhere, interrupting the user constantly (reserve for urgent)- Injecting the live region at the same time as its content (must pre-exist to announce)
// Related terms
ARIA (Accessible Rich Internet Applications)
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.
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.
Focus Management
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.