W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > October to December 2000

Scope, Intro, Inside/Outside Analysis

From: Eric Hansen <ehansen7@hotmail.com>
Date: Sun, 08 Oct 2000 01:35:08 EDT
To: w3c-wai-ua@w3.org, ehansen@ets.org
Message-ID: <F172pOTziwi7Qf4vKhB000135e7@hotmail.com>
To: UA List
From: Eric Hansen
Re: Scope, Intro, Inside/Outside Analysis

The suggestions in Part 1 are intended to fulfill the assignment that I took 
to write material on "scope and limitations". I have placed that material in 
a larger section that I call the "Introduction." Part 1 also provides are 
newly revised Abstract.

Part 2 provides an analysis of in-scope versus out-of-scope accessibility 
capabilities.

====

Suggestion 1: Refix the Abstract.

This revision to the Abstract supersedes the 6 October version. It uses the 
term "user agent" instead of "Web browser". It also utilizes Jon's 
suggestion for focusing on "built-in features" and "compatibility", which I 
now think makes sense.

Old (29 September 2000):

"Abstract"

"The guidelines in this document explain to developers how to design user 
agents that are accessible to people with disabilities. User agents include 
graphical desktop browsers, multimedia players, text browsers, voice 
browsers, plug-ins, and other assistive technologies that provide access to 
Web content. Virtually all the requirements in this document apply to 
mainstream graphical browsers and multimedia players. Many of the 
requirements also apply to other user agents, such as text browsers, voice 
browsers, and assistive technologies. Following the principles presented in 
this document will help make the Web accessible to users with disabilities 
and will benefit all users."

New:

"Abstract"

"This document provides guidelines to help developers design "user agents" 
-- software that retrieves and renders Web content -- that are more 
accessible to people with disabilities. A user agent that conforms to these 
guidelines will be tend to be (a) directly accessible through _built-in 
accessibility features_ and (b) indirectly accessible through _compatibility 
with other software_ (especially assistive technologies) that can provide 
other important features that are beyond the scope of this document. This 
document intends that a variety of different kinds of user agents be able to 
achieve conformance. Conformance claims for mainstream desktop user agents 
with multimedia capabilities will tend to involve virtually all the 
requirements of this document. Yet the document also allows conformance 
claims that are achievable by user agents that have different or more 
limited media presentation capabilities, such as text-only browsers and 
audio-only browsers."

Comment 1:

I feel much better about this Abstract.

====

Suggestion 2: Add an Introduction that addresses "scope and limitations".

You may notice that my Introduction elaborates on quite of the material in 
sections 3.2 and 3.3 as well as some other material.

Old (29 September 2000):

3.2 Which user agents are expected to conform
Users with disabilities often require a variety of software and hardware for 
full access to the Web. For example, a user might require a graphical 
desktop browser, a multimedia player, and specialized assistive technologies 
such as screen readers, which are useful for controlling speech output and 
refreshable braille display. This document has been designed to promote the 
accessibility of mainstream user agents so that most users with disabilities 
will have access to the Web when using a conforming subject in conjunction 
with assistive technologies. This document also includes requirements to 
promote the accessibility of mainstream user agents for users with 
disabilities who do not require assistive technologies for full access.

User agent developers are strongly encouraged to design software that 
conforms in the default configuration. Users may not be able to install 
complementary software because the default configuration does not allow it 
easily (e.g., the mechanisms for retrieving and installing plug-ins are not 
accessible by default), because they don't have access privileges on a 
public computer, etc. In order for people to use the software at all, the 
installation procedure (and any subsequent software update procedures) must 
be accessible according to the guidelines of this document. For example, the 
software must provide device-independent access and accessible documentation 
of the installation.

Developers are encouraged to adopt operating system features to meet the 
requirements of this document. However, if these features are not 
accessible, the subject must provide an alternative accessible solution. 
Developers may, but are not required to, provide access to adopted operating 
system features through the subject's user interface. For example, if the 
subject relies on the operating system's audio control features to meet some 
requirements of this document, the subject is not required to include those 
controls in its own user interface.

Note: Some software may not conform to this document but still be accessible 
to some users with disabilities. Conformance is expected to be a strong 
indicator of accessibility, but it is neither a necessary nor sufficient 
condition for ensuring the accessibility of software.

3.3 Which user agents are not expected to conform
Specialized assistive technologies (as opposed to mainstream user agents) 
may conform to the requirements of this document when used on their own, but 
this document has not been designed to promote conformance for such 
configurations. This document should still be useful to assistive technology 
developers because it explains what information an assistive technology may 
expect from a conforming subject. Also, many of the design principles in 
this document apply to all software.

