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

Ian Hixie wrote:

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

>   C. Mark the image as being equivalent to some
> text that already appears ...  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

We agree that we're looking for a least-of-evils solution, but we do
not agree on which option is the least bad.

You obviously prefer D.

Several posters prefer "E:  Do not support this use case", beecause it
is rare (but a frequently used excuse).

Other posters (and apparently the WCAG) prefer C.  They agree it isn't
desirable, but they feel it is still better than D.

Even assuming that D is the correct choice:

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

And they all have problems; the decision between them isn't a clear
technical decision.

You prefer omitting alt.  Given the legacy content that I have viewed,
I see that as a sloppy equivalent to case A -- effectively declaring
the image decorative.

The arguments against new attribute values are largely by analogy --
and not everyone agrees on which analogies are strongest.

The argument against a conformance definition is that toolmakers will
still cheat to be "valid" -- but that isn't proven yet either.  If we
call it "unready", you're probably right.  I don't think they would
subvert a state called "Author Must Enter Alt text -- otherwise
valid".  (Maybe I'm just not cynical enough, but ... you haven't
provided evidence for that strong of a claim.)

-jJ

Received on Thursday, 17 April 2008 01:44:09 UTC