- From: Al Gilman <Alfred.S.Gilman@IEEE.org>
- Date: Wed, 30 Jan 2008 10:56:14 -0500
- To: wai-xtech@w3.org
- Cc: Tim Boland <frederick.boland@nist.gov>, Becky Gibson <gibsonb@us.ibm.com>
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