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

On May 12, 2008, at 1:23 PM, John Foliot wrote:

>
>
> @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.

This particular point wasn't about making alt optional. It was about  
whether particular markup situations are better handled with empty alt  
or non-empty alt. Please re-read the thread.

> 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.

I think before being dismissive of other's efforts you could read the  
thread and try to understand the actual point at issue here.

I will also add that VoiceOver is not nearly as complicated as a  
fighter jet, even with the screen turned off (which I have tried, but  
I still need a cheat sheet for the keyboard shortcuts). I hope anyone  
out there thinking of trying a screen reader to hear for themselves  
what different kinds of markup do will not be intimidated by this  
inapt analogy.

> 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?

I think it is the job of the spec to not explicitly require redundant  
text, yes.

> 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?

I am personally unwilling to take the word of a self-proclaimed expert  
on any topic without explanation. It does not matter if it is the word  
of an expert on networking, security, graphics, internationalization,  
text layout or indeed accessibility. Decisions in the context of a  
standards body should be made based on public reasons, which means  
explaining one's reasoning so that any reasonable informed person can  
understand (even if not necessarily agree). Examples of valid public  
reasoning would include (but are not limited to) citing a user study,  
explaining what alternatives were considered and why they were  
rejected or presenting pros and cons of different approaches. I do not  
see citation of expert opinion as valid public reasoning.

Incidentally I have not "proposed [a] solution of optional @alt". To  
recapitulate, my comments on the Action Item 54 proposal were:

a) That it does not handle the use case where alternative text is not  
available: a number of solutions have been proposed, including  
allowing alt to be omitted in such cases, having a magical alt value  
(such as a space or asterisk), or requiring a different attribute such  
as noalt or importantimage, possibly in conjunction with an alt value.  
I did not argue for or against any of these, simply noted that the use  
case was not addressed. If this is by design, then I think it should  
be explained why none of the proposed solutions are acceptable. I  
assumed this was obvious from pointing out that the use case is not  
served. (In the earlier rounds of the discussion my personal  
preference for handling this use case was a noalt attribute.)

b) I asked for an explanation for why images that carry the same  
information as surrounding text (adding only a visual aid) should  
carry alt text or description links repeating the same information yet  
again. It seems that this would lead to repetitive text in screen  
readers, which could be annoying. No one has clearly explained why  
this is not a problem ("screen reader users have learned to tune  
things out" is a partial explanation, but no one made that argument  
when it comes to possibly reading meaningless filenames), or whether  
alternatives have been considered that serve the required use cases  
without creating this problem. Note that besides screen reader users,  
users of text-only browsers will also see repeated text. I have  
lifelong experience as a reader of printed text, and in this context I  
can say with some certainty that excess repetition harms the user  
experience.

I hope my comments are now clear and the authors of the Action Item 54  
proposal can address them or not as they see fit. Note that these are  
two separate comments and *neither* of them is a call to make alt  
optional.

Regards,
Maciej

Received on Monday, 12 May 2008 21:19:29 UTC