jQuery UI A11Y
Tips, Tricks and Pitfalls
jQUery UI ARIA Hackathon 2011
Hans Hillen, TPG
Project Background
• TPG: Accessibility Consultancy & Development
• jQuery UI work requested by AOL, using AEGIS
funding
• Started with a small set of widgets, stuck
around do more widgets
• Changes are still being checked in
• Live Demo at
http://hanshillen.github.com/jqtest
Widgets Worked On So far
•
•
•
•
•
Slider
Progress bar
Dialog
Datepicker
Menubar
•
•
•
•
Popup
Tabs
Tree (external plugin)
Carousel (external
Plugin)
• (Button, Checkbox,
Tooltip)
Type of Fixes:
•
•
•
•
Keyboard Support
Focus Management
ARIA Implementation
High Contrast Mode Support
High Contrast Mode
• Windows OS feature that overrides
background and foreground colors
– Enabled through the accessibility preferences,
– shortcut: Left Alt + Left Shift + Print Screen
• Inherited by browsers, which overrides CSS
styles accordingly
• Background colors and background images are
removed
Challenges With HC Mode
• Information relying on CSS background styles will
no longer be visible :
– Icon buttons with CSS background images can become
unusable
– CSS background colors used to indicate selection or
focus will not be visible anymore (e.g. tree views or
DHTML listboxes)
– CSS background colors used to create a "fill" will
become invisible (e.g. progress bars).
– Overlapping containers may become transparent,
showing the content behind it (e.g. dialogs, menus)
How to Deal With HC Mode?
• High Contrast Mode detection
• If HC mode is detected: perform the changes
needed to fix the damage high contrast caused in
your UI:
– CSS unhiding: HC – Safe content is hidden by default,
shown in HC mode
– Use border styles to create "faux fills"
– Use visual indications other than color (e.g. font
styles, weight, size, text decoration)
– Use actual text, ASCII or HTML images
ARIA Pitfalls
• Incomplete browser support
– I'm looking at you, IE…
• Buggy, incomplete screen reader support
• Insufficient developer knowledge
• Users getting confused
–
–
–
–
"Things were working before, why can't it work now?"
"Why do I need to update my 1000$ AT product?"
"Why can't I use my virtual mode features anymore?"
"What is 'application mode' and how do I get rid of it?"
• MODE MADNESS!
Virtual Mode
• Virtual (PC Cursor) Mode:
– Default mode for web content
– User interacts with a virtual copy of the DOM
– Static content (e.g. text, lists, headings, tables, images) can be
navigated using virtual cursor
– Screen reader provides many additional shortcuts for virtual
navigation such as:
• Navigating by elements type (e.g. headings, images, form fields,
tables)
• Listing element by type (heading list, link list, etc.)
• Data table navigation
– Ideal for exploring unfamiliar web content, or getting "unstuck"
– The downside: Most keyboard input is intercepted by screen
reader and will not not reach your web app
Non Virtual Mode
• Non – Virtual mode
– A.k.a. Forms mode, pass through mode, browse mode
off, etc.
– All benefits from virtual mode are gone
• Only keyboard accessible, focusable elements can be
navigated
• No more heading navigation, link lists, etc.
• All keyboard input is allowed to reach the web application
• Similar to screen reader navigation in a desktop application
• Successful navigation fully depends on keyboard accessible
content.
Virtual VS Non Virtual
• Most web applications use customized rich
internet widgets (e.g. sliders, tree views, tabs) as
opposed to just native HTML controls (text input,
checkbox, select, etc.)
• These widgets have customized (e.g. non native)
keyboard interaction
– Keyboard input is Intercepted in virtual mode, making
the widget unusable in virtual mode
• In order to be able to successfully interact with
these custom widgets, virtual mode must be
(temporarily) disabled
Mode Madness (1)
•
Application Mode:
– Similar to forms mode, but can be induced (forced) by the developer rather than the user.
– Applied by adding role="application" to a container.
•
Screen reader will automatically disable virtual mode within this container
– Easily misused
•
•
Application mode expects a fully keyboard accessible desktop like UI, but most developers just use it
to get rid of virtual mode and make their widget operable by screen reader users
Only use application mode if you can guarantee a completely keyboard accessible, understandable and
navigable UI that truly reflects a desktop application
– Confuses users
•
•
•
Application mode = a web page pretending to be a desktop application running from inside another
application (i.e. the browser)
People expect a Web 1.0 style interface (lots of tabbing and virtual navigation) but get a completely
different UI and navigation style then what they would expect in web content.
People don't like to have their virtual privileges taken away from them
– JAWS allows you to override app mode and switch back to virtual mode
•
•
If web app is not 100% keyboard accessible, it can still be navigated somewhat successfully in virtual
mode
NVDA DOES NOT ALLOW THIS ("If it's a true application, it does not need virtual navigation. If it's not,
don't use role='application' to begin with")
Mode Madness (2)
• Using application mode is fine if your web app
truly behaves like a desktop application
– All content is either:
• Navigable / focusable, operable by keyboard
• Associated to content mentioned above (ariadescribedby, labelledby, grid headers
• For 99% of web applications this is NOT true
– Most web applications are a hybrid of application
UI and static content
Mix of Static and Desktop like Content
Mode Madness (3)
• Mixed content means switching modes:
– Non virtual for widget interaction
– Virtual mode for static content
• How does the (novice user) know how to switch modes?
• How the user know when to switch?
– Provide documentation, hints
– Experienced screen reader users will be prepared to use
unconventional navigation styles such as the JAWS cursor in
applications in order to find certain content. It's not always
necessary to hold their hand for every step
• How will the user back track to where focus was when
switching back?
– Tabs Demo
Mode Madness (4)
• Wrapping role="application" around every widget kind of works, but does
not make sense
– You don't really have a web page with 30 little one-widget applications in it
• Role="document" is useful for actual documents containers, e.g. web
based reading and editing panes
– It's not useful for random static content spread out between rich widgets
• Screen readers need to become smarter about dealing with mix of web
based desktop UI and static content.
• Good start: modern day screen readers perform "auto-forms mode"
– Virtual mode by default, snaps to non-virtual mode when interactive controls
are navigated
– A "best of both worlds" approach
• Doesn't take away virtual privileges
• Allows customized keyboard interaction with widgets where needed
– Still problematic: global shortcuts
– Can be buggy in JAWS
Mode madness (5)
• Custom roles will override native roles
– Sometimes this is good:
• <a href="#" role="tab" aria-selected="true">Options</a>
– Sometimes it's not:
• <h2 role="tab" tabindex="0">Accordion Section 1</h2>
• Heading role is replaced by tab role, removing the heading from heading
nav and heading list feature
• It makes sense from a conceptual standpoint, because semantically
speaking the heading is now a tab. BUT:
– Someone who prefers to navigate virtually now unnecessarily suffers, even if the
page was marked up with a correct heading structure.
– Leaving the headings as they were means that keyboard users can't use them for
navigation (which is why they were turned into accordion headers in the first
place)
– Why can’t the screen reader just support both?
– Ugly workaround: <h2 ><span role="tab" tabindex="0">Accordion Section
1</span></h2>
Documentation
• Many end users have not made the paradigm shift yet
• They expect a document, but get a faux application UI
• JAWS is either not helpful or just lies
– Provides the wrong instructions for certain roles, e.g. tablist:
• "Press Ctrl + Tab to switch the tab"  correct in Desktop environment,
generally not in web based tablists (because it would conflict with the existing
browser shortcut for switching tabs)
• Users need to be trained in this new form of Web UI
– Must be part of screen reader training
• Application developers need to provide documentation
– Explain how each widget is used
– Explain that a non-virtual mode is required and how to switch modes
in popular screen readers
– Help users ease into Web 2.0
Questions