380 likes | 498 Views
Hans Hillen (TPG) Steve Faulkner (TPG). Accessibility of HTML5 and Rich Internet Applications (Part 2). In This Part:. Keyboard and Focus Management Labeling and Describing Live Regions Form Validation Mode Conflicts Fallback Solutions. Keyboard and Focus Management .
E N D
Hans Hillen (TPG) Steve Faulkner (TPG) Accessibility of HTML5 and Rich Internet Applications (Part 2) Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
In This Part: • Keyboard and Focus Management • Labeling and Describing • Live Regions • Form Validation • Mode Conflicts • Fallback Solutions Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
Keyboard and Focus Management Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
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 2012
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 2012
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.): • Every widget should only have 1 stop in the tab order. • Keep track where your widget’s current tab stop 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 2012
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 • DHML Style Guide: http://dev.aol.com/dhtml_style_guide • ARIA Best Practices: http://www.w3.org/TR/wai-aria-practices/ Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
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 2012
Popup Dialogs and Windows • More and more web apps use HTML based popup dialogs rather than actual browser windows/dialogs • Get a screen reader to perceive it properly using role="dialog" • Dialogs should have their own tab order • Focus should "wrap" • For modal dialogs, it should not be possible to interact with the main page • Prevent keyboard access • Virtual mode access can't be prevented • For non modal dialogs, provide shortcut to switch between dialog and main page • If dialog supports moving or resizing, these features must be keyboard accessible • Support closing dialogs using Enter (OK) or Escape (Cancel) keys • Focus should be placed back on a logical element, e.g. the button that triggered the dialog. Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
Selection & Editing • Trees, Lists, Grids can support single or multiple selection • Multiple selection must be keyboard accessible, for example: • Shift + arrow keys: contiguous selection • Ctrl + arrow keys: move focus without selection • Ctrl + space: Toggle focused item in selection (discontiguous selection) • Editable grids need to support switching to edit mode by keyboard Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
Labeling and Describing Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
Labeling in a Nutshell • All of these must have an accessible name: • Every interactive widget • Composite widgets (menu(bar), toolbar, tablist, tree, grid) • Groups, regions and landmarks • Browsers determines an element’s accessible name by checking the following : • aria-labelledby • aria-label • Associated label (<label for=“myControl”>) or alt attribute • Text contents • Title attribute Optionally, add an accessible description for additional info Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
Label, Labelledby & Describedby • Aria-labelledby=“elemID” • Points to element ID that identifies the widget. • Can also use regular label element / title attribute • Aria-describedby=“elemID” • Optional, providesadditional info besidesidentity • Usefulforadditionalinfo, instructions, hints • Aria-label=“text” • Only use when no on-screen text • Title attribute will also work • <h2 id=“treeLbl”>My Folders</h2> • <p id=“treeDesc” class=“hidden”>Each tree item has a context menu with more options</p> • <div role=“tree” aria-labelledby=“treeLbl” aria-describedby=“treeDesc”> Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
Labeling And Describing Widgets (2) • Aria-labelledby=“IDREFS” • Value is one or more IDs of elements that identifiy the widget. • The elements ‘aria-labelledby’ targets can be any kind of text based element, anywhere in the document. • Add multiple Ids to concatinate label text: • Multiple elements can label one widget, and one element can label multiple widgets. (example) • Aria-describedby=“IDREFS” • Similar to labelledby, except used for additional description, e.g. Form hints, instructions, etc. • Aria-label • Simply takes a string to be used as label. • Quick and dirty way of making the screen reader say what you want. • Very easy to use, but only supported in Firefox at the moment. <h2 id=“treeLbl”>My Folders</h2> <p class=“hidden”>Each tree item has a context menu with more options</p> <div role=“tree” aria-labelledby=“treeLbl” aria-describedby=“treeDesc”> ... Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
Labeling containers • Containers such as toolbars, dialogs, and regions provide context for their contents • When the user moves focus into the container, the screen reader should first announce the container before announcing the focused control <div role="dialog" aria-labelledby="dialogTitle" aria-describedby="dialogDescription"> <h2 id="dialogTitle">Confirm</h2> <p id="dialogDescription"> Are you sure you want to do that? </p> <button>Yes</button> <button>No</button> </div> Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
Labeling Tables • <caption> still alive and kicking • In HTML5 it’s allowed to nest headings • Summary attribute obsolete in HTML5 Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
Live Regions Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
ARIA Live Regions • Problem: content is updated dynamically on screen may not be apparent to screen reader users • No page refresh, no screen reader announcement • Change is only announced by stealing focus • Users miss relevant information • Users have to ‘search’ for updated page content • Solution: live regions indicate page updates without losing focus • Screen readers announce changebased on type of live region • Challenge: When should users be informed of the change? • Ignore trivial changes: changing seconds in a clock • Announce important changes immediately / as convenient Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
“Built In” Live Regions • Role=“alert” for one-time, high-priority notifications • Shown for a period of time, or until the cause of the alert is solved • Basic message, no complex content • The element with the alert role does not need to be focused to be announced • Role=“alertdialog” is similar to alert, but for actual (DHTML) dialogs. • May contain other widgets, such as buttons or other form fields • Does require a sub-element (such as a ‘confirm’ button) to receive focus • Live regions ‘built into ‘ roles’ • role="timer", "log", "marquee" or "status“ get default live behavior • Role=“alert” implicitly sets live to assertive Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
How to Use Live Regions • Identify which part (containing HTML element) is expected to be updated • To make it live, add ‘aria-live’ attribute with a politeness value: • Off (default): Do not speak this region • Polite: Speak this region when the user is idle • Assertive: Speak this region as soon as possible • Choose whether entire region should be announced or just the part that changed: • ‘aria-atomic': true (all) or false (part) • Add other attributes as necessary: • aria-relevant: choose what to announce: • Combination of ‘Additions’, ‘removals’, ‘text’, ‘all’ • aria-busy: indicate content is still updating • aria-labelledby, aria-describedby: label and describe regions Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
Forms & Validation Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
Forms & ARIA • You can used 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 • Live Regions: Use for concise feedback messages Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
Mode Conflicts Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
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 2012
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 2012
Fall Back Solutions Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
Role = Presentation • Role=“presentation” overrides existing role • Useful to ‘hide’ default HTML roles from AT • For example: • Hide layout tables by adding the role to the <table> element • Textual content read by the screen reader but table is ignored Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
Fall back solution for dialogs • In IE, JAWS currently does not properly announce dialogs when moving focus into them • It's possible to provide a fallback solution for IE to fix this, using hidden fieldsets to apply the ARIA dialog markup to • Hide fieldset's padding, margin, and border • Move legend off-screen <fieldsetrole="dialog" aria-labelledby="dialogTitle" aria-describedby="dialogDescription"> <legend id="dialogTitle">Confirm</legend> <p id="dialogDescription"> Are you sure you want to do that? </p> <button>Yes</button> <button>No</button> </fieldset> Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
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) • You lie! 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 2012
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 2012
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 2012
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 */ .ui-helper-hidden-accessible { position: absolute !important; clip: rect(1px 1px 1px 1px); clip: rect(1px,1px,1px,1px); } Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
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” would be ideal, but: • The spec did not intend for aria-hidden to be used this way • Browsers handle aria-hidden differently • IE does nothing • FF exposes content but marks it as hidden • Chrome does not expose content (i.e. truly hides it) Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
Grids and Tables Accessibility of HTML5 and Rich Internet Applications - CSUN 2012
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 2012
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 2012
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 2012
Anything Else? • Questions? • Additional Topics? • Course Material: http://www.paciellogroup.com/training/CSUN2012 Accessibility of HTML5 and Rich Internet Applications - CSUN 2012