Matt May, W3C
Much of today's Web is not in document form, but in the document-software half-state we call Web applications. Using HTML, script and style, most designers have stretched the boundaries of browsers and languages to create fascinatingly complex interfaces, which unfortunately have left most users with disabilities behind completely.
The Protocols and Formats Working Group has tracked accessibility issues with Web technologies since 1997, and offers a brief history of the Web, and some proposals for increasing overall Web application and format accessibility.
The PFWG reviews W3C specifications for accessibility issues and proposes solutions based on such factors as device-independent interaction, functionality, authorability, and interoperability with assistive technologies such as screen magnifiers, screen readers, and on-screen keyboards. The Working Group has also written numerous Working Group Notes, including the XML Accessibility Guidelines, which specify best practices in creating XML-based languages that interface directly with the user.
The Web application was borne of a series of innovations of browsers and ad-hoc additions to the HTML language. Netscape 1.1 added the TABLE element, later added to the HTML 2.0 specification. Netscape 2.0 introduced both frames, added in HTML 4.0, and JavaScript, which for the first time allowed client-side forms validation, and later meant the death of us all.
CSS, introduced in Internet Explorer 3 and refined over the next seven years, allowed pixel-level control over the display, causing unreadable documents to become the norm, and further blurring the line between Web page and application.
Each of these enhancements was used to push the model of a Web-based, native-looking user interface to sometimes absurd extents. Despite lacking any real hooks into the client's user interface preferences, Web developers (including this author) dutifully made interfaces that looked an awful lot like Windows. Which was great, unless you liked the interface to actually feel like Windows, or if you were on another operating system.
The many generations of semantic obliteration of HTML was a red flag that developers wanted a user interface language, a layout language with the forms-and-HTTP model of the Web. And they're not alone: developers of assistive technology are at a complete loss from page to page on the Web in determining just how a given developer broke HTML this time. The result is an inconsistent and commonly low-fidelity representation of Web documents, utterly lacking in the very semantic value that HTML was designed to represent. While the world is graduating to CSS-based, semantic design, we find a graveyard of nested layout tables, FONT tags, frames, HTML generated by script, and other undesirable content giving assistive technology users and developers fits.
The needs of accessibility has guidance for Web applications in several departments. Web applications -- and the languages used to create them -- should learn the lessons of current practice and adapt for the benefit of both authors and users. We present a few signposts on the way there:
Languages should use declarative syntax for user interface where possible.
Scripting languages, if used, should have event models that are congruent with device independence. Failure to answer the device independence question has real consequences for accessibility, as we've seen with, for example, onmouseover and onmouseclick in JavaScript. The problem is so prevalent that the User Agent Accessibility Guidelines 1.0 indicated that Web browsers should reattach these mouse events to keyboard events to cover for the millions of implementations of device-specific script on the Web. The DOM 2 HTML spec later added device-independent events, but the activate event still lacks enough support to supplant mouse events.
The moral here is to ensure that the user's intent, and not her hardware, is taken into account when creating an event model. The mouse-click and key-press events should inherit from a common activation event, and developers should be instructed to use that activation event except where such usage is clearly illogical.
The presence of standardized namespaces is a basic requirement for assistive technology. Without an understanding of the semantics of a given language and its context within a document, assistive technology cannot determine an appropriate rendering for a user.
In the realm of document types that present information or interface to the user, the fewer different interoperating specifications, the better. Presently, three incompatible forms specs (Adobe eForms, Microsoft's Infopath, W3C's XForms) are out in public view, yet none are supported by assistive technology, and may not gain support until AT vendors are funded to do so, or one dominant format emerges. A solid, well-researched and well-documented method for presenting user interfaces around various datasets is a far better approach for accessibility than a mishmash of arbitrary XML data wrapped with CSS and/or XSLT.
An event model for Web applications must have clear guidance in terms of device-independent
input. Mouse-specific events should have keyboard analogues, or better, mouse
and keyboard events should derive from a single device-independent event, like
DOMActivate.
Likewise, consideration must be given to device-independent output. The desktop
of a computer is not visualized by a screen-reader user. Therefore, the interaction
mode of this user should be taken into consideration. Graphs or data structures
that are presented visually need to be maintained in the data model for non-visual
presentation, or for rendering in a manner that suits the user's needs (for
example, users with red-green colorblindness). The user's ultimate control over
style, as established in CSS2, must continue to be respected.
Plugins are only made accessible to assistive technology on a piecemeal basis. This is as a result of the numerous incompatible and incomplete plugin APIs in use across platforms. ATs must work with individual plugin developers on only the most popular platforms, in a time-consuming and expensive process.
In the case of Macromedia Flash, this happened only recently, with Flash Player 6, some five years after its appearance on the market. Even then, support was added for only one screen reader, Window-Eyes, with the more popular JAWS added in a later version. And these screen readers had mutually incompatible implementations, and bugs including the inability to escape from a Flash movie once one has been entered, causing users to be stuck within their browser.
A component extension API is a major step forward from the perspective of accessibility. The requirements for such an API were assembled in 2001, but plugin vendors and the makers of plugin hosts have been slow to adopt this work. This is a priority for better access to Web content such as what is currently available.
A new task force within the PFWG has begun work on a roadmap for "dynamic HTML" to satisfy accessibility requirements. Among the roadmap's requirements is that the solution leverage recent W3C specifications, allow separation of content presentation, scale up to complex interface designs, and support internationalization needs. The task force is trying to involve user agent developers in the earliest stages of the process, and propose guidelines on implementing DOM 3 Events, XForms and XHTML 2.0 in a way that most directly benefits assistive technologies. From this work, the PFWG hopes to guide future Web browser and application development with W3C technologies.
There are other projects underway to present user interfaces, including Mozilla's XUL, Microsoft's XAML, and Macromedia's MXML language. While the approach is fundamentally different, the needs and success criteria from an accessibility standpoint are the same, and we encourage the authors of these languages to work on accessibility as early and as thoroughly as possible, keeping in mind the lessons presented here.