Re: More on 3.4

I want to highlight that in the 31 July draft, the non-text content for 
text does not have to be included inline, it can be linked to.  Also, note 
that I included a quote from "human performance engineering" as a warning 
that use of non-text content should be used well.  If there is too much or 
if it is poorly designed, it could be overwhelming.  It could *decrease* 
the readability of the content.

Every single success criteria has the option to link to something.  This is 
the primary difference from my proposal that I sent to the list and the 
text that ended up in the 31 July 2001 draft.

This is still probably flawed, as paul has said it is not an exhaustive 
list. However, I think it addresses some of the concerns Matt is raising 
about the author changing their content in order to conform.

It  also parallels the "annotate complex info" checkpoint.  You can point 
to summaries or simpler information.

Note that "pointing to" is probably not the best term since this could be 
accomplished through metadata.  Instead perhaps we should just say "associate"?

Therefore, please stop discussing the proposal for 3.4 that I sent to the 
list and instead focus on what is in the current draft.

Thank you,
--wendy

At 08:36 PM 7/31/01 , Matt May wrote:
>----- Original Message -----
>From: "Anne Pemberton" <apembert@erols.com>
> >          It is not only in guideline 3.4 in which we presume to suggest to
> > the author of a page that his/her horizons be expanded .... we do this
> > throughout the guidelines.
>
>The 1.0 guidelines do no such thing. In the case of alt text and
>synchronized scripts, all that happens is that shortcomings of _technology_
>are overcome. WCAG 1 asks authors to use their eyes and ears to take down
>technical barriers to those who can't use their eyes or ears. All of WCAG 1,
>save 14.1 (clear and simple language), boils down to:
>1) use the technology appropriately; and
>2) where the technology can't make itself accessible, do it yourself.
>
>This includes 14.2, the predecessor of 3.4:
>14.2 Supplement text with graphic or auditory presentations where they will
>facilitate comprehension of the page. [Priority 3]
>
>I honestly don't see why anything more needs to be said, or why this needs
>to be tied to some metric for words to pictures, as has been suggested.
>Authors need to be reminded that this is a consideration to be made with
>content, not ordered to change how they produce it, or given some number
>they can interpret as being satisfactory. I see the current 3.4 lulling
>authors into a false sense of security with "success criteria" that don't
>lead to more comprehensible sites. It's not that easy.
>
>WCAG 1 tells people what to do with their message, without necessarily
>changing its format. The current 3.4 requires a direct change in content
>itself, which is much more invasive and bound to be ignored, even where it
>is actually feasible (which my experience tells me is not often). I think
>WCAG 1 got it right.
>
> > An author who intended content to be a graphic
> > is required to expand that concept to include an alt text and sometimes a
> > long description. Do we ask if the author has the skills or tools to do
>so?
> > No, we just say do it ....
>
>We do assume that the author has the skills and tools to make a site
>accessible. Every rule in 1.0 can be implemented for HTML and CSS using the
>same tools and skills the author used to create the site. And authors should
>be able to interpret the images down to alt text using their knowledge of
>both the content and context of the image (that is, we _already_ are
>depending on the author's knowledge of his or her content to make things
>accessible). What they can't do, reliably, is learn visual communication at
>the drop of a hat.
>
>Which introduces another problem that hasn't as yet been asked: if graphical
>representations are required in a document to make them "accessible", does
>that not preclude nearly every author who is blind from creating accessible
>documents?
>
>-
>m

--
wendy a chisholm
world wide web consortium
web accessibility initiative
seattle, wa usa
/--

Received on Wednesday, 1 August 2001 13:29:30 UTC