4.1 Use of new provisions for keyboard focus and semantics to support platform accessibility APIs

Adaptive technologies, that need to provide alternative access to complex user interfaces authored via HTML, are often left guessing at the semantics behind specific portions of HTML document. As an example, an XHTML document might use a certain HTML construct, such as a collection of DIVs, to create navigation bars, a site-navigation menu, and other GUI-like user interface widgets. To fix the problem we will cover how we incorporate the role attribute, the accessible state properties, and give the object focus using the new TABINDEX feature. Addition of this information will allow the author to provide the necessary information to enable the user agent to support the accessibility api accessed by the adaptive technology.

4.1.1 Provision of the role attribute "What the object is"

Each platform accessibility API has the notion of a role for a GUI object. This is the case for Microsoft Active Accessibility (MSAA), the Java Accessibility API, the Gnome Accessibility Toolkit (ATK), the Mac Accessibility API for Cocoa, or UI Automation for Longhorn (called content type in UI Automation). To add this information we use namespaces to pull in the role attribute from XHTML2 and assign it a value from the GUI Role Taxonomy. Since the XHTML 2 role attribute takes a qname we can use a qname to reference the role attribute from the W3C WAI GUI RoleTaxonomy. In the following example we use namespaces to assign a role of menu to a div. Menu is defined in the GUI role taxonomy.


A decision by the HTML working group was to make role a qname and allow others to define sets of standard roles. Furthermore, these roles should be extensible. It is the intent of the HTML working group to have these qnames refer to RDF which defines the element. The RDF should ultimately define the object. The WAI Role Taxonomy for Accessible Adaptable Applications, covered later in this roadmap, introduces the purpose of this taxonomy and how RDF can be used to describe these roles.

4.1.2 Provision of the accessibility state information "What meaningful properties does this object have at this time"

Since this is dynamic content, the state of these new repurposed objects will change. The WAI Accessible States and Adaptable Properties Module shall provide the common accessible properties needed to support the accessible state or property information provided by the platform accessibility API defined previously. This specification was created based on an analysis of the accessibility properties defined in MSAA and ATK. To pull in these information we again use namepaces to extend XHTML. The following example extends the previous by adding the haspopup accessibility property.



A Windows user agent may now map this property to the Microsoft Active Accessibility state of STATE_SYSTEM_HASPOPUP. Adding or removing this state would result in the Windows user agent sending an EVENT_OBJECT_STATECHANGE event to the assistive technology. The task of the JavaScript page author would be to maintain this state attribute which can easily be done through the use of Document Object Model calls.

4.1.3 Provision of the keyboard or input focus "What object am I working on?

Virtually all adaptive technology solutions, such as screen readers and onscreen keyboards, need to know what object currently has focus. For example, I might want to insert text into the current object with focus or I might want to announce information about the object that has focus. Today, HTML 4.01 and XHTML 1.x limit script authors to only being able to provide focus to form and anchor elements yet the Document Object Model Specification allows all elements to receive events including keyboard events. This means that HTML, by design prohibits script authors from making all HTML elements keyboard accessible. This single problem has impacted the usability of web pages whereas gaining access to all elemens means using the tab key on desktop browsers. This slow, unproductive, approach makes it difficult for portal navigation whereas all active elements must be tabbed through to get to an active element in the last portlet in a document.

To solve this problem in XHTML 1.x we are incorporating a feature in Firefox and IE to define the tabindex for -1. This allows a script author to give an element focus without placing it in the tab order: The following table desribes these changes which will be incorporated into the new Accessible Adapative Application specfication.

tabindex attribute	Focusable with mouse or JavaScript via element.focus()	Tab navigable
not present	Follows default behavior of element (yes for form controls, links, etc.)	Follows default behavior of element
Negative, e.g. tabindex="-1"	Yes	No, author must focus it with element.focus() as a result of arrow or other key press
Zero, e.g. tabindex="0"	Yes	In tab order relative to element's position in document
Positive, e.g. tabindex="33"	Yes	Tabindex value directly specifies where this element is positioned in the tab order. These elements will be positioned in the tab order before elements that have tabindex="0" or that are naturally included in the tab order (form elements and links)

The following example shows the introduction of TABINDEX to provide focus to a DIV having the new accessibility meta data:



XHTML 2 will allow all elements to receive focus, eliminating the need for this tabindex modification.

4.2 Use of XHTML2 role landmarks to improve document navigation

In addition to the common roles which will reside in the GUI Role Taxonomy, XHTML 2.0 defines a collection of common roles that define pertinent parts of a document for the purpose of accessibility. User agents may incorporate device equivalents, such as key mappings in the case of a desktop user agent, to navigate to these sections of a document independent of the web site. The addition of these semantics allows the user agent to provide standardized navigation to common document sections. This is especially important for portals to improve the usability. These may be used as attributes in XHTML 1.x by applying them to sections of the document as shown in this example.



An an alternative to placing these landmarks on the XHTML elements is to place them in the header through the use of link which is also applicable to HTML 4.01. Here, Link's rel attribute may take an string value which may be used to represent the landmark. Additionally, a description may be added to the title as shown in this example:



This is being worked by the WAI coordination group as a best practice. The example above was taken from the header from the Career Center web page at the University of Illinois at Urbana-Champaign.

Students form this university, under the Jon Gunderson's guidance created Accessibility extensions for Mozilla/Firefox, in part, allow a page author or user to launch a table of contents to viewer to list the landmarks. Keyboard navigation of the table of contents causes the corresponding document section to be highlighted.

Figure 3.0 Table of Contents generated from navigation landmarks in the header



Figure 3.0 shows the Accessibility extensions for Mozilla/Firefox from the University of Illinois at Urbana-Champaign to render the document landmarks. This picture shows the Firefox Browser rendering the University of Illinois Career Career Center home page. In this example. The "Table of Contents" viewer is shown launched from the extension on the toolbar and the secondary "Featured Events" is selected resulting in that section of the document to be highlighted in yellow. The Table of Contents viewer lists the following section type/title pairs:

• Banner / Career Center
• Navigation / Career Counseling Resources
• Navigation / Quick Links
• Navigation / Resources by Audience
• Main / Welcome to the Career Center
• Secondary / Content Info
• Secondary / Featured Events
• Search / Search Career Center
  

4.3 WAI Role TAXONOMY for Accessible Adaptable Applications - Define XML Extensible Semantics for Role through RDF

It will be necessary to describe how to interact with a document element having a specific role. This is critical when defining roles not included in the common set specified previously. It should be possible to describe UI widgets and how to interact with them. RDF is a way for using data to describe data and provides a W3C standards-based approach to represent this information.

Figure 4.0 Partial RDF Map for a GUI Role Taxonomy

 

Figure 4.0 Shows a basic RDF mapping which defines a set of terms and relationships defining an object. At the center is a Widget object that defines common states and properties for all GUI widgets. The Button object extends Widget and inherits defined accessibility properties from the superclass Widget. It also defines a relatedConcept property to a Link object. The ButtonUndo role extends Button and an instance of extends of Button. It  has a relatedConcept of an HTML input object. ButtonUndo will introduce Dublin Core meta data such as the description of the object.

The terms relatedConcept and requiredState are terms which which will be defined as part of the corresponding RDF schema. Each role instance will represent standard Roles found in platform accessibility APIs platforms like Windows and Gnome as well as content structure. These roles will form the taxonomy. Each RDF role may be referenced  using a qname from Host XML markup such as XHTML:


<div x2:role="wairole:ButtonUndo">

whereby wairole:ButtonUndo expands to:

http://www.w3.org/2005/01/wai-rdf/GUIRoleTaxonomy#ButtonUndo in the button markup

The power of this design is it allows user agents to go back into the corresponding RDF markup and determine what properties it supports for Accessibility API mapping. Also, new web authoring tools can use the self describing RDF to help test for accessibility conformance to semantic web markup representing the role. Additional, middleware solutions can now make intelligent transformations of Web Content by processing the semantics behind rich browser and rich structured frameworks to adapt accessible solutions for a broader user base.

Our immediate goal is to fix the accessibility problem with scripted web content.

Assistive technologies will use the standard roles to determine how to render most content. For custom widgets they should be able to determine how to interact with it using the RDF document defining the roles.

Figure 5.0 DHTML Example



Figure 5.0 shows a DHTML example of using XHTML, JavaScript, and CSS to produce a GUI-like application. This example of a DHTML web page being developed in IBM shows a notebook tab with a data grid that behaves like you would expect a GUI to. Keyboard navigation within the data grid is done with arrow keys. Navigation among the page tabs is done with the arrow key. Navigation between the notebook tab, the edit fields, buttons, and the data grid is done using the tab key. Accessible role and state meta data from the GUI role taxonomy and Accessible Adaptable Application specifications, respectively are added as attributes to each of the XHTML elements repurposed as GUI widgets dynamically. The user agent, in this case Firefox, maps this information to the platform accessibility API. Figure 6.0 shows the Microsoft Active Accessibility rendering of the new accessibility markup provided on the DataGrid page tab which has focus.

Figure 6.0 Microsoft Inspect Tool rendering of the page tab DataGrid



Figure 6.0 is a Microsoft Inspect 32 rendering of the DataGrid Page page tab in Figure 5.0. Inspect32 provides Microsoft Active Accessibility Information. It shows the accessible role of "page tab" and accessible state information of focused, focusable, and linked. There are no page tab elements in XHTML. Here, an  XHTML DIV element is repurposed by a JavaScript controller to look like a notebook tab. It is now able to receive focus unlike in standard XHTML 1.X. It can do so without requiring tabbing. With  these specifications the script author may now add the accessibility properties to support platform accessibility API. Accessible state properties for the DataGrid page tab are shown as focused, focusable, and linked. Unlike a GUI application, the author need only enable their application once for multiple operating system platforms.

4.3.1 Future Opportunities of Roles and Semantic Web Technology

Beyond scripted web content, the working group intends to extend the use of roles to enable other user cases. These may include:

