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

Re: Discussion on Change Proposal for ISSUE-66

From: Shelley Powers <shelley.just@gmail.com>
Date: Sun, 24 Jan 2010 10:04:12 -0600
Message-ID: <643cc0271001240804u34039ba6k7589a36d2af5b8a5@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Matt May <mattmay@adobe.com>, John Foliot <jfoliot@stanford.edu>, Maciej Stachowiak <mjs@apple.com>, HTML WG <public-html@w3.org>, "public-html-a11y@w3.org" <public-html-a11y@w3.org>
On Sun, Jan 24, 2010 at 9:52 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 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).

The use of the filenames typically happens with the authoring agents.
File names, or titles of post are fairly common. And again, when the
author sees the result, they are more likely to do the correction when
the material is posted.

And this action occurs once, when the material is created. Think about
the CPU usage if Chrome performs OCR on every single image in a photo
gallery that don't have the alt text. Frankly, no user agent would do
this -- it would be irresponsible, and a misuse of the user's
computing resources.

And then one browser does this, another does that, a screen reader
does a third option, another user agent does a fourth -- this is what
we want? I will repeat: we are better off with them not doing
anything.

In addition, OCR can not determine author intent. We, the visually
capable can, when we look at the entire image in context, because of
some silly expression, or some other obviousness with the image. All
OCR can do is a vague translation of some of the contents -- the
context is completely lost. It does not convey author intent. It
can't, it never will.

The alt text is an author responsibility. Anything else undermines this.

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

They do not exist now.

I suggest that the browser companies work with the accessibility task
force, to see about where this type of information can be cleanly
incorporated, and into what document. In the meantime, let's leave the
alt attribute cleanly defined.

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

Then it seems we are in agreement on this. Again, though, I would
recommend that those concerned work with the accessibility group to
determine what information should be presented, in what document, and
where in the document.

> ~TJ
>

Shelley
Received on Sunday, 24 January 2010 16:04:47 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:13 UTC