EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: The title="" attribute is as close as we can get to this without being media- or device-specific. Just consider title="" to be for tooltips and in practice you will be fine.

The reason that the spec dodges the issue as it does is that we have to leave precise user interface details up to the user agent. For example, the Lynx implementors might prefer to show the advisory text in a status line rather than in a tooltip.

The Editor's response does not address the 3 technical requirements articulated in the initial bug:

1. Must be accessible in a device agnostic manner.(Tool-tips are mouse-dependant at this time)
2. Text must be resizeable and restyleable. (low vision users, contrast issues, etc.)
3. Duration of display must be configurable by users. (addresses cognitive processing issues)

For these reasons, a newly minted tool-tip element should be considered that can thus take on attributes such as 'delay', event-handlers such as :focus (this could be native) and the ability to be styled using CSS.

(In reply to comment #1)
> EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
> satisfied with this response, please change the state of this bug to CLOSED. If
> you have additional information and would like the editor to reconsider, please
> reopen this bug. If you would like to escalate the issue to the full HTML
> Working Group, please add the TrackerRequest keyword to this bug, and suggest
> title and text for the tracker issue; or you may create a tracker issue
> yourself, if you are able to do so. For more details, see this document:
>    http://dev.w3.org/html5/decision-policy/decision-policy.html
> 
> Status: Rejected
> Change Description: no spec change
> Rationale: The title="" attribute is as close as we can get to this without
> being media- or device-specific. Just consider title="" to be for tooltips and
> in practice you will be fine.
> 
> The reason that the spec dodges the issue as it does is that we have to leave
> precise user interface details up to the user agent. For example, the Lynx
> implementors might prefer to show the advisory text in a status line rather
> than in a tooltip.

"The tooltip is a common graphical user interface element. It is used in conjunction with a cursor,usually a mouse pointer. The user hovers the cursor over an item, without clicking it, and a tooltip may appear  a small "hover box" with informationabout the item being hovered over." (http://en.wikipedia.org/wiki/Tooltip)

If I wish to ensure that my content appears as a tooltip either:

1. UAs must support the functionality, and must so do accessibly, or

2. I must implement the functionality myself.

The current spec * does not * provide for a tooltip, only that the title attribute content * may * 'be appropriate for a tooltip'

Would it be sufficient to add some additional requirements for @title? @title displays as a tooltip in all modern graphical user agents. It would be better to enhance @title than to invent a brand new feature for similar functionality, in my opinion.

(In reply to comment #4)
> Would it be sufficient to add some additional requirements for @title? @title
> displays as a tooltip in all modern graphical user agents. It would be better
> to enhance @title than to invent a brand new feature for similar functionality,
> in my opinion.

If @title can be enhanced to meet the requirements specified:

 1. Must be accessible in a device agnostic manner. (Ref: UAAG 4.1.1, WCAG 2.1.1)
 2. Text must be resizeable and restyleable. (Ref: WCAG 1.4.4, UAAG 3.9.2)
 3. Duration of display must be configurable by users. (Ref: WCAG 2.2.1)

...then it would likely be sufficient to close this bug. Do you have specific ideas how this could be done?

(In reply to comment #5)
> (In reply to comment #4)
> > Would it be sufficient to add some additional requirements for @title? @title
> > displays as a tooltip in all modern graphical user agents. It would be better
> > to enhance @title than to invent a brand new feature for similar functionality,
> > in my opinion.
> 
> If @title can be enhanced to meet the requirements specified:
> 
>  1. Must be accessible in a device agnostic manner. (Ref: UAAG 4.1.1, WCAG
> 2.1.1)

Seems to me UAAG 4.1.1 already applies, since it explicitly applies to all functionality. It would be helpful if the Implementing UAAG 2.0 draft could give examples of how to offer access to tooltips using the keyboard. It seems to me this is important for @title even if a new feature is also added.

http://www.w3.org/TR/2010/WD-IMPLEMENTING-UAAG20-20100617/#gl-keyboard-access

However, UAAG 4.1.1 does not strike me as "device agnostic". It specifically requires access via the keyboard. This is surely not appropriate for devices without a physical keyboard, for example the iPhone. iOS has been praised for its accessibility support, through voice and touch: <http://behindthecurtain.us/2010/06/12/my-first-week-with-the-iphone/>. Interaction using a virtual onscreen keyboard would be much worse.

That being said, tooltips themselves do not work very well for any users on touchscreen devices, since there is no concept of hover. So it is probably not good for device-independence to further encourage their use.


>  2. Text must be resizeable and restyleable. (Ref: WCAG 1.4.4, UAAG 3.9.2)

Do you mean this UAAG 3.9.2?

"3.9.2 User Style Sheets: If the user has supplied one or more style sheets, the user has the following options (Level A):
(a) select between the style sheets, or
(b) turn off the style sheets."

If the intent of that UAAG requirement is that all text anywhere in the UI must be styleable with CSS, then it probably needs to be updated.

If that were done, then it would apply directly. However, it's not clear to me if this requirement would be practical. Operating systems have specific conventions on how tooltips look. Magnification is generally controlled in an OS-wide way, and not controlled by the UA.

>  3. Duration of display must be configurable by users. (Ref: WCAG 2.2.1)

This too seems like an OS-level issue. (On the Mac, as far as I can tell the standard is that tooltips display indefinitely until the user moves the mouse. I am not sure if there is a requirement to configure the display duration to be limited instead.)
 
> ...then it would likely be sufficient to close this bug. Do you have specific
> ideas how this could be done?

Not totally sure, but I gave some comments above. I think the challenges are the same whether @title or @tooltip is the name of the attribute. This bug does not appear to explain how the problems would be solved for proposed tooltip attribute.

(In reply to comment #6)
> 
> Seems to me UAAG 4.1.1 already applies, since it explicitly applies to all
> functionality. It would be helpful if the Implementing UAAG 2.0 draft could
> give examples of how to offer access to tooltips using the keyboard. It seems
> to me this is important for @title even if a new feature is also added.
> 
> http://www.w3.org/TR/2010/WD-IMPLEMENTING-UAAG20-20100617/#gl-keyboard-access
> 
> However, UAAG 4.1.1 does not strike me as "device agnostic". It specifically
> requires access via the keyboard. This is surely not appropriate for devices
> without a physical keyboard, for example the iPhone. iOS has been praised for
> its accessibility support, through voice and touch:
> <http://behindthecurtain.us/2010/06/12/my-first-week-with-the-iphone/>.
> Interaction using a virtual onscreen keyboard would be much worse.

Good observations/comments Maciej, and I will be sure to forward them to the UAAG team. Perhaps a 4th requirement for any solution then is that it be truly agnostic and 'work' on touch-input devices as well.

> 
> That being said, tooltips themselves do not work very well for any users on
> touchscreen devices, since there is no concept of hover. So it is probably not
> good for device-independence to further encourage their use.

Which raises the larger question: do authors/users need or want Tool Tips? If the answer to that is yes, then we need to figure out how to do them right, which is one of the foundations of this bug (the other being that it is an accessible solution)

> 
> 
> >  2. Text must be resizeable and restyleable. (Ref: WCAG 1.4.4, UAAG 3.9.2)
> 
> Do you mean this UAAG 3.9.2?
> 
> "3.9.2 User Style Sheets: If the user has supplied one or more style sheets,
> the user has the following options (Level A):
> (a) select between the style sheets, or
> (b) turn off the style sheets."
> 
> If the intent of that UAAG requirement is that all text anywhere in the UI must
> be styleable with CSS, then it probably needs to be updated.
> 
> If that were done, then it would apply directly. However, it's not clear to me
> if this requirement would be practical. Operating systems have specific
> conventions on how tooltips look. Magnification is generally controlled in an
> OS-wide way, and not controlled by the UA.

I was mostly thinking about user-supplied style sheets w.r.t. the ability to style the tooltip: change the contrast, enlarge the size, perhaps even apply a different font-face[1] if required.
[1. http://www.aph.org/products/aphont.html]

The problem we have is that unlike other UI controls linked to the OS, tooltips are being used by the page/app author to convey information to the end user: the source of the "information" is not the UI/OS, but removed-to/assigned-to the content author.

For example, most browsers today allow for a "zooming" of the on-screen content in the browser - a feature that has been shifted to the browser (one of the upsides being the relaxed requirement on fixed font-sizes). However, if a low-vision user "zooms" a web-page, everything is enlarged to a size they can see *except* the author supplied 'tip' in the tool-tip.

I for one am not overly religious on how this problem should be solved, and welcome input from the engineering teams on suggestions, as long as the problem is solved in a stable and dependable, cross-browser, cross-platform way. 

One way to achieve this is to perhaps a) mint a new <tooltip> element (we certainly have examples of need and use-cases), or b) create a new attribute (which would be harder to style, but not impossible AFAICT) or c) as you suggest modify/improve @title

> 
> >  3. Duration of display must be configurable by users. (Ref: WCAG 2.2.1)
> 
> This too seems like an OS-level issue. (On the Mac, as far as I can tell the
> standard is that tooltips display indefinitely until the user moves the mouse.
> I am not sure if there is a requirement to configure the display duration to be
> limited instead.)
> 

...and if this is the case for all OSes that run browsers, then it may be that this is a non-problem. I will ask whether there is value in specifically stating this as a requirement for tooltips, to ensure that this remains the case?


> 
> Not totally sure, but I gave some comments above. I think the challenges are
> the same whether @title or @tooltip is the name of the attribute. This bug does
> not appear to explain how the problems would be solved for proposed tooltip
> attribute.

I was not aware that submitted bugs also require solutions. :-) 

The problem has been brought to the engineers so that dialog can happen; so that together we can all figure this out. My gut reaction is/was to create a new <tooltip> attribute (which could be a child element of any block-level element) but that has not been fully thought out or explored. I am personally mindful of the desire to keep "creep" in check however, so open to other thoughts and suggestions.  Bottom line is to solve the problem, which today is real.

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.

(In reply to comment #8)
> Those suggestions were added in response to Bug 10873. Are there additional
> suggestions we should add?

Sorry, I meant to refer to Bug 9589:

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

(In reply to comment #8)
> 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 fact, a "tooltip" value for "appearance" is already in the CSS3 Basic User Interface draft:

http://www.w3.org/TR/css3-ui/#appearance-val

Either REOPEN or TrackerRequest.  As discussion is ongoing, I'm removing TrackerRequest.

HTML a11y TF bug triage sub-team adding a11yTF keyword and assigning the bug to the editor because his response to the REOPEN state change is needed next

(In reply to comment #2)
> The Editor's response does not address the 3 technical requirements articulated
> in the initial bug:
> 
> 1. Must be accessible in a device agnostic manner. (Tool-tips are
> mouse-dependant at this time)

The specification doesn't require that they be tooltips -- that would make no sense, e.g. in a non-visual interface. The title="" attribute is not mouse-specific (unless I made a mistake, in which case please quote the relevant text so that I can fix it).

Furthermore, it would be inappropriate for the HTML spec to require a user interface. For example, a search engine is an HTML user agent, but it would be completely meaningless to require that the search engine make tooltips accessible in a device-agnostic manner, since the tooltips aren't made available at all to the users of the search engine.


> 2. Text must be resizeable and restyleable. (low vision users, contrast issues,
> etc.)

Nothing prevents a user agent from resizing or restyling tooltips. Indeed, no restrictions whatsoever are placed on how tooltips are to be displayed; I would expect them to use platform-specific conventions.


> 3. Duration of display must be configurable by users. (addresses cognitive
> processing issues)

Nothing in the specification suggests that there should even be a finite duration, so making it configurable seems to rather miss the point. It's up to the user agent.

Imagine I made a browser for people on Times Square to play with the Web, whose UI consisted of just a large trackball and a single button. It would be silly to require that this browser allow the user to configure the tooltip display time. We shouldn't make such browsers non-conforming merely because they can't provide such preferences.


> For these reasons, a newly minted tool-tip element should be considered that
> can thus take on attributes such as 'delay', event-handlers such as :focus
> (this could be native) and the ability to be styled using CSS.

title="" can already be made accessible in just the same way that a new element could. There's no need to add an element for this reason.


(In reply to comment #3)
> "The tooltip is a common graphical user interface element. It is used in
> conjunction with a cursor,usually a mouse pointer. The user hovers the cursor
> over an item, without clicking it, and a tooltip may appear  a small "hover
> box" with informationabout the item being hovered over."
> (http://en.wikipedia.org/wiki/Tooltip)
> 
> If I wish to ensure that my content appears as a tooltip either:
> 
> 1. UAs must support the functionality, and must so do accessibly, or
> 
> 2. I must implement the functionality myself.
> 
> The current spec * does not * provide for a tooltip, only that the title
> attribute content * may * 'be appropriate for a tooltip'

HTML is device-agnostic. What you quote is specifically for graphical user interfaces. Not all browsers have GUIs. For example, there are audio browsers. Therefore we can't require specific graphical renderings. That would make no sense.

Insofar that we can require a rendering, the spec does require that title="" be rendered as a tooltip: the rendering section says "Given an element (e.g. the element designated by the mouse cursor), if the element, or one of its ancestors, has a title attribute, and the nearest such attribute has a value that is not the empty string, it is expected that the user agent will expose the contents of that attribute as a tooltip".


(In reply to comment #8)
> 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).

That is true. It would also allow ruby, embedded images and videos, and other such features. So far, the use cases for these more advanced features have not been on the right side of the 80/20 divide. Maybe in the future this will change.


> This would, for example, allow text-to-speech agents to read content in
> different languages appropriately.

Somewhat, though in practice language detection is a more reliable mechanism for this these days; there's a lot of content out there that is not correctly labeled.


> 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".

Indeed.


> 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.

Indeed.


> 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.

Indeed.


EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: see above.

HTML A11Y TF has agreed to close this issue and will put the idea into the wiki for consideration as an extension spec.