Introduction to ARIA

Overview

In this lesson, you will learn about the basics of the Accessible Rich Internet Applications (ARIA) standard. Your goal is to get a better understanding of the kinds of challenges that exist around accessibility for dynamic content, including some of the dangers of using ARIA incorrectly.

Goals

You have the following goals for this lesson:

• Learn the most commonly used ARIA attributes
• Identify incorrect use of ARIA and its inconsistencies
• Learn about semantic HTML and the corresponding ARIA
• Learn how ARIA affects assistive technologies

Warm up

Think about some interactive elements you've encountered on websites, like dropdown menus, tab panels, or star rating widgets. These components often change content or behavior dynamically. Now ask yourself: how can we ensure that users relying on screen readers or other assistive technologies can access and understand these changes?

Vocabulary

You will be learning about the following vocabulary words:

Web Content Accessibility Standards

This lesson covers the following standards:

• WCAG 2.2 - 1.1.1 Non-text Content
• WCAG 2.2 - 1.3.1 Info and Relationships
• WCAG 2.2 - 2.1.1 Keyboard
• WCAG 2.2 - 4.1.2 Name, Role, Value

Explore

Accessible Rich Internet Applications (ARIA) is a set of attributes added to elements on a page with the intent of making those elements more accessible. ARIA is not a true programming language and what attributes do depends on the browser interpreting it and the assistive technology the user has. This means that behavior varies by browser, which is a common technical frustration with the specification.

ARIA alone does not change functionality or visual appearance. A good rule of thumb is that ARIA is intended to enhance HTML, but it does not replace it or change what the code does programmatically. Mentioned in the WCAG 2.2 A, Section 3 and 4 Lesson, the main features of ARIA are roles, properties, and states. As a brief reminder, consider an example of what each of these are:

A role tells you what the element is.

<div role="button">Submit</div>

A property describes a characteristic or relationship an element has.

<div role="button" aria-describedby="more-info">Copy Example</div>
<div id="more-info">Use this button to copy the example code into the clipboard to paste into the editor </div>

A state describes the current status or value of an element.

<div role="checkbox" aria-checked="false">Remember Me</div>

A crucial idea to understand is that while ARIA describes information about the HTML, at the end of the day, the words and symbols used in the specification get mapped down to the computer's operating system. However, Windows, Mac, iOS, and Android all have incompatible ways of managing these attributes, so naturally there are inconsistencies in how ARIA is used and interpreted. Unfortunately, this means developers are stuck with typing out the ARIA and hoping it works how the specification says it should, which is often wrong.

The use of ARIA attributes should be based on both their specification and real-world testing. Overuse or misuse of ARIA can degrade accessibility rather than improve it [1], particularly when roles and attributes are not used together as expected.

Roles

ARIA roles are fundamental to making custom and complex web interfaces accessible to users who rely on assistive technologies. At their core, roles assign a specific purpose or identity to elements on a web page. These roles inform screen readers and other assistive tools how to interpret and interact with the element in question. For example, an element with a role=’textbox’ will be treated as an editable text field by a screen reader, even if it is visually styled with nothing more than a <div> or <span>.

It is important to remember that assigning an ARIA role does not automatically make an element interactive or functional. While roles provide semantic meaning, actual behavior must often be implemented with JavaScript. Whenever possible, native HTML elements should be used first, since they come with built-in semantics and accessibility support. For example, <button> or <input type=’checkbox’> have roles like ‘button’ and ‘checkbox’ baked in and already follow expected accessibility behaviors.

However, in some cases, developers build entirely custom components using <div> or <span> elements, applying roles and behaviors manually. This is where ARIA becomes vital. If you are replacing a native control or building something new, applying the correct role and managing its behavior and relationships becomes essential.

Landmark Roles

Among ARIA roles, landmark roles serve to define sections of a web page. These roles allow users to navigate quickly using their assistive technology. For instance, screen reader users can skip directly to the main content or jump to the navigation bar if these areas are marked appropriately. Roles like banner, navigation, main, complementary, and contentinfo help break up the page into recognizable regions.

