Many web developers and designers are asking, “What is ARIA?” Accessible Rich Internet Applications (ARIA) make a website more accessible to people with disabilities.
This concept isn’t new, but not many developers understand it. Fortunately, this article explains what ARIA is, how it works, and how to use it to improve user interaction.
Building ARIA friendly websites starts with a platform that supports clean code, semantic structure and accessibility best practices out of the box. The builders in this table offer features that make it easier to apply ARIA roles, labels and attributes correctly. Check out our recommended website builders here to create a site that delivers a stronger, more inclusive user experience.
Website Builders Designed for Better ARIA Integration
| Provider | User Rating | Recommended For | |
|---|---|---|---|
 | 4.6 | Beginners | Visit Hostinger |
 | 4.4 | Pricing | Visit IONOS |
 | 4.2 | Design | Visit Squarespace |
What is ARIA? An Introduction to Web Accessibility
ARIA means Accessible Rich Internet Applications. It’s a web protocol that helps you make your website more understandable to all users. It works with native HTML, particularly helping assistive technology users.
The Bridge Between Dynamic Content and Accessibility
ARIA makes web content more accessible for people with visual disabilities. It works by empowering assistive technologies that visual impaired users use to interact with websites. Ordinarily, these tools, like screen readers, can’t understand certain web content and applications. And that’s where ARIA comes in.
ARIA attributes describe your web content for screen readers. These tools then present these simplified web pages for visually impaired people.
The World Wide Web Consortium (W3C) introduced the ARIA standards to help people with visual impairment. These suites of web guidelines are particularly helpful for dynamic websites with complex interfaces.
First, developers often build interactive website elements with HTML, JavaScript, and the like to improve user experience. However, these advanced interface components can become a problem for people with disabilities.
Assistive technologies can’t understand these web applications without context. So, people who use these technologies suffer.
But with ARIA, anyone can easily understand your website content. It adds meaning to complex JavaScript widgets, structures, and behaviors. Dynamic content updates, form hints, and error messages become easier to understand.
The current W3C recommendation is WAI-ARIA 1.2, published on June 6, 2023. The W3C approves this document as a web standard after an extensive collaboration with experts.
The 3 Core Components of ARIA
ARIA has three main components that help you create an accessible website. These features are what you add to HTML elements to make them more understandable. You must understand these attributes to help you use ARIA the right way.
1. ARIA Roles: Defining an Element’s Purpose
ARIA roles describe what an element is or what it does to assistive technologies. Just like job descriptions tell people what they ought to do, roles define an element’s purpose. This functionality helps screen readers and related technologies interpret and interact with an element. For example, role=”form” or role=”heading”.
Roles categories include:
- Landmark: Used to identify the structure of a web page. Assistive systems use these roles to provide keyboard navigation around a site. Examples include: banner, main, region, form, navigation, etc.
- Widget: Helps define interactive elements that help users engage with your site. It makes the website interface more intuitive. They include tabpanel, menu, alert, grid, etc.
- Document Structure: Describes the section within a page. It helps screen reader users understand the content of each web page. They include heading, listitem, document toolbar, etc.
An HTML element should only have one ARIA role to avoid confusion. You shouldn’t also change the defined role while users are still using your page. This practice ensures that assistive tools always understand your page.
2. ARIA States: Communicating Current Conditions
ARIA States describe HTML elements that change with user interaction. What this means is that these attributes define the current state of an element, which can change anytime. States can support the existing ARIA role on a web page.
Common examples include:
- aria-checked: Shows the current state of checkboxes, radio buttons, or other widgets (true, false, mixed). For example, aria-checked=“true” means the element is checked.
- aria-disabled: Indicates that an element is visible but not interactive. This specification means that users can’t edit or operate the element.
- aria-expanded: Indicates if a collapsible element is currently expanded or collapsed.
- aria-hidden: Shows whether an element is visible to assistive technologies.
States show real-time changes. When a user clicks a toggle button, the “aria-expanded” should update right away to reflect the new state.
3. ARIA Properties: Defining Relationships and Features
ARIA Properties describe relationships between elements. They provide more context to elements so that assistive tools can better understand. They’re similar to ARIA states in that they support ARIA roles, but are less dynamic. That is, they rarely change.
Key examples include:
- aria-label: Provides an accessible name for an element missing one or lacking a proper descriptive name.
- aria-labelledby: Links two elements by using one’s text to label the other.
- aria-describedby: Links an element to one that provides a better description.
- aria-controls: Identify the elements controlled by another element.
These properties give accessibility technologies more details to understand how elements connect and relate.
Namecheap
How ARIA Works with the Accessibility Tree
As you’ve seen earlier, ARIA makes advanced web applications accessible to assistive tools. It doesn’t generally change a website’s structure for users. Instead, it modifies the accessibility tree for screen readers and other assistive technologies.
Modifying Semantics Without Changing Behavior
When a user requests a webpage, the browser builds a DOM (Document Object Model) as it loads the requested page. At the same time, it creates a related accessibility tree derived from the DOM.
This accessibility tree is what simplifies the advanced user interface controls for assistive technologies. It contains contextual details about each element that users easily understand.
ARIA attributes alter the accessibility tree to define the name, role, state, and relationships of elements. For instance, adding role=”checkbox” to a <span> tells a screen reader it’s a checkbox.
However, it won’t function as one unless you enable it. You’ll need JavaScript and tabindex to add this functionality.
Learning how to create a website with proper structure matters, so ARIA implementation makes sense. A professional website creates the solid foundation that ARIA needs to improve website accessibility.
Practical Code Examples
Below are real-world scenarios where ARIA solves accessibility challenges:
Live Region for Dynamic Content
Aria-live works for dynamic content so that users can get updated content.
<div aria-live=”polite”>Your form has been submitted successfully!</div>
The aria-live attribute makes screen readers announce content changes, without needing users to navigate. The “polite” value means it waits for the user to be idle before it announces.
Custom Progress Bar
For a custom progress bar made with a <div>, ARIA provides the necessary context.
<div role=”progressbar” aria-valuenow=”75″ aria-valuemin=”0″ aria-valuemax=”100″></div>
Without these ARIA attributes, a screen reader would announce “group” or ignore the element entirely. With them, it announces “progress bar, 75 percent.”
Accessible Label for an Icon Button
The aria-label attribute gives an accessible name to a button that only contains an icon.
<button aria-label=”Close dialog”><span class=”icon-close”></span></button>
Visual users see an X icon and understand it closes the dialog box. Screen reader users hear “Close dialog button” and understand the same thing.
Why You Should Use ARIA (and When to Be Cautious)
ARIA can be a powerful tool for enhancing web accessibility, but it’s not always so. A wrong use of any of its attributes can cause problems for users. Imagine something being good and bad; indeed, it’s powerful.
Thus, understanding when to use ARIA is critical for improving accessibility without compromising overall user experience.
Filling the Gaps Where Native HTML Falls Short
ARIA is useful for assisting HTML. But you should only add ARIA attributes when HTML can’t provide the needed accessibility to users. Over 30 ARIA roles and 20 ARIA states and properties exist that describe web elements that HTML alone can’t.
- Roles not in HTML: alert, alertdialog, grid, log, menu, menubar, tablist, switch, tooltip, tree.
- States/Properties not in HTML: aria-activedescendant, aria-atomic, aria-busy, aria-haspopup, aria-live, aria-owns.
When building advanced web applications with custom parts, ARIA becomes necessary. This technical specification makes these elements usable for everyone. For instance, a custom autocomplete widget needs aria-autocomplete, aria-activedescendant, and aria-expanded to work well for screen reader users.
Just like managed hosting keeps your site working well, using ARIA the right way ensures it’s accessible to everyone.
The 5 Golden Rules of ARIA Use
The Web Accessibility Initiative through the W3C provides rules for using ARIA. Not following these guidelines can complicate your web pages for your users.
- Rule 1: The first rule is to always use native HTML, except that it can’t provide the needed accessibility. Standard HTML elements have built-in accessibility features that work well with all assistive technologies.
- Rule 2: Do not change native semantics unless you have to. Native HTML is most of the time enough. For example, don’t add role=”button” to an <h1>. This scenario confuses assistive technology users who expect headings to behave like headings.
- Rule 3: All interactive ARIA controls must be keyboard accessible. Use tabindex=”0″ on elements that need to receive keyboard focus. Anything clickable with a mouse should also be operable using a keyboard.
- Rule 4: Do not use role=”presentation” or aria-hidden=”true” on a focusable element. This phenomenon causes confusion where keyboard users can focus on items they can’t see.
- Rule 5: All interactive elements must have an accessible name. You can use visible text, the aria-label attribute, or the aria-labelledby attribute to describe its purpose.
These rules aren’t random. They come from years of testing with people with disabilities and show how assistive tools really work.
“No ARIA is Better Than Bad ARIA”: A Word of Warning
Using ARIA wrongly will make you wish you had never used it at all. You’ll end up making your website inaccessible to visitors.
Let’s take a look at this survey:
A WebAIM survey of the top one million home pages found that pages with ARIA had twice as many errors as those without. As if that was not enough. The more ARIA attributes were present, the more detected errors increased.
But why is this the case?
Many developers often use ARIA without understanding how it works. If you don’t understand the purpose of roles, how then can you create proper navigation? As a result, their implementation ends up confusing the assisted technologies, they otherwise should be helping.
Always test your implementation with real screen readers (JAWS, NVDA, VoiceOver) and not only automated tools. Use keyboard navigation also to ensure it works correctly.
Just like you must follow web design guidelines to create an attractive site, you must follow ARIA principles to ensure accessibility.
Getting Started with Web Accessibility
Understanding what ARIA is and when to use it is an important first step, but it doesn’t end there. Web accessibility requires a well-structured design from the start. You need a reliable framework that’ll make Aria attributes function well.
Building Your Accessible Foundation
A solid foundation is the core for a functioning site. Without this strong base, you can’t guarantee a usable site for anyone.
The best web hosting is what builds this foundation. It will keep your site fast, secure, and always online for everyone, including those with disabilities.
If you’re new to web development, website builders will work best for you. Hostinger and IONOS are good options that simplify things for beginners. They’re easy to use and offer the right features for creating an accessible site.
As you advance, platforms like WordPress become a necessity. They provide many accessibility plugins and themes that make adding ARIA and other elements easier. But ensure you understand how WordPress works to get it right from the start.
Furthermore, learn UX design principles. This insight will help you design beautiful and easy-to-use interfaces for all users.
Essential Tools for ARIA Validation and Testing
Use automated and manual testing to test your ARIA implementation. You want to catch and fix any errors early enough.
- Browser DevTools: Chrome and Firefox have built-in tools for viewing the accessibility tree. You’ll see the ARIA states, roles, and properties as they appear for assistive technologies.
- Automated Checkers: Tools like axe DevTools catch common ARIA mistakes right in your browser. They identify issues like missing accessible names and incorrect role usage.
- Markup Validation: Use the W3C Nu Markup Checker to check your HTML and ensure you add ARIA attributes correctly.
Additionally, test with real assistive tools. Download NVDA (free for Windows) or use VoiceOver (built into macOS and iOS) to see how screen reader users experience your site.
Using ARIA, like writing alt text, requires understanding context. You need to know how assistive technology users interact with web content.
Conclusion
ARIA is powerful. It helps assistive technologies understand your site to make it usable for people with disabilities. But understanding what ARIA is and how to use it is where the power lies. Follow the guidelines in this guide to implement it properly.
Remember to use semantic HTML first and test your implementation when necessary. Understand what makes a website good to help you build the right foundation for accessibility.
Next Steps: What Now?
Do the following to implement ARIA on your site properly:
- Choose a reliable hosting for your site.
- Understand the three main components of ARIA.
- Start with HTML elements and add ARIA when HTML elements fall short.
- Change native HTML only when necessary.
- Make interactive ARIA controls keyboard accessible.
- Test your implementation before launch.
Further Reading & Useful Resources
Below are additional resources to help you learn more about website accessibility:
- Web accessibility: Discover 10 things every designer should know.
- Best accessibility tools: Discover the best tools for testing website accessibility.
- How to make a website look professional: Learn 15 actionable tips to make your site professional.
- What Is a Sitemap? Learn more about website navigation.
- What is a website widget? Learn types and functions.
- What is responsive design? Learn how to create mobile-friendly sites.
