WHAT Is ARIA And WHAT Problems Does It Solve?

What is ARIA?

WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) or ARIA for short as will be used in this training is a technical specification published by World Web Consortium (W3C) that defines new ways for advanced web content and advanced user interface controls or components, especially those developed with Ajax and JavaScript (e.g., an accordion) to provide interaction with assistive devices (e.g., screen readers) so that it can be used by people with disabilities.

HISTORY: The phrase Rich Internet Application (RIA) was first used by Macromedia (now Adobe) in 2002 and represented web based applications that have “the richness of the desktop with the reach of the web.” ARIA is an extension of this with the “A” add to the “RIA” for accessibility.

What Problems Do ARIA Solve?

HTML uses JavaScript to make a web application dynamic. However, this may introduce a lot of UNKNOWN content to assistive technology:

  1. Unknown components functionality or behavior
  2. Unknown components’ states and properties
  3. Unknown keyboard accessibility or focus
  4. Unknown dynamic content changes

ARIA solves that problem of unknown content by describing how to INJECT a set of semantic attributes INTO native HTML content to make user interface controls and dynamic content more accessible to users with disabilities especially those with visual impairment that use a screen reader. These attributes help assistive technology IDENTIFY roles, states, properties, and relationships with user interfaces components as will be discussed later.

NOTES:
  • This is the same process that developers use for many JavaScript frameworks (e.g., jQueryMobile, BootStrap, AngualarJS to name a few) and CSS where attributes are added to HTML elements (e.g., <a href =”mylink.html”>Mylink</a>) to extend or enhance their functionality.  So, ARIA should not be hard for most developers using these technologies to embrace, understand, and use.
  • ARIA does not modify any HTML element inherent behavior. It only EXPOSES EXTRA INFORMATION to assistive devices. However, ARIA does modify the accessibility tree for any element.

WHERE Is ARIA Use?

ARIA is intended to be used with or used in:

  • Modern browsers (e.g., Firefox, Chrome - build into the browser as an accessibility API)
  • Mobile devices (e.g., iOS, Android - can be used with the WebView component in mobile devices)
  • Screen readers (e.g., JAWS, NVDA - screen readers use accessibility tree that is created by ARIA)
  • JavaScript libraries (e.g., jQuery, BootStrap - injected into popular Javascript frameworks)

WHY Should You Use ARIA?

ARIA provides the FRAMEWORK for:

  • Adding ADDITIONAL attributes to identify page elements for user interaction (e.g., identify regions like menu, primary/secondary content, footer, banner, etc.). Regions allow a user to quickly move among page regions rather than having to press the Tab key repeatedly.
  • Helping users manage interactive content (e.g., widgets (alert, progress bar), menus, list box, etc.)
  • Determining how page elements relates to one another (e.g., aria-describedby)
  • Determining page elements current state (e.g., enabled/disabled or collapsed/expanded)
  • Mapping controls, AJAX live regions, and events to accessibility API.
  • Hiding elements if semantics is not required.
  • Extend the tabindex attribute to any element.

WHEN Should You Use Or NOT Use ARIA?

WHEN Should You NOT Use ARIA?

Whenever you can use HTML5 do so. HTML5 has added several useful semantic elements and attributes (e.g., nav, menu, required, checked) so that is may not be necessary to use ARIA if the semantics is already available in HTML5.

EXAMPLES:
You should use the HTML5 disabled and required states over ARIA aria-disabled and aria-required unless you are still using HTML 4.01 in which ARIA is not recognized.

NOTE: HTML5 has the required attribute, but aria-required is still useful for user agents that do not yet support HTML5.

In the example below, ARIA is not needed because standard HTML attributes will AUTOMATICALLY communicate semantics information to the assistive technology:

<label for=”agreeToTerms”>Agree To Terms</label>
<input type="checkbox" id=”agreeToTerms” required" />

The type=”checkbox” (role) and the required (property) attributes communicate to the assistive device that it is a checkbox and that is required. Since the checked attribute is NOT specified (state), the default state will be unchecked. Here, we see role, property, and state being used or implied without any ARIA.

Instead of an <input> and <label> element, you could have used:

  • a non-semantic <span> element and style it with CSS to make it look like a checkbox
  • role=”checkbox”
  • aria-required=”true”
  • aria-checked=”false”
  • add a tab-index to make it tabable to a keyboard only user
  • some JavaScript to it to make it behave like a checkbox.
<label for="agreeToTerms">Agree To Terms</label>
<span id="agreeToTerms" role="checkbox" aria-required="true" aria-checked="false"></span>

NOTE: Tab index and JavaScript not shown.

But why!!!—That would be stupid to do. When you can simply use a standard semantics element and attributes to accomplish the same task without any ARIA at all. You can always style a native element with CSS to make it look the way you want and still retain the implicit semantics and behavior.

NOTE: It is important to note that ARIA roles have SUPPORTED states and properties. In the above example, the checkbox is the role, aria-required is the role's property and, aria-checked in the role's state. So, when properties or states change through user interaction, ARIA will notify the assitive device that a change has been made.

WHEN Should You Use ARIA?

If there is a HTML element or attribute already available but it is NOT accessible, then you can use ARIA.
First, determine if you can use native semantic HTML elements because for the most part they will provide focus, keyboard accessibility, and built-in semantics. However, there are times when creating a custom component (e.g., pop-up-menu), there is NO HTML element that will provide the semantics needed for it to communicate with an assistive technology (e.g., screen reader).

NOTES:
  • It is important to note that certain HTML elements restricts what type of ARIA roles and attributes that can be added to it. For example, <input type="text"> cannot have any additional ARIA role/attribute applied to it. (VERIFY THIS STATEMENT)
  • Since ARIA is ONLY recognized by assistive technology, it can be used without risk if you use it correctly.