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

Re: User agent capabilities [was Agenda

From: Jason White <jasonw@ariel.ucs.unimelb.edu.au>
Date: Sat, 9 Dec 2000 12:00:01 +1100 (EST)
To: Web Content Accessibility Guidelines <w3c-wai-gl@w3.org>
Message-ID: <Pine.SOL.4.10.10012091139070.14277-100000@ariel.ucs.unimelb.edu.au>

On Fri, 8 Dec 2000, Leonard R. Kasday wrote:

> Take LONGDESC for example.
> and consider a WCAG that
> 1. omitted LONGDESC from the baseline requirement
> 2. said "to accommodate users with user agents that support LONGDESC it is 
> sufficient to use that that attribute to give a more detailed description"
> 3. also said  "to accommodate users with agents that don't support 
> LONGDESC, use a "D link" as follows etc..."
Part 1 of the above is satisfied by checkpoint 1.1 in the current WCAG 2.0
draft. Parts 2 and 3 would be covered by the HTML/XHTML/SMIL techniques
(I.E., the techniques corresponding to those formats in which Longdesc is
defined). The fundamental policy here is that the format-specific
requirements be provided in the techniques and not in the guidelines.

My understanding of the resolution achieved at yesterday's meeting is as

1. Techniques would be provided both for user agents which do, and user
agents which do not, support specific protocol or markup language features
(the LONGDESC attribute in this example).

2. These alternatives would be clearly documented as such, and the issue
of user agent support for the particular feature (e.g., LONGDESC) would be
made explicit in the techniques.

I would also suggest, though this wasn't discussed at yesterday's meeting,
that we add informative comments regarding implementation of each feature
by user agents/adaptive technologies. Perhaps we should establish standard
categories with which to describe the current implementation status, such
as the following (and these are only examples):
a. Not known to have been implemented;
b. Known to have one implementation.
c. Known to have multiple, consistent implementations.
d. Known to have multiple implementations, subject to consistency problems
(i.e., incompatible implementations)
e. Known to be incompatible with assistive technologies

If the techniques were loaded into a data base, one could then restrict
the search by implementation category. Dates could even be associated with
the designations, specifying for example that multiple implementations
were in existence as of a particular date (for example June 1997 or
whatever it may be). Then, the content developer could decide to include
all features which have been implemented for a year, two years, or however
long he or she thought reasonable.

This kind of scheme does not capture all of the complexity which Charles
has mentioned, but a workable solution could perhaps be developed along
these lines.
Received on Friday, 8 December 2000 20:00:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 16 January 2018 15:33:35 UTC