accessibility of html5 and rich internet applications (part 2)
DESCRIPTION
Hans Hillen (TPG) Steve Faulkner (TPG). Accessibility of HTML5 and Rich Internet Applications (Part 2). In This Part:. Keyboard and Focus Management Labeling and Describing Live Regions Form Validation Mode Conflicts Fallback Solutions. Keyboard and Focus Management . - PowerPoint PPT PresentationTRANSCRIPT
Accessibility of HTML5 and Rich Internet Applications (Part 2)
Hans Hillen (TPG)Steve Faulkner (TPG)
02 / 25 / 13 Accessibility of HTML5 and Rich Internet Applications - CSUN 2013 1
In This Part:
Keyboard and Focus Management Labeling and Describing Live Regions Form Validation Mode Conflicts Fallback Solutions
02 / 25 / 13 Accessibility of HTML5 and Rich Internet Applications - CSUN 2013 2
Keyboard and Focus Management
02 / 25 / 13 Accessibility of HTML5 and Rich Internet Applications - CSUN 2013 3
Accessibility of HTML5 and Rich Internet Applications - CSUN 2013 4
The Problem with Custom ControlsProblem: Images, divs, spans etc. are not standard controls with
defined behaviorso Not focusable with keyboardo Have a default tab ordero 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 / 25 / 13
Keyboard Issues in a Nutshell Reachability: Moving keyboard focus to a
widget o Through tab order
• Native focusable controls or tabindex=“0”o Through globally defined shortcuto By activating another widget
Operability: Interacting with a widgeto All functionally should be performable through
keyboard and mouse input02 / 25 / 13 Accessibility of HTML5 and Rich Internet Applications - CSUN 2013 5
Focus & Keyboard Accessibility 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 / 25 / 13 Accessibility of HTML5 and Rich Internet Applications - CSUN 2013 6
Accessibility of HTML5 and Rich Internet Applications - CSUN 2013 7
Keyboard Handling Every widget needs to be operable by keyboard.
common keystrokes are:o Arrow keyso Home, end, page up, page downo Enter, spaceo ESC
Mimic the navigate in the desktop environmento DHML Style Guide: http://dev.aol.com/dhtml_style_guide o ARIA Best Practices:
http://www.w3.org/WAI/PF/aria-practices/
02 / 25 / 13
Skipping Mechanisms 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
misusedo But keyboard users still need to be able to skip
Other alternatives for skipping:o Collapsible sectionso 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 / 25 / 13 Accessibility of HTML5 and Rich Internet Applications - CSUN 2013 8
Popup Dialogs and Windows More and more web apps use HTML based popup dialogs rather than actual
browser windows/dialogso Get a screen reader to perceive it properly using role="dialog"
Dialogs should have their own tab ordero Focus should "wrap"
For modal dialogs, it should not be possible to interact with the main page o Prevent keyboard accesso 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) keyso Focus should be placed back on a logical element, e.g. the button that triggered the
dialog.
02 / 25 / 13 Accessibility of HTML5 and Rich Internet Applications - CSUN 2013 9
Selection & Editing
Trees, Lists, Grids can support single or multiple selectionoMultiple 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 keyboard02 / 25 / 13 Accessibility of HTML5 and Rich Internet Applications - CSUN 2013 10
Labeling and Describing
02 / 25 / 13 Accessibility of HTML5 and Rich Internet Applications - CSUN 2013 11
Labeling in a Nutshell All of these must have an accessible name:
o Every interactive widgeto 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-labelledby2. aria-label3. Associated label (<label for=“myControl”>) or alt attribute4. Text contents5. Title attribute
Optionally, add an accessible description for additional info02 / 25 / 13 Accessibility of HTML5 and Rich Internet Applications - CSUN 2013 12
Labeling And Describing Widgets (2) 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 / 25 / 13 Accessibility of HTML5 and Rich Internet Applications - CSUN 2013 13
Labeling containers 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" aria-describedby="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 / 25 / 13 Accessibility of HTML5 and Rich Internet Applications - CSUN 2013 14
Labeling Tables
<caption> still alive and kickingo In HTML5 it’s allowed to nest headings
Summary attribute obsolete in HTML5<table>
<caption><h2>Animals</h2>
</caption><tbody>
<tr><th scope="col" abbr="pet name">Name<th scope="col">Age</th><th scope="col">Species</th>
</tr>...
</tbody></table>
02 / 25 / 13 Accessibility of HTML5 and Rich Internet Applications - CSUN 2013 15
Live Regions
02 / 25 / 13 Accessibility of HTML5 and Rich Internet Applications - CSUN 2013 16
Accessibility of HTML5 and Rich Internet Applications - CSUN 2013 17
ARIA Live Regions Problem: content is updated dynamically on screen may not be apparent to screen
reader userso No page refresh, no screen reader announcemento Change is only announced by stealing focuso Users miss relevant informationo Users have to ‘search’ for updated page content
Solution: live regions indicate page updates without losing focuso 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 clocko Announce important changes immediately / as convenient
02 / 25 / 13
Accessibility of HTML5 and Rich Internet Applications - CSUN 2013 18
“Built In” Live Regions Role=“alert” for one-time, high-priority notifications
o Shown for a period of time, or until the cause of the alert is solvedo Basic message, no complex contento 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 fieldso 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 / 25 / 13
Accessibility of HTML5 and Rich Internet Applications - CSUN 2013 19
How to Use Live Regions1. Identify which part (containing HTML element) is expected to be
updated2. To make it live, add ‘aria-live’ attribute with a politeness value:
o Off (default): Do not speak this region o Polite: Speak this region when the user is idleo Assertive: Speak this region as soon as possible
3. 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 updatingo aria-labelledby, aria-describedby: label and describe regions
02 / 25 / 13
Forms & Validation
02 / 25 / 13 Accessibility of HTML5 and Rich Internet Applications - CSUN 2013 20
Forms & ARIA You can used ARIA to make your form validation easier to manage.
o aria-required & aria-invalid stateso Role="alert" to flag validation errors immediately
Use validation summaries invalid entries easier to findo Use role=“group” or Role="alertdialog" to mark up the summaryo Link to corresponding invalid controls from summary itemso Use different scope levels if necessary
Visual tooltips: Useful for validation messages and formatting instructionso Tooltips must be keyboard accessible o Tooltip text must be associated with the form control using aria-
describedby Live Regions: Use for concise feedback messages02 / 25 / 13 Accessibility of HTML5 and Rich Internet Applications - CSUN 2013 21
Mode Conflicts
02 / 25 / 13 Accessibility of HTML5 and Rich Internet Applications - CSUN 2013 22
Accessibility of HTML5 and Rich Internet Applications - CSUN 2013 23
Role = Application Screen readers normally browse in ‘virtual mode’
o Navigates a virtual copy of the web pageo Intercepts all keystrokes for its own navigation (e.g. ‘H’ for heading
navigation) For dynamic Web apps, virtual mode may need to be
turned offo Interactive widgets need to define the keystrokes themselveso Content needs to be live, not a virtual copyo Automatically switches between virtual and non-virtual mode
role=“application”o Screen reader switches to non-virtual for these elementso Must provide all keyboard navigation when in role=“application” modeo Screen readers don’t intercept keystrokes then, so typical functions will
not work
02 / 25 / 13
Accessibility of HTML5 and Rich Internet Applications - CSUN 2013 24
Role = Document For apps with ‘reading’ or ‘editing’ sections
o A reading pane in an email cliento Screen reader switches back to virtual mode,
standard ‘web page reading’ shortcuts work againo 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 / 25 / 13
Fall Back Solutions
02 / 25 / 13 Accessibility of HTML5 and Rich Internet Applications - CSUN 2013 25
Accessibility of HTML5 and Rich Internet Applications - CSUN 2013 26
Role = Presentation 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> elemento Textual content read by the screen reader but table is ignored
02 / 25 / 13
Fall back solution for dialogs In IE, some versions of 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 bordero Move legend off-screen
<fieldset role="dialog" aria-labelledby="dialogTitle" aria-describedby="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 / 25 / 13 Accessibility of HTML5 and Rich Internet Applications - CSUN 2013 27
Fallback solutions for link buttons 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 / 25 / 13 Accessibility of HTML5 and Rich Internet Applications - CSUN 2013 28
Hiding Content
Three types of hiding:1. Hiding content visually and from AT:2. Hiding content visually, but not from AT3. Hiding content from AT, but not visually
02 / 25 / 13 Accessibility of HTML5 and Rich Internet Applications - CSUN 2013 29
1. Hiding Content from All Display: none;
o Hides content both visually and from AT products
oOnly works when CSS is supported (by user agent, user, or AT product)
oOnly 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 / 25 / 13 Accessibility of HTML5 and Rich Internet Applications - CSUN 2013 30
2. Hiding Content Visually 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 CSSo 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 / 25 / 13 Accessibility of HTML5 and Rich Internet Applications - CSUN 2013 31
3. Hiding Content From AT Only Sometimes developers want to hide content from
screen readers, e.g.:o Duplicate controlso 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:• 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 / 25 / 13 Accessibility of HTML5 and Rich Internet Applications - CSUN 2013 32
ARIA-HIDDEN
<a href="#"> <span aria-hidden="true">A</span> <span class="HiddenText">Small Font</span></a>
02 / 25 / 13 Accessibility of HTML5 and Rich Internet Applications - CSUN 2013 33
JAWS 14 and NVDA will honor aria-hidden in IE, Firefox and Chromeo regardless of whether the browsers actually
expose it! VoiceOver does not honor aria-hidden at
this point
Grids and Tables
02 / 25 / 13 Accessibility of HTML5 and Rich Internet Applications - CSUN 2013 34
Fixing Incorrect Grid Structure (1) 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
rowso 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 tableso Association between column headers and cells is brokeno Screen reader's table navigation is broken
02 / 25 / 13 Accessibility of HTML5 and Rich Internet Applications - CSUN 2013 35
Fixing Incorrect Grid Structure (2) 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 readerso Use a combination of "grid", "row", "gridcell",
"columnheader" roles to make the screen reader see one big grid.
02 / 25 / 13 Accessibility of HTML5 and Rich Internet Applications - CSUN 2013 36
Fixing Incorrect Grid Structure (3) 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 / 25 / 13 Accessibility of HTML5 and Rich Internet Applications - CSUN 2013 37
Anything Else?
Questions? Additional Topics? Course Material:
http://www.paciellogroup.com/training/CSUN2013
02 / 25 / 13 Accessibility of HTML5 and Rich Internet Applications - CSUN 2013 38