Hitting the accessibility high notes with ARIA

Hitting the high notes
with ARIA
Ted Drake, Intuit Accessibility
Silicon Valley Code Camp,
October 2013
Sunday, October 6, 13
This presentation on ARIA was created for the Silicon Valley Code Camp, 2013 by Ted Drake.

Goals
• Screen Reader Introduction
• Introduce ARIA
• Use it today
• Examples
The goal of this talk to to de-mystify ARIA and encourage engineers to make their sites more
accessible by using it correctly. This talk will be focused on new users, but should also
provide interesting content and examples for more advanced users.

Screen
Readers
Screen readers are used primarily by people with vision disabilities. However, they are also
used as a middle layer for automated testing and for people with cognitive and physical
disabilities.
Screen readers interpret the user’s interaction and the applications responses.

This short video shows how a screen reader announces the content and role of an element,
such as a link or form input.

This short video shows how a screen reader user can navigate around a page by examining
the header tags. The user can also navigate via landmarks, form elements, links, images, and
other types of elements on the page.

What is ARIA?

a·ri·a
ˈärēə/
noun Music
noun: aria; plural noun: arias
1.
a long, accompanied song for a solo voice,
typically one in an opera or oratorio.
An aria is the solo performance during an opera that brings people to their feet.

A·RI·A
ˈärēə/
nounTechnology
noun: aria;
1.
WAI-ARIA (Web Accessibility Initiative -
Accessible Rich Internet Applications) is a draft
technical speciﬁcation published by the World
Wide Web Consortium that speciﬁes how to
increase the accessibility of dynamic content and
user interface components
WAI ARIA is a web standard established as a bridging technique to provide accessibility to
dynamic web sites.

Basics
• HTML attributes
• Good support
• Easy
• Bridge to HTML5
• No visual impact
ARIA is a set of HTML attributes that provide information to the user via the browser and
assistive technology.
ARIA has good support via browsers and screen readers, but not as good for other assistive
technology.
Don’t depend on ARIA if possible.
ARIA’s basic elements are easy to understand and code
ARIA is a bridge technology until HTML5 is completely supported. It’s ok to combine and
should be future proof.

ARIA Rules
1. Don’t use ARIA if
native tag is available.
2. See #1
The best user experience is created with the semantic HTML tags. ARIA is meant to ﬁx areas that
cannot use existing native elements.
Use <button> instead of role=”button”, <table> instead of role=”grid”, and <img> instead of
role=”img”
too many people are using crap code because it is part of a platform, given in a demo, or think it’s
easier to style a blank element.
Don’t do this. Use the correct tag to give your site structure. If you are stuck using bad code, use ARIA
to make it work, but you are still stuck with a bad foundation.
http://www.w3.org/TR/aria-in-html/#ﬁrst-rule-of-aria-use

ARIA > HTML
ARIA has more importance than HTML.
When you put ARIA on a tag, it will supercede the tag’s value.
This includes role, state, and properties.

I’m a link that points to
the same page and
says “Button”
Before ARIA
In this example, we have a link that has been styled to look like a button.
<a href=”#”>Button</a>

<a href=”#”>
! Button
</a>
This is the code for the link that looks like a button. It will be announced as an internal link,
as the href value is #.

I’m a button that says
“Button”
After ARIA
In this example, we have a link that has been styled to look like a button.
<a href=”#” role=”button”>Button</a>

<a href=”#” role=”button”>
! Button
</a>
In this example, we are using the ARIA role attribute to redeﬁne a link as a button. This will
cause the screen reader to ignore the href.
Links should take the user to a new page or chunk of content.
Buttons should trigger an action.

Roles
• Widget: role=”alert”
• Composite: role=”grid”
• Document Structure: role=”img”
• Landmark: role=”search”
• w3.org/TR/wai-aria/roles
Alert is a widget role. Adding this role suggests an interface and may be standalone or part of
a group. Alert will prompt the browser to announce the content when this object changes,
such as when an alert appears on a page.
Grid is a composite role. There’s a complex arrangement of sub-roles. Grid allows a set of
divs to act like a table.
Img is a structure role. It describes the structural elements and are not interactive.
Landmarks are regions that can be used for navigation to key elements of an application.
http://www.w3.org/TR/wai-aria/roles

Landmarks
• Search Form: role=”search”
• Main: role=”main”
• Nav: role=”navigation”
• Header: role=”banner”
landmarks deﬁne content areas on a page. These match HTML5 tags and can be combined.
They provide alternate navigation opportunities for users.
Firefox is the only browser that currently surfaces the native HTML5 tag roles to assistive
technology.
So <nav role=”navigation”> is good.

Landmarks
<form role=”search”>
<label for=”q”>Search</label>
<input type=”search” id=”q” name=”q”>
<button>submit</button>
</form>
Adding role=”search” to the form tag allows a user to quickly move to the search form from
anywhere in the page. Note, this goes on the form, not the input.

States
• aria-disabled=”true | false”
• aria-expanded=”true | false | undefined”
• aria-hidden=”true | false”
• aria-invalid=”true | false | grammar | spelling”
• aria-selected=”true | false | undefined”
States represent the current state of an object and can change as the user interacts with the
application.
Many are tied to specific roles and cannot be used indiscriminately.
Many of these states are already commonly used in HTML elements

