2005 Conference Proceedings

Go to previous article 
Go to next article 
Return to 2005 Table of Contents 

DHTML Accessibility - Fixing the JavaScript Accessibility Problem

Rich Schwerdtfeger, Senior Technical Staff Member Architect
IBM Software Group Accessibility Architect and Strategist
Member W3C WAI PF and HTML Working Groups
Email: schwer@us.ibm.com
11501 Burnet Road
Austin, TX 78758

Becky Gibson, Senior Software Engineer
IBM Software Group Web Tooling and Component Accessibility Architect
Member W3C WAI WCAG Working Group
Email: gibsonb@us.ibm.com
5 Technology Park Dr.
Westford, MA 01886


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 

Accessibility APIs for GUI frameworks define a standard contract between an application component and an assistive technology (AT). A component could be a button, list box, or any other desktop component. In this example we use the Java Accessibility API but we could use the Accessibility Toolkit (ATK) for Gnome or Microsoft Active Accessibility (MSAA) for Windows. Figure 1.0 demonstrates core Java Accessibility API applied to a component. It shows the standard accessibility API or "contract" applied to a Java Foundation Class component. The figure shows an assistive technology communicating with the component through the accessibility API. This design follows a model-view-controller architecture. The component is the controller and the UI represents the View. (Note: for this discussion, object and component are used interchangeably). The accessibility API is dependent on the data rather than how it is rendered in the View. Changes in accessibility data results in events generated by the supported "contract." This design reduces the burden on the AT in that the AT is allowed to be notified of changes rather than having to poll for them.

The information provided by this API are as follows:

 Implementation of the API is dependent on the data housed in the component as shown in Figure 1.0.

 Accessible Component

Figure 1.0 illustrates a typical JFC Component and its Model View Controller architecture. It's accessibility interface is applied to the component but dependent on the component's data. The standard Accessibility API contract represents this interface and acts as the adapter between the assistive technology and the the JFC component. The accessibility interface provides role, state, caret, selection, event notification, parent/child information, relationship, and descriptions.

Accessible Application
Figure 2.0 Expanding the accessibility model to the application. Here, the assistive technology monitors user focus changes and uses this information to then walk the application tree structure and attach itself to the accessibility API for each component. This list of referenced accessible components creates an accessible dynamic view of the application.  This view may be rendered by the assistive technology in an alternative modality such as speech and additional key navigation controls in the case of a screen reader.

Analyzing the Problem

Accessibility for traditional HTML suffers from a number of problems that make it difficult to support dynamic content. When accessibility standards were proposed for HTML in the late 1999, see Web Content Accessibility Guidelines 1.0 very little JavaScript was being used on the Internet. Browsers like Links could be used to access most Web content. These early guidelines addressed the small JavaScript issue by requiring authors to produce content which would be accessible when scripting was turned off (See section 6.3 of these guidelines). Later on, scripting languages like JavaScript were used to create rich web applications which closely model a GUI in appearance. The common response to this problem was that JavaScript was not accessible. In actual fact, the problem is that HTML and other script did not provide an infrastructure what would allow a author to produce accessible dynamic content. If the proper accessibility standards could be applied by authors, the user agent could then map that accessibility "data" to the accessibility API on the platform and produce an accessible dynamic web application.

Solving this problem requires analysis of the fundamental components and filling in the gaps in the standards to allow a user agent to map the accessibility information to the platform APIs and allow the author to provide an accessible solution.

As a result, the accessibility guidelines did not address the issues of dynamic web content. Furthermore, dynamic accessibility API issues like state data were not addressed by these guidelines. Analyzing the problem requires us to look at the semantics of what is provided in legacy HTML.

DOM Node Analysis

User agents parse HTML into a Document Object Model (DOM). The DOM is a document tree structure with an API to modify, access, and monitor the document. The DOM represents the data model in traditional HTML and should be the location where most accessibility information is stored.

