jQuery UI A11Y Tips, Tricks, and Pitfalls

This content delves into the accessibility aspects of jQuery UI, highlighting tips, tricks, challenges, and solutions related to ARIA implementation, high contrast mode support, and dealing with issues like incomplete browser support and user confusion. It also covers the background of the project, widgets worked on, and strategies for managing High Contrast Mode in your UI to ensure accessibility standards are met.

• jQuery UI
• Accessibility
• A11Y Tips
• High Contrast Mode
• ARIA

breklynnb Follow

Uploaded on Mar 04, 2025 | 0 Views

Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.

Presentation Transcript

1. jQuery UI A11Y Tips, Tricks and Pitfalls jQUery UI ARIA Hackathon 2011 Hans Hillen, TPG

2. 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

3. Widgets Worked On So far Popup Tabs Tree (external plugin) Carousel (external Plugin) (Button, Checkbox, Tooltip) Slider Progress bar Dialog Datepicker Menubar

4. Type of Fixes: Keyboard Support Focus Management ARIA Implementation High Contrast Mode Support

5. 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

6. 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)

7. 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

8. 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!

9. 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

10. 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.

11. 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

12. 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")

13. 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 (aria- describedby, labelledby, grid headers For 99% of web applications this is NOT true Most web applications are a hybrid of application UI and static content

14. Mix of Static and Desktop like Content

15. 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

16. 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

17. 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>

18. 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

19. Questions