Intro to ARIA

The aim for today:

• An introduction to the Accessibility Tree, accessible names and descriptions.
• An understanding of ARIA.
• The difference between aria-describedby, aria-labelledby and aria-label.

Accessibility APIs communicate information about the user interface from the browser to the Assistive Technology.

There have been many Accessibility APIs released over the years, all building on and improving previous versions.

Browsers generally support one or more of the available accessibility APIs for the platform they’re running on.

Windows:

• Firefox, Chrome and Opera support MSAA/IAccessible and IAccessible2.
• Internet Explorer supports MSAA/IAccessible and UIAExpress.

OSX:

• Safari, Firefox and Chrome support NSAccessibility.

iOS:

• Safari, Firefox and Chrome support UIAccessibility.

The browser uses the DOM, along with further information derived from CSS, to generate an Accessibility Tree.

This information is passed to the relevant accessibility APIs associated with the browser / operating system.

This Accessibility Tree exposes information on specific elements to Assistive Technologies via the Accessibility API.

Information includes:

• The role, name and state of each object in the content.
• How each object relates to other objects in the content.

Each browser will produce a unique Accessibility Tree due to their specific source code/Accessibility API combination.

Chrome’s “Accessibility” tab has three key areas:

• Accessibility Tree.
• ARIA attributes.
• Computed properties.

As you inspect an element in the DOM, any relevant ARIA information is presented in the Accessibility Tree tab.

As you inspect an element in the DOM, any relevant ARIA attributes are presented in the ARIA Attributes tab.

As you inspect an element in the DOM, all the computed properties of that element are presented in the Computed Properties tab.

Open https://russmaxdesign.github.io/exercise/.

Browsers use the DOM tree to create a second tree, called the Accessibility Tree.

Inspect the “What are mammals?” heading. What is this elements role and level the Accessibility Tree?

Inspect the “Full name” <input>. What is this elements role in the Accessibility Tree?

Inspect the “Email” <input>. Is this element defined as being required in the Accessibility Tree?

Type some content into the “Email” <input> field. Does the element now have a value in the Accessibility Tree?

Choose “Aardvark” from the “Favourite Mammal” dropdown. Does the <select> element now have a value in the Accessibility Tree?

Check “Yes” from the “Subscribe to newsletter” checkbox group. Does the checkbox now have a checked status in the Accessibility Tree?

As you can see, there are a wide range of possible properties that can be presented as part of the accessibility tree, depending on the element being inspected.

Some of the key accessibility tree properties include:

Accessible names are names given to elements in the Accessibility tree.

Accessible names are very important for Assistive Technology users as they help to identify elements within the accessibility tree.

Accessible names are defined as text strings.

Chrome’s accessibility tree shows all the possible options that could be used to provide the accessible name.

It also displays the final computed accessible name as a text string.

Accessible names can be applied to elements in a range of different ways, depending on the element.

The contents of links and buttons can be converted into text strings and used as their accessible names.

The value of the alt attribute for an image can be converted into a text string and used as the accessible name.

For elements that allow the title attribute, the title value can be converted into a text string and used as the accessible name.

For some elements, the placeholder value can be converted into a text string and used as the accessible name.

For some elements, the aria-label value can be converted into a text string and used as the accessible name.

The contents of the <label> element can be converted into a text string and used as the accessible name for <input>, <select> and <textarea> elements.

The contents of the <caption> element can be converted into a text string and used as the accessible name for the <table> element.

The value of aria-labelledby attribute can be converted into a text string and used as the accessible name for various elements.

Use accessible names based on:

• Visible content for <a> and <button> elements.
• <label> contents for relevant form elements.
• <caption> contents for <table> elements.
• Alt attribute content for <img> elements.

Whenever possible, avoid using:

• placeholder.
• title.
• aria-label.
• aria-labelledby.

Accessible names should:

• Be concise.
• Start with a capital letter.
• Convey function or purpose, not form.
• Put the important words first.

Open https://russmaxdesign.github.io/exercise/.

Inspect the “Email” <input>. What is this elements name in the Accessibility Tree?

In this case, the accessible name is taken from the for attribute of the <label> element.

