Re: Discussion on Change Proposal for ISSUE-66

On Sun, Jan 24, 2010 at 10:49 AM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> On Jan 24, 2010, at 8:04 AM, Shelley Powers wrote:
>
>> 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.
>
> When alt is completely missing, most browser + screen reader combos will read the filename. That is simply a fact. What authoring tools do is interesting, but doesn't factor into it. Using *no* repair techniques is something that no reasonably accessible browsing solution does. (Of course, many image filenames are terrible, and screen readers don't pay attention to whether they have something human readable, but that's exactly why better repair techniques are worth considering. Try using a screen reader sometime, it is quite educational to see what the experience is like.)
>
>>
>> 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.
>
> A sane implementation would do it only when an assistive technology that needs the text is being used, and only on demand. That's how substituting filenames works - doesn't bother to truncate the URL into a filename until that particular image is visited. The way screen readers typically work, you have a virtual "cursor" that's over some place in the document, and that's the only place you need full info for at that particular moment. Also, OCR is not actually that computationally expensive.
>
>> 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.
>
> Screen readers do all sorts of different things today to adapt content that is not properly accessible. And that's ok. It's a quality-of-implementation issue.
>
>>
>> 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.
>
> Nor does the filename typically convey author intent. But screen readers do in fact read it when alt is missing, and things are ok.
>
>>
>> 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.
>
> I'm kind of confused. On the one hand, you say it would be terrible for browsers to every use repair techniques for missing alt, but on the other hand, here you say that it's fine to allow repair techniques and cite UAAG's info on the topic.
>

Please don't misconstrue my words. I said that the browser companies
should work with the accessibility groups to see what type of
information should be included, and where. Putting general statements
into a specification that is specific to browsers is not the same as
embedding bits of it all over the HTML specification, obfuscating the
roles and responsibilities of other parties.

In the meantime, we need to respond to Matt's change proposal. His
proposal states to remove the one section. Not replace it with
something else. Not "soften the text" or provide a detailed listing of
what tools can now do with images. Remove the section.


> Regards,
> Maciej
>
>

Shelley

Received on Sunday, 24 January 2010 17:03:54 UTC