Re: Comment on WCAG 2.0

So fundamentally one could say it is a matter of using the most
semantically rich and flexible technology available, all other
considerations (i.e., user agent support) being equal.

Specifically this would mean:

Prefer style sheets to presentational markup

Prefer text to images of text.

Prefer vector graphics to raster-based images (again for reasons of
scalability)

Prefer formats that encode structure to those which do not.

Allow the final presentation to be generated at that point in the
delivery path at which software exists that can best satisfy the
user's needs. Specifically this means in some cases that the
presentational form can best be generated on the author's server, by a
proxy, or by the user agent and that as content negotiation
technologies improve the choice between these options will become more
automated.

Of course the countervailing consideration is, inevitably, user agent
support, which will change in the course of time. Thus we can't freeze
any particular "user agent baseline" into our guidelines, as it will
soon be out of date, and in any event, developers shouldn't be
penalized for using a newer, less supported but superior (from an
accessibility point of view) technology by not being able to claim any
level of conformance to accessibility guidelines.

Cynthia's proposed solution might be of help here. Modifying it
slightly, this proposal would be approximately as follows:

1. The content developer should define (or adopt from us) a user agent
   support baseline, e.g., HTML 4.01 + CSS level 1, with allowance for
   known implementation issues - or whatever it may be. This baseline
   should be documented by the developer and referred to from the
   conformance claim (especially a metadata conformance claim).

2. We would provide suggested baselines determined by whatever evidence we
   can gather regarding assistive technology support, and publish them
   periodically.

3. In the techniques documents we would have a consistent labeling
   scheme indicating, for each technique, the earliest version of the relevant
   technology in which the necessary features are available, with some
   comment as to known implementation status and any issues that
   developers should consider. Developers could then choose techniques
   according to whatever user agent baseline has been set.

4. Ideally, there should be tools for managing this process - that is,
   filtering techniques by technology version and/or implementation
   status.

5. The implementation status categories might be roughly as follows:

a. not known to be implemented

b. implemented, but not supported by assistive technologies and/or
user agents typically used by people with disabilities

c. Implemented by some user agents and, where applicable, assistive
technologies, but not yet widely available.

Internationalization/localization category:

a. Not yet internationalized/localized

b. Internationalized/localized by user agents

c. Internationalized/localized by user agents, including some user
agents/assistive technologies significant to people with disabilities.

d. Internationalized/localized to a significant extent, and widely
supported by implementations.


Perhaps this is somewhat too complex and could be simplified a little
- maybe a scale from 1-10 with points added or subtracted based on
various factors (degree of user agent/assistive technology support,
whether known implementation problems/incompatibilities exist, whether
internationalized/localized versions are available), with fuller
details included for those who want them.


Disclaimer: I am not necessarily committed to any of the above ideas;
they are just thoughts that might be useful in the resolution of the
relevant issues.

Received on Sunday, 5 May 2002 07:42:33 UTC