Transcript Hans Hillen (TPG) Steve Faulkner (TPG) 02 / 27 / 12 Accessibility of HTML5 and Rich Internet Applications - CSUN 2012

Hans Hillen (TPG)
Steve Faulkner (TPG)
02 / 27 / 12
Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
1
 Keyboard and Focus Management
 Labeling and Describing
 Live Regions
 Form Validation
 Mode Conflicts
 Fallback Solutions
02 / 27 / 12
Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
2
02 / 27 / 12
Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
3
Problem:

Images, divs, spans etc. are not standard controls with
defined behaviors
o Not focusable with keyboard
o Have a default tab order
o Behavior is unknown
Solution:

Ideally: Use native focusable HTML controls
o <a>, <input type=“image” />, <button>, etc.

Or manually define keyboard focus and behavior needs
02 / 27 / 12
Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
4
 Reachability: Moving keyboard focus to a widget
o Through tab order
• Native focusable controls or tabindex=“0”
o Through globally defined shortcut
o By activating another widget
 Operability: Interacting with a widget
o All functionally should be performable through keyboard
and mouse input
02 / 27 / 12
Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
5

To be accessible, ARIA input widgets need focus
o Use natively focusable elements, such as <a>, <input />, etc
o Add ‘tabindex’ attribute for non focusable elements, such as
<span>, <div>, etc.
• Tabindex=“0”: Element becomes part of the tab order
• Tabindex=“-1” (Element is not in tab order, but focusable)
o For composite widgets (menus, trees, grids, etc.):
• Every widget should only have 1 stop in the tab order.
• Keep track where your widget’s current tab stop is:
o Alternative for tabindex: ‘aria-activedescendant=“<idref>”
• Focus remains on outer container
• AT perceives element with the specified ID as being focused.
• You must manually highlight this active element, e.g. With CSS
02 / 27 / 12
Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
6

Every widget needs to be operable by keyboard.
common keystrokes are:
o Arrow keys
o Home, end, page up, page down
o Enter, space
o ESC

Mimic the navigate in the desktop environment
o DHML Style Guide: http://dev.aol.com/dhtml_style_guide
o ARIA Best Practices: http://www.w3.org/TR/wai-aria-practices/
02 / 27 / 12
Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
7

The ability to skip content is crucial for both screen
reader and keyboard users

Skip links are out of date, out of fashion and often
misused
o But keyboard users still need to be able to skip

Other alternatives for skipping:
o Collapsible sections
o Consistent shortcuts (e.g. a shortcut that moves focus between
panes and dialogs)
o Custom focus manager that allows the user to move focus into
a container to skip its contents
02 / 27 / 12
Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
8

More and more web apps use HTML based popup dialogs rather than actual
browser windows/dialogs
o Get a screen reader to perceive it properly using role="dialog"

Dialogs should have their own tab order
o Focus should "wrap"

For modal dialogs, it should not be possible to interact with the main page
o Prevent keyboard access
o Virtual mode access can't be prevented

For non modal dialogs, provide shortcut to switch between dialog and main page

If dialog supports moving or resizing, these features must be keyboard accessible

Support closing dialogs using Enter (OK) or Escape (Cancel) keys
o Focus should be placed back on a logical element, e.g. the button that triggered the dialog.
02 / 27 / 12
Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
9
 Trees, Lists, Grids can support single or multiple
selection
o Multiple selection must be keyboard accessible, for
example:
• Shift + arrow keys: contiguous selection
• Ctrl + arrow keys: move focus without selection
• Ctrl + space: Toggle focused item in selection (discontiguous
selection)
 Editable grids need to support switching to edit
mode by keyboard
02 / 27 / 12
Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
10
02 / 27 / 12
Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
11

All of these must have an accessible name:
o Every interactive widget
o Composite widgets (menu(bar), toolbar, tablist, tree, grid)
o Groups, regions and landmarks

Browsers determines an element’s accessible name by checking the
following :
1.
aria-labelledby
2.
aria-label
3.
Associated label (<label for=“myControl”>) or alt attribute
4.
Text contents
5.
Title attribute
Optionally, add an accessible description for additional info
02 / 27 / 12
Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
12

Aria-labelledby=“elemID”
o Points to element ID that identifies the widget.
o Can also use regular label element / title attribute

Aria-describedby=“elemID”
o Optional, provides additional info besides identity
o Useful for additional info, instructions, hints

Aria-label=“text”
o Only use when no on-screen text

Title attribute will also work
<h2 id=“treeLbl”>My Folders</h2>
<p id=“treeDesc” class=“hidden”>Each tree item has a context menu with more options</p>
<div role=“tree” aria-labelledby=“treeLbl” aria-describedby=“treeDesc”>
02 / 27 / 12
Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
13

