Abstract

W3C roadmap for addressing the accessibility of dynamic web content.

Request for Comments

The PF working group has
developed this roadmap
for making dynamic
web content more accessible to people with
disabilities. To assure this roadmap and the corresponding technologies
produced to support it will interoperate in a
manner that improves accessibility for the widest range of web
technologies, the PF working group asks for comments and suggestions on
how this roadmap can be improved for use in the technologies that
you or your working group are developing. In general we prefer public comments so that all people
(including the general public) reviewing the document can be aware of
your comments, but you may also send member
confidential comments that will be available only to the working
group and other W3C members.

Dynamic Accessible Web
Content
Roadmap

JavaScript is found on over 50%
of all web sites today, dramatically
affecting the ability for persons with disabilities to access web
content. New Rich Internet web applications are being created to render
custom
widgets modeling rich desktop componentry. Legacy GUI accessibility
frameworks address these issues through a comprehensive accessibility
API and infrastructure to foster interoperability with assistive
technologies. These API's constitute a contract between applications
and assistive technologies, such as screen readers, to allow them to
gain access to rich dynamic content with the appropriate semantics
needed to produce a usable alternative.

Unfortunately, HTML and other markup does not provide adequate
markup to support accessible dynamic content. Until now, the W3C WAI
has discouraged the use of JavaScript per Web
Content Accessibility Guidelines (WCAG) 1.0. The W3C has a number
of initiatives in the pipeline to address this problem using a
declarative markup approach. This roadmap is designed to create a
bridge to fix the interoperability probem with assistive technologies
today by incorporating the appropriate meta data in today's XHTML
markup to support today's accessibility API. It will incorporate some
of the advanced accessibility features in technologies like XHTML2. The
intent of XHTML 2 is to make the enablement of web applications and
documents easier for authors. This roadmap will create cross-cutting
technologies which may be incorporated by XHTML 2 authors in their
markup to describe GUI widgets and document structure to assist
assistive technology vendors in providing accessible, usable solutions.
The W3C WAI PF working group will work with User Agent manufacturers
and assistive technology
vendors to ensure we have a working solution.

1.0 The Problem

Accessibility for traditional HTML suffers from a number of problems
that
make it difficult to support dynamic content:

Accessibility
is dependent on abstracting semantics from both content and
presentation
information. Extracting this semantics from today's HTML content is
typically not reliable. Today,
semantics
are limited to the tag elements names.

HTML allows content to be repurposed for presentation formatting
without providing a way to convey this information. A common example of
this is the use of tables for formatting content as opposed to style
sheets.

HTML, when combined with script and CSS may be repurposed to
create dynamic custom components without the ability for the author to
convey this information to the native accessibility
architectures designed to support dynamic GUI content.

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 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. An HTML DIV provides no
semantic
information. The page author may define a DIV as the start
of a
pop-up menu or even an ordered list. No HTML facility provides a
mechanism for the page author cannot convey the
role of
the DIV as being a pop-up menu. Consequently, a page author cannot tell
an assistive
technology when these elements have focus. There is
no mechanism to convey accessibility property information as to whether
the pop-up menu
is
collapsed or expanded. There is also no mechanism to define what the
actions
are
that can be formed on the element other than through a
device-dependent
means through the event handler type (onmouseover, onclick, etc.)

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

Figures1.0 Accessibility Interoperability at a
DOM Node
without JavaScript

t

Figure 1.0 illustrates a typical DOM node in a
Model-View-Controller architecture. On the node, data, or the "Model",
which should include semantic information, is separated from the user
interface presentation, the "View." Here, the document element is
managed by the user agent based on the default behavior of the element.
The user agent's default behavior at the document element forms the
controller. Placed between the DOM
node and the asssistive technology is a box containing the contract
provided
by the user agent to the assistive technology. This data includes
typical accessibility information found in the accessibility API for
many of
our accessible
platforms for GUIs (role, state, caret, selection, text, hypertext,
name description,
parent/child
information, parent/child information, and relations). For HTML and
other W3C
markup, the accessibility information provided is dependent on that
which is provided by the element's tag name and any accessibilility
attributes that map to that provided. For example, the accessible role
of a table is table. The accessible description would be provided by
the author by assigning a title attribute.

