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

If you pay for my ticket, and put me up in a nice hotel, I'll wear
sackcloth and ashes ...

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

Matt's point is absolutely spot on.

Anything that the user agent derives will most likely only make things
worse. It would probably be better not to have anything at all. The
specification should never even give the slightest implication that
the author is off the hook on this one.

Authoring tools are doing a better job now, of making it easier to add
the alt text. If the author doesn't, the tools themselves will attempt
to "repair" the omission, and at that point, the author than gets to
see what others will see, and still have a chance to fix the alt text
themselves.

Left to the user agent, goodness knows that the clever little darlings
will derive. Whatever it is, it won't be consistent and is very
unlikely to even remotely reflect what the author wants. Worse though,
is the author may not even be aware of what's being displayed,
instead.

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

Absolutely spot on, again. This type of information should be in Section 5.

The existing paragraph and most of the discussion has been specific to
one implementation of HTML, not anything that is markup specific. We
should say when an attribute is required, and provide a clear
definition of what's required as content. Period.

> -
> m

Now excuse me, I must return to my dastardly plot to commit havoc on
the interwebs.

Shelley

Received on Sunday, 24 January 2010 14:14:32 UTC