Static vs. Dynamic WAI-ARIA

Even if you don’t use JavaScript, there is a good amount you can do with static WAI-ARIA to improve the accessibility of a website or web application. You may have already gathered from the discussion of states and properties that some WAI-ARIA can be written right into the HTML of a web page (e.g., properties and landmarks). Others need to be dynamically updated based on user input or context (e.g., states and some properties).

Some of the static WAI-ARIA attributes you are likely to use are listed below, with their descriptions from W3C.

Global Static Properties

• aria-describedby: Identifies the element (or elements) that describes the object.
• aria-labelledby: Identifies the element (or elements) that labels the current element.
• aria-label: Defines a string value that labels the current element.
• aria-controls: Identifies the element (or elements) whose contents or presence are controlled by the current element.
• aria-owns: Identifies an element (or elements) in order to define a visual, functional, or contextual parent/child relationship between DOM elements where the DOM hierarchy cannot be used to represent the relationship.
• aria-details: Identifies the element that provides a detailed, extended description for the object.

Below is an example of some of these attributes in action. Though this example would need some scripting to handle the submenu opening and closing, and dynamically updating aria-expanded to false when the submenu is closed, and update the active element referenced in aria-activedescendant, you can get an idea of the semantics that are being applied to make the nested list announce itself as a menu. Watch or listen to the screen reader output in the video that follows the code box below to understand how the WAI-ARIA attributes are read. Examine the code in the code box to understand what WAI-ARIA is being used to produce that output.

How Does the Above Markup Work?

1. Navigating with the Tab key, focus first goes to the "menu_container" div, which is made keyboard focusable with the tabindex="0" attribute.
2. There the screen reader reads the content of the “chooser” div, identified by aria-details, describing what the menu is used for. This div is hidden from view but available to screen readers. This div could be made visible to make it available for everyone.
3. Next, the “offerings” UL receives focus, also made focusable with tabindex="0".
4. There, the screen reader reads the content of the “navhowto” div, identified by aria-describedby, explaining how to navigate the menu. This div is hidden from view for most users.
5. Next, using the Arrow keys as instructed by the “navhowto” div, the ‘Home’ menuitem takes focus, announcing “menubar expanded with submenu, Home, menu”. Probably a little more verbose in this case than it needs to be, but that’s how ChromeVox handles menu items.
6. Using the Down Arrow key, focus is moved to the “Courses” menu item, announcing “Courses, menu expanded with submenu.” The aria-haspopup attribute is what causes a screen reader to announce a submenu. aria-expanded="true" causes the screen reader to announce that the menu is expanded.
7. Using the Down Arrow, focus moves into the submenu, announcing “Menu with two items, Economics, menuitem 1 of two.” The submenu is announced as a menu of its own, identified by adding role="menu" to the UL containing the two submenu items.
8. Finally, using the Down Arrow, the screen reader announces “Computer Science, menuitem two of two.”

Here’s a video that shows how ChromeVox would read out the menu described above:

Video: Example Menu with WAI-ARIA (0:33)

Most of the WAI-ARIA elements described in the above series of steps can be used statically by typing the attributes right into the HTML. The aria-activedescendant would typically be dynamically updated with script as the menuitems are selected. The aria-expanded would also be updated dynamically switching between true and false when the submenu is toggled opened or closed.

Here are some more static WAI-ARIA attributes, which we’ll look at in a little more detail later as you complete the activities.

Widget Static Attributes

• aria-haspopup: Indicates the availability and type of interactive popup element, such as menu or dialog, that can be triggered by an element.
• aria-modal: Indicates whether an element is modal when displayed
• aria-readonly: Indicates that the element is not editable but is otherwise operable.
• aria-required: Indicates that user input is required on the element before a form may be submitted.

Live Static Regions

• aria-live: Indicates that an element will be updated and describes the types of updates the user agents, assistive technologies, and user can expect from the live region.
• aria-atomic: Indicates whether assistive technologies will present all, or only parts of, the changed region based on the change notifications defined by the aria-relevant attribute.
• aria-relevant: Indicates what notifications the user agent will trigger when the accessibility tree within a live region is modified.