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

Re: ToolTips: bug or feature?

From: Gregory J. Rosmaita <oedipus@hicom.net>
Date: Sun, 29 Jul 2007 16:51:12 -0400
To: "David Poehlman" <poehlman1@comcast.net>, "Lachlan Hunt" <lachlan.hunt@lachy.id.au>
Cc: <public-html@w3.org>, <w3c-wai-ua@w3.org>
Message-Id: <20070729200000.M61478@hicom.net>

aloha, david!

you wrote, quote:
> Tooltips as they are implemented using title and alt is a bug. 
>  alt and title are addative for many and necessary for others. 
unquote

i believe the key words in the first sentence are: quote as they 
are implemented unquote.  both ALT and TITLE are necessary for 
some, but they can and do perform a valuable service for those 
who either cannot make sense of the iconic conventions used in 
a document instance or for whom the content of the icon -- 
a picture of text of any type may need exposition for a screen 
magnification user, or a low vision (that is, neither totally 
blind or legally blind, but those with degenerative eyesight 
over the 20/200 barrier) user...

which is why i maintain that ToolTip exposition 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 hyperlilnk 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
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; 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,
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.
----------------------------------------------------------
Whatever one believes to be true either is true or becomes 
true in one's mind.              -- Gene Fowler, 1890-1960
----------------------------------------------------------
Gregory J. Rosmaita, oedipus@hicom.net
  Camera Obscura: http://www.hicom.net/~oedipus/index.html
----------------------------------------------------------

---------- Original Message -----------
From: "David Poehlman" <poehlman1@comcast.net>
To: "Gregory J. Rosmaita" <oedipus@hicom.net>, "Lachlan Hunt" 
<lachlan.hunt@lachy.id.au>
Cc: <public-html@w3.org>, <w3c-wai-ua@w3.org>
Sent: Sun, 29 Jul 2007 15:43:42 -0400
Subject: Re: ToolTips: bug or feature?

> Tooltips as they are implemented using title and alt is a bug. 
>  alt and title are addative for many and necessary for others. 
>  The way they should work is by user choice either through 
> suppression of the content they represent or via user agent 
> configuration to meet other needs.  In other words, by default,
>  it should never be possible to see title or alt or perhaps only 
> alt unless certain conditions are met.
> 
> ----- Original Message ----- 
> From: "Gregory J. Rosmaita" <oedipus@hicom.net>
> To: "Lachlan Hunt" <lachlan.hunt@lachy.id.au>
> Cc: <public-html@w3.org>; <w3c-wai-ua@w3.org>
> Sent: Sunday, July 29, 2007 9:52 AM
> Subject: ToolTips: bug or feature?
> 
> lachlan wrote, quote:
> > The alt attribute is only rendered as a tooltip in IE, and
> > that's considered a bug for a variety of reasons. See this article.
> >
> > http://hixie.ch/advocacy/alt-tooltips
> unquote
> 
> i find hixie's arguments, decidedly unconvincing.  there ARE 
> valid reasons why @alt and @title should be exposed to the user 
> onMouseOver -- as i indicated, what you perceive as a logical 
> icon may not be understood by a sighted visitor from a vastly different
> culture, so a tooltip exposition of ALT text is actually beneficial
> to users of all stripes.  in the end, all hixie really addressed 
> is author complaints, which have far more to do with user agent 
> implementations than anything defective in the markup.
> 
> if authors are so worried about ToolTips "cluttering" their 
> pages, then they should be able to set their user agent to 
> display ALT as tooltips, display TITLE as tooltips, display ALT 
> and TITLE as tooltips, display no tooltips -- this is a user 
> agent issues, better addressed by the User Agent Accessibility 
> Guidelines Working Group:
> 
> http://www.w3.org/WAI/UA
> 
> than the HTML working group.
> 
> gregory.
> -----------------------------------------------------------------
> ABSURDITY, n.  A statement or belief manifestly inconsistent with
> one's own opinion.      -- Ambrose Bierce, The Devils' Dictionary
> -----------------------------------------------------------------
> Gregory J. Rosmaita, oedipus@hicom.net AND unagi69@concentric.net
>          Camera Obscura: http://www.hicom.net/~oedipus/index.html
> UBATS: United Blind Advocates for Talking Signs: http://ubats.org
> -----------------------------------------------------------------
------- End of Original Message -------
Received on Sunday, 29 July 2007 20:51:57 GMT

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