Hans Hillen Steve Faulkner In This Part Keyboard and Focus Management Form Validation Screen Reader Mode Conflicts Solutions Workarounds and Considerations 2 Keyboard and Focus Management ID: 363475
Download Presentation The PPT/PDF document "Accessibility of HTML5 and Rich Internet..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
Accessibility of HTML5 and Rich Internet Applications (Part 2)
Hans Hillen
Steve FaulknerSlide2
In This Part:
Keyboard and Focus Management
Form Validation
Screen Reader Mode Conflicts Solutions, Workarounds and Considerations
2Slide3
Keyboard and Focus Management
3Slide4
The Problem with Custom Controls
Problem:
Images, divs, spans etc. are not standard controls with defined behaviors
Not focusable with keyboardHave a default tab orderBehavior is unknownSolution:Ideally: Use native focusable HTML controls <a>, <input type=“image” />, <button>, etc.
Or manually define keyboard focus and behavior
needsSlide5
Keyboard Issues In A Nutshell
Reachability: Moving keyboard focus to a widget
Through tab order
Native focusable controls or tabindex=“0”Through globally defined shortcutBy activating another widget Operability: Interacting with a widgetAll functionally should be performable through keyboard and mouse input
5Slide6
Focus & Keyboard Accessibility
To be accessible, ARIA input widgets need focus
Use natively focusable elements, such as <a>, <input />, etc.
Add 'tabindex' attribute for non focusable elements, such as <span>, <div>, etc.Tabindex="0": Element becomes part of the tab orderTabindex="-1" (Element is not in tab order, but focusable)For composite widgets (menus, trees, grids, etc.), use a "roving tabindex
"
:
Every widget should only have 1 stop in the tab order.
Dynamically keep track where your widget’s current tab stop (active part) is:
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
6Slide7
Keyboard Handling
Every widget needs to be operable by keyboard. common keystrokes are:
Arrow keys
Home, end, page up, page downEnter, spaceESCMimic the navigate in the desktop environment ARIA Best Practices: http://www.w3.org/WAI/PF/aria-practices/
Always manage and keep track of your focus. Never let it get lost.
7Slide8
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 misused
But keyboard users still need to be able to skip Other alternatives for skipping:Collapsible sectionsConsistent shortcuts (e.g. a shortcut that moves focus between panes and dialogs)Custom focus manager that allows the user to move focus into a container to skip its contents
8Slide9
Form Validation
9Slide10
ARIA & Form Validation
You can use ARIA to make your form validation easier to manage.
aria-required & aria-invalid states
Role="alert" or live regions can be used to flag validation errors immediately, but are likely to be disruptiveProvide validation feedback both in inline scope and form scopeUse validation summaries invalid entries easier to find
Use
role="group"
or Role="alertdialog" to mark up the
summary
Provide quick access to invalid
fields:
Link to corresponding invalid controls from summary
items
Nice to have: provide global shortcuts
10Slide11
Solutions, Workarounds and Considerations
11Slide12
Fallback solutions for link buttons
Developers often use links as (icon) buttons
Side effect: screen reader will announce them as a link, not a button
This can be made accessible by setting role="button"Screen reader announces link as button now, but also provides hint for using a button ("press" space to activate”)Screen reader lies: Links work through the Enter key, Space will scroll down the page To make sure JAWS is not lying, you'll have to manually add a key event handler for the Space key.Slide13
Screen Reader Mode ConflictsSlide14
VIRTUAL VS NON VIRTUAL MODE
Virtual
Mode
(a.k.a. browse / virtual PC cursor mode
)
Non-Virtual Mode (
a.k.a.
forms / application mode)
Default navigation
m
ode for navigating and reading documents, such
as PDF documents or web pages.
Default
navigation mode for desktop applications, interactive web forms, and web applications (i.e. role=“application”).
User navigates through the document with
a “virtual cursor”, allow
ing static content (e.g. plain text, images, data tables) to be traversed as well.
Only keyboard accessible content
(e.g. focusable elements) or content associated with such elements (e.g. through
aria-labelledby
)
can be accessed.
Screen reader provides special shortcuts and features
to enhance virtual navigation, e.g. heading navigation or link lists. Arrow keys are used for basic sequential navigation.
No special shortcuts
or features are available, except what’s provided by the web page’s level of keyboard accessibility (tabbing, keyboard shortcuts, and scripted movement of keyboard focus).
Screen reader will intercept user’s key strokes and break custom
keyboard behavior, e.g. a custom widget requiring arrow key
input
won’t work in this mode.
Screen
reader lets all keystrokes pass through to the web content. Custom widgets will work as intended provided they are keyboard accessible.Slide15
Role="Application"
Screen readers normally browse in ‘virtual mode’
Navigates a virtual copy of the web page
Intercepts all keystrokes for its own navigation (e.g. ‘H’ for heading navigation)For dynamic Web apps, virtual mode may need to be turned offInteractive widgets need to define the keystrokes themselvesContent needs to be live, not a virtual copyAutomatically switches between virtual and non-virtual mode
role=“application”
Screen reader switches to non-virtual for these elements
Must provide all keyboard navigation when in role=“application” mode
Screen readers don’t intercept keystrokes then, so typical functions will not workSlide16
Role="Document"
For apps with ‘reading’ or ‘editing’ sections
A reading pane in an email client
Screen reader switches back to virtual mode, standard ‘web page reading’ shortcuts work againRead / edit documents in a web applicationBanner, complementary, contentinfo, main, navigation, search & formWhen applied to a container inside an application role, the screen reader switches to virtual mode.
16Slide17
Explaining to Users how Rich Internet Applications (RIA) works
People that depend on assistive technology often:
Expect to be able to tab through all interactive elements
Expect virtual mode to work Expect web content to be like it was in the late 90's:Simple page loads, no dynamic changesSimple Keyboard navigation: Tab, Enter, some times arrow keysWAI – ARIA is meant for "Application UI's"
Requires virtual mode to be disabled
Requires custom shortcuts
Content can update
dynamically
17Slide18
Explaining to Users how Rich Internet Applications (RIA) works (2)
How do you convey this different navigation style to screen reader users?
Modern screen readers have "auto-forms" mode (virtual mode is automatically turned off where applicable
Screen readers will provide basic instructions for interactionsLess experienced users will likely be confusedSighted keyboard users do not get any instructions at all
18Slide19
19
A tab list widget:
Web 1.0: Tab through every tab in the list
Web 2.0: Tab list takes up one tab stop, arrow keys are used for switchingWhich one is correct?
What will the end user expect?
ExampleSlide20
The Perfect Dialog
20Slide21
Dialog: Roles & States
Use role="dialog", combined with:
Aria-labelledby (for dialog title)
Aria-describedby (for dialog message text)Slide22
Dialog: Focus Management
When
dialog opens, focus should move to first focusable element inside the dialog
Focus should "wrap" inside dialog and be contained by it . For modal dialogs: No keyboard access with background content should be possible When the dialog closes, focus should be placed back on a logical element, e.g. the button that triggered the dialog.For modal dialogs: prevent virtual navigation to background using aria-hidden="true"
22Slide23
Dialog: Shortcuts
If dialog supports moving or resizing, these features must be keyboard accessible
For non modal dialogs: provide shortcut to switch between dialog and main page
Support closing dialogs using buttons and Escape key23Slide24
24
"WAI-ARIA provides dialog and alertdialog roles that are to be treated as special case application roles. Like application,
screen readers will leave the main job of keyboard navigation up the dialog
."
WAI-ARIA 1.0 Authoring Practices
Dialog Quote 1:Slide25
25
"When using dialog,
all static text must be associated with widgets, groups or panes using the aria-labelledby and aria-describedby properties
, otherwise it will not be read by the screen reader when the user navigates to the related widget or group. "
WAI-ARIA 1.0 Authoring Practices
Dialog Quote 2:Slide26
Dialog Pitfalls
According to the ARIA Best Practices document:
A dialog is a special type of "application window"
All content must be (associated with) keyboard accessible content. Regular static is content not allowed.Virtual navigation by screen readers is not allowedThis works for simple dialogs…But not for complex dialog content often found in real life projects, which may have a large amount of static contentTo force support for virtual navigation, role=“document” can be wrapped around the dialog
content.
Focus management
For dialogs with a large amount of (scrollable) content, the first focusable element may be too far down. Moving focus to it would cause a lot of content to be
skipped
26Slide27
Code Sample Original Dialog:
27
<div tabindex="-1" role="dialog" aria-labelledby="ui-id-1">
<div>
<h1 id="ui-id-1" tabindex="-1">For Your Information</h1>
<button>Close</close>
</div>
…
</div>Slide28
Code Sample Modified Dialog:
28
<div tabindex="-1" role="dialog" arialabelledby="ui-id-1">
<div role="document" aria-label="Dialog contents">
<p class=“HiddenText">Start of dialog</p>
<div>
<h1 id="ui-id-1" tabindex="-1">For Your Information</h1>
<button>Close</button>
<span class="HiddenText">Close</span></a>
</div>
<div id="dialog" class="contentWrap">
…
</div>
<p class="HiddenText">End of dialog</p>
</div>
</div>Slide29
Hiding Content
29Slide30
Hiding Content
Three types of hiding:
Hiding content visually and from AT:
Hiding content visually, but not from ATHiding content from AT, but not visually Slide31
1. Hiding Content from All
Display: none;
Hides content both visually and from AT products
Only works when CSS is supported (by user agent, user, or AT product)Only use to hide content that still ‘makes sense’E.g. contents of a collapsible section Do not use for content that provides incorrect informationE.g. preloaded error messages that are not applicable at the moment, or stale content Instead, this content should be removed from the DOM completely
31Slide32
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 CSS
E.g. add hidden headings, screen reader instructions, role & state info for older technology32Slide33
Styles for Visually Hidden Content As Used in Bootstrap:
33
.sr-only {
position
: absolute;
width
: 1px;
height
: 1px;
margin
: -1px;
padding
: 0;
overflow
: hidden; clip: rect(0,0,0,0); border: 0
;
}Slide34
3. Hiding Content From
Screen Readers
Only
Sometimes developers want to hide content from screen readers, e.g.:Duplicate controlsRedundant information that was already provided through semantic mark up. Difficult to achieve:Role=“presentation” will remove native role, but content is still visible for AT products
Aria-hidden=“true” provides a solution:
Not supported well in older technology
34Slide35
Aria-hidden
35
Supported by the latest versions of major browsers and assistive technology.
Use with care: only for redundant/decorative contentNEVER use directly on focusable elements
<a href="#">
<span aria-hidden="true">A</span>
<span class="HiddenText">Small Font</span>
</a>Slide36
Scrollable Content
36Slide37
Scrollable Content
Some widgets use scrolling or animation to "slide" content into view
Example: a carousel widget: A long list of items, of which only a few are visible at a time
Example: A table that only shows a few columns at a time, and can be scrolled horizontally through "next" and "previous" buttons.Content that slides into view is often not hidden properly, but "clipped" through overflow:hidden stylesContent is visually hidden, but still part of the tab order and (unintentionally) reachable to keyboard users
37Slide38
Scrollable Content - Solution
When content is scrolled out of view, ensure that it's not reachable to keyboard users
To do this, the "visibility: hidden" style is often easiest to use:
When content is scrolled out of view, set visibility: hiddenBefore content is about to be scrolled into view, set visibility: visible Use "visibility: hidden" over "display: none" to maintain the content's layout, which is often needed for the scrolling / animation to function correctly
38Slide39
Tables
39Slide40
Labeling Tables
<caption> still alive and kicking
In HTML5 it’s allowed to nest headings
Summary attribute obsolete in HTML540Slide41
Heading In Caption Example
41
<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>Slide42
Fixing Incorrect Grid Structure
Some developers will use multiple HTML <table> elements to create one single grid. For example:
One <table> for the header row, one <table> for the body rows
One <table> for every single rowWhy? 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 tablesAssociation between column headers and cells is broken
Screen reader's table navigation is broken
42Slide43
Support for High Contrast Mode
43Slide44
Support for High Contrast Mode
When Windows High Contrast Mode is enabled, the following will happen:
Background and foreground colors are overridden
Background images are removedCustom user style sheets often apply similar changesUI libraries often uses background images for icons, which means these icons become invisible
44Slide45
High Contrast Mode – Solutions?
It's possible to detect the effects of high contrast mode or a custom stylesheet using scripting:
On page load, create an off screen div element, assign border and background styles to it, and inspect computed styles to see if they are overridden
This detection can be used to "fix" issues related to HC mode, e.g.:Unhide hidden text to replace background imagesFont icons are great for high contrast mode, but:Not supported on all devices
Break easily when custom user stylesheet overrides font-family
“Invisible font” solution is a promising workaround for this issue
45