Re: Discussion on Change Proposal for ISSUE-66

On Sun, Jan 24, 2010 at 12:39 AM, Matt May <mattmay@adobe.com> wrote:
> On Jan 23, 2010, at 9:46 PM, Tab Atkins Jr. wrote:
>> On Sat, Jan 23, 2010 at 9:24 PM, Shelley Powers <shelley.just@gmail.com> wrote:
>>> Then there's the issue of performance -- authoring tools only have to
>>> try to determine the alt text once. Do we really want every user agent
>>> to attempt the same process every time the web page is opened? For
>>> every image?
>>
>> What's the alternative?  If neither the author nor the authoring tool
>> fills in the alt-text, do we just shrug our shoulders and say "Sorry,
>> blind people, guess you're out of luck."?
>
> I don't think Shelley is to blame for how the web has functioned up to this point. (If she is, I'll invite her to the CSUN Conference to apologize.) I'd also like to remind you that not only is this kind of functionality not in any shipping browser, I'm not aware of anyone who's working on it. If you want to frame it that way, do your thing, but it seems to me that you're being unnecessarily adversarial here. Her point is clearly something user agent developers will encounter if they implement any repair techniques on images.

?  This functionality *is* in shipping browsers, though it's very
limited.  Right now they may 'repair' missing alt-text by subbing in
the filename.  They don't do OCR or statistical analysis on the image,
but this can easily become reasonable to do in the future (or even
now, for ATs that *rely* on alt-text - I expect OCRing images to give
a pretty decent benefit).

>> It seems pretty obvious that the correct solution for accessibility is
>> to address this issue at *all* levels.  The earlier the better, but
>> it's not excusable to fail users with accessibility needs when we
>> *can* do something to help them.
>
> The creation of @alt content is the sole responsibility of the author, and facilitated by the authoring tool. @alt is the product of what the author intends to communicate.
>
> Once it has left the author's control, anything created anywhere else in the lifecycle of that content (server, user agent, assistive technology, display) is a degradation, because it is trying to reconstitute the author's intent, without ever knowing it for certain. None of us are saying that browsers should be prevented from doing more for users. The absence of a MAY, which was what the original issue here sought, does not equal the presence of a MUST NOT.

Sure, a decent inferred alt is still worse than if the author supplied
some alt themself.  But no alt is worse than that.  The only thing
worse than no alt at all is a completely wrong inferred alt.  If it
was reasonable to think that most such inferred alts would be
completely wrong, I'd agree with you, but it's not.  There are very
reasonable methods of inferring alt text that work well on many
images.

>> I'm just behind a slight softening of the spec text, as Lachlan and
>> Maciej have suggested.
>
> Between the two, I prefer Maciej's idea of stripping out the specific advice and pointing to UAAG. More importantly, though, I think this advice belongs somewhere in Section 5 ("Web browsers"), not connected to @alt. What is being discussed here has more to do with browser functionality than it does with one specific attribute (especially given that it applies equally to image inputs and imagemap areas, and that OCR techniques could for example also be useful in the case of background images, canvas and plugin content as well).

That doesn't seem disagreeable.

~TJ

Received on Sunday, 24 January 2010 15:52:49 UTC