So far we've strongly encouraged using native elements because they give you
focus, keyboard support, and built in semantics essentially for free.
But there are instances when native HTML won't cut it.
The Web Accessibility Initiatives Accessible Rich Internet Applications
spec is good for bridging areas where there are accessibility
issues that can't be managed with native HTML.
I don't have time to keep saying the Web Accessibility Initiatives Accessible
Rich Internet Applications specification.
So for the rest of the course, we'll be calling it by its much friendlier
nickname, ARIA, but you'll often see it referred to as Wai-Aria as well,
which is helpful if you want to search for it.
Aria works by allowing you to specify attributes on elements
which modify the way that element is translated into the accessibility tree.
Let's take a look at a really basic example to show how this works.
If we create a plain check box we saw in less than three
that a screen readable announcer as a check box,
tell you its label if it has one and tell you whether it is checked or not.
And similarly uses of other assistive technologies like voice control
will be able to operate it.
However, what happens if for
some reason we decide,we really need to reimplement a basic checkbox?
Well, for a start, we know from lesson two that we need to make it focusable
and handle the same keyboard interactions as a native check box.
But what happens if we then try to use it with a screen reader?
The screen reader gives us no indication that the element is meant to
be a check box.
Sighted users can see the visual cues which indicate the check box pattern,
but nothing is announced to screen reader users.
Using ARIA allows us to tell the screen reader that extra information.
To give you an idea how it works, let's look at this toy fake check box example.
Just to clarify,
there's very little reason you'd ever want to write code like this.
You're usually much better off styling a regular check box, but
this gives us a taste of what ARIA allows us to do.
So I'll run Chrome Vox light on this page,
to show what things are like before we do anything.
>> Tim-tams, mint slices.
>> We have a checked and unchecked custom check box up here.
Chrome Vox reads out the labels as tim-tams and mint slices,
but doesn't give us any indication that either one is a check box.
If we compare that with the native checkbox.
>> [SOUND] Tim-Tams check box checked.
[SOUND] Mint slices, check box not checked.
>> ChromeVox reads out the label, the role, and the checked state of each,
and plays a small earcon, which is that small sound effect you might have heard
at the start, to give a quick indication of the role and checked state as well.
So I'm going to pop open DevTools, and add an ARIA role of check box and
an ARIA-checked state to each of those custom check boxes.
So the first one gets an aria-checked state of true and
the second one will get an aria-checked state of false.
Note that I need to explicitly specify that aria-checked is true or false.
Just adding the attribute with an empty string,
like we often do with other HTML attributes, won't do the job.
ARIA attributes always need to have explicit values.
So now we're going to close the dev tools and
start up Chomebook slide again.
>> [SOUND] TIm-Tams checkbox checked, [SOUND] mint slices check
box not checked, [SOUND] Tim-Tams check box checked.
>> So now we can hear that there's really no difference from ChromeVox's
point of view, between the fake check boxes and the native check boxes.
They all sound identical, so
adding that role attribute and that aria-checked attribute
causes the node in the accessibility tree to have the desired role and state,
without changing anything else about that node's appearance or behavior.
In terms of the accessibility tree,
what ARIA does is allow you to essentially do some tree surgery.
We take the accessibility tree as generated from the plain HTML tree,
add ARIA and get a different accessibility tree.
It may be subtly different or
radically different depending on what attributes we use and where.
However, we need to keep in mind that this is the only thing ARIA changes.
It doesn't change anything about the behavior of the element it's added to.
For example, it's not going to make the element focusable or
add keyboard event listeners.
We still need to do the work by making sure we're keeping the promise we're
making by telling assistive technology that it has that role.
We'll be looking closer at what that means throughout this lesson, but
I'll point out right now that it's no coincidence that we're
covering ARIA after the lesson on focus and keyboard.