Transcript Accessibility of Rich Internet

Hans Hillen (TPG)
Steve Faulkner (TPG)
03 / 15 / 11
Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
1
New Solutions
New Problems
will be a beautiful thing
 What is meant by support?
oFeatures provided
oFeatures implemented
oFeatures implemented with accessibility
support
• In Browsers
• In Assistive Technology
 Features are implemented in browsers
o Useful site - When can I use...
 Does not mean features are usable by all users even
if they use a browser that ‘supports’ a feature.
 Firefox video support
 No major browser has full accessibility support for
HTML5 video
 Providing full accessibility support means jumping
through hoops:
 Scripted controls
 Scripted captioning and audio description
 All major browser now support HTML5 video
 Meaning you can watch/hear a video and use the
controls if you can see, hear and use a mouse
Terril Thompson:
“That all sounds like a lot of work. Isn't HTML5 <video>
supposed to be easy?”
“Ultimately though ... HTML5 <video> is easy. A novice web
developer can pop a video onto their web page in less
than a minute with some very simple HTML markup.
Unfortunately if they do that today it won't be accessible
without a little additional sweat. Someday, hopefully,
browsers will do all of this work for us, and every video
will be accessible. That's what we're working toward.”
 All major browser now support HTML5 canvas
 Meaning dynamic images, animation, games and
content is available without plug-ins
 Only one major browser supports HTML5 canvas
accessibility
 And only partially
 The accessibility features of canvas are still being
specified.
 What is implemented in IE9 gives an idea of how
canvas accessibility will work.
 Example
 What’s it mean?
o Conveys semantics required to understand and interact.
o Can be used in a device independent way
o Uses common design patterns
o Accomodates browser & OS accessibility features
o interoperable
Accessibility API
Input device
browser
role=button
state=focused
value= search
action=press
Accessibility APIs
roles
states
properties
interaction
MSAA
Iaccessible2
UI automation
AX
STK
+ device independent
interaction
MSAA inspect.32.exe or inspect.exe
 Accessibility features for a button a whirlwind tour
 When implemented and implemented accessibly,
will make it a lot easier to provide accessible UI’s
 Current implementation is patchy and where
implemented, accessibility support is poor.
 Lets take a quick tour: HTML5 form controls
 Minor addition to HTML5
 Yet brings new headaches for developers and users
o Poor contrast
o disappears
o Results in different accessible labels across browsers and
labelling methods
o HTML5 Accessibility Chops: the placeholder attribute
 ARIA defines roles that act as landmarks for intra
page navigation and identification of common
content areas
 HTML5 defines section elements for common
semantic features of pages, some old some new
 There is some overlap
 HTML5 section elements are largely unimplemented
(accessible).
o FireFox has some experimental implementation
 Examples of use
o Bruce Lawson’s site
o Wordpress
 Mappings between section elements and landmark
roles:
o HTML5 Accessibility Chops: section elements
 Landmark roles identify important sections commonly
found in web pages:
o Applied to container elements
o Allow AT users to quickly see which sections a page has and
navigate to individual sections
o In JAWS, use the following commands:
• ; (semicolon):jump to next landmark
• Shift + ;(semicolon): jump to previous landmark
• Ctrl + Ins + ;(semicolon): Show list of available landmarks
o In NVDA use
• D to jump to next landmark
• Shift + D to previous landmark
• NVDA+f7 Show list of available landmarks

Available Landmark Roles
 Banner: A region that contains the primary heading or web site title. (site







logo, login details, etc.)
Search: The search tool of a web document.
Navigation: The documents Navigation menus and links.
Main: The main content of web document.
Form: contains a collection of items and objects that, as a whole,
combine to create a form.
Complementary: content that has meaning outside the page as well
(e.g. a sidebar with related articles).
Contentinfo: Metadata that applies to the parent document (e.g. copy
right disclaimers, company info).
Application: See next slide.
Using WAI ARIA Landmark Roles

Normally, Screen readers browse in ‘virtual mode’
o Screen reader navigates a virtual copy of the web page.
o Screen reader intercepts all keystrokes, and uses them for its
own virtual navigation (e.g. ‘H’ for heading navigation).

For dynamic web apps, virtual mode may need to be turned
off
o Interactive widgets need the keystrokes themselves.
o Content needs to be live, not a virtual copy.
o Normally, the user had to switch manually between virtual an
non-virtual mode.

role=“application”
o When applied a container element the screen reader will
automatically switch to non virtual mode.

Some parts of your application may actually be treated as a
document rather than application UI. For example:
o A web based email client has panes in which messages are read
or created.
o A blog viewer web application can load articles to read.

In these parts, the screen reader user needs virtual mode:
o To make use of the special navigation that comes with it.
o To be able to read non focusable content

role=“document”
o When applied to a container inside an application role, the
screen reader will switch back to virtual mode.
o Allows documents to be read or edited inside a web app.
HTML5Accessibility.com
Practical examples
03 / 15 / 11
Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
27
1.
Start with HTML elements
o Any HTML element can be extended with ARIA. Examples:
• <span>, <div>, <table>, <td>, <ul>, <li>, <p>, <img>
2.
Add a ‘role’ attribute.
o Only one role is allowed per element,
• <span role=“checkbox”>
• <div role=“tab”>
3.
Add state /properties attributes if applicable.
o A single elements can have one or more states
• <span role=“checkbox” aria-checked=“true”>
• <div role=“button” aria-pressed=“true” aria-disabled=“true”>
o Attribute names always start with ‘aria-’
03 / 15 / 11
Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
28

ARIA doesn’t change anything to your widget:
o It only provides semantic information for AT
o Behavior and styles still need to be provided by developer

Some HTML elements already have a default, ‘native’ role.
o e.g. <td> (role = ‘cell’), <a> (role=“link”), <input>, <li>
o Native role is always overridden by ARIA role
• E.g. <table role=“tab”> is announced as a tab by a screen reader rather than a table

Role values generally stay the same, state values can change
o Trough user input (event handlers),
o elem.setAttribute(‘aria-selected’, ‘false’);

Some roles have required state attributes
o E.g. A ‘radio’ role requires the ‘aria-checked’ state

Requirements for an ‘ARIA ready’ widget: Focusable & Keyboard Accessible!
03 / 15 / 11
Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
29
03 / 15 / 11
Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
30

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
03 / 15 / 11
Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
31

Every Widget must be operable by keyboard

Create you own event handlers to manage
o For composite widgets (trees, menus, etc.) individual parts can be
reached using other keys, such as:
• Arrow keys
• Home, End, PgUp, PgDn
• Enter, Space

Keep in mind: how would I navigate this widget in a desktop
environment?

Mouse based actions must also be available through the keyboard.
For example:
o Write Key handlers trigger the same results mouse events
o Use context menus to make relevant options accessible.
03 / 15 / 11
Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
32
 Not sure about how a widget should behave with the
keyboard?
o Use the DHTML Style Guide:
o http://dev.aol.com/dhtml_style_guide
03 / 15 / 11
Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
33
 Make sure that all widgets are reachable through
