Re: [whatwg] @generator-unable-to-provide-required-alt, figure with figcaption

On Sun, 2 Jun 2013, Martin Janecke wrote:
> 
> I'm in charge of a code generator and while it is not widespread at all, 
> my opinion might be shared by others who make code generators: This new 
> option is too verbose – especially for something that has no meaning for 
> the document it is contained in. And it kind of sounds as if the 
> particular generator using this attribute is more inapt than other 
> generators who output
> 
> <img src="…" alt="image">
> 
> As developer of a code generator I don't feel inclined to use this new 
> non-conforming attribute instead of an inappropriate
> 
> <img src="…" alt="image"> or

It would definitely be unfortunate if you wanted to use that instead of 
<img src="..." generator-unable-to-provide-required-alt>.


> <img src="…" alt=""> or

This is, per the spec, a valid last-resort option for you to use (and if 
you have any reason to believe the image is decorative, it's the best 
option as well).


> <img src="…" title="image">

If you have a caption from the user (as opposed to replacement text), then 
this is a perfectly valid option. It's as valid as the <figure> case, and 
means the same thing.


> While I can imagine why an accessibility evangelist would want a 
> conformance-checker-silencer to be as unattractive to use as possible, 
> that really defeats its purpose, if it also deters code generator 
> programmers.

The goal isn't to make it unattractive per se, it's to make it obvious 
that it means that it was a markup generator that was forced into the bad 
position of having to output invalid code against its will, in such a way 
that an author wouldn't conclude that it makes sense to mark up the page 
this way in order to get around validators.


> Previously, conformance checkers had been silenced by a single
> 
> <meta name="generator" content="…">
> 
> in cases of missing alt-attributes. This solution effectively removed 
> any urge to use an inappropriate alt-text for me as a code generator 
> developer.

Yeah. As I recall, this approach wasn't popular with validators, amongst 
others. :-(


> I don't know whether someones writes something like „… which the 
> following figure illustrates“ instead of „… which is illustrated by fig. 
> 3“ somewhere in the text above a figure. But this difference decides 
> whether using the figure element conforms with the spec. So a code 
> generator can only use something which is structurally and optically 
> identical to the figure element but does not have the theoretical 
> requirement to be movable to a different place in the document, e.g.:
> 
> <div class="figure">
> <img src="…">
> <div class="caption">…</div>
> </div>
> 
> And here conformance checkers will complain about the missing 
> alt-attribute again …

If you use <img src="..." title="..."> it'll work (and be correct, 
insofar as anything missing alt text can be correct).


On Sun, 2 Jun 2013, Jukka K. Korpela wrote:
> 
> The purpose presented is "to avoid markup generators from being 
> pressured into replacing the error of omitting the alt attribute with 
> the even more egregious error of providing phony alternative text". This 
> is rather speculative, and it seems to lead to various attempts that are 
> more or less self-contradictory.

It's not that speculative, your e-mail is a response to a markup generator 
implementor who feels pressured in exactly this way!


> Authors of generators always have the option of generating things like 
> alt="(an image)", which can hardly be worse than lack of alt attribute.

It's worse because it prevents authors from being able to find images that 
are lacking good alternative text, and because it makes it less likely 
that future user agents will try to automatically figure out what the 
alternative text should be (since one is already provided).

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

Received on Friday, 7 June 2013 21:13:34 UTC