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

Re: ISSUE-66 Change Proposal: no change

From: Shelley Powers <shelley.just@gmail.com>
Date: Tue, 9 Mar 2010 13:23:27 -0600
Message-ID: <643cc0271003091123i4974a881i3e04bc6b67a6fe12@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: public-html@w3.org
I've been told that my alt text is too wordy in the example.

So let's say:

"Bear cub using paws and tongue to get at peanut butter smeared inside a
ball"

I don't want to sidetrack the discussion about automated processes deriving
user intent, with what is or is not "good" alt text.

Shelley

On Tue, Mar 9, 2010 at 8:07 AM, Shelley Powers <shelley.just@gmail.com>wrote:

>
>
> On Tue, Mar 9, 2010 at 4:44 AM, Ian Hickson <ian@hixie.ch> wrote:
>
>>
>> SUMMARY
>>
>> There is no problem and the proposed remedy is to change nothing.
>>
>>
>> RATIONALE
>>
>> There is no problem.
>>
>> One other change proposal says that no technology exists to convert images
>> to text. However, this is not true; for example OCR technology has existed
>> for decades and is widely available in both commercial off-the-shelf and
>> open-source packages.
>>
>
> There is no software that can determine the web page author's intent when
> placing an image in a page.
>
> A scenario: a car maker creates an ad page featuring one of its hot new
> cars. The car is in a street scene, pulled up in front of a stop sign. The
> word "Stop" is legible. OCR's interpretation of the image does not reflect
> the ad creator's interest in pointing out how nice the car looks, how sleek,
> and fast, No, instead the OCR technology would reduce the entire image down
> to one word: stop.
>
> Another scenario: the web page author takes a photo of a bear cub at the
> zoo, as it tries to stick its head into a ball that has peanut butter
> smeared on the inside. The intent of the photo is to show how cute the cub
> is, how tenacious its efforts, how difficult the prize.  Alt text could be
> along the lines of, "A very young bear cub, determinedly trying its best to
> shove its overlarge paws and nose into a plastic ball that has peanut butter
> smeared on the inside--bright pink tongue extended as far as it can to
> access the tasty treat."
>
> The best image recognition software: bear holding round object. If there's
> a lot of areas of high contrast--dappled light, strong shadows, we probably
> wouldn't even get bear -- we'd get some form of animal holding some form of
> object. It would never "see" cute. It can't "see" determined.
>
> There is no image software in the world, there never will be, that is fully
> capable of understanding _why_ the person who added the photo to the page,
> did so. The most any of the most sophisticated, cutting edge applications
> can do is determine words, whether appropriate to the intent of the image or
> not, or provide a blunt assessment of the image. They can't convey "cute" or
> "determined", "fast", or "sleek", because these are subjective values.
>
> An image is more than the sum of its parts.
>
>
>
>> That other change proposal also suggests that the spec might make it
>> unclear that authors should be the ones that give alternative text, rather
>> than automated tools. However, to draw such a conclusion one would have to
>> ignore the pages and pages of detailed instructions on how authors must
>> write alternative text, and one would have to ignore a big warning placed
>> immediately adjacent to the controversial paragraph asserting in no
>> uncertain terms that "authors must not rely on such behaviour".
>>
>>
> Why muddy the topic, though? With big, garish red letters? Why not keep it
> simple: authors, do this. Clean, simple, to the point, without a lot of
> extra words, extra text, garish red letters, and vague references to
> wonderful technology ...that doesn't exist, and in effect, can't exist.
>
> Why can't we just keep things simple?
>
>
>> That other change proposal further suggests that we should not suggest to
>> implementors that they help users understand images, because they will do
>> so without prompting. However, this would be inconsistent with the style
>> of the specification, which is to be explicit about everything and to
>> leave nothing to chance, especially not something as important as
>> accessibility.
>>
>>
> I strongly recommend that you re-do your change proposal and include
> references to the other change proposals, because I haven't a clue which
> change proposal you're talking about here. I'm only aware of one change
> proposal: Matt's original. And that's all that shows in the Issues Status
> page.
>
>
>
>> Another change proposal suggests that not including more detail would be
>> missing out on an opportunity to increase competition in the field.
>> However, there's no reason to go overboard; just mentioning one simple and
>> unambiguously possible technique like OCR should be enough.
>>
>>
>>
> ditto -- Matt's change proposal does not reflect this text. If you're
> referring to the email discussion, those aren't change proposals. That was
> just people saying things.
>
>
>
>> DETAILS
>>
>> Change nothing.
>>
>>
>> IMPACT
>>
>> POSITIVE EFFECTS
>>
>> Leaving the text in will encourage implementors to explore the boundaries
>> of alternative text repair techniques, increasing the overall
>> accessibility of the Web over time.
>>
>> NEGATIVE EFFECTS
>>
>> Leaving the text without change might fail to highlight possible future
>> work, such as performing landmark recognition or facial recognition in
>> photographs, reducing the chances that an implementor will investigate
>> these groundbreaking image analysis techniques in the context of
>> alternative text repair.
>>
>>
> I think we can safely say that we've never seen any company fail to use its
> newest, wizziest, coolest technology, just because there's nothing in a
> specification that says, "It's OK, you can innovate, now".
>
>
>
>> CONFORMANCE CLASS CHANGES
>>
>> None.
>>
>> RISKS
>>
>> It is suggested that mentioning that user agents might be able to repair
>> non-conforming pages could make authors less likely to write conforming
>> pages, though it is not clear why this would apply here and not in the
>> many other parts of the spec that mention repair techniques, especially
>> the sections that explicitly mandate specific user agent repair
>> techniques.
>>
>>
> There is a world of difference between repairing an unclosed element, and
> determining why Jane or Joe put a picture of a bear with a ball on a web
> page.
>
> There are some things that can't be repaired. For these, we rely on people,
> scary as that may seem to be.
>
> --
>>
>> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
>>
>
>
> Shelley
>
>
Received on Tuesday, 9 March 2010 19:23:57 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:59 UTC