This article first appeared in issue 231 of .net magazine – the world's best-selling magazine for web designers and developers.
When you create a User Interface (UI) widget it’s likely to be a composite of HTML elements. Generally speaking it’s easy for someone to work out what the widget does, or what role it plays within the page, based on the way it looks or the controls it makes available. That holistic perspective isn’t obvious to assistive technologies (ATs) though, and that (of course) is where ARIA comes in.
ARIA, or Accessible Rich Internet Applications to give it its full title, can be used to give your widget a role. Or to look at it another way, you can use ARIA roles to tell ATs something about your bundle of HTML elements as though they were a single entity.
The ARIA 1.0 specification includes a taxonomy of roles. It describes the characteristics and properties of 73 different roles, grouped into four high level categories.
The first category defines 12 abstract roles. In the same way that abstract classes are never instantiated when programming, abstract roles should never be used within your code. They describe different types of role at a conceptual level, and so they’re used only within the taxonomy itself.
Roles
One abstract role stands apart from the rest. The role (abstract role) is the base role from which all other roles in the taxonomy inherit. Other abstract roles include the input (abstract role), landmark (abstract role), and widget (abstract role).
Let’s take the widget (abstract role) as an example. It describes an umbrella role, under which all other widget roles in the taxonomy sit. Here’s how it’s described in the ARIA specification:
“An interactive component of a Graphical User Interface (GUI). Widgets are discrete user interface objects with which the user can interact.”
This leads neatly to the next category, which defines 34 widget roles. Widgets are interactive controls that can either stand alone, or be combined to create more intricate UI components. Nine of these roles define containers that can be used to encapsulate other widgets to form more complex controls.
The remaining 25 roles define widgets that can be used independently or as part of a complex composite control. An element with the role of tablist can contain multiple elements with the role of tab, for example. When used in conjunction with a corresponding set of elements with the role of tabpanel, they combine to form a composite tabbed interface. Elements with roles such as alert, checkbox or dialogue can also be part of a more complex UI control, or they can stand alone.
The third category defines 18 document structure roles. These roles describe typical content formations such as heading, list, and toolbar. Unlike widget roles, document structure roles are not interactive as a rule.
The last category defines eight landmark roles. They can be applied to different sections of a web page, providing landmarks that ATs can use to navigate by. Roles within this category include banner, main, and navigation.
Discover the 20 best wireframing tools for designers at Creative Bloq.
