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

Re: User agent capabilities [was Agenda

From: Charles McCathieNevile <charles@w3.org>
Date: Fri, 8 Dec 2000 11:28:16 -0500 (EST)
To: "Leonard R. Kasday" <kasday@acm.org>
cc: <w3c-wai-gl@w3.org>
Message-ID: <Pine.LNX.4.30.0012081120090.14706-100000@tux.w3.org>
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         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 11:28:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:08 GMT