- From: Ian Jacobs <ij@w3.org>
- Date: Sun, 20 Aug 2000 00:40:58 -0400
- To: Eric Hansen <ehansen7@hotmail.com>
- CC: w3c-wai-ua@w3.org
Eric Hansen wrote:
>
> To: UA List
> From: Eric Hansen
> Subject: Accessibility and Conformance, etc.
[snip]
My comments preceded by IJ:.
Eric, I'm surprised that you have focused on applicability this much.
I thought it was on the way out...
My primary concern with your comments is that they seem to change
significantly the intended scope of the document. Please bear in
mind that this document does not attempt (nor has it ever attempted)
to include requirements for user agents so that a conforming user
agent on its own would meet the needs of all users with disabilities.
Some of your proposals below suggest to me that you wish it did include
these requirements. More details follow.
> Problems That I Think Could Arise
>
> Following are some problems that I think could arise with our current
> conformance claim system.
>
> Problem #1: A buyer of user agents says: "According to their developers,
> user agents T and R both achieve triple-A conformance. They must be equally
> accessible." Yet a closer look at the claim shows that user agent cites 30
> inapplicable checkpoints and the other cites only 2 inapplicable
> checkpoints. Is that a fair comparison?
IJ: We require in the claim that you indicate how many checkpoints
you consider don't apply. So we have accounted for this to a certain
extent.
> Problem #2: A buyer of user agents says: "According to their developers,
> user agent S achieves double-A conformance and user agent U achieves
> single-A conformance. User agent S must be more accessible than user agent
> U." Yet a closer look at the claim shows that user agent S cites 15
> inapplicable checkpoints and the other cites only 1 inapplicable checkpoint.
> Is the single-A conformant user agent really less accessible than the
> double-A conformant user agent?
>
> Problem #3. A developer of user agent X makes a claim that says, "A
> composite user agent W composed of user agents X, Y, and Z achieves triple-A
> conformance. Wow! Agent X must be a very accessible user agent!" A closer
> look at the claim shows that there are only 3 inapplicable checkpoints. Not
> too bad! But what the conformance claim does not reveal is that user agents
> Y and Z _by themselves_ would achieve the same thing (triple-A conformance
> with 3 inapplicable checkpoints). This could occur, for example, if user
> agents X and Y were actually the same kind of user agent. Regardless of how
> inaccessible user agent X is, it does not lower the overall rating the
> composite user agent that includes user agents Y and Z. The public who reads
> the claim assumes that user agent X is highly accessible, yet in reality it
> contributes nothing to the overall rating.
IJ: I don't consider that the possibility that someone might abuse the
guidelines in this way means that there's a problem with the Guidelines.
We cannot design a document that is devious-proof.
> A Problem That I Would Like to Be Assured Could Not Arise
>
> Problem #4. A user agent adheres fully to the checkpoints, notably
> checkpoint 1.1 (though see Issue X below) and checkpoints in guideline 5
> ("Observe system conventions and standard interfaces), but the user agent is
> not fully operable and usable by people who are blind, deaf-blind, have
> physical disabilities, etc., because although the document requires the
> prerequisites for such operability, it does not actually require that
> operability.
> SOME PREREQUISITES TO SOLVING THE PROBLEMS
>
> Generally, we need to focus clearly on who our audience is and what kinds of
> decisions we want them to be able to make based on the conformance claims.
>
> I don't know if the following will entirely solve the problems, but I think
> that they will make considerable progress.
>
> ====
>
> Suggestion 1. Focus more specifically on "general-purpose graphical desktop
> browsers that provide multimedia presentation capabilities".
>
> Instead of trying to address all different kinds of user agents, I believe
> that the scope should narrow. For example, about the ideal scope that I can
> think of at this moment is: "general-purpose graphical desktop browsers that
> provide multimedia presentation capabilities". (I can think of other
> definitions that may have technical advantages, but I don't think that they
> communicate as well.)
>
> For the most part, I am merely suggesting a tightened focus. For at least
> months, it seems that the UAAG working group has acknowledged that the
> document has general-purpose graphical desktop browsers are of primary
> interest. I am merely suggesting lumping in the multimedia capabilities
> (audio, animation, and motion video).
>
> I think that in this matter, we are far better off doing one thing well
> rather than trying to do too much and doing them all not so well.
>
> ====
>
> Suggestion 2. Define the term 'fully compliant user agent'.
>
> "For the purpose of this document, a 'fully compliant user agent' is a user
> agent that (a) achieves a triple-A rating (i.e., adheres to all applicable
> checkpoints) and (b) has _no inapplicable checkpoints_. One may also refer
> to such a user agent at a certain conformance level. For example, a 'fully
> compliant double-A user agent achieves the double-A UAAG level and has no
> inapplicable Priority 2 or Priority 1 checkpoints. "
IJ: That is interested. I am a little concerned that too many terms
will confuse people, but let's suppose that we have a single label
for the case where all checkpoints are considered applicable.
> ====
>
> Suggestion 3. Acknowledge the necessity for composite user agents.
>
> The document should acknowledge the following:
>
> "It is recognized that user agents that provide 'general-purpose graphical
> desktop browsers that provide multimedia presentation capabilities' may
> actually constitute a "composite user agent", i.e., a user agent that is
> composed of multiple, 'smaller', user agents such as (a) a general-purpose
> graphical desktop browser and (b) a multimedia player. Indeed, at the time
> of the publication of this document, a general-purpose graphical desktop
> browser typically relies on a distinct multimedia player for multimedia
> capabilities. "
IJ: Please refer to the new language in sections 3.2 and 3.3 of the
18 August draft and say whether you think that the text suffices.
> ====
>
> Suggestion 4. Define the terms 'prime user agent' and 'supplementary user
> agent'.
>
> New:
>
> "Conformance claims must designate a 'prime user agent'. If the claim is for
> a composite user agent, then the prime user agent should be the user agent
> for which the claimant has the most direct interest or knowledge. For
> example, the developer of a multimedia player might designate the multimedia
> player as the prime user agent, making the other user agents, 'supplementary
> user agents'. If a claim is for a singular user agent, then that single user
> agent is the prime user agent."
IJ: We used to say "independent" and "dependent" user agent. We deleted
those terms when we decided to stop trying to craft a conformance
mechanism
to suit all user agent types. I am not convinced yet that this
distinction
is necessary. I'd rather consider user agents as modules, without
hierarchy
if possible.
> ====
>
> Suggestion 5. Allow few if any inapplicable checkpoints.
>
> I think that we need to set a maximum number of inapplicable checkpoints or
> perhaps even allow no inapplicable checkpoints. Another way of saying this
> is that any valid claim must encompass all or nearly all of the UAAG
> checkpoints. Does it really make sense to try to compare the accessibility
> of (a) a composite user agent with a vast array of functionality and (b) a
> user agent that has only a tiny fraction of the same functionality?
IJ: I think it's a mistake to set a maximum number. I think it does
make sense to tell people that a bunch of inapplicable checkpoints is
a bad sign of ... applicability of the guidelines. Until the 18 August
draft, we had text to that effect. From the 28 July guidelines [1],
section 1.7:
This document has been designed to promote the accessibility
of general-purpose graphical user agents. While many of the
principles set forth in this document apply to other classes
of user agents, including assistive technologies, many of the
checkpoints do not. As the number of applicable checkpoints
decreases for a piece of software, the likelihood increases
that the guidelines are not an accurate gauge of the accessibility
of that piece of software.
I prefer this kind of warning to a hard and fast limit.
[1] http://www.w3.org/WAI/UA/WD-UAAG10-20000728/
> ====
>
> Suggestion 6. Define a clear relationship between the fully compliant user
> agent and capabilities associated with screen readers and refreshable
> braille user agents.
>
> The relationships between the fully compliant user agent and braille and
> screen-reader-type capabilities is critical because braille and
> speech-synthesis are integral to our concept of accessibility, notably
> through the concept of text elements (including text equivalents), which
> must be understandable when output to synthesized speech and braille.
>
> As I consider the current document (18 August 2000), the capabilities
> associated with screen readers and braille devices are _outside_ the
> boundary of the fully compliant user agent.
IJ; Yes.
> For example, no checkpoint
> requires that a user agent be operable via screen reader/speech-output
> program. Nor does any checkpoint require that the user agent be operable via
> a refreshable braille device. I might not be so concerned about these lacks
> if there were checkpoints that specifically required _fully compatibility_
> with screen-reader-type programs and refreshable braille devices. But no
> checkpoint specifically requires such compatibility or operability.
IJ: That is because we very consciously chose to avoid requiring this
type of
dependency in a conformance claim between one vendor and another. Our
recent discussions about claims address the "right" to make such a
claim, but we have in the past not wanted to "require" interdependencies
(even while the actual interoperability is a good and important thing.).
If this document is aimed at developers of general purpose user agents,
then they should not "suffer" because assistive technology developers
are not holding up their end of the "bargain", due to say, a business
decision. In short, we decoupled vendors intentionally, after getting
confirmation from assitive technology vendors that the DOM and
other standard interfaces did in fact meet their needs and they were
interested in requiring that those APIs be implemented. That is as
far as we wanted to go.
> It
> appears to me that adherence to several checkpoints in Guideline 5 ("Observe
> system conventions and standard interfaces") fulfill critical prerequisites
> for operability by facilitating communication with such devices. And
> certainly the checkpoints in guideline 7 ("Provide navigation mechanism")
> and other guidelines would be very relevant for navigating through a
> document via speech output or braille, but if they may do little good if
> there is _no actual requirement for operability_ via speech-output and
> braille device. I am concerned that there may be a gap that may be unbridged
> between the UAAG requirements and full operability via such user agents. I
> am not sure how big of a problem this is. For the purpose of the present
> discussion, suffice it to say that the capabilities associated with screen
> readers and braille devices are _outside_ the boundary of the fully
> compliant user agent.
IJ: Yes, intentionally, for the reasons cited.
> This discussion brings to mind a comment made by at least one individual in
> a recent conversation who said approximately as follows: "We plan to comply
> with the UAAG document using our browser and JAWS for Windows." However, if
> I understand the current UAAG document correctly, the document does not
> specifically require operability via any package like JAWS for Windows.
>
> I think that this would mean that, under the current document, the
> conformance claim for a fully compliant user agent need not actually mention
> screen reader packages or braille devices. I am again concerned that this
> may not be adequate.
IJ: It may not be. However, we have chosen (so far) to not require
vendor
A's general purpose user agent conformance to depend (indeed, fluctuate)
based on the presence of, say, three interoperable products in the
market.
It is important that those products exist (otherwise we will have failed
in promoting accessibility). However, in terms of the *scope of this
document*, we have chosen not to include an interoperability
requirement.
> By the way, I think that we need to keep in mind that it is the checkpoints
> that constitute the normative part of guidelines. The introductory material
> for guidelines and the notes attached to checkpoints are not what matter. It
> is the checkpoints themselves that are the requirements. (Please correct me
> if I am wrong in this idea.)
>
> ====
>
> Suggestion 7. Add checkpoints that require basic graphical and multimedia
> capabilities.
>
> I mentioned this suggestion before and saw Ian Jacob's 18 August 2000
> response [1]. Ian cited earlier discussions that resulted in the exclusion
> of such requirements. But I would say again that it makes no sense to me at
> all to set out requirements for a user agent of the type we are referring to
> in this document and fail to mention that it must be able to present
> graphics and multimedia (including audio, animation, video, etc.). Such
> media presentation capabilities are extremely important for people with a
> variety of disabilities (deaf, blind, learning disability, cognitive
> disability).
IJ: But these are important to everyone! Why would a user agent not do
these things - its only purpose is to implement specifications for
these content types.
> Furthermore, I think that an implicit part of our accessibility
> philosophy is that people with disabilities should be free to rely on
> primary content (e.g., the text, graphics, video, audio, animation, etc.,
> that is intended for people without any disability) as much as they want as
> well as to have access to secondary content that can substitute for portions
> of the primary content that is inaccessible to them. I think that failure to
> require that at fully compliant user agent to present these basic types of
> media would represent a gaping hole in the document.
I don't believe that it is based no our checkpoint 6.2 that requires
conformance to applicable W3C specifications: markup, style, graphics,
etc.
What more would you wish to say than this?
> While there may have
> been good reason to exclude these requirements in a earlier stage of the
> development of the document, I don't think that those reasons hold any
> longer. Finally, I would add that if the working group agrees to the tighter
> focus on 'general-purpose graphical desktop browsers that provide multimedia
> presentation capabilities', then it would seem all the more puzzling to lack
> a requirement for presentation of graphics and multimedia.
>
> ====
>
> Suggestion 8. Consider adding functional requirements that are more specific
> to the needs to particular disability audiences.
>
> I think that it is worth considering adding more general functional
> requirements to the existing checkpoints. Such requirements might help
> ensure operability.
>
> >From the Trace R&D revision of the NPRM proposed standards [2]:
>
> § 2194.27 Functional performance criteria.
> NOTE: If users would typically have related assistive technology with them
> whenever they wanted to use the E&IT then the ability of the product meet
> this criterion can be evaluated with the assistive technology(s) in place.
> (1) At least one mode of operation and information presentation that does
> not require user vision and that allows full access shall be provided.
> (2) At least one mode of operation and information presentation that does
> not require visual acuity greater than 20/200, that does not require audio
> perception, and that allows full access shall be provided.
> (3) At least one mode of operation and information presentation that does
> not require user hearing and that allows full access shall be provided.
> (4) Where audio information is important for the use of a product, at least
> one mode of operation and information presentation shall be provided in an
> enhanced auditory fashion.
> (5) At least one mode of operation and information presentation that does
> not require user speech and that allows full access shall be provided.
> (6) At least one mode of operation and information presentation that does
> not require fine motor control or simultaneous actions, that is operable
> with limited reach and strength, and that allows full access shall be
> provided.
> (7) ADVISORY: Wherever possible products should minimize the cognitive and
> memory ability required of the user and accommodate people with learning
> disabilities.
IJ: I would STRONGLY (read: STRONGLY) object to adding these as
checkpoints to the document at this time. You are, in essence, asking
that a general purpose user agent (the focus of this document) also
be a specialized user agent for all of the functional limitations you
cite.
That would be an ENORMOUS change in the document, and inappropriate at
this
stage of the document's development.
I would not object at all at including this or similar text as
informative
material to educate readers, i.e., to explain that this is the goal
of the sum of software that a user may require for access. However, many
of these functionalities exceed the scope of this document.
>
> ====
>
> Suggestion 9. Require conformance claims to indicate the identity of the
> claimant.
>
> The claimant could be an individual, an organization, or a part of an
> organization.
IJ: I don't think that this should be a requirement, though it may be
suggested. Please explain why this should be added.
> ====
>
> Suggestion 10. Require that for each component in the claim, the claimant
> indicate its role.
>
> For example, for each component, the following roles might be allowed:
> Developer, User, Other, etc.
IJ: I thought you were going to say that the "role" was, for instance,
graphical user agent, SVG viewer, SMIL player, etc. That would be
useful, and perhaps even important to consumers to understant.
> ====
>
> Suggestion 11. Require that if two or more components of a claim are the
> same component, a rationale for this must be included.
>
> We want to avoid claims that might contain problems like problem #3 at the
> beginning of this memo.
> ====
>
> Suggestion 12. Reexamine situations in which the language of "applicability"
> occurs within checkpoints.
>
> I think that we need to examine how the word "apply" or related words are
> used and see if we really want them associated with the concept
> applicability.
IJ: Yes.
> ====
>
> Suggestion 13. Define the circumstances under which a two or more user
> agents become to be counted as a single user agent.
IJ: Why does it matter to count a user agent as a single user agent?
I don't want to get into the implementation details of the fact that
emacs may be implemented by a server and a client, for instance.
> ====
>
> Suggestion 14. Define the circumstances under which the user interface (per
> checkpoint 1.1) of a user agent comes to include the user interface of
> another user agent.
>
> ====
>
> Suggestion 15. Explain what we think are appropriate uses of the ratings.
>
> For example, is it appropriate to use such ratings as sole criteria in
> buying decisions? Even more modestly, are the ratings appropriately used in
> representing the accessibility factor in buying decisions.
>
> [1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0263.html
> [2] http://www.access-board.gov/sec508/comments-nprm/101.html
IJ: I would object to such information in this document. I would not
object to making such comments about UAAG 1.0 in other documents,
intended
for other audiences.
_ Ian
--
Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 831 457-2842
Cell: +1 917 450-8783
Received on Sunday, 20 August 2000 00:41:09 UTC