[Bug 9589] HTML5 should give examples for how to present @title when the user can't use a pointing device

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





--- Comment #7 from Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>  2010-04-26 09:47:33 ---
(In reply to comment #5)
> For any focusable elements, I would suggest that the tootlip
> appears on focus after a brief delay, windows OS does this (for
> example on the 'start' menu)

Are they comparable scenarios? If someone is tabbing through the
page, might not the tooltip overlay some text they are trying to
read? How would you make the tooltip disappear again if you wanted
to read the text?

That said, if *all* focusable controls (e.g. fields) display their
tooltips on focus, it's probably worth subscribing to the system UI
norms.

> Whatever solution is suggested in needs to provide access to title
> attribute content in a similar way to mouse users in so much as
> the content is displayed via an incidental behaviour

I'm not sure I'd describe the access to title attributes by mouse
users as always "incidental". You do have to hover and wait.

Why does access need to be "incidental"?

What more "incidental" UI do you have in mind?

One alternative might be to provide a mode where all "title" values
are simply inserted into the text flow (a bit like content inserted
with :after), with some special styling to distinguish them. This
would prevent the title box overlaying other content. However, I
suspect this would play havoc when combined with publisher styles.
For example, if an element with a "title" has a parent element with
a set height and width and overflow hidden, the "title" text would
be invisible. (In general, browsers have been wary of injecting
extraneous UI into web pages.)

Another alternative might be to insert little icon buttons,
indicating the presence of a "title" at a given location, into the
focus order of the page. The buttons would only appear on focus (a
/bit/ like the IE image toolbar that appears only on hover).
Activating such a button would cause the tooltip to appear,
activating it again would make it disappear. But the interaction
with publisher manipulation of the default focus order via tabindex,
aria-flowto, and focus() might prove problematic.

> not by the user having to query an element via a custom keystroke
> on the hope that there maybe a tooltip.

The solution suggested by Maciej allows users to discover all
"title" attributes on a page without querying individual elements.
The "hope" is per-page not per-element.

> If keyboard is provided for all title attribute content, it will
> still be a poor method for providing caption content for images.
> Captions should be displayed by default and be styleable and able
> to have semantics added, they should not be limited to a text
> string. We have a chance to do better than that in HTML5, lets not
> fetter the provision of captions to a broken attribute.

Users deserve access to "title" content regardless of whether it's
good practice to use it for captions or not, because there's plenty
of deployed content using "title".

Talking of XKCD, its use of title is forcing people to somewhat
inventive lengths to retrieve their values:

http://maebmij.org/blog/2009/05/11/read-xkcd-titles-from-the-command-line/

Note also the WCAG2 Techniques using the "title" attribute that also
call for universal access:

http://www.w3.org/TR/WCAG20-TECHS/H33.html

http://www.w3.org/TR/WCAG20-TECHS/H89.html

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

Received on Monday, 26 April 2010 09:47:40 UTC