W3C home > Mailing lists > Public > public-html@w3.org > January 2010

Re: Discussion on Change Proposal for ISSUE-66

From: Maciej Stachowiak <mjs@apple.com>
Date: Thu, 21 Jan 2010 23:24:14 -0800
Cc: Shelley Powers <shelley.just@gmail.com>, Jonas Sicking <jonas@sicking.cc>, HTML WG <public-html@w3.org>
Message-id: <581B5138-1FCD-43F5-AF56-64356E60B750@apple.com>
To: Matt May <mattmay@adobe.com>

On Jan 21, 2010, at 11:09 PM, Matt May wrote:

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

Actually, nowadays images that are are purely decorative are reasonably likely to be CSS background images, or else to have empty alt, so they wouldn't trigger this. I should note that many current screen readers will read the filename by default for any image that is not marked as decorative however, and this is often useless. I have actually tried using screen readers and I get a lot of "eye em gee seven one eff three bee four dot jay pee gee". I think the user experience overall would be much better if anything that's a guess, rather than actual alt text, were presented as such. But that's up to screen reader developers.

> 
> 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...")

My experience with screen readers leads me to conclude that their users have a very high tolerance for repetition. I will also say that hearing the above can't possibly be as bad as hearing a random string of letters and numbers, and that's an experience that happens dismayingly often today.

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

I think it would be fine to have a separate subsection for repair advice. Though it would likely only contain a few sentences. Like I said before, it seems better

Regards,
Maciej
Received on Friday, 22 January 2010 07:24:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:00 GMT