wai-aria - an introduction to accessible rich internet applications (1 day workshop) / darmstadt /...

wai-ariaAN INTRODUCTION TO ACCESSIBLE RICH INTERNET APPLICATIONS

Patrick H. Lauke / Version 1.0.24012015

what is ARIAand why do we need it?

the problem

it's "easy" (in most cases) to make static web content accessible, butnowadays the web strives to be an application platform

complex web applications require structures (e.g. interactive controls)that go beyond what regular HTML offers (though some of thisintroduced with HTML5 ... more on that later)

jQuery UI

Polymer Project

the problem

when building interactive controls, some (too many) web developersgo "all out" on the JavaScript/CSS, but ignore/sidestep regular HTMLcontrols completely

<div onclick="...">Test</div>

faked button

<div tabindex="0"onclick="...">Test</div>

faked button with focus

<div tabindex="0"onkeyup="..."

onclick="...">Test</div>

faked button with focus and keyboard handling

for a sighted mouse/keyboarduser

this is a button...

...but what about ascreenreader user?

compare <div> to a real<button>

faked button versus real <button>

more complex examples...

jQuery UI - Slider

What's the experience here for assistive technology users?

the problem

generic/inappropriate HTML elements, with extra JavaScript/CSS ontop...but they're still recognised and exposed as <span> , <div> , etc

Operating systems and other platforms provide interfaces that exposeinformation about objects and events to assistive technologies

Java Accessibility API [JAPI], Microsoft Active Accessibility [MSAA], the Mac OS XAccessibility Protocol [AXAPI], the Gnome Accessibility Toolkit (ATK) [ATK], and

IAccessible2 [IA2]

Marco Zehe: Why accessibility APIs matter

assistive technologies

assistive technologies

•   NVDA (free)

•   Narrator (free)

•   JAWS

•   ZoomText

•   Dragon NaturallySpeaking

•   VoiceOver (free)

•   TalkBack (free)

•   ...

Léonie Watson - Basic screen reader commands for accessibilitytesting

inspection tools

inspection tools

test using assistive technologies (e.g. screenreaders), however...

assistive technologies often use heuristics to repairincomplete/broken accessibility API information - so we want tocheck what's actually exposed to the OS/platform.

of course, browsers also have bugs/incomplete support...

Firefox DOM Inspector

chrome://accessibility view of the raw accessibility tree

Accessibility Viewer (aViewer)

James Craig - Using ARIA 1.0 and the WebKit Accessibility NodeInspector