These roles do not change how elements appear visually, but they offer powerful structural hints that improve navigability, especially for those not using a mouse or relying on visual cues. Used correctly, they allow for a more streamlined experience when navigating pages with repetitive elements. The next lesson on Tagging and Structure in ARIA will explore Landmark Roles in more depth.

Widget Roles

One of the subcategories of roles in ARIA are known as the widget roles. These describe interactive interface elements. They are essential when developers create custom controls that do not rely on native HTML. For example, if a developer creates a toggle switch from scratch using <div> elements, they might assign role=’switch’ to help define how that control behaves from an accessibility standpoint.

Widget roles are broad and include types like button, checkbox, dialog, slider, and tab. These roles are typically assigned to elements that accept user input or perform an action. However, it is important to understand that assigning a role like checkbox does not make the element checkable by itself, developers must still implement the interaction logic and update relevant states using JavaScript.

When building widgets from scratch, developers need to consider not just roles but also the appropriate ARIA attributes and keyboard support to ensure the experience is accessible and usable across various devices.

Simple and Composite Widgets

Some ARIA widgets are relatively straightforward, like button, link, or progressbar. These are often referred to as simple widgets. They typically map to a single visual control and can be handled with one ARIA role and a few supporting attributes or states.

In contrast, composite widgets are made up of multiple elements that work together to form a cohesive interactive experience. Examples include a tablist that contains multiple tab elements and a corresponding set of tabpanel sections. Similarly, a menu widget may contain multiple menuitem roles that allow users to navigate a series of choices. These widgets require careful coordination between the parent and child roles, keyboard navigation patterns, and dynamic ARIA state updates.

Composite widgets are more complex to implement accessibly, but they offer powerful functionality. Ensuring that focus management, role relationships, and state updates are correctly applied is essential. Without these, the widget might be visually usable but completely unusable for someone relying on assistive technology.

The point is to recognize that ARIA expands upon native HTML elements. However, using ARIA requires that you do some real and thorough testing. Sometimes it can be truly finicky. This lesson gives a brief overview of what is available, but is not the end of the story. Just adding a word to the HTML is often not enough for accessibility.

States And Properties

ARIA also provides a rich set of attributes called states and properties, which describe the current status or behavior of an element beyond its role. These attributes can inform a user whether a checkbox is checked (aria-checked), if a section is collapsed (aria-expanded), or whether a field is required (aria-required).

States usually represent dynamic conditions, or attributes that may change over time. Properties tend to be static descriptions or associations that help define an element’s relationships or meaning, such as aria-label, which provides a textual label for elements without visible text, or aria-describedby, which references another element that offers a longer description.

While ARIA attributes are designed to improve accessibility, their real-world effectiveness can vary based on screen reader support and how each attribute is implemented. For instance, aria-describedby, introduced in ARIA 1.0, remains broadly supported and reliably interpreted. In contrast, newer attributes like aria-description, added in ARIA 1.2 to provide additional user-facing context, are still inconsistently supported across different screen readers. The impact of a given ARIA state or property also depends on context. For example some attributes like aria-label, are global and almost always announced, while others, such as aria-valuemin and aria-valuemax, may be ignored on elements like buttons where they do not apply semantically.

This might sound straightforward, but it is a key concept. One of the most common questions is: Why does one screen reader respond differently than another to the same ARIA markup? The answer is that ARIA is mapped to platform-specific accessibility APIs, which vary across operating systems. Additionally, each assistive technology vendor can choose how (or whether) to interpret any ARIA attribute. This leads to a somewhat inconsistent, patchwork experience across devices and browsers.

To ensure you are using ARIA attributes effectively, always consult documentation for the specific role you are working with. Some roles require certain properties to function properly. However, as ARIA standards continue to evolve, developers should verify support through hands-on testing rather than relying solely on documentation, especially when using newer or less widely adopted attributes. Below are examples of commonly used states and properties:

