ARIA Made Easy

ARIA Topics Covered

Introduction

As you are developing web-based technologies here at the University of Arizona you should utilize as much accessible technology and tools that you can to ensure the widest accessible experience for all of our users. ARIA is one way to accomplish this task. This document is designed to guide you in the use of ARIA and to point you to a wealth of additional resources where you can learn more.

First of all, what is ARIA? The W3C defines ARIA as:

WAI-ARIA, the Accessible Rich Internet Applications Suite, defines a way to make Web content and Web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies. Currently certain functionality used in Web sites is not available to some users with disabilities, especially people who rely on screen readers and people who cannot use a mouse. WAI-ARIA addresses these accessibility challenges, for example, by defining new ways for functionality to be provided to assistive technology. With WAI-ARIA, developers can make advanced Web applications accessible and usable to people with disabilities.

You should assume when developing your sites that users will be utilizing up-to-date screen reading technology that conforms to the use of ARIA.

Note We would like to thank WebAIM for allowing us to use some of their material for this document.

Developing With ARIA

While this document will be a guide to ARIA we would strongly suggest that you review the WAI-ARIA Authoring Practices and the WAI-ARIA Primer documents to get even more familiar with ARIA as it relates to authoring web sites and web-based applications.

Rule #1: Don't use ARIA!

ARIA is intended as a Band-Aid when standard HTML controls and markup cannot be used. Whenever possible do not use ARIA but use accessible based HTML programming techniques. For example, if you have an item that acts like a button but isn't coded as one then reconsider the implementation to use a standard HTML button tag. We fully understand that this is not always possible and for that reason ARIA was adopted as a standard to fill in the gaps.

Screen Reader Accessibility and Browser API and how it relates to ARIA

When a screen reader looks at an element it can get at certain properties of an object. Some of these are:

Role
Name
Description
Value
State

Let's take the example of a checkbox:

<input type="checkbox" value="Subscribe” id="sub"> <label for="sub">Subscribe?</label>

<input type="checkbox" value="Subscribe” id=" sub"="">Subscribe?

The screen reader would see these properties:

Role=checkbox
Name=Subscribe?
Description=
Value=subscribe
State=checkable, checked

ARIA Roles

ARIA helps define the roles, Names, Values and States of objects that screen readers can understand. The real purpose is to remap the native Role of an element into something that you have re-purposed the element to do differently. For this reason ARIA glues the screen reader and your code together. ARIA simply tells the screen reader that this object is a button but provides no functionality to support the action of a button. For example if you define a paragraph of text to act like a button when clicked with the mouse and you tell the browser that this paragraph is a button then the appropriate keyboard hooks need to be programmed to ensure proper accessibility. For example:

<p role="button"> This is a paragraph marked up as a button as far as ARIA is concerned.</p>

This is a paragraph marked up as a button as far as ARIA is concerned.

This paragraph will look to a screen reader as a button but there is no functionality in code to make it act like one. Keep this in mind when using ARIA. ARIA is only changing the role of an object, not its functionality.

Avoid duplicating roles. If an object is already a button there is no need to use ARIA to tell it that it is a button:

<button role="button">Example Button</button>

Use ARIA roles wisely. One reclass of a control could make accessibility nearly impossible for screen reader users. Take an example of a checkbox:

<input type="checkbox" role="radio">

While functionally this will look and act like a Checkbox the screen reader will think it is a Radio Button.

ARIA and Code Validation

ARIA attributes were added to validation checkers at the W3C for HTML 5 documents. If your code validates without ARIA and the ARIA markup is correct then consider your document valid. This of course only applies to HTML 4documents as HTML 5 documents should validate just fine.

Defining Landmarks/Regions on your Web Pages for easier navigation

ARIA defines these roles for easier navigation by screen readers:

Note: These are taken from the ARIA specification.

banner: A region that contains the prime heading or internal title of a page.
complementary: Any section of the document that supports the main content, yet is separate and meaningful on its own.
contentinfo: A region that contains information about the parent document such as copyrights and links to privacy statements.
form: A region of the document that represents a collection of form-associated elements, some of which can represent editable values that can be submitted to a server for processing.
main: Main content in a document. In almost all cases a page will have only one role="main".
navigation: A collection of links suitable for use when navigating the document or related documents.
search: The search tool of a Web document.
application: A region declared as a web application, as opposed to a web document. (note: The role of application should only be used with caution because it gives a signal to screen reading software to turn off normal web navigation controls. Simple widgets should generally not be given the application role, nor should an entire web page be given the application role, unless it is not to be used at all like a web page, and not without much user testing with assistive technology.)

