Accessibility of Rich Internet Applications (Afternoon Session)

1. Hans Hillen (TPG) Steve Faulkner (TPG) Accessibility of Rich Internet Applications (Afternoon Session) Accessibility of HTML5 and Rich Internet Applications - CSUN 2011

2. New Solutions New Problems HTML5 accessibility

3. Accessible HTML5 • will be a beautiful thing

4. Current support for HTML5 accessibility • What is meant by support? • Features provided • Features implemented • Features implemented with accessibility support • In Browsers • In Assistive Technology

5. What is meant by support? • Features are implemented in browsers • Useful site - When can I use... • Does not mean features are usable by all users even if they use a browser that ‘supports’ a feature. • Firefox video support

6. the <video> element • No major browser has full accessibility support for HTML5 video • Providing full accessibility support means jumping through hoops: • Scripted controls • Scripted captioning and audio description

7. the <video> element • All major browser now support HTML5 video • Meaning you can watch/hear a video and use the controls if you can see, hear and use a mouse

8. the <video> element Terril Thompson: “That all sounds like a lot of work. Isn't HTML5 <video> supposed to be easy?” “Ultimately though ... HTML5 <video> is easy. A novice web developer can pop a video onto their web page in less than a minute with some very simple HTML markup. Unfortunately if they do that today it won't be accessible without a little additional sweat. Someday, hopefully, browsers will do all of this work for us, and every video will be accessible. That's what we're working toward.”

9. Example the <canvas> element • All major browser now support HTML5 canvas • Meaning dynamic images, animation, games and content is available without plug-ins

10. Example the <canvas> element • Only one major browser supports HTML5 canvas accessibility • And only partially

11. Example the <canvas> element • The accessibility features of canvas are still being specified. • What is implemented in IE9 gives an idea of how canvas accessibility will work. • Example

12. Accessible implementation • What’s it mean? • Conveys semantics required to understand and interact. • Can be used in a device independent way • Uses common design patterns • Accomodates browser & OS accessibility features • interoperable

13. The humble button Accessibility API Input device browser role=button state=focused value= search action=press

14. Accessibility APIs MSAA Iaccessible2 UI automation AX STK roles states properties interaction + device independent interaction

15. A tool to look under the hood MSAA inspect.32.exe or inspect.exe

16. The humble button • Accessibility features for a button a whirlwind tour

17. New HTML5 form controls • When implemented and implemented accessibly, will make it a lot easier to provide accessible UI’s • Current implementation is patchy and where implemented, accessibility support is poor. • Lets take a quick tour: HTML5 form controls

18. Placeholder attribute • Minor addition to HTML5 • Yet brings new headaches for developers and users • Poor contrast • disappears • Results in different accessible labels across browsers and labelling methods • HTML5 Accessibility Chops: the placeholder attribute

19. ARIA landmark roles vs HTML5 section elements • ARIA defines roles that act as landmarks for intra page navigation and identification of common content areas • HTML5 defines section elements for common semantic features of pages, some old some new • There is some overlap • HTML5 section elements are largely unimplemented (accessible). • FireFox has some experimental implementation

20. Section elements and landmarks • Examples of use • Bruce Lawson’s site • Wordpress • Mappings between section elements and landmark roles: • HTML5 Accessibility Chops: section elements

21. ARIA Landmark Roles • Landmark roles identify important sections commonly found in web pages: • Applied to container elements • Allow AT users to quickly see which sections a page has and navigate to individual sections • In JAWS, use the following commands: • ; (semicolon):jump to next landmark • Shift + ;(semicolon): jump to previous landmark • Ctrl + Ins + ;(semicolon): Show list of available landmarks • In NVDA use • D to jump to next landmark • Shift + D to previous landmark • NVDA+f7 Show list of available landmarks

22. ARIA Landmark Roles • Available Landmark Roles • Banner: A region that contains the primary heading or web site title. (site logo, login details, etc.) • Search: The search tool of a web document. • Navigation: The documents Navigation menus and links. • Main: The main content of web document. • Form: contains a collection of items and objects that, as a whole, combine to create a form. • Complementary: content that has meaning outside the page as well (e.g. a sidebar with related articles). • Contentinfo: Metadata that applies to the parent document (e.g. copy right disclaimers, company info). • Application: See next slide. Using WAI ARIA Landmark Roles

