ALT issue redux

With the arrival of a published working draft of HTML5
http://www.w3.org/TR/2008/WD-html5-20080122

.. it is time for us to return to the request for input we got
regarding when and how to use @alt.  See for example

http://lists.w3.org/Archives/Public/wai-xtech/2007Nov/thread.html#msg70

** executive summary

* on the process

I would like PFWG to address the full list of "how to populate @alt"  
statements
and not just the one mentioned in the request we got.

There are more subsections that need help than just the one, and
more kinds of people with disabilities affected than just the
eyes-free.

There are also more ways to skin the "deliver accessible
content" cat than format specifications.  We need effective
action across the board.  And to get that we should retain
some flexibility about which tool or document says what about this
kind of a discrepancy.

* on the product

The relevant section of the stable draft of HTML5 is at
http://www.w3.org/TR/2008/WD-html5-20080122/#alt

Clearly the preference from the WAI community is that in the narrow  
case described as
<q>A key part of the content that doesn't have an obvious textual  
alternative</q>
..  the absense of an @alt should be a violation of the format  
specification.

This defect should not be passed over in the format specification with
a "s**t happens" shrug.

Other cases where there is not text in @alt because of accompanying
text to which the image is supplemental require beefing up so that
the relationship between the image and the text is machine-recognizable.

** more detail

* more issues than "required @alt for critical content."

I am reluctant to send a message to HTML WG that deals only with the  
narrow
issue of the missing ALT in the case

<q>A key part of the content that doesn't have an obvious textual  
alternative</q>

There are several other cases where the instructions in the HTML5 draft
are that the @alt should be empty.  These are similar to putting a null
@alt on an image in an image link when the link @title is desired to be
spoken.

I think that these cases need to be identified by machine-applicable
selectors before the "no @alt" instruction can be acceptable.

In other cases, where an image amplifies some text also in the page,
the relationship of the image to the text must be machine recognizable.
People with reading difficulties need the association to be machine-
recognizable because they may be critically dependent on the image to
grok the words.

* whose error is it?  affirmative action beats un-enforced rules

Given the low level of strict conformance to W3C format specifications
in the Web as she is spoke today, it is not clear how much of a prize
it is to insist that a missing @alt in this case is a format error
vs. just being an accessibility error (which it will be anyway).

http://www.w3.org/2007/11/07-TechPlenAgenda#html

If the format errors are not going to be checked in the content  
development
pipeline, then we are going to have to use policy concern for
accessibility to get content checked anyway.  In that case accessibility
violations with be caught and to the extent that the enforcement is
effective, fixed.  In other words, it is more of a gain to get more
authoring tools to implement ATAG techniques to help authors use
@alt right than to insist the format spec be what says they were wrong
when it's not done right.

We should regard the HTML WG desire to standardize recovery from defects
as a positive step.  Something that we should applaud and work with.

Clearly, the absense of an @alt in the narrow case described above
should not be cause for the browser to reject the whole document, as
is the uncomfortable rule with many XML errors.

If we look more closely at who should respond how at each stage
in the content production and extraction process, and get those
responses tooled up better, we will get more conformance and more
access.

Al

Received on Wednesday, 30 January 2008 15:56:34 UTC