Introduction

JavaScript is found on over 50% of all web sites today, dramatically affecting the ability for persons with disabilities to access web content.  An increasing number of web applications are utilizing JavaScript to mimic desktop widgets like menus, tree views, rich text fields and tab panels. Web developers are constantly innovating, and future applications will contain complex, interactive elements such as spreadsheets, calendars, organizational charts and beyond. Until now, no accessibility solution has existed for these advanced web applications -- even if a web developer wanted to do the right thing.

Custom widgets are not a new problem.  For years, desktop GUI frameworks have made it possible to develop accessible versions of custom widgets through several methodologies. First, GUI frameworks allow developers to make any widget focusable and tab navigable. Second, GUI frameworks provide accessibility APIs to facilitate interoperability with assistive technologies such as screen readers. These APIs allow a developer to provide the information that assistive technologies need -- such as the "who, what and where" of any custom widget that a user can interact with. Finally, these APIs provide the basis for an accessible, dynamically changing application.

IBM is leading an effort in the W3C to create a similar accessibility solution for JavaScript-based web applications. In fact, the Web Content Accessibility Guidelines 2.0 will be the first W3C accessibility standard which does not discourage the use of JavaScript. A number of other efforts at IBM and initiatives in W3C are being pulled together into a cohesive roadmap, called the DHTML Web Content Task Force Roadmap. The roadmap is based on Gap architectural analysis procedures used by the IBM Accessibility Architecture Review board. The analysis has found that functionality, such as accessibility meta data, supported in platform accessibility APIs for GUIs, is missing today and needs to be added so that the platform accessibility architecture may be supported. This effort defines the need for open standards and assistive technology support. IBM is partnering with GW Micro to adopt support for these standards into the Window-Eyes screen reader. IBM has already partnered with GW Micro on making Mozilla accessible through Window-Eyes.

This presentation is designed to show the audience how the Gap analysis was used to create a strategy to solve the DHTML accessibility problem. It will: Demonstrate how the resulting roadmap is being employed to address the problems; Describe the standards being developed; Demonstrate how the end result will lead to a much more usable experience for all.

A look at GUI accessibility architectures 

• Role - What the component or object is
• State - The state of the potentially dynamically changing object (e.g. checked, expanded, collapsed, visible, showing)
• Caret - The caret position in a text component
• Selection - What is currently selected by the user
• Value - The value of an object (such as a slider value)
• Name - The actual name or object label.
• Description -  Description or help  information about the object
• parent/children - relationship to  parent and child objects
• changes - Change event notification of states or other accessibility data
• Relationships - Relationship to other objects  outside  parent/child  such as (group, label for, and controller for)
  

Analyzing the Problem

DOM Node Analysis

Authors of JavaScript generated content do not want to tie themselves to the standard tag elements that define the actual user interface element such as tables, ordered lists, etc. JavaScript authors will also make extensive use of tag elements such as DIVs where they will dynamically apply a UI through the use of style sheets and dynamic content changes. A DIV allows for little semantic information. The page author may define a DIV as the start of a pop-up menu or even an ordered list. A page author cannot convey the role of the DIV as being a pop-up menu. A page author cannot tell an assistive technology when these elements have focus. There is no semantic event to do this. There is no mechanism to convey state information as to whether the pop-up menu is collapsed or expanded. There is no mechanism to define what the actions are that can be formed on the element other than through a device-dependent means via the event handler type (onmouseover, onclick, etc.)

In short JavaScript needs an accessibility architecture it can write to so that a solution can be mapped to the accessibility frameworks on the native platform by the user agent.

Figure 3.0 Accessibility Interoperability at a DOM Node

The Focus Problem

A Look at Device Independence

GAP analysis

Filling the Gaps using today's XHTML and HTML

Manipulating the focus

How to Use the New System

To make simple tab navigable widgets, the solution is to use tabindex="0" on the <div> or <span> representing it. Here's an example of a span based checkbox (http://www.mozilla.org/access/samples/span-checkbox) that is keyboard accessible in both Mozilla 1.8a5 and IE (although the:before rule for the checkbox image doesn't work in IE).

For grouping widgets, such as menus, tab panels, grids or tree views, the parent element should have tabindex="0", and each descendent choice/tab/cell/row should have tabindex="-1". A keydown event that watches for arrow keys can then use element.focus() to set the focus on the appropriate descendent widget and style it so that it appears focused. Note that setTimeout() must be used in conjunction with the focus call or it will be ignored.  See "Implementation Details" section for more details.

