Re: handling of HTML title attribute

It's interesting though that the spec says that the title attribute offers
advisory information.  Example notwithstanding, this would seem to indicate
that that it would not be appropriate to use it as a replacement for link
text.  Maybe the problem is that we have title for link and perhaps should
disallow it.  At any rate, I do understand the need to seek clarity and to
make it possible for as many users as possible to benefit.

Johnnie Apple Seed

----- Original Message ----- 
From: "Al Gilman" <Alfred.S.Gilman@IEEE.org>
To: <w3c-wai-ua@w3.org>
Cc: "Johannes Koch" <johannes.koch@fit.fraunhofer.de>
Sent: Tuesday, September 07, 2004 11:12 AM
Subject: Re: handling of HTML title attribute



At 11:54 AM -0400 9/1/04, david poehlman wrote:
>Part of the problem here is the use of title.  Title should always be able
>to be addative.  Link text is primary at all costs.  I should then be able
>to have both title and link text in links list if that is my desire but I
>should not have to have title in a links list if the link text primary is
>provided sufficiently.  In other words, link text should be necessary,
title
>should be supportive.  I can or should be able to do with or without title
>but refferably I would have it available to me through the ua/at/uaat.

Well, that's been our general idea of how the world should work, in
the WAI, so far as I know. On the other hand, I don't see an iron
clad argument for why that is required by any of the formal documents,
or that it is an unqualified best answer from first principles.

The UAAG does say, in addition to the checkpoint that Johannes cited,

<quote cite=
"http://www.w3.org/TR/UAAG10/guidelines.html#tech-doc-content-access">

2.1 Render content according to specification (P1)

</quote>

What did the HTML specification say?

<quote cite=
"http://www.w3.org/TR/html401/struct/global.html#adef-title">

title =text
This attribute offers advisory information about the element for
which it is set.

Unlike the TITLE element, which provides information about an entire
document and may only appear once, the title attribute may annotate
any number of elements. Please consult an element's definition to
verify that it supports this attribute.

Values of the title attribute may be rendered by user agents in a
variety of ways. For instance, visual browsers frequently display the
title as a "tool tip" (a short message that appears when the pointing
device pauses over an object). Audio user agents may speak the title
information in a similar context. For example, setting the attribute
on a link allows user agents (visual and non-visual) to tell users
about the nature of the linked resource:

....some text... Here's a photo of
<A href="http://someplace.com/neatstuff.gif" title="Me scuba diving">
     me scuba diving last summer
</A> ...some more text...

</quote>

Note the following things:

1) The specification doesn't clearly say whether the 'title' attribute
should
be a supplement or a replacement for the element content.

2) The example given is of something that makes sense as a replacement
and would be a repetitious nuisance if read in addition to the link content
in audio.

3) The tooltip use case doesn't really force a strong preference on the user
for a supplement or a replacement.  In the transient visual display,
something
supplemental or an expanded or summarized text fragment all make sense.
And in the visual scenario the user has the option to refer back to the
content
or not as they find convenient and the author or the UA never knows any
better.

So there is nothing firm in the specification to say that it has to
be supplemental
or suitable as a replacement.

I will admit that there is nothing in the HTML specification to
suggest that the
link text is 'conditional content' in the words of the UAAG.

Between the HTML Specification and the UAAG, even taken together, there is
no clear specification basis to say that the 'title' attribute on an
A element should
be supplemental and not fit to replace the link content, or that the
link content
always must be included in the audio display regardless of whether the
title is spoken or not.

Beyond that, we have to deal with the fact that if we insist on this
interpretation,
we have created a demand on the author that is not so easy to satisfy as if
the
'title' is allowed to be something that would serve standalone as a
stand-in for
the link.  This is, after all, the common English sense of the word
'title.'  While
the XAG says "don't rely on the mnemonic sense of the code name as defining
anything, we have to face the fact that it is powerful in coaching
author behavior.

It's hard to get authors to conform to a definition that is at
variance with the plain
sense of the name of a data field they are populating.

We have also found that examples in the specification speak louder for
authors
than the rules of the specification.  And the example in the specification
also
encourages the authoring of 'title' attributes on the premise that they
could
replace what they title in a summary view.

>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 11:18 AM
>Subject: Re: handling of HTML title attribute
>
>
>
>Example:
>
>Link Text: documentation on some topic
>Advisory information: this document requires an ABC plugin
>
>Markup according to HTML spec:
><a href="http://www.example/" title="this document requires an ABC
>plugin">documentation on some topic</a>

Not  so fast -- either way is 'advisory' information, whether
supplemetal or standalone.

>visual: _documentation on some topic_ [this document requires an ABC
plugin]
>
>spoken [only content]: "documentation on some topic"
>spoken [only title]: "this document requires an ABC plugin"
>spoken [longest]: "this document requires an ABC plugin"
>spoken [content and title]: "documentation on some topic. this document
>requires an ABC plugin"
>
>
>Al Gilman wrote:
>
>>  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.
>
>So the title attribute does not contain only advisory information, but
>all required information for the link.
>
>Markup according to you:
><a href="http://www.example/" title="documentation on some topic (this
>document requires an ABC plugin)">documentation on some topic</a>

Not quite.

<p>
For more on topicFoo see the
<a href='http://www.example.com/lib/foo/manual.abc'
title="topicFoo - document requres ABC plugin">
Manual</a>.  You can get the plugin
<a href='http//abc.example.com/downloads/plugin.rpm'
title="download ABC plugin">here</a>.

Visual:

          fleetingly, onMouseOver   >>           [topicFoo - document
requires ABC plugin]
                                                                /
For more on topicFoo see the _Manual_.

Spoken in isolation [only content]:  "*link*: Manual"
                                                        "*link*: here"

User either has ABC plugin installed or learns they need it when the
Manual won't open.

Spoken in isolation [only title]:        "*link*: topicFoo - document
requires ABC plugin"
                                       "*link*: download ABC plugin"

Spoken in isolation [longest]: -- same as only title

Spoken in isolation [title, break, content]:
                                       "*link*: topicFoo - document
requires ABC plugin, Manual"
                                       "*link*: download ABC plugin, here"

Spoken in context [only content]:  "For more on topicFoo see the
*link*: Manual"
                                                        "You can get
the plugin *link*: here"

Spoken in context [only title]:   "For more on topicFoo see the
*link*: topicFoo - document requires ABC plugin"
                                       "You can get the plugin *link*:
download ABC plugin"

Spoken in context [longest]: -- same as only title

Spoken in context [title, break, content]:
                                       "For more on topicFoo see the
*link*: topicFoo - document requires ABC plugin, Manual"
                                       "You can get the plugin *link*:
download ABC plugin, here"

Making the "supplemental text" an expanded, standalone form is
entirely in the same vein as the
practice of 'tapered prompts' in VoiceXML, for example.

http://www.w3.org/TR/2004/REC-voicexml20-20040316/#dml4.1.6

Or layered help.

http://www.w3.org/2002/07/DIAT/posn/trace.html

In other words, this strategy has non-trivial positive credentials
behind it.  Should not be dismissed
out of hand.

Al

>visual: _documentation on some topic_ [documentation on some topic (this
>document requires an ABC plugin)]
>
>spoken [only content]: "documentation on some topic"
>spoken [only title]: "documentation on some topic. This document
>requires an ABC plugin"
>spoken [longest]: "documentation on some topic. This document requires
>an ABC plugin"
>spoken [content and title]: "documentation on some topic. documentation
>on some topic. This document requires an ABC plugin"
>
>--
>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 Tuesday, 7 September 2004 15:58:22 UTC