- From: Steven Faulkner <faulkner.steve@gmail.com>
- Date: Mon, 28 Apr 2008 10:44:07 +0100
- To: HTML4All <list@html4all.org>
- Cc: "Charles McCathieNevile" <chaals@opera.com>, "W3C WAI-XTECH" <wai-xtech@w3.org>, "Ian Hickson" <ian@hixie.ch>, "Al Gilman" <Alfred.S.Gilman@ieee.org>
Hi Al, John, It should be noted that some of the suggestions outlined by John and myself were previously raised by Al and discussed on a thread back in February [1]: [1] what's machinable [was: Re: ALT issue redux] http://lists.w3.org/Archives/Public/wai-xtech/2008Feb/0006.html http://lists.w3.org/Archives/Public/wai-xtech/2008Feb/0008.html regards stevef On 27/04/2008, John Foliot <foliot@wats.ca> wrote: > Charles McCathieNevile wrote: > >>> +1 to "required @alt is persuasive in training sessions" > >>> Accessibility staff get limited time [...] > > > > I don't actually find this terribly persuasive. > > > > With due respect then Chaals, some more time in those particular trenches is > recommended. > > While I am painfully coming around to the notion that "bad" @alt is indeed > worse than "no" @alt, one of my on-going concerns remains working at the > content author level. I keep thinking that it is not an accident that *ALL* > the major accessibility guidelines out there start with a variant that > insists on a textual alternative to visual only content: > > * WCAG 1: > 1.1 Provide a text equivalent for every non-text element > > * WCAG 2.0 (Draft): > 1 Perceivable > 1.1 Provide text alternatives for any non-text content so that it can be > changed into other forms people need, such as large print, braille, speech, > symbols or simpler language > > * Section 508: > a) A text equivalent for every non-text element shall be provided (e.g., > via "alt", "longdesc", or in element content) > > * AccessiWeb (France): > 1.1 : Chaque élément graphique possède-t-il une alternative textuelle? > [Trans: Does each graphic element possess a text alternative?] > (http://tinyurl.com/2o5zuu) > > *IBM Web Accessibility Checklist V 3.5: > Checkpoint 1: Images and animations - Use the alt="text" attribute to > provide text equivalents for images. Use alt="" for images that do not > convey important information or convey redundant information. > *AND* > Checkpoint 2: Image maps - Use client-side image maps and alternative text > for image map hot spots. If a server-side map is needed, provide equivalent > text links. (http://tinyurl.com/23yjfr) > > * WCAG Samurai Errata (Unofficial): > Guideline 1. Provide equivalent alternatives to auditory and visual > content. (http://wcagsamurai.org/errata/errata.html) > > * TEITAC Draft Recommendation (AKA Section 508 Refresh) > 3-F - Non-text Objects - All non-text objects that are presented to the > user must have a text alternative that presents equivalent information, > except for the situations listed below. > (http://teitac.org/wiki/EWG:Draft_Jan_7#3-F_-_Non-text_Objects) > {This is the exception to the norm, in that it is not the /first/ > requirement on the list, although it is noted as being critical, and that it > affects "all disabilities"} > > (I am sure as well that there exists numerous corporate internal > requirements, not wholly published, that insist on a similar requirement - > Sample: http://tinyurl.com/6bn97o) > > > While *WE* all know that web accessibility transcends more than just the > visually impaired, *WE* still have a long way to go in conveying that > message (as even those that should know better forget sometimes - > http://tinyurl.com/3noxl9 "...FOR THE LAST TIME..."), and further have a > long way to go simply conveying the entire "web accessibility" message, > never mind that it is more than just for blind people. > > > None-the-less, as the "web" for most users remains a visual experience, > using the notion that a suitable alternative *must* exist for visual only > elements to ensure universal access is a simple concept to grasp by > virtually all (right down to a primary school level), and so has enormous > value to those of us who "teach" about this subject. Removing the > requirement for this concept at the technical level *does* send a poor > message, and equates roughly to "Do as I say, not as I do". > > [Sidebar: I wish to commend Henri Sivonen and his http://validator.nu method > of providing a means of checking appropriate text alternatives, as his > methodology is both sound and useful] > > ************* > > <opinion> > There has been much discussion surrounding heuristic evaluations, and other > ways of providing useful alternative content to the end-user, outside of > cramming in bogus @alt content, and for the large part they do have > credence. The question then remains, how do we continue to pressure content > creators to include useful "equivalent alternatives", when at the end of the > day the spec says you *really* don't have to. (Guidance and specific > language aside, the fact remains that anyone can step up and claim "special" > status, and the spec as written today in it's interpretive way* will allow > conformance, as there is no programmatic way of testing the subjective > decision of the author/authoring tool). > > [* there is "can't", and then there is "won't", and the difference is worlds > apart] > > If we are to relax the mandatory requirement for @alt in the next generation > Markup Language, then we must also explicitly note and provide as many > /other/ ways of providing this information as possible: > > @alt and/or @longdesc > @alt and/or @legend > @alt and/or @id > @alt and/or @figure > @alt and/or @caption > @alt and/or (ARIA Variants suggested) > @alt and/or (suggested reserved values) > @alt and/or (open to further suggestions) > > With these (and perhaps other) means/tools at their disposal, I cannot think > of *any* scenario where one of these options could not be implemented, > either by the end (human) author or at the "program" level (WYSIWYG/file > upload site/etc.). Having *any* of the above methods of expanding upon the > visual-only content present would thus render the <img> element conformant. > I would then suggest that any other HTML 5 implementation of <img> which > lacks *any* of the provided means of "equivalent alternatives" be > non-conformant, and further suggest that this result with the most drastic > of consequences: non-rendering. (Give out more rope, but increase the risk > of hanging oneself) > > Regarding backwards compatibility: The web is a constantly evolving > organism, and all players have a responsibility to ensure that the web > continues "to work". I am sure we are all familiar with the IE8 "switch" > problem, and why they (Microsoft) felt that using the DTD was (is?) an > unreliable mechanism. However, as the defacto HTML 5 Conformance checker > (validator.nu) notes, content that lacks the appropriate DTD (<!DOCTYPE > HTML>) is non-conformant, and so this mechanism *could* be deployed as the > means of conformance checking for images and other visual-only content. > Documents that were authored to any other spec ( =< HTML 4.01, => XHTML 1.0, > documents with no DTD) could continue to allow non-conformant <img> elements > to render (in a 'quirks' kind of way), but moving forward if you want to be > authoring true HTML 5 then you need to step up to the plate and use any one > of the now (proposed) multiple means of ensuring equivalency provided within > the spec. > </opinion> > > Let fly the bouquets and brickbats. > > JF > > > > > > > _______________________________________________ > List_HTML4all.org mailing list > http://www.html4all.org/wiki > -- with regards Steve Faulkner Technical Director - TPG Europe Director - Web Accessibility Tools Consortium www.paciellogroup.com | www.wat-c.org Web Accessibility Toolbar - http://www.paciellogroup.com/resources/wat-ie-about.html
Received on Monday, 28 April 2008 09:44:41 UTC