Re: Discussion on Change Proposal for ISSUE-66

On Jan 22, 2010, at 12:16 AM, Maciej Stachowiak wrote:
> You are right that it could sometimes fail. Other times it could give weird results. It seems to me that even the odd results you describe may still be better than saying "IMG01279.JPEG" or "JPEG image", which is what you may well get from the URL or content type.

I'd love to have all kinds of functionality in the browsers to let users find out whatever information they can about an image (including image analysis heuristics, ironically enough), but I would leave it up to them whether or not it's enabled, and probably make it a feature you'd only call with a keyboard shortcut on one image at a time. Screen reader users are generally pretty good at being able to isolate an image they think is meaningful, and they know how to poke and prod at it to get info like filename. This would be useful for that level of repair.

Here's the problem: the people who need this information most are people who aren't going to be able to reliably discern if it's any good or not. They may experience some false positives, things that sound good but are inaccurate. But more often, if this were functionality that were on by default, they'd get lots more false negatives where, say, background patterns were misinterpreted as something when they're actually nothing.

If it's on by default, it'd just make pages chattier, and probably take waaaaay longer to render. Especially when we know how many existing images don't have @alt to begin with. (Ugh. Imagine hearing this each time you encountered the old layout table rounded-corner hack. "image: quarter circle. image: horizontal line. image: quarter circle. image: vertical line...")

I'm not blind, so I can't tell you whether blind users would find this useful enough to pursue. I'm hoping some folks will chime in here. I can, however, say that OCR has figured into print accessibility from 1974 all the way into GUIs, so there's plenty of historical data to mine on the subject.

> Almost all the text in the alt section describes what is expected for authors. I think it's just this one statement allowing repair that would need to be distinguished.

Since there is such potential to conflate author advice with UA advice, I would much rather put repair techniques in a section of its own. Since the outcome of any repair techniques would vary from browser to browser, it's a set of recommendations that may help UAs further assist users, but would completely confound authors who might expect behavior where it may not yet exist. If further down the line browsers can agree on a given heuristic and commit to one technique working in a standard manner in all supporting browsers, it can be moved back to a normative section. But in many cases, such as OCR or image analysis, that consensus functionality won't ever happen until everyone is using one single algorithm, which won't happen until it's a fundamentally solved problem. (And we've been "just 5 years away" from that every year since 1974.)

-
m

Received on Friday, 22 January 2010 07:10:04 UTC