Aria-labelledby=“IDREFS”
o Value is one or more IDs of elements that identifiy the widget.
o The elements ‘aria-labelledby’ targets can be any kind of text based element, anywhere
in the document.
o Add multiple Ids to concatinate label text:
• Multiple elements can label one widget, and one element can label multiple widgets. (example)

Aria-describedby=“IDREFS”
o Similar to labelledby, except used for additional description, e.g. Form hints,
instructions, etc.

Aria-label
o Simply takes a string to be used as label.
o Quick and dirty way of making the screen reader say what you want.
o Very easy to use, but only supported in Firefox at the moment.
<h2 id=“treeLbl”>My Folders</h2>
<p class=“hidden”>Each tree item has a context menu with more options</p>
<div role=“tree” aria-labelledby=“treeLbl” aria-describedby=“treeDesc”>
...
02 / 27 / 12
Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
14

Containers such as toolbars, dialogs, and regions provide
context for their contents

When the user moves focus into the container, the
screen reader should first announce the container before
announcing the focused control
<div role="dialog" aria-labelledby="dialogTitle" ariadescribedby="dialogDescription">
<h2 id="dialogTitle">Confirm</h2>
<p id="dialogDescription">
Are you sure you want to do that?
</p>
<button>Yes</button>
<button>No</button>
</div>
02 / 27 / 12
Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
15
 <caption> still alive and kicking
o In HTML5 it’s allowed to nest headings
 Summary attribute obsolete in HTML5
02 / 27 / 12
Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
16
02 / 27 / 12
Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
17

Problem: content is updated dynamically on screen may not be apparent to screen reader users
o No page refresh, no screen reader announcement
o Change is only announced by stealing focus
o Users miss relevant information
o Users have to ‘search’ for updated page content

Solution: live regions indicate page updates without losing focus
o Screen readers announce change based on type of live region

Challenge: When should users be informed of the change?
o Ignore trivial changes: changing seconds in a clock
o Announce important changes immediately / as convenient
02 / 27 / 12
Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
18

Role=“alert” for one-time, high-priority notifications
o Shown for a period of time, or until the cause of the alert is solved
o Basic message, no complex content
o The element with the alert role does not need to be focused to be
announced

Role=“alertdialog” is similar to alert, but for actual
(DHTML) dialogs.
o May contain other widgets, such as buttons or other form fields
o Does require a sub-element (such as a ‘confirm’ button) to receive focus

Live regions ‘built into ‘ roles’
• role="timer", "log", "marquee" or "status“ get default live behavior
• Role=“alert” implicitly sets live to assertive
02 / 27 / 12
Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
19
1.
Identify which part (containing HTML element) is expected to be updated
2.
To make it live, add ‘aria-live’ attribute with a politeness value:
o Off (default): Do not speak this region
3.
o Polite:
Speak this region when the user is idle
o Assertive:
Speak this region as soon as possible
Choose whether entire region should be announced or just the part that
changed:
o ‘aria-atomic': true (all) or false (part)
4.
Add other attributes as necessary:
o aria-relevant: choose what to announce:
• Combination of ‘Additions’, ‘removals’, ‘text’, ‘all’
o aria-busy: indicate content is still updating
o aria-labelledby, aria-describedby: label and describe regions
02 / 27 / 12
Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
20
02 / 27 / 12
Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
21

You can used ARIA to make your form validation easier to manage.
o aria-required & aria-invalid states
o Role="alert" to flag validation errors immediately

Use validation summaries invalid entries easier to find
o Use role=“group” or Role="alertdialog" to mark up the summary
o Link to corresponding invalid controls from summary items
o Use different scope levels if necessary

Visual tooltips: Useful for validation messages and formatting instructions
o Tooltips must be keyboard accessible
o Tooltip text must be associated with the form control using aria-describedby

Live Regions: Use for concise feedback messages
02 / 27 / 12
Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
22
02 / 27 / 12
Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
23

Screen readers normally browse in ‘virtual mode’
o Navigates a virtual copy of the web page
o Intercepts all keystrokes for its own navigation (e.g. ‘H’ for heading navigation)

For dynamic Web apps, virtual mode may need to be turned off
o Interactive widgets need to define the keystrokes themselves
o Content needs to be live, not a virtual copy
o Automatically switches between virtual and non-virtual mode

role=“application”
o Screen reader switches to non-virtual for these elements
o Must provide all keyboard navigation when in role=“application” mode
o Screen readers don’t intercept keystrokes then, so typical functions will not work
02 / 27 / 12
Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
24
 For apps with ‘reading’ or ‘editing’ sections