Figure 2.0 Accessibility Interoperability at a
DOM node with JavaScript)

Figure 2.0 shows the same DOM node provided in
Figure 1.0 but with JavaScript acting as the new controller.
JavaScript overrides the default user agent behavior at the DOM node.
It manipulates the data, content, and style in response to events
caused
by user interaction to produce Custom widgets. In this situation the
default accessibility information is no longer valid and therefore the
contract is now invalid. Figure 2.0 shows the contract with asterisks
in
front of role, state, actions, value, event changes, and
relations. These asterisks represent potential accessibility errors
and gaps in the base markup. These gaps result from the author's
inability to provide the new semantic data needed to support the
contract.

2.0 Requirements

Allow for discovery of custom UI components through
the use of semantic web technologies

Web ontologies allow for storage of semantic information about
objects and how they relate to others in the ontology.

Solution must support today's accessibility
architectures

Accessibilty architecture today is centered around object
technology. Each object in an application or document, exposes
accessibility information about itself to an assistive technology.

Allow for separation of content and presentation

Dynamic content authors must be able to store the accessible
meta data in the document independent of how it is rendered.

Allow for passive monitoring of the application by
an assistive technology

Assistive technology vendors should not be required to poll an
application for changes in accessibility information.

Leverage new W3C efforts to solve the problem

This problem needs to be solved quickly. There are a number of
efforts underway, such that minimal changes may be required to bring
them to the level needed.

Light weight

The solution needs to be light-weight in order to see uptake
among HTML authors.

Scaleable

The solution needs to be scalable, i.e., make simple things easy
while making complex things possible.

Internationalizable

Like other Web solutions, our solutions must be
internationalizable.

Guarantee User Agent support up front

We need to involve user agent manufacturers up front

Involve assistive technology vendors up front

Assistive technology vendors need to be involved from day one.
We
need to leverage support by AT vendors so that we can have a total
solution available when the specification is complete

Produce Developer Guidelines during the process

This is a critical mistake made by people creating a new
accessibility model. Developers must be on board early on so that they
may contribute feedback and start producing workable solutions early.

3.0 Proposed Solution

3.1 Executive summary

What is clear from the problem statement is that the author does not
have the ability to provide the appropriate accessibility information
in the markup to support the accessibility APIs on the target platform.
This problem is not limited to HTML. It extends to other markup,
including SVG. Some of these issues will be addressed through the
introduction of declarative markup. New work being done on XForms and
XHTML 2 are designed to incorporate accessibility features through the
declarative markup of the language. This has the added benefit of
reducing the enablement effort by authors through leveraging the
existing accessibility information stored in these markups to offload
some of the accessibility work to the User Agent. That said, we need to
build a bridge which will fill the accessibility gaps on today's HTML
markup which will lead to broad applicability to today's markup while
moving forward with declarative markup to reduce the enablement effort.

3.2 HTML Accessibility API
Support Analysis

Using Figure 1.0 as template for addressing the
problem and 508
accessibility
standards, a Gap analysis has been constructed in Table
1.0 to show
where
the gaps are in the infrastructure and what W3C standards should be
used to
address the problem. In right column, table cells which are empty or
which indicate a limitation represent accessibility gaps in HTML and
XHTML.

Provide focus to all active elements
(important for equivalent keyboard access on desktops)

Limited to forms and achors

4.0 The Roadmap - Filling the Gaps

At this time, the primary effort in the W3C WAI Protocols and
Formats working group is to focus on an extension to XHTML 1.1. It
should be noted that XHTML 1.0 could also be enhance to support this
extension through the use of a hybrid DTD which incorporates the
extensions. The reason for focusing on XHTML 1.X is that XHTML is
extensible through the use of namespaces and because it is renderable
by
today's browses. For this work, we will be producing a document called
the Accessible Adaptive Applications (AAA) document and a GUI role
taxonomy document. The AAA will constitue extensions to XHTML 1.1 to
fill most of the gaps needed to support accessibility API
infrastructures and dynamic XHTML content. It will also borrow the role
attribute from XHTML 2 for which a set of accessible role values may be
applied from the WAI GUI Role Taxonomy specification. The Role
taxonomy specification will provide the necessary core roles found in
Accesssibility API sets for Windows and Linux. Additionally, it will
contain roles which are representative of document structure. The use
of document structure is necessary for assistive technologies to
navigate complex documents and to know when they have entered active
areas of a web page such as in the case of a dynamic scripted web
application. It will be designed to assist the user agent or authoring
tool in determining what properties are supported by a given role and
assist with accessibility api mapping of these properties. The taxonomy
will be like a class hierarchy used to convey semantics and structure
and therefor knowledge about each role. At this time that taxonomy will
be written in RDF.

