[
https://issues.apache.org/jira/browse/TRINIDAD-888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12733257#action_12733257
]
Blake Sullivan commented on TRINIDAD-888:
-----------------------------------------
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
(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
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
initialFocusId.
- 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.
Andy
> Add support for tabindex to focusable components
> ------------------------------------------------
>
> Key: TRINIDAD-888
> URL: https://issues.apache.org/jira/browse/TRINIDAD-888
> Project: MyFaces Trinidad
> Issue Type: Improvement
> Components: Components
> Affects Versions: 1.0.5-core, 1.2.5-core
> Reporter: Andrew Robinson
> Assignee: Andrew Robinson
> Priority: Minor
>
> Add support for tabindex to focusable components (initial list, maybe changed
> during implementation):
> breadCrumbs
> chooseColor
> chooseDate
> commandButton
> commandLink
> commandNavigationItem
> goButton
> goLink
> inputColor
> inputDate
> inputFile
> inputListOfValues
> inputNumberSpinbox
> inputText
> navigationPane
> navigationTree
> panelAccordion
> panelPopup (not with hover?)
> panelRadio/showDetailItem
> panelTabbed
> processChoiceBar
> resetButton
> selectBooleanCheckbox
> selectBooleanRadio
> selectManyCheckbox
> selectManyListbox
> selectManyShuttle
> selectRangeChoiceBar
> showDetail
> singleStepButtonBar
> table
> train
> tree
> treeTable
> According to the w3c:
> http://www.w3.org/TR/html4/interact/forms.html#adef-tabindex
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