Live Regions

Not all content is static, and sometimes you may need to notify the user that something has changed or requires their immediate attention. ARIA provides a way to communicate these changes to assistive technologies through live regions. However, live regions should be used with caution. If implemented incorrectly or overused, they can create a frustrating experience by repeatedly interrupting the user with constant updates. In some cases, such as for users of braille displays, the device might not even relay the notification. For these and other reasons, live regions can be very useful but must be applied carefully and thoughtfully.

With that caution in mind, ARIA live regions include several properties that control how updates are communicated to users. The aria-live property, in particular, determines how forcefully dynamic content should be announced. It can take the following values:

• polite: Updates will only be announced when not busy. Useful when content changes are non-essential
• assertive: Updates will be announced immediately. Screen readers might interrupt their current speech for the update. Useful for urgent information like an alert or error message.
• off: Updates are to not be announced unless focus is on or inside the element. Useful for dynamic content that updates frequently but is not critical.

Citations

1. Mozilla Developer Network. ARIA: Accessibility roles and attributes. MDN Web Docs.
2. W3Schools. Tryit Editor v3.7 - Default. W3Schools. https://www.w3schools.com/html/tryit.asp?filename=tryhtml_default
3. World Wide Web Consortium (W3C). WAI-ARIA: Accessible Rich Internet Applications. W3C Web Accessibility Initiative (WAI). https://www.w3.org/WAI/standards-guidelines/aria/

Engage

In this activity, you will explore how ARIA attributes can enhance or complicate a user's experience, especially for those using assistive technologies like screen readers or keyboard navigation.

While visually, buttons may appear identical and respond similarly to mouse input, the underlying code can cause them to behave very differently depending on how a user interacts with them. These differences can either support accessibility or unintentionally create confusion, inconsistency, or exclusion.

You will be examining several variations of buttons, some built semantically, others manually constructed using ARIA roles and properties. Your task is to investigate how these differences can impact usability and then apply what you have learned to improve them.

Directions

Begin by exploring the interactive buttons provided below. If possible, turn on a screen reader on your device (such as VoiceOver on Mac, NVDA or JAWS on Windows, or TalkBack on Android) before starting. This will allow you to experience how each button communicates with assistive technology in addition to how it behaves visually.

Investigate Challenge

Your task is to investigate how each button behaves and sounds when activated using different input methods. Try selecting each button in three ways: by clicking with a mouse or trackpad, by pressing the Enter key, and by pressing the Spacebar key. Pay attention to which buttons are operable by keyboard or mouse alone, which ones produce audible feedback through the screen reader, and whether the feedback matches what sighted users receive. Do each of the buttons behave the same across methods and tools? What stands out, and why?

Once you have completed your investigation, continue with the Fix Challenge.

Fix Challenge

Now that you have investigated how each button behaves, copy the full HTML code for the buttons and paste it into the W3Schools TryIt Editor or another HTML editor of your choice, your task is to fix each button individually so that its behavior is consistent, accessible, and meaningful, without simply turning every button into the same HTML structure. If time allows, try to fix all of them.

Focus on making sure that:

• All methods of selection (mouse click, Enter key, and Space key) work the same.
• The visual label (what the button text says) matches what the button actually appears to do (based on alerts or other feedback). For example, if the alert says a form was submitted, the button text should say something like ‘Submit Form,’ not just ‘Activate.’)
• The auditory experience (especially for screen reader users) matches what a sighted user would experience visually.

Remember that semantic HTML elements like <button> are generally preferred for accessibility, however for the context of this lesson, working with a variety of structures will ensure you understand how ARIA and HTML work together. Do not simply convert everything to <button> tags. Instead, focus on improving each button's accessibility within its existing structure, ensuring that it communicates clearly and functions consistently for all users.

Next Tutorial

In the next tutorial, we will discuss Tagging And Structure In ARIA, which describes the underlying structure in ARIA to communicate the organization and purpose of content to assistive technologies.