Blogs

ARIA 101 

By Debra Ruh, Ruh Global Communications, CEO and Rosemary Musachio, CSO

What is ARIA and can it help blend accessibility into your processes?  ARIA stands for Accessible Rich Internet Applications.  It is a  W3C protocol that allows developers to achieve, enhance, and support accessibility of scripted and dynamic content.  ARIA allows the technologist to define ways to make Web content and applications more accessible to everyone, including persons with disabilities. 

According to W3C, “ARIA enhances accessibility of interactive controls (such as tree menus, drag and drop, sliders, sort controls, etc.) provides content for identifying page structure (navigation, search, main content, etc.), areas that can be dynamically updated (called "live regions" in ARIA), better support for keyboard accessibility and interactivity, and much more.”[1]

Why did W3C WCAG create ARIA?

According to the W3C website: “HTML and other markup languages do not provide adequate support for accessible dynamic content. 

WAI-ARIA brings advanced accessibility features of the desktop to the web through the creation of cross-cutting technologies that (X)HTML authors can incorporate in their markup. WAI-ARIA defines roles, states, and properties, which reflect standard GUI elements that are recognized by accessibility Application Programming Interfaces (APIs).  These attributes that describe these GUI widgets and document structures help assistive technology vendors in providing accessible, usable solutions.”[2]  Thanks to ARIA roles and states, screen reader users know the function and status of each component as they reach them.  Due to ARIA properties, they know fixed characteristics of every user interface control.

What problem was W3C WCAG trying to solve by creating ARIA?

Certain aspects of HTML, especially the dynamic content, are more difficult to make and keep it accessible.

Here is a list from W3C WCAG.[3]

1. Accessibility of dynamic content relies on abstracting semantics from both content and presentational information. Extracting semantic cues from current HTML content is typically unreliable as the cues are limited to tag elements names.
2. While HTML allows content to be repurposed for presentational formatting, it lacks the ability to attach meaningful metadata about document structure and to convey semantic information. A common example of this is content formatted with tables rather than style sheets.
3. When combined with script and cascading style sheets (CSS), HTML can be repurposed to create dynamic custom components without providing a means to convey semantic information to native accessibility architectures designed to support dynamic graphical user interface (GUI) content.
4. Custom components built from common HTML elements often are not keyboard accessible.

Authors of JavaScript-generated content do not want to limit themselves to using standard tag elements that define the actual user interface element such as tables, ordered lists, etc. Rather, they make extensive use of elements such as DIV tags in which they dynamically apply a user interface (UI) through the use of style sheets and dynamic content changes. HTML DIV tags provide no semantic information. For example, authors may define an DIV as the start of a pop-up menu or even an ordered list. However, no HTML mechanism exists to:

• Identify the role of the DIV as a pop-up menu
• Alert assistive technology when these elements have focus
• Convey accessibility property information, such as whether the pop-up menu is collapsed or expanded
• Define what actions can be formed on the element other than through a device-dependent means through the event handler type (, , etc.)

In short, JavaScript needs an accessibility architecture to write to such that a solution can be mapped to the accessibility frameworks on the native platform by the user agent.[4]

Although ARIA’s capability to let screen readers convey essential information about user interface controls is great, it does have a limit.  For instance, if a native HTML element is available to convey the same information, use it instead of ARIA.  A common mistake is using aria-label within the label element

<label for=”” aria-label=”name>Name</label>

The screen reader ends up saying “Name” twice.  Instead, ARIA implementation should be used on non-native HTML elements that normally are not for used for user interface controls, such as <ul> elements in the tab example above.  Besides <ul>, other non-native elements that can have ARIA assigned to them include <div>, <span>, and <h#>.

However, with everything else in life, the non-native HTML rule has exceptions.  When a user interface control formed by HTML elements cannot be made accessible due to layout or some other technicality, then AIA should be implemented.  A dilemma that appears often is a heading or even a form field that identifies a group of form fields in a complex data table as Illinois Center for Information Technology and Web Accessibility shows.  If defined as a legend for a fieldset, then the heading or form field would have duel purposes, which complicates the code or confuses the user.  So it’s ARIA to the rescue.  Aria-label is assigned to each of the form fields in the group to associate it with the heading or identifying form field.

