Adding the comments from the most recent previous mail thread on this issue started on 3/18/08:
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
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.
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
This was my main question after reading the Andrew's wiki page - I
want to be sure to understand the use cases that we are trying to
address before moving forward with a solution. Many use cases can be
addressed by simpler solutions, eg:
- The login page initial focus case can be addressed by tr:document
- The skip advertising/chrome use case can be addressed by improved
skip link support.
- The newspaper-style column-based tab traversal can be addressed by
using multi-column panelFormLayouts, or similar dom structures.
We should at least consider whether such solutions meet our
requirements before deciding to add new functionality.