RE: [1.1] Text-equivalents for illustrations?

Not all dividers are used to divide information on an auditory level.
Let's talk about shopping carts for a moment.

Visually I want to separate items in a vertical presentation.  I can do
this by alternating colors or by placing a divider between the items.
This is done to be nice to the visual shopper or simply for aesthetics.
There's no need for an auditory response.

If a divider is meant to divide text on the auditory level as well as
visual then I need to use an <hr>.  This is where two segments of text
are separated to remove the confusion of running together two unrelated
paragraphs.  However, this should be done with CSS so that the text is
far enough separated to remove any possible confusion.

Imagine hearing:

"Mary had a little lamb whose fleece was white as snow. The little lamb
would follow" "rule" (<hr>) "Peter Piper picked a peck of peppers."

The <hr> is heard as "rule", so that now makes it heard as "Mary had a
little lamb whose fleece was white as snow. The little lamb would follow
rule Peter Piper picked a peck of peppers.".

Separation of text in the auditory level is extremely hard and would
require more than just a simple <hr>.  Perhaps <hr title="new section
follows"> would work.

I'd love to review thoughts on this.

Sincerely,
Lee Roberts

-----Original Message-----
From: Gregg Vanderheiden [mailto:gv@trace.wisc.edu] 
Sent: Monday, March 15, 2004 3:23 AM
To: 'Lee Roberts'; 'Yvette P. Hoitink'; w3c-wai-gl@w3.org
Subject: RE: [1.1] Text-equivalents for illustrations?


I agree that it should be done in CSS -- if CSS is used.    But we do
not
require it.

In this case she was just talking about having a dotted line,    and
having
it with null alt text.    My comment was meant to point out that (in the
case I supposed)  the function would not be decorative and it should not
be null text.

You mentioned that since it was a visual technique - no auditory
technique
was needed.   I'm not sure I follow that.  Can you elaborate?     If the
function was to divide text visually,  -- then there would also need to
be
something to divide the text auditorily.   Else the two paragraphs would
run
together -- which they are not supposed to do.   Yes?

 
Gregg

 -- ------------------------------ 
Gregg C Vanderheiden Ph.D. 
Professor - Ind. Engr. & BioMed Engr.
Director - Trace R & D Center 
University of Wisconsin-Madison 


-----Original Message-----
From: Lee Roberts [mailto:leeroberts@roserockdesign.com] 
Sent: Sunday, March 14, 2004 9:36 PM
To: 'Gregg Vanderheiden'; 'Yvette P. Hoitink'; w3c-wai-gl@w3.org
Subject: RE: [1.1] Text-equivalents for illustrations?

I have to disagree with this technique.

Quoted from Gregg:
If the function of the dotted line you mentioned is to divide two blocks
of text -- then it does need an alt text and the alt text should be
"divider
line"  or some such.   It should not describe what the line looks like
('e.g. dotted line") but rather its function.

This should be a CSS technique and be a border set as dashed.

Dividers are for visual presentations.  I don't see a reason for them to
be in an aural presentation.  If it needs to be in an aural presentation
it should be an <hr>.

Thanks,
Lee Roberts

-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On
Behalf Of Gregg Vanderheiden
Sent: Sunday, March 14, 2004 9:18 PM
To: 'Yvette P. Hoitink'; w3c-wai-gl@w3.org
Subject: RE: [1.1] Text-equivalents for illustrations?





Good comments.

Here are some random musings as I wait for a delayed plane

NOTE: The following are just some comments from me -- not in any way an
official finding of the group.
  
I think we again have to go back to function.

As I understand it... 

If the function of the dotted line you mentioned is to divide two blocks
of text -- then it does need an alt text and the alt text should be
"divider
line"  or some such.   It should not describe what the line looks like
('e.g. dotted line") but rather its function.

If a graphic is on the page to confirm to the viewer that they got to
the right page...  and the page already has a title -- then it may not
have an additional function.  But if it is to show how nice a place it
is -- then it does have a function - and that function should be
provided in text. You do not need to describe every little detail in the
picture.  (e.g. if it is a picture of the town you don't have to
describe the number of buildings, what they look like, the street sign,
etc. etc. unless some part of that is
critical to the function of the town.   E.g.  could any other picture of
another part of the town have been used instead.) 

In general I would think the safer thing to do is to provide short alt
text
of pictures rather than decide that they have no function.   It is
rarely
true.     I would ask, why is this picture here.  Could I put any other
random picture here?  If not, why not.   Why is it important to use this
picture vs a random picture.  What is it conveying.


 
Gregg

 -- ------------------------------ 
Gregg C Vanderheiden Ph.D. 
Professor - Ind. Engr. & BioMed Engr.
Director - Trace R & D Center 
University of Wisconsin-Madison 

-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On
Behalf Of Yvette P. Hoitink
Sent: Sunday, March 14, 2004 3:33 PM
To: w3c-wai-gl@w3.org
Subject: [1.1] Text-equivalents for illustrations?


Hello everyone,

I posted a link to the working draft on a Dutch webdesign newsgroup. We
got to talk about the need for a text equivalent for non-text content.
Two extremes are clear: If you illustrate a principle using an image,
you have to provide a text equivalent. If you use an image as a spacer
image to force the layout, it needs a null equivalent (alt="" in HTML).
But what about images that are used as an illustration but could be
described in words?

The case we discussed was the largest image on
http://www.erfgoedoverijssel.nl, a website my company built last year
about the local history of a village called Denekamp. The alt-text for
the largest image currently says "Photograph of the backside of the
Keizer house with the Saint Nicholas church in the background". Both the
Keizer house and the Nicholas church are familiar buildings in Denekamp,
so both the picture and the alt give a 'Denekamp' feeling to the site
for people who are familiar there (which is why these illustrations were
chosen). 

One people in the discussion group said he thought this image should
have a null alt, because adding this text didn't help accessibility
since the function of the image is purely decorative. I disagree because
I do not want to decide for a blind person that he doesn't need or want
this information. Also, people who can't see very well and use
screenreaders can decide based on the alt if they want to take the
trouble to view the image. Giving it a null alt means people without
visual browsers do not know what they're missing. One comment was of the
group was: blind people have already accepted that they can't see the
images, now I need to accept that as well. 

One person in the newsgroup had a nice litmus test to determine whether
you need an alt or a null alt: If the words of the potential text
equivalent appear in the text and are illustrated by the image, a null
alt suffices. If the content of the image is not discussed in the text
you have to wonder what the image is doing there in the first place. The
answer to that question decides whether you need an alt or not. If it is
just an illustration, a null alt is enough.

Bottom line: In WCAG 2 we seem to require text equivalents for
practically anything you can put into words. But does that help
accessibility? I can describe a dashed line in words but that only
annoys people instead of helping them. I think we need to think about
illustrations whose function is purely decorative. I don't think they
fall in the category "Non-text content that is designed to create a
specific sensory experience" so according to the current formulation it
would require a text equivalent. But are we sure we're helping people
when doing that?

Yvette Hoitink
Heritas, Enschede, The Netherlands

Received on Monday, 15 March 2004 08:07:11 UTC