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