Phase 1: Web Fundamentals

ARIA roles & attributes for screen readers

Beginner ~4 min read
Think of it this way A friendly analogy. Read this if the technical version feels dense. Show Hide

Imagine you’re building an awesome LEGO castle, full of cool towers, secret passages, and drawbridges. You can see every piece and know exactly what everything is for. But what if you wanted to explain your fantastic castle to a friend who couldn't see it? You’d need to describe it really well, right? On the internet, some people use special tools called 'screen readers' that are like a helpful computer voice. Instead of seeing the pictures and buttons, the screen reader reads everything out loud. The tricky part is, sometimes we build things on a website that look amazing, but the computer voice doesn't quite understand what they are or how they work.

That's where something called ARIA comes in! ARIA stands for Accessible Rich Internet Applications. Think of ARIA like a special set of instruction stickers you can put on your LEGO pieces. These stickers aren't for you, because you can already see and understand your castle. Instead, they’re for your friend (or the screen reader) who can’t see it. These stickers give extra clues and details, making sure nothing is misunderstood. It’s all about making sure that everyone can explore and enjoy the amazing websites you build, no matter how they're looking at them.

ARIA gives us two main types of these helpful stickers: roles and attributes. A role sticker tells the screen reader what kind of LEGO part something is. For example, if you built a custom drawbridge lever from simple flat LEGO bricks (which usually don't mean 'lever' by themselves), you could put a role="button" sticker on it. This tells the screen reader, 'Hey, this acts like a button!' Then there are attributes. These are like extra detail stickers that give more information. So, once you've labeled your drawbridge opener as a button, you might add an aria-expanded="true" sticker to say, 'And right now, the drawbridge is OPEN!' Or an aria-label="Open the drawbridge" sticker to give it a super clear name.

So, when you start building your own cool web pages, you'll learn to use these ARIA roles and attributes. They're your way of adding those super helpful instruction stickers to the parts you create. This means that every person who visits your website, whether they're looking at it with their eyes or listening to it with a screen reader, will understand exactly what everything is and how to use it. You'll be building welcoming, understandable digital castles for everyone!

As a Frontend Developer, you'll build web interfaces that need to be usable by everyone, including people who use screen readers to navigate websites. This is where ARIA (Accessible Rich Internet Applications) comes in. Think of ARIA as a special set of extra instructions you can give to your HTML elements, primarily to help screen readers understand what a complex part of your page is, what it does, and its current state. While semantic HTML (like using <button> for a button or <nav> for navigation) is always your first and best tool for accessibility, ARIA steps in when standard HTML alone isn't enough to convey all necessary information, especially for custom interactive components.

ARIA provides two main types of helpers: roles and attributes. An ARIA role tells a screen reader what type of user interface element something is. For example, if you build a custom button using a <div> tag (which has no inherent semantic meaning), you can add role="button" to tell screen readers it functions like a button. ARIA attributes, on the other hand, provide more detailed information, such as an element's current state (aria-expanded="true" for an open accordion), properties (aria-haspopup="menu" for a dropdown), or relationships to other elements (aria-labelledby to link a label to an input). These attributes ensure that users relying on screen readers get the full context of what's happening on the page.

The most important rule when using ARIA is the "first rule of ARIA": If a native HTML element or attribute already provides the semantic meaning and behavior you need, use that instead of ARIA. For instance, use <input type="checkbox"> instead of a div with role="checkbox" and aria-checked. You primarily use ARIA for custom widgets, dynamic content updates, or when native HTML doesn't offer a specific semantic equivalent for complex interactions. Learning ARIA ensures your web applications are robust, inclusive, and accessible to the widest possible audience, which is a core responsibility of any great frontend engineer.

Key Takeaways

  • ARIA helps screen readers understand complex or custom web components.
  • ARIA 'roles' describe what an element is (e.g., role="button").
  • ARIA 'attributes' describe an element's state, property, or relationship (e.g., aria-expanded, aria-label).
  • Always use semantic HTML first; only use ARIA when native HTML isn't sufficient.
  • Using ARIA is crucial for building inclusive and accessible web applications.

Code Example

Preview

How this code works

This code demonstrates how to build an accessible custom toggle switch, like a "Dark Mode" button, that screen readers can understand and users can operate with a keyboard. Instead of using a standard HTML input, a div element is given specific ARIA attributes to mimic a switch. The role="switch" attribute explicitly tells assistive technologies its function, while aria-checked="false" sets its initial visual and programmatic state. tabindex="0" makes the custom element focusable by keyboard, and aria-label="Enable dark mode" provides a clear, concise description for screen reader users.

The JavaScript adds interactivity to this custom switch. A click event listener toggles the aria-checked attribute between true and false and updates the visible text between "On" and "Off". For keyboard accessibility, a separate keydown event listener is included. It checks for Enter or Spacebar presses to activate the switch. A subtle but crucial detail here is e.preventDefault() when Spacebar is pressed; this prevents the browser from scrolling the page, ensuring the key press solely triggers the toggle's intended action and maintains a consistent user experience.