RE: User agent capabilities [was Agenda

Yep.

All these things are currently possible. I figure that we can get closer to
the endgame with these issues still open.

The value is that we are giving clear answers to the question "how do I make
this page accessible..." although we are ducking for now the question of
"what software do people actually have, and how much of that is their own
fault for not upgrading, or for working for a company that has a policy of
not upgrading, or ..." which in the long run I think is an important
question, but complex, and varies considerably in different parts of the
world.

Charles

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

  There's another alternative.  We could write documents that would allow
  people to make claims that look like this:

  <quote>
  This site is double A compliant    _with_respect_to_    the "target set" of
  browsers having the following characteristics:

       1. display LONGDESC
       2. Do not handle scripts
       3.  etc.
  </quote>

  To make such claims possible, we'd write checkpoints or normative
  techniques that say things like

       always provide ALT text
       if the target set of browsers doesn't support LONGDESC, use D Link
       if the target set of browsers ... etc

  In other words,  a site isn't simply "double A compliant".  It's compliant
  with respect to a target set of browsers, and the checkpoints (or normative
  techniques, I'm not concerned with what what we call it) each become
  conditional on the "target set" of browsers.

  We may then choose or not to define one or more standard "target sets"
  of  browsers.  These "standard sets" may well be non-normative.  This would
  push the non-stable stuff (state of the browser world) into documents that
  don't have to go thru rec.

  Len

  At 01:54 PM 12/8/00 -0500, Charles McCathieNevile wrote:
  >I agree that I think we have an open issue.
  >
  >Currently, conformance is based on teh checkpoints. I woulod be leaving this
  >stuff in the techniques. The missing link is whether we are assuming a
  >browser set that supports longdesc. The other missing bit is that i should
  >have been more explicit in saying that this technique will satisfy the
  >checkpoint, for the given set of technologies.
  >
  >So we document what we think is the state of play when we get to Rec, and
  >that
  >a)allows people to use the giudelines for general accessibility
  >b)allows people who are only looking for a particular user segment to know
  >what bits they still need to use and what bits of accessibility they are just
  >going to ignore.
  >
  >Or we decide that techniques are normative (but that means we have to send
  >them through the Rec process too)
  >
  >chaals
  >
  >On Fri, 8 Dec 2000, Cynthia Shelly wrote:
  >
  >   have we decided that the techniques are non-normative?  I think we still
  >   have an open issue on whether the technology-specific parts of the
  >   guidelines are non-normative "techniques" or normative "technology-specific
  >   checkpoints".  I, for one, strongly believe that the technical sections
  > need
  >   to be normative.
  >
  >    -----Original Message-----
  >   From: Leonard R. Kasday [mailto:kasday@acm.org]
  >   Sent: Friday, December 08, 2000 10:37 AM
  >   To: Charles McCathieNevile
  >   Cc: w3c-wai-gl@w3.org
  >   Subject: Re: User agent capabilities [was Agenda
  >
  >
  >
  >   Charles,
  >
  >   There's still something I don't get here.  The WCAG draft
  >   http://www.w3.org/WAI/GL/WCAG20/ <http://www.w3.org/WAI/GL/WCAG20/>   still
  >   says that people will be able to use it to judge conformance.
  >
  >   Now suppose I have a web page that has LONGDESC but no D links.  The way
  >   you've described it,  I don't see how I can figure out the conformance from
  >   the guidelines because LONGDESC isn't even in the guidelines.  It's in the
  >   techniques which are not normative.
  >
  >   And even if we brought your statement into the guidelines, viz
  >   quote
  >
  >   HTML: Use the longdesc attribute to link to a full description. This can be
  >
  >   provided in the same page. This requires browsers that support longdesc, so
  >
  >   does not work for (almost anything available today, but we probably want to
  >
  >   have a way of saying this that future proffs us a bit). Alternatively, link
  >
  >   a letter 'D' immediately after the object being described to the
  >   description.
  >
  >   This works in anything. (because somewhere we have stated that we expect
  >
  >   links to work in all browsers...)"
  >
  >   unquote
  >
  >   that doesn't say whether D is required.
  >
  >   So how do we measure conformance?
  >
  >   Len
  >
  >
  >
  >
  >
  >   At 11:28 AM 12/8/00 -0500, Charles McCathieNevile wrote:
  >
  >
  >   No, I am after something a bit different.
  >
  >   We say in the guidelines "provide functional equivalents that can be
  > used in
  >   different circumstances - by people who are deaf, blind, unable to read
  > huge
  >   slabs of text, ..."
  >
  >   Then in the checkpoints we say "provide text equivalents for all non-text
  >   elements".
  >
  >   (then in the glossary we say that non-text elements are ones that cannot be
  >   rendered as text - they do include ASCII art but may not include accessibly
  >   designed SVG images...)
  >
  >   Then in the techniques we say:
  >   "HTML: Use the alt attribute to provide a short functional equivalent. This
  >   needs to allow the user to scan quickly through the page, so information
  >   that
  >   is more than a sentence or so should normally be a long description (see
  >   below).
  >
  >   And somewhere further on (or maybe this is a checkpoint)...
  >
  >   A long description must be provided for complex information presented
  > in the
  >   a non-text element.
  >
  >   HTML: Use the longdesc attribute to link to a full description. This can be
  >   provided in the same page. This requires browsers that support longdesc, so
  >   does not work for (almost anything available today, but we probably want to
  >   have a way of saying this that future proffs us a bit). Alternatively, link
  >   a letter 'D' immediately after the object being described to the
  >   description.
  >   This works in anything. (because somewhere we have stated that we expect
  >   links to work in all browsers...)"
  >
  >   Does that make it clearer? I guess we will need to go a  few times
  > around to
  >   get this sorted.
  >
  >   Cheers
  >
  >   Charles
  >
  >
  >   On Fri, 8 Dec 2000, Leonard R. Kasday wrote:
  >
  >     Charles,
  >
  >     Let me check if I understand what you mean with an example.
  >
  >     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..."
  >
  >     Now, for purposes of discussion, please put aside for now whether we
  >     actually want to omit LONGDESC from the baseline, and also please
  > also put
  >     aside whether the rest of this example is worded optimally or complete.
  >
  >     I want to ask just this narrower question: is this the type of Guideline
  >     document you are advocating?
  >
  >     Len
  >
  >     p.s.
  >
  >     I'd personally support that sort of document.  Then the only issue
  > will be
  >     whether WAI will want to say anything anywhere about what sets of user
  >     agent capabilities might be assumed and how the guidelines filter thru
  >     those assumptions.
  >
  >
  >     At 03:36 PM 12/7/00 -0500, Charles McCathieNevile wrote:
  >     >Actually, I think that it is a much lower priority work item for us to
  >   create
  >     >profiles of WCAG for different constraints provided by certain
  >   organisations.
  >     >It seems to me much more the job of whoever is placing the
  > constraints to
  >     >demonstrate tht for their purposes a particular requirement of universal
  >     >accessibility is not relevant.
  >     >
  >     >For example, we could in principle assume that everyone in the world
  > uses
  >     >iCab (the japanese version) with the speech and keyboard control systems
  >     >native to the Macintosh, and work out what are the requirements that we
  >   can
  >     >ignore, or can list the problems that occur, based on that.
  > Essentially I
  >     >think we have a critical requirement to make one such decision: What is
  >   the
  >     >baseline requirements for a User Agent?
  >     >
  >     >Beyond this, we should be able to name the problems that each checkpoint
  >     >addresses. But there are limits to how far we can track each tool
  > set and
  >     >which checkpoints are relevant to it.
  >     >
  >     >(For me this is in the same basket as setting policy. i.e. it belongs to
  >   the
  >     >people who are doing it.)
  >     >
  >     >Charles.
  >     >
  >     >On Thu, 7 Dec 2000, Leonard R. Kasday wrote:
  >     >
  >     >   Another user agent issue I face is that it depends on the user group.
  >     >
  >     >   For example, if a business or agency provides its employess with user
  >     >   agents having certain capabilities, it doesn't have to worry about
  >   older
  >     >   user agents, for pages only used by those employees.   In other
  > words,
  >   we
  >     >   can assume more for intranet pages than for internet pages.  (I'm
  >   dealing
  >     >   with this as we speak BTW).
  >     >
  >     >   I think this is yet another argument for having a document (or
  > section
  >   of a
  >     >   document) that deals only with accessibility as a function of user
  >   agent,
  >     >   and omits "requirements" or "compliance".
  >     >
  >     >   Requirements for compliance should be in a different document (or
  >   document
  >     >   section), which takes into account the user population (e.g. public
  >   vs.
  >     >   employee) and factors against which there may be a tradeoff with
  >     >   accessibility (e.g. "essential purpose" ).
  >     >
  >     >   I think this will save time in the long run, since we'll otherwise
  >   have
  >     >   perpetual arguments due to different people having different
  >   situations in
  >     >   mind.
  >     >
  >     >   Len
  >     >
  >
  >     --
  >     Leonard R. Kasday, Ph.D.
  >     Institute on Disabilities/UAP and Dept. of Electrical Engineering at
  >   Temple
  >     University
  >     (215) 204-2247 (voice)                 (800) 750-7428 (TTY)
  >     http://astro.temple.edu/~kasday
  >   <http://astro.temple.edu/~kasday%A0%A0%A0%A0%A0%A0%A0%A0>
  >   mailto:kasday@acm.org <mailto:kasday@acm.org>
  >
  >     Chair, W3C Web Accessibility Initiative Evaluation and Repair Tools Group
  >     http://www.w3.org/WAI/ER/IG/ <http://www.w3.org/WAI/ER/IG/>
  >
  >     The WAVE web page accessibility evaluation assistant:
  >     http://www.temple.edu/inst_disabilities/piat/wave/
  >   <http://www.temple.edu/inst_disabilities/piat/wave/>
  >
  >
  >
  >
  >--
  >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

  --
  Leonard R. Kasday, Ph.D.
  Institute on Disabilities/UAP and Dept. of Electrical Engineering at Temple
  University
  (215) 204-2247 (voice)                 (800) 750-7428 (TTY)
  http://astro.temple.edu/~kasday         mailto:kasday@acm.org

  Chair, W3C Web Accessibility Initiative Evaluation and Repair Tools Group
  http://www.w3.org/WAI/ER/IG/

  The WAVE web page accessibility evaluation assistant:
  http://www.temple.edu/inst_disabilities/piat/wave/


-- 
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 14:35:01 UTC