W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > January to March 2002

longish response RE: 3.3 action !

From: Charles McCathieNevile <charles@w3.org>
Date: Sun, 3 Feb 2002 17:30:45 -0500 (EST)
To: Bob Regan <bregan@macromedia.com>
cc: "_W3C-WAI Web Content Access. Guidelines List" <w3c-wai-gl@w3.org>
Message-ID: <Pine.LNX.4.30.0202031700350.5020-100000@tux.w3.org>
my responses throughout.


On Sun, 3 Feb 2002, Bob Regan wrote:

  However, I am wondering if this checkpoint is inherently fraught with
  difficulty. Are assumptions inherent in the success criteria that we must
There are some assumptions underlying the proposed criteria, as with all
criteria. In this case they are assumptions about what makes content easier
to read and understand for people with literacy problems. Some of these are
based on published research, some on simple testing... (Consider the success
criteria for any other checkpoint, and try to determine as many of the
assumptions as possible).
  Are we presuming that each piece of content is instructional in
No, not as far as I am aware. That would be a bad assumption.
  For example, is it possible for a piece of fiction to comply? While the
  language in the checkpoint allows for context, the language of the
  success criteria is much more specific. How can the success criteria be
  communicated to publishers of fiction on the web?
It is possible for fiction to comply. It is possible that not all fiction
will comply. It is unlikely, for example, that a piece of deliberately
complex language, such as that used in Finnegan's Wake by James Joyce, would
be re-edited to be accessible. (Hmmm, maybe that is a bad example, as it is
not accessible to most people I know who have tried to read it).

If we start by assuming that we are producing guidelines that will ensure
that all kinds of content are accessible, we will produce guidelines that
achieve their stated goal, but do not help people access content. If we
produce guidelines for how content can be made accessible we need to
recognise that not all content will be made accessible.

Different people, and different societies, have different standards for
deciding whether or not they will require a particular object, service, etc
to be accessible and how much impact they believe is acceptable. It is a
truism that having to have a ramp at the front of a building makes a big
impact on a design that envisages a pure sweep of 100 small, regular steps
across the entire front of the building. Does this mean that anyone who
cannot climb 100 steps should be made tofind an alternative entrance to the
hospital, in order to preserve the essential integrity of the design? (what
if it was only 5 steps, or 2?) There isn't a universal answer to this kind of
question. But we as a group can say "if you want all people to be able to get
into the hospital, you need to have a smooth entrance from the street, at
least". (We could probably do even better than that - "make the door wide
enough for a large wheelchair, light enough or automatic to allow frail
people to open it, etc...")
  Similarly, I edit an online journal for educators in Portuguese speaking
  countries. The journal articles we published are from established
  scholars whose work frequently is not easily summarized or even
  understood. Is it possible for this journal to comply?
Yes. How well it will comply to  this requirement (and for that matter to any
requirement) depends to some extent on the skills of the scholars you are
working with, and yourself. (Assuming that you are prepared to make this
content accessible, or that the journal decides that is a requirement)
  My more general concern with this checkpoint is that once it is dismissed
  as not feasible, it casts a shadow over the other checkpoints as well.
  This attempt at constructing success criteria, while very accurately
  capturing the goals inherent in the checkpoint also points to the broader
  difficulty with the checkpoint itself.
I agree, except if you are suggesting that the checkpoint is dismissed as
unfeasible, rather than pointing out that if, in a hypothetical situation, it
was dismissed as such then we would have a problem.

Much more important in my opinion, I don't think it is an issue at all
limited to this checkpoint - a quick look at the endless discussions about
what text alternatives should be provided on the Interest Group List shows
that for most checkpoints, we end up relying to some extent on the judgement
and interpretation of an individual, and we can see that until there are lots
of examples of "doing it right", or "doing it wrong" that include
explanations of why they are good or bad, those interpretations and
judgements are likely to lead to widely variant results.

Consider something apparently clear, like "use code validly, according to

I would suggest that the HTML 4.01 specification for the element "samp" is
not itself using the element according to specification.. Although that
document uses HTML better than most documents do. Valid syntax is trivially
straightforward to test. (In most cases). But testing services can disagree,
although most would agree that there is a lot of invalid code produced
automatically for the web by systems designed by experts, in the absence of
even a simple argument that this is to remain compatible with some bug in
software that users haven't been able to have fixed for them.
  I would encourage us to writing a much broader description that points to
  understanding a page's audience and highlights issues for folks with
  cognitive disabilities or else reconsidering the checkpoint altogether.
I think that having broader descriptions, and new attempts at success
criteria, are certainly required before we have enough material (and
examples) to be satisfied. Until that time (which I guess is when we are
ready to publish a last call draft), this and all other checkpoints are under
constant reconsideration unless explicitly declared off limits by the chair.


Received on Sunday, 3 February 2002 17:30:47 UTC

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