[html4all] some reflections on @alt usage

[John Foliot]

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