Xcode Accessibility Inspector(but for Chrome, remember to turn on accessibility mode in chrome://accessibility)

compare <div> to a real<button>

faked button versus real <button>

if you use custom (notstandard HTML) widgets,

use ARIA to ensure correct infois exposed

what is ARIA?

W3C - Accessible Rich Internet Applications (WAI-ARIA) 1.0

ARIA defines HTML attributesto convey correct role, state,

properties and value

W3C - WAI-ARIA 1.0 - 5.3.1 The Roles Model

W3C - WAI-ARIA 1.0 - 6. Supported States and Properties

what information does ARIA provide?

•   role: what type of widget is this? (e.g. 'slider')

•   state: what is its situation? (e.g. 'disabled')

•   identity: what does it represent? (e.g. 'volume control')

this information is mapped by the browser to the operating system'saccessibility API and exposed to assistive technologies.

extra benefit: AT will (may) automatically announce widget-specifichints and prompts (e.g. JAWS "... button - to activate, press SPACEbar")

<div tabindex="0"role="button" onkeyup="..."onclick="...">Test</div>

faked button with appropriate role

use ARIA to:

•   make custom widgets understandable to assistive technology users

•   programmatically indicate relationships between elements

•   notify users of dynamic updates

•   hide irrelevant visible content from assistive technology

•   remediation of inaccessible content without completely recoding

ARIA roles and attributes: restrictions

•   certain role s only make sense as part of a specific complex widget

•   some aria-* attributes are global

•   other aria-* attributes only make sense for particular role

•   not all roles/attributes are supported/implemented consistentlyeverywhere

what ARIA doesn't do...

ARIA is not magic: it only changes how assistive technologyinterprets content.

•   make an element focusable

•   provide keyboard events

•   add properties

•   change visible appearance

all of this is still your responsibility...

ARIA support: browsers

•   Firefox 3+

•   Internet Explorer 8+

•   Safari 4+ (Mac)

•   Chrome 17+

ARIA support: assistive technologies

•   JAWS 8+ (Win)

•   Windows Eyes 5.5+ (Win)

•   ZoomText

•   VoiceOver (OS X/iOS)

•   NVDA (Win)

•   ORCA (Linux)

ARIA support: libraries

•   extJS

•   jQuery

•   Dojo

•   GWT

•   ...

"support" does not mean thateverything works, though...

In principle ARIA works in all markup languages...but obviously thatdepends on user agent/AT support. We'll focus on ARIA and HTML

Sidenote: Using ARIA to enhance SVG accessibility

using WAI-ARIA in HTML

W3C - Using WAI-ARIA in HTML

the 5 rules of ARIA use

1. don't use ARIA

If you can use a native HTML element [HTML5] or attribute with thesemantics and behaviour you require already built in, instead of re-purposing an element and adding an ARIA role, state or property tomake it accessible, then do so.“

2. don't change nativesemantics

unless you really have to / know what you're doing

don't do this:<h1 role="button">heading button</h1>

do this instead:<h1><span role="button">heading button</span></h1>

otherwise the heading is no longer a heading(e.g. AT users can't navigate to it quickly)

don't do this:<ul role="navigation"> <li><a href="...">...</a></li> ...</ul>

do this instead:<div role="navigation"> <ul> <li><a href="...">...</a></li> ... </ul></div>

otherwise the list is no longer a list(e.g. AT won't announce "list with X items...")

3. make interactive ARIAcontrols keyboard accessible

All interactive widgets must be focusable and scripted to respond tostandard key strokes or key stroke combinations where applicable. [...]

Refer to the keyboard and structural navigation and design patternssections of the WAI-ARIA 1.0 Authoring Practices

4. don't "neutralise" focusableelements

don't use role="presentation" or aria-hidden="true" on a visiblefocusable element. Otherwise, users will navigate/focus onto"nothing".

<!-- don't do this... -->

<button role="presentation">press me</button>

<button aria-hidden="true">press me</button>

<span tabindex="0" aria-hidden="true">...</span>

5. interactive elements musthave an accessible name

<!-- don't do this... -->

<span tabindex="0" role="button"> <span class="glyphicon glyphicon-remove-sign"></span></span>

<span tabindex="0" role="button" aria-label="Delete" > <span class="glyphicon glyphicon-remove-sign"></span></span>

<span tabindex="0" role="button" title="Delete" > <span class="glyphicon glyphicon-remove-sign"></span></span>

<span tabindex="0" role="button"> <span class="glyphicon glyphicon-remove-sign"> <span class="...">Delete</span> </span></span>

refer to WAI-ARIA 1.0 - 5.2.7. Accessible Name Calculation

WAI-ARIA spec can be dry/technical - use for referenceW3C - WAI-ARIA 1.0 Authoring Practices more digestible.

ARIA and HTML5

ARIA is used whenbuilding/denoting things that

native HTML can't do

HTML5 introduces newelements, element types,

attributes that solve some ofthese situations

example: HTML5 slider

HTML5 accessibility

Implementation status for HTML5 element/attribute accessibilitymappings

HTML5 now also includes WAI-ARIA ...

... meaning we can validate pages with (static) ARIA validator.w3.org

common structures and widgets

(not an exhaustive list - enough to understand concepts)

using ARIA to providestructure

heading

<p class="heading1">Heading 1</p>...<p class="heading2">Heading 2</p>...<p class="heading3">Heading 3</p>...

<p class="heading1" role="heading" aria-level="1" >Heading 1</p>...<p class="heading2" role="heading" aria-level="2" >Heading 2</p>...<p class="heading3" role="heading" aria-level="3" >Heading 3</p>...

example: headings

•   add role="heading"

•   if more than one hierarchical level, and can't be inferred fromstructure, add explicit aria-level

list

<div> <div>...</div> <div>...</div> <div>...</div> ...</div>

generally more complex (big markup structures that boil down toessentially "a list of things...")

<div role="list" > <div role="listitem" >...</div> <div role="listitem" >...</div> <div role="listitem" >...</div> ...</div>

example: list/listitem

•   add role="list" and role="listitem"

landmarks

adapted from HTML5 Doctor - Designing a blog with html5

why define landmarks?

•   users of assistive technologies can more easily find areas of yourpage/app

•   AT keyboard controls to navigate to/between landmarks

•   overview dialogs listing all landmarks (e.g. NVDA)

doesn't HTML5 solve this?

adapted from HTML5 Doctor - Designing a blog with html5

using ARIA forsimple/standalone widgets

button

<span tabindex="0" class="...">Button?</span>

example: button

<span tabindex="0" role="button" class="...">Button!</span>

•   add role="button"

•   make sure it's focusable

•   add handling of SPACE

toggle button

<span tabindex="0" class="...">Option</span>

<span tabindex="0" class="... pressed">Option</span>

example: [TODO] span and fixed with ARIA

<span tabindex="0" role="button" aria-pressed="false" class="...">Option</span>

<span tabindex="0" role="button" aria-pressed="true" class="... pressed">Option</span>

•   add role="button"

•   make sure it's focusable

•   add handling of SPACE

•   add aria-pressed and dynamically change its value

checkbox

<span tabindex="0" class="...">Option</span>

<span tabindex="0" class="... checked">Option</span>

example: checkbox

<span tabindex="0" role="checkbox" aria-checked="false" class="...">Option</span>

<span tabindex="0" role="checkbox" aria-checked="true" class="... checked">Option</span>

•   add role="checkbox"

•   make sure it's focusable

•   add handling of SPACE

•   add aria-checked and dynamically change its value

similar to toggle button, but announced differently by AT

aria-checked="true"

aria-checked="false"

aria-checked="mixed" <!-- "partially" checked -->

example: tri-state checkbox

radio button

<span tabindex="0" class="...">Yes</span><span tabindex="0" class="... selected">No</span><span tabindex="0" class="...">Maybe</span>

example: radio button

<span tabindex="-1" role="radio" aria-checked="false" class="...">Yes</span><span tabindex="0" role="radio" aria-checked="true" class="... selected">No</span><span tabindex="-1" role="radio" aria-checked="false" class="...">Maybe</span>

•   add role="radio"

•   only single tab-stop (as with native radio buttons)

•   add handling of SPACE and cursor keys

•   add aria-checked and dynamically change its value

•   should be contained inside role="radiogroup" (cfr. <fieldset> )

link

<span tabindex="0" onclick="document.location(...)">link</span>

<span tabindex="0" role="link" onclick="document.location(...)">link</span>

•   add role="link"

•   make sure it's focusable

•   ensure correct ENTER keyboard handling

tooltip

<span tabindex="0" onmouseover="..." onfocus="...">...</span>...<span>this is the tooltip text</span>

<span tabindex="0" onmouseover="..." onfocus="..." aria-describedby="tooltip" >...</span>...<span role="tooltip" id="tooltip"> this is the tooltip text</span>

example: tooltip

•   add role="tooltip" (but seems to have no effect in AT)

•   add aria-describedby pointing to id of tooltip

status bar

<span role="status" > some form of status bar message...</span>

example: status bar

•   add role="status" (varying support?)

•   an example of a live region (more on this later)

alert message

<span role="alert" > an alert message (no user interaction)</span>

example: alert

•   add role="alert" (varying support?)

•   an example of a live region (more on this later)

progress bar

<div> <span style="width:40%"></span></div>

<div tabindex="0" role="progressbar" aria-label="..." aria-valuemin="0" aria-valuemax="100" aria-valuenow="40" aria-valuetext="40% complete" > <span style="width:40%"></span></div>

example: progress bar

•   add role="progressbar" (varying support?)

•   add aria-valuemin , aria-valuemax , aria-valuenow

•   optional aria-valuetext

•   make it keyboard-focusable

•   should have a name/label, e.g. aria-label

slider

<!-- taken from jQueryUI -->

<div ... class="ui-slider ..."> <span class="ui-slider-handle ..." tabindex="0" style="left: 7%;"></span></div>

example: standard jQueryUI slider

<div ... class="ui-slider ..." role="slider" aria-valuemin="0" aria-valuemax="100" aria-valuenow="40" aria-valuetext="40%" > <span class="ui-slider-handle ..." tabindex="0" style="left: 40%;"></span></div>

•   add role="slider"

•   add aria-valuemin , aria-valuemax , aria-valuenow

•   optional aria-valuetext

•   ensure it handles cursor keys correctly

•   should have a name/label, e.g. aria-label

Hans Hillen's Accessible jQuery-ui Components Demonstration

dialog

<div role="dialog" tabindex="0" aria-labelledby="dialog-header" > <div id="dialog-header">My custom dialog</div> ...</div>

example: jQueryUI dialog (enhanced)

Karl Groves - a11yDialog

using ARIA forcomplex/composite widgets

menu

<div role="menu" </div> <div role="menuitem" ...>...</div> <div role="menuitem" ...>...</div> <div role="menuitem" ...>...</div> ...</div>

<div role="menubar" > <div role="menuitem" ...> ... <div role="menu" </div> <div role="menuitem" ...>...</div> <div role="menuitem" ...>...</div> <div role="menuitem" ...>...</div> ... </div> </div> ...</div>

example: Open Ajax Alliance - Menubar

most suitable for real "application-like" web-apps - arguably notappropriate for general "website navigation"

W3C - Web Accessibility Tutorials - Web Application Menus

Adobe - Accessible Mega Menu

W3C - Web Accessibility Tutorials - Fly-out Menus

Heydon Pickering - Practical ARIA - Simple dropdowns

tabs / accordions

<div role="tablist" ...> <div role="tab" aria-controls="panel1" aria-selected="true" ...>Tab 1</div> <div role="tab" aria-controls="panel2" ...>Tab 2</div> <div role="tab" aria-controls="panel3" ...>Tab 2</div></div>

<div role="tabpanel" id="panel1" aria-hidden="false" >...</div><div role="tabpanel" id="panel2" aria-hidden="true" >...</div><div role="tabpanel" id="panel3" aria-hidden="true" >...</div>

example: Open Ajax Alliance: Tab Panel

variations on this theme: Marco Zehe - Advanced ARIA tip #1: Tabs inweb apps

not appropriate if you're just marking up a site navigation...

<div role="tablist" ...> <div role="tab" aria-controls="panel1" ...>Tab 1</div> <div role="tabpanel" id="panel1">...</div> <div role="tab" aria-controls="panel2" ...>Tab 2</div> <div role="tabpanel" id="panel2">...</div> <div role="tab" aria-controls="panel3" ...>Tab 2</div> <div role="tabpanel" id="panel3">...</div></div>

example: Hans Hillen - Accessible jQuery-ui Components: Accordion

sometimes better to keep it simple (series of expand/collapsecontrols): whatsock - AccDC Technical Style Guide / AccDC TechnicalStyle Guide (GitHub)

listbox

<div role="listbox" aria-activedescendant="opt2" tabindex="0"> <div role="option" id="opt1">Option 1</div> <div role="option" id="opt2" class="active">Option 2</div> <div role="option" id="opt3">Option 3</div></div>

example: James Craig - multiselect listbox

•   add role="listbox" on the container

•   add role="option" on each option

•   implement standard keyboard interaction (complex for multiselect)

•   use aria-activedescendant to manage focus (more later)

combobox

<!-- similar to <select> --><input type="text" role="combobox" aria-expanded="true" aria-autocomplete="list" aria-owns="optlist" aria-activedescendant="opt2" >

<div role="listbox" id="optlist"> <div role="option" id="opt1">Option 1</div> <div role="option" id="opt2" class="active">Option 2</div> <div role="option" id="opt3">Option 3</div></div>

example: Open Ajax Alliance: Combobox with aria-autocomplete=list

•   combination of focusable text input and listbox (likeautocomplete/search suggestions)

tree

<!-- list with selectable items, expand/collapse, nesting --><div role="tree" > <div role="treeitem" >...</div> <div role="treeitem" >...</div> <div role="treeitem" >... <div role="group" > <div role="treeitem" >...</div> <div role="treeitem" >...</div> </div> </div> ...</div>

example: Tree example (no ARIA used) / Tree example (with ARIA)

support very poor on mobile (as with many complex ARIA widgets)!

grid

<!-- interactive table/spreadsheet --><div role="grid" > <div role="row" > <div role="columnheader" >...</div> <div role="columnheader" >...</div> </div> <div role="row" > <div role="gridcell" >...</div> <div role="gridcell" >...</div> </div> ...</div>

example: Open Ajax Alliance: Grid example

sometimes better to simplify: Dennis Lembree - Interactive elementswithin a grid layout

managing focus and keyboardinteractions

the basics

to be usable – all interactive controls must be:

•   focusable

•   in the logical tab order

•   visible when they receive focus

•   have a clear indication of focus

•   operable with the keyboard

•   no focus trap

•   focus does not cause a change of context

problem with custom controls

•    <div> , <span> etc. are not standard controls with defined behaviors

•   not focusable with keyboard by default

solution

•   ideally, use native focusable HTML controls ( <a> , <button> , etc.)

•   or add tabindex="0" , appropriate role , and manually handlekeyboard interactions

complex widgets and focus

•   generally, complex widgets (group of radio buttons, menus, listboxes,tab lists) only have a single "tab stop"

•   interactions within the widget handled programmatically

•    TAB / SHIFT + TAB moves to the next widget, not to sub-components

keyboard navigation within widgets

•   either: "roving" tabindex (only one element inside widget hastabindex="0" , all others tabindex="-1" )

•   or: focus remains on widget itself, denote active child element witharia-activedescendant (and manually scroll into view, provide

highlight via CSS)

not all complex widgets lend themselves to "roving" tabindex - e.g.role="combobox" needs aria-activedescendant , as actual focus

must remain inside the textbox.

W3C WAI-ARIA 1.0 Authoring Practices - 3.1.3. Keyboard Navigationwithin Widgets

<!-- roving tabindex example --><div role="radiogroup"> <div role="radio" aria-checked="true" tabindex="0" ...> ... <div role="radio" aria-checked="false" tabindex="-1" ...> ... <div role="radio" aria-checked="false" tabindex="-1" ...> ...</div>

only one radio button inside the group has focus

<!-- roving tabindex example --><div role="radiogroup"> <div role="radio" aria-checked="false" tabindex="-1" ...> ... <div role="radio" aria-checked="true" tabindex="0" ...> ... <div role="radio" aria-checked="false" tabindex="-1" ...> ...</div>

changing the selection dynamically changes tabindex , aria-checked and sets focus() on the newly selected radio button

<!-- activedescendant example --><div role="radiogroup" tabindex="0" aria-activedescendant="rad1" > <div role="radio" id="rad1" aria-checked="true" ...> ... <div role="radio" id="rad2" aria-checked="false" ...> ... <div role="radio" id="rad3" aria-checked="false" ...> ...</div>

radiogroup itself takes focus - selected radio button only identifiedvia aria-activedescendant

<!-- activedescendant example --><div role="radiogroup" tabindex="0" aria-activedescendant="rad2" > <div role="radio" id="rad1" aria-checked="false" ...> ... <div role="radio" id="rad2" aria-checked="true" ...> ... <div role="radio" id="rad3" aria-checked="false" ...> ...</div>

changing the selection dynamically changes aria-activedescendant on the radiogroup , aria-checked on the radiobutton - but focus still remains only on the radiogroup

Medialize - ally.js

live regions

making AT aware of content changes

best way to notify users of assistive technologies of new content (anew element added to the page, made visible, a change in text) is tomove focus() programmatically to it.

but this is not always possible, as it would interrupt the user's currentactions...

example: faked button with notification via focus()

ARIA live regions

•   announce a change on content without moving focus to it

•    aria-live : off , polite , assertive

•    aria-atomic

•    aria-relevant

example: faked button with notification using aria-live and aria-atomic

some role s have implicit live region - e.g. role="alert"

unfortunately, support is...flaky

Karl Groves - jQuery Live Regions

drag & drop

Dev.Opera - Gez Lemon - Accessible Drag and Drop Using WAI-ARIA

•    aria-grabbed

•    aria-dropeffect

example: Open Ajax Alliance - Drag and Drop / Gez Lemon's Drag andDrop example

support is still bad (particularly on mobile) - consider refactoring orproviding alternative instead

what about role="application" ?

document vs application mode

assistive technologies/screenreaders generally operate in two modes:document mode and application mode (terminology varies)

•   in document mode ("reading mode"), user can navigate freely throughthe page/content with keyboard shortcuts provided by AT

•   in application mode ("forms mode"), keystrokes are mostly passeddirectly to page, which needs to handle all interactions

SSB Bart Group - How Windows Screen Readers Work on the Web

role="application"forces application mode

the result

•   all keystrokes can now be handled via JavaScript

•   need to ensure any text/content is explicitly associated withfocusable elements, use live regions, etc

•   any content areas should be given role="document" to re-enableuser control

(Google Mail doesn't use role="application" ... for illustrative purposes only)

you don't need role="application" ...

•   for native HTML elements ( <button> , <select> etc)

•   for common complex ARIA widgets (treeview, slider, dialog, etc)

in both cases, assistive technologies recognise them andautomatically switch to applicable mode / pass relevant keystrokes tothe page

tl;dr: in most situations, you won't need role="application"

use role="application" withcaution/sparingly

(generally not to entire page)

use role="document" to thendenote content areas

Marco Zehe - If you use the WAI-ARIA role “application”, please do sowisely!

ARIA to explicitly definerelationships

beyond what HTML offers natively

example: form enhancement using aria-describedby (plus aria-required and aria-invalid )

example: form enhancement using aria-labelledby

ARIA for remediation

if your page/app uses inappropriate markup, ARIA can be used topatch some of the issues (if it can't be fixed properly)...

<table role="presentation" > <tr> <td>Layout column 1</td> <td>Layout column 2</td> </tr></table>

example: layout table remediation

web components, angular, etc?

Polymer - Paper Elements - Slider

Addy Osmani / Alice Boxhall - Accessible Web Components

W3C Editor's Draft - Custom Elements - 11.1 Custom Tag example

AngularJS Developer Guide - Accessibility with ngAria

recap...

get in touch@patrick_h_lauke

github.com/patrickhlauke/ariapatrickhlauke.github.io/aria/presentation/

slideshare.net/reduxpaciellogroup.com

splintered.co.uk