RE: Checkpoint 4.4 Review

Users still have some responsibility for their own tools.  Allow me to
draw a physical-world analogy...

Existing physical-world regulations require that a mobility-impaired
user be able to get into my building in a wheelchair.  They do not
require that he be able to get in *without* one.  

Should every person who needs a wheelchair have one?  Absolutely.  Does
every person who needs a wheelchair have one?  Probably not.  Does that
suck?  You bet.  Is it the responsibility of every building owner to fix
it?  I don't think so.  

It would be inefficient and ineffective for every building-owner to
address this issue. The user (and various agencies that represent him)
has the responsibility to supply the wheelchair, find funding for it,
and maintain it. The building owner's responsibility ends at adding a
ramp, so that once a user has a wheelchair he can access the building.  

It is our job to decide what is the wheelchair and what is the ramp.  

I would like to see this on the agenda for a call (or even the f2f?)
once we have finished with the success criteria.  I will be happy to
write up a proposal to start with.

-----Original Message-----
From: gian@stanleymilford.com.au [mailto:gian@stanleymilford.com.au] 
Sent: Wednesday, February 06, 2002 3:32 PM
To: mcmay@bestkungfu.com; w3c-wai-gl@w3.org
Subject: RE: Checkpoint 4.4 Review

Inflexibility is one thing, but while playing the political game we
can't forget why we are doing this in the first place. In the long run,
if these things are a problem for people with disabilities then we need
to deal with them in the guidelines, otherwise WCAG will turn into just
one more irrelevant document that pays lip service to the real problems
people with disabilities face. 

-----Original Message-----
From: mcmay [mailto:mcmay@bestkungfu.com]
Sent: Thursday, 7 February 2002 10:27 AM
To: w3c-wai-gl
Subject: Re: Checkpoint 4.4 Review


Someone correct me if I'm wrong, but wasn't the appearance of
inflexibility
with respect to technology one of the major complaints about WCAG 1?

A definition this harsh makes WCAG irrelevant, because no one will take
it
seriously. A checkpoint already exists to require that sites be usable
when
technologies aren't available. We don't need to resort to requiring
content
providers to write on stone tablets.

----- Original Message -----
From: <gian@stanleymilford.com.au>
To: <charles@w3.org>; <w3c-wai-gl@w3.org>
Sent: Wednesday, February 06, 2002 3:04 PM
Subject: RE: Checkpoint 4.4 Review


My perspective on all of this has been that the content and
functionality of the site must remain in a baseline browser- HTML only.
No images, no CSS, no plugins, no PDFs, no java, no Flash.

Regardless of how 'widely available' these addins are there will always
be some people not using them (except maybe in 20 years time when ALL
browsers come packaged with Adobe Acrobat and have been for the previous
five years).

People who are blind cannot see images
People who use screen-readers often cannot navigate a flash screen
People without Acrobat cannot read PDFs (I do not believe the PDF
converter is of sufficient capability to render a document readable)
People without Word cannot read doc files
People using Lynx cannot use java
People with vision impairments do not use CSS

The people we aim to serve have trouble with all these addins. We can't
assume anything is available to them.

But I do believe we need to close the issue on baseline capabilities.
And whatever conclusion we come to as a group needs to be very clearly
stated in the guidelines. My feeling is baseline is pure HTML.

Gian


-----Original Message-----
From: charles [mailto:charles@w3.org]
Sent: Wednesday, 6 February 2002 10:26 PM
To: GV
Cc: w3c-wai-gl
Subject: Re: Checkpoint 4.4 Review


comments on Gregg's analysis:

1. We need to determine (close the issue about) what are the expected
baseline capabilities of a browser. HTML? Images? SVG? CSS? ...
This never seems like it will be easy. But until we have done it, I
think we
are not going to be able to finish the guidelines.
I also still believe that the ideal goal would be to agree on how to
decide
when a technology (HTML / PDF / Flash / .doc format / whatever) is
sufficiently widely available, and then to use those criteria to decide
what
things we expect of a browser today.

