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

Maciej Stachowiak wrote:
> 
> 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.

David Singer's point about the round and round notwithstanding...

I have read all of the points in all of the threads... It is not like I've
just dropped in to this discussion.  In the use-case where there is no
author supplied alternative text, then any number of other alternative
pieces of metadata might suffice.  Which piece is better than another might
be open for discussion, but providing *nothing* is not, nor should not, be
considered one of the options.


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

The point of the issue is that @alt is for more than just screen readers.
*You* are concerned that providing redundant text is detrimental to the
user-experience, and *you* appear to continue to support the idea that @alt
being optional some of the times is a valid assertion.  I disagree, although
appreciate your question regarding redundancy.

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

Yes, I also hope that they too turn off their monitor, and have it read
aloud at 2 to 3 times faster than a normal speaking voice.  Oh, and have
memorized that cheat sheet too... Finally, they should also remember that
just like different browsers, different screen reading technologies can be
configured differently based upon user requirements, and that given
identical scenarios may actually perform differently. (think Acid2 as an
point of reference)

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

Correct me if I am wrong, but the emergent HTML5 spec is about how to mark
up content so that it can be rendered in a "user agent" normally thought of
as a browser.  Where does it "explicitly" require redundant text?  You are
suspecting that this may be a possible outcome, but I don't see anywhere
where it says "...and the user agent must explicitly provide redundant
text".

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

First, I do not claim to be said expert (although I will unabashedly state
that I probably have more experience in this area than you do). However
since the W3C has decided that the PFWG and WAI should be the go-to
'experts' in the area of web accessibility, and that WCAG 1 (and 2) emerged
via consensus, what better pedigree do you require?  They have reported back
to the HTML WG that maintaining @alt as a mandatory requirement should
remain, and yet that group (your group?) continue to question us/them and
argue for your point.

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

Others have pointed to the relevant records at WAI regarding images and
WCAG2, which is what the current revised draft text references.  Can we see
the same kind of "evidence" that supports the contrary claims?  We've been
asking for that for a very long time now, and still we've yet to see it.
Your considered concerns aside, where does it state (via, but not limited
to, a user study) that there is a problem?  Where does it show other
alternatives considered besides making @alt optional, complete with pros and
cons, etc.  Outside of Ian Hickson claiming last month that he had caught up
on his email reading and had not seen any further evidence to refute the new
proposal (and attempting to close the issue), where is the proof for the
other side of the discussion?

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

As has also been pointed out, there is *always* some useful information
attached to an image.  The question is not whether or not @alt should be
mandatory, but rather what is an acceptable default value when the content
author does not provide something.  I pointed to Robert Burns' thoughts on
that topic, specific to a photo sharing site.  

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

It can be, and often is.  So is having a news (portal) page with 7 different
links that all have the link text of "More...".  Shall we write the spec to
forbid the using the same link text more than once on the same document, so
as not to annoy users?

> 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),

It is a problem.  The proposed solution of making @alt optional as a means
of fixing this problem is not an acceptable solution.  Reading meaningless
file names is a problem too, which is what would generally happen with
today's screen reading technology if @alt is omitted.  In the absence of any
real solution, most would agree better the devil we know than the devil we
don't.

> or whether
> alternatives have been considered that serve the required use cases
> without creating this problem.

Some have, yes.  See Robert Burns' thoughts.  In an email* now some 2 weeks
old, I suggested that if *any* method of /directly linking/ text to an image
was present then perhaps relaxing a mandatory @alt could be envisioned.  I
also suggested in the same email however that if there was no text
alternative available in any fashion, that the image be non-conformant and
simply not render on screen.  Harsh yes, but that is essentially what would
be given to some users through ignorance, ineptitude or by deliberate
exclusion.  I believe I said "give them more rope..."
[* http://lists.w3.org/Archives/Public/wai-xtech/2008Apr/0393.html]

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

This is an authoring issue, just as having 7 links to "More..." is an
authoring issue.  It is not nor should it be the goal of a markup
specification to make value judgments of any subjective nature.

JF

Received on Monday, 12 May 2008 22:46:13 UTC