Accessibility is dependent on abstracting semantics from both content and presentation information. Extracting semantics from today's HTML content is problematic. Today, semantics are limited to the tag element names. This leads to the second problem where content authors use these same tag elements for the purpose of formatting content. Currently, semantic information is dependent upon the tag element name.  Additional semantic information may be  introduced on the element - such as when tables are used to format how content is rendered within the user agent. The third is HTML's inability to map to 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 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

Accessible Element with JavaScript Controller

Figure 3.0 illustrates a typical DOM node from a model-view-controller perspective. On the DOM node, data which should include semantic meta data, is separated from presentation. An ellipse is drawn around the document element and its data (the model) and presentation pieces (the view). This ellipse represents what is controlled by JavaScript. JavaScript acts as the controller. JavaScript manipulates the data and content as well as the style. Style is manipulated through the use of style sheets. The JavaScript controller is event driven. Upon event notification, such as a mouse or keyboard event, it will modify the data and style of the document to produce custom widgets not generally found on a web page. Examples are trees, menus, and spreadsheets. Placed between the DOM node and the assistive technology in figure 3.0, 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 of many of our accessible GUI platforms: role, state, caret, selection, event notification, parent/child information, relationship, and descriptions. Today, there are considerable standard gaps in the required information needed by assistive technologies.

Outside of the semantics and interoperability problem, the next major problem is providing focus.

The Focus Problem

The ability to provide focus is an essential requirement for applications. Assistive technology needs to be able to track where the user is navigating within a document or application. Within an application this is typically the keyboard focus. Within a web page this is also called the point-of-regard. The specification for the W3C Document Object Model (DOM) provides for a focus() function but it is limited to anchor tags and form elements . This is problematic for script developers in that they want to be able to set focus to any element on the page and in particular for DIVs.

A Look at Device Independence

Device independence is not adequately addressed in HTML. Going forward XML Events and XHTML 2 will be introducing device independent event access whereby authors who create event handlers shall be able to provide descriptions as to the handlers purpose and make use of DOMActivate which is device neutral.

GAP analysis

Figure 4.0 compares the required components and features to develop an accessible GUI application with what is available in HTML today.

Required Components What's available today?
Ability to set the focus with Script
 Limited to Form elements and anchors
Event: Notification
Activation, Caret Change, Selection, Mutation
 User Agent (browser)
Other Event Notification - Accessibility API
State, Value Change Limited to Forms
Enumerate and Control Actions
Limited to tag device dependent functionality (onmouseover,etc.)
State Information: Limited to Form elements
Role Information: Limited to standard HTML tag names. (Mix Content/presentation)
Relationships: Parent/child Limited DOM (affected by style) (Mix Content/presentation)
Relationships: (Label, Group, ControllerFor) Limited to HTML (Title, alt, label)
Content selection User Agent
Text, Font/Font Style Information Core DOM/ User Agent
Description/Help HTML 4.0 - Alt Text, title text
Respond Desktop Font/Color Changes partial (conflicts with CSS and JavaScript)
Keyboard Navigation/Access (UAAG Compliant) User Agents, Access Keys (HTML)
Accessibility API Mapping Dependent on available information

Figure 4.0 Gap Analysis of HTML support for DHTML

Filling the Gaps using today's XHTML and HTML

Solving the problem requires a solution that can be applied to today's content while preparing for tomorrow. Additionally, we needed to provide the author or industry the tools to define interoperability.

Manipulating the focus

HTML page authors use the Document Object Model (DOM) API to manipulate the document structure, content, and focus of an HTML document. You can think of the DOM as a tree structure representation of a parsed HTML document. JavaScript uses the focus() method as defined by the HTML DOM specification. Unfortunately, this method is limited to anchor tags and form elements. JavaScript authors use <DIV>s, <SPAN>s, <TABLE>s, and other elements to represent other GUI objects such as menus, spread sheets, and expandable/collapsible trees.

