This morning's look at 3590 I think has brought me closer to
understanding the problem... unfortunately the best understanding now is
that I can no longer think of a way of resolving it.
The key change in the "new" browsers appears to be the computation of
default tabindex order, as I suggested last night... however, the
crucial change appears to be in the treatment of elements whose tabindex
is explicitly set to -1. As you may recall, this is the strategy used in
the Reorderer to explicitly remove the reordered elements from tabindex
sequence.
It appears (at least in Firefox 3.6) that if focus is programmatically
set onto an element with tabindex -1, the browser considers that the
"focus location" is now in fact at the head of the document. This causes
the next tabbed element to become the first default tabbable control in
the window, leading to the environment-dependent "focus trapping"
behaviour reported in the JIRA. Setting a tabindex of 0 removes this
behaviour, but then of course causes each of the elements to be tabbable.
No "moral" way out of this problem is apparent. We could start to
consider "immoral" ones such as embedding a hidden tabbable element
after the reorderer for the purpose of explicitly throwing focus onto
when we are trying to navigate out. From experience, efforts like these
usually end up confusing screenreaders further. Likewise, "live"
tabindex manipulations have been ruled out.
The only idea that comes to mind is to, on receiving "tab" whilst
focused on an element, to programmatically throw focus back to the
container and then try to synthesize a tab event directed at it. Given
this problem only occurs on "modern" browsers, and that these are the
ones that have proven slightly more amenable to "realistic event
simulation" this has at least some chance of success...
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
