ARIA Implementation Checklist Template

What This Template Is For

ARIA (Accessible Rich Internet Applications) attributes bridge the gap between custom UI components and assistive technology. Native HTML elements like , , and communicate their role, state, and behavior to screen readers automatically. Custom components built from

and elements do not. ARIA adds that missing semantic layer.

The problem is that incorrect ARIA is worse than no ARIA. A

without keyboard event handlers creates a visual button that screen readers announce as a button but that keyboard users cannot activate. This template provides a component-by-component checklist for implementing ARIA correctly, including the roles, states, properties, and keyboard interactions each pattern requires.

Use this template during development of custom interactive components. It pairs with the accessibility audit template for post-build verification and the focus management template for keyboard interaction patterns. The Technical PM Handbook covers how PMs can review technical implementation details like ARIA usage without needing to write the code themselves. For a broader view of accessibility requirements beyond ARIA, the WCAG audit template covers the full compliance picture.

---

How to Use This Template

1. Before reaching for ARIA, check if a native HTML element does the job. A is always better than
   . A

is always better than a custom dropdown with ARIA. The first rule of ARIA is: do not use ARIA if you can use native HTML.

For each custom component, find its WAI-ARIA Authoring Practices pattern. The W3C maintains a patterns library with required roles, states, properties, and keyboard interactions for common widgets.

Use the checklist tables below to verify your implementation. Each row is a testable requirement. Check the box when the requirement is met.

Test with a screen reader after implementing ARIA. VoiceOver on macOS, NVDA on Windows, and TalkBack on Android are the priority test targets. ARIA support varies between screen reader and browser combinations.

Document any ARIA decisions that deviate from the standard patterns and explain why.

---

The Template

ARIA First Principles Checklist

Before implementing ARIA on any component, verify these foundations.

• ☐ Prefer native HTML. Every custom widget was evaluated for a native HTML alternative first. Where native HTML works, ARIA was not added.
• ☐ No ARIA is better than bad ARIA. Incomplete ARIA implementations (roles without keyboard support, states that do not update) were identified and either completed or removed.
• ☐ All interactive ARIA elements are keyboard accessible. Every element with an interactive role (button, link, tab, menuitem, etc.) can be reached with Tab and activated with Enter or Space.
• ☐ ARIA states update dynamically. When a component's state changes (expanded, selected, checked, pressed), the corresponding aria-expanded, aria-selected, aria-checked, or aria-pressed attribute updates in the DOM.
• ☐ ARIA labels are human-readable. aria-label and aria-labelledby values are descriptive sentences or phrases, not CSS class names or developer shorthand.
• ☐ No redundant ARIA on native elements.

or