- From: Ian Jacobs <ij@w3.org>
- Date: Fri, 11 May 2001 23:29:18 -0400
- To: "Hansen, Eric" <ehansen@ets.org>
- CC: w3c-wai-ua@w3.org
Hi Eric, My comments preceded by IJ: (and lots snipped). _ Ian "Hansen, Eric" wrote: > > ================================ > > 2) Section 2. The guidelines. > > ================================ > > > > Since talking to developers and W3C Working Groups, it has become > > apparent to me that it is sometimes challenging to "instantiate" > > our fairly abstract requirements for specific formats or > > software. The Techniques document seems to help a lot (and I look > > forward to providing additional help in the form of more > > examples, profiles, test suite examples, etc.). However, I think > > the following type of statement might be useful to give readers a > > heads-up about what is expected when they read the document: > > > > <CURRENT> > > Each checkpoint is intended to express one or more minimal > > requirements clearly, so that someone evaluating a user agent may > > verify that it satisfies the requirements. User agent developers > > are encouraged surpass the minimal requirements expressed by the > > checkpoints. Indeed, for some requirements, it is expected that > > developers will find it easier or less costly to implement a > > solution that is more general than one that would only satisfy > > the minimal requirements of a checkpoint. Both this document and > > "Techniques for User Agent Accessibility Guidelines 1.0" > > [UAAG10-TECHS] suggest techniques to help user agent developers > > meet or surpass the minimal requirements. Note: In some cases, > > though the requirement of a checkpoint may be clear, without > > documentation from vendors (e.g., about implemented APIs), it may > > be difficult to verify that the subject of a conformance claim > > has satisfied the requirement. Some checkpoints (e.g., those > > requiring developers to follow conventions or implement > > specifications defined outside this document) are inherently more > > subject to interpretation than others. > > </CURRENT> > > > > <NEW> > > Each checkpoint expresses one or more minimal > > requirements. However, the checkpoints are not technology > > specific. In fact, they have been designed to make sense for a > > variety of existing and future technologies. As a result, > > developers and other readers must think about how the abstract > > requirements apply in specific contexts (e.g., for > > HTML or for SVG, in this or that operating environment, etc.). > > "Techniques for User Agent Accessibility Guidelines 1.0" > > [UAAG10-TECHS] provides technology-specific information that is > > intended to help developers understand how to apply the > > checkpoints in different contexts (and to understand when the > > checkpoints might not apply). > > EH: This raises the issue: Must one read the Techniques document to know > whether a checkpoint applies? Ideally, UAAG 1.0 should be sufficient to > guide the user on that point. Or if they need guidance from the Techniques > document to make that determination, then perhaps that needs to be noted for > specific relevant checkpoints. IJ: I don't think that developers are required to read the Techniques document to understand whether a checkpoint applies. However, it may be an indispensable resource: the more experience we have with different formats, and can compare techniques from format to format, the easier it will be for developers to apply the checkpoints to their situation. As long as the checkpoints are technology independent, then a technology-specific companion will be very important. > > User agent developers are encouraged surpass the minimal > > requirements expressed by the checkpoints and to address > > accessibility issues not covered by this document. For instance, > > while some checkpoints make requirements for "content only", > > many of those requirements make sense for the user interface as > > well (e.g., allow the user to render blinking text as motionless > > text). > > > > User agent developers are encouraged to satisfy the requirements > > of this document by adopting "universal design" solutions: > > solutions that improve the user agent for all users and > > simultaneously improve accessibility. > > EH: The foregoing language may be OK, but in general, I think that we should > temper our emphasis on making improvements for "all users". One reason for > this tempering is something that relates to the notion of equal access. I > think that our primary focus is and should be on improving access for people > with disabilities. Period. Improvements for people without disabilities are > a possible secondary effect. IJ: I think we emphasize universal design primarily to remind people that a more general solution may both be easier to implement, may benefit more users, and may still meet the requirement. Do you see any instances where we emphasize "all users" other than as a general side-effect or way to simplify implementation? - Ian -- Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs Tel: +1 831 457-2842 Cell: +1 917 450-8783
Received on Friday, 11 May 2001 23:29:18 UTC