2. If we had a way of saying "the information presented by a document"
which
was clearly different from "all the things in a document" it would be
helpful.

cheers

chaals

On Wed, 6 Feb 2002, Gregg Vanderheiden wrote:

  1 - I think the checkpoint could be worded more straightforwardly.
  Perhaps

  Checkpoint 4.4 --  Ensure that content is usable with default user
agent
  settings and no plug-ins.

  2 - I don't know how an author can do this since we don't specify
which
  user agent.  Any user agent?  All user agents?

  3 - default for some user agents includes many 'plug in' like
  properties.  Also style sheets are usually turned on.  (See related
  comment in checkpoint text below).

  4 - the success criteria is pretty good,  but should say that all the
  function is preserved.  The word "content" is ambiguous to some.
Maybe
  the phrase "all content and function" would work.

  5 - the success criteria is not the same as the checkpoint.  It
suggests
  that the checkpoint should be

  Checkpoint 4.4   Ensure that all content is readable and all function
  (other than artistic) is preserved when stylistic and scripting
  technologies are not supported or are turned off.

  [The success criteria would then be pretty much the same as the
  checkpoint.  But that isn't bad.]

  6 - Example 2 needs to have some words at the end like: "while
  preserving all content and functionality of the pages".

  Example 3 - the last sentence should be deleted or changed to:  "This
  benefits those with older browsers and new and old assistive
  technologies"





  ==================================================


  Checkpoint 4.4 Ensure that content remains usable when technologies
that
  modify default user agent processing or behavior are turned off or not
  supported.


  Issue: define "default" for purposes of this checkpoint. If "default"
  were taken to mean "a user agent's default rendering", then this would
  defeat the purpose of the checkpoint, because (for many user agents)
the
  default is to apply style sheets, invoke scripts and programmatic
  objects, etc.


  Success criteria


  You will have successfully ensured that content remains usable when
  technologies that modify default user agent processing or behavior are
  turned off or not supported if:

  *   for technologies that associate presentation with structure, the
  content is still usable and readable by the user even if stylistic or
  scripting technologies are not supported or turned off.


  Examples (informative)


  *   Example 1: Metadata.
  A scalable image of the layout of a network uses metadata to label
each
  piece of the network and how they connect to each other. The metadata
  can be used to create a text description of the network.
  *   Example 2: A transformation filter.
  A Web site provides a transformation filter that allows users to
design
  how they will interact with the layout of the content on the site -
with
  or without images, with or without tables, etc.
  *   Example 3: Human resources intranet site.
  The human resources department for a large company provides multiple
  versions of the same content to ensure backwards compatibility with
  older browsers. The IT department is not large enough to update
  everyone's browsers and assistive technologies so many people make do
  with older technologies.


  Benefits (informative)


  In determining the extent to which older technologies should be
  supported, keep in mind that

  *   assistive hardware and software are often slow to adapt to
  technical advances.
  *   for significant groups of users, it may not be possible to
  obtain the latest software or the hardware required to operate it.







  -- ------------------------------
  Gregg C Vanderheiden Ph.D.
  Professor - Human Factors
  Dept of Ind. Engr. - U of Wis.
  Director - Trace R & D Center
  Gv@trace.wisc.edu < <mailto:Gv@trace.wisc.edu>
  mailto:Gv@trace.wisc.edu>, < <http://trace.wisc.edu/>
  http://trace.wisc.edu/>
  FAX 608/262-8848
  For a list of our listserves send "lists" to listproc@trace.wisc.edu <
  <mailto:listproc@trace.wisc.edu> mailto:listproc@trace.wisc.edu>







--
Charles McCathieNevile    http://www.w3.org/People/Charles  phone: +61
409 134 136
W3C Web Accessibility Initiative     http://www.w3.org/WAI    fax: +1
617 258 5999
Location: 21 Mitchell street FOOTSCRAY Vic 3011, Australia
(or W3C INRIA, Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex,
France)

Received on Thursday, 7 February 2002 16:16:13 UTC