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: Thu, 21 Jan 2010 08:20:25 -0600
Message-ID: <643cc0271001210620p4e08b20et91966b5b53d468ad@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Maciej Stachowiak <mjs@apple.com>, Matt May <mattmay@adobe.com>, HTML WG <public-html@w3.org>
On Thu, Jan 21, 2010 at 2:44 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> I don't understand why we would *forbid* UAs from improving image
> accessibility by whatever means they can.
>
> However I do agree with the change proposal in that I would be fine
> with removing the current text. However I would suggest replacing it
> with a general statement that UAs are allowed to improve accessibility
> in any way it can. Even if that goes against the letter of the spec.
>
> This is similar to how I think the spec should say that UAs should be
> allowed to deviate from the spec for security reasons if the UA so
> desires.
>

That's a dangerous precedent to take.

If a UA sees the potential for security risks in any of the specs, it
should be working, now, to ensure the component leading to the risk is
removed, or altered.

> In practice UAs are going to put security above what the spec says
> anyway. And I suspect that if they can improve accessibility they are
> going to do that too. But I would be very sad if a UA decide not to
> improve accessibility for its users because the spec says that is not
> allowed.
>

If the UA will do so, and I agree, they should, as security takes
precedence over adherence to specifications, they don't need text in
the spec saying it's OK to do so. We do not need to state the obvious.

Removing the sentence doesn't say UAs aren't allowed to improve
accessibility -- it's just removing what amounts to an
overspecification.

> / Jonas
>

Shelley
> On Wed, Jan 20, 2010 at 6:55 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>>
>> I haven't seen any follow-up discussion. I'm interested in hearing what the rest of the Working Group thinks. Does anyone strongly agree with Matt that the sentence he objects to should be removed? Does anyone strongly feel that the sentence should be retained? Does anyone have alternate wording to suggest that might be acceptable to everyone?
>>
>> My own feeling is that I don't care much either way. I'd like to see whether anyone else in the Working Group has an opinion on this issue before we decide how to proceed.
>>
>> Regards,
>> Maciej
>>
>> On Jan 16, 2010, at 8:38 PM, Maciej Stachowiak wrote:
>>
>>>
>>> On Jan 15, 2010, at 2:20 PM, Matt May wrote:
>>>
>>>> I have completed my Change Proposal for ISSUE-66 (Remove Image Heuristics paragraph from img Element Section):
>>>>
>>>> http://esw.w3.org/topic/HTML/ChangeProposals/ImageHeuristics
>>>
>>> Thanks, I have recorded this on the status page.
>>>
>>> - Maciej
>>>
>>>>
>>>> Summary:
>>>>
>>>> In the absence of evidence (or implementation in browsers), the current draft suggests that image heuristics algorithms may be used to recover from images with missing @alt. The technology not only does not exist: it cannot exist.
>>>>
>>>> It's possible that Google Goggles was the proposed implementation of image analysis heuristics here, but while it may perform well with well-defined objects with large databases of established imagery, it is not a cure-all for the problem of missing @alt -- and if it were, in fact, that good, it would be better positioned as a tool for the authoring process than in the browser.
>>>>
>>>> The reason for this is that images themselves are only place markers for what the author intends to express. It is the author, then, and not the image, that is most responsible for determining what fits best as alternate content. And for this reason, no automated tool can possibly claim to sufficiently repair missing @alt content. This sentence only serves to make that less clear.
>>>>
>>>> User agents may use any technology they choose to improve the user experience for users with disabilities. Such an implementation may in fact have positive effects, in certain cases. However, it is not necessary to specify this, particularly if by doing so the necessity of human-created @alt is made less than perfectly clear.
>>>>
>>>> A second problem is that @alt, when contained within an anchor, is according to best practice used to describe the purpose of the link. Consider the following code, which is extremely common:
>>>>
>>>> <img src="diskette.gif" alt="Save">
>>>>
>>>> The intent of the graphic is to convey, through a common icon, that the control using this image saves current work. An image heuristic would not find "Save" but instead an image of 3.5" diskette. Replacing the image with a description is not necessarily a good indication of the author's intent, even when the description is accurate.
>>>>
>>>> Finally, image analysis systems such as Google Goggles require enormous (as in upper terabytes to lower petabytes) databases of content in order to function at anything better than parlor-trick levels of efficacy. At the moment, the only available provider for such a service is Google. This is, in effect, a binding in the specification to a closed-source, single-provider service, which sets a dangerous precedent.
>>>>
>>>> I have updated the ChangeProposals page with this one:
>>>>
>>>> http://esw.w3.org/topic/HTML/ChangeProposals
>>>>
>>>> -
>>>> m
>>>
>>>
>>
>>
>>
>
>
Received on Thursday, 21 January 2010 14:21:00 GMT

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