Mastering ARIA Accessibility for a More Inclusive Web
Ready to see AudioEye in action?
Watch Demo
ARIA accessibility refers to roles and attributes that overcome accessibility issues that cannot be addressed by HTML alone. Learn more about ARIA roles and attributes below.
Given how much emphasis is placed on the user experience today, it’s surprising more attention isn’t paid to the accessibility barriers impacting the 1.3 billion people globally who live with a disability. Yet, certain web functionalities prevent users, particularly those who rely on assistive technologies such as screen readers or voice-to-text, from accessing parts of the web.
The problem? HTML.
Previous versions of HTML (such as HTML5) failed to provide an accessible experience for those using screen readers or other assistive technologies. For example, many websites lacked the tags to describe certain parts of the user experience, creating accessibility issues.
To break down accessibility barriers, the Web Accessibility Initiative (WAI) group created Accessible Rich Internet Applications (ARIA).
What is ARIA?
Put simply, ARIA (also known as WAI-ARIA) is a set of roles and attributes that can be added to HTML code. They're used to describe certain components of the user interface that don’t have semantic tags in HTML. ARIA was designed to make inaccessible parts of the web more accessible to those using assistive technologies.
For example, older versions of HTML did not include tags that could describe web elements such as menus or progress bars. This is problematic for users who cannot view the screen. ARIA resolves this by creating roles like “menu” or “slider image” to describe widgets on the page.
ARIA is composed of three main components: roles, states, and properties.
Roles
The purpose of ARIA roles is to provide semantic meaning to web content. More simply, roles describe web elements that don’t exist in HTML (i.e. role=”role_name).
For example, say a web page has a panel with multiple clickable tabs. HTML does not include roles for this web element, which creates an accessibility issue. ARIA adds a role to this element (<ul role="tabpanel">) so it can be read and announced by screen readers. This eliminates the accessibility issue and ensures disabled users understand what’s on the page.
There are six types of ARIA roles:
- Abstract roles: These are the foundation for other ARIA roles and provide meaning for other roles.
- Document structure roles: Document roles provide descriptions for specific sections on a web page.
- Landmark roles: Similar to document structure roles, ARIA landmarks identify a web page's overall structure and organization and allow users to skip to specific parts of a web page. These ARIA attributes can be added to applications, banners, forms, headers, or search bars.
- Widget roles: These describe interactive elements on the site. These include elements such as buttons, checkboxes, or radio.
- Live region roles: Live region roles help inform assistive technology users about changing content on a web page.
- Window roles: These roles help in creating a sub-window within a webpage and ensuring they’re readable by assistive technology.
States and Properties
States and properties are typically used together to support ARIA roles. ARIA states can change on their own or with user interaction (i.e. aria-checked and aria-disabled) and are typically used with JavaScript. ARIA properties, on the other hand, rarely change once set (i.e. aria-labelledby and aria-describedby).
The four categories of ARIA states and properties include:
- Drag-and-drop attributes: These attributes inform assistive technologies about drag-and-drop elements and their targets. Some examples of drag-and-drop ARIA tags include aria-dropeffect and ariagrabbed=true.
- Widget attributes: These are commonly used for UI elements that receive user input and process those actions or information. Some examples include aria-complete, aria-checked, aria-labeled, aria-expanded, etc.
- Relationship attributes: Relationship attributes add relationships between elements that could otherwise not be determined by assistive technologies For example, aria-described by and aria-labelledby help screen readers understand when information is related to successful page navigation.
- Live region attributes: This indicates to users when a change in content has occurred. For example, if a message will be read aloud with the flow of content (i.e. aria-live=polite”) or will interrupt the flow of content (i.e. aria-live=assertive”).
Common Uses for ARIA
The WAI has provided several examples for using ARIA in HTML elements. Some of these include:
- Descriptive labels
- Alerts
- Relationships
- Forms
- Breadcrumbs
- Message dialogs
- Grids
- Menus, menu buttons, or menu bars
- Sliders
- Tables
- Popups
- Links
- Carousels
- Listbox
ARIA in HTML
As mentioned above, ARIA attributes can be added to HTML elements to enhance accessibility. For example, you can pair ARIA with HTML in web patterns that need more assistive technology support due to environmental constraints.
Don’t override default HTML roles and reduce redundancy when using ARIA in HTML. It’s also important to be aware of unintentional side effects. Below, we’ll look at ARIA authoring practices to ensure proper application in HTML:
Example #1
Don't:
<a role="heading">Read more</a>
This assigns users the wrong role and creates a confusing experience for users.
Do:
<a aria-label="Read more about some awesome article title">Read More</a>
This ensures the right user is assigned the right role. The extra link description also better explains what’s happening on the page.
Example #2
Don't:
<button role="button">...</button>
This is a good example of redundancy in HTML. The “button” element is already exposed and informs readers of a button on the page. While this may not have unforeseen side effects for users, it can create unnecessary distractions.
Do:
</button>...</button>
This removes the redundancy and improves usability.
Example #3
Don't:
<summary role="button">more information</summary>
...
</details>
This creates unforeseen side effects that can hinder accessibility.
Do:
<details>
<summary>more information</summary>
...
</details>
This eliminates potential side effects.
ARIA Accessibility Guidelines
Before you start using ARIA, it’s important to understand how to apply the rules of ARIA. They’re based on the guidelines provided by the Accessible Rich Internet Applications Working Group of the WAI in the Authoring Practices 1.2 specification.
Prioritize Using Native HTML Elements
Opt for using native HTML elements in all situations unless it’s absolutely necessary to do otherwise. Native HTML is the default choice for accessibility and should be used as much as possible.
Keep Native HTML Semantics Intact when Possible
Native HTML elements typically meet accessibility needs effectively, so altering their semantics should be a last resort.
Ensure Keyboard Accessibility for All Interactive ARIA Controls
To ensure keyboard users can easily navigate a page, ensure interactive elements have tabindex=”0”. This ensures they’re appropriately integrated into logical keyboard navigation sequences.
Avoid role=”presentation” or aria-hidden=”true” on Focusable Elements
Using these attributes can cause navigation issues for some users and create confusion when users focus on elements with no discernible content.
Assign Accessible Names to All Interactive Elements
All parts of a website should be navigable, including interactive elements. Ensure all input fields have an accessible name property with a value — this helps assistive technologies identify them.
Align ARIA Roles with User Expectations
When using ARIA roles, such as defining a <div> element like a “button”, it’s crucial to match the behavior and interactions that users expect from these roles.
Utilize ARIA for Enhancing Accessibility Semantics
ARIA attributes play a critical role in conveying the purpose and meaning of UI elements to assistive technologies. However, these roles must be used correctly to avoid overriding inherent accessibility semantics.
What is the Difference Between WAI-ARIA and WCAG?
WAI-ARIA and the Web Content Accessibility Guidelines (WCAG) play an essential role in creating accessible web applications and content. However, WCAG and ARIA cover various parts of accessibility.
WCAG, for example, provides recommendations based on how content should be created to be accessible to people with disabilities. WAI-ARIA, on the other hand, is more about how developers can create content that conforms with WCAG. More simply, ARIA is about providing technical solutions that meet accessibility guidelines and principles and ensure web content is accessible to as many people as possible.
To learn more about WCAG conformance, check out our post on WCAG 2.2 compliance.
How Accessibility Testing can Help You Meet ARIA Guidelines
The first step to increasing your site’s accessibility is uncovering where existing accessibility barriers exist. This is done with accessibility testing or accessibility audits.
Accessibility testing takes an in-depth look at your site and uncovers where accessibility issues are. Most accessibility checkers provide recommendations on how to resolve issues; some even provide real-time fixes.
There are several benefits to conducting accessibility testing, including:
- Delivering an inclusive, user-friendly experience to everyone: The web should be accessible to all — regardless of their background, circumstances, or ability. Accessibility testing helps you achieve this by highlighting accessibility issues and how to create a more accessible design.
- Reduces legal risk: Accessibility testing decreases the chances of someone pursuing legal action against your company for lack of accessibility. With regular accessibility testing, you can take proactive steps to resolve accessibility issues, decreasing the chances of legal action being taken against you.
- Enhances SERP ranking and brand reputation: Enhancing accessibility creates a more usable experience for your users, which can increase your SERP rankings. Well-structured content, appropriate alt text for images, and closed captions for videos all improve your site's usability. This increases the number of customers who use it, boosting your ranking on search engines and your overall reputation.
Keep Up Compliance Efforts with AudioEye
Following ARIA accessibility guidelines is only half the battle. Website accessibility is an ongoing journey — one that requires regular testing, maintenance, and monitoring.
With the help of AudioEye’s digital accessibility platform, your journey is made easier than ever. Whether you’re looking to use ARIA attributes to enhance accessibility or uncover common accessibility issues, AudioEye has you covered.
Get a free website scan to discover where you can improve your site’s accessibility.
Book a free demo to see how AudioEye uses both automated and expert testing to break down accessibility barriers.
Frequently asked questions
Ready to see AudioEye in action?
Watch Demo
Ready to test your website for accessibility?
Share post
Topics:
Keep Reading
How to Test a Website for Accessibility: Quick Test Guide
Testing your website for accessibility doesn't have to be overwhelming. Discover quick ways to test your digital content for accessibility in this quick test guide.
accessibility
December 02, 2024
Web Accessibility Consultants: How the Human + Automation Approach Affords Maximum Protection
Regular web accessibility consultants help with remediation, compliance and legal challenges. Find out how AudioEye's approach goes a step beyond.
accessibility
November 29, 2024
WCAG 2.0 vs. 2.1: What’s the Difference?
Discover the key differences between WCAG 2.0 and 2.1. See how the updates impact web accessibility and how you can meet the latest standards to ensure compliance.
accessibility
November 20, 2024