In the DOM, remove for="form-email" from the “Email” <label> element. Does the element have a name in the Accessibility Tree now?

This form field now has no accessible name, so there is no way for Assistive Technologies to understand its purpose.

Inspect the <fieldset> element associated with “Subscribe to newsletter”. Does it have a name in the Accessibility Tree?

Inspect the <main> element above the “What are mammals” heading. Does it have a name in the Accessibility Tree?

Look at the first “Find out more” link on the page. In theory, the accessible name for this element should be “Find out more” from the contents of the link.

However, the element has also been given an aria-label, which provides a different accessible name of “Find out more about mammals”.

So, there are two possible accessible names. Which one wins? The answer is displayed in the accessibility tree.

Notice how the accessibility tree interface displays the link contents as crossed out, while the aria-label content is highlighted.

This means the aria-label content will be used as the accessible name for this element.

An accessible description provides additional information, related to an interface element, that complements the accessible name.

The accessible description might or might not be presented visually on-screen.

Accessible descriptions are defined as text strings.

Open https://russmaxdesign.github.io/exercise/.

Inspect the “Address” input. What is this elements description in the Accessibility Tree?

How are the accessible name and description announced in different screen readers?

Screen readers announce objects within the accessibility tree in the following order:

• Accessible name.
• Role.
• Description.
• Additional instructions.

let’s use the “Address” <input> again to see the announcement order in different screen readers.

With Voiceover, there is a pause after the accessible name and role are announced.

OSX / VoiceOver / Chrome

• Accessible name: “Address”.
• Role: “Edit text”.
• [Pause].
• Description: “Include full street address”.
• Additional instructions: “You are currently on a text field. To enter text in this field, type.”.

Windows / NVDA / Chrome

• Accessible name: “Address”.
• Role: “Edit”.
• Description: “Include full street address”.
• Additional instructions: “Blank”.

Windows / JAWS / Chrome

• Accessible name: “Address”.
• Role: “Edit”.
• Description: “Include full street address”.
• Additional instructions: “Type in text”.

Web Accessibility Initiative (WAI)

WAI is a working group that develops standards and support materials to help implement accessibility.

Accessible Rich Internet Applications (ARIA)

ARIA is a standard that defines a way to make websites and web apps more accessible to people with disabilities.

ARIA especially helps with dynamic content and advanced user interface controls developed with HTML and JavaScript.

WAI-ARIA 1.0 was published as a completed W3C Recommendation on 20 March 2014.

WAI-ARIA 1.1 was published as a completed W3C Recommendation on 14 December 2017.

WAI-ARIA 1.2 was published as a completed W3C Working Draft 18 December 2019. This means it is still not the official standard yet!

How ARIA works can be defined in three simple statements:

• WAI ARIA is a series of custom HTML attributes.
• These attributes can be used to change and augment the Accessibility Tree.
• They provide addition information to Assistive Technologies.

ARIA can be used change and augment the Accessibility Tree in the following ways:

1. Add semantics to the accessibility tree

i.e. adding semantics to generic elements via the role attribute.

2. Modify existing semantics to the accessibility tree

i.e. modifying the existing semantics of elements via the role attribute.

3. Apply states to the accessibility tree

i.e. informing Assistive Technologies of a widget’s current state.

4. Provide or improve accessible names in the accessibility tree

i.e. adding additional labelling to elements.

5. Provide descriptions to the accessibility tree

i.e. adding descriptions to elements.

6. Establish relationships in the accessibility tree

i.e. informing Assistive Technologies of the relationships between specific elements, than may not be possible via the DOM.

7. Informing Assistive Technologies about possible changes to the DOM

i.e. Defining region “live” and may change.

ARIA does not do any of the following:

1. Modify an element’s visual appearance.
2. Modify the element’s behaviour.
3. Add focusability.
4. Add keyboard functionality.

ARIA attributes are broken down into three categories:

• Roles.
• States.
• Properties.

ARIA roles are HTML attributes that are added to elements using:

role="[role-type]".

ARIA roles can be used to add or change the semantic meaning of HTML elements in the accessibility tree.

For example: Is the element a menu, slider, spinner, progress bar?

A list of all roles, including how they have changed in different versions of ARIA.

ARIA state and properties are HTML attributes that are added to elements using:

