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
