Another summary of alt="" issues and why the spec says what it says

On Wed, 16 Apr 2008, John Foliot wrote:
> 
> "Conclusion:  barring the introduction of new, 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."

The "new good" reasons are that HTML4 didn't take into account all cases. 
HTML4 had no solution for the case where an important (non-decorative) 
image was present, but the person or software generating the page did not 
know what the image represented. This case was raised as an issue, and 
several solutions were considered (such as magical values, omitting the 
alt attribute in such cases, not supporting the use case, etc), and the 
only solution that was found to be compatible with legacy markup, 
compatible with existing user agents, and that solved the use case was 
what the spec defines now.


> Furthermore, the response also stated:
> 
> "The language "In such cases, the alt attribute may be omitted," gives 
> the appearance of creating a policy line that is inconsistent with WCAG, 
> whether 1.0 or 2.0. As such, this needs to be changed."

Right, the spec was changed in response to this feedback and other 
feedback to more clearly explain that the alt attribute _must not_ be 
omitted unless certain rare conditions are met.


> > If there is some more concrete feedback that I should deal with, I 
> > would encourage you to send it.
> 
> I believe that Laura Carlson, Steven Faulkner, et.al., as members of the 
> HTML WG, have requested further feedback from 2 other W3C working 
> groups. 
> [http://lists.w3.org/Archives/Public/public-html/2008Apr/0408.html]

Indeed, I also encouraged such feedback in my reply to that message:

   http://lists.w3.org/Archives/Public/public-html/2008Apr/0412.html


On Wed, 16 Apr 2008, John Foliot wrote:
>
> Strong language and instruction within HTML5 aside, the spec ultimately 
> leaves the binary decision to subjective determination, which leaves 
> open the possibility of abuse.

As far as I'm aware, there have only been five concrete proposals made:

 * What the spec says now: define the omission of alt to be this case.
 * What HTML4 said, which doesn't handle this case.
 * Introducing a magic value for alt in this case. (alt=_missing)
 * Introducing a new attribute to replace alt in this case. (noalt)
 * Label a page as not being "fully" conforming in this case. (unready)

I've explained the reasons for not going the magic values route before, 
e.g. in:

   http://lists.w3.org/Archives/Public/public-html/2008Apr/0458.html
   http://lists.w3.org/Archives/Public/public-html/2008Apr/0439.html
   http://lists.w3.org/Archives/Public/public-html/2008Apr/0434.html
   http://lists.w3.org/Archives/Public/public-html/2008Apr/0431.html

I've explained the reasons for not going the new attribute route before, 
e.g. in:

   http://lists.w3.org/Archives/Public/public-html/2008Apr/0269.html
   http://lists.w3.org/Archives/Public/public-html/2008Apr/0449.html

The problem with labelling pages as non-conforming or not fully conforming 
is that it will cause people to instead use one of the other options, as 
they want their pages to be conforming. (I am here assuming that the 
author cares about conformance, since if he doesn't care about conformance 
then anything we say here is irrelevant anyway.)

The HTML4 route doesn't address the use case that has been raised.

This only leaves what the spec says now.

If you can suggest a way to make the text not machine-checkable instead of 
subjective, I'm certainly eager to change the spec to be more machine 
checkable. However, I really cannot see any way to compute whether 
alternative text is valid or not, or whether it is ok for alternative text 
to be omitted or not.


> The text says:
> 
> "In a rare[1] subset of these cases, there might be no alternative text
> available[2].

> [1] Rare as in 1 in a million, 1 in a trillion, or 1 in 100?

I have no idea. Does it affect the debate? It happens on major sites, like 
Flickr, so even if Flickr was the _only_ site it happened on, we'd still 
have to deal with it.


> [2] 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." 
> (http://annevankesteren.nl/2007/09/alt)

No, the spec makes the alt attribute required in this case:

   When it is possible for alternative text to be provided [...] text 
   that conveys can serve as a substitute for the image must be given as 
   the contents of the alt attribute.

The [...] bit is a non-normative clause giving examples of such cases:

   for example if the image is part of a series of screenshots in a 
   magazine review, or part of a comic strip, or is a photograph in a blog 
   entry about that photograph, 

"Not bothering" is not one of the reasons that the spec gives for not 
providing alternative text. I can make this more explicit if you like.


> This could be the case, for instance, on a photo upload site[3], if the 
> site has received 8000[4] photos from a user without the user annotating 
> any of them.

Note that this sentence has no normative criteria -- as an example, it is 
purely there for exposition, and what it says is just an example.


> [3] 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")

It's just an example. The normative text is "In a rare subset of these 
cases, there might be no alternative text available. In such cases, the 
alt attribute may be omitted, but the alt attribute should be included, 
with a useful value, if at all possible.". That's all. It doesn't make any 
judgements about whether this does or doesn't apply to wikis or CMSes.


> [4] 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?

No, that's again just an example and the number is meaningless. I can make 
it smaller if you want. It's just a random number.


> In such cases, the alt attribute may[5] be omitted, but the alt 
> attribute should be included, with a useful value, if at all possible." 
> [http://www.w3.org/html/wg/html5/#alt]

This is the actual normative conformance criteria.


> 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 [5]may emerge as
> reality, and the spec explicitly condones such.  This is what I (we?) see as
> a serious flaw in the current proposal.

Whatever we do, there will be sites that simply don't know what a critical 
image represents, and they will be faced with the question of what to do.

Sites that don't care about conformance are irrelevant here, since what we 
require will have no effect, by definition.

Sites that _do_ care about conformance have these options:

   A. Mark the image as decorative.

   B. Mark the image as being equivalent to some arbitrary text that they 
      come up with which (by definition) can't be especially useful or 
      appropriate, since they don't know what the image is.

   C. Mark the image as being equivalent to some text that already appears 
      elsewhere on the page, e.g. a caption, user-provided description, 
      GPS location, timestamp, camera model, etc.

   D. Mark the image as being critical-but-of-unknown-content.

Options A-C all result in a worse accessibility situation. D is not 
possible in HTML4, and is the option we want to provide in HTML5. How we 
provided it is up to us. As listed at the top of this e-mail, I'm aware of 
three syntax proposals for D (omitting alt to indicate this case, 
introducing a new attribute value to indicate this case, and introducing a 
new attribute to indicate this case) and one conformance definition 
proposal for handling D. I've cited above the e-mails listing the problems 
with two of the syntax proposals, and the "unready" conformance proposal 
doesn't solve the problem (sites that care about conformance want to 
conform, they don't want to reach a level of "unready" conformance), so 
that leaves us with just what the spec says now.


> 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.

The words "may" and "should" are defined by RFC2119 and have very specific 
conformance meanings in the context of HTML5:

   http://www.whatwg.org/specs/web-apps/current-work/multipage/section-conformance.html#conformance
   http://www.ietf.org/rfc/rfc2119


> 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" response.

I have given these proposals serious thought and I have listed the 
technical reasons for rejecting those proposals. This is the same process 
I have followed for all the other issues in the spec so far.

I don't know what else you want me to do, short of ignore the technical 
reasons I've listed and go with one of the other proposals despite my 
conclusions. The problem is that if you want me to ignore technical 
considerations and go with your solution, I end up with a propblem when 
people in an opposing camp ask me to ignore technical considerations and 
go with _their_ solution. How do I pick which solution to follow?

The only good way I have found to decide which of several conflicting 
proposals to pick is to base the decision purely on technical reasoning.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 16 April 2008 22:30:06 UTC