ARIA Cheatsheet for Designers
For: Designers, frontend developers learning accessibility
The first rule of ARIA: don't use ARIA when a native HTML element does the job. A button is more accessible than a div with role="button" + tabindex + key handlers. This cheatsheet covers the few cases where ARIA is genuinely required and the patterns that get them right.
References: WAI-ARIA Authoring Practices Guide · W3C ARIA 1.2 · First rule of ARIA use (No ARIA is better than bad ARIA)
Want to audit color contrast against this checklist on real screens — instantly, from your phone?
Use AccessAudit AI — runs offline, captures photo evidence per item, exports a sharable PDF.
When NOT to Use ARIA
Native HTML works — use <button>, <a>, <select>, <input>, <details>, <dialog> instead of div+ARIA
role="button" on a div without keyboard handlers — actively makes things worse
Redundant ARIA — <button aria-label="Submit">Submit</button> announces "Submit Submit"
role="presentation" or role="none" on interactive elements (kills accessibility)
When YOU NEED ARIA
These are the cases where native HTML doesn't cover the pattern.
Custom widgets without HTML equivalent — combobox, treegrid, slider (use APG patterns exactly)
Live regions — aria-live="polite" for status updates, "assertive" for errors
Labeling icon-only buttons — aria-label="Search" on icon button
Hiding decorative content from screen readers — aria-hidden="true" on visual-only items
Linking labels to inputs when <label for=> isn't possible — aria-labelledby
Marking required fields — aria-required="true" (along with visual + text indicator)
Disclosure widgets — aria-expanded on the trigger, aria-controls pointing at the panel
Modal dialogs — role="dialog" + aria-modal="true" + aria-labelledby pointing at the title
Run this on your phone
Point your iPhone camera at any color pair to see WCAG contrast ratio + pass/fail in real time. 100% on-device.