W3C home > Mailing lists > Public > public-html@w3.org > May 2008

RE: HTML Action Item 54 - ...draft text for HTML 5 spec to require producers/authors to include @alt on img elements.

From: John Foliot <foliot@wats.ca>
Date: Mon, 12 May 2008 13:23:19 -0700
To: "'Dave Singer'" <singer@apple.com>, <public-html@w3.org>, "'W3C WAI-XTECH'" <wai-xtech@w3.org>, <wai-liaison@w3.org>, "'Dan Connolly'" <connolly@w3.org>, "'Chris Wilson'" <Chris.Wilson@microsoft.com>, "'Michael\(tm\) Smith'" <mike@w3.org>, "'Boris Zbarsky'" <bzbarsky@MIT.EDU>
Message-ID: <012c01c8b46e$04fc8780$413142ab@stanford.edu>

Dave Singer wrote:
> This entire conversation seems to be be in repeating circles.
> Personally, I would like to see a considered answer to the question
> below, and I don't think I have.  Having, in essence, the question or
> disagreement endlessly repeated is making the mailing list tedious to
> follow.  If we've had a helpful answer, can someone repeat it?  If
> we're on track for getting an answer, can we wait for it?  If we
> don't think an answer is possible, then we need to re-frame the
> question.

I think that the answers are pretty clear:

1) retain @alt as mandatory, as recommended by the PFWG / WAI - the group
entrusted to advise on web accessibility issues.

2) the new draft language proposed references WCAG 2 as the W3C resource
regarding accessibility issues and in particular images.  This is in keeping
with W3C charters, and why the HTML WG feels that somehow their collective
wisdom is superior to that of the WAI continues to both confound and
frustrate many.

3) stop writing a spec based upon speculation, opinion and infrequent usage
of screen readers by those who do not use AT on a daily basis.

4) await requested input from PFWG regarding authoring tools, and separate
the lousy state of authoring tools today from the need for an authoring
(markup) language that will serve us into the future.


> 
> "In striving for the best support for accessibility, we would like
> guidance on what to say in a specification on the use of the alt
> attribute for an image when there is no reasonable alt text known.

   <snip>

> Do you have guidance on what to say in a specification on the
> use of the alt attribute for an image when there is no reasonable alt
> text known?"

Many have already shown that this is a false premise - there is *always*
something that we (programmatically) know about an image; the better
question is what should be reported as a default value when there is no
author input.  Accessibility advocates do not accept "nothing" as a viable
response.

Robert Burns has actually spent some real time working through this, and
perhaps his thoughts will shed more light.  
See: 
 http://html4all.org/mailman/archives/list_html4all.org/2008-May/000845.html
 http://lists.w3.org/Archives/Public/public-html/2008May/0034.html

If this helps reframe the question, then let's talk about that.  However, in
my opinion this is more of an authoring tool discussion rather than a
mark-up/compliance question. 


@Maciej Stachowiak:
> From my experience it does lead to redundant content using a screen
> reader to read the whole document or read by paragraph. Are you
> telling me no screen reader user does this? Or does degrading the
> experience of doing this not matter for some reason? Have you
> personally tried either of the alternatives in any form of assistive
> technology, or watched anyone do so? I understand that trying it
> myself is not much, but it's more than nothing. I would like to hear
> what testing you have done on this issue, that you are so glibly
> dismissive of mine.

Maciej, with due respect, there have been many daily users of adaptive
technology that have all voiced their disagreement with making @alt
optional. Some have agreed that the current state is less than perfect, but
none that I know of have agreed with the proposed solution.  Their
collective voices have been routinely and often rudely dismissed.  While it
is appreciated that the HTMLWG is striving for a better user-experience, if
you refuse to listen to those same end users then all is for nothing.
Firing up Voiceover and "testing" out things is akin to going to the local
mall and playing with a "fighter-jet" video game, and then thinking you
understand how to fly a fighter jet.  I don't mean to be rude, but the
analogy is correct.

Have *you* spent more than a few minutes with a daily AT user?  One thing
that surprises many is the speed with which these daily users listen to the
content being read, as well as the end user's ability to "filter" auditory
information that you would painstakingly listen to verbatim.  It's good that
you are thinking that redundantly redundant text is redundant, but is it
really the job of the spec to fix that?  And when the experts all agree that
the proposed solution of optional @alt is not a workable solution, why can't
you accept that answer?  

@Boris Zbarsky
> 
> I feel that it would help me, as an implementor, to understand the
> reasons for the WCAG 2.0 decisions, not just read the final product...
>

The short answer is that @alt serves more than just screen readers, as
Steven took time to explain in his original response.  Have you actually
spent any time with WCAG2? The following section is pretty thorough:
http://www.w3.org/TR/WCAG20/#text-equiv 


JF
Received on Monday, 12 May 2008 20:24:23 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:55 UTC