The Internet is supposed to be accessible to everyone. Unfortunately, some attributes make this a challenging task, especially for users with disabilities. It’s because of website HTML where the code used does not provide enough information for assistive technologies to understand. This is where ARIA helps by describing accessible user interface elements and components that assistive technologies can understand. However, some people may not understand the attributes and role of ARIA in enhancing website accessibility. This is where we at ADA Site Compliance can help. Our team of accessibility experts will help and guide you to properly use ARIA to ensure website compliance.
What is ARIA?
ARIA is the acronym for Accessible Rich Internet Applications and is a specification of the Web Accessibility Initiative of the World Wide Web Consortium. It provides the HTML attributes that supplement HTML to help assistive technology understand complex interactions commonly found in today’s websites and web technologies.
What can ARIA do?
ARIA helps share relationships between placement and design to assistive technologies like screen readers. The four key characteristics they convey are:
Roles convey the page structure, like headings, search fields, banners, sidebars, and the main content to users. They describe what interactive elements are or what they do, and once set, they don’t change. They are perfect for defining roles unavailable in HTML and overriding default HTML element roles.
There are a total of four ARIA roles categories:
- Landmark roles that help assistive technology users with navigation. It helps the user navigate the web page by identifying the different parts of web pages, like forms and applications.
- Document roles used for describing the page’s content structure, like lists, images, and headings. It does not work much at describing content on the entire page.
Abstract roles form the base roles for other WAI-ARIA roles, like the abstract roles of foundations.
Relationships tell users the relation between places and include descriptions, instructions, and information about the next element.
States are used to define an interactive element’s current state. For example, it defines if the element is disabled, busy, selected, or hidden. As a result, states are often dynamic and can change individually or because of another user’s interaction.
ARIA properties provide vital additional contexts or semantics for user interface elements that standard HTML does not support. They thus do not change after once set.
How Drupal uses ARIA
The Accessibility Initiative started in Drupal 7 led to major advancements in core and contributed modules for delivering accessibility to all users. They include:
With accessibility being the top priority for the Drupal community, it has various built-in core accessibility features.
With its jQueryUI auto-complete feature, users can auto-complete form fields once they start typing into a field on a web page. They fill up the form fields with the help of previously entered data.
Fieldsets in the Form API organize related sections in forms into sub-sections. Checkbox and radio button groups are automatically grouped in field sets, while other elements are also grouped in a field set.
Inline form errors
The inline form errors added to each form field make completing forms all the easier.
Drupal uses HTML5 elements and ARIA to deliver semantic meaning to content. The AT users can use their browser customization feature to navigate the web without being forced into what’s set for a specific site.
Keyboard accessibility through tabs
Drupal’s Tabbing Manager provides a solution to users who use a keyboard to navigate the web by allowing developers to use the aria attribute in its controlled tab to add or remove tab constraints from a page.
Views are useful for adding multiple ARIA attributes and more descriptive labels to an HTML element. Once you open view, you will be able to select a field and open the ‘Rewrite’ section.
The many contributed modules in Drupal offer additional accessibility features and functionally complement built-in features.
Block ARIA landmark roles
Site builders can add landmark roles to any block on the site.
The module adds an abbreviation button to the Rich Text Editor toolbar that, when clicked, creates an accessible abbreviation at the user’s cursor location.
With this module in the user’s keyboard, users can toggle the site’s high-contrast view, especially for users with visual disabilities.
This module is for users with low vision, where it adds a tool with a block that lets the user resize the text as per their needs. The tool comes with increased and decrease text size buttons.
ARIA Accessibility Guidelines
Understanding the ARIA accessibility guidelines based on the ARIA Working Group guidelines.
1. Use native HTML elements where possible
While ARIA is for filling gaps in HTML4, web authors prefer using the right semantic HTML element instead of ARIA role, state, or property.
2. Meet the user’s ARIA role expectations
Ensure the ARIA role you use behaves as it should.
3. ARIA is to add and not remove accessibility semantics
Assistive technologies depend on accessibility semantics to understand the meaning and purpose of user interface elements. Proper ARIA helps provide accessibility semantics while anything wrong overrides it.
ARIA provides the info in two ways. The first is by cloaking the original content, while the second option is to add more meaning.
ARIA Accessibility examples
While the WAI offers an entire state of web standards for using ARIA in HTML, some examples support aria amount of roles, states, and properties, including:
- Alert and message dialogs
- Menus and their bars or buttons
5 ways to use ARIA for improved Web Accessibility
When properly used, ARIA can improve accessibility for screen readers and other assistive technologies. However, if not properly done, ARIA can create digital accessibility barriers. Here are a few tips to appropriately use ARIA:
1. Use semantic HTML instead of WAI-ARIA
It’s not always ARIA that makes your website accessible to assistive technology users. It’s the last choice available because assistive tools may implement ARIA differently.
HTML5 is a better choice while authoring for accessibility as it describes most web elements’ functionality. ARIA may be the better choice if your website has complex functionalities.
It is also better to work with accessibility experts like ADA Site Compliance if you need to use ARIA to ensure its proper implementation. Besides, ARIA can improve your website, but it is a significant investment and requires expertise. Switch to HTML if a new HTML tag equals an ARIA role.
2. Don’t change native semantics
ARIA roles provide content with semantic meaning to help assistive tools predictably and intuitively present interactions. It doesn’t provide as much detail as semantic HTML. And ARIA is better for content without appropriate HTM semantics.
3. ARIA controls should be usable with only a keyboard
As most ARIA technologies rely on keyboard navigation, keyboard accessibility is essential. The user will use another method for interacting with the ARIA control if it doesn’t support keyboard navigation.
4. Double check ARIA syntax
Misunderstandings are often the cause of ARIA mistakes. For example, ARIA roles are better written in lowercase because not all browsers and assistive devices can interpret ARIA roles in uppercase letters. So the best option would be to test with multiple devices and software to decide if your ARIA roles conform to standards.
5. Using WAI-ARIA will not always make your site accessible
Developers implement ARIA-to-author content that works perfectly with screen readers and other assistive technologies. However, this doesn’t imply that adding ARIA makes your site more accessible. Besides, there is the risk of your site creating serious banners with improper ARIA implementation.
Make it a habit to audit your content periodically if you use ARIA. And these audits should be conducted using automated accessibility scans and manual tests. In the case of manual tests, it should include various assistive tools, browsers, and operating systems.
And with ARIA implementation, you need to test for common accessibility issues like poor color contrast usage and improper semantic HTML5 implementation.
Multiple WAI-ARIA versions
As of date, there are now two completed WAI-ARIA versions:
- WAI-ARIA 1.0 was published in 2014 as a completed W3C Recommendation.
- WAI-ARIA 1.1 was published in 2017 as a completed W3C Recommendation
- WAI-ARIA 1.2 is in the developmental stage, with many new features to help with ARIA and web accessibility.
Frequently Asked Questions
Normally, you may have more questions to ask about ARIA and its role in web accessibility. Here are some of the most common questions we are periodically asked.
What is the role of ARIA in achieving accessibility?
ARIA is the acronym for Accessible Rich Internet Applications and comprises a set of attributes and roles. These roles and attributes define ways to make web content and applications much more easily accessible to people with disability.
What is the purpose of an ARIA?
ARIA comprises an attribute set essential in making websites accessible to users with disabilities who use assistive technologies to read website content. ARIA bridges any gaps in accessibility issues that native HTML cannot complete.
What is the ARIA label used for accessibility?
The ARIA label provides the ARIA required for a label for objects to be ready by assistive technology. This attribute provides the necessary text label for any element, like a button. So whenever a screen reader encounters the object or button it reads the aria-label text. This way, the screen reader user knows what its objective is.
What are the consequences of the implementation of WAI-ARIA in older browsers?
Generally, the WAI-ARIA coding methods do not affect how older browsers project their web content. In browsers that do not support WAI-ARIA attributes, web content adding WAI-ARIA attributes will continue to work as it always did on the browsers.
ARIA is undoubtedly important for website accessibility. However, it is also a very deep technical specification that not everyone can handle. It is better if someone who knows all about ARIA handles it.
We at ADA Site Compliance have in-depth knowledge about ARIA roles, states, and properties. Our accessibility experts will strive to make them as useful as possible for your website’s optimal web compliance.
Speak With An Expert Now
Have a question?
We’re always here to help.
The ADA prohibits any private businesses that provide goods or services to the public, referred to as “public accommodations,” from discriminating against those with disabilities. Federal courts have ruled that the ADA includes websites in the definition of public accommodation. As such, websites must offer auxiliary aids and services to low-vision, hearing-impaired, and physically disabled persons, in the same way a business facility must offer wheelchair ramps, braille signage, and sign language interpreters, among other forms of assistance.
All websites must be properly coded for use by electronic screen readers that read aloud to sight-impaired users the visual elements of a webpage. Additionally, all live and pre-recorded audio content must have synchronous captioning for hearing-impaired users.
Websites must accommodate hundreds of keyboard combinations, such as Ctrl + P to print, that people with disabilities depend on to navigate the Internet.
Litigation continues to increase substantially. All business and governmental entities are potential targets for lawsuits and demand letters. Recent actions by the Department of Justice targeting businesses with inaccessible websites will likely create a dramatic increase of litigation risk.
Big box retailer Target Corp. was ordered to pay $6 million – plus $3.7 million more in legal costs – to settle a landmark class action suit brought by the National Federation of the Blind. Other recent defendants in these cases have included McDonald’s, Carnival Cruise Lines, Netflix, Harvard University, Foot Locker, and the National Basketball Association (NBA). Along with these large companies, thousands of small businesses have been subject to ADA website litigation.
Defendants in ADA lawsuits typically pay plaintiff's legal fees, their own legal fees for defending the litigation, and potential additional costs. In all, the average cost can range from tens of thousands of dollars, to above six figures. There are also high intangible costs, such as added stress, time and human capital, as well as reputational damage. Furthermore, if the remediation is incomplete, copycat suits and serial filers can follow, meaning double or triple the outlay. It's vital to implement a long-term strategy for ensuring your website is accessible and legally compliant.