ARIA vs. Semantic HTML: The Golden Rule
Understand the difference between native semantic HTML and ARIA attributes, and learn why the first rule of accessibility is to not use ARIA if a native alternative exists.
<button>, <input>, <nav>) which already come with built-in accessibility and behavior. ARIA (Accessible Rich Internet Applications) is a set of attributes added to the code to “patch” or explain custom elements that the browser doesn’t understand by default.The First Rule of ARIA
If there is one thing every designer and developer should remember, it is the First Rule of ARIA:
“If you can use a native HTML element or attribute with the semantics and behavior you already need built-in, then do so.”
In other words: Don’t build a button with a <div> and a bunch of ARIA attributes to make it “look” like a button. Use a native <button> tag. It is faster, safer, and works better across all devices.
1. The Power of Native Semantics
Native HTML is a contract with the operating system and assistive technologies. When you use a native element, you get for “free”:
- Keyboard Accessibility: The button is focusable via Tab and activated with Space/Enter.
- Roles and States in the Accessibility Tree: The screen reader already knows what it is and whether it’s pressed or not.
- Predictable User Experience: The user knows how to interact with it because it behaves the same across the entire web.
2. When ARIA IS Necessary
ARIA is not bad; it’s a lifesaver when native tags fall short. It should be used for complex components that don’t exist in standard HTML:
- Tabs: There is no native
<tabs>tag, so we use ARIA to explain the relationship between the tab and its content (role="tablist",role="tabpanel"). - Tooltips and Help Text: To visually connect a help icon with its text description (
aria-describedby). - Live Regions: To notify a blind person that content in one part of the screen has changed (e.g., an error message that suddenly appears) without them having to move their focus there (
aria-live). - Complex Navigation Menus: To indicate that a button toggles a side menu (
aria-expanded="true/false").
Comparison: Which to Choose?
| Feature | Semantic HTML | ARIA Attributes |
|---|---|---|
| Complexity | Low (Native to the browser). | High (Requires JS to function). |
| Support | Universal and robust. | Can vary by screen reader. |
| Maintainability | Easy (Less code). | Difficult (Many manual attributes). |
| Ideal Use | Standard elements (Buttons, Links, Titles). | Custom components (Modals, Accordions). |
Common Bad ARIA Practices (Design and Code)
- Redundant ARIA: Adding
role="button"to a<button>. It’s already a button; don’t shout at the browser. - False Signifiers: Using ARIA to make an element “look” like something that doesn’t behave as such. If you say it’s a
checkbox, the user will expect to be able to check and uncheck it. - Forgetting the Keyboard User: ARIA helps screen readers understand, but it doesn’t help the user move. You will still need JavaScript for the keys to work correctly.
Mentor’s Tips
- Don’t overcomplicate: Before asking a developer to create a complex component from scratch with ARIA, check if there is a native solution (e.g., the
<details>and<summary>tags for accordions). - Document Intent: In your design specifications, indicate: “This element should be a native button” or “This is a tab component that will need ARIA logic.”
- Perform User Testing: Accessibility doesn’t end at the code. Test your component with a screen reader to verify that ARIA is communicating what you intended to express visually.
Useful Resources and Tools
- W3C: WAI-ARIA Authoring Practices (APG)
- Sara Soueidan: Accessible Component Patterns
- Deque University: ARIA Overview
- Articles: The Pitfalls of Over-ARIA
accessibility-tree focus-management screen-reader-testing identity-roles-states