keyboard
o Depend on Tab order (default or custom?)
o Support global keyboard shortcuts
• How do you notify your users?
o Implementing a custom focus manager
• Might be best solution for very complex UI's
• Let go of the traditional tab order idea ("all focusable elements
must be reachable by tab order")
• Provide intuitive skipping mechanisms
03 / 15 / 11
Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
34

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 is
misused

Better 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
03 / 15 / 11
Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
35

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.
03 / 15 / 11
Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
36
 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
03 / 15 / 11
Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
37

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 with links to make invalid entries easier
to find
o Role="alertdialog" to mark up the summary

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 ariadescribedby
03 / 15 / 11
Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
38
03 / 15 / 11
Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
39
 Every widget need some kind of ‘identity’, or
‘label’ that AT can use to announce it to the user:
o Singular interactive widgets, e.g. button, checkbox
o Composite widgets, such as trees or toolbars:
• Requires both a label for the widget as a whole and its
individual parts
o Container widgets:
• A window or Pane requires a title
 To label ARIA widgets:
o You could use standard HTML labeling techniques:
• Label element and title attributes.
o Or: Aria-labelledby, aria-label, & aria-describedby
03 / 15 / 11
Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
40

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”>
...
03 / 15 / 11
Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
41
 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>
03 / 15 / 11
Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
42
03 / 15 / 11
Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
43
 Live regions
o Parts of a Web page that the author expects to change and
where new information maybe added updated or
removed.
o Examples of live regions:
•
•
•
•
•
03 / 15 / 11
Status updates
Changing stock information
Chat windows
Log windows (chat transcript logs),
notification areas (status, alerts)
Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
44
 Live regions enable assistive technologies (such
as screen readers) to inform users of updates.
 Without live regions, AT users may not be aware
that content elsewhere on the page has changed.
o Users miss out on relevant info
o Users have to ‘search’ for updated page content
 With live regions, updated information is
announced automatically.
 Example: stock updater
03 / 15 / 11
Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
45
 To identify a live region, add the aria-live attribute.
 One of the most important concepts behind live
regions is politeness.
 Politeness indicates how much priority a live region
has.
 The following politeness values are available for aria-
live: off, polite, and assertive.
03 / 15 / 11
Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
46

Aria-live="off"
o Default value, identical to not setting aria-live. Examples:
• A DHTML clock
• Number of users currently online

Aria-live=“polite”
o Updates are announced but won’t interrupt the user
o Should be used in most situations involving live regions that present
new information to users:
• Updates to news headlines, twitter alerts, monitored stocks, etc.

Aria-live=“assertive”
o Updates are announced and interrupt what the user is doing
• Only use for important updates that require immediate attention.
• Warnings & error notifications.
• Session timeout notifications
03 / 15 / 11
Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
47
 aria-atomic="true | false"
o Optional. Indicates if assistive technology should present
all or part of the changed region to the user.
• aria-atomic=“true”: assistive technology should announce the
entire region when part of it changes;
• aria-atomic=“false”: only the part of the region that changed should
be announced on its own.
 aria-busy="true | false"
o Optional. Indicates whether region has finished updating,
or whether certain parts are still expected to change.
• aria-busy=“true”: region not fully updated yet, AT should wait.
• aria-busy=“false”: region update is complete, AT can start
announcing the update.
03 / 15 / 11
Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
48

Role=“alert”
o Used for one-time, high priority notifications.
o Should be shown for a period of time, or until the cause of the alert is
solved.
o Should contain a basic message, no complex content.
o The element with the alert role does not need to be focused to be
announced.
• Elements with role=“alert” receive aria-live=“assertive” and aria-atomic=“true” as
default values.
• Screen reader automatically announces the alert text, after saying ‘alert’
o Example: Form validation sample

Role=“alertdialog”
o Similar to Alert, but meant for actual (DHTML ) dialog windows .
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.
03 / 15 / 11
Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
49

Role=“status”
o Contains advisory information for the user but is not important enough to
justify an alert.
o Automatically receives aria-live=“polite”
o Should not receive focus

Role=“timer”
o A numerical counter which indicates an amount of elapsed time from a
start point, or the time remaining until an end point.
o Should be updated at regular intervals

Role=“marquee”
o A type of live region where non-essential information changes frequently
• E.g. stock tickers, banners

Role=“log”
o Like marquee, but information is added in meaningful order and old
information may disappear.
03 / 15 / 11
Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
50
03 / 15 / 11
Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
51

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>
03 / 15 / 11
Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
52

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>
03 / 15 / 11
Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
53
 Sometimes a widget structure is not explicit via the
DOM and logical structure of a page.
 Aria-owns=“IDREFS”
o Indicates that the element(s) referenced by the IDs should
be considered a child of the element that has this
attribute.
<h3 id="header">Vegetables</h3>
<ul role="list" aria-labelledby="header" aria-owns="external_listitem">
<li role="listitem">Carrot</li>
<li role="listitem">Tomato</li>
<li role="listitem">Lettuce</li>
</ul>
…
<div role="listitem" id="external_listitem">Asparagus</div>
03 / 15 / 11
Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
54

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
03 / 15 / 11
Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
55
 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.
03 / 15 / 11
Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
56
 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>
03 / 15 / 11
Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
57
03 / 15 / 11
Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
58

To be WCAG 2 compliant, background and foreground colors for
text needs to have sufficient contrast

If that's not possible, it's an option to design a high(er) contrast
theme that the user can enable
03 / 15 / 11
Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
59

High Contrast Mode:
o Windows OS specific feature, inherited by browser
o Background & foreground colors are overridden
o Background images are stripped out

Problematic for widgets:
o They often use background color and images to indicate information (e.g.
icons & selection highlights)

Solution:
o Detect whether high contrast mode is active
o If so, provide workarounds:
• Inject html images or text to DOM
• Add additional visual indications, e.g. font weight, decoration & style
03 / 15 / 11
Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
60
03 / 15 / 11
Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
61
03 / 15 / 11
Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
62

To test if your ARIA works:
o Use a screen reader to try out your aria widgets and roles.
• JAWS 10 has decent support, but misses certain things
• NVDA has better ARIA support, is free and has a ‘silent’ mode
• Compare with widgets in Desktop to know what to expect.

Using MSAA Tools
o Inspect32
• quick and effective
• Shows Focus role, states, name and description
o AccExplorer
• Lets you have a look at your page’s underlying ‘accessible tree

Using Browser Tools
o Firebug for firefox
o Developer Tools for IE8
03 / 15 / 11
Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
63
 Get Started with ARIA:
o http://www.w3.org/WAI/intro/aria
 ARIA Best Practices:
o http://www.w3.org/TR/wai-aria-practices/
 DHTML Styleguide:
o http://dev.aol.com/dhtml_style_guide
03 / 15 / 11
Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
64