[whatwg] @generator-unable-to-provide-required-alt, figure with figcaption
ian at hixie.ch
Tue Sep 3 14:09:30 PDT 2013
On Sat, 8 Jun 2013, Jukka K. Korpela wrote:
> 2013-06-08 0:13, Ian Hickson wrote:
> > 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!
> And who wrote that generator-unable-to-provide-required-alt is...
Just because the solution is inadequate doesn't mean the problem isn't
real. You were saying the problem wasn't real; I was pointing to a
counterproof. I would be the first to agree that the spec isn't perfect.
> > > 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).
> To a user, even “(an image)” is better than lack of alt attribute
I disagree. The lack of an alt attribute can be used by user agents to
substitute the string "(an image)", in which case it is the same, or it
can be used to do far more, e.g. image recognition, OCR, etc. This isn't
academic, these technologies exist today.
> which is what generator-unable-to-provide-required-alt really means
To the non-validator user agent, that attribute means nothing. It's a
non-conforming attribute with no semantics to any software outside content
generators and conformance checkers.
> To analyze which images lack good alternative texts, you need to look at
> the images in their context. It’s just wrong to assume that they can be
> identified using some simple automated analysis.
If you don't write bad alternative text (like "(an image)"), but sometimes
write no alternative text at all, then detecting images without good
alternative text is the same as detecting images with no alternative text.
Certainly, detecting images with present but bad alternative text is a
much harder problem -- that's why we should discourage the use of bad
alternative text such as "(an image)".
> And future user agents won’t try to figure out what the alternative text
> should be, any more than current browsers do such things. It is just
> wishful thinking to expect such processing, and if browsers tried to do
> such things, they would just mess things up.
We are far closert to this than I think you realise. Try doing image
searches in G+, for exmaple (assuming you have a lot of photographs in
your G+ stream). Even with virtually no context, no captions, no incoming
links from other pages, and so forth, G+ image search can return accurate
results for searches like "house", "tree", "cat", and so forth. It's not
at all a stretch to imagine the next stage of this technology is the
ability to describe an image. It won't happen tomorrow, maybe not even
next year, but HTML is likely to be with us for decades more.
On Tue, 18 Jun 2013, Steve Faulkner wrote:
> > > > >>
> > > > >> <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.
> > >
> > > the above statement is bad advice:
> > >
> > > browsers map title to the accessible name in accessibility APIs when
> > > alt is absent, so--
> > ...so the browsers are buggy. This is not unusual. File bugs. :-)
> > Indeed, since you've demonstrated yourself able to write code, you
> > could just go and fix the bugs directly. :-)
> This behavior doesn't appear to be due to a bug, its by design, the
> title attribute is used as an accessible name of last resort for all
> elements and its implemented pretty much in the same (interoperable) way
> in all browsers.
That doesn't mean it's not a bug.
> > Writing specs for the lowest-common-denominator is not the way we'll
> > get a usable, accessible Web. We might sometimes be forced to when
> > there are compat requirements with massively deployed content that Web
> > author are relying on that prevent certain behaviours from being
> > fixed, but this really doesn't apply in the case of ATs, since the
> > vast majority of authors have never tested how their pages work in
> > ATs.
> I don't understand what you are saying here, can you elaborate?
Which part is unclear?
On Thu, 20 Jun 2013, Martin Janecke wrote:
> >> Unfortunately -- although its verbosity is there to prevent any
> >> misunderstanding for its use -- it might leave the impression that a
> >> generator writing
> >> <img src="..." generator-unable-to-provide-required-alt="">
> >> is not as good as a generator writing
> >> <img src="..." alt="an image">
> > Indeed. I don't know of a way to fix that. It's always going to be the
> > case that a generator doing the wrong thing in a way that is
> > machine-readably indistinguishable from the right thing is more likely
> > to look correct at a quick glance than a generator that is doing the
> > wrong thing in a machine-detectable way. I don't know what we can do
> > about that.
> > I'm open to suggestions.
> I see. Unfortunately I do not have a better idea.
If anyone does come up with one, please speak up!
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg