An important and recent addition to the family of accessibility standards created by the W3C is WAI-ARIA. This acronym stands for “Web Accessibility Initiative,” the W3C subgroup that created the standard, and “Accessible Rich Internet Applications,” the name of the standard itself. In this book, we touch on WAI-ARIA without going into much detail. It is primarily aimed at developers who create custom web applications and widgets using non-standard HTML. For example, a developer might create a checkbox out of an HTML
<div>element. WAI-ARIA allows a developer to assign checkbox semantics to that
<div>, like its role (i.e.,
role="checkbox") and its state (i.e.,
aria-checked="false"), so when it is encountered by an assistive technology, the technology recognizes that
<div> as a checkbox.
You were indirectly introduced to some of the semantics described in the paragraph above in Activity 1. As you were navigating through the Showcase demo website, you would have heard a number of WAI-ARIA elements announced by your screen reader.
As part of this book, just knowing of the existence of WAI-ARIA will be sufficient. Here, we will provide an overview of how it works and when it should be used, along with an example you can try with your screen reader to develop a little practical experience with it.
Static vs. Dynamic WAI-ARIA
Though primarily aimed at developers and programmers, there is some WAI-ARIA that can be used in a static form. That is, a person writing HTML can write WAI-ARIA right into the HTML. The landmark navigation elements you were introduced to earlier is one example of a static use of HTML. These landmarks are a type of role, specifically used to define regions on a web page. There are eight landmark roles, listed here.
WAI-ARIA Landmark Roles
- menubar (defines a role for a container, typically a top level list, where multiple submenus are present)
- menu (the role assigned to each submenu)
- menuitem (the role assigned to each item in a submenu)
- aria-haspopup (assigned to menu items that are the parent of a submenu that can be opened)
- aria-activedescendant (the ID value of the menu item that is currently active)
- aria-describedby or aria-labelledby (refers to the ID of an element containing a description of the menu or instruction on how to operate it)
- aria-expanded (when a menu item’s submenu is open, aria-expanded is set to “true”; otherwise, it should be set to false)
- aria-hidden (set to true to hide inactive submenus; set to false when a submenu is displayed)
When to Use WAI-ARIA
It is important to understand when and when not to use WAI-ARIA. If incorrectly used, it can create more problems than it resolves. Any standard uses of HTML do not need WAI-ARIA. For example, an HTML
<form> does not need its role defined as a form (i.e.,
role="form"). It already has this role defined by default.
As described above, if a developer wanted to create a custom checkbox using a
<div> element, in that case,
role="checkbox" would be added as an attribute of the
<div>. Assistive technologies would then recognize the
<div> as a checkbox. That said, however, when there is an HTML element that serves a particular purpose, like a checkbox, it is generally better to use the standard checkbox rather than creating a custom one.
When navigating through the menu examples above, you may notice that the list semantics of the second menu are suppressed in the first menu. In this case, replacing the list semantics with menu semantics is desired. On the other hand, if HTML headings were being used as headers in a collapsible menu, adding the
role="menu" attribute to the heading would suppress the structural semantics associated with the heading. This potentially upsets the structure of the document and removes headings as a means of navigation.