• Structured Textual Markup - enhancing structure of the markup of a document, including Data Tables , or translating the structure of an XML document to a markup structure that user agents are used to dealing with (e.g. myXML to XHTML) Binding sections of a document to a common role. This allows for different navigation techniques though a document
• Knowledge representation of web content - As a secondary benefit, Roles improves compatibility Knowledge-Based Services and the Semantic Web. In integrating accessibility and the semantic web, accessibility can be moved forward, paving the way for customized accessible searches and intelligent user agents with additional applications.
• Adding concepts in the type of content for adaptation to the user scenario - The more that is understood about content the better it can be adapted for the end user. For example:
  
  
  1. If it is known that a page hyperlink has the role of taking the user to the site’s home page, then that knowledge can be used to create enhanced accessibility in different ways in many different scenarios, such as icons or accesskeys.
  2. If it is known that a text box is for the user email address then the user agent can support users filling in the form by labeling it with an icon or symbol, automatically validating it, or even form filling.
  3. If it is known that a paragraph is complex, a simple equivalent can be shown in its place
  4. If a word is ambiguous then a role of a concept can be give, providing clarity
      An example of this may be :
     
     <span x2:role="role:nonliteral" aaa:hasAlternate="no">

4.4 Accessibility Events and Event Handling

Interoperability between applications and assistive technologies requires event notification for accessibility. The events defined in Table 2.0 will be fired via the user agent. The accessible value and state property changes will be generated in response to changes in the DOM attributes as defined by the AAA specification. User agents supporting the platform accessibility API, will support event notification such as the MSAA EVENT_OBJECT_STATECHANGE or EVENT_OBJECT_VALUECHANGE events.

4.5 XML events, XForms, XHTML2, and declarative markup - A Look Ahead

Up to this point, the roadmap has discussed addressing today's XHTML markup as supported by today's desktop browsers. The markup in today's browsers, like accessibility, requires developers to do things manually through the use of JavaScript. While this is extremely flexible it suffers from a number of problems:

• Although improvements have occurred, JavaScript is not the same on all browsers and platforms
• Data models are inconsistent
• Accessibility is bolted on rather than being built in
• Accessibility solutions are more device dependent than we like
  
• Heavy accessibility lifting is done by the author in line with the way JavaScript is used

Industry evolution has shown that we can do things better and produce more consistent cross-platform solutions which support accessibility and reduce the enablement efforts of the author.

4.5.1 XML Events and Handlers - adding purpose to actions

HTML is a device dependent solution. An impaired user needs to make an intelligent decision as to what actions they can perform on a document element. An impaired user wishing to enumerate the available actions that may be performed on a page element is confronted with the non-informative information provided by HTML's intrinsic events. The information provided is very device specific and non-informative. For example, what action does an event handler perform in response to an onclick event? This is problematic for blind, low vision, and mobility impaired users. There may be more than one action to be performed on a given element. A mobility impaired user would like to enumerate the handlers and make a decison. Generating the appropriate mouse event is problematic. Blind users and low vision users would like to make informed decisions before they accidentally make a purchase. Some information can be gleaned from the UI by sited users, however some of this information may be obscured from view due to the use of a magnifier by low vision users.

The HTML working group is working to address this problem through the use of XML events. XML Events provide XML languages with the ability to uniformly integrate event listeners and associated event handlers with Document Object Model (DOM) Level 2 event interfaces [DOM2EVENTS]. The result is to provide an interoperable way of associating behaviors with document-level markup. Through the use of XML this is done declaratively. Having the ability to use XML to integrate listeners and handlers will allow us in in future versions of the XML event specification to tie a descriptive purpose to the handlers.

This problem also manifests itself when encountering event handlers authored via element script. XML Events and XML Handlers solves the first half of the accessibility problem by introducing a clean declarative syntax while encouraging authors to use high-level event names and descriptions. This gives the author the flexibility to assign device specfic mappings to event handlers while providing for added semantics. In XForms 1.0, we have gone one step further by introducing declarative action handlers for commonly used event handlers, e.g., setfocus. The combination of REL navigation semantics, XML events, XML handlers, and XForms declarative markup set the stage for an access key replacement. Access key suffers from a lack of semantics and support for device independence.

Dynamic web content implies the use of event handlers. From an accessibility perspective we need to assist the user in determining how to interact with a web application in a device independent way. The provision for named events and the ability to bind event handlers to document element events in the  XML Event specification is critical. At the time of binding we can incoporate the additional Role information as well as make use of the name information to provide semantics about what the event handler does. In the future, this information should be mapped to the available accessibility infrastructure by a, UAAG conforming, user agent on the platform. Once complete, a user agent conforming to the  DOM 3 event specification will allow for enumeration of event handlers with corresponding descriptions. The ability to ask this information has been added to the EventTarget interface in DOM3 events through the hasEventListenerNS method.

Platform accessibility API like the Gnome ATSPI Accessible Action interface may now enumerate these actions for assistive technologies so that the user may be provided with descriptive information to make an informed decision as to which action to take.

Screen Reader user would be able to pop-up a list of event handlers in a list such as follows:

• Role over help information
• Submit the form

vs:

• OnMouseOver
• OnClick

Authors wishing to incorporate XML events may do so to existing XHTML 1.1. markup through modularization.