(In reply to comment #0)
> HTML5 suggests that user agents may present @title or other caption information
> without requiring use of a pointing device, and are encouraged to do so. But it
> doesn't give examples of how this could be done. For the case of missing
> images, it seems like the title could be shown inline, but with some text to
> distinguish it from alt. For example:
> 
> <img src=broken-link.jpg title="Picture I took yesterday."> ==> "Caption:
> Picture I took yesterday."
> 
> I'm not sure how to do it in the case of a visual UA when the image is not
> missing. The typical UI for @title is that it's shown as a tooltip on hover. I
> cant think of a keyboard-driven way offhand.

I suggest the advice should not be restricted to the img element, the same issue is evident on any element the title attribute is used to present content. It should also not be restricted to the a case where some content is not displayed (as in the image case). input device independent access to title attribute content is equally problematic whether an image is displayed or not.

(In reply to comment #1)
> 
> I suggest the advice should not be restricted to the img element, the same
> issue is evident on any element the title attribute is used to present content.
> It should also not be restricted to the a case where some content is not
> displayed (as in the image case). input device independent access to title
> attribute content is equally problematic whether an image is displayed or not.

I agree, the example I gave only covers the special case of an <img> element with a missing image. The spec should make some reasonable suggestion that covers the general case.

As a browser implementor I can see how it would be useful to give some form of keyboard access to @title contents but I'm not sure of the best way to do it. One possibility is to have a keyboard shortcut to cycle through every item with a title attribute, which highlights it somehow (maybe) and displays the tooltip. I'm not sure if that's a very good UI design though.

Adding the a11y and a11y_text-alt keywords and copying the task force.

This bug is key to ISSUE-31 and ISSUE-80:
http://www.w3.org/html/wg/tracker/issues/31
http://www.w3.org/html/wg/tracker/issues/80 

It affects two change proposals:
http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20090126
http://esw.w3.org/topic/HTML/ChangeProposals/ImgElement20091203

(In reply to comment #2)
> As a browser implementor I can see how it would be useful to give some form of
> keyboard access to @title contents but I'm not sure of the best way to do it.
> One possibility is to have a keyboard shortcut to cycle through every item with
> a title attribute, which highlights it somehow (maybe) and displays the
> tooltip. I'm not sure if that's a very good UI design though.

I think it's better than my initial idea (have a shortcut to show all tooltips at once) since it avoids the problem of overlapping tooltips. Perhaps rather than cycling from the top if an element already has focus, the UA should cycle forward from that focused element (and back to the top if necessary)?

Note also these old Mozilla feature requests for exposing titles of controls on focus:

https://bugzilla.mozilla.org/show_bug.cgi?id=97223

https://bugzilla.mozilla.org/show_bug.cgi?id=273704

(In reply to comment #2)
> (In reply to comment #1)
> > 
> > I suggest the advice should not be restricted to the img element, the same
> > issue is evident on any element the title attribute is used to present content.
> > It should also not be restricted to the a case where some content is not
> > displayed (as in the image case). input device independent access to title
> > attribute content is equally problematic whether an image is displayed or not.
> I agree, the example I gave only covers the special case of an <img> element
> with a missing image. The spec should make some reasonable suggestion that
> covers the general case.
> As a browser implementor I can see how it would be useful to give some form of
> keyboard access to @title contents but I'm not sure of the best way to do it.
> One possibility is to have a keyboard shortcut to cycle through every item with
> a title attribute, which highlights it somehow (maybe) and displays the
> tooltip. I'm not sure if that's a very good UI design though.

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) this does not solve the problem of non focusable elements. 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, not by the user having to query an element via a custom keystroke on the hope that there maybe a tooltip.

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.

(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)

I'm not sure that's a very good UI design in general. The tooltip could partially obscure a UI element (or others nearby) right when you're about to use it, if it appears on focus. That could be annoying if it appeared over a text field, if the text field happened to have @title. Or likewise for a button, or a link.

> this does not solve the problem of non focusable elements.

Indeed.


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

This bug is not primarily about the appropriate way to provide caption content in images. There are pages that have important content in title attributes, for example this one (and many others like it on the same site): <http://xkcd.com/732/>. Note that the element on that page with a title attribute is not focusable.

Right now, users who browse visually but can't use a pointing device miss out on this content. That's something we need to fix, regardless of what happens with the alt issue. The spec should give some advice on how to get this right.

(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

(In reply to comment #7)



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

if the browser provided a keystroke to show the tooltip, could they not as easily provide a keystroke to dismiss/re-display the tooltip?


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

in no way am i arguing they do not, I had input on the wcag techniques you cite and provided detailed arguments on why UA/AT support at the time  was not sufficient to advocate the use of the title attribute on links which is why there are so many caveats to its use in the technique.
I also did user testing and research on the title attribute back in 2005:
http://www.paciellogroup.com/blog/?p=37
unfortunately nothing has changed since then in regards to accessibility support for title attribute access.

apolgies missed these questions frist pass

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

i describe them as incidentalk since tootips are displayed when users are in the act of doing other things, such as moving their mouse over a link in preparation to activate.

>Why does access need to be "incidental"?

they probably do not need to be incidental, but do need to be discoverable without having to query an individual element by an additional action.

>What more "incidental" UI do you have in mind?
 In the case of interactive elements the display of the title attributre after a brief delay on focus would be incidental to the user navigating the focusable elements using the keyboard.

(In reply to comment #8)
> > 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?
> 
> if the browser provided a keystroke to show the tooltip, could
> they not as easily provide a keystroke to dismiss/re-display the
> tooltip?

True - the problem would be discoverability of the keystroke!

How about this:

   * Browser has Show Next Tooltip, Show Previous Tooltip, and Hide
     Tooltip commands. "Show Next Tooltip" shows the first available
     tooltip from current control focus or, if there is no focus,
     top of document.
   * These commands are mapped to keyboard shortcuts. Could be
     mapped to Command-., Shift-Command-., and Alt-Command-. in
     Safari, for example. (If there are host system functions for
     tooltip manipulation, could use those instead.)
   * For control types where the system UI exposes tooltips on
     focus, Show Next Tooltip is automatically called.

I think exposing on-focus tooltips *automatically* in a different
way to the host system could create a usability problem since
people - even existing keyboard users - will not be familiar with
how to dismiss such tooltips and may assume either the page or the
browser is broken if important content gets hidden.

One possible compromise might be to show the tooltip on focus, then
gradually fade it out? That way keyboard users *know* there is a
tooltip there (meeting the goal of "incidental" discoverability),
and could retrieve it using Show Next Tooltip, but keyboard users who
don't know the Hide Tooltip command would still have access to
anything hidden by the tooltip.

Another possibility might be to include a hint about the keystroke
to dismiss the tooltip in the tooltip bubble. That could be
confusing when tooltip text itself contains hints about shortcuts
for a web app though. Showing a hint in the Status Bar might also
be a possibility - but that's not always visible.

> > 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".
> 
> in no way am i arguing they do not

Absolutely - I just don't want to see this ticket derail into a
(worthwhile but I /think/ separable) discussion about best practice
for captions. :)

> These commands are mapped to keyboard shortcuts. Could be mapped
> to Command-., Shift-Command-., and Alt-Command-. in Safari, for
> example. (If there are host system functions for tooltip
> manipulation, could use those instead.)

Actually, at least in Chrome Mac Dev Channel, /any/ keypress (or
mouse movement) dismisses the tooltip. If broadly adopted, Hide
Tooltip would not need a distinct keyboard binding. This also
reduces the learning curve problem I was worrying about, so any user
action will make the tooltip disappear.

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: Accepted
Change Description: see diff given below
Rationale: Concurred with reporter's original comment.

Checked in as WHATWG revision r5320.
Check-in comment: Add some examples of UIs that expose tooltips without a pointing device.
http://html5.org/tools/web-apps-tracker?from=5319&to=5320

http://lists.w3.org/Archives/Public/public-html-a11y/2010Aug/0013.html

The bug triage sub-team thinks the HTML A11Y TF does not need to formally follow this bug. Original submitters or other interested parties may choose to continue to push this issue on their own. Notes from the sub-team may follow in a separate comment.