Web accessibility - WAI-ARIA a small introduction

WAI-ARIA
a small introduction
web app & widgets
FrontEnders Ticino support Global Accessibility Awareness Day
May 17th, 2017
Bellinzona, Switzerland

Geoffroy Baylaender
Front end web designer at KaVoKerr
@gBaylaender

“The power of the Web is in its
universality. Access by everyone
regardless of disability is an
essential aspect.”
Tim Berners-Lee
W3C Director and inventor of the World Wide Web

> 1 BPeople have a disability in the World*
Hearing impaired: 360M / Vision impaired: 285M / Cognitive: 194M
Physical impairment: 13M / Other (Depression, Alcohol, Dementia): 148M
source: http://www.who.int/mediacentre/factsheets/fs352/en/

54%Have some form of disability
The Myth of Minority
Source: PEW internet project

Baby Boomers
Getting older
https://en.wikipedia.org/wiki/Baby_boomers

9 out of 10websites are inaccessible
http://www.who.int/mediacentre/factsheets/fs352/en/

~8%Colorblind people in the World
~ 7% male , ~ 1% female
source: https://nei.nih.gov/health/color_blindness/facts_about

Some common
accessibility
barriers
Semantic Markup
Page Title
Headings
Graphics (no alt)
Links
Tables and Forms
Poor color contrast
on Web pages

Accessibility:
what are the benefits?

Efficient code
Website maintenance
Device compatibility
Faster page loading
SEO

… a problem ...
HTML has a very limited set of interface controls and interactions.
Built-in tags without semantically describe these kinds of widgets, using generic
elements such as <div> and <span>

...
Dynamic content on a web page can be particularly problematic for users who,
for whatever reason, are unable to view the screen.
JavaScript provides us many things including:
Dynamic interactions, i.e.: drag and drop, resizing, hide and show, open and
shut, switch views etc.
Widgets and components, i.e.: modals, in-page tabs, date pickers, page
loaders, sliders etc.

... at the end the root cause is:
a lot of dynamic interactions and widgets are problematic for Assistive
Technologies (i.e.: screen reader)

… an problematic example ...
<ol>
<li id="ch1Tab">
<a href="#ch1Panel">Chapter 1</a>
</li>
<li id="ch2Tab">
</li>
<li id="quizTab">
<a href="#quizPanel">Quiz</a>
</li>
</ol>
<div>
<div id="ch1Panel">
Chapter 1 content goes here
</div>
<div id="ch2Panel">
</div>
<div id="quizPanel">
Quiz content goes here
</div>
</div>
Tabs widget without ARIA labeling:
no information in the markup to describe the widget's form and function.

Look & Feel problems
Widgets built this way are rarely keyboard accessible.
The role of the widget, what it does, is not available to assistive technology.
States and properties of the widget are not available to assistive technology.
Updates, and discovery of the updates are not reported to assistive
technology.

… and the problem continuing ...
Users might recognize it visually, but
there are no machine-readable
semantics for an assistive
technology.

That’s where ARIA
comes in.
Web Accessibility Initiative - Accessible Rich Internet Applications
It helps with dynamic content and advanced user interface controls developed
with Ajax, HTML, JavaScript, and related technologies.

WAI-ARIA
“WAI-ARIA is a specification that
provides a means of describing
roles, states, and properties for
custom widgets so that they are
recognisable and usable by
assistive technology users.
WAI-ARIA also provides a
mechanism to ensure that users of
assistive technologies are aware of
updates in the application.”
Gez Lemon
on Dev.Opera.com
August 1st, 2008

ARIA role=“*” (most common)
http://w3c.github.io/aria-in-html/#aria-roles
the value of role have the priority on
native value
The values are standard and
automatically translated by the
assistive technology.
From W3C page:
The roles defined in this specification include a
collection of document landmarks and the WAI-
ARIA role taxonomy.

The solution of the problem...
<ol role="tablist">
<li id="ch1Tab" role="tab">
</li>
<li id="ch2Tab" role="tab">
</li>
<li id="quizTab" role="tab">
<a href="#quizPanel">Quiz</a>
</li>
</ol>
<div>
<div id="ch1Panel" role="tabpanel" aria-labelledby="ch1Tab">
</div>
<div id="ch2Panel" role="tabpanel" aria-labelledby="ch2Tab">
</div>
<div id="quizPanel" role="tabpanel" aria-
labelledby="quizTab">
Quiz content goes here
</div>
</div>
Tabs widget with ARIA labeling

ARIA’s rules
http://w3c.github.io/aria-in-html

Rule #0
Structure your HTML markup
following the W3C Standards in a
semantic way

Rule #1
If you can use a native HTML element
or attribute with the semantics and
behaviour you require already built in,
instead of re-purposing an element
and adding an ARIA role, state or
property to make it accessible, then
do so.

Rule #2
Do not change native semantics,
unless you really have to.
For example: Developer wants to
build a heading that's a button.
Do not:
<h1 role=button>heading button</h1>
Do:
<h1><button>heading button</button></h1>
or
<h1>
<span role=button>heading
button</span>
</h1>

Rule #3
All interactive ARIA controls must be usable
with the keyboard.
If you create a widget that a user can click or
tap or drag or drop or slide or scroll, a user must
also be able to navigate to the widget and
perform an equivalent action using the
keyboard.
All interactive widgets must be scripted to
respond to standard key strokes or key stroke
combinations where applicable.
For example, if using role=button the element must
be able to receive focus and a user must be able to
activate the action associated with the element using
both the enter (on WIN OS) or return (MAC OS) and
the space key.

