[whatwg] Conformance checking of missing alternative content for images
ian at hixie.ch
Thu Sep 6 22:12:50 PDT 2012
On Wed, 22 Aug 2012, Jukka K. Korpela wrote:
> 2012-08-22 3:43, Ian Hickson wrote:
> > [...] the argument is that WYSIWYG editor implementors will be
> > pressured into making their tools output conforming content by people
> > who don't understand the subtlties of this thread, based purely on
> > validator output.
> To which extent do people pressure WYSIWYG editor implementors into
> that, who are these people, and is there evidence of the pressure being
> successful? How often have they made implementors generate alt="" for
> unknown images, instead of something appropriate like alt="(an image)"?
alt="(an image)", or alt="DSK1298.JPG", or similar such strings, are
terrible alternative text. They're not uncommon. (I don't have numbers at
hand. I did look into it a few years ago. It would certainly be good to
have someone do more recent research.)
> > A user converting 100,000 PDFs to HTML isn't going to be entering
> > alternative texts for each image.
> Such bulk conversions can be useful for many purposes, but the results
> are not accessible and do not conform to good HTML authoring rules.
> There is no reason to prevent validators from saying this, in their own
There is a reason; it's been explained in some detail in this thread.
Briefly again: If they're not silent, the authors of those tools will be
pressured into making the images have bogus alternative texts that are not
programmatically detectable, by people comparing such tools using
validators. Better to have the output be clearly non-conforming, but for
the validators not to complain about it by default.
> Take the example of converting one non-HTML document with images to HTML
> format. Should the result of an automatic converter that generates <img>
> tags without alt attributes be considered as valid as the result of
> human conversion with alt attributes added or semi-automatic conversion
> (where a human is prompted for entering alt texts)?
It's not valid to omit alt="" in these cases. We just don't want
validators to say that it's not valid.
On Sun, 26 Aug 2012, Benjamin Hawkes-Lewis wrote:
> >> It would help catch the not uncommon antipattern where the "content"
> >> of a link or button is provided only by a background image.
> >> <a href="somewhere"></a>
> >> <a href="somewhere-else"></a>
> >> <button class="delete"></button>
> > This is should-level non-conforming and has no reason to be
> > conforming, as far as I can tell ("elements whose content model allows
> > any flow content or phrasing content SHOULD have at least one child
> > node that is palpable content and that does not have the hidden
> > attribute specified").
> > The only reason it's not entirely non-conforming ("must" rather than
> > "should") is that there are some edge cases where it makes sense, e.g.
> > when you have an empty paragraph that you're going to fill in later.
> > But maybe we should tighten this up again, e.g. for interactive
> > content?
> I cannot imagine a good reason to include an unnamed control, so yes.
> Note that this would need to take into account that fields might be
> labelled by a <label> or a table header cell.
Hm, that's a good point. I don't think there's a good way to
programmatically detect whether there's a label or not, so I'll just leave
it as a SHOULD for now.
On Wed, 22 Aug 2012, Steve Faulkner wrote:
> >> The spec currently allows img without alt if the title attribute is
> >> present
> > That's a wild over-statement of the case.
> In terms of conformance checking it is not, as you have said yourself
This is only a limitation of the state of the art. There's no way to
detect these valid cases vs the invalid ones, and reporting false
negatives ("you're invalid" when it is valid) is worse than false
positives ("you're valid" when it is not).
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg