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

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

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.   `._.-(,_..'--(,_..'`-.;.'