- From: David Poehlman <david.poehlman@handsontechnologeyes.com>
- Date: Tue, 22 Apr 2008 17:29:13 -0400
- To: "Al Gilman" <Alfred.S.Gilman@IEEE.org>, "W3C WAI-XTECH" <wai-xtech@w3.org>
- Cc: "Ian Hickson" <ian@hixie.ch>
Thanks al, My only addition is that alt="" should be flagged for attention incase it was put there automatically without thought or understanding of its intended consequences. ----- Original Message ----- From: "Al Gilman" <Alfred.S.Gilman@IEEE.org> To: "W3C WAI-XTECH" <wai-xtech@w3.org> Cc: "Ian Hickson" <ian@hixie.ch> Sent: Tuesday, April 22, 2008 4:54 PM Subject: some reflections on @alt usage Reference: discussions of if and when the HTML5 specification should tell authors to omit the @alt attribute, in the TR page draft at http://www.w3.org/TR/html5/#the-img .. and on this list. Caveat 1: these are personal perceptions, not PFWG consensus Caveat 2: I'm not going to try to give direct answers to the questions that have been asked of PFWG. I want to get some ideas out here that address (1) the 'feasible range' of a solution that all can live with (2) the considerations that should be weighed in selecting a solution within that feasible region. ** Summary: * Cautions to editor: 1. The two examples offered for when a missing @alt might be the highest and best markup available to the encoding sofware are ill-chosen. They don't pass accessibility review as exemplifying the logical conditions they are supposed to represent. 2. Don't say that this markup advice is for *important* images where you don't know what to provide as a text alternate. The 'important' restriction is not appropriate. The same markup approach should apply for unimportant images where you don't know that they are unimportant. And make it clear that the "human didn't bother" case is included. It probably represents the lion's share of the missing @alt attributes out in the wild today; so if we are going to try to address this as a common case, unknown-to-be-decorative images should be included and not just other unknown-what-to-say images thought to be 'important.' * Cautions to the 'required is required' advocates: 3. The HTML5 draft is attempting to provide markup for what has in practice been a common case: insufficient human thought has been applied to the web-posting of an image for there to be a known-good @alt value for that image. That is to say, known to the software module that is performing the markup encoding of the content on its way to the web. While there are downsides to eliminating the simple statement "@alt is required," there are upsides to the fact that the information provided to client-side repair activity is of greater accuracy. 4. WAI has at least in some cases set a precedent for a prominent informative reference to the WAI Recommendations as an acceptable alternate to a copy-in of WAI Guideline provisions or a normative reference to them. for example SpecGL: http://www.w3.org/TR/qaframe-spec/#address-other-topics 5. The real pain if HTML5 is more subtle about "text alternate" requirements than just saying "@alt is required; Do It," comes in accessibility education. But don't underestimate the power of running code. If the author's tools flag @alt problems more consistently; that replaces many many hours of lecture time in the classroom, in terms of "good text alternates" that wind up in the live Web. It matters less what reference appears in the footnote at the end of the discrepancy-explanation. More that the author gets alerted to the discrepancy more consistently. HTML WG and HTML5 specification can help us get there; do consider reasonable alternatives. ** longer, stream-of-unconsciousness mutterings +1 to "web pages where the page doesn't know what to say as the @alt value are common." Note 1: The language in the 22 January 2008 draft poisons the debate by talking only about "important" images where a suitable @alt value is not known. That is misleading. Most of the time, if you know the image is important, you have something better to say that "I don't know" by way of an @alt value. If you don't know what to say in @alt, you don't know if it is 'important' or not. If the specification is going to state conditions under which the @alt attribute is to be omitted, they should be "I don't know" conditions spanning both important and decorative (but unknown decorative) images as well. in: http://www.w3.org/TR/html5/#the-img ..where it says "A key part of the content that doesn't have an obvious textual alternative" Note 2: In particular, most accessibility experts will not agree that the photo upload use case is one where the authoring tool could not come up with something that is better than nothing. So the example adds more heat than light. Something on the order of $userScreenName's Nth photo [ uploaded | taken ] $date [ $time ] is something that uses information the generator of the HTML access page for the uploaded image files has available and is arguably better than nothing. -1 to "bad @alt is worse than no @alt in many situations" .. could not confirm this with the user community. +1 to "required @alt is persuasive in training sessions" Accessibility staff get limited time to educate developers. They don't have time for subtleties. A clear DoIt tends to get action. .. interpretation: If @alt is not required, there is damage to the accessibility outreach effort; some mitigating measures to offset this should be considered. Possible mitigating measures include things like: (a) where the specification says that the missing @alt is undesirable, it instead say is contrary to the applicable W3C Recommendation and cites WCAG. (b) in its processor provisions, HTML5 says that authoring tools should provide a conformance checking function, and that in the shipping default configuration of that conformance checking function, a missing text alternative (Note 3) will be flagged as a defect, with a help trail that leads back to the WCAG standards. Note 3: the test should be that the "text alternative" http://www.w3.org/TR/WCAG20/#text-altdef as described in WCAG2 is not defined by the markup. It is within the purview of the HTML5 specification to provide that the legend of a figure structure is in the search list to be the text alternate for the image in that structure, for example. The text alternative will frequently be provided by @alt but WCAG provides for other markup means in principle. On the other hand... +1 to "Missing @alt cues repair, and this is useful." Present client-side processing is centered around the following pattern: if @alt="" the image is ignored. if @alt is not there, processors may and sometime do attempt some sort of repair. The filename of the image is commonly used as a substitute. Note 4: In the case of the Specification Guidelines (SpecGL) the WAI agreed that the SpecGL document should not re-ordain what was already ordained in the WAI Guidelines, but rather should include an informative but conspicuous reference to the WAI Guidelines at critical points of relevance. http://www.w3.org/TR/qaframe-spec/#address-other-topics This is a precedent for having the HTML5 specification cite the WCAG requirement for a text alternative; rather than substituting a different requirement, or making a normative re-statement that creates two documents purporting to be the origin of the same requirement. Note 4: The Rorschach test example is also not a valid example of what it attempts to illustrate. It is clear from the following WCAG language <quote cite="http://www.w3.org/TR/2007/WD-WCAG20-20071211/#text-equiv-all"> (3) a test or exercise that must be presented in non-text format, (4) primarily intended to create a specific sensory experience, then text alternatives at least provide descriptive identification of the non-text content </quote> .. that there are appropriate things to say in a text alternate in this case, and why not use @alt to say them? In other words, "ink blot" or "test stimulus" would, either of them, be appropriate @alt values and in 'no way' is there is no way to provide an appropriate text alternative. Al
Received on Tuesday, 22 April 2008 21:30:18 UTC