Copyright © 2000 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This document lists some of the hurdles that the User Agent Accessibility Guidelines Working Group (UAWG) encountered while developing the "User Agent Accessibility Guidelines 1.0". It is hoped that this document (and revisions) will facilitate future efforts by the UAWG and also the Web Accessibility Initiative (WAI) as a whole in the development of accessibility guidelines for the Web.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.
This is the first draft of this document. This is not currently a work item of the User Agent Accessibility Guidelines Working Group and is neither endorsed by that Working Group or by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than "work in progress."
UAWG participants who wish to comment on this document are invited to send comments to the UAWG mailing list, w3c-wai-ua@w3.org (archives).
This document is part of a series of accessibility documents published by the Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C). WAI Accessibility Guidelines are produced as part of the WAI Technical Activity. The goals of the User Agent Accessibility Guidelines Working Group are described in the charter.
A list of current W3C Recommendations and other technical documents can be found at the W3C Web site.
This document lists some of the hurdles that the User Agent Accessibility Guidelines Working Group (UAWG) encountered while developing the "User Agent Accessibility Guidelines 1.0". This document includes a little bit of "history" (in the form of references to particular emails or discussion threads), but is largely constructed from memory and notes. Most of these topics appear on the issues list at least once, and so it is possible to trace discussions there. Refer also to the history of changes to the document to find out when these issues affected the document.
Conformance, and issues related to conformance, has arguably been the most difficult issue the Working Group has had to address.
"What is a user agent?" is a question that has lurked behind many of the issues that this WG has faced. In the end, the WG decided not to try to answer that question formally, though loosely, a user agent is defined as software that retrieves and renders Web content for users.
Instead, the question was narrowed to "For what type of conforming user agent should we design this document?" The WG underwent a slow process of narrowing the scope of this document from all user agents to focusing on mainstream graphical user agents and multimedia players. At first, the WG tried to design a document that would allow any type of user agent to conform, although some of the requirements clearly did not "apply" to those user agents. For requirements that the user be able to reconfigure the graphical user interface of the user agent did not seem to apply to some speech synthesizers whose intended audience did not require that functionality.
In order to allow more user agents to conform, the document initially included a number of "applicability provisions" that enabled exemptions in order to conform. Including specific provisions was considered an improvement over the option of stating very generally that "a user agent doesn't need to satisfy a checkpoint if it doesn't make sense for that user agent". However, it became apparent that too much flexibility in applicability has several disadvantages:
As the document matured, the WG accepted to reduce the scope of the document and narrow its focus to mainstream user agents with graphical capabilities. In doing so, the WG was able to reduce the number of applicability provisions, which had the effect of tightening the document by removing some areas where readers would have to interpret the document (refer to points of interpretability).
The 23 October 2000 last call draft still includes some applicability provisions, notably allowing variance in support for different content types. However, the document's conformance mechanism now makes clear which requirements must be met as soon as a user agent claims to support a particular content type.
For background on discussions of applicability, please refer to:
Another aspect of determining the scope of the document involved assigning responsibilities for meeting user needs. It is possible to assign responsibility for meeting user agents to at least the following parties:
For the UAWG, it was most difficult to decide when to include a requirement as part of conformance or when to assume/decide that it would best be met by, or should best be met by, an assistive technology. In particular, the topic of which entity was responsible for providing access to tables took up a substantial amount of WG energy.
A number of factors influenced the WG's decisions to include a requirement in the document (for a conforming user agent) or not, including:
The UAAG 1.0 includes requirements that a conforming user agent make available content through the W3C DOM and user interface data through other APIs. Once these requirements were firmly established, it became easier to say (for better or for worse) "Assistive technologies can and should do that, since they have access to the DOM". Note: Assistive technologies can construct a document view by scraping information from the rendering of another user agent (the "offscreen model"). The UAAG 1.0 discourages this approach and promotes instead communication through the W3C DOM. While discouraged, the offscreen model approach is still made possible because of requirements that conforming user agents not bypass standard APIs (e.g., those used for drawing text on the screen).
I don't think that the UAWG has established a clear and definitive set of criteria for determining whether a requirement should appear in the document. This is an area where the WG should invest energy before producing the next version of the guidelines.
Some functionalities that are out of scope in UAAG 1.0 include: braille rendering, table navigation, and voice input (except where covered by standard input APIs and configurability). Synthesized speech output is covered a little bit, but coordination with the Voice Browser WG is expected for future work on speech and voice.
For background on discussions of user agent responsibilities, please refer to:
Another aspect of scope that has been discussed by the WG involves conformance claims about "composite" user agents, i.e., more than one piece of software that together meet the requirements of the document. Allowing conformance by software used in tandem in part acknowledges the difficulty we have in defining exactly what a user agent is. For instance, one developer suggested that users would benefit from being able to download modules from the Web that would provide additional features that benefit accessibility, and that the user agent should be considered to conform when used with those modules. Discussion about this topic relieved some pressure from the "native implementation" discussion since there is no longer a notion of "native" in the document -- there is only a conformance claim about a set of software, and those components, as a whole, must meet all of the requirements of the document.
However, this direction for the document does not eliminate the "scope" issue since a conforming user agent is not required to meet the needs of all users (e.g., a conforming user agent is not required to render content as braille).
Also, the question of conformance for components used in tandem put more pressure on the issue of an accessible installation. It is important for users with disabilities to be able to install software, and the installation procedure must be accessible. The document does not currently include a checkpoint requiring an accessible installation (due, in large part, to the fact that an accessible installation involves almost all of the other requirements of the document, and would be largely redundant). This may be an area for future work.
UAAG 1.0 adopts the general conformance scheme of the WCAG 1.0 and ATAG 1.0 documents that preceded it. There have been comments in all three WAI WGs (refer specifically to UA Proposed Recommendation issue 252) that the conformance mechanism (Level A, Double-A, Triple-A) doesn't allow enough granularity for claims. In response to this:
This is an issue that is likely to require re-examination, if only to reconfirm to the next WG that too much granularity will make the guidelines difficult to interpret.
The concept of "recognize" is important to conformance. A (conforming) user agent is not required to make guesses or fulfill requirements outside of what it can "recognize" definitively. For instance, if link text reads "I open a viewport", the user agent is not required to "know" that following this link will open a new viewport, since the author has not used well-known markup to express that behavior. The user agent is only required to fulfill requirements when it can recognize properties, behavior, etc. This is particularly relevant to the realm of scripts, for user agents cannot always tell what the purpose of a script it.
The WCAG WG faced a significant challenge when designing WCAG 1.0 (and still does today): how to design guidelines that help authors today and also promote "the right way" to author content? The UAAG 1.0 faces this problem to a lesser extent since it is explaining to developers how to build more accessible software (than is available today). The document's emphasis is more about the future (and, in a sense, the ideal world) than about current technology.
Manifestations of the emphasis on the future/ideal Web:
Manifestations of the emphasis on the present Web:
The conformance provisions refer to the "subject" of a conformance claim, which will usually be more than one software component such as a browser in conjunction with a media player. The "subject" of the claim is in fact the "user agent" that is the focus of each checkpoint. The document states that when you make a conformance claim, the subject of the claim must satisfy all of the applicable checkpoints, or applicable portions thereof.
To the extent possible, the document attempts to eliminate points of interpretability from the document. For instance, instead of requiring readers to identify which checkpoints must be satisfied if they implement video, we encode the definitive list in the document. In general the WG tried to offer a "menu" of options to limit the reader's interpretative effort and to reduce the risk of misunderstanding or non-interoperability.
Some attempts to limit points of interpretability failed. For instance, the WG attempted to identify, for HTML and other markup languages from W3C, definitive lists of "important elements" for the purposes of navigation. In the end, for the particular question of navigation, the WG did not find the discrete set solution satisfactory, and so the document leaves somewhat open the question of what "important elements" are for HTML, etc.
Here is a list of checkpoints where some interpretation is required (e.g., because of dependencies outside of UAAG 1.0):
These checkpoints may make it difficult to determine conformance because of dependencies on conformance to other specifications, to system conventions, to vendor-supplied information about implementation of APIs, etc.
Based on comments from the Proposed Recommendation review, the WG (from April 2000 to 23 October 2000) reviewed all of the requirements of the document, identified minimal requirements to the extent it could, and reduced each checkpoint to an expression of "minimal" requirements (based on a suggestion from Eric Hansen).
The document "Determining Conformance to UAAG 1.0" was used to organize and track discussions about minimal requirements for each checkpoint of the Proposed Recommendation. That document proposed a rough "framework" for considering minimal requirements. For instance, in some cases, it was possible to establish a "logical" minimum for a requirement.
The most difficult cases for determining minimal requirements involved choosing a range of values for a requirement. At times, the range was identified based on current practice or available technology. At others, it was chosen "arbitrarily" by the Working Group based on user needs and other factors.
The 23 October 2000 last call draft includes the concept of "reference disability group" in the definition of "text element". The assumption is that a text element (as it is defined in the document) is potentially understandable to three reference disability groups, as long as some conditions are met (availability of hardware, etc.).
The WG should document more explicitly the assumptions that have an impact on conformance criteria. As a starting point, refer to Eric Hansen's emails on this topic ( Hansen from 8 October and correction).
Much of the "native" accessibility of the user agent involves control that the user can exercise over rendering, behavior, and configurability.
In the context of this document, both the terms "control" and "configure" share in common the idea of governance such as a user may exercise over interface layout, user agent behavior, rendering style, and other parameters required by this document. "Configure" carries the sense of persistent changes across different browsing sessions. A "profile" is a portable representation of configuration preferences. Control carries the sense of "interactive".
Granularity of control and configuration was also discussed. An example of global control: increase the font size of all text in the current page. An example of global configuration: set the font size used to render reference (e.g., paragraph) text by default. An example of local control: zoom the text of a selected element. An example of local configuration: use of user style sheets to set the text size of all H1 headings to a certain size.
There are at least three possible "levels" at which the user may want to configure or control rendering:
In Guideline 3, UAAG 1.0 focuses on global level configuration and element level control. For instance, one checkpoint requires the user to be able to configure the user agent so that for all documents, images are not rendered and instead a placeholder is rendered. Then, the user can request that a particular image be rendered (this is element level control). Guideline 3 is also about preventing rendering that may interfere with accessibility.
In Guideline 4., UAAG 1.0 focuses on:
Guideline 4 is also about control of rendering that may be necessary for accessibility.
There was a recurring idea that some users with disabilities (e.g., with a physical disability, or blind) may be disoriented by changes to content or the user interface and therefore must be able to stop automatic changes and effectuate them manually. Some instances in the document included: manual form submission (e.g., when forms would otherwise be submitted automatically by scripts), manual updates to pages (due to client-side initiated refreshes), suppression of automatic rendering of audio or video content on load (which may interfere with speech synthesizers or be otherwise distracting), and automatic changes to focus (e.g., when a new viewport opens).
The UAAG 1.0 does not require much in the way of alerts to the user. The term "alert" means that user input is not required to acknowledge reception of the information (as opposed to "prompt"). Alerts must be accessible (e.g., have a text equivalent in the user interface).
Alerts to the user are primarily required in conjunction with configuration. When the user agent has been configured to suppress certain behavior (e.g., to not render a background image), the user agent should alert the user to the fact that the content is available, but has not been rendered. This applies to other situations as well (e.g., the user has configured the user agent to allow manual updates to an otherwise automatically updating page. The user agent should alert the user to the fact that new content is available, and the user agent is awaiting manual update).
Alerts to changes in content and user interface states are also required through an API so that assistive technologies have access to them.
A lot of WG energy has gone into discussing the definition of "content". (In fact, it makes sense that following terms undergo significant scrutiny within WAI: author, authoring tool, content, user agent, accessibility, and guideline).
Following are just some of the issues that have arisen around the definition of content:
The UAAG 1.0 uses the term "content" to mean the document object, which is prior to rendering. For instance, text content is a sequence of characters. The document refers to "rendered content" to mean the part of content that is available through a viewport.
The distinction between pre- and post-rendering is important and is an integral part of the definition of "text element" and "text equivalent". The concept is important because the author is required to provide content that when rendered has the potential of being accessible to users with disabilities. That this content's input format is text-based is incidental. For instance, SVG is a markup language for creating images. The fact that the input format is composed of text characters does not mean that an SVG is a text element since it may not convey the same information to a user who is blind as to a user who can use the image. Note: Authors should describe SVG images as part of making them accessible.
The UAAG 1.0 does not distinguish between "primary" and "alternative" content in the following sense: that "primary" content is intended by authors for users without a disability and "alternative" is intended by authors for users with a disability. Though authors may in fact intend some content for users with a disability, UAAG 1.0 makes no correlation between the author's intent and the potential for content to be accessible.
In October 2000, there were a number of discussions about whether the term "equivalent" as defined in UAAG 1.0 was sufficient to capture some of the requirements of the document. In the 23 October 2000 last call draft, the definition of "equivalency" includes some accessibility implications w.r.t. the user. The WG is contemplating using another term (e.g., "alternative") that refers to the author's intent. Refer to the proposal to include and define alternative and for differences in meaning between "equivalent" and "alternative". Refer to other threads on equivalency: initial thread from Eric.
The WG spent quite a bit of time discussing the definition of "multimedia" (refer to comments and definitions from Eric, thoughts from Ian, and history from Eric). In fact, the WG was not able to come up with a definitive definition of multimedia, and found that it wasn't necessary.
Instead, the document talks about audio, video, animations, and where necessary, synchronization. The term "multimedia" is not part of any requirements, but it is used to convey to the reader generally accepted usage. For the purposes of this document, a multimedia presentation is a presentation that is not a visual-only presentation, audio-only presentation, or tactile-only presentation. In a "classic" multimedia presentation (e.g., a movie that has sound track or an animation with accompanying audio), at least one visual track is closely synchronized with at least one audio track.
Conformance to standards, adoption of system and programming language conventions, and use of standard APIs promotes predictability for users and assistive technology developers alike.
The UAAG 1.0 includes two requirements related to WCAG 1.0 and no requirements related to ATAG 1.0. The requirements related to WCAG 1.0 are:
The UAAG 1.0 does not include any "relative priority" (as defined in ATAG 1.0) checkpoints with respect to WCAG 1.0. For checkpoint 6.1, the priority 1 UAAG 1.0 requirement is implementation of any feature identified by WCAG 1.0 as an accessibility feature (even Priority 3 requirements in WCAG 1.0). This is to ensure that user agent developers implement features to begin with, so that authors may use them.
For checkpoint 10.1, the priority 1 UAAG 1.0 requirement is that documentation conform to WCAG Level Double-A. The definition of priority 1 in UAAG 1.0 is that if the requirement is not met, some users will find access impossible. Since that is not the definition of WCAG 1.0 priority there requirements, the WG (with document objections) decided to limit checkpoint 10.1 to Level Double-A WCAG 1.0 conformance.
UAAG 1.0 focuses on conformance to W3C specifications. The WCAG WG is starting to explore the accessibility of content in formats developed outside W3C, and the UAWG will have to track those developments in later versions of the document.
UAAG 1.0 requires conformance to W3C specifications at a priority 2 level (since other specifications may be accessible). This reveals an assumption made by the UAWG that the UAAG 1.0 should encourage conformance to W3C specifications over non-W3C specifications.
The UAWG considered that support for the internationalization features of a markup language (e.g., HTML "lang", "dir", BDO, etc.) is part of conformance and general, and lack of support does not create problems specifically to users with disabilities (but to all users). The UAAG 1.0 does include one requirement related to support for natural language: if the user agent doesn't have the resources to render content in a particular natural language, it should not render "junk" instead, because that may confuse users with disabilities. Note: The UAWG recognizes that the word "script" is a more appropriate word than "natural language", but the UAAG 1. uses "natural language" to avoid confusion with scripting programming languages.
UAAG 1.0 requires conforming user agents to make information about content and user agent user interface controls available through APIs. There is a hierarchy of APIs:
UAAG 1.0 includes a priority 2 requirement (checkpoint 5.8) to implement operating system and programming language conventions that benefit accessibility. This is a "dangerous" checkpoint because it is open-ended and requires developers to find accessibility information elsewhere. This will be a checkpoint where it is difficult to gauge conformance.
The UAAG 1.0 includes one requirement related to performance: checkpoint 5.6 requires "timely access" during programmatic exchanges. This is so that assistive technologies can "keep up" with changes in the conforming user agent (otherwise, the user may be hearing, for example, content that they are no longer navigating).
In general, the Working Group steered clear of any performance-related requirements and concentrated on functional requirements. However, the "timely access" requirement was considered very important for the proper functioning of assistive technologies.
As a performance requirement, it was difficult to establish a minimal conformance requirement for "timely access" (refer, e.g., to issue 127, issue 9, and issue 201). Therefore, the Techniques document is particularly "fleshed out" in this area so that developers have a strong sense of what will be considered acceptable performance.