- From: <bugzilla@jessica.w3.org>
- Date: Mon, 26 Apr 2010 08:58:54 +0000
- To: public-html-a11y@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9589 --- Comment #5 from steve faulkner <faulkner.steve@gmail.com> 2010-04-26 08:45:20 --- (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. --- Comment #6 from Maciej Stachowiak <mjs@apple.com> 2010-04-26 08:59:26 --- (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. -- 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 Monday, 26 April 2010 08:59:28 UTC