Overview
The W3C's own first rule of ARIA use is to avoid it whenever a native HTML element already provides the needed semantics and behavior, a native <button> gets keyboard activation, focus handling, and correct screen-reader semantics for free, while a <div role="button"> requires manually rebuilding every one of those behaviors and is easy to get subtly wrong. Color contrast has a similarly concrete, non-arbitrary standard: WCAG AA requires a 4.5:1 ratio for normal text and a relaxed 3:1 for large text, calibrated to the fact that larger, wider character strokes are genuinely easier to read at lower contrast, not just a stylistic threshold. Both point at the same underlying practice: accessibility bugs are frequently invisible to a purely visual review, a component can look and work correctly with a mouse while being unreachable by keyboard or meaningless to a screen reader, which is why direct keyboard and assistive-technology testing matters, not just design review.
Quick Reference
| Rule | What it says |
|---|---|
| First rule of ARIA | Use a native HTML element/attribute instead of re-purposing one with ARIA, whenever one already fits |
| WCAG AA contrast, normal text | 4.5:1 minimum |
| WCAG AA contrast, large text (18pt+/14pt bold+) | 3:1 minimum |
Syntax
<!-- Prefer this: native semantics, keyboard support, focus handling, free -->
<button type="button">Submit</button>
<!-- Over this: requires manually replicating everything a button already does -->
<div role="button" tabindex="0">Submit</div>Examples
<!-- A div-based "button" needs all of this manually added just to
approach what a native <button> already does automatically. -->
<div
role="button"
tabindex="0"
onkeydown="if (event.key === ' ') event.preventDefault(); if (event.key === 'Enter' || event.key === ' ') activate()"
onclick="activate()"
>
Submit
</div>Looking right visually doesn't mean it's accessible
A custom component can pass a visual design review while being completely unreachable by keyboard or meaningless to a screen reader. Test directly with Tab/Enter/Arrow keys and a screen reader, don't infer accessibility from appearance alone.
Visual Diagram
Common Mistakes
- Reaching for a styled
<div>plus ARIA roles before checking whether a native element (<button>,<select>,<a>) already does the job. - Adding
role="button"without also adding keyboard support (EnterandSpace), leaving the element unusable without a mouse. - Choosing text colors based on visual preference without checking the actual contrast ratio against WCAG's 4.5:1/3:1 thresholds.
- Reviewing accessibility purely by looking at the UI, instead of actually testing with a keyboard and a screen reader.
Performance
- Native HTML elements ship their accessibility behavior in the browser itself, at effectively zero additional script cost, compared to hand-rolled ARIA widgets that need real JavaScript to replicate the same behavior.
- Accessibility testing (keyboard navigation, screen reader checks) has a real time cost during development, but it is far cheaper than retrofitting it after a component has shipped broadly.
Best Practices
- Default to native HTML elements for interactive controls, and only reach for ARIA when there is genuinely no native element that fits.
- Check text/background color combinations against WCAG's actual 4.5:1 (normal) or 3:1 (large text) ratios, not by eye.
- If a custom widget is genuinely necessary, replicate the full expected keyboard behavior (Tab order, Enter/Space activation, Arrow-key navigation where applicable), not just the visual appearance.
- Test with a keyboard alone and a screen reader as a normal part of review, not as a separate, occasional accessibility pass.