Your SlideShare is downloading. ×
Accessible web applications
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Accessible web applications

2,633
views

Published on

accessible web application workshop slides presented at CSUN 2011 by Hans Hillen and Steve Faulkner from The Paciello Group (TPG)

accessible web application workshop slides presented at CSUN 2011 by Hans Hillen and Steve Faulkner from The Paciello Group (TPG)

Published in: Technology

0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,633
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
32
Comments
0
Likes
4
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • With accessibility support HTML5 will become a powerful, useful, interoperable, versatile language for the world wide web.
  • Each HTML feature has a role, name, state and other property values that need to be hooked into the accessibility APIs by the browser. Assistive technology can then use this information to convey a representation of the feature to users.
  • For users of assistive technology to be able to access and interact with web content, browser developers need to expose HTML5 features through accessibility applications interfaces and make interactive features operable without the use of a mouse.
  • This site is a resource to provide information about which HTML5user interface features are accessibility supported in browsers, making them usable by people who rely upon assistive technology (AT) to use the web.It is not intended to dissuade developers from using HTML5 features. Sometimes there are better choices, sometimes developers have to add a little extra to make the feature useful or usable, and other times features have simply not been implemented by any browser or only by browsers that do not yet support assistive technologies. As a consequence it may not yet be practical to use a particular HTML5 feature. Example work around for lack of implementation or lack of accessible implementation are are provided.
  • Demos:Bad treeGood Tree
  • Demo: Slider
  • Jquery Demo (collapsible sections)GXT Focus Manager
  • GXT Focus Manager demo (open window under "Window" tab)
  • Basic GridGridrow editor
  • Validation sample
  • CA example
  • Jquery dialog example
  • Stock sample
  • ARIA grid fix example
  • Transcript

    • 1. Accessibility of Rich Internet Applications (Afternoon Session)
      Hans Hillen (TPG)
      Steve Faulkner (TPG)
      1
      03 / 15 / 11
      Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
    • 2. HTML5 accessibility
      New Solutions
      New Problems
    • 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. Another tool to look under the hood
      Aviewer
    • 17. The humble button
      Accessibility features for a button a whirlwind tour
    • 18. 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
    • 19. 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
    • 20. 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
    • 21. Section elements and landmarks
      Examples of use
      Bruce Lawson’s site
      Wordpress
      Mappings between section elements and landmark roles:
      HTML5 Accessibility Chops: section elements
    • 22. 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
    • 23. ARIA Landmark Roles
      • Available Landmark Roles
      • 24. Banner: A region that contains the primary heading or web site title. (site logo, login details, etc.)
      • 25. Search: The search tool of a web document.
      • 26. Navigation: The documents Navigation menus and links.
      • 27. Main: The main content of web document.
      • 28. Form: contains a collection of items and objects that, as a whole, combine to create a form.
      • 29. Complementary: content that has meaning outside the page as well (e.g. a sidebar with related articles).
      • 30. Contentinfo: Metadata that applies to the parent document (e.g. copy right disclaimers, company info).
      • 31. Application: See next slide.
      Using WAI ARIA Landmark Roles
    • 32. 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.
    • 33. 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.
    • 34. HTML5 Accessibility information
      HTML5Accessibility.com
    • 35. Implementing ARIA Solutions
      Practical examples
      03 / 15 / 11
      Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
      27
    • 36. 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”>
      • 37. <div role=“tab”>
      Add state /properties attributes if applicable.
      A single elements can have one or more states
      • <span role=“checkbox” aria-checked=“true”>
      • 38. <div role=“button” aria-pressed=“true” aria-disabled=“true”>
      Attribute names always start with ‘aria-’
      03 / 15 / 11
      Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
      28
    • 39. 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
      • 40. 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!
      03 / 15 / 11
      Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
      29
    • 41. Focus and Keyboard Accessibility
      03 / 15 / 11
      Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
      30
    • 42. 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
      03 / 15 / 11
      Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
      31
    • 43. Focus & Keyboard Accessibility (2)
      • Every Widget must be operable by keyboard
      • 44. Create you own event handlers to manage
      • 45. For composite widgets (trees, menus, etc.) individual parts can be reached using other keys, such as:
      • 46. Arrow keys
      • 47. Home, End, PgUp, PgDn
      • 48. Enter, Space
      • 49. Keep in mind: how would I navigate this widget in a desktop environment?
      • 50. Mouse based actions must also be available through the keyboard. For example:
      • 51. Write Key handlers trigger the same results mouse events
      • 52. Use context menus to make relevant options accessible.
      03 / 15 / 11
      Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
      32
    • 53. 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
      03 / 15 / 11
      Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
      33
    • 54. 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
      03 / 15 / 11
      Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
      34
    • 55. Skipping Mechanisms
      • The ability to skip content is crucial for both screen reader and keyboard users
      • 56. Skip links are out of date, out of fashion and often is misused
      • 57. 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
      03 / 15 / 11
      Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
      35
    • 58. 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
      • 59. If dialog supports moving or resizing, these features must be keyboard accessible
      • 60. 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.
      03 / 15 / 11
      Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
      36
    • 61. 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
      03 / 15 / 11
      Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
      37
    • 62. 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
      03 / 15 / 11
      Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
      38
    • 63. Advanced ARIA Implementation Techniques
      03 / 15 / 11
      Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
      39
    • 64. Labeling And Describing Widgets
      • Every widget need some kind of ‘identity’, or ‘label’ that AT can use to announce it to the user:
      • 65. Singular interactive widgets, e.g. button, checkbox
      • 66. Composite widgets, such as trees or toolbars:
      • 67. Requires both a label for the widget as a whole and its individual parts
      • 68. Container widgets:
      • 69. A window or Pane requires a title
      • 70. To label ARIA widgets:
      • 71. You could use standard HTML labeling techniques:
      • 72. Label element and title attributes.
      • 73. Or: Aria-labelledby, aria-label, & aria-describedby
      03 / 15 / 11
      Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
      40
    • 74. Labeling And Describing Widgets (2)
      • Aria-labelledby=“IDREFS”
      • 75. Value is one or more IDs of elements that identifiy the widget.
      • 76. The elements ‘aria-labelledby’ targets can be any kind of text based element, anywhere in the document.
      • 77. Add multiple Ids to concatinate label text:
      • 78. Multiple elements can label one widget, and one element can label multiple widgets. (example)
      • 79. Aria-describedby=“IDREFS”
      • 80. Similar to labelledby, except used for additional description, e.g. Form hints, instructions, etc.
      • 81. Aria-label
      • 82. Simply takes a string to be used as label.
      • 83. Quick and dirty way of making the screen reader say what you want.
      • 84. 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”>
      ...
      03 / 15 / 11
      Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
      41
    • 85. 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>
      03 / 15 / 11
      Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
      42
    • 86. ARIA Live Regions
      03 / 15 / 11
      Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
      43
    • 87. 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)
      03 / 15 / 11
      Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
      44
    • 88. What are Live Regions? (2)
      • Live regions enable assistive technologies (such as screen readers) to inform users of updates.
      • 89. 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.
      • 90. Example: stock updater
      03 / 15 / 11
      Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
      45
    • 91. 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.
      03 / 15 / 11
      Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
      46
    • 92. Live Regions: Politeness Levels
      • Aria-live="off"
      Default value, identical to not setting aria-live. Examples:
      • A DHTML clock
      • 93. Number of users currently online
      • 94. 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.
      • 95. Aria-live=“assertive”
      Updates are announced and interrupt what the user is doing
      • Only use for important updates that require immediate attention.
      • 96. Warnings & error notifications.
      • 97. Session timeout notifications
      03 / 15 / 11
      Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
      47
    • 98. 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;
      • 99. aria-atomic=“false”: only the part of the region that changed should be announced on its own.
      • 100. 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.
      • 101. aria-busy=“false”: region update is complete, AT can start announcing the update.
      03 / 15 / 11
      Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
      48
    • 102. 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.
      • 103. 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.
      03 / 15 / 11
      Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
      49
    • 104. 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
      • 105. Role=“log”
      Like marquee, but information is added in meaningful order and old information may disappear.
      03 / 15 / 11
      Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
      50
    • 106. Fallback solutions / Hacks
      03 / 15 / 11
      Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
      51
    • 107. Fall back solution for dialogs
      • In IE, JAWS currently does not properly announce dialogs when moving focus into them
      • 108. 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
      <fieldset role="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>
      03 / 15 / 11
      Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
      52
    • 109. 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>
      03 / 15 / 11
      Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
      53
    • 110. Fixing Structure: Aria-owns
      • Sometimes a widget structure is not explicit via the DOM and logical structure of a page.
      • 111. Aria-owns=“IDREFS”
      • 112. Indicates that the element(s) referenced by the IDs should be considered a child of the element that has this attribute.
      <h3 id="header">Vegetables</h3>
      <ul role="list" aria-labelledby="header" aria-owns="external_listitem">
      <li role="listitem">Carrot</li>
      <li role="listitem">Tomato</li>
      <li role="listitem">Lettuce</li>
      </ul>

      <div role="listitem" id="external_listitem">Asparagus</div>
      03 / 15 / 11
      Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
      54
    • 113. 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.
      • 114. 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
      03 / 15 / 11
      Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
      55
    • 115. 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.
      03 / 15 / 11
      Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
      56
    • 116. 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>
      03 / 15 / 11
      Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
      57
    • 117. Color and Contrast
      03 / 15 / 11
      Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
      58
    • 118. Sufficient Contrast for colors
      • To be WCAG 2 compliant, background and foreground colors for text needs to have sufficient contrast
      • 119. If that's not possible, it's an option to design a high(er) contrast theme that the user can enable
      03 / 15 / 11
      59
      Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
    • 120. Windows high contrast mode support
      • High Contrast Mode:
      Windows OS specific feature, inherited by browser
      Background & foreground colors are overridden
      Background images are stripped out
      • Problematic for widgets:
      They often use background color and images to indicate information (e.g. icons & selection highlights)
      • Solution:
      Detect whether high contrast mode is active
      If so, provide workarounds:
      • Inject html images or text to DOM
      • 121. Add additional visual indications, e.g. font weight, decoration & style
      03 / 15 / 11
      60
      Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
    • 122. high contrast mode example
      03 / 15 / 11
      61
      Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
    • 123. Wrapping Up
      03 / 15 / 11
      Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
      62
    • 124. Testing ARIA: approaches
      • To test if your ARIA works:
      • 125. Use a screen reader to try out your aria widgets and roles.
      • 126. JAWS 10 has decent support, but misses certain things
      • 127. NVDA has better ARIA support, is free and has a ‘silent’ mode
      • 128. Compare with widgets in Desktop to know what to expect.
      • 129. Using MSAA Tools
      • 130. Inspect32
      • 131. quick and effective
      • 132. Shows Focus role, states, name and description
      • 133. AccExplorer
      • 134. Lets you have a look at your page’s underlying ‘accessible tree
      • 135. Using Browser Tools
      • 136. Firebug for firefox
      • 137. Developer Tools for IE8
      03 / 15 / 11
      Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
      63
    • 138. Where to Find More
      Get Started with ARIA:
      http://www.w3.org/WAI/intro/aria
      ARIA Best Practices:
      http://www.w3.org/TR/wai-aria-practices/
      DHTML Styleguide:
      http://dev.aol.com/dhtml_style_guide
      03 / 15 / 11
      Accessibility of HTML5 and Rich Internet Applications - CSUN 2011
      64