[html4all] More effective approaches? (was RE: Request for review of alt and alt value for authoring or publishing tools)
foliot at wats.ca
Wed Apr 16 14:23:57 PDT 2008
Lachlan Hunt wrote:
> Keep in mind that the *current* generation authoring language does not
> allow alt to be omitted. A simple requirement for alt in HTML5, just
> like in HTML4, won't have any effect on sites like flickr. But there
> is sure to be other, more effective approaches that might.
Lachlan, if this is true, then let us hear the optional, more effective
approaches. Right now, the only option we are being presented from the
Working Group is to omit adding an alt value "sometimes". This is really
not that effective in addressing the real needs (that most of us on either
side of this discussion are all in agreement with) of non-visual users.
Strong language and instruction within HTML5 aside, the spec ultimately
leaves the binary decision to subjective determination, which leaves open
the possibility of abuse. The text says:
"In a rare subset of these cases, there might be no alternative text
available. This could be the case, for instance, on a photo upload
site, if the site has received 8000 photos from a user without the
user annotating any of them. In such cases, the alt attribute may be
omitted, but the alt attribute should be included, with a useful value, if
at all possible."
 Rare as in 1 in a million, 1 in a trillion, or 1 in 100?
 Or perhaps the content provider just can't be bothered to add an alt
text because "...it wasn't really clear to me what would be a better
solution given the single constrain I have: not finding it necessary to
provide replacement text for all those images."
 So other CMS applications cannot seek the same dispensation? A wiki is
not a "photo upload site" even though it allows for photo uploads. Wikis
and other CMSes then must insist on adding alt text for all images uploaded
or be non-conformant? I guess the other solution would be to rename my wiki
a "photo upload site" that includes a lot of text, and I'm home-free then?
("Drupal, a popular photo-upload utility")
 I note that we've upped the ante to 8,000 from 3,000. So then, if the
number of images uploaded < 8,000 then alt *must* be included, but if the
number of images uploaded >= 8,000 it can become optional?
Yes or course, I am both poking fun at and exaggerating to some extent, but
the real problem is that the caricatures I note above may emerge as
reality, and the spec explicitly condones such. This is what I (we?) see as
a serious flaw in the current proposal. Having worked *directly* with WCAG
1 for close to a decade, I know first-hand the problems of slippery words
such as "may", "should", and "until such time" when it comes to guidance and
(even more importantly) standards. May and should are not "standards"
words, they are at best suggestions.
There have been at least two other proposals ("Magic tokens/reserved values"
and an "unready" stamp) that at the very least should warrant real
investigation beyond Ian's "*I* have considered it and am skeptical"
> HTML5 conformance criteria should not be considered to be a social
> engineering tool. The lack of requirement for alt in a few cases does
> not prevent alt text inspection tools being integrated into
> accessibility checkers or validators. Social engineering on this
> issue can and should continue through other avenues, such as
> accessibility guidelines, advocacy and education; but not in the
> HTML5 specification.
Lachlan, I can tell you first hand that without a stick, the carrot alone is
often less than useful. Like it or not, HTML today transcends merely a
technical "mark-up" language - the emergence of the WWW in the past decade
is on par with the effect that the steam engine had on the Industrial
Revolution, or on how the automobile has shaped society (especially
"Western" society) - I think we can all agree on this. Since HTML is the
primary binder of the bulk of the content that moves over the internet, it
now contains a social engineering component, whether or not mechanical (CS)
engineers wish to accept it or not.
More information about the List_HTML4all.org