aria-[state|property]=[property-type]

ARIA states define the current state of HTML elements in the accessibility tree.

For example: Is the element checked or disabled?

ARIA properties define purpose or relationships of HTML elements in the accessibility tree.

For example: "Does the element have a description? Does the element interact with other elements?

A list of all states and properties, including how they have changed in different versions of ARIA.

Files:

• Open exercises/exercise07-start.html in a text editor and browser.
• View exercises/exercise07-finished.html to check your results.

Our aims are to:

1. Add role="checkbox" to each of the fake checkboxes.
2. Add aria-checked="false" to each of the fake checkboxes.
3. Add role="group" to the parent container.
4. Add aria-labelledby="group-label" to the parent container .
5. Add id="group-label" to the <h3> element.

Imagine you have to make a checkbox group, but you have to to use <div> elements instead of native checkboxes.

As you will see:

• Some basic JavaScript is already in place.
• Keyboard focus is in place via tabindex="0".

However, this widget is completely inaccessible to assistive technologies.

• The elements have no role defined.
• The elements have no checked state defined.
• The <h3> heading is not programmatically associated with the checkbox group.

Step 1:

Add role="checkbox" to each of the fake checkboxes.

Step 2:

• Add aria-checked="true" to the first fake checkbox.
• Add aria-checked="false" to other fake checkboxes.

If we inspect any of the fake checkboxes in the accessibility tree, they now have roles and states.

Step 3:

Add role="group" to the parent container so that we can create a fake <fieldset>.

Step 4:

Add aria-labelledby="group-label" to the parent container so we can give it an accessible name.

Step 5:

Add id="group-label" to the <h3> element. Now it will operate like a fake <legend>.

If we inspect the parent container in the accessibility tree, it now has an accessible name and a role.

This is a quick example to show how ARIA is used to augment the accessibility tree to help Assistive Technologies.

This is where a primary element is given a label (another name for an accessible name) by a secondary element.

The aria-labelledby attribute is applied to the primary element, and the matching ID value is applied to the secondary element.

So, the primary element is literally being “labelled by” the secondary element in the accessibility tree.

This <section> element will now have an accessible name of “Contact details” in the accessibility tree because it is being “labelled by” the <h3> element.

Files:

• Open exercises/exercise08-start.html in a text editor and browser.
• View exercises/exercise08-finished.html to check your results.

Our aims are to:

1. Add aria-labelledby="section-heading" the the <div>.
2. Add id="section-heading" to the <h3>.
3. View the accessible name in the Accessibility Tree.

The aria-label attribute is used to provide a label directly to the element itself.

The primary element is literally being “given a label” in the accessibility tree.

This <button> element will now have an accessible name of “Close and return to account details” in the accessibility tree.

In fact, if you look in the accessibility tree, the contents of the <button> is replaced by the aria-label as the accessible name.

Files:

• Open exercises/exercise09-start.html in a text editor and browser.
• View exercises/exercise09-finished.html to check your results.

Our aims are to:

1. Add aria-label="Close and return to account details" the the <button>.
2. View the accessible name in the accessibility tree.

This is where a primary element is given a description by a secondary element.

The aria-describedby attribute is applied to the primary element, and the matching ID value is applied to the secondary element.

So, the primary element is literally being “described by” the secondary element in the accessibility tree.

This <input> element already has an accessible name of “Phone”.

However, it will now has an accessible description of “Error: Include area code” in the accessibility tree.

The aria-describedby attribute cannot provide an accessible name in the accessibility tree - it is just for descriptions.

Multiple descriptions can be applied to a single element using aria-describedby. They are defined using space-separated values.

The order that these elements are defined within the aria-describedby value determines the order in which the descriptions are announced.

In this case, because hint1 is defined before error1 the accessible description will be:

“Include an area code Error: Include area code”

Files:

• Open exercises/exercise10-start.html in a text editor and browser.
• View exercises/exercise10-finished.html to check your results.

Our aims are to:

1. Add id="hint" to the <span> element with a class of help-text.
2. Add id="error" to the <span> element with a class of error-message.
3. Add aria-describedby="hint error" to the <input> element.
4. View the accessible name in the accessibility tree.