[Bug 10873] Provide a method of explicitly setting a tooltip for an element

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10873

Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bhawkeslewis@googlemail.com

--- Comment #8 from Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com> 2010-10-02 20:35:05 UTC ---
A benefit of an element-based replacement for "title" not mentioned by Everett
would be that it would allow authors to mark up changes of language, emphasis,
and voice in advisory text (e.g. using the "span", "em", and "kbd" elements).
This would, for example, allow text-to-speech agents to read content in
different languages appropriately.

Everett says we need an element in order to mandate UI, but HTML5 does not need
to introduce a new feature to mandate UI. For example, it /could/ mandate that
any elements with "title" should be inserted into the focus order and that
"title" should be shown as a tooltip on focus. Why would UA implementors be
more likely to meet such requirements for a "tooltip" element than for a
"title" attribute? And how would such requirements help users who need access
to the information currently locked away in "title" attributes? What we need is
better implementations of "title".

Moreover, document format specifications such as HTML5 (and OpenDocument, etc)
should define how conforming applications must extract information from the
format, not mandate particular UIs for the presentation of and interaction with
that information. Other applicable specifications such as W3C's User Agent
Accessibility Guidelines, the sometimes proposed Note for HTML5 user agent
implementors, ISO's Guidance on Software Accessibility, and the forthcoming
Section 508 refresh are all more appropriate places to make UI conformance
requirements, such as device-agnostic, user-stylable, time-unlimited access to
information in platform tooltips.

In line with this, HTML5 generally does not mandate any UI for any HTML
semantics. For example, HTML5 does not even require UAs to differentiate links
from surrounding text or activate links on click. Instead HTML5 makes hints
about how to represent semantics, including suggestions about how to make
"title" available in "a device agnostic manner":

    http://dev.w3.org/html5/spec/rendering.html#the-title-attribute-0

Those suggestions were added in response to Bug 10873. Are there additional
suggestions we should add?

(Those wanting to debate whether HTML5 should or should not mandate UI should
really take up that question outside this bug, since it's an overarching
question applicable to many more issues than this one.)

Everett also says we need an element in order to style tooltips. But (I think)
it would be better to propose CSS features (to the CSS WG) that would allow
authors and users alike to style existing tooltips. For example, a "::tooltip"
pseudo-element would allow the styling of platform tooltips and a "tooltip"
value for the "appearance" property would allow elements and pseudo-elements to
mimic platform tooltips.

In practice, when developers today want tooltips with a complex substructure,
or a different style or behavior from "title", they roll their own with an
element customized with styles and script. Examples incude:

   * YUI tooltip: http://developer.yahoo.com/yui/container/tooltip/
   * JQuery tooltip: http://docs.jquery.com/UI/Tooltip
   * DOJO tooltip: http://docs.dojocampus.org/dijit/Tooltip

ARIA's "tooltip" role, made conforming in HTML5, allows authors to designate
such DHTML tooltips as such for the benefit of user agents, including assistive
technology. Even if we introduced a "tooltip" element, authors would need to
continue to apply the same styles, scripting, and accessibility annotations to
the "tooltip" to achieve the same effect for several years.

Elements are better than attributes for text, and native semantics are
preferable to ARIA roles, but the benefits of specifying and implementing a
"tooltip" element pale against the benefits of improving accessibility of
tooltips using existing features (the "title" attribute, the "alt" attribute,
the SVG "title" element, or the ARIA "tooltip" role), whether via accessibility
standards or new CSS features. Conversely, introducing a "tooltip" element
*without* improving the implementations of "title" would perpetuate the current
disjointed web user experience where tooltips inevitably look and behave
differently, and not necessarily for the better, on different pages.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Saturday, 2 October 2010 20:35:09 UTC