It is important to understand that ARIA is still not yet universally supported with existing HTML and scripting accessibility techniques.  Even if ARIA implementation is supported in a browser, some ARIA elements may not function.  For instance, as noted in How Browsers Interact with Screen Readers and Where ARIA Fits in the Mix, JAWS 13 announces ARIA tabs correctly in Internet Explorer and Firefox but not in Chrome.

The good news though is it can provide additional accessibility support where ARIA is supported.  Additionally, ARIA does not interfere AT functionality if browsers do not support it.  It also works with most up-to-date browsers, screen readers, and most scripting libraries.  ARIA does not work as well with older technologies, however.

What problems is ARIA trying to solve?  According to WebAim[5]:  “In general, accessibility issues with rich internet applications can be characterized as:

• Inability to provide the semantic structure of page areas and functionality (e.g., navigation, main content, search, etc.)
• Inaccessibility of content that is dynamic and may change within the page (e.g., AJAX content updates)
• Inability to change keyboard focus to page elements (e.g., setting focus to an error message within the page)
• Difficulty with keyboard and screen reader accessibility with complex widgets and navigation elements (e.g., sliders, menu trees, etc.)”

ARIA provides a set of accessibility attributes that can be added to any but is very helpful with HTML.  ARIA is particularly helpful for sites developed with Ajax and JavaScript.  ARIA can help the developer create and enable navigation landmarks, JavaScript widgets, form hints and error messages, live content updates, and more fully accessible content.

ARIA has three main components.

1. Roles
2. Properties
3. States

Roles: ARIA roles define what an element is or does. Most HTML elements have a default role that is presented to assistive technology. For example, a button has a default role of "button" and a form has a default role of "form". With ARIA, you can define roles that are not available in HTML. You can also override HTML's default roles. This allows you to present elements and widgets in HTML to screen readers in a more accurate and accessible way.  An example of an ARIA role is <form role="search">. In HTML, all forms have the same semantics.  With ARIA, however, you can add to the semantics of a particular form to define it as the search form.[6] 

Properties: ARIA properties define characteristics of elements that do not change with user interaction.  An example is <input aria-required="true">.  The field is always required regardless if users interact it or not.  You can extend HTML's native semantics by defining properties for elements that are not allowed in standard HTML. This property will cause a screen reader to read this input as being required (meaning the user must complete it).[7]

States: ARIA states define the current condition of an element.  They generally change based on user interaction or some dynamic variable. An example is <input aria-disabled="true">. This property will cause a screen reader to read this input as being disabled, but this state value could easily be changed to false dynamically based on user input.  ARIA roles, states, and properties can be defined in markup or they can be defined and dynamically set and changed using scripting. ARIA states and property attributes always start with "aria-" (e.g.,aria-required="true"). [8]

ARIA allows developers to address accessibility challenges by defining how information can be provided to assistive technology.  It can also help developers to create dynamic and robust web content and applications that are accessible to all users including users of assistive technology and persons with disabilities.

For more information about here is a list of resources.

Resources:

http://www.w3.org/WAI/intro/aria

https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA

http://webaim.org/techniques/aria/

http://www.w3.org/WAI/intro/aria.php

https://www.w3.org/TR/wai-aria-primer/#ref_ARIA-PRACTICES

https://www.w3.org/TR/wai-aria-primer/#ref_ARIA-ROADMAP

https://www.w3.org/TR/wai-aria-primer/

#AXSChat: Join Neil Milliken, Antonio Santos and myself for a weekly Twitter Chat on Disability Inclusion, ICT Accessibility, Built Environment, CRPD, and Employment. Just search the hashtag #AXSChat at 3pmEST and join the conversation.  You can learn more about AXSChat at www.AXSChat.com.

Learn more about our work at www.RuhGlobal.com or follow us on Social Media @debraruh, @rosemusachio, @kevinruhglobal, @emilyruhglobal and @ruhglobal on most social media channels.