One of the core aspects of the ARIA system is its collection of roles.
As we learned in lessons 3 and 4, a role, an accessibility term,
amounts to a shorthand for a particular UI pattern.
ARIA provides a vocabulary of patterns we can use via the role attribute on
any HTML element.
When we applied role=checkbox in the example earlier, we were telling
assistive technology that the element should follow the checkbox pattern.
We're promising that it will have a checked state, either checked or
not checked, and that the state may be toggled using the mouse or
via the space bar.
If we followed the advice in earlier lessons,
we've already kept part of that promise by implementing keyboard behaviors.
In fact, since the keyboard interactions feature so
prominently, it's very important to make sure that when creating a custom widget,
the role attribute is always applied in the same place as the tabindex attribute
so that keyboard events will go to the right place and so that when page focus
lands on an element, its role is conveyed accurately.
The ARIA spec describes a taxonomy of possible values for
the role attribute and associated ARIA attributes which may legally be used in
conjunction with those roles.
This is the best source of truth when it comes to understanding how the ARIA
roles and attributes all work together and
may be used in a way that is supported by browsers and assistive technologies.
It's well worth browsing through the list of roles linked from the instructor
notes, since there's a finite vocabulary of roles which can be used and
each one has specific semantic implications.
Also, in this screenshot,
we can see that certain roles are designated as abstract.
These capture certain properties which may be common to several roles, but
may not be used as values for the role attribute.
The ARIA spec also has a section on each role, explaining its semantic meaning
as well as any associated attributes that may or may not be used with it.
Let's walk through these sections.
The top section gives you the name of the role,
a brief description of its semantic meaning,
as well as a brief description of the related radiogroup role.
Then, in the table, we start off with a superclass role.
The role's model includes a taxonomy of roles, including some abstract roles,
which capture groups of roles with common properties but
can't be used on their own.
In this case, the superclass rolls are option and checkbox.
So radio button inherits properties from both of those.
We also have a related concept.
This is just kind of a catch-all for things that are semantically related.
In this case,
a radio input is related because it's a common presentation of a radio button.
These inherited states and properties are all the properties which may or
must be applied to this element based on its superclass roles.
Most of these will be optional generic global attributes.
But in this case, we see aria-checked,
which is inherited from the checkbox role, is a required attribute.
So if we're going to create an ARIA radio button we have to make sure
aria-checked is set correctly.
We have some information about labels referred to as name here.
Name From indicates whether the name may be taken from the element's text content
like a button element or needs to be provided by some other mechanism
like a native HTML radio input.
Having contents as one of the options here indicates that the element's text
content if it has any will be used as its accessible label.
Author indicates that the author must explicitly provide a name,
which we'll cover a bit later in this lesson.
Accessible Name Required obviously indicates you've got to specify some
type of name for this role.
This is usually but not always true.
For example, the main role indicates the main region of a page,
which requires no explanation in most cases.
And finally, the implicit value note here indicates that the default value
for aria-checked is false.
This means that if we omit the aria-checked attribute,
the radio button will be represented as being unselected.
It's definitely worth learning to navigate the ARIA spec
to find out about the specifics of ARIA roles, states, and properties.
But if you can find a specific pattern you want in the ARIA practices guide,
then that gives you all the information you need to implement the widget
in one place.
It also links back to the ARIA spec for
information on all of the ARIA attributes I've mentioned.
Earlier we saw the 1.0 version of this document.
This is the 1.1 version, which at the time I'm recording this,
is a working draft.
I'm working off this version in this lesson since it's more up to date and
will eventually become the standard version.
This is the design pattern we already saw for
a radio group, which gives us the keyboard interaction and
also some more detailed advice on the ARIA attributes which should be used.
The design pattern tells us that we need to put our radio buttons in a container
element with a role of radiogroup, give each one a role of radio, and
ensure that we set aria-checked correctly.
So let's try that out.