Re: ToolTips: bug or feature?

aloha, chaaals!

let me reiterate my original proposition, which is archived at:
http://lists.w3.org/Archives/Public/public-html/2007Jul/1135.html

ToolTip exposition should be treated as a User Agent question, 
rather than one which can be addressed via HTML -- a user should 
be able to set their user agent to display ALT as tooltips, 
display TITLE as tooltips, display ALT or TITLE (whichever is 
longer) as tooltips, and display no tooltips...

how individuals interact with a document instance is as varied 
as there are document instances -- why outlaw a practive that 
has tangible benefits for a wide spectrum of users?  just as 
one can set one's user agent to render images or not to render
images, one should be able to specify the manner in which ALT 
and TITLE are either exposed or ignored...  this is a question 
of basic usability -- if the markup is there, there must be an
easy and immediate means to expose the markup, whether aurally,
tactilely, or visually...  icons are cultural conventions that 
often serve as shorthand for an action or the firing of an 
event -- if i select a graphically defined hyperlink of a phone,
it really doesn't affect my experience if the ALT text for that 
graphic is NOT "telephone", but "Company Phone Directory" -- ok,
you may reply, the ALT should be "telephone" and the TITLE 
"Company Phone Directory", but most screen readers do NOT allow 
individuals to query for ALT and TITLE seperately -- it is usually 
an either/or proposition, speak ALT, speak TITLE, speak longest, 
which is obviously an insufficient exposition mechanism -- a user 
should be able to set one or the other as default, but should also 
be able to query the object for the other.  another place where 
the user experience should be enhanced and made more flexible when 
it comes to the expansion of ABBR and ACRONYM; currently, many 
scren readers that support ABBR and ACRONYM offer the user only a 
single toggle: "expand contents of ABBR" and "expand contents of 
ACRONYM" when a more efficacious setting would be "expand inline",
"signal the presence of expansions by: [combo box of options]"; and,
of course, the ever important, "expand on demand (in response to 
keystroke [enter keystroke here]";

even titles added to repetitious hyperlink text (for example, 
multiple "Sign In" or "Read More..." to provide extended contextual
information such as:

<a href="pc.html" title="Sign into Personal Checking">Sign In</a>

and

<a href="more-sbc.html" title="Read More About Small Business Checking"
>Read More...</a>

are not queriable; if one wants to hear the TITLE defined for a link, 
there should be a simple querying mechanism, rather than the far more 
common choices offered the user:

"speak hyperlink text"
"speak title"
"speak longest"

optimally, in a "List of Links", a user would be able to toggle between
the display of hyperlink text and the TITLE defined for the link (if 
present)

obviously, setting your screen reader to read TITLE over hyperlink text
inline will cause severe dislocations and interruptions in the rendering 
of a document instance, since the user is relegated to an either/or 
choice...

the main point is, there should be no restriction on the means of 
exposing ALT and/or TITLE, other than the implementor's creativity
and imagination, provided that user agents are capable of providing 
multiple options for their exposition as well as for ignoring them 
altogether...

no one can acurately predict who will be interacting with one's document,
nor how that interaction will take place -- it is up to the markup 
language to provide a mechanism for providing a means of annotating 
objects with quote hidden unquote metadata and/or descriptors, and it 
is up to the user agent to provide the user with a flexible means of 
accessing that metadata and/or descriptor; tooltips aren't inherently 
evil, and there are use cases where a user will need the contents of 
ALT or TITLE exposed visually to a user, in order to clearly and 
unambiguously communicate the functionality or change in viewport which 
may occur in response to user interaction, so that that interaction is 
as informed as possible...   just as ALT and TITLE should be available to 
a screen reader user whether or not image loading is turned on or off 
(something over which a user in a locked-down situtation may have 
absolutely no control, so too should ALT and TITLE be made available 
to a user who is capable of perceiving the graphic, but who doesn't
understand what it is intended to signify...

and, obviously, exposition of this content in a ToolTip is ONLY one 
means of providing ALT or TITLE to the user -- the contents of one 
or the other or both could be expanded in the status line or any 
number of means that do NOT require a MouseOver (such as OnFocus); 
the bottom line is that the user should not only be given a choice 
of how to expose the contents of ALT and TITLE and ABBR and ACRONYM 
and HR OnMouseOver AND OnFocus, but how to expose the contents of ALT 
and TITLE by using the keyboard to place focus on the item for which 
ALT or TITLE has been defined, in a less obtrusive manner than a 
ToolTip, and in a manner that is a more stable and longer-lasting 
than a ToolTip, provided that, if it is a ToolTip the user wants, it 
remains available to the user as a user agent option...

gregory.

----------------------------------------------------------------
CONSERVATIVE, n.  A statesman who is enamored of existing evils,
as distinguished from the Liberal, who wishes to replace them 
with others.         -- Ambrose Bierce, _The Devil's Dictionary_
----------------------------------------------------------------
             Gregory J. Rosmaita, oedipus@hicom.net
  Camera Obscura: http://www.hicom.net/~oedipus/index.html
----------------------------------------------------------------

Received on Monday, 30 July 2007 21:43:40 UTC