Accessibility of HTML5 and Rich Internet Applications (Part 2) Hans Hillen Steve Faulkner.
-
Upload
clifton-hill -
Category
Documents
-
view
214 -
download
0
Transcript of Accessibility of HTML5 and Rich Internet Applications (Part 2) Hans Hillen Steve Faulkner.
Accessibility of HTML5 and Rich Internet Applications (Part 2)
Hans HillenSteve Faulkner
2
IN THIS PART:
• Keyboard and Focus Management• Form Validation• Screen Reader Mode Conflicts • Solutions, Workarounds and
Considerations
KEYBOARD AND FOCUS MANAGEMENT
3
THE PROBLEM WITH CUSTOM CONTROLSProblem: • Images, divs, spans etc. are not standard controls
with defined behaviors• Not focusable with keyboard• Have a default tab order• Behavior is unknown
Solution:• Ideally: Use native focusable HTML controls • <a>, <input type=“image” />, <button>, etc.
• Or manually define keyboard focus and behavior needs
5
KEYBOARD ISSUES IN A NUTSHELL• Reachability: Moving keyboard focus to a
widget • Through tab order•Native focusable controls or tabindex=“0”
• Through globally defined shortcut• By activating another widget
• Operability: Interacting with a widget• All functionally should be performable
through keyboard and mouse input
6
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 order• Tabindex="-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
7
KEYBOARD HANDLING
• Every widget needs to be operable by keyboard. common keystrokes are:• Arrow keys• Home, end, page up, page down• Enter, space• ESC
• Mimic 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.
8
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 sections• Consistent 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
FORM VALIDATION
9
10
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 disruptive• Provide validation feedback both in inline scope and form
scope• Use 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
SOLUTIONS, WORKAROUNDS AND CONSIDERATIONS
11
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.
SCREEN READER MODE CONFLICTS
VIRTUAL VS NON VIRTUAL MODEVirtual Mode (a.k.a. browse / virtual PC cursor mode) Non-Virtual Mode (a.k.a. forms / application mode)
Default navigation mode 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”, allowing 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.
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 off
• Interactive widgets need to define the keystrokes themselves• Content needs to be live, not a virtual copy• Automatically 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 work
16
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 again
• 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.
17
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 changes• Simple Keyboard navigation: Tab, Enter, some
times arrow keys• WAI – ARIA is meant for "Application UI's"
• Requires virtual mode to be disabled• Requires custom shortcuts• Content can update dynamically
18
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 interactions
• Less experienced users will likely be confused• Sighted keyboard users do not get any
instructions at all
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 switching
• Which one is correct?• What will the end user expect?
EXAMPLE
THE PERFECT DIALOG
20
DIALOG: ROLES & STATES
• Use role="dialog", combined with:• Aria-labelledby (for dialog title)• Aria-describedby (for dialog
message text)
22
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"
23
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 key
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:
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:
26
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 allowed
• This works for simple dialogs…• But not for complex dialog content often found in real life
projects, which may have a large amount of static content• To 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
27
CODE SAMPLE ORIGINAL DIALOG:
<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>
28
CODE SAMPLE MODIFIED DIALOG:
<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>
HIDING CONTENT
29
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
31
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 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
32
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 technology
33
STYLES FOR VISUALLY HIDDEN CONTENT AS USED IN BOOTSTRAP:.sr-only {
position: absolute;width: 1px;height: 1px;margin: -1px;padding: 0;overflow: hidden;clip: rect(0,0,0,0);border: 0;
}
34
3. HIDING CONTENT FROM SCREEN READERS ONLY• Sometimes developers want to hide content
from screen readers, e.g.:• Duplicate controls• Redundant 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
35
ARIA-HIDDEN
• Supported by the latest versions of major browsers and assistive technology.
• Use with care: only for redundant/decorative content
• NEVER use directly on focusable elements
<a href="#"> <span aria-hidden="true">A</span> <span class="HiddenText">Small Font</span></a>
SCROLLABLE CONTENT
36
37
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 styles• Content is visually hidden, but still part of the tab
order and (unintentionally) reachable to keyboard users
38
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: hidden• Before 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
TABLES
39
LABELING TABLES
• <caption> still alive and kicking• In HTML5 it’s allowed to nest
headings• Summary attribute obsolete in
HTML5
40
41
HEADING IN CAPTION EXAMPLE
<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>
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 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• Association between column headers and cells is
broken• Screen reader's table navigation is broken
42
SUPPORT FOR HIGH CONTRAST MODE
43
44
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 removed
• Custom user style sheets often apply similar changes
• UI libraries often uses background images for icons, which means these icons become invisible
45
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 images
• Font 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