# 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.

*Tags: ux, concept, accessibility, a11y, development*

---


> [!info] Quick Definition
> **Semantic HTML** uses the browser's native tags (such as `<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](/concepts/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)](https://www.w3.org/WAI/ARIA/apg/)
- **Sara Soueidan:** [Accessible Component Patterns](https://www.sarasoueidan.com/blog/accessible-components-links-and-buttons/)
- **Deque University:** [ARIA Overview](https://dequeuniversity.com/curriculum/courses/fundamentals/aria-overview)
- **Articles:** [The Pitfalls of Over-ARIA](https://uxdesign.cc/why-you-should-avoid-over-using-aria-8a3d8e3e8e3)
---
[[accessibility-tree]]
[[focus-management]]
[[screen-reader-testing]]
[[identity-roles-states]]


---

Source: https://www.fernandoux.com/en/wiki/concepts/aria-vs-semantics/