o A reading pane in an email client
o Screen reader switches back to virtual mode, standard
‘web page reading’ shortcuts work again
o Read / edit documents in a web application
 Banner, complementary, contentinfo, main,
navigation, search & form
 When applied to a container inside an application
role, the screen reader switches to virtual mode.
02 / 27 / 12
Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
25
02 / 27 / 12
Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
26

Role=“presentation” overrides existing role
o Useful to ‘hide’ default HTML roles from AT

For example:
o Hide layout tables by adding the role to the <table>
element
o Textual content read by the screen reader but table is ignored
02 / 27 / 12
Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
27

In IE, JAWS currently does not properly announce dialogs when moving
focus into them

It's possible to provide a fallback solution for IE to fix this, using hidden
fieldsets to apply the ARIA dialog markup to
o Hide fieldset's padding, margin, and border
o Move legend off-screen
<fieldset role="dialog" aria-labelledby="dialogTitle" ariadescribedby="dialogDescription">
<legend id="dialogTitle">Confirm</legend>
<p id="dialogDescription">
Are you sure you want to do that?
</p>
<button>Yes</button>
<button>No</button>
</fieldset>
02 / 27 / 12
Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
28

Developers often use links as (icon) buttons
o Side effect: screen reader will announce them as a link, not a button

This can be made accessible by setting role="button"
o Screen reader announces link as button now, but also provides hint for
using a button ("press" space to activate)
• You lie! Links work through the Enter key, Space will scroll down the page
o To make sure JAWS is not lying, you'll have to manually add a key
event handler for the Space key.
<a role="button" onkeypress="handleKeyPress(event);">refresh</a>
02 / 27 / 12
Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
29
 Three types of hiding:
1. Hiding content visually and from AT:
2. Hiding content visually, but not from AT
3. Hiding content from AT, but not visually
02 / 27 / 12
Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
30
 Display: none;
o Hides content both visually and from AT products
o Only works when CSS is supported (by user agent, user, or
AT product)
o Only use to hide content that still ‘makes sense’
• E.g. contents of a collapsible section
o Do not use for content that provides incorrect information
• E.g. preloaded error messages that are not applicable at the
moment, or stale content
• Instead, this content should be removed from the DOM completely
02 / 27 / 12
Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
31

Hiding content off-screen will still make it available for screen readers,
without it being visible

Useful to provide extra information to screen reader users or users that do
not support CSS
o E.g. add hidden headings, screen reader instructions, role & state info for older
technology
/* Old */
.offscreen {
position: absolute;
left: -999em;
}
/* New */
.ui-helper-hidden-accessible {
position: absolute !important;
clip: rect(1px 1px 1px 1px);
clip: rect(1px,1px,1px,1px);
}
02 / 27 / 12
Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
32

Sometimes developers want to hide content from screen
readers, e.g.:
o Duplicate controls
o Redundant information that was already provided through semantic
markup.

Difficult to achieve:
o Role=“presentation” will remove native role, but content is still visible
for AT products
o Aria-hidden=“true” would be ideal, but:
• The spec did not intend for aria-hidden to be used this way
• Browsers handle aria-hidden differently
• IE does nothing
• FF exposes content but marks it as hidden
• Chrome does not expose content (i.e. truly hides it)
02 / 27 / 12
Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
33
02 / 27 / 12
Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
34

Some developers will use multiple HTML <table>
elements to create one single grid. For example:
o One <table> for the header row, one <table> for the body rows
o One <table> for every single row

Why? Because this is easier to manage, style, position,
drag & drop, etc.

Screen reader does not perceive one single table, but it
sees two ore more separate tables
o Association between column headers and cells is broken
o Screen reader's table navigation is broken
02 / 27 / 12
Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
35
 If using a single table is not feasible, use ARIA to fix
the grid structure as perceived by the screen reader
o Use role="presentation" to hide the original table
elements form the screen readers
o Use a combination of "grid", "row", "gridcell",
"columnheader" roles to make the screen reader see one
big grid.
02 / 27 / 12
Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
36
 Using ARIA to create a correct grid structure
<div role="grid">
<table role="presentation">
<tr role="row">
<th role="columnheader">Dog Names</th>
<th role="columnheader">Cat Names</th>
<th role="columnheader">Cow names</th>
</tr>
</table>
<table role="presentation">
<tr role="row">
<td role="gridcell">Fido</td>
<td role="gridcell">Whiskers</td>
<td role="gridcell">Clarabella</td>
</tr>
</table>
</div>
02 / 27 / 12
Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
37
 Questions?
 Additional Topics?
 Course Material:
http://www.paciellogroup.com/training/CSUN2012
02 / 27 / 12
Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
38