Skip to main content

Name, Role, Value (ARIA).

Accessibility WCAG 2.1/2.2 Automated Compliance

Interactive elements must have accessible names — otherwise invisible to assistive tech

What does this check test?

This check verifies that all user interface components have an accessible name, an appropriate role, and that states and values are programmatically determinable. For standard HTML elements, the browser provides this automatically (a `<button>` has role "button" and gets its name from its text content). For custom components — React/Vue/Svelte widgets, custom dropdowns, modals, date pickers, tabs — developers must explicitly set ARIA attributes: `role`, `aria-label` or `aria-labelledby`, `aria-expanded`, `aria-selected`, `aria-checked`, etc. This maps to WCAG 2.2 Success Criterion 4.1.2 (Level A).

Why does it matter?

Assistive technology presents UI components to users through their accessible name, role, and state. A screen reader announces a button as "Submit, button" — 'Submit' is the name and 'button' is the role. If a custom `<div onclick>` element lacks a role, the screen reader announces it as generic text — the user has no idea it is clickable. If a custom accordion lacks `aria-expanded`, the user cannot tell whether a section is open or closed. Missing or incorrect ARIA makes custom widgets completely unusable for assistive technology users.

Who is affected?

Front-end developers building custom interactive components, React/Vue/Angular component library maintainers, designers specifying interactive behaviors that need ARIA support, and accessibility auditors testing custom widgets. Anyone replacing a native HTML element with a custom implementation must replicate its full accessibility API.

Where does this apply?

Every custom interactive component: custom buttons (divs/spans with click handlers), modal dialogs, dropdown menus, tab panels, accordions, carousels, date pickers, autocomplete inputs, tree views, drag-and-drop interfaces, toggle switches, and custom video players. Also check icon-only buttons, hamburger menus, and close buttons that lack visible text labels.

How to fix it

Prefer native HTML elements — `<button>`, `<select>`, `<input type="checkbox">` — which have built-in roles and states. The first rule of ARIA is: don't use ARIA if you can use native HTML. Custom toggle with ARIA:
html
<!-- Bad: div with click handler, no role or state -->
<div onclick="toggle()">Dark mode</div>

<!-- Good: button with role and state -->
<button role="switch" aria-checked="true" aria-label="Dark mode">
  <span class="toggle-track">...</span>
</button>
Modal dialog with ARIA:
html
<div role="dialog" aria-modal="true" aria-labelledby="modal-title">
  <h2 id="modal-title">Confirm deletion</h2>
  <p>This action cannot be undone.</p>
  <button>Cancel</button>
  <button>Delete</button>
</div>
Tabs with proper roles and states:
html
<div role="tablist">
  <button role="tab" aria-selected="true" aria-controls="panel-1">Tab 1</button>
  <button role="tab" aria-selected="false" aria-controls="panel-2">Tab 2</button>
</div>
<div role="tabpanel" id="panel-1">Content for Tab 1</div>
<div role="tabpanel" id="panel-2" hidden>Content for Tab 2</div>
Automated tools detect missing accessible names, invalid roles, and some incorrect ARIA usage, but full validation of custom widget keyboard behavior requires manual testing.

References

AppVet checks Name, Role, Value (ARIA) automatically

Run a free accessibility scan and get a full report with actionable fixes, including a Fix with AI prompt you can paste into any coding tool.

Run Audit