Here's a real example: Most DHTML menus don't act like regular menus with respect to keyboard access. If you can use the keyboard to get to the menu at all, a common mistake is to put each menu item in the tab order (often accomplished by making each menu item an <a>). In fact, the correct behavior for menus is that the entire menu should be in the tab order once, and arrow key navigation should be supported. This also true for other "grouped navigation" widgets such as tree views, grids and tab panels.

Despite this limitation, Internet Explorer, filled a hole in the HTML specification which allows elements with a tabindex < 0 to receive focus without being entered in the tab order. We now treat this as a best practice and it has also been implemented in Firefox and Mozilla. So, it's now possible for HTML authors to do the right thing with respect to keyboard navigation.

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)

Figure 5.0: Best use of TABINDEX to provide 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

XHTML 2 is taking a major step forward in introducing a role meta attribute for document elements. This attribute allows the page author to tell the user agent and assistive technology what the role is. XHTML 2 is also defining standard roles which can be used to define standard sections of a document;  main content, header, footer, banner, search section, navigation section and other content information. Providing this in a standard form allows the user agent to map standard key sequences to access these document components on any page. The role attribute is designed to be a qname. In XHTML, qnames are a combination of a namespace and a name or id in the space. The WAI is creating a taxonomy for common GUI widgets which will map to standard roles for the common GUI platforms such as for MSAA (Windows) and ATK (Gnome/KDE). Each role attribute will map to XML markup, written in Resource Descriptor Framework (RDF), to define how common attributes may be mapped by the user agent for accessibility. The collection of roles will form a taxonomy for the GUI and will form the basis to extend to other taxonomies. In short this design provides:

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:wairoles= "http://www.w3.org/2005/01/wai-rdf/GUIAccessTaxonomy#"
<link rel="x2:navigation" id="#div1"></link>
<table border=2>
<div id= "div1" tabindex=-1 x2:role="wairoles:menu">
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 a Resource Description Framework (RDF) resource for each role. In our case these resources represent standard roles found in a GUI, most of which map to standard platform accessible roles for MSAA and the Gnome ATK. Each resource is part of a collection which forms the GUI Role taxonomy.

WAI GUI Role Taxonomy

The WAI GUI Role taxonomy defines a class hierarchy representing standard standard roles found in a Graphical User Interface. Each role in this taxonomy defines the design pattern for it to tell the user agent, such as Firefox or IE, what state attributes may be provided for that role or possibly what roles it is similar to. This information allows assistive technologies to better process custom roles as they will understand what standard role it may be similar to. We will not discuss RDF as it is beyond the scope of this presentation.

Flash Market Track NYSE
Figure 6.0 shows a 3D Market chart in Flash. At the upper left is a diagram showing a list of symbols for which there is a symbol widget. represented in the RDF diagram. It contains the number of shares and the percent of change. The rest of this image is simply different views of the same information. One is a table view and another is an activity map of the same information based on the floor of the exchange. We believe the same standards for the Web could ultimately be applied to other non-W3C content and therefore this was used as an example. Additionally, at the bottom, there are graphs for advances, declines, active stocks, and activity in the Dow Jones Industrial Average.

Sample Role taxonomy for Market Track

Figure 7.0 shows a basic RDF mapping which defines a set of terms and relationships defining an object. At the center is a Widget object which isSimilarTo a Navigation List  which cancontain a Navigation Item.  The widget has an author, description; and a title based on Dublin Core meta data. These are johns@nyse.com, "Cool Market Track", and Market Track respectively. The widget hasStates active and visible. This widget represents the symbol shown in Figure 6.0. The Widget contains Stockinfo which contains a symbol, a price, and %change.  The terms cancontain, isSimilarTo, contains, etc. are terms which we will need to define for the schema. If properly defined we should be able to define each of the standard roles and how they work. Additionally, any new roles should be definable from the final RDF Schema.

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.

Introducing state Attributes - The WAI State Taxonomy