The GUI Role Taxonomy specification is meant to be cross-cutting.
XHTML 2
introduces the role attribute as part of its built-in accessibility
support. The common roles defined in this taxonomy may also be applied
to XHTML 2 content and other markup such as SVG should those efforts
allow for a mechanism to reference these common roles.

Table 2.0 GAP Analysis - Progressive
Filling of the Gaps for HTML
in support of Accessibility API

User Agent to monitor specific
accessibility properties in the AAA. For
properties representing platform accessibility API values as specified
by a given role, it will
generate an accessible value change event. (See Value
Change)

User Agent to monitor change
from WAI
State Taxonomy information supplied by the Author
and fire the platform specific Accessibility API event

User Agent to map new AAA
properties and role meta data to the platform accessibility API

Provide focus to all
active elements

TABINDEX=-1 best practice

TABINDEX

TABINDEX

All XHTML 2 elements shall be
focusable.

Table 2.0 shows
the roadmap for filling
the gaps in Table 1.0. The
effort is designed to fill the gaps for HTML content. Required
components marked with an asterisk indicate gaps to fill in the
roadmap.
As you move to
the
right in the table a transition to more declarative markup will take
place. The use of declarative markup reduces the enablement effort
required while better addressing
accessibility. Declarative markup is used to build accessibility in
rather than bolting it on. Subsequent sections highlight the
requirements and standards efforts set to address the gaps.

A way to summarize this chart is that the critical extensions needed
to
make accessible dynamic web content accessible for XHTML 1.x, that may
be made interoperable with assistive technologies, will be provided
through the use of:

AAA Specification

XHTML 2 role attribute

XHTML 2 role document landmarks

WAI GUI Role Taxonomy Specification

In short, these changes will fix the dynamic acripted web
content, in particular the use of JavaScript with HTML markup.
The next section will describe how these are used all together. Less
critical for XHTML 1.X but will be very helpful for accessibility
will be the descriptive extensions to XML events and the new access
element for XHTML 2.

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.

Example: Use of namespaces to incorporate role
information information into XHTML 1.x

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.

Example: Use of namespaces to incorporate
accessible state information information into XHTML 1.x

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.

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:

Example: Use of tabindex to give non-form and
anchor elements focus in XHTML 1.x

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.

Example: Use of namespacs to incorporate an
XHTML 2.0 common landmark to define a landmark for the navigation
section in an XHTML 1.X document

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:

Example: Use of Link/Rel with an ID href
and title to assign a document landmark

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:

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:

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.

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.

If it is known that a paragraph is complex, a
simple equivalent can be shown in its place

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.

The introduction of standardized events that reduce the need for
specialized JavaScript.

The first benefit is less JavaScript. XForms provides a common set
of available actions that can be performed
on a form. XForms
is a delarative markup. The engineers who designed XForms took the
standard use cases for how we create forms and built in support for the
standard actions performed in a web form. From an accessibility
perspective, this means these functions should be available from the
browser independent of platform. So, rather than guess what an onclick
does on a form, the user should be able to access the available
functions and Notification events that are used in that specific form
as defined by the XForms standard.

In addition to device independent events, XForms also provides another
powerful feature by its model-view-controller design. XForms separates
content from presentation while embedding relevant meta data in user
interface constructs.

XForms provides the following meta data: label for the user interface controlhint help text for the user interface controlhelp help text for the user interface control

XForms also encourages intent-based authoring by introducing these
constructs:

group to group a set of user interface controlsswitch , and case which can be used to hide or
reveal logical groups of controls

