[html4all] ALT issue redux

[John Foliot]

Al Gilman wrote (in response to Laura Carlson):
> 
> Since by the Principles propounded by the HTML Working Group they
> *want* to support accessibility, let's build on that and find an
> answer to *how* HTML5 supports accessibility that works.  
> 
>> According to WCAG alt is required.
> 
> In terms of WCAG1 that is true.
> 
> In terms of WCAG2 a text alternative is required.  The
> format specifics have been removed from the success criterion. The
> difference matters. 
> 
> In looking toward HTML5 which may take longer to finalize that even
> WCAG2, it is important to look at the trend, the nature of the
> differences between WCAG1 and WCAG2.  

<snip>
> 
> The HTML5 draft is clear that, at a moral level, the critical content
> *should* have its text alternate, in the @alt attribute. 
> 
> When they say "none may be available, or obvious," the narrative
> discussion suggests a division of labor where the photo-sharing site
> provides the markup and the public provides the image content.  
> 
> It doesn't matter much whether it's a format rule or a WCAG rule that
> has been violated; what is going to affect public behavior is things
> like: ...

<snip>

> 
> The question in terms of deployment is "what is going to happen to
> you or your content if you violate this rule?"  It's not a question
> of "is it a language rule?" or "is it an accessibility rule?" but
> "what is going to happen?"

OK, time to jump in...

What is going to happen is that an image will exist that has *no* contextual
data associated to it.  Thus, by it's very nature, it will be inaccessible
to those who cannot see the image.  At best, adaptive technology will "know"
that there is/are images in the document, but despite the well-meaning
wishes of the HTML WG, no current amount of heuristic analysis will be able
to suggest whether a specific image is critical, in-consequential, or
somewhere in-between.  Further, A.T. will be unable to determine whether
this is by design, ignorance or by accident.

The argument has been put forth by the HTML WG that ALT="" may in fact be
"harmful" to accessibility (a claim, BTW, they have not been able to
substantiate).  However, even though today there exists many, many images
with ALT="" (and are still functionally inaccessible to many users), it has
emerged as the cowpath-de-jour. 

I respectfully suggest then that we both need to acknowledge the problem as
well as suggest a way forward - but a way forward that insists that
non-textual content, and specifically the image element, *must* contain the
ALT attribute to be conformant - full stop.  It has been suggested (by
myself, but also by others) that some reserved values be created and
referenced in the specification that could replace the current default of
<quote quote>.  A synopsis and related reading exists within the ESW Wiki at
http://tinyurl.com/2v9c6f  

Images that lack either ALT="" (backward compatible), or one of the newly
suggested reserved values (ALT="_none", ALT="_omit", ALT="_decorative", etc.
- all values which *do* provide some contextual information) would then be
non-conformant, and subjected to the following:
  
> 
> Josh and I would seem to be agreed that "refuse to process
> such a page in the browser" is justified for a critical-content image
> that is lacking @alt. 

(I would amend that to read *any*, as how does the non-author determine what
is critical vs. non-critical?)

A solution such as this builds upon the current cowpath (ALT=""), and at the
same time seeks to further enhance the semantic value of newly minted
content, while still addressing the needs of Adaptive Technology. (As a
further wrinkle, and building upon a different furor in a different camp,
documents that render in quirks mode that lack any alt attribute could be
"forgiven" and output as best as possible - quirky indeed)

> 
> The problem with the immediate section about
> 
> <q>A key part of the content that doesn't have an obvious textual
> alternative</q> 
> 
> .. is the casual, colloquial way it is written.  It neither meets the
> need of software developers for a crisp rule they can program to, and
> at the same time it irritates access advocates by allowing the
> inference that it disagrees with the accessibility Recommendations.


In the many go-rounds on this topic, another critical piece of information
emerged, not obvious on the surface (or in the draft), but spoken of
none-the-less.  As it currently stands, omitting *any* alternative content
rests primarily with the content author - it is a subjective decision that
often may also be supported by authoring tools or applications (i.e. the
photo sharing site), but the bottom line is that the decision is
discretionary:

"I am currently following HTML5 (omitting alt) as it wasn't really clear to
me what would be a better solution given the single constraint I have: not
finding it necessary to provide replacement text for all those images. This
would take too much time for little benefit." 
http://annevankesteren.nl/2007/09/alt

[REPEAT] ...too much time for little benefit...  

It is this "loop-hole" which both frustrates and frightens me.  In contrast,
the addition of reserved values can be programmatically accounted for in
conformance checkers, accessibility "validators", etc. and the author
"intent" is conveyed, even if the intent is to deliberately not provide
contextual alternative(s) to images or other non-text items.
   
> 
> I think that a better way to frame the argument is something like:
> 
> 1.  By the principles, HTML5 wants to support accessibility

...in so far as it does not impact on other critical goals.  Witness the
disappearance of @headers/@id, @longdesc, and the poorly documented (to
non-existent) information alternatives to newly introduced elements such as
@canvas

> 
> 2.  By their charters, WAI groups (here WCAG) are the go-to experts
> in matters of accessibility 
> 
> 3.  WCAG requires @alt (WCAG1) or the function that in HTML4
> is provided by @alt (WCAG2)  [editorial note -- add links]
> 
> 4.  By the principles, if it 'tain't broke, don't fix it.
> 
> 5.  Conclusion:  barring the introduction of three fresh good reasons
> for a change, the failure of the HTML5 draft to make @alt on <img> an
> across-the-board requirement (even if sometimes it has the value of
> &quot;&quot;) is a bug.  Or do you have reasons?   
> 
> Does this work for you?

If we can hold them to this, then yes.  I would further posit that author
ignorance and non-ATAG conformant tools not be accepted as "good reasons",
as both can and must change in the evolutionary process.  Freezing time is
only self-defeating.

One final thought - Patrick Lauke wrote:

> 4. it's broken because, in the wild, the proportion of images lacking
> @alt (or with broken/incomplete/inappropriate @alt) is a few orders of
> magnitude higher than that of properly @alt-ed images. this despite
> making @alt mandatory for validation XHTML

...meanwhile:
"This specification represents a new version of HTML4 and XHTML1, along with
a new version of the associated DOM2 HTML API. Migration from HTML4 or
XHTML1 to the format and APIs described in this specification should in most
cases be straightforward, as care has been taken to ensure that
backwards-compatibility is retained." 
- http://www.w3.org/html/wg/html5/#relationship

"HTML 5, one vocabulary, two serializations" 
- http://www.w3.org/QA/2008/01/html5-is-html-and-xml.html

If the new spec removes the previous mandatory obligation for @alt in
XHTML1, how then can it be backward compatible to XHTML1, as it removes a
requirement previously obliged?  To my thinking it is a backward step,
rather than a forward one.  Or am I completely missing something here?


Respectfully
JF