430 likes | 533 Views
Hans Hillen (TPG) Steve Faulkner (TPG) Karl Groves (TPG) Billy Gregory (TPG). Accessibility of HTML5 and Rich Internet Applications (Part 2). In This Part:. Keyboard and Focus Management Form Validation Mode Conflicts Solutions, Workarounds and Considerations.
E N D
Hans Hillen (TPG) Steve Faulkner (TPG) Karl Groves (TPG) Billy Gregory (TPG) Accessibility of HTML5 and Rich Internet Applications (Part 2)
In This Part: • Keyboard and Focus Management • Form Validation • Mode Conflicts • Solutions, Workarounds and Considerations Accessibility of HTML5 and Rich Internet Applications - CSUN 2014
Keyboard and Focus Management Accessibility of HTML5 and Rich Internet Applications - CSUN 2014
The Problem with Custom Controls Problem: • 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 Accessibility of HTML5 and Rich Internet Applications - CSUN 2014
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 Accessibility of HTML5 and Rich Internet Applications - CSUN 2014
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 Accessibility of HTML5 and Rich Internet Applications - CSUN 2014
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. Accessibility of HTML5 and Rich Internet Applications - CSUN 2014
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 Accessibility of HTML5 and Rich Internet Applications - CSUN 2014
Forms & Validation Accessibility of HTML5 and Rich Internet Applications - CSUN 2014
Forms & ARIA • You can use ARIA to make your form validation easier to manage. • aria-required & aria-invalid states • Role="alert" to flag validation errors immediately • Use validation summaries invalid entries easier to find • Use role=“group” or Role="alertdialog" to mark up the summary • Link to corresponding invalid controls from summary items • Use different scope levels if necessary • Visual tooltips: Useful for validation messages and formatting instructions • Tooltips must be keyboard accessible • Tooltip text must be associated with the form control using aria-describedby • Provide both inline and form wide feedback Accessibility of HTML5 and Rich Internet Applications - CSUN 2014
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. <a role="button" onkeypress="handleKeyPress(event);">refresh</a> Accessibility of HTML5 and Rich Internet Applications - CSUN 2014
Mode Conflicts Accessibility of HTML5 and Rich Internet Applications - CSUN 2014
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 Accessibility of HTML5 and Rich Internet Applications - CSUN 2014
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. Accessibility of HTML5 and Rich Internet Applications - CSUN 2014
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 Accessibility of HTML5 and Rich Internet Applications - CSUN 2014
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 Accessibility of HTML5 and Rich Internet Applications - CSUN 2014
Example • 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? Accessibility of HTML5 and Rich Internet Applications - CSUN 2014
The Perfect Dialog Accessibility of HTML5 and Rich Internet Applications - CSUN 2014
The Perfect Dialog, in Theory: • Use role="dialog", combined with: • Aria-labelledby (for dialog title) • Aria-describedby (for dialog message text) • 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 • For non modal dialogs: provide shortcut to switch between dialog and main page • Support closing dialogs using buttons and Escape key • 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" • If dialog supports moving or resizing, these features must be keyboard accessible Accessibility of HTML5 and Rich Internet Applications - CSUN 2014
Problems with the Perfect Dialog • 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, but it’s an ugly hack. • 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 Accessibility of HTML5 and Rich Internet Applications - CSUN 2014
Code Sample Original Dialog: <div tabindex="-1" role="dialog" arialabelledby="ui-id-1"> <div> <h1 id="ui-id-1"tabindex="-1">For Your Information</h1> <a href="#" class="icon-circle_remove" role="button" aria-label="Close“ tabindex="0"> <span class=“HiddenText">Close</span></a> </div> … </div> Accessibility of HTML5 and Rich Internet Applications - CSUN 2014
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> <a href="#" class="icon-circle_remove" role="button" aria-label="Close“ tabindex="0"> <span class=“HiddenText">Close</span></a> </div> <div id="dialog" class="contentWrap"> … </div> <p class=“HiddenText">End of dialog</p> </div> </div> Accessibility of HTML5 and Rich Internet Applications - CSUN 2014
Hiding Content Accessibility of HTML5 and Rich Internet Applications - CSUN 2014
Hiding Content • Three types of hiding: • Hiding content visually and from AT: • Hiding content visually, but not from AT • Hiding content from AT, but not visually Accessibility of HTML5 and Rich Internet Applications - CSUN 2014
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 Accessibility of HTML5 and Rich Internet Applications - CSUN 2014
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 /* Old */ .offscreen { position: absolute; left: -999em; } /* New */ .offscreen { position: absolute !important; clip: rect(1px 1px 1px 1px); clip: rect(1px,1px,1px,1px); } Accessibility of HTML5 and Rich Internet Applications - CSUN 2014
3. Hiding Content From AT Only • Sometimes developers want to hide content from screen readers, e.g.: • Duplicate controls • Redundant information that was already provided through semantic markup. • 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 Accessibility of HTML5 and Rich Internet Applications - CSUN 2014
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> Accessibility of HTML5 and Rich Internet Applications - CSUN 2014
Tables Accessibility of HTML5 and Rich Internet Applications - CSUN 2014
Labeling Tables • <caption> still alive and kicking • 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> Accessibility of HTML5 and Rich Internet Applications - CSUN 2014
Fixing Incorrect Grid Structure (1) • 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 Accessibility of HTML5 and Rich Internet Applications - CSUN 2014
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 • Use role="presentation" to hide the original table elements form the screen readers • Use a combination of "grid", "row", "gridcell", "columnheader" roles to make the screen reader see one big grid. Accessibility of HTML5 and Rich Internet Applications - CSUN 2014
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> Accessibility of HTML5 and Rich Internet Applications - CSUN 2014
Scrollable Content Accessibility of HTML5 and Rich Internet Applications - CSUN 2014
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 Accessibility of HTML5 and Rich Internet Applications - CSUN 2014
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 Accessibility of HTML5 and Rich Internet Applications - CSUN 2014
Support for High Contrast Mode Accessibility of HTML5 and Rich Internet Applications - CSUN 2014
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 Accessibility of HTML5 and Rich Internet Applications - CSUN 2014
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 Accessibility of HTML5 and Rich Internet Applications - CSUN 2014
TPG Bug Bash • Calling all AT users, QA testers, web developers, vendors, and general accessibility enthusiasts • Find and report AT Bugs • Track us on Twitter #TPGBB Accessibility of HTML5 and Rich Internet Applications - CSUN 2014
TPG Bug Bash • Thursday, March 20th • 5.30pm to 6.30pm • Suite 3233, Harbor tower, Manchester Grand Hyatt Accessibility of HTML5 and Rich Internet Applications - CSUN 2014
Anything Else? • Questions? • Additional Topics? • Course Material: http://www.paciellogroup.com/training/CSUN2014 Accessibility of HTML5 and Rich Internet Applications - CSUN 2014