Accessible Name
// Definition
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.
// Why it matters
A control with no accessible name is invisible to screen-reader users — an icon-only button announces as just "button". QA cares because this is one of the most common, most impactful accessibility failures, and it's testable: you can assert an element's computed accessible name automatically, no manual pass required.
// How to test
// Assert the computed accessible name (axe + role queries)
cy.findByRole('button', { name: /close dialog/i }).should('exist')
// icon-only button must STILL have a name:
cy.get('[data-cy=icon-close]')
.should('have.attr', 'aria-label').and('not.be.empty')// Common mistakes
- Icon-only buttons/links with no
aria-label(announce as just "button") - Assuming a visible label is the accessible name (it depends on the priority order)
aria-labeloverriding useful visible text, so name ≠ what's shown
// 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.
Semantic HTML
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.