Your site works perfectly on Chrome, but a screen reader makes it feel like a wall of plaster. No structure, no landmarks. Visually impaired users get lost — and you lose customers.
We, at Meteora Web, work daily with developers and SMEs who discover their site is inaccessible only after launch. And when a WCAG compliance notice arrives, costs skyrocket. ARIA (Accessible Rich Internet Applications) is one of the most powerful tools to fix this — but used incorrectly, it does more harm than good.
This guide explains when and how to use ARIA roles, labels, and landmarks to make your site truly accessible, without tricks. We start from the concrete.
What are ARIA roles, labels, and landmarks, and why do they matter for accessibility?
ARIA is a set of HTML attributes that enrich the semantic meaning of elements for assistive technologies (screen readers, braille displays, voice commands). The three pillars are:
- Roles: define the element type (e.g.,
role="button",role="navigation"). - Labels: provide an accessible name for elements that would otherwise be anonymous (e.g.,
aria-labelon an icon button). - Landmarks: specific roles that mark key page regions (
banner,navigation,main,contentinfo, etc.), allowing users to jump from section to section.
Why do they matter? Because HTML alone isn't enough. A <div> with a click handler is a button only for those who see the cursor. A screen reader reads it as "div". Adding role="button" and aria-label="Search" turns it into an interactive named element.
Sponsored Protocol
Imagine entering an office without signs: every door looks the same. Landmarks are the signs reading "HR office", "Restrooms", "Exit". Without them, users grope in the dark.
Operational: check if your page uses landmarks
Open your page in Chrome, open Developer Tools (F12), go to the "Accessibility" tab and look at the "Accessibility Tree". If you see only generic or region without a name, you're on the ground. Alternatively, use WAVE Evaluation Tool: it immediately reports missing landmarks.
When should you use ARIA roles — and when should you avoid them?
The golden rule from the W3C: Don't use ARIA if you can use a native HTML element. A <button> already has implicit role="button", native keyboard behavior, and focus management. Writing <div role="button"> means manually handling events, state, and focus. More code, more bugs, more costs.
So when should you use ARIA roles?
- When you need to create a custom component (a dropdown menu, a carousel, a tab set) with no native HTML equivalent.
- When you want to change the semantics of an existing element (e.g., an
<a>used as a button without an href). - When you need to add a landmark role to a generic container (
<div role="navigation">).
Common mistake: adding role="banner" to a <header> that already has implicit role. Useless and redundant. Let native HTML do its job.
Sponsored Protocol
Operational: when tempted to use ARIA, ask yourself: is there an HTML tag for this?
If yes (<header>, <nav>, <main>, <footer>, <button>, <input>), use that. ARIA is only for cases where HTML falls short.
How to correctly implement landmarks in a page?
Landmarks are the roles defining macro-regions. The most common:
banner— site header (usually<header>)navigation— navigation menu (<nav>)main— main content (<main>)complementary— supporting content (<aside>)contentinfo— footer (<footer>)search— search featureform— form (use with care; better<form aria-label="...">)
Use native HTML elements that already have implicit roles. If layout forces you to use <div>, add role and, if needed, aria-label to distinguish two regions of the same type (e.g., two nav: one primary, one secondary).
Example: a basic landmark structure
<body>
<header role="banner">
<h1>Meteora Web</h1>
</header>
<nav aria-label="Main navigation">
<ul>
<li><a href="/">Home</a></li>
<li><a href="/services">Services</a></li>
</ul>
</nav>
<main>
<article>...</article>
</main>
<aside role="complementary" aria-label="Related articles">
...
</aside>
<footer role="contentinfo">
<p>© 2026 Meteora Web</p>
</footer>
</body>
Note: Do not mix two roles on the same element. A <header> cannot also be navigation. Use nested children.
Sponsored Protocol
How to associate labels and descriptions with non-text elements using ARIA?
The attributes aria-label, aria-labelledby, and aria-describedby give a name or description to an otherwise anonymous element. Concrete examples:
- An icon-only button:
<button aria-label="Menu">☰</button> - An input without a visible label:
<input aria-label="Search the site" type="search"> - An iframe embedding a video:
<iframe title="ARIA tutorial video" src="..." aria-label="Explanation of ARIA roles"></iframe>(prefer nativetitle)
Difference between label and description: the label is the short, unique name; the description provides extra information. Example: a "Buy" button might have a description "Adds to cart and proceeds to checkout" via aria-describedby.
Sponsored Protocol
Operational: test labels with a screen reader
Try NVDA (free on Windows) or VoiceOver (on Mac) and navigate using Tab. Every interactive element should announce a name. If you hear only "Button" without context, a label is missing.
What are common ARIA mistakes and how to avoid them?
We've seen dozens of sites with these errors. The worst ones:
- Redundant ARIA roles:
<button role="button">— completely useless. - Missing or overlapping landmarks: two
role="navigation"without distinct names. The screen reader lists them both as "Navigation", with no differentiation. Usearia-labelon each. - No focus management: add
tabindex="0"to elements with interactive roles, and implement keyboard navigation. ARIA doesn't do magic — you must program the behavior. - Declared but unsupported attributes: some roles require specific properties (
aria-expanded,aria-pressed). If you don't set them, the screen reader reports wrong states. - Not testing with real users: automated tools (WAVE, axe) catch technical errors, but only a test with visually impaired users reveals usability gaps.
Operational: run a quick audit with axe DevTools
Install the axe DevTools extension on Chrome, open your page, and run an audit. Filter for "ARIA". Resolve every issue, starting with critical ones. After each fix, rerun the test.
Sponsored Protocol
What to do now to make your site WCAG compliant with ARIA
You don't need to rebuild everything. Follow this operational checklist for each page (start with the homepage and most visited pages):
- Identify macro-regions (header, nav, main, aside, footer) and assign the correct landmark — preferably with native HTML tags.
- Name each landmark with
aria-labelif you have two of the same type (e.g., two navigations). - Check that all buttons and links have an accessible name: if they use icons, add
aria-label. - Verify forms have explicit labels (
<label>oraria-labelfor every input). - Remove redundant ARIA: delete
roleon native elements like<header>,<nav>,<main>,<button>. - Test with NVDA or VoiceOver navigating only by keyboard (Tab, Shift+Tab, arrow keys).
- Document your choices: if you used custom roles, leave comments in the code for future developers.
We at Meteora Web do this for every project we handle, from domain to revenue. It's not just compliance: it's respect for your users and an investment that pays off in reach, reputation, and reduced legal risk.
For deeper reading, check our pillar guide on web accessibility WCAG.
For official resources: consult the W3C ARIA Authoring Practices and the MDN ARIA reference.
