W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > July to September 2004

[re-send of] Re: handling of HTML title attribute

From: Al Gilman <Alfred.S.Gilman@IEEE.org>
Date: Wed, 1 Sep 2004 11:24:56 -0400
Message-Id: <p06110404bd5b99fe2b82@[10.0.1.2]>
To: w3c-wai-ua@w3.org
Cc: "Johannes Koch" <johannes.koch@fit.fraunhofer.de>

Two different user agent behaviors encourage two different author
behaviors, here. And vice versa.

The use of the 'title' attribute as a tooltip, a transient
onMouseOver display, encourages the authors to write supplemental
text in that attribute.
http://lists.w3.org/Archives/Public/w3c-wai-ua/2003JanMar/0054.html

The use of 'title' as a [natural language sense of 'title']
identification of the link is rational if the user agent behavior is
to switch between the title and the link content as the source of the
text version.

Either pairing of author behavior and user agent behavior makes sense
when they are matched up right. What we have now is the free mix and
match of the two author behaviors with the two user agent behaviors
which generates a lot of garbage on mismatches.

There has been confusion in the community about a) whether 'alt' or
'title' text should be used as the tooltip, and b) whether 'add' or
'replace' behavior is appropriate when electing to display the
'title' attribute in a textual reading of the document.

We probably won't solve this problem without attacking the root cause
of the problem. The idea that the text range sensitized for clicking
should be a complete, standalone identification of what the link does
is unnatural in terms of human factors in the visual delivery
context. The natural tendency for visual use is to make the button,
the clickable portion, of the *climax* of the association with the
remote, linked document. It is not what you need to know before you
go there to decide if you want to go there, but how you will recall
the linked document after you have been there and have a rich memory
to associate with.

The kind of thing that we could do with XHTML 2.0 might be like

<li href="linkToDestination">
For more information about this,
<span role="unifiedWidgets:button">click here</span>
</li>

The 'list of links' view would pick up the content of the element
bearing the href attribute.

The click sensitivity in GUI mode would extend [by default] only over
the display region for the text ranged assigned the 'button' role
within that content. This fits the very common practice of offering
lists of links. If an icon and a text phrase are both clickable,
there could be two sub-elements with the role of 'button' but only
one destination through the 'href' attribute at the outer 'li'
element.

Writing the 'title' attribute for the list-of-links view and the link
text for the GUI view is simple for the author to understand and do
right. Expecting the author to write something that will come out
right after weird text-mungeing processes is very likely to be weak
in its uptake and buggy in its implementation where it is taken up.

If the author authors that way, it is useful for the User Agent to
display only the 'title' and not the link content, no matter how
unorthodox this is with respect to the original intent of the vague
specification. If the 'title' and link text are duplicates, then
saying them both not only wastes time, it is a major source of
confusion for the listener trying to assemble the sounds into a
sentence or menu list item.

The 'real answer' (XHTML 2.0) is to allow the author to write either a
supplement or a replacement but require them to identify (by
different markup) which it is that they feel they have supplied.

In backward-compatible usage we have the option of trying to convince
authors and screen readers to follow one practice or the other
universally, or of introducing conventions for metadata saying which
assumption the author made and asking the AT to adapt to the intent
of the author, when documented.

This is part of the late-blooming realization that the verbosity and
baby-step-ness of the user interaction should adapt to the delivery
context, the actual conditions under which the content is being used,
along with colors and font sizes.

Al

At 8:58 AM -0400 9/1/04, david poehlman wrote:
>I don't have your quote handy from the spec, but as I read it and as I
>understood it as we were developping it, title was considered to be
>addative.  I wonder if it's part of the erratta? I wonder if there are
>techniques or perhaps something in the test suites that provide guidance?
>
>Johnnie Apple Seed
>
>----- Original Message -----
>From: "Johannes Koch" <johannes.koch@fit.fraunhofer.de>
>To: <w3c-wai-ua@w3.org>
>Cc: <w3c-wai-ua@w3.org>
>Sent: Wednesday, September 01, 2004 8:35 AM
>Subject: Re: handling of HTML title attribute
>
>
>
>david poehlman wrote:
>>  As I read this, jaws is behaving in reaction to the real world
>
>Do you know a real-world example that makes it necessary to render the
>title attribute instead of the link text?
>
>>  but you are
>>  correct, were title used appropriately, it would be addative, not
>>  juxtaposed.
>
>My problem is not only the screen reader configuration but also the
>passage in the UAAG spec which permits it.
>--
>Johannes Koch - Competence Center BIKA
>Fraunhofer Institute for Applied Information Technology (FIT.LIFE)
>Schloss Birlinghoven, D-53757 Sankt Augustin, Germany
>Phone: +49-2241-142628
Received on Wednesday, 1 September 2004 15:32:28 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:33 UTC