Keep in mind that this is not yet part of any W3C or other official standard. At this time it is necessary to bend the rules in order to have full keyboard accessibility.

Now that we can give these object's focus we now need to tell the assistive technology and the user agent what the role of the object is.

XHTML 2 and the introduction of the "role" attribute

• What the object is
• How do I process it (e.g. How does the user agent convert it to an accessibility API for the screen reader)
• How the object relates to other objects in the taxonomy
  

Example: Use of XHTML 2.0 Role meta data in
XHTMl 1.0 or XHTML 1.1

<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:x2="http://www.w3.org/2002/06/xhtml2"
xmlns:wai="http://www.w3.org/2004/roleset"
xmlns:wairoles= "http://www.w3.org/2005/01/wai-rdf/GUIAccessTaxonomy#"
>
 <head>
   <link rel="x2:navigation" id="#div1"></link>
 </head>
    <body>
    <table border=2>
       <tr><td>hello</td><td>world</td></tr>
    </table> 
    <div id= "div1" tabindex=-1 x2:role="wairoles:menu">
    </div>
</body>
</html>

WAI GUI Role Taxonomy

Introducing state Attributes - The WAI State Taxonomy

<html lang="en" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml"
      xmlns:x2="http://www.w3.org/TR/xhtml2"
      xmlns:wai="http://www.w3.org/wai/pf/GUIRoleTaxonomy#"
      xmlns:waistate="http://www.w3.org/wai/pf/GUIStateTaxonomy#">
..........................

  <span class="checkbox" id="chbox1" x2:role="wai:checkbox" waistate:checked="true" tabindex="0"
        onkeydown="return checkBoxEvent(event);" onclick="return checkBoxEvent(event);" >
    Include decorative fruit basket
  </span>

function checkBoxEvent(event)
{
  if ((event.type == "click" && event.button == 0) ||
      (event.type == "keydown" && event.keyCode == 32)) {
    // Toggle checkbox
    var checkbox = event.target;
    if (checkbox.getAttributeNS("http://www.w3.org/wai/pf/GUIStateTaxonomy#", "checked") == "true") {
       checkbox.removeAttributeNS("http://www.w3.org/wai/pf/GUIStateTaxonomy#", "checked");
    }
    else {
      checkbox.setAttributeNS("http://www.w3.org/wai/pf/GUIStateTaxonomy#", "checked", "true");
    }
    return false;  // Don't continue propagating event
  }
  return true;  // Browser can still use event
};

<style TYPE="text/css">
  @namespace state url("http://www.w3.org/wai/pf/GUIStateTaxonomy#");
  
  .checkbox:before {
    content: url('./unchecked.gif')
   }
  .checkbox[state|checked="true"]:before {
    content: url('./checked.gif')
  }
</style>

Keyboard Accessibility - Making HTML act like a GUI

• May need both onclick and onkeydown events. You will need to handle both mouse and keyboard events for items with tabindex. For example, if you have an onclick="doSomething()" you may also need onkeydown="if (event.keyCode == 13){ return doSomething();}" in order to allow the Enter key to activate the element. Save point of regard  information so mouse and keyboard can interact
  
• For best browser compatibility use the onkeydown event. The onkeypress event only supports alphanumeric events (no arrows) in IE.   Firefox has been updated so that this event is now cancelable in both IE and Firefox.
• Stop propagation of handled keyboard events.  When an arrow key is used to navigate within a component, prevent the browser from using the key to do something (such as scrolling) via:
  <span tabindex="-1" onkeydown="return handleKeyDown();">. If handleKeyDown() returns false, the event will be consumed and thus the browser will not perform any action based on the keystroke. A return value of true indicates that the event was not handled and should be handled by the browser in the normal fashion. 
• Don't capture all keyboard events.  Allow any appropriate user agent key combinations to behave as normal.  For example, if every arrow key event is captured the browser commands to navigate forward and back which are implemented via alt-left arrow and alt-right arrow, respectively will no longer work. Only handle the arrow keys that are not modified with the alt key for navigation within the widget.
  
• Place the event at the highest level object possible. This avoids having to add an event handler on each navigable element. 
  
• Dynamically change the focus ability of widgets using the ta index property.  Change the tabindex value of a widget from 0 to -1 if it becomes disabled. Disabled widgets should not be in the tab order.  However, you can typically arrow to them if they're part of grouped navigation widget.
  
