Further elaborating on what Andy wrote, the reason why Trinidad has
never supported tab index directly is that tab index is lame. In
addition to the reasons that Andy listed, tab index has real problems
when composing content from multiple authors (in the simplest case
jsp:include), as there is no way for the authors to collaborate on the
correct indices to use. Even specifying a tab-base on the locations
where external content is included either hacking the ResponseWriter to
modify the actual tab index written has potential problems with the
limited tabindex space (0 - 32767) unless multiple passes are used.
Even then, if the tab indices are packed too tightly together a PPR
request that adds new items to be inserted into the tab order adds
complexity, as it can require the shifting of existing indices to make
space for the new items. All of this ignores sources of raw HTML
content, such as Portlets, that a solely ResponseWriter-based system
can't deal with.
However, my biggest issue with exposing tab index on Trinidad components
is that I doubt that it is even the appropriate abstraction. I suspect
that some sort of focus manager strategy, attachable to any component
would be more appropriate. I preferred to wait until we had a good set
of concrete focus management use cases. We could then verify that a
component tree with attached focus managers handled these cases and look
at whether a small set of declarative focus managers covered these cases.
-- Blake Sullivan
Andy Schwartz said the following On 3/22/2008 5:15 AM PT:
Hey All -
The concern with exposing a public component-level tabIndex attribute
has always been that this opens up the potential for way more problems
than it solves. The problem with HTML tabIndex attribute is that once
you set one positive tabIndex value, in order to ensure that the tab
traversal order matches the natural reading order (eg. the order in
which a screen reader traverses the content), you are required to set
tabIndex values on every tab stop on the page. This might be possible
on extremely simple pages, but anything beyond that becomes
unmanageable. Since it is not obvious to most page authors that
setting tabIndex can actually have a negative impact on the
accessibility of their page, we have historically avoided this issue
by not exposing access to this functionality.
The solution for the colorChooser problem is to:
1. Make the first color cell a tab stop.
2. Make all of the other color cells focusable, but not tab stops
(tabIndex="-1").
3. Implement up/down/left/right arrow key handlers which explicitly
call element.focus() to move the focus to the appropriate color cell.
I guess we could implement #1 and #2 now and leave #3 for later,
though in the case where the chooseColor is used in an inputColor's
popup (probably more common than the inline case), keyboard users
would be losing some functionality - ie. they would no longer tab
through the color cells in the popup. On non-FF browsers where the
focus highlight is displayed, this might be considered useful, though
clearly #3 is a much better solution.
Andy
