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

Re: Investigating the proposed alt attribute recommendations in HTML 5

From: Leif Halvard Silli <lhs@malform.no>
Date: Fri, 31 Aug 2007 20:29:44 +0200
Message-ID: <132693e8de1e7e561232e99e9b1f4da5@10013.local>
To: public-html@w3.org
Cc: Sander Tekelenburg <st@isoc.nl>

On 2007-08-31 17:06:51 +0200 Sander Tekelenburg <st@isoc.nl>:
> At 13:39 +0200 UTC, on 2007-08-31, Leif Halvard Silli wrote:
>>>> On 2007-08-30 18:06:26 +0200 Sander Tekelenburg <st@isoc.nl> wrote:
>>>>> At 05:43 +0200 UTC, on 2007-08-30, Leif Halvard Silli wrote:

>>>>> [...]

>>>>>> The HTML5 draft says that TITLE and ALT should be showed in
>>>>>> different ways.  But perhaps is enough to say that they should be
>>>>>> showed in different ways only if the element has both a TITLE and
>>>>>> an ALT text?
>>>>> I'd think that would result in inconsistent behaviour, which would
>>>>> hurt usability.
> [...]
>> I was just reading the text of the draft: «User agents must not present the
>> contents of the alt attribute in the same way as content of the title
>> attribute.»
> Right. That text makes perfect sense to me. It intends to ensure that UAs
> make it clear to the user which is the textual equivalent, and which the
> advisory information.

That is how it sounds, literally. But as there are no GUAs (I think) that let you see both ALT text and TITLE text simultaneously  or consecutively - without a reload, the text does not speak about reality. 

And given the attitude towards the (un)necessity of ALT=TEXT of the drafters up until now, we have little reason to think that the text want to say that the users must have access to both texts.

To lift the cat out of the bag: this text is just a critisim of Internet Explorer for showing ALT texts as tool tips, when TITLE isn't available. (For the record: iCab does the same thing, but the condition isn't TITLE but SRC: When SRC is wrong, you can read the alt text in the document and as tooltip, [because in iCab, the full ALT texts isn't always readable]. When SRC is omitted or empty, you do not see the ALT text in the document at all, but you do get it as tooltip.)

>> A reformulation could be that UAs must present ALT text, only not so that
>> it confused with the TITLE text.
> I don't understand. The current text (that you quoted) says exactly that.

No, it doesnt. My reformalation above is just a logical conclusion about what the text says, if it shall be taken litterally - or to its logical and selfevident end. But it isn't told straight out that both TITLE and ALT must be available to the users.

In fact, there is no place that outlines the relationship between TITLE and ALT, that I can see - except for this little snippet.
>> And since the spec is supposed ot be media independent, this goes for
>> screeen readers as well.
> Of course.
>> (Hence, to say that screen readers can just use TITLE with ALT is not
>> available is backwards.)
> Indeed. But where does the spec say that?

It doesn't. But some have the last days proposed that screenreaders can simply show the TITLE= when ALT= text is not available. Jon Barnett even suggested that we could change the requiremenst to say that there must be either a TITLE or a ALT [1]:

	My comment about requiring @title would satisfy the need for
	accessible markup without changing semantics.

and [2]

	(And in turn, I wouldn't be opposed to requiring @title when @alt is

And I am just pointing out that this is speaking against the media independence aspect. The accessibility aspect is also a media independence aspect.

The draft says:

        If the src attribute is omitted, the image represents whatever
        string is given by the element's alt attribute, if any, or
        nothing, if that attribute is empty or absent.

But if one *really* think that it is enough that either TITLE or ALT is availble, then we should add something like this:

	    «If the src and alt attributes are omitted, the image represents 
        whatever string is given by the element's title attribute.»

> All I know is that some UAs (Jaws) have been reported to be configurable
> (might be the default; that hasn't been reported) to present the contents of
> @title when @alt isn't available. We don't even know if in that case the UA
> indicates that it is reading @title.

I know. And now we are discussing browser behaviour - not author requirements. That is confusing. In order to test what the author requirements could lead to, Joshue have been performing user tests. When we got the results, some were reacting by saying that Jaws should change its behaviour. 
>> The «side-by-side» here is valid about TITLE vs. ALT: _they_ must not be
>> presented in such a way that you do not understnad what is TITLE and what is
>> ALT.
> Indeed.
>> I do (of course) not think that ALT and the image should be presented side
>> by side.
> Well actually I *do* think that UAs should make it possible for users to
> consume multiple equivalents simultaneously.

OK - then we are in agreement, I think. Except I would not say that it matters _that_ much whether it happens simultaneously or consecutively. What matter is that the user can load the document, and opt to see the alt text for a certain image - either simultaneously or consecutively, without having to do extraordinary stuff - like turning off _all_ images, reloading the document etcetera etcetera. User should be able to focus on one particular image and get the ALT text as well as its title.

>  We've had the examples of
> needing to read a transcript along with listening to audio; the example of
> someone relying on screen magnification who wouldbe helped by being able to
> consume both the image and the textual equivalent; and just the plain and
> simple case where it is just not clear to anyone what the image is meant to
> convey.
> So IMO UAs must by default present only a single equivalent, but should make
> it possible for users to consume multiple equivalents simultaneously. I
> wouldn't mind at all if that sentence would be added to the spec.

Absolutely, the spec should be made clearer about this. It must not only be possble but simple ... as I said above.

> [...]
>> Btw, I think the proper description of TITLE is to say that it is about
>> (describing the) _context_. A flag can have different meanings. But TITLE
>> can advice us that alt="English" refers to TITLE="Nationality".
> Sure. To the best of my knowledg that's what both HTML 4.01 and HTML5 say:
> @title is for advisory information.

For myself, 'context' helped me understand better. Title can tell about the authors intent. A good TITLE therefore, can help make the ALT text shorter.

[1] <http://lists.w3.org/Archives/Public/public-html/2007Aug/1158.html>
[2] <http://lists.w3.org/Archives/Public/public-html/2007Aug/1134.html>
leif halvard silli
Received on Friday, 31 August 2007 18:30:03 GMT

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