The next major gap which must be filled is the provision for state attributes. By, their nature the GUI objects which form a dynamic user interface maintain state. What is missing is a standard way for a page author to provide state information for these objects which can be mapped to the standard accessible state information on the platform. For example, if you had a checkbox you would like to know if it is in a "checked" state.

Below a checkbox has been implemented using a <span> element.  It has been assigned a role of "wai:checkbox" and an initial state of waistate:checked = true;  Both onkeydown and onclick event handlers are provided to support both keyboard and mouse.
<html lang="en" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml"

<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
The JavaScript function below shows how the state of the checkbox is accessed using the getAttributeNS() DOM api.  Note that this code is a Mozilla/Firefox only example.
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
Finally the checkbox is styled based on the value of the waistate:checked state:
<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')

Keyboard Accessibility - Making HTML act like a GUI

With the ability to set focus on any element via the tabindex attribute, JavaScript authors can now create components that are fully keyboard accessible.   This is a bit of a paradigm shift for web components.  Previously each item on the page that needed focus was implemented as an HTML form element or link. This would put the item in the tab order and allow keyboard access to it.  Unfortunately. this required a keyboard user to have to tab repeatedly to reach elements in the lower parts of a page or application. Navigation was tedious and time consuming.   In this new model, each widget can be put into the tab order and arrow keys can be used to navigate within the component.  

Generally, the parent element of the widget is set to receive a default keyboard focus by assigning it a tabindex="0".   This puts the element in the default tab order and allows the keyboard user to initially gain focus to the component.  Each individual element of the component is assigned a tabindex < 0 so focus can be programmatically set to it.  Navigation to each item in the component is via the arrow keys.  For example, in a spreadsheet component implemented via an HTML table, the <table> element has tabindex="0" and each individual <td> element has tabindex="-1".  A cell receives focus when the user navigates to it using the arrow keys.  Arrow key support is achieved by handling the onkeydown event.  The onkeydown event for navigation is generally  handled by one of the parent elements. The arrow keys can be trapped by the overall component and the enter or "activation" key is handled by each individual piece of the component.  Using the spreadsheet as an example, the arrow key navigation is handled via an onkeydown handler associated with the <table> element.   Any action to be performed on an individual cell is handled via an onkeydown and onclick handler associated with the cell.  

When trapping key events, it is important to prevent the browser from executing the default behavior of  the keystroke. The common browser action resulting from a down arrow press is to scroll the document..  If the JavaScript author wishes to trap that arrow key and use it to change focus to a different spreadsheet cell, the default scrolling behavior needs to be prevented. This is done by setting the return value of the event.   Return false if the default propagation of the event should be prevented.  Return true to allow the browser to process the key as normal.   The code snippet below adds on onkeydown handler to a spreadsheet table element.  

<table border="2" cellspacing="0" tabindex="0" id="gridEx" x2:role="wairole:spreadsheet" onkeydown=" return doNavigation(event);"  >

This Javascript shows the code for processing arrow keys.

<script type="text/javascript">
var KEY_UP = 38;
var KEY_DOWN = 40;
var KEY_LEFT = 37;
var KEY_RIGHT = 39;
var gFocusItem = null;  // object to set programmatic focus to

