Re: User agent capabilities [was Agenda

I like the scheme idea. Except that I would look at doing it in terms of
collecting known implementations and marking them as "rare (e.g. only
available for a couple of Operating System", "normal (e.g. available on half
a dozen different platforms)" and "conflicting (e.g. interoperability problem
with a standards-conformant implementation)" and note what languages they
work in. Then we can just deduce the data for a given date...

Charles

On Sat, 9 Dec 2000, Jason White wrote:



  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
  follows:

  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.



-- 
Charles McCathieNevile    mailto:charles@w3.org    phone: +61 (0) 409 134 136
W3C Web Accessibility Initiative                      http://www.w3.org/WAI
Location: I-cubed, 110 Victoria Street, Carlton VIC 3053, Australia
September - November 2000:
W3C INRIA, 2004 Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, France

Received on Friday, 8 December 2000 20:05:23 UTC