I’m a disabled button
that says “Disabled
Button”
After ARIA
In this example, we have a span that has been styled to look like a button.
<a href=”#” role=”button”>Button</a>

<a href=”#”
role=”button” aria-disabled=”true”>
! Disabled Button
</a>
In this example, we added aria-disabled=”true” to the link to let users know this isn’t just a
button, it’s a disabled button.
It would be easier to simply use <button disabled>Disabled Button</button>

<button disabled>
Disabled Button
</button>
This shows how it is much easier to use the native tags and avoid ﬁxing stuff with ARIA
http://www.w3.org/TR/html401/interact/forms.html#h-17.12

Properties
• aria-live=”polite | assertive | off”
• aria-label=”string”
• aria-describedby=”string”
• aria-haspopup=”true | false”
Properties attributes don’t change frequently. They describe special features for an object
aria-live: describes how a browser/screen reader should announce content when it changes, ie polite waits for
the user to pause.
aria-label: provides a label when the standard text label is not available. It will also over-write any existing text
labels.
aria-describedby: is treated similar to the title attribute. It announces optional information that provides context.
aria-haspopup: clicking on this link or button will generate a new chunk of content, such as a dropdown menu or
dialog window.

Live Regions
• aria-live=”polite”: announced after user
stops interacting with page.
• aria-live=”assertive”: interrupts user
• aria-live=”off”: no announcement
• role=”alert”: inherits aria-live=”assertive”

This example from the University of Illinois Urbana-Champagne shows how aria-live
announced new content.
There is a message box that will interrupt the reading of the text box.
The message box is using aria-live=”assertive”
http://test.cita.illinois.edu/aria/live/

Screen Reader Problems

This shows how pseudo buttons are not focusable via tab key and are announced as a text
string, not an interactive element
test page: http://fyvr.net/a11y/fake-real-buttons.html

This short video shows a common pattern where the search form has no label. Further, the
input is using the value attribute to contain a pseudo-placeholder. The value is cleared when
the user places focus into the input.
This fails because the input now has no label, no placeholder, and no value.
The placeholder attribute is not consistently supported and will not be announced if a user
moves back into the input after a value has been entered.

This video is a bit more difficult to understand. It shows a data table that uses divs instead of
a standard table markup. the screen reader announces the content as a series of simple
strings. The selected icons are not announced, as they are empty spans with background
images.
Test page: http://fyvr.net/a11y/payroll-table.html

ARIA to the
Rescue
Let’s go back to our earlier examples and show how ARIA can ﬁx those common issues.

This video shows how role=”button” makes a link sound just like a real button.
<a href=”#” role=”button”>foo</a>

This form ﬁxes the search form by adding role=”search” to the form tag. This sets it as a
landmark.
The input receives a label via aria-label=”search”
The placeholder attribute is not a substitute for a label.

This example isn’t perfect. But it does show how these divs can be given the data table
semantics by using the role=”grid” and appropriate children roles. The blue dots are also
given text: supported and not supported.
This could have been built with a basic data table in the start.

ARIA Form
• role=”alert”
• aria-describedby=”emailerror”
• aria-invalid=”true”
So far, this presentation has given examples of using ARIA to restore semantics and add
landmarks. Let’s see how a few small changes can make signiﬁcant usability improvements
that were not possible with basic html.
This example will use role=”alert” on an input’s error message. The invalid form input will
also get aria-invalid=”true” and aria-describedby to point to the error message.

This form has an email input that is validated as the user leaves the input (onBlur). The video
shows how the screen reader will announce the alert as soon as it appears. When the user
goes back to the input, they are told the input is invalid and the error message is repeated.

role=”alert”
<p role="alert" id="emailerror">
Please enter a valid email
address
</p>
Adding role=”alert” to an element will trigger the screen reader to announce the content
whenever it changes. In this page, the content is announced when the display status is
changed from display:none to display:block.
Also note, there is an id on this element. This will be used by aria-describedby attribute.

Original input
<input
type="email"
required
id="email"
name="email" >

Invalid input
<input
type="email"
required
id="email"
name="email"
aria-invalid=”true”
aria-describedby=”emailerror” >
After the input has been identiﬁed as invalid, we will need to add some attributes.
aria-invalid=”true” lets the user know when an input is invalid.
Add this attribute in your logic that uses a style or content to visually identify invalid inputs.
aria-describedby points to the id value of the error message. This will be announced as the
input has focus.

Repeat the video to show how this works.

Key Takeaways
• ARIA is easy and safe to use.
• Use basic HTML before reaching into the
ARIA bag
• ARIA provides information on role, state,
and property
• Make your forms more accessible with
ARIA
• Stop the div-itis

T: @ted_drake
S: slideshare.net/7mary4
U: last-child.com
Y: youtube.com/7mary4responding
E: ted_drake@intuit.com
Thank You!

Hitting the accessibility high notes with ARIA

Recommended

Recommended

More Related Content

Similar to Hitting the accessibility high notes with ARIA

Similar to Hitting the accessibility high notes with ARIA (20)

More from Ted Drake

More from Ted Drake (20)

Recently uploaded

Recently uploaded (20)

Hitting the accessibility high notes with ARIA