case includes a Boolean attribute called selected
that allows the group of controls within that case to become active.
This is important to assistive technologies, such as a screen reader,
which would monitor the document to determine when to speak selected
elements. If none of the cases within the switch are selected, the
first case in document order becomes active by default. How those
elements are rendered visually is of no consequence. The semantics are
preserved.

The use of a standard data model reduces extensive author enablement
work in the area of adding accessibility properties to content. The
model, when bound to XForms elements, may be used by the user agent to
directly support the platform accessbility API as shown in this
abridged
table:

State

XForms today

User Agent Mapping (MSAA)

User Agent Mapping ATK (Gnome,KDE)

disabled

<select1>, <item>, <textarea>,
<secret>, <input>

STATE_SYSTEM_UNAVAILABLE

This is determined from relevant. If relevant is false this disabled
shall be mapped

ATK:ATK_STATE_DISABLED

focusable

<select1>, <item>, <textarea>,
<secret>, <input>, <choices>, <repeat>

STATE_SYSTEM_FOCUSABLE

This is determined from relevant. If relevant is false this disabled
shall be mapped

ATK:ATK_STATE_FOCUSABLE

invalid

<select1>, <item>, <textarea>,
<secret>, <input>

no mapping

ATK:ATK_STATE_INVALID

If the state is computed to be invalid, out-of-range, or required this
value should be returned as true. In the case of MSAA the user agent
should provide a specialized API to return its value. Alternatively, if
the user agent provides a specialized API for XForms it may provide
invalid(), outOfRange(), or empty() (returns true when required
but not available). This information is computed from the
instance data associated with the form element.

The user agent will need to set this to true when there is no binding
to data in a form element. Elements with this state should not be made
available to users.

ATK_STATE_VISIBLE : false if
hidden=true.
Otherwise false

The user agent will need to set this to true when there is no binding
to data in a form element. Elements with this state should not be made
available to users.

multiline

<textarea>

no mapping. This is implied based on the textarea being
representative of
it role.

ATK_STATE_MULTI_LINE

multiple

<select>, <repeat>

STATE_SYSTEM_EXTSELECTABLE

This attribute is implied based on the element type in XForms. It is up
to the User Agent to do the implied mapping to the appropriate state.

ATK_STATE_MULTISELECTABLE

This attribute is implied based on the element type in XForms. It is up
to the User Agent to do the implied mapping to the appropriate state.

optional

<select1>, <item>, <textarea>,
<secret>, <input>, <choices>

no mapping

This attributed is determined from from the XForms model. The XForms
implementation should provide a method either in the DOM or a
specialized API since this value should be calculated as optional may
be set to true or be evaluated based on an XPath. For example, a method
of isOptional() is suggested.

no mapping

This attributed is determined from from the XForms model. The XForms
implementation should provide a method either in the DOM or a
specialized API since this value should be calculated as optional may
be set to true or be evaluated based on an XPath. For example, a method
of isOptional() is suggested.

readonly

<select1>, <item>, <textarea>,
<secret>, <input>, <choices>

STATE_SYSTEM_READONLY

This attributed is determined from from the XForms model. The XForms
implementation should provide a method either in the DOM or a
specialized API since this value should be calculated as required may
be set to true or be evaluated based on
an XPath. In the case of Windows this would be computed and added to
the MSAA accessible states. In ATK
this would be computed and added to the AccessibleStateSet. On other
systems a method could be provided
such as isReadOnly().

ATK_STATE_READONLY=inverse of
readonly

This attributed is determined from from the XForms model. The XForms
implementation should provide a method either in the DOM or a
specialized API since this value should be calculated as required may
be set to true or be evaluated based on
an XPath. In the case of Windows this would be computed and added to
the MSAA accessible states. In ATK
this would be computed and added to the AccessibleStateSet. On other
systems a method could be provided
such as isReadOnly().

required

<select1>, <item>, <textarea>,
<secret>, <input>, <choices>

no mapping.

This attributed is determined from from the XForms model. The XForms
implementation should provide a method either in the DOM or a
specialized API since this value should be calculated as required may
be set to true or be evaluated based on an XPath. For example, a method
of isRequired() is suggested.

no mapping.