New:

"INTRODUCTION"

"This document provides guidelines to help developers design "user agents" 
that are more accessible to people with disabilities."

"A user agent that conforms to this document does so by following (adhering 
to) specific requirements called "checkpoints". Each checkpoint is intended 
to clearly express a minimal requirement. Developers are encouraged to 
exceed the minimal requirements when possible."

"The document offers three conformance levels -- A, double-A, and triple-A, 
with each successive level requiring adherence to more checkpoints, 
including the checkpoints of the previous levels."

"Anyone may make a conformance claim about a user agent. This document 
provides instructions for publishing a conformance claim."

"In this document the term "user agent" is used in a general sense to refer 
to any software for retrieving and rendering Web content."

"The term "user agent" is also used in a specific sense of referring to the 
specific software for which a conformance claim is made. It is used in this 
sense within the checkpoints. Thus, in the context of the checkpoints, the 
term "user agent" refers to the 'subject of a claim.'"

"The user agent (i.e., subject of the claim) may consist of one component or 
many. Typically one component is some kind of "Web browser" and may be 
supplemented by other components, such as multimedia players or other 
viewers." [NOTE. I don't want to emphasize assistive technology here. It 
would confuse the issue.]

"Accessibility Strategy"

"A user agent that conforms to these guidelines will be tend to be (a) 
directly accessible through _built-in accessibility features_ and (b) 
indirectly accessible through _compatibility with other software_ 
(especially assistive technologies) that can provide other important 
accessibility features that are beyond the scope of this document."

"Scope"

"Some of the important accessibility features that are _inside_ the scope of 
this document include:" [Insert some of the capabilities listed by Jon in 
his recent memo. Include those capabilities that are intended to _promote_ 
'compatibility' with other software.]

"Some features that are _outside_ the scope of this document include braille 
support, some navigation using synthesized speech output, some resizing and 
color-modification of visual objects. Some of the most important 
capabilities that are _outside_ the scope of this document are those that 
can typically provided by assistive technologies, at least the mainstream 
desktop environment."

"Variety of Conforming User Agents"

"This document intends that a variety of different kinds of user agents be 
able to achieve conformance. Conformance claims for mainstream desktop user 
agents with multimedia capabilities will tend to involve virtually all the 
requirements of this document. Yet the document also allows conformance 
claims that are achievable by user agents that have different or more 
limited media presentation capabilities, such as text-only browsers and 
audio-only browsers. Section 3.4 provide more detail on the range of 
possible conformance claims."

"Benefits to Different Audiences"

"This document will benefit many different audiences. Developers of Web 
browsers will benefit directly from the guidelines when designing Web 
browsers. Developers of assistive technologies will benefit from knowing how 
to make their products communicate better with conforming Web browsers. 
Consumers can claims to evaluate which user agents are best suited to their 
accessibility purposes. All audiences can use the document to interpret and 
construct conformance claims. Many of the principles and specific 
requirements of this document are expected to improve the accessibility of 
many different kinds of software, not just Web user agents."

"Disclaimer"

"Conformance to the requirements of this document is expected to be a strong 
indicator of accessibility, but it is neither a necessary nor sufficient 
condition for ensuring the accessibility of software. Some software may not 
conform to this document but still be accessible to some users with 
disabilities. Conversely, software may conform to this document but still be 
inaccessible to some users with disabilities."

====

Suggestion 3: Add Assumptions.

New:

"ASSUMPTIONS"

"Following are assumptions that underlie the development of the guidelines. 
Generally, the more closely that actual conditions parallel, the 
assumptions, the more likely that a conformant user agent will meets the 
real-life accessibility requirements of people with disabilities."

"1. Both Disabled and Non-disabled Users"

"This document assumes that most conformant user agents will need to be 
usable by both disabled and non-disabled users and not just one or the 
other. Implicit in this assumption is the notion of "universal design" -- 
that is, to the extent possible, one ought to develop products that can be 
used by everyone, including people with and without disabilities."

"2. Utility of Partial Coverage of All Accessibility Requirements"

"This document is based on the assumption that it is worthwhile to make 
progress in accessibility of user agents even though one cannot meet the 
access needs of every person with a disability. Some disabilities -- such as 
severe cognitive disabilities -- may cause accessibility barriers that 
cannot yet be overcome through modifications to either Web content or the 
user agents that retrieve and render Web content. While this document 
attempts to address the access requirements of major disability groups, it 
does not meet the access need of every individual with a disability."

"2. WCAG Conformant Content"

"This document assumes that Web content conforms well [NOTE: I don't know 
that we need to say more "how" well.] to WCAG 1.0. A consequence of this 
assumption is that the document does not place much emphasis on 'repair 
functions' that might compensate for bad authoring. For example, the 
document does _not_ require capabilities that might exploit style 
information in Web content to _infer_ the document structure that the Web 
content author had in mind. Specifically a repair function might attempt use 
style information such as large font and bolding to infer that author 
intended large font bolded content to serve as section headings. With good 
authoring, the need for such repair functions is minimized since structure 
will usually be explicitly indicated through markup (e.g., heading level 
markup, etc.)."

"3. Non-Extreme Environmental Conditions"

"The document assumes that user agents are not being used under extreme 
environmental conditions. A consequence of this assumption is that the 
document does not necessarily take into account considerations that would be 
extremes of lighting, weather, or environmental noise."

"4. Limited Diversity of Delivery Systems"

"This document assumes limited diversity of delivery equipment. While an 
attempt has been made to make the document useful for a wide range of 
delivery devices, the document does not necessarily anticipate all the 
diverse kinds of devices on which a user agent might operate. For example, 
on the whole, the requirements and conformance outcomes resulting from 
document might fit better with user agents operating on desktop multimedia 
personal computers than with mobile browsers with super-small visual 
displays."

"5. General-Purpose Web Content"

"This document is based on the assumption that the Web browser is being used 
to access content representing a wide array of purposes (e.g., information, 
education, entertainment, commerce). For example, the document is not 
necessarily optimal for a user agent that is intended solely for a narrow 
content purpose (e.g., stock quotes)."

"6. Attention to Other Important Design Requirements"

"This document assumes that developers and others will take into account a 
variety of design considerations as well as the "accessibility" 
considerations set forth in this document. Considerable effort has been made 
to ensure the requirements of this document are compatible with other good 
software design practices. However, this document does not purport to be a 
complete guide to good software design."

"7. "Accessibility" Relevant Given Very Limited Presentation Capabilities"

"This document assumes that it is sensible to attribute "accessibility" even 
to user agents having extremely limited presentation capabilities, such as 
those with only visually displayed text output or only audio output. One 
could argue, for example, that a user agent with text-only output could not 
be considered accessible because it could not be used by someone who is 
blind, and that therefore, it should not be able to conform to the document. 
However, this document allows such user agents to achieve conformance 
levels. Of course, conformant user agents will tend to be compatible with 
assistive technologies that, while outside the scope of the document, could 
address the accessibility requirements of people with diverse disabilities."

"8. Greater Assistive Technology Reliance on the Document Object Model 
(DOM)"

"This document was developed with the expectation that developers of 
assistive technologies will come to rely on the user agent's DOM. [ETC.]. 
This document was developed with involvement of developers of assistive 
technologies."

"9. Much of the Value of Assistive Technologies Outside the Scope"

"This document is based on the assumption that while assistive technologies 
will continue to be an essential part of full accessibility solutions, much 
of their greatest value will be felt outside the scope of this document. 
There is nothing that prevents any software, including assistive technology 
software from being included within a conformance claim and claimants are 
welcome to do so. However, some of the things that assistive technologies do 
best (braille support, navigation via speech output, object enlargement, 
etc.) are either not required by the document (braille) or are not heavily 
emphasized by the document."

"10. Software Source as Essentially Irrelevant"

"This document assumes that it is essentially irrelevant whether user agent 
software arrives comes from one source and vendor a hundred sources and 
vendors. This assumption likely to become more true than it is today."

"11. Installation and Configuration as Out of Scope Issues"

"This document assumes that installation and configuration of user agent 
software are outside the scope of this document. However, user agent 
developers are strongly encouraged to design software that conforms in the 
default configuration. Users may not be able to install various software 
components because the default configuration does not allow it easily (e.g., 
the mechanisms for retrieving and installing plug-ins are not accessible by 
default), because they don't have access privileges on a public computer, 
etc."

=====

Suggestion 4: Fix or remove the verbiage on installation.

The following is out of place. It is either redundant with existing 
checkpoints or if something more is intended, it should be a checkpoint.

"In order for people to use the software at all, the installation procedure 
(and any subsequent software update procedures) must be accessible according 
to the guidelines of this document. For example, the software must provide 
device-independent access and accessible documentation of the installation."

====

Suggestion 5: Consider where to put the following.

The follow is left over in section 3.2. It seems as though there is a 
checkpoint hidden in the paragraph. (Perhaps the second sentence?)

"Developers are encouraged to adopt operating system features to meet the 
requirements of this document. However, if these features are not 
accessible, the subject must provide an alternative accessible solution. 
Developers may, but are not required to, provide access to adopted operating 
system features through the subject's user interface. For example, if the 
subject relies on the operating system's audio control features to meet some 
requirements of this document, the subject is not required to include those 
controls in its own user interface."

PART 2: IMPORTANT CAPABILITIES EXTERNAL TO UAAG CLAIMS

As part of my assignment to draft a section on scope and limitations, I am 
trying to identify what user agent capabilities are essential parts of our 
vision of user agent accessibility but which are outside the scope of UAAG 
claims.

I believe that we need to be able to articulate our reasons for not 
including those capabilities within the document. One example is Braille 
output. That is outside the scope of the document even though, I would 
argue, it is an essential part of WAI's accessibility strategy. As will be 
shown below, there are also other examples. In the Appendix, I have also 
tried to articulate the relationship between the UAAG document and assistive 
technologies.

Characteristics of Essential Un-addressed Capabilities

What would be the _characteristics_ of capabilities that are essential but 
not addressed by the UAAG checkpoints? Possible characteristic of essential 
un-addressed capabilities might be as follows:

(a) The capability is an essential part of the current WAI vision of 
accessibility;
(b) The capability can now or could soon be technologically feasible to 
implement; and
(c) The capability is not addressed by the conformance claims.

By "essential" I mean something on the order of a Priority 1 or perhaps 
Priority 2 requirement if it were to be included in a WAI accessibility 
guideline (WCAG, ATAG, UAAG).

Full Minimal Capabilities For Rendering of Web Content

I think that WAI's "vision" -- particularly as it relates to rendering of 
content -- might, at a minimum, require things such as the following.

a. Basic content types such as text, graphics, tables, animations, video, 
and audio ought to be available to people with disabilities in their 
'default' (or 'initial') renderings (i.e., audio objects as audio output, 
graphics as visually displayed objects, etc.).
b. Text equivalents must be provided for all non-text elements so that 
content that is inaccessible in is 'default' presentation mode can be made 
accessible.
c. People with disabilities ought to be able to receive the essential 
benefit of Web content by relying on visually-displayed-text-only, speech 
synthesis-only, Braille-only output, if those modes are helpful.
d. Users ought to be able to control and/or configure major presentation 
characteristics of media (size, volume, fonts, replay, slow, color, etc.).
e. The subject of a claim should be able to communicate well with other 
software (including assistive technologies) so that it will be easy to add 
new capabilities.

If that is not a good summary of the vision, then I think that one ought to 
be produced. (I think that we actually have the pieces but I think that we 
need to pull it together more tightly.)

Importance of the Big Picture

Why is it important for UA developers and other users of the specification 
to have the full minimal capabilities in mind? First, UA developers are 
likely to develop a better UA if they know how what they are doing fits into 
the big picture (i.e., the "full solution"). Second, they will have a better 
idea about what external capabilities they need communicate with (to not 
conflict with). Third, they will know what kinds of capabilities they might 
wish to incorporate into their UA in order to provide a greater proportion 
of the full solution. Fourth, by understanding better the specific ways in 
which their user agent does not provide the "full minimal solution" they may 
be more accurate in the _informal_ claims that they make regarding the 
"accessibility" of their UA. Fifth, if the UAAG document identifies some 
essential un-addressed capabilities as not being addressed because the 
requirement are not sufficiently well-understood, then this may help UA 
developers better focus their research and development resources. Sixth, 
buyers of user agents (and the "boxes", e.g., desktop computers, kiosks, 
mobile devices) must have some sense of what else they need in order to 
provide "full solutions".

Reasons for Not Including All Essential Capabilities Within a Claim

What might be good reasons for not directly addressing all full minimal 
capabilities? For example, how would one rationalize the exclusion Braille 
output capabilities? I think that there are several potentially legitimate 
reasons for existence of an "essential un-addressed capability".

a. The capability is now or will soon be achievable through _readily 
available technologies_, including _commercial assistive technologies_.

b. The capability cannot be handled by _software_ alone.

c. The capability cannot be implemented until other specifications are 
improved.

d. The capability, though feasible, currently lacks a sufficient number of 
implementations to allow consideration within the document.

e. The capability would encourage practices that are contrary to the 
consensus accessibility strategy.

f. The capability is insufficiently well understood.

g. The capability is too general to be validated.

h. The capability is too complex to be expressed in a practical set of 
design requirements.

i. The capability is only hypothetically necessary since the document 
already requires access to "all content" (UAAG checkpoint 2.1).

j. The capability is handled indirectly by the applicability provisions.

k. The capability is _too narrow_ in application.

l. The capability is already part of some, if not all, operating system or 
GUI environments.

m. To include the capability within the subject of the claim would violate 
traditional boundaries of what is provided by Web browsers and what is 
provided by assistive technology.

In presenting this list, I am not claiming that each of these reasons 
necessarily constitutes a legitimate reason to not include the capability.

My main point is not how legitimate each of these reasons is, but rather 
that if we are knowingly setting essential UA-type capabilities outside the 
boundaries of a claim, then we need to let people know that and give them 
some rationale for our doing it.

Some Examples

Following is a list of things that seem essential but which are either not 
addressed or seem under-addressed by UAAG. In presenting this list, I am not 
saying that I think that they need to be reflected in new or modified 
checkpoints. I am inviting deliberate affirmations of our decisions about 
them.

1. No requirements for Braille access. Rationale: Handled by assistive 
technology.
2. Very few requirements for speech-output-based access. Rationale: Handled 
by assistive technology (?). To include would violate a traditional boundary 
between assistive technology and regular user agents.
3. Little capability specifically for table navigation. Rationale: Not 
enough known (?). Handled by assistive technology (?).
4. No repair capabilities for capturing important information found in 
styles. Rationale: The capability would encourage practices (bad authoring 
practices) that are contrary to the consensus accessibility strategy. [I 
have tried to address this in [1] but it looks as though such requirements 
may not be included.]
5. No requirement to actually render through an output device. Rationale: 
Capability cannot be handled by software alone.
6. No checkpoint requirement to actually handle any media type (content 
type). Rationale: The issue is handled indirectly applicability provisions 
(labeled sets, etc.).
7. No general requirement to resize objects other than text per UAAG 
checkpoint 4.1. (Note. Checkpoint 4.1 encompasses use of fonts in SVG [and 
how about MathML?]. Rationale: Handled by assistive technology. [Evidently 
built into MacOS(?).] (Still under consideration.)

I think that the bottom line is this. If we think that there is some very 
important UA capability ("retrieving and rendering Web content") that is not 
within the scope of the UAAG claim, we need to document those capabilities 
and say something about why they are not within the claim. For example, I 
think that if we really think that there are speech-output-based navigation 
capabilities that are essential but outside our claim, then we need to say 
so, and give reasons (e.g., "We recognize that fully conformant user agents 
must still be augmented with additional software (e.g., screen-reader) in 
order to be fully useful to a person who is blind.").

Conclusion

Comments are welcomed about items on the list (1 through 7). I should point 
out that some of the list may not even be relevant because at the time that 
the working group considered them, they were simply not considered important 
enough or were not though to be feasible. If so, I would like to be alerted 
to that as well.

I would also be happy to receive any comment on rationales "a", "b", "c", 
etc.

Appendix A examines the relationship between the UAAG document and 
capabilities outside the claim, particularly those that might be provided 
via assistive technologies.


[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0004.html

====

Appendix A: UAAG and Assistive Technologies

The UAAG WG takes the position of excluding some capabilities believed to be 
valuable for accessibility. This means that even a subject of a UAAG 
conformance claim (sometimes simply called the "Subject") that is 
_conformant_ must still work with _external_ technologies (e.g., assistive 
technologies) to provide some essential accessibility functionalities. I 
have previously advocated including all essential capabilities _within_ the 
claim, yet for technical and non-technical reasons, we are taking a 
different approach.

There is nothing to prevent any software component, including an assistive 
technology, from being the subject a claim (either as a singular user agent 
or as a component of a "composite" user agent) and therefore being 
_internal_ to the claim. Yet developers of assistive technologies would have 
to meet fairly stringent requirements (e.g., regarding their user 
interfaces, the modes of communicating with other software, etc.) in order 
to move inside the claim, either as a component of a composite user agent or 
as a singular user agent. An additional disincentive for the inclusion of 
assistive technologies within claims is the fact that some of the very kinds 
of important capabilities that are _not_ required by UAAG checkpoints are 
the _very_ capabilities that are typically provided by assistive 
technologies (Braille, advanced speech navigation, visual enlargement of 
non-text element, etc.). Thus, the capabilities that assistive technologies 
are best at providing are often either _not required_ or are not emphasized 
by UAAG. This means that while there is nothing to prevent inclusion of 
assistive technologies within a UAAG claim, the document provides little 
incentive for their inclusion within the claim.

I think that it is legitimate for the _user_ of an accessibility 
specification such as the UAAG to be notified if there are essential 
accessibility capabilities that are not addressed by the document and, if 
so, why they are not addressed. For example, if certain essential 
capabilities are not included in UAAG claims because we expect them to be 
handled by assistive technologies, then we need to say so.

<END OF MEMO>


_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.
Received on Sunday, 8 October 2000 01:35:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:50:22 GMT