The ARIA Roles Model Part 1

Posted: 13 Jul 2015 05:30 AM PDT

What can you do when the native semantics of the HTML you use don't communicate enough information or they don't communicate appropriate information to assistive devices? You use ARIA roles, states, and properties to communicate the semantics instead.

title — A UML diagram of the ARIA roles model

Last week I began a look at WAI-ARIA. I talked about why ARIA exists and offered a quick introduction to the three ways you can communicate semantics using it. Then I walked through a simple example using roles, states, and properties to add semantics to a non-standard checkbox.

I want to talk in more detail about all three over the next two weeks. I want to look at the taxonomy behind the roles model and their supported states and properties. I'll start today with roles. Next week I'll finish talking about the roles model and then talk about supported states and properties.

Similar to the principles and guidelines of the Web Content Accessibility Guidelines (WCAG), the number of roles, states, and properties are too many to walk you through each individually. Instead I'll again point you to resources where you can find the details. Consider this more of an overview of ARIA to make it easier to find and understand those details.

Assuming my skills counting and performing simple math are good, there are a total of 73 different ARIA roles, which is a lot to try to memorize, especially when you add in the states and properties of each.

Fortunately ARIA roles, states, and properties are organized in a taxonomy called the roles model. Understanding this taxonomy can help us understand the purpose of each role and which states and properties are available to it.

ARIA Roles

Adding an ARIA role to an HTML element overrides the native semantics of the element. Adding an ARIA role won't change how an element looks or works, but it does change the semantics communicated to assistive devices.

Pretend you want to create a button. For some reason you can't use a button element and you decide to use a span instead. Unfortunately spans aren't buttons, so you write CSS and Javascript to make the span look and function like a button.

You code is still a non-semantic span to assistive devices, though. To communicate that the span should be treated like a button you can add a role of button that includes the proper semantics for screen readers.

1	<span role="button">Click Me</span>

Adding the role provides assistive devices information about how to interpret and treat the element. Assistive devices receive a description of the role along with the states and properties the role supports.

Also communicated are hierarchical relationships with related roles such as the treegrid role being a subclass of the grid role. Assisted devices also receive information about a role's context so they understand a gridcell should be inside a row. The hierarchy allows for semantic inheritance between roles as well.

And since specifications beyond WAI-ARIA exist, references to related concepts in other specs are also communicated though the role.

One thing to note is that roles are element types and their values should not change over time. If something should carry the semantics of the button role, then it should always carry those semantics. If you want to change the role, you should remove the element and it's descendants and replace them with a new element and new descendants with the appropriate semantics.

Relationships Between Concepts

ARIA roles are based on concepts outside of ARIA and they're organized into a taxonomy of classes, superclasses, and subclasses. The UML (Unified modeling language) diagram at the top of this post shows the taxonomy. Click on the image for a larger view. You might want to keep it open in another tab while you read.

Don't worry if the organization makes no sense at first glance. It should by the time you finish reading next week's post.

If you look in the top left of the roles model diagram, you'll find the range role (just to the right of composite). It includes four aria-* attributes, which I think you'll agree make sense for something called range.

aria-valuenow
aria-valuemin
aria-valuemax
aria-valuetext

One of the subclasses of range is the slider role (directly below range in the diagram). Subclasses inherit all the attributes of their superclass, so the four attributes for range are also attributes of slider. Slider then adds one additional attribute, aria-orientation.

Roles have base concepts that serve as prototypes. For example the the base concept for the button role is an HTML button. There is no inheritance from base concept to role. If the definition of an HTML button were to change, it wouldn't affect the ARIA button role.

Roles also have related concepts. They share similarities, but they aren't identical. For example buttons and links are similar. You can click each and something will happen. They're not the same thing, but they are similar. Related concepts do not inherit properties from each other so changing one doesn't affect the other. A new definition for a button would have no effect on the definition for a link.

Characteristics of Roles

The characteristics of a role define and describe the role's place in the interface, its structural function, the concepts behind it, and the supported and required attributes it contains. The roles taxonomy defines eight characteristics that are communicated for each role.

Abstract Roles
Required States and Properties
Supported States and Properties
Inherited States and Properties
Required Owned Elements
Required Context Role
Accessible Name Calculation
Presentational Children
Implicit Value for Role

Abstract Roles are the building blocks for the other roles. Content authors shouldn't use them. User Agents shouldn't do anything with them. The spec goes as far to say that you must not use them.

They exist to help:

Organize the role taxonomy and provide roles with a meaning in the context of known concepts.
Streamline the addition of roles that include necessary features.

I'll talk a little more about abstract roles next week when we look at how all the roles are categorized.

Required States and Properties are those states and properties that must be set for a given role. For example a checkbox without checked and unchecked states isn't much of a checkbox so the aria-checked state is required for the checkbox role and it must be set.

Supported States and Properties are those available to the role. Content authors can add them, but they don't have to. Supported states and properties have default values and authors may rely on them instead of explicitly setting a value.

Since all these states and properties should be available to content authors, user agents are instructed that they must map them to an accessibility API.

Inherited States and Properties are those that are inherited from a superclass role in the roles taxonomy and not from an ancestor element in the DOM.

They're inherited and not explicitly defined on the role. The inheritance is automatic. Combined with supported states and properties they form the complete list of states and properties. In other words all attributes of a role are either inherited or explicitly supported.

Required Owned Elements are a little more complicated to explain. Some elements only exist inside other elements. For example a listitem will always be contained inside a list. The listitem is thus a required owned element of a list.

Some roles will have several required owned elements. For example a menu should have at least one instance of a menuitem, menuitemcheckbox, or menuitemradio. All three are required owned elements in that they need to be contained in a menu. The menu isn't required to use all of them. It need use only one, but it must use at least one.

Required Context Roles are like required owned states in reverse. For example listitems only make sense inside a list so a list is a required context role for a list item role.

When a role has a required context you must ensure it's contained inside (owned by) the required context role. The required context role is the owning role and the required owned element is the role being owned.

Accessible Name Calculation are names user agents use to convey information to assistive devices. These names can come from the author of the content or the content itself.

Authors can explicitly name elements through properties like aria-label and aria-labbelledby to make clear the name of the element being labelled.

The text of the element may also be used by the user agent in addition to the name set by authors and in some cases can be used in lieu of the name set by content authors. If you're interested the link a couple paragraphs back will give you details about the calculation.

Presentational Children are children of an element that are there for presentation only. They have no semantics to communicate and user agents shouldn't expose them though an accessibility API.

Implicit Values for Roles are non-standard default values. Many states and properties have default values, but sometimes these defaults should be different based on the role that uses them.

The role indicates this through an implicit value, which creates a new default. If an author explicitly sets a value it overrides either the natural default or the implied value for the role.

Closing Thoughts

The roles model is a taxonomy for organizing all the ARIA roles, states and properties. Roles are organized hierarchically through classes, superclasses, and subclasses. The hierarchy establishes relationships between different roles and provides a mechanism for semantic inheritance.

Roles can have a variety of characteristics including required, supported, and inherited states and properties, which brings us to next week's post.

Next week I'll look more at the supported states and properties after finishing this discussion about roles. I'll talk about the four types of roles that are used to categorize all roles.

Download a free sample from my book Design Fundamentals.

The post The ARIA Roles Model Part 1 appeared first on Vanseo Design.