- From: Gregg Vanderheiden <gv@trace.wisc.edu>
- Date: Mon, 13 Mar 2006 12:15:06 -0600
- To: "'John M Slatin'" <john_slatin@austin.utexas.edu>, <w3c-wai-gl@w3.org>
- Message-ID: <008201c646ca$0ef1e5f0$ee8cfea9@NC6000BAK>
Hi John
- I personally have no problem putting 'at least" back in. I think we had
consensed at a previous teleconf call to remove the 'at least' from the old
one - but I like it - and since it doesn't require more - I would like to
put it in here.
- re the hurricane, there are a thousand datapoints all being presented
visually and simultaneously and changing from one moment to the next. If
they were all described it would be so much data as to be incomprehensible.
Now different conclusions or observations can be drawn from it - but they
are not what is being presented. They may be in the text already and the
data are being presented to back it up. Hmmmm. Sort of like an
orchestra. Describe what an orchestra sounds like in real time. Or even
delayed. You can't present the rich multifaceted sounds. You can describe
parts of it - but we don't and can't ask for a text equivalent of it. Now
think of something that isn't music but is that complex a sound. Maybe
listening to a complex machine or multifrequency sound imaging. What is
the text equivalent.
I do like the "at least' idea. I would like to see people write up what
they can. But I don't think we can ask at level 1 that they provide a text
alternative. I don't know how to do it.
Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.
Professor - Ind. Engr. & BioMed Engr.
Director - Trace R & D Center
University of Wisconsin-Madison
The Player for my DSS sound file is at http://tinyurl.com/dho6b
<http://tinyurl.com/cmfd9>
_____
From: John M Slatin [mailto:john_slatin@austin.utexas.edu]
Sent: Monday, March 13, 2006 10:28 AM
To: Gregg Vanderheiden; w3c-wai-gl@w3.org
Subject: RE: Reworking 1.1
Thanks, Gregg. Very interesting proposal. But it worries me a little.
You wrote:
<blockquote>
4) There is a visual representation of a hurricane showing the
direction of air follow throughout. Where an obstruction is encountered
the flow
directions distort all around the obstruction. This is presentation of
information with non-text content - but it is not possible to present this
in
a text alternative. We have no exception for this. Only for functional
non-text content.
</blockquote>
First: if you're right in saying that it "is not possible" for a text
alternative to present the same information about turbulence as the visual
representation does, then the revised SC you proposed doesn't require even
an *attempt* to describe what's happening in the visual representation-- the
only thing required would be to "identify the purpose of" the non-text
content ("Visual representation of turbulent flow in a hurricane," for
example. That's much weaker than our current wording, I think, and would be
a serious problem for me. (More below.)
I have a similar concern about the bullet that includes non-text content
"intended primarily to create a sensory experience": the proposed wording no
longer even hints at the possibility of going beyond a "descriptive label."
I would like to restore the phrase "at least" here. The SC could still be
satisfied using just a descriptive label, but it would encourage doing more.
Back to the example about the hurricane:
I don't actually agree with the assertion that "it is not possible to
present this [turbulence created when moving air encounters an obstacle] in
a text alternative." I agree that it is not possible to introduce
hurricane-like turbulence into the text itself (this is one of the reasons I
argued that we should use "text alternative" instead of WCAG 1.0's "text
equivalent"). But it is certainly possible to describe in text what is
happening within the visual representation, whether the representation is
static or dynamic. The more I think about it the more I realize that the
visual representation in your example is not a case of "real" turbulence; it
is only a *representation* of turbulence, and all the text alternative has
to do is provide a *textual representation* of the visual content-- not a
representation of the hurricane. It doesn't have to *be* turbulent any more
than the visual representation has to *be* turbulent.
If the visual representation is the output of a simulation, then I agree
that it wouldn't make sense to expect the simulation to output text rather
than dynamically generating a visual representation. But the visuals
produced by the simulation can be described, even if the description can't
be continually updated as the simulation continues to run.
(So now I'm not sure whether I'm arguing against the proposed wording, or
just making the case that this particular example *can* have and thus would
require description rather than mere identification.
This is really important. One of my graduate students just sent me research
showing that *one hundred percent (100%)( of scientific articles published
between 1976-2000 included at least one visual illustration of some sort.
John
"Good design is accessible design."
John Slatin, Ph.D.
Director, Accessibility Institute
University of Texas at Austin
FAC 248C
1 University Station G9600
Austin, TX 78712
ph 512-495-4288, f 512-495-4524
email jslatin@mail.utexas.edu
web <http://www.utexas.edu/research/accessibility/>
http://www.utexas.edu/research/accessibility/
_____
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf
Of Gregg Vanderheiden
Sent: Monday, March 13, 2006 2:20 am
To: w3c-wai-gl@w3.org
Subject: Reworking 1.1
In closing out the issues I found that there were several 1.1 issues that we
did not address yet
1) All CAPTCHA except logic puzzles are currently outlawed by our
guidelines. Logic puzzles are a problem for cognitive and also for CAPTCHA
developers since you can't generate a large enough set that they can't be
cataloged and handled by robots.
2) Sensory tests (visual test or exercises, auditory tests or
exercises) (e.g. colorblindness tests)
3) Spelling test (do you need to caption or provide transcripts for
audio files used in spelling tests?)
4) There is a visual representation of a hurricane showing the
direction of air follow throughout. Where an obstruction is encountered
the flow directions distort all around the obstruction. This is
presentation of information with non-text content - but it is not possible
to present this in a text alternative. We have no exception for this. Only
for functional non-text content.
5) Some non-text content is both informational and functional.
6) We currently have an SC under "Guideline 1.1 Provide text
alternatives for all non-text content." that doesn't involve providing
alternate text.
To address all these I have reworked the L1 SC to cover these issues.
Guideline 1.1 Provide text alternatives for all non-text content.
1.1.1 For all non-text content, one of the following is true:
* If non-text content presents information or responds to user
input, text alternatives serve the same purpose and present the same
information as the non-text content. If that is not possible, text
alternatives identify the purpose of the non-text content;
* If non-text content is multimedia, live audio-only, live
video-only, a sensory-stimulus specific test or exercise, or primarily
intended to convey a sensory experience, text alternatives identify the
non-text content with a descriptive label. (For multimedia -see also,
Guideline 1.2)
* If non-text content is an automated Turing test, different forms
are provided to accommodate multiple disabilities.
* If non-text content is purely decorative or used solely for visual
positioning, it is implemented such that it can be ignored by assistive
technology.
It is all in one SC because two of the four cannot stand as separate SC
under the guildeline.
For the reasons for the rest of the changes - see the 6 issues above.
I will put this out to survey in a bit.
If this looks ok - I will rework the How to Meet docs.
(this also removes a large amount of redundancy from the HTM docs
They will now fall into one - and the parallel presentation makes it much
easier to explain what to do.
Gregg
------------------------
Gregg C Vanderheiden Ph.D.
Professor - Depts of Ind. Engr. & BioMed Engr.
Director - Trace R & D Center
University of Wisconsin-Madison
< <http://trace.wisc.edu/> http://trace.wisc.edu/> FAX 608/262-8848
For a list of our list discussions <http://trace.wisc.edu/lists/>
http://trace.wisc.edu/lists/
The Player for my DSS sound file is at <http://tinyurl.com/dho6b>
http://tinyurl.com/dho6b
<http://trace.wisc.edu:8080/mailman/listinfo/>
Received on Monday, 13 March 2006 18:15:25 UTC