23. Aria Landmark Roles: Role=“Application” • Normally, Screen readers browse in ‘virtual mode’ • Screen reader navigates a virtual copy of the web page. • Screen reader intercepts all keystrokes, and uses them for its own virtual navigation (e.g. ‘H’ for heading navigation). • For dynamic web apps, virtual mode may need to be turned off • Interactive widgets need the keystrokes themselves. • Content needs to be live, not a virtual copy. • Normally, the user had to switch manually between virtual an non-virtual mode. • role=“application” • When applied a container element the screen reader will automatically switch to non virtual mode.

24. Application Role vs. Document Role • Some parts of your application may actually be treated as a document rather than application UI. For example: • A web based email client has panes in which messages are read or created. • A blog viewer web application can load articles to read. • In these parts, the screen reader user needs virtual mode: • To make use of the special navigation that comes with it. • To be able to read non focusable content • role=“document” • When applied to a container inside an application role, the screen reader will switch back to virtual mode. • Allows documents to be read or edited inside a web app.

25. HTML5 Accessibility information HTML5Accessibility.com

26. Implementing ARIA Solutions Practical examples Accessibility of HTML5 and Rich Internet Applications - CSUN 2011

27. Recap: How to Apply ARIA • Start with HTML elements • Any HTML element can be extended with ARIA. Examples: • <span>, <div>, <table>, <td>, <ul>, <li>, <p>, <img> • Add a ‘role’ attribute. • Only one role is allowed per element, • <span role=“checkbox”> • <div role=“tab”> • Add state /properties attributes if applicable. • A single elements can have one or more states • <span role=“checkbox” aria-checked=“true”> • <div role=“button” aria-pressed=“true” aria-disabled=“true”> • Attribute names always start with ‘aria-’ Accessibility of HTML5 and Rich Internet Applications - CSUN 2011

28. ARIA: Important Notes • ARIA doesn’t change anything to your widget: • It only provides semantic information for AT • Behavior and styles still need to be provided by developer • Some HTML elements already have a default, ‘native’ role. • e.g. <td> (role = ‘cell’), <a> (role=“link”), <input>, <li> • Native role is always overridden by ARIA role • E.g. <table role=“tab”> is announced as a tab by a screen reader rather than a table • Role values generally stay the same, state values can change • Trough user input (event handlers), • elem.setAttribute(‘aria-selected’, ‘false’); • Some roles have required state attributes • E.g. A ‘radio’ role requires the ‘aria-checked’ state • Requirements for an ‘ARIA ready’ widget: Focusable & Keyboard Accessible! Accessibility of HTML5 and Rich Internet Applications - CSUN 2011

29. Focus and Keyboard Accessibility Accessibility of HTML5 and Rich Internet Applications - CSUN 2011

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

31. Focus & Keyboard Accessibility (2) • Every Widget must be operable by keyboard • Create you own event handlers to manage • For composite widgets (trees, menus, etc.) individual parts can be reached using other keys, such as: • Arrow keys • Home, End, PgUp, PgDn • Enter, Space • Keep in mind: how would I navigate this widget in a desktop environment? • Mouse based actions must also be available through the keyboard. For example: • Write Key handlers trigger the same results mouse events • Use context menus to make relevant options accessible. Accessibility of HTML5 and Rich Internet Applications - CSUN 2011

32. Expected Widget Behavior • Not sure about how a widget should behave with the keyboard? • Use the DHTML Style Guide: • http://dev.aol.com/dhtml_style_guide Accessibility of HTML5 and Rich Internet Applications - CSUN 2011

33. Managing Interwidget Navigation • Make sure that all widgets are reachable through keyboard • Depend on Tab order (default or custom?) • Support global keyboard shortcuts • How do you notify your users? • Implementing a custom focus manager • Might be best solution for very complex UI's • Let go of the traditional tab order idea ("all focusable elements must be reachable by tab order") • Provide intuitive skipping mechanisms Accessibility of HTML5 and Rich Internet Applications - CSUN 2011

34. 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 is misused • Better 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 2011

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

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

37. 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 with links to make invalid entries easier to find • Role="alertdialog" to mark up the summary • 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 Accessibility of HTML5 and Rich Internet Applications - CSUN 2011

38. Advanced ARIA Implementation Techniques Accessibility of HTML5 and Rich Internet Applications - CSUN 2011

39. Labeling And Describing Widgets • Every widget need some kind of ‘identity’, or ‘label’ that AT can use to announce it to the user: • Singular interactive widgets, e.g. button, checkbox • Composite widgets, such as trees or toolbars: • Requires both a label for the widget as a whole and its individual parts • Container widgets: • A window or Pane requires a title • To label ARIA widgets: • You could use standard HTML labeling techniques: • Label element and title attributes. • Or: Aria-labelledby, aria-label, & aria-describedby Accessibility of HTML5 and Rich Internet Applications - CSUN 2011

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

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

42. ARIA Live Regions Accessibility of HTML5 and Rich Internet Applications - CSUN 2011

43. What are Live Regions? • Live regions • Parts of a Web page that the author expects to change and where new information maybe added updated or removed. • Examples of live regions: • Status updates • Changing stock information • Chat windows • Log windows (chat transcript logs), • notification areas (status, alerts) Accessibility of HTML5 and Rich Internet Applications - CSUN 2011

44. What are Live Regions? (2) • Live regions enable assistive technologies (such as screen readers) to inform users of updates. • Without live regions, AT users may not be aware that content elsewhere on the page has changed. • Users miss out on relevant info • Users have to ‘search’ for updated page content • With live regions, updated information is announced automatically. • Example: stock updater Accessibility of HTML5 and Rich Internet Applications - CSUN 2011

45. Live Region Properties and How to Use Them • To identify a live region, add the aria-live attribute. • One of the most important concepts behind live regions is politeness. • Politeness indicates how much priority a live region has. • The following politeness values are available for aria-live: off, polite, and assertive. Accessibility of HTML5 and Rich Internet Applications - CSUN 2011

46. Live Regions: Politeness Levels • Aria-live="off" • Default value, identical to not setting aria-live. Examples: • A DHTML clock • Number of users currently online • Aria-live=“polite” • Updates are announced but won’t interrupt the user • Should be used in most situations involving live regions that present new information to users: • Updates to news headlines, twitter alerts, monitored stocks, etc. • Aria-live=“assertive” • Updates are announced and interrupt what the user is doing • Only use for important updates that require immediate attention. • Warnings & error notifications. • Session timeout notifications Accessibility of HTML5 and Rich Internet Applications - CSUN 2011

47. Live Regions: Other important attributes • aria-atomic="true | false" • Optional. Indicates if assistive technology should present all or part of the changed region to the user. • aria-atomic=“true”: assistive technology should announce the entire region when part of it changes; • aria-atomic=“false”: only the part of the region that changed should be announced on its own. • aria-busy="true | false" • Optional. Indicates whether region has finished updating, or whether certain parts are still expected to change. • aria-busy=“true”: region not fully updated yet, AT should wait. • aria-busy=“false”: region update is complete, AT can start announcing the update. Accessibility of HTML5 and Rich Internet Applications - CSUN 2011

48. Useful Roles with ‘Built In’ Live Regions • Role=“alert” • Used for one-time, high priority notifications. • Should be shown for a period of time, or until the cause of the alert is solved. • Should contain a basic message, no complex content. • The element with the alert role does not need to be focused to be announced. • Elements with role=“alert” receive aria-live=“assertive” and aria-atomic=“true” as default values. • Screen reader automatically announces the alert text, after saying ‘alert’ • Example: Form validation sample • Role=“alertdialog” • Similar to Alert, but meant for actual (DHTML ) dialog windows . • May contain other widgets, such as buttons or other form fields. • Does require a sub element (such as a ‘confirm’ button) to receive focus. Accessibility of HTML5 and Rich Internet Applications - CSUN 2011

49. Useful Roles with ‘Built In’ Live Regions (2) • Role=“status” • Contains advisory information for the user but is not important enough to justify an alert. • Automatically receives aria-live=“polite” • Should not receive focus • Role=“timer” • A numerical counter which indicates an amount of elapsed time from a start point, or the time remaining until an end point. • Should be updated at regular intervals • Role=“marquee” • A type of live region where non-essential information changes frequently • E.g. stock tickers, banners • Role=“log” • Like marquee, but information is added in meaningful order and old information may disappear. Accessibility of HTML5 and Rich Internet Applications - CSUN 2011

50. Fallback solutions / Hacks Accessibility of HTML5 and Rich Internet Applications - CSUN 2011