behavior matters (why is a TITLE not a title?)

If I recall correctly, there have been problems because

a) Jaws substituted a TITLE attribute, if present, on a text link, for the
text content of the link, with no ifs ands or buts.  The user has no
recourse, it just happens.

b) Authors often put text in the link [A element] TITLE which is
supplemental or auxiliary, dependent on the link element text content to
identify the link target.

Why?

Well, on the one hand Phill Jenkins says, in

  http://lists.w3.org/Archives/Public/w3c-wai-ig/2001AprJun/0588.html

[quote]

But the real problem I have with the TITLE attribute solution is that it
prevents the developer from providing a "tool tip" type additional
information, such as "see field x from the taxpayers W2", which is what the
TITLE attribute is spec'd for.

[end quote]

One might expect that the TITLE attribute is supposed to perform the
function indicated by the natural English sense of the word 'title.'  This
pretty much implies that it stands on its own to identify the object titled.

But Phill is pretty much right.  In the HTML 4.01 specification, this is
not implied and the much weaker language "advisory information" is used.
This could be a standalone title or a dependent supplement; either fits
that description.  Tool tip behavior (transient, adjacent presentation on
pointer over the object) is recognized as a common behavior in browsers,
but not invoked as definitive, or "what it is for," however.

The way Phill put it is clearly what many to most authors _think_ it is for
because it acts that way.  Here we have a case that the popular
understanding reflects a "TITLE is as TITLE does" principle.

In our accessibility planning we have been counting on a more "TITLE is a
title" than "TITLE is a tooltip" semantic.  The designers of the Jaws
screen reader got caught making this assumption.  If the TITLE attribute
were always filled in as a title that could stand on its own to identify
what it decorates, the substitution of TITLE for element contents would not
be what the UAAG asks for, but would in fact not generate a breakdown in
accessibility.

If we are going to have an SVG-like TITLE sub-element serve as "fit for use
in automatic Table of Navigation extraction" we need to make it clearer
that it is to be independent of the other details of the titled object, and
capable of giving a general orientation to what the object is on its own,
without depending on further details inside its object.  Compare the
exhortations concerning providing a TITLE for the root SVG element in the
SVG specification.

 http://www.w3.org/TR/SVG/struct.html#DescriptionAndTitleElements

The role definition for the TITLE on general drawing groups, however, is
not so specific, and veers off in the tooltip direction.

Thus, re-read the SVG specification, 'standalone' is a requirement which is
not present in general even in the SVG TITLE element, as it is not present
in the HTML 4.01 baseline of HTML semantics.  So we have a ways to go, if
we want an language construct which will produce consistent good results
when used to automatically generate orientation to some navigable structure
spanning the document.

Al

Received on Friday, 6 July 2001 15:19:57 UTC