• Use setTimeout with element.focus() to set focus: Do not use createEvent(), initEvent() and dispatchEvent() to send focus to an element, because DOM focus events are considered informational only -- generated by the system after something is focused, but not actually used to set focus. The timeout is necessary in both IE and Mozilla, to prevent scripts from doing strange unexpected things as the user clicks on buttons and other controls. The actual code to focus an element will look something like this:
  setTimeout("gFocusItem.focus();",0);  // gFocusItem must be a global
• Don't use :focus or attribute selectors to style the focus.  Unfortunately IE does not support the CSS  :focus pseudo-class on all elements nor does it support CSS attribute selectors.  In order  to show the focus on an element the JavaScript author must specifically set the focus style in an onfocus event handler. For example, in a <div> menu item's focus handler add this.style.backgroundColor = "gray";.
• Draw the focus for tabindex="-1" items and elements that receive focus programmatically. IE will not automatically draw the focus outline for items that programmatically receive focus. Consider changing the background color via something like "this.style.backgroundColor='gray';" and adding  a dotted border via "this.style.border='1px dotted invert';".
• Do not rely on color alone to distinguish focus.    In the dotted border case above you will need to make sure those elements have an invisible 1px border to begin with, so that the element doesn't grow when the border style is applied.  This is because borders take up space, and IE doesn't implement the CSS outline attribute which does not.
• Use try/catch to avoid JavaScript errors. This system is not currently supported by Opera, Safari, Firefox (as of 1.0) and older versions of Mozilla (1.7 and earlier). Because some browsers don't support the new capabilities like the tabindex property on all elements, use try/catch where appropriate. The widgets should still be usable with the mouse on those browsers that don't support the DHTML key navigation system. Support is planned for future versions of Opera and Safari (via WHATWG specs).

Assistive Technology Support and User Agents Support

Future advancements

Looking forward there are things that can be done to not only improve dynamic web access but there things we can do to provide better access.

A Look ahead XHTML2 and XForms

Access - Access key replacement (descriptions, device independence)

• Uses title for description
• Optional Keyboard shortcut
• style-able
  
• Optional Role based navigation
• Optional targetID for navigation
  
• Options to select the event fired (activate, provide focus, etc.)
  

Standard roles for document landmarks

main

This defines the main content of a document.

secondary

This is any unique section of the document. In the case of a portal, this may include but not be limited to: show times; current weather; or stocks to watch.

navigation

This is the navigation bar on a web document. This is typically a list of links to other pages on the site or other areas of the same document.

banner

A banner is usually defined as the advertisement at the top of a web page. The banner content typically contains the site or company logo and other key advertisements for the site.

contentinfo

This is information about the content on the page. For example, footnotes, copyrights, links to privacy statements, etc. would belong here.

note

The content is parenthetic or ancillary to the main content of the resource.

seealso

Indicates that the element contains content that is related to the main content of the page.

search

This is the search section of a web document. This is typically a form used to submit search requests about the site or is a more general Internet wide search service.

New Accessibility Features of XForms

Event Model Accessibility Features

• next and previous
• focus
  
• help and hint
• refresh
• revalidate
• recalculate
• rebuild
• reset
• submit
  

• Activate
• Value change
• Select and Deselect
• Scroll First, Scroll Last
• Insert, Delete
• Valid, Invalid
• FocusIn
• FocusOut
• ReadOnly, ReadWrite
  
• Required, Optional
  
• in-range, out-of-range
• submit-done
• submit-error
  

Use of a Model-View-Controller design:

About this session 

The audience will gain an understanding of:

• Accessibility Issues with Dynamic web content
• Limited keyboard access
• Limited assistive technology support
• Unaddressed gaps in the technology
• Near-term Open Standard Solutions based on XHTML
  
• Work with W3C to develop new standards for semantic meta data
  
• Work with browser manufacturers to support the new standards.
• Provide full keyboard focus and tab navigation - available today.
• Accessible, dynamic custom widgets
• Work with assistive technology vendors to support new standards
  
• Future Solutions (Target beyond the desktop and HTML)
  
• Full replacement for accesskey
  
• Advances in tooling to support accessible dynamic web content
  
• Continue working with W3C on standards to reflect the new possibilities
• Accessibility features targeted for XHTML 2, XForms
  

The presenters will give a live demonstration of these new standards implemented on an XHTML 1.1 web page using Mozilla and working with a screen reader.