Introduction to understanding WAI-ARIA 1.0 Roles

Preface

This is not a coding introduction to help you get started in using WAI-ARIA 1.0 Roles in your websites/web applications, therefore do not expect to see code examples.

This introduction to understanding WAI-ARIA 1.0 Roles is my attempt to explain what effects the WAI-ARIA 1.0 Roles have/do to your HTML Markup, so that you will use the correct WAI-ARIA role for the specific scenario.

Introduction

I’ve seen and read a number of tutorials on WAI-ARIA 1.0, all of them only go over the basic code syntax, none have gone and explained what exactly WAI-ARIA does; expecting their readers to have already read the WAI-ARIA 1.0 specification. Therefore in this article, I would like to fill that void.

What is WAI-ARIA

WAI-ARIA is a technical specification that provides a framework to improve the accessibility and interoperability of web content and applications.

The WAI-ARIA specification is divided into two groupings; roles (the type defining a user interface element) and states and properties supported by the roles.

In this article I will only be looking at the roles component.

What are WAI-ARIA Roles

WAI-ARIA Roles are a set of defined roles web content creators and developers can use in their custom widgets to inform assistive technologies what exactly their custom widget/content is, allowing assistive technologies to interpret the custom widget/content correctly.

What does applying a WAI-ARIA Role do to an HTML element

Attaching a role gives assistive technologies information about how to handle each element.

This basically means, when you add a role to an HTML element, you are telling assistive technologies to ignore whatever the default roles/events the HTML element had and interpret the HTML element as if it was an element based on the new role.

For example:

Applying role="link" to an HTML element will tell assistive technologies to ignore whatever the HTML element is and treat it as a link. So for a screen reader, when it comes across the HTML element, it will announce ‘Link’.

And also by changing the role of the HTML element, the new role behaviours are also required to be handled, in this case:

Navigate the user to another page/screen when it is clicked on or the enter key is pressed with it in focus.

What types of WAI-ARIA Roles are available

The WAI-ARIA Roles are categorised into 4 groups:

  1. Abstract Roles (Only used for ontology, should not be used in web content)
  2. Widget Roles
  3. Document Structure Roles
  4. Landmark Roles

For the list of specific roles available, I suggest you have a look at The Roles Model.

What’s a correct usage of a WAI-ARIA Role

The correct usage of WAI-ARIA Roles differs between each role, the only way to correctly use a role is to read the requirements for that particular role and satisfy all the outlined requirements. This is because each role is unique and therefore cannot be generalised. Which is one of the purposes of having the roles in the first place.

What’s a incorrect usage of a WAI-ARIA Role

Unfortunately, unlike its nemesis, there are many ways you could incorrectly use WAI-ARIA Roles and when you do incorrectly use WAI-ARIA Roles, you do a lot more harm than good. Therefore it is advised to avoid applying an WAI-ARIA roles to an HTML element until you are sure it’s the correct role to use and have covered all the requirements required by the role.

When you are misusing WAI-ARIA Roles, think of it as like telling your potential customer over the phone you have a mini-bus, where in actual fact you have a two-seater convertible.

Conclusion

WAI-ARIA roles all have a unique role to play and unless you are using the simpler LANDMARK or DOCUMENT STRUCTURE roles; I highly recommend you refer to the role definitions section of the WAI-ARIA 1.0 specification whenever you are planning to use a WAI-ARIA role to ensure you use the appropriate role and cover all additional role entailed requirements.

Bonus note

Native semantic HTML elements already include appropriate events handling and have an implied role, therefore, use a native HTML element whenever possible to avoid re-inventing the wheel and creating a load of unnecessary work for yourself and others.

You may also like to read my articles: Native HTML Controls and Accessibility and HTML Semantics and Accessibility