If you have multiple landmarks of the same type use aria-label to label the landmark appropriately.

HTML 5 tags that also provide navigation should be given ARIA roles whenever possible. For example if you want to use the HTML5 nav element, add role="navigation" to it:

<nav role="navigation">

ARIA States and Properties

All ARIA properties and states begin with aria in their name. If a property or state is used then ARIA always wins as far as a screen reader is concerned. Here are some samples:

<input aria-checked="true">

<a aria-expanded="false">View details</a>

<a aria-haspopup="true">Open dialog</a>

<input aria-labelledby="foo">

<div role=slider aria-valuemin=0 aria-valuemax=100 aria-valuenow=10>

Earlier we talked about how one attribute can cause problems for accessibility. This still stands so be very careful if you are injecting JavaScript to change these values dynamically.

ARIA Labeling Techniques

Here are a few things to remember when using ARIA labeling techniques:

Always use HTML label techniques whenever possible to ensure the widest accessible experience.
Remember that the <label> tag can only label one field.
The aria-label attribute can label anything, not just form fields.
The aria-labelledby attribute can use the id from another area where text is shown to be used as a label for multiple controls. You can concatenate multiple labels into one label if desired by separating each id by a space inside of the attribute.
The aria-describedby attribute is used to provide a description of an element.

Here are some examples of labeling techniques:

Standard HTML label

<label for="CompanyName">Company Name:</label>

<input type="text" id="CompanyName">

Company Name:

Note: Remember that <label> can only be used on form fields.

ARIA Labels can label a control as well

<input aria-label="Company Name" id="CompanyName">

Note: The aria-label attribute can label anything you wish.

ARIA labeling can label more then one field

<p id="mylabel">Customer Name</p>

<input type="text" id="cust1" aria-labelledby="mylabel">

<input type="text" id="cust2" aria-labelledby="mylabel">

Customer Name

Multiple labels can be used on one field

<p id="JeffName">Jeff Bishop</p>

<p id="JeffOfficeNumber">520.626.1145</p>

<input type="text" name="Jeff1" aria-labelledby="JeffName JeffOfficeNumber">

Jeff Bishop

520.626.1145

An example of providing more descriptive text for a form field

<label for="pass">Password:</label>

<input type="password" id="pass" aria-describedby="passworddetails">

<p id="passworddetails">Password must be at least 8 characters in length and contain one number and one punctuation symbol.</p>

Password:

Password must be at least 8 characters in length and contain one number and one punctuation symbol.

Defining Required and Invalid Form Fields

Form validation and accessibility can be a tricky thing to implement. ARIA addresses this area by allowing you to set the aria-required and aria-invalid attributes. Let's first address the required attribute:

Required Fields and ARIA

Many web sites use an asterisk and color to determine which fields are required. Many screen readers may not speak the asterisk if punctuation settings are not enabled in their screen reader of choice.
Showing required fields using color may also create problems for those users that are color blind.
Set the aria-required attribute to true on those fields that are required in your forms.
Using asterisk (*) and color are fine as long as you use the aria-required attribute.
Many sites will also put "(required)" as a part of their form field label to also show which fields are required. While much of this is redundant it also ensures that multiple paths are available to determine if a form field is indeed required.
This attribute can be dynamically updated in code using JavaScript.
It is strongly suggested that if you are going to use the aria-required attribute that you code your style sheets to act on this attribute's value. Thus, you can handle the styling of required fields based on the ARIA attribute.

<input aria-required="true" type="text" name="CompanyName" id="CompanyName">

Marking up Invalid Fields with ARIA

As for the aria-invalid attribute:

Use the aria-invalid attribute to mark those fields that are currently invalid (badly formatted data for example).
This attribute can be dynamically updated in code using JavaScript. Be careful on how this is implemented though. It is suggested that validation take place on the onblur event or some other strategy and not on keypress events inside of the field.
It is strongly suggested that if you are going to use the aria-invalid attribute that you code your style sheets to act on this attribute's value. Thus, you can handle the styling of required fields based on the ARIA attribute.

<input aria-required="true" aria-invalid="true" type="text" name="CompanyName" id="CompanyName">

Marking up your Links

The following rules should be considered when defining your links on your page:

Ensure all interactive elements are keyboard focusable and actionable. Make sure all links work across all devices. For example, don't assume mouseover events will be enough.
Ensure a visual indication of interaction and state is available (:focusin CSS).
Each link should have an associated href attribute. If it does not then the screen reader will consider the link text and not a link.
Be careful with the use of the aria-label attribute. Remember, ARIA attributes always win. This means that the aria-label attribute will overwrite the text of the link that is presented for the screen reader. In some cases this may be desired, just be cautious in your implementation.

Tabindex - Friend or Foe

The tabindex attribute should be avoided unless you really know what you are doing with it on your web pages. The following rules should be considered:

If the default tab order is not logical, fix your source code order.
tabindex="1+" defines an explicit tab order. This should be avoided.
tabindex="0" allows things besides links and form elements to receive keyboard focus. Setting the elements tabindex to 0 places it in the order of the page. You may want to do this for items like text that should be seen by screen readers when filling out forms. Other techniques are also possible and should be used (such as aria-describedby).
tabindex="-1" allows things besides links and form elements to receive programmatic focus (by scripting, links, etc.). Setting the tabindex to -1 will remove the ability to tab to the element using the keyboard. Using the -1 technique should be used for error messages, dialogs, etc.
Ensure all interactive elements are links or form controls, or make them focusable with tabindex=”0”.
Test your keyboard tab order with and without a screen reader. Just using a screen reader isn't good enough.
If using tabindex, detect Enter and Space key events.

Web Based Applications and the Application Role

As we move to more applications on the web that act like desktop applications we have had to rethink how screen readers interact with the web. A screen reader works with a web page by rendering the page in a document like structure. The screen reader vendor supplies navigation keys to move around in this virtual document to get at web based elements. As web-based applications have developed we have needed a way to tell the screen reader that we need you to interact with this page like it were a desktop application. ARIA fulfills this requirement with the role of application. When this is encountered the screen reader turns off all virtual document keystrokes and treats the page like it were a Windows desktop application. The following rules should be considered when using the application role:

Use the application role wisely. For example, do not put it on the body tag of your web site.
Some elements have an implied application role: Treeviews, Sliders, interactive tables, grids, Tab Controls, dialogs, Toolbars, Menus and Menu Items.
Define the role closest to where it is needed.
To turn off application mode set the role of the closest element outside of the interactive area to document.

Hiding content on screen from Screen Readers

You can hide content from screen readers by using the aria-hidden="true" construct. This should be used with caution. We implemented this on the UITS Net ID Plus pages to rename the help buttons from question marks to "Help". Here are two links from Codepen that show examples of how you might re-label buttons for screen readers:

ARIA Alerts

From the W3C:

The alert role is used to communicate an important and usually time-sensitive message to the user. When this role is added to an element, the browser will send out an accessible alert event to assistive technology products which can then notify the user about it. The alert role is most useful for information that requires the user's immediate attention, for example:

An invalid value was entered into a form field.
The user's login session is about to expire
The connection to the server was lost, local changes will not be saved

Using the alert role on an element implies that that element has aria-live="assertive".
The alert role should only be used to for static text content. The element that the alert role is used on does not have to be able to receive focus, as screen readers will automatically announce the alert regardless of where keyboard focus is currently located.
If an alert also provides interactive controls (such as form controls that allow the user to rectify a problem, or an "OK" button that discards the alert) the alertdialog role should be used instead.

ARIA Live Regions

Screen readers are designed to focus the users attention on one specific area of a web page. This means that if meaningful changes take place on the page somewhere else and it is vital that the user be aware of this then you either need to move the users focus to the notification or provide an alert or notification using a live region. If an alert is triggered using an ARIA live region then the screen reader user will be notified immediately no matter where they are on the page. The aria-live attribute has three distinct values:

Off - no notification.
Polite - screen reader notifies user once current task is complete.
Assertive - screen reader interrupts current task to notify user.

Caution: Make sure you use this technique sparingly and wisely.

Resources

Screen Reader Resources

General Resources

Conclusion

If you would like more information on ARIA please contact us at itaccess@email.arizona.edu.