Re: ToolTips: bug or feature?

we'd do better to have a tooltip attribute and handle alt and title in 
better ways.  Alt and title have been confused as tooltips thus have done 
poorly over all.


----- Original Message ----- 
From: "Gregory J. Rosmaita" <oedipus@hicom.net>
To: "David Poehlman" <poehlman1@comcast.net>; "Lachlan Hunt" 
<lachlan.hunt@lachy.id.au>
Cc: <public-html@w3.org>; <w3c-wai-ua@w3.org>
Sent: Sunday, July 29, 2007 4:51 PM
Subject: Re: ToolTips: bug or feature?



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 21:11:16 UTC