W3C home > Mailing lists > Public > public-html@w3.org > May 2008

Re: Is Flickr an Edge Case? (was Re: HTML Action Item 54)

From: Matt Morgan-May <mattmay@adobe.com>
Date: Tue, 27 May 2008 14:56:31 -0700
To: "L. David Baron" <dbaron@dbaron.org>, John Foliot <foliot@wats.ca>
CC: "'Maciej Stachowiak'" <mjs@apple.com>, "'Karl Groves'" <karl.groves@ssbbartgroup.com>, "'Andrew Sidwell'" <w3c@andrewsidwell.co.uk>, <public-html@w3.org>, "'W3C WAI-XTECH'" <wai-xtech@w3.org>, <wai-liaison@w3.org>, "'HTML4All'" <list@html4all.org>
Message-ID: <C461D19F.88E3%mattmay@adobe.com>

On 5/27/08 1:59 PM, "L. David Baron" <dbaron@dbaron.org> wrote:
> So you're saying that you prefer people litter their meaningful
> images with alt="" so that it's harder to distingush the meaningful
> ones without useful alternate text from those that are purely
> decorative?

If the alternative is having to distinguish between those two cases and a
third case where @alt was simply ignored, then yes, "littering," as you put
it, is preferable. However, your argument appears to be based on a belief
that the majority of authors would rather create bogus alt text to satisfy
the validator than create usable alt text, which is a theory I strongly
dispute.

> Would you agree that something like alt="[PHOTO]" or alt="[IMAGE]"
> would be better for users in  that case than alt=""?

Photo, maybe, and only if it is, in fact, a photograph. Image, no, since
that's what screen readers announce anyway.

This approach (or "_none", or any other overloading of the content of @alt)
also has implications for i18n, as well as existing assistive technology,
which will read out loud whatever is specified without parsing it.

> If so, would you agree that it's worth standardizing what should be
> used to mark such a case rather than having authors pick "[IMAGE]"
> or "[PHOTO]" or their own variant?

I don't see the value in taking what should be a token and throwing it into
an attribute of type text. It strikes me as lazy.

-
m
Received on Tuesday, 27 May 2008 21:57:44 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:31 UTC