Re: Investigating the proposed alt attribute recommendations in HTML 5

2007-08-30 08:32:16 -0500 "Jon Barnett" <jonbarnett@gmail.com>:
> On 8/29/07, Leif Halvard Silli <lhs@malform.no> wrote:
>>>> On 29/08/2007, Jon Barnett <jonbarnett@gmail.com> wrote:

>>> […] All of the @alt attributes on that page would
>>> serve better as @title attributes - they're descriptions, not
>>> alternates.  (And in turn, I wouldn't be opposed to requiring @title
>>> when @alt is omitted)
>>
>> So, you are putting the most weight on the semantic meaning of
>> "title" and "alt" - rather than on the functions they have: Alt= is

> For the record, no, I wasn't trying to put more weight on their
> semantics than their functions, but I'm implying that the semantics
> exist for a reason, and they can still be presented differently.  When
> @alt is present, JAWS could announce the @alt text without announcing
> the presence of a graphic.  If @alt is missing and @title is present,
> JAWS could announce the presence of a graphic and the @title text.
> (If both are present JAWS can still make it possible to present @title
> if it wants to in some way, just like it might for any other element
> with a @title).  The point being that there's a difference in the
> semantics, and a slight difference in their presentation based on
> those semantics.  I don't know how feasible that is, but it's a way to
> present the content that matches the proposed semantics.

There is difference. But in this debate, the purist argument have used to say that no alt is better than a bad alt. I also think that the purist argument, the «no, that is not alt text, that is title text», have lead to insecurity for authors - am I doing this right now? Insecurity perhaps leads to dropping of both attributes ... 

I am living in a country were every forreign langugage movie on the TV or the cinema, is supplied with parallell content - the films are subtitled. As most films are in English, I could probably also live without it. But often I compare speech and translation - because it is helpful. 

The alt= text might be just what you want to have - as reader. Just as I sometimes want to read an alternative version of a text, for instance I might want to read the english origional of the norwegian translation,  I would sometimes want to read the alt= text to get a clearer picture (sic)  of the what the image tells, rather than having to rely on the catchy text of the TITLE= attribtue.

Also, I would maintain that TITLE is often not used as intended. In a recent message, allthough the text dealt with ALT=, Lachlan gave an example of how TITLE _in theory_ can be used [1]:
                                                                         
	<img src="http://imgs.xkcd.com/comics/cat_proximity.png"
      alt="As a human approaches a cat, intelligence decreases and the
           inanity of statements increases. e.g. A man says to a cat:
           'You're a kitty!'">
      title="Yes you are!  And you're sitting there!  Hi, kitty!" >

But very few put catchy titles like that in the TITLE attribute. 

> My comment about requiring @title would satisfy the need for
> accessible markup without changing semantics.  Are you suggesting that
> the semantics of @alt be changed to serve as either an alternative OR
> a description?  (Obviously in the given example, @alt-as-a-description
> is better than nothing, but I would still prefer the better semantics
> instead of codifying @alt-as-a-description)

I would ask: What does «alternative content» mean? Whatever you put inside ALT becomes alternative content.

The draft says «The alt attribute does not represent advisory information. User agents must not present the contents of the alt attribute in the same way as content of the title attribute.»

This almost sounds like: «Do not rush to make the ALT text available».

So how do I get access to alt= text the simplest way as reader? Must I turn of all image display first?

[1] <http://lists.w3.org/Archives/Public/public-html/2007Aug/1039.html>
-- 
leif halvard silli

Received on Friday, 31 August 2007 00:31:52 UTC