This attributed is determined from from the XForms model. The XForms
implementation should provide a method either in the DOM or a
specialized API since this value should be calculated as required may
be set to true or be evaluated based on an XPath. For example, a method
of isRequired() is suggested.

secret

<secret

STATE_SYSTEM_PROTECTED
ROLE_SYSTEM_TEXT

This is state is managed by the user agent. Use of secret as a tag
implies secret.

ATK_ROLE_PASSWORD_TEXT

This is state is managed by the user agent. Use of secret as a tag
implies secret.

selectable

<item>

STATE_SYSTEM_SELECTABLE

Note: <itemset> should be expanded by the user agent. An
attribute of selectable should automatically be set by the user agent
as long as it is bound.

ATK_STATE_SELECTABLE

Note: <itemset> should be expanded by the user agent. An
attribute of selectable should automatically be set by the user agent
as long as it is bound.

singleline

<input>

implied by <input> being representative of its
role.

ATK_STATE_SINGLE_LINE

This saves authoring time by levering the XForms model to support
accessibility directly. IBM is beginning development platform
accessibility support for XForms in 2005 as a contribution to the open
source community.

4.5.3 XHTML2

XHTML 2 is
being desiging to build accessibility in from the ground floor. It is
clear from the roadmap that some XHTML 2 accessibility features
are borrowed through the use of name spaces to extend XHTML 1.1 through
modularization. XHTML
2 incorporates the role attribute, document landmarks, XForms, XML
Events, and a number of other accessibility features. It introduces an
access element designed to address device independence, semantic
navigation, and activation. It also benefits from the WAI GUI Role
Taxonomy
which is a cross-cutting technology. The XHTML 2
specification is still in working draft form. A future list of the
extensive accessibility features of XHTML 2 will
be necessary.

4.6 User Agent Support

User agents are required to provide interoperable interfaces to
assistive
technology run times to produce a usable experience for users with a
specific
disability. A task of the roadmap will be to define requirements for
UAAG. This is necessary
provide a cohesion between user agent and author supplied state
information.

User agents may need to adjust their user interface in response to
state information stored in document elements. For example, an
element having the focusable attribute set to true should result in a
desktop user agent's placing the element in the keyboard tabbing order.

4.7 Assistive Technology Support

The WAI PF working group and IBM are working with assistive
technologies to ensure support of the roadmap.

4.8 Authoring Tool Support

The WAI PF working group will be looking at ways to address authoring
tools requirements for testing the accessibilitty of scripted web
content. The development of authoring tools to assist the author in
testing dynamic web content for accessibility is important. Today's
accessibility fixers and checkers test to static web content.
Accessibility properties will change during web page use. Web authoring
tools should consider reusable accessible widgets and prompt for
variable accessibility information such as title text. The use of RDF
in the WAI GUI Role Taxonomy should be used to ensure which properties
may be supported by which roles. W3C
Authoring Tools Accessibility Guidelines 2.0 is developing
requirements that will better address authors will creating accessible,
dynamic, scripted web content.

4.9 Developer Guidelines and
Implementations

At this time, IBM is doing much of the prototyping of this work. Sample
markup has been contributed by IBM and may be found on the Mozilla accessibility web
site. IBM is working on a best practices document and is
contributing to WCAG 2.0 implementation techniques. UB Access is
contributing much of the RDF design supporing the Role taxonomy work.
At this time these
guidelines are not yet made available.

4.10 Roadmap Deliverable Timeline

The following table is the technology deliverable Timeline for the
Dynamic Accessible Web Content Roadmap.

5.0 Conclusions

This roadmap is designed to address the accessibility of dynamic,
scripted, web content that may be rendered in today's browser while
bridging to future declarative standards, such as XHTML2, in the W3C.
The extensions being created for XHTML 1.X are intended to be
cross-cutting. This roadmap clearly indicates that WCAG, ATAG, and UAAG
should be in
lock step for a common strategy. All groups are impacted and are
interdependent. Additionally, close work with mainstream working
groups, like HTML, CSS, and Device Independence will not only produce a
working solution but it will produce a working solution that will have
a broader impact than just XHTML.

6.0 Appendix

6.1
W3C Deliverables: New Specifications to Fill the Gaps

The following table indicates the specifications to track which
address the gaps in the Roadmap.