- From: Maciej Stachowiak <mjs@apple.com>
- Date: Mon, 12 May 2008 14:18:42 -0700
- To: John Foliot <foliot@wats.ca>
- Cc: '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>
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:32 UTC