Rule #4
Do not use role="presentation" or aria-
hidden="true" on a visible focusable element .
Using either of these on a visible focusable
element will result in some users focusing on
“nothing”.
If an interactive element cannot be seen or
interacted with, then you can apply aria-hidden.
Do not:
<button role="presentation">press
me</button>
or not:
<button aria-hidden="true">press me</button>
Do
button {visibility:hidden}
<button aria-hidden="true">press me</button>
If an interactive element is hidden using display:none, it will also be removed from the accessibility tree,
which makes the addition of aria-hidden="true" unnecessary.

Rule #5
All interactive elements must have an
accessible name.
An interactive element only has an accessible
name when its Accessibility API accessible
name (or equivalent) property has a value.
For example, the first input type=text in the code
example aside has a visible label 'user name' ,
but no accessible name:
Do not:
User name <input type="text">
Or
<label>User name</label>
<input type="text">
Do:
<label>User name <input type="text">
</label>
<label for="userName">User
name</label>
<input type="text" id="userName">

Some important attributes
aria-live
aria-labelledby & aria-describedby
aria-atomic
aria-relevant
aria-busy
aria-select
...
www.w3.org/TR/wai-aria/states_and_properties
Focus on these

aria-live
Dynamic information, could create two
problems:
1. screen reader don’t understand when a
content is loaded
2. screen reader can focus only one part of
the document, the risk of missing the
update is high
Attribute aria-live notify the screen reader when
the content is updated.
Use it for any page regions need to be updated
after the first load
use attribute aria-live on any HTML element, i.e.:
<div aria-live=”off”>

</div>

aria-live’s values:
off (default):
Updates to the region will not be presented to the user unless the assistive technology is currently
focused on that region. For info not critical to use
polite:
(Background change) Assistive technologies SHOULD announce updates at the next graceful
opportunity, such as at the end of speaking the current sentence or when the user pauses typing.
assertive:
This information has the highest priority and assistive technologies SHOULD notify the user
immediately. Because an interruption may disorient users or cause them to not complete their
current task, authors SHOULD NOT use the assertive value unless the interruption is imperative.
https://www.w3.org/TR/wai-aria/states_and_properties#aria-live

aria-live values explanation
https://www.w3.org/TR/wai-aria/states_and_properties#aria-live
off Not an information the user
needs to know (not critical)
polite Should announce updated at
the next opportunity (i.e.: end
of current sentence)
Information the user
needs to know
assertive Reader should announce
immediately the user
Use only if is
mandatory to notify the
user

aria-labelledby
The aria-labelledby attribute contains the
element IDs of labels in objects such as input
elements, widgets, and groups. The attribute
establishes relationships between objects and their
labels.
Assistive technology, such as screen readers, use
this attribute to catalog the objects in a document so
that users can navigate between them. Without an
element ID, the assistive technology cannot catalog
the object.
The aria-describedby attribute is used to indicate
the IDs of the elements that describe the object. It is
used to establish a relationship between widgets or
groups and text that described them. This is very
similar to aria-labelledby: a label describes the
essence of an object, while a description provides
more information that the user might need.
When user agents compute the accessible name property of elements that have both an aria-
labelledby attribute and an aria-label attribute, the user agents give precedence to aria-
labelledby.
aria-describedby

aria-labelledby & aria-describedby
<div role="applicaton" aria-labelledby="calendar" aria-describedby="info">
<h1 id="calendar">Calendar<h1>
<p id="info">
This calendar shows the game schedule for the Boston Red Sox.
</p>
<div role="grid">
...
</div>
</div>

Insert aria-* by inline or script
If the ARIA role or aria-* attribute does not
rely on scripting to provide interaction
behaviour, then it is safe to include the ARIA
markup inline
Web app not JS based: inline
Wep app JS based: load by script but
suggested inline
Web app with JS interaction: inline, and
modify by script
http://w3c.github.io/aria-in-html/#inline
<li role=treeitem aria-expanded=false
When the user opens the section, it is changed
to this using JavaScript :
<li role=treeitem aria-expanded=true

Validation
http://validator.w3.org/nu/

ARIA attributes
don’t affect
anything about
the web page
Except for the information exposed by the
browser's accessibility APIs

Don’t use ARIA
until you don’t
need to use it!

Use the native
HTML elements or
attributes
already existing
and built in!

Use the correct
semantic HTML
elements. Don’t
use as fixer!

Use aria-*
attributes with
care and test
heavily before
using

Thanks to
Joe Devon – @JoeDevon
Dennys Vitali – @DenysVitali

Bibliography
https://developer.mozilla.org/en-US/docs/Web/Accessibility
http://maxdesign.com.au/jobs/sample-accessibility
https://webaccessibility.withgoogle.com
https://accessibility.blog.gov.uk
https://www.gov.uk/service-manual/helping-people-to-use-your-service/making-your-
service-accessible-an-introduction
https://developer.mozilla.org/en-US/docs/Learn/Accessibility/WAI-ARIA_basics

ARIA’s values
true/false
tristate
(value representing true or false, with an intermediate "mixed" value. Default value is "false" unless otherwise specified)
true/false/undefined
(value representing true or false, with a default "undefined" value indicating the state or property is not relevant)
ID refrence
ID reference list
integer
string
token
(one of a limited set of allowed values)
token list

-1to allow a programmatic focus

0 - 32767positive values in order to have
a keyboard user can navigate in the element
Suggestion: don’t use it, if your markup is correct, probably you don’t need it

Web accessibility - WAI-ARIA a small introduction

Web accessibility - WAI-ARIA a small introduction

In this document