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

In terms of options A through D, below, there is another option E which is that sites that care about conformance make sure that any images they use already have author-provided image provenience metadata that accurately describes the image, as is being discussed in another thread "[html4all] New issue: IMG section -- metadata "
 
I had this really unpleasant thought that I just had to share (with a tiny gleam of mischief in my eye): suppose someone decided to bring legal action against the User Agent manufacturer for requiring alt tags, on the grounds that as a result, this forced authors to invent alt descriptors that, unbeknownst to them, ended up defaming or diluting someone else's trademark. Do the browser makers seek that additional exposure?
 
If an image's provenience is properly described by its originator (and presumable copyright holder) then that additional liability is not created.
 
fun, que no?
David

________________________________

From: public-html-request@w3.org on behalf of Ian Hickson


[...]

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 Thursday, 17 April 2008 00:24:16 UTC