function doNavigation(event) {
    var bEventContinue = true;  // browser can still use event
    var key = event.keyCode;
    if ((key >=KEY_LEFT && key <= KEY_DOWN) ) {
        // was an arrow key - handle
       // find the next cell to receive focus
       gFocusItem = nextCell;
       // set focus to it
        bEventContinue = false;  // event has been handled, prevent further propagation
    return bEventContinue;

Each individual item in a component may need handlers for both mouse and keyboard events.  In a spreadsheet component a cell has onclick, ondblclick, and onkeydown handlers to process focus and the editing action for the cell.  The user edits a cell by navigating to it and pressing enter or double clicking.  The onclick handler for the cell is used to set focus to it via the mouse. 

<td tabindex="-1"   x2:role="wairole:gridcell"  onclick="doClick(event,5,3);" ondblclick="doEdit(this);" onkeydown="if (event.keyCode == 13) { doEdit(this);return false;}"  >$6.50</td>

In addition to arrow key navigation, the user may also use the mouse to interact with a component.  In a spreadsheet component the user can set focus to a cell by navigating to it using the arrow keys.  As each cell receives focus the style is changed to display that focus to the user. The user can also set focus to a cell by single clicking on it.  In a multi-select component, individual items may be selected but may not necessarily receive focus.   In order to have the keyboard and mouse navigation work together, the author should store the focus and select information for the component - its point of regard. This can be done using a globally scoped variable or a JavaScript object.   The spreadsheet example uses global Array variables to store the current row and column numbers of the currently selected cell.  Each Array variable is indexed by the id of the parent <table> element - this allows more than one spreadsheet component on the same page.

// global vars for storing selection and focus information; indexed by the id of the parent table element
var gCurrentRow = new Array();
var gCurrentCol = new Array();
var gCurrentSelected = new Array();
var gCurrentCell = new Array();

gCurrentRow ["sheet1"] = -1;   // 0 based row number
gCurrentCol["sheet1"] = 0;    // 0 based column number
gCurrentSelected ["sheet1"]=null;  // currently selected row object
gCurrentCell["sheet1"] =null; // currently selected cell object

        function someFunction(event) {
             var bEventContinue = true;
               var srcElem = getParentTable(event);     // local function to determine parent table element from event info
               var srcId = srcElem.getAttribute("id");
               var rowNum = 0;
               // store current row number
             gCurrentRow[srcId] = rowNum;   
             return bEventContinue;

Keyboard and mouse navigation can be achieved via the proper use of onclick, ondblclick and onkeydown event handlers on appropriate elements.   The navigation mechanisms can co-exist by keeping track of and storing focus and selection information.

Implementation Details

Assistive Technology Support and User Agents Support

Currently, IBM is working with the W3C and the Mozilla foundation to add  DHTML accessibility extensions to Firefox. The extensions are centered around generating the appropriate state change events from the DOM and supporting the standard accessibility infrastructure on Windows and Gnome desktops. The roadmap and plans are being shared with AT vendors such as Freedom Scientific, GW Micro, AI Squared, and Dolphin. GW Micro is the first to be adding support for Firefox.

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

New accessibility features in in XHTML2 will vastly improve accessibility for XHTML content.

Access - Access key replacement (descriptions, device independence)

Standard roles for document landmarks

The provision for common landmarks allows the author to easily specify them to the user agent or assistive technology. With this knowledge, either technology can provide the author with a common landmark navigation mechanism on any supported site.

List of standard roles
This defines the main content of a document.
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.
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.
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.
This is information about the content on the page. For example, footnotes, copyrights, links to privacy statements, etc. would belong here.
The content is parenthetic or ancillary to the main content of the resource.
Indicates that the element contains content that is related to the main content of the page.
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

XForms is a forms processing model whose design was based on common use cases for forms. It is based on a model-view-controller architecture. This design allows the user agent to grab  most accessibiltiy state information from the data model just like many GUIs.

Event Model Accessibility Features

Declarative, "built in," events define what can be done with forms - rather than guessing what the associated JavaScript implements.

Interaction events (includes state changes) include: Notification Events
Event sequencing for form controls is also added so that you don't have to guess. Additionally, this event model allows for device independence. XForms makes use of XML events which will allow the author to say what the event does in a future version of XML events. This will allow the author to provide an event description vs. having to tell the user that the function is an HTML  event like "ON_MOUSECLICK."

Use of a Model-View-Controller design:

This allows separation of content and presentation and allows access to a standard data model for different modalities. It also allows direct access to accessibility state meta data.

Additional accessibility features of XForms

XForms has additional accessibility features built in which map to our model view controller architecture as described earlier. These are

About this session 

The audience will gain an understanding of:

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.

Reprinted with author(s) permission. Author(s) retain copyright.