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

Re: Images and alternative text

From: Jon Barnett <jonbarnett@gmail.com>
Date: Sun, 10 Aug 2008 23:28:52 -0500
Message-ID: <bde87dd20808102128g3e82f75aredfef62d9a4088bd@mail.gmail.com>
To: "James Graham" <jg307@cam.ac.uk>
Cc: "Ian Hickson" <ian@hixie.ch>, "Philip Taylor" <pjt47@cam.ac.uk>, "public-html@w3.org" <public-html@w3.org>
On Fri, Aug 8, 2008 at 7:40 AM, James Graham <jg307@cam.ac.uk> wrote:

>
> James Graham wrote:
>
>    <img src="..." alt="The fraction x over y is equal to 1 divided by the
>>>  fraction y over x.">
>>>
>> It's impractical to expect people to do this if the method of generating
>> the page is conversion of TeX-like source to HTML (which it almost always
>> is), especially for complex expressions (there is a reason for using a
>> symbolic language after all). I don't think that making the low-effort
>> solution break at random on the basis that people should use a solution that
>> is orders of magnitude more effort is going to improve overall
>> accessibility.
>>
>> Even without this specific example I think using random microsyntaxes in
>> existing attributes is a bad idea for the reasons Phillip mentioned.
>>
>
> (one day I will learn that Philip only has one l...)
>
> As an alternative proposal with similar semantics I suggest that instead of
> hacking a microsyntax into alt we add a boolean attribute to image called
> no-text-equivalent (I don't care about the dashes if they are considered too
> unlike other attribute names). If this attribute is present the content of
> @alt would be a category to which the image belongs i.e. instead of:
> <img src="img_1234.jpg" alt="{Photo}">
> we would have
> <img src="img_1234.jpg" alt="Photo" no-text-equivalent>
> This has several advantages:
>
> No unexpected behavior from reasonable alt text that just happens to match
> the microsyntax. For example under the current proposal authors wishing to
> provide equivalent text for an image image of a pair of curly braces, or
> authors wishing to provide an image representing a smilie like {8-} are
> forced to use workarounds like inserting extra whitespace into @alt. This is
> something that people will get wrong and not notice.


The current spec is better because it's more backward compatible.  Even if
the UA doesn't understand the {} syntax, it still might present/display the
{} characters somehow, which is still better than throwing out the bare word
"photo" on the page.

If {} characters are bad, are there other special characters that would work
better?
-- 
Jon Barnett
Received on Monday, 11 August 2008 04:29:28 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:57 UTC