Re: [html4all] some reflections on @alt usage

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