- From: Eric Hansen <ehansen7@hotmail.com>
- Date: Sun, 08 Oct 2000 01:35:08 EDT
- To: w3c-wai-ua@w3.org, ehansen@ets.org
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 UTC