ARIA Roles and Properties Accessibility Audit

ARIA Roles and Properties Audit

ARIA (Accessible Rich Internet Applications) attributes bridge the gap between custom UI components and assistive technologies. WCAG criteria 4.1.2 (Name, Role, Value) and 4.1.3 (Status Messages) directly depend on correct ARIA usage.

When to Use ARIA

The first rule of ARIA is: do not use ARIA if native HTML can achieve the same result. Native <button>, <input>, <select>, and <nav> elements have built-in accessibility.

ARIA is needed when:

• Building custom widgets (tabs, accordions, comboboxes)
• Creating dynamic content updates (live regions)
• Providing additional context (descriptions, labels)
• Defining page landmarks beyond HTML5 semantics

Key ARIA Attributes to Audit

Roles: Verify custom widgets use correct roles:

• role="tablist", role="tab", role="tabpanel" for tab interfaces
• role="dialog" for modal dialogs
• role="menu", role="menuitem" for application menus
• role="alert" for important, time-sensitive messages

States: Verify dynamic states are updated:

• aria-expanded="true/false" for collapsible sections
• aria-selected="true/false" for tabs and list items
• aria-checked="true/false" for custom checkboxes
• aria-disabled="true/false" for disabled controls

Properties: Verify relationships are defined:

• aria-label or aria-labelledby for accessible names
• aria-describedby for additional descriptions
• aria-controls to connect triggering elements to controlled regions
• aria-live="polite/assertive" for dynamic content updates

Common ARIA Mistakes

1. Using ARIA instead of native HTML — <div role="button"> instead of <button>
2. Incorrect role hierarchy — role="tab" not inside role="tablist"
3. Missing required children — role="list" without role="listitem" children
4. Stale ARIA states — aria-expanded not updating when toggled
5. Conflicting roles — Applying ARIA roles to elements with implicit roles