The ARIA Roles Model Part 2

Posted: 20 Jul 2015 05:30 AM PDT

There are a lot ARIA roles, states, and properties to remember. Add in all the details of each and it's unlikely you're going to memorize all of ARIA. I suspect most of us will need to look things up more often than not. Fortunately the roles model can help us do just that.

title — A UML diagram of the ARIA roles model

Last week I started talking about ARIA'a roles model. I talked in general about the taxonomy behind the model, how roles are organized in a hierarchy, and how different roles are related to each other. I closed last week's post talking about the different characteristics of roles.

Today I want to continue talking about the roles mode, specifically how roles are organization into four categories. Then I'll talk about the supported states and properties of roles and how these attributes are grouped and organized.

Categorization of Roles

I mentioned a few times last week that the ARIA roles model is a taxonomy and in part that means grouping them all under different categories. ARIA roles are divided into four major categories.

Abstract Roles
Widget Roles
Document Structure Roles
Landmark Roles

Abstract Roles are used to define general role concepts. There are 12 in total and they serve as the building blocks for all of the other roles. If you look at the roles model diagram at the top of this post, you'll see there's a widget role, a structure role, and a landmark role (the other three categories) and all three are abstract. Each serves as the base type for a group of roles.

Abstract roles are used by browsers and offer no additional semantics to assistive devices. You won't ever use them. In fact the spec explicitly states authors must not use abstract roles in content and the words "must" and "not" are bold and entirely in capital letters so you know it's really important.

Widget Roles are used for interface widgets and there are 34 widget roles in total. They can describe complete widgets in and of themselves or be component parts of a composite widget. For example cells in a grid would get the role gridcell, while the complete grid would get a role of grid.

Widget roles are even divided into those that act as standalone items in an interface and those that act as composites, usually containers for the standalone widgets. To give you an idea what's considered a widget, here are the nine roles for composite widgets.

combobox
grid
listbox
menu
menubar
radiogroup
tablist
tree
treegrid

The other 25 widget roles are standalone widgets like a progressbar or something like a gridcell meant to be used as a component inside a composite widget.

Document Structure Roles are about content. There are a total of 19 of them and they describe the structures that organize content on a web page. They are generally not interactive, but some could be.

Two of the roles I mentioned when talking about HTML5 sectioning elements, article and region, are included in this group. In an ideal world you would use the article element (article role) or the section element (region role), however not all browsers currently support the mapping, so for now you probably want to use both the element and role. In time we'll be able to skip the redundancy.

Landmark Roles exist to help assistive devices navigate web pages. There are 8 landmark roles in total and they help define the big picture structure of your page. Five of the eight will be familiar to you if you read my aforementioned series on HTML5 structural elements.

Since there are only eight I'll list them all here.

application
banner
complementary
contentinfo
form
main
navigation
search

All content on a webpage should be inside a container with a landmark role that makes the general region accessible. The role might be communicated through native HTML, but either way the semantics should be there. It helps make every piece of content on your web pages navigable.

Stop for a moment about these categories. One of them, abstract, you won't ever use. Of the other three, landmark roles describe the more general and higher level parts of your layout, your main page header and footer, your main content area, and any sidebars you might have.

These general parts will be filled with content (document structure roles) and interactive widgets (widget roles). A few of the landmark roles like navigation, and search might be thought of more as components within the layout, but as they're usually included on every site, they can be considered as higher levels parts of the layout.

Supported States and Properties

As we saw last week, one of the characteristics of all roles is that they support certain attributes. All roles have supported states and properties, some of which are required, and some of which are inherited from a superclass role.

States and properties refer to similar features. Both describe the objects they're applied to and contribute to the definition and nature of the role. While they're similar, there are some differences to distinguish one from the other.

The values of properties are less likely to change than the values of states, which will change with user interaction. For example if you associate a checkbox with a label you wouldn't expect the label to change so properties like aria-label and aria-labelledby would remain constant.

On the other hand checkbox is sometimes checked and sometimes unchecked so a state like aria-checked is expected to change. Some properties like aria-valuenow are also expected to change often lessening the distinction.

Another difference is that properties are essential to the nature of a given object. Changing a property could significantly alter the meaning or presentation of an object. States on the other hand don't affect the essential nature of an object, but represent data associated with it.

You'll find both referred to as ARIA attributes. Like roles they're added as attributes to HTML elements and they all take the form aria-*

1 2	<span id="check" role="checkbox" aria-required="true" aria-checked="false" /> <label for="check">Check Me (required)</label>

Here checkbox is the role, aria-required is a property of the role, and aria-checked is a state of the role. When states (and some properties) change their values through user interaction, such as checking and unchecking a checkbox, screen readers are notified of the change.

There are a total of 10 states and 35 properties and like roles I don't expect either of us to memorize them all. Here are the states.

aria-busy
aria-checked
aria-current
aria-disabled
aria-expanded
aria-grabbed
aria-hidden
aria-invalid
aria-pressed
aria-selected

Hopefully the names alone are enough to know that the values of any of them can and likely will change.

Value Types of States and Properties

The values of all states and properties will be one of the following types. I assume most are self-explanatory, but where you might not (ok where I didn't know) the specific definition, I added it.

true or false
tristate (true or false with an intermediate "mixed" value)
true, false, or undefined
ID reference (of an element in the same document)
ID reference list (a list ID references)
integer
number
string
token (limited set of allowed values)
token list (list of tokens)
URI

An undefined value is often allowed as an explicit declaration that a state or property isn't set.

Taxonomy of States and Properties

Like roles, states and properties are grouped into four base attribute types, each with a number of specific states and properties.

Widget Attributes are specific to common graphic user interface elements and rich internet applications that receive user input and process user actions. Most states are widget attributes. In fact, 7 of the 10 total states are widgets states.

An example of a widget attribute is aria-required for any input that's required and an example of a widget state is aria-checked to indicate whether a checkbox is checked, unchecked, or mixed.

Live Region Attributes are for live regions in rich internet applications and they can be applied to any element. There are four live region attributes, one of which, aria-busy is a state.

Live region attributes exist to indicate that content changes may occur on an element, even when the element doesn't have focus. They also provide information to assistive devices for how to process the content updates.

An updating stock ticker is an example of a live region. Updating sports scores or weather information are also good examples.

Drag-and-Drop Attributes provide information about drag-and-drop interface elements. There are only two attributes, aria-dropeffect, which is a property and aria-grabbed, which is a state.

The aria-dropeffect property indicates what can happen when a dragged object is dropped on the target area. The aria-grabbed state indicates if an element has been grabbed or is capable of being grabbed.

Relationship Attributes specify relationships or associations between elements which cannot be easily determined from the document structure alone.

For example to know how many columns a gridcell spans you would need to first know the entire structure of the grid. The aria-colspan property can communicate the information as soon as the gridcell is encountered.

All 14 relationship attributes of ARIA 1.1 are properties.

Global States and Properties

Of the 45 total attributes, 18 of them are global, because they're applicable to all elements regardless of whether a role is applied. These 12 properties and 6 states are supported by all roles and by all base markup elements.

Global states and properties are applied to the roletype role, which is an abstract role that all other roles inherit from.

If you were adding up the numbers I mentioned for each group of attributes you may have notice they add up to 43 and not 45. That's because two of the attributes are global only and not included in any of the attribute groups.

aria-current (state)
aria-describedat (property)

Closing Thoughts

Roles are organized into four major groups, abstract, widget, document structure (or just structure) and landmark. I think the groupings make it a little easier to understand the purpose of each role.

Abstract roles are not to be used by content authors. Landmark roles are for the big picture areas of your layout and widget and structure roles are for what's inside the landmark elements.

All roles have supported states and properties or attributes when they're talked about together. They differ in that states are usually for interactive parts of the page that may change. Some states and properties will be required for a given role and some will be inherited from a superclass.

Like roles, states and properties are organized into four major types, with some attributes also considered to be global. Like roles you don't need to memorize the details of each. Instead make sure to bookmark the pages listing them all so you can quickly find the details you need.

I have one last post in this series before moving on to another topic. Next week I want present some general guidelines for working with ARIA as part of how to use ARIA when writing HTML.

Download a free sample from my book Design Fundamentals.

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