Re: [whatwg] Drop tabindex=
Dropping tabindex /might/ make sense if HTML5 was to be so feature complete that no-one would ever build a DHTML widget out of generic elements ever again. Is this likely to be the case? Because, if not, tabindex looks like part of a solution: http://developer.mozilla.org/en/docs/Key-navigable_custom_DHTML_widgets Of course, we might want to try to improve on tabindex and fix the scoping problem. Perhaps: div id=foobar div tabgroup=foobar taborder=2/ div tabgroup=foobar taborder=1/ /div -- Benjamin Hawkes-Lewis
Re: [whatwg] Drop tabindex=
On Wed, 21 Mar 2007 04:16:41 +0100, Simon Pieters [EMAIL PROTECTED] wrote: 3) The tab order should be up to the user. In Opera you can navigate in any direction you want using e.g. Shift+arrows, allowing you to freely navigate in tables for instance. The author shouldn't have any say about the tab order other than the source order. That holds true for Opera on desktop. Keep in mind that there are devices without useful 4-way navigation, such as the Sony Ericsson M600i, where your only means of (keyboard) navigation is through the scroll wheel on the side of the device. -- Arve Bersvendsen, Web Applications Developer Opera Software ASA, http://www.opera.com/
Re: [whatwg] Drop tabindex=
Colin Lieberman wrote: Drop tabindex altogether. It's just not useful. Before doing that, it might make sense to consult the accessibility teams of the UA vendors. In Mozilla's case, that's Aaron Leventhal. I believe that there have been recent changes to this property to better allow keyboard accessibility of DHTML widgets: http://developer.mozilla.org/en/docs/Key-navigable_custom_DHTML_widgets Gerv
Re: [whatwg] Drop tabindex=
Gervase Markham wrote: Before doing that, it might make sense to consult the accessibility teams of the UA vendors. In Mozilla's case, that's Aaron Leventhal. I believe that there have been recent changes to this property to better allow keyboard accessibility of DHTML widgets: http://developer.mozilla.org/en/docs/Key-navigable_custom_DHTML_widgets Gerv Certainly that's reasonable. Yes, you are absolutely right insofar as FF goes, although I'm not 100% convinced that authors should be left in the driver's seat; this may be something best left 100% in the hands of UA. Colin
Re: [whatwg] Drop tabindex=
Once upon a time Colin Lieberman shaped the electrons to say... Certainly that's reasonable. Yes, you are absolutely right insofar as FF goes, although I'm not 100% convinced that authors should be left in the driver's seat; this may be something best left 100% in the hands of UA. The UA could always offer the ability to override/disable tabindex in documents - as they can offer user stylesheets, etc. People who dislike the tabindex could disable it, and those who prefer to use the pages as the author index them can do the so. -MZ -- URL:mailto:megazoneatmegazone.org Gweep, Discordian, Author, Engineer, me. A little nonsense now and then, is relished by the wisest men 508-852-2171 URL:http://www.megazone.org/ URL:http://www.eyrie-productions.com/ Eris
[whatwg] Drop tabindex=
Hi, I think tabindex= has a number of problems: 1) Lacking a feature to scope tabindexes into local contexts, which I proposed[1] a while back, makes the feature rather useless for its intended purpose (which, AIUI, was to provide a means for the author to suggest a different tab order than the natural one, because he was using, say, form controls in a table where the navigation should go down through the columns rather than row for row). 2) Using tabindex=0 or -1 to indicate whether an element can have focus is arguably bogus IMHO. Whether something is focusable depends on the UA or the device. I don't see any reason why apps would use span tabindex=0 onclick onkeypress instead of just using links, form controls, or contenteditable= (depending on what you're doing). (If you'd do this because form controls are hard to style, then HTML isn't the place to address that problem.) 3) The tab order should be up to the user. In Opera you can navigate in any direction you want using e.g. Shift+arrows, allowing you to freely navigate in tables for instance. The author shouldn't have any say about the tab order other than the source order. From what I've seen, most authors who use tabindex use it out of a cargo cultish habit thinking it would aid accessibility because some outdated accessibility guidelines told them so. The result mostly being reducing keyboard usability by distorting the tab order, because the elements with tabindex receive focus before anything else on the page. These authors don't realise how tabindex actually works, but they feel good about having added it because they comply with the accessibility guidelines, yet they don't know that it in fact screws up the tab order because they don't browse with the keyboard. It was pointed out on IRC that there might be valid use-cases for #2, e.g. making a canvas focusable for games with keyboard controls. Then that's ok with me, I don't have strong opinions on this either way, I just think existing elements should be used where possible instead of reinventing links or checkboxes with span tabindex or similar. However, for positive values of tabindex, I only see problems. The source order should be a powerful enough mechanism for authors to suggest a tab order of elements. I would love to see browsers treat all positive values for tabindex as equivalent to 0 (i.e., just make it focusable but don't change the tab order). I would also like to propose that positive values for tabindex be disallowed in HTML5 documents. I don't think it's a good idea to add a scoped tabindex feature (trying to address #1) as I proposed before. [1] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2006-August/007228.html Regards, -- Simon Pieters
Re: [whatwg] Drop tabindex=
Simon Pieters writes: The tab order should be up to the user. In Opera you can navigate in any direction you want using e.g. Shift+arrows, allowing you to freely navigate in tables for instance. The author shouldn't have any say about the tab order other than the source order. In a table, I think I agree. The user should know how to get around via UI conventions. In more abstract structures, the author may be able to provide useful hints through tab order. DD
Re: [whatwg] Drop tabindex=
On Mar 20, 2007, at 8:16 PM, Simon Pieters wrote: Hi, I think tabindex= has a number of problems: 1) Lacking a feature to scope tabindexes into local contexts, which I proposed[1] a while back, makes the feature rather useless for its intended purpose (which, AIUI, was to provide a means for the author to suggest a different tab order than the natural one, because he was using, say, form controls in a table where the navigation should go down through the columns rather than row for row). Sounds like such a feature could be useful, but it would be tricky to make it compatible with older UAs. 2) Using tabindex=0 or -1 to indicate whether an element can have focus is arguably bogus IMHO. Whether something is focusable depends on the UA or the device. I don't see any reason why apps would use span tabindex=0 onclick onkeypress instead of just using links, form controls, or contenteditable= (depending on what you're doing). (If you'd do this because form controls are hard to style, then HTML isn't the place to address that problem.) I disagree with this. Arbitrary elements accepting keyboard input (which is what focus is about) is just as important as arbitrary elements receiving mouse input. You even cited one of my examples below: consider a game implemented with canvas that uses keyboard controls. Obviously you want to be able to make canvas focusable in such cases. There are many analogous use cases, consider building compound controls with XBL that want to have their own keyboard navigation. I don't think there is any need to limit what elements can get keyboard input 3) The tab order should be up to the user. In Opera you can navigate in any direction you want using e.g. Shift+arrows, allowing you to freely navigate in tables for instance. The author shouldn't have any say about the tab order other than the source order. Shift+arrows are a completely separate issue from tab order. From what I've seen, most authors who use tabindex use it out of a cargo cultish habit thinking it would aid accessibility because some outdated accessibility guidelines told them so. The result mostly being reducing keyboard usability by distorting the tab order, because the elements with tabindex receive focus before anything else on the page. These authors don't realise how tabindex actually works, but they feel good about having added it because they comply with the accessibility guidelines, yet they don't know that it in fact screws up the tab order because they don't browse with the keyboard. This sounds like something to be fixed in the relevant accessibility guidelines. HTML5 can also recommend not adding these attributes gratuitously. It was pointed out on IRC that there might be valid use-cases for #2, e.g. making a canvas focusable for games with keyboard controls. Then that's ok with me, I don't have strong opinions on this either way, I just think existing elements should be used where possible instead of reinventing links or checkboxes with span tabindex or similar. I agree that existing elements should be used when possible, but sometimes none of the small set of elements that is focusable by default is suitable. Note that UAs do not even agree on what elements are focusable by default. In Safari, links and input type=button controls are not in the tab order, for instance, to match Macintosh UI conventions. However, for positive values of tabindex, I only see problems. The source order should be a powerful enough mechanism for authors to suggest a tab order of elements. Document order is insufficient in the presence of positioning, or the column vs. row example you cited. I would love to see browsers treat all positive values for tabindex as equivalent to 0 (i.e., just make it focusable but don't change the tab order). I would also like to propose that positive values for tabindex be disallowed in HTML5 documents. I don't think it's a good idea to add a scoped tabindex feature (trying to address #1) as I proposed before. [1] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2006-August/ 007228.html Regards, -- Simon Pieters
