What is WAI-ARIA?
A set of attributes for filling accessibility gaps
Dynamic content can be especially challenging for users who are unable to view a screen. Live updates, progress bars, and personalization can modify the DOM in ways that assistive technology can’t detect. That's where ARIA comes in. By further defining attributes like roles and states, assistive devices can better determine what the element is. This in turn allows the user a better understanding of relationships between elements, the state of an element, and how to interact with it.
A compliment to HTML semantics
Semantics are the implied meaning of a subject, and in our case, HTML tags. HTML tags serve both humans and machines by suggesting the purpose of the content enclosed within the HTML tag. Examples include H1-H6 tags to notate headings, and LI tags for list items. HTML5 introduced semantic tags whose purpose is to do nothing but help better identify the contents they contain. These tags don't replace generic container divs, but compliment them by adding semantic meaning. ARIA can be used with both HTML5 and XHTML.
A W3C Specification
What isn't WAI-ARIA?
ARIA has no effect on how page elements are displayed or behave in browsers. ARIA as a specification is designed as a descriptive layer for screen readers, added right into your HTML code. An example of this is a button: a “real” button element has added keyboard focusability, an automatic click handler, or other properties that are inherent to the button element. A “div” with the button role will still need all of this additional functionality coded in to make it as accessible as the native button element. That said,“if you can use a native HTML element [HTML51] or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state, or property to make it accessible, then do so.” http://www.w3.org/TR/aria-in-html/
OK, this could go either way. Some people call it a Band-Aid meaning that the use is really just covering up the underlying accessibility problems in the code. What I’m saying here is to NOT use ARIA in this manner. Don’t add ARIA just because you can. Just like all of your code, use it sparingly, where it will make the most impact for assistive technology. Jared Smith talks about it in his excellent post “Accessibility Lipstick on a Usability Pig”: “As ARIA is increasing in popularity, it is quickly becoming the accessibility lipstick of choice. And some sites are smothered in it, yet beneath it all, they are still just pigs. While ARIA is a powerful tool for filling the accessibility gaps for screen reader users, if all you have is an ARIA hammer, everything starts to look like a nail.”
A replacement for good coding practices
As previously stated, adding ARIA support to a web page will not change the behavior or presentation of the pages to sighted users, so all of your clean, semantic code will have a positive effect on ALL of your users. Using semantic structure first, with a dash of ARIA thrown in as needed will give your site’s visitors the best experience.
Examples of WAI-ARIA
Most of the ARIA specification is intended to be used in web applications. ARIA attributes are defined in the specification and are divided into roles, states, and properties.
Roles are used to describe the structure of the web page. Roles can also act as navigational landmarks, and roles can also describe the type of widget presented. For more information and a complete list of ARIA roles, visit the W3C ARIA Roles page.
Properties often describe relationships with other elements and for the most part, do not change once they’re set. Properties describe characteristics of these widgets, such as if they have a required component, or have a pop-up associated with them. For more information and a complete list of ARIA states, visit the W3C ARIA Properties page.
Practical Use of WAI-ARIA
ARIA landmarks are attributes you can add to page elements to define areas of content or navigation. When you add these attributes, it allows screen reader users the ability to move around from section to section of your page and know where they are going.
Always use a label element whenever possible. It’s still the most supported technique for screen reader support. Use aria-describedby in cases where you’ve exceeded the information presented in the label element, like additional instructions for filling out a form field.
aria-describedby is also useful for providing summary information for tables. If you happen to have a page that uses a table for layout purposes (we can talk about how it’s not recommended, later) then you could add role=presentation to remove the native semantics from the table, the table row, and the table cell. This will aid in hiding the table structure from assistive technologies.
In our August webinar, we’re going to talk about the basics of WAI-ARIA and when you should or should not use it. We’ll go over a few examples and how WAI-ARIA will affect all your users. This webinar will be more code-focused than our usual webinars.