- From: <bugzilla@jessica.w3.org>
- Date: Tue, 02 Nov 2010 19:27:32 +0000
- To: public-html-a11y@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10873
Ian 'Hixie' Hickson <ian@hixie.ch> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |WONTFIX
--- Comment #13 from Ian 'Hixie' Hickson <ian@hixie.ch> 2010-11-02 19:27:32 UTC ---
(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.
--
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 Tuesday, 2 November 2010 19:27:34 UTC