More on FLUID-3590

Colin Clark colinbdclark at gmail.com
Sat Apr 10 03:45:58 UTC 2010


To close up this thread:

Antranig made a small patch yesterday that switches our keyboard navigation strategy fully to the "Roaming Tabindex" idiom, described here:

http://www.yuiblog.com/blog/2009/02/23/managing-focus/

It's a slight variation on what we were doing previously, with the difference being that we now dynamically change an item's tabindex to "0" before focusing it, and switch it back to "-1" on blur. To appropriate Antranig's terminology, this is a "suitably moral" solution, and appears to be required for several latest-generation browsers. Just in case, we'll also put together a simple test case and escalate it to Mozilla in the hopes of getting clarity on why the behaviour of tab focus changed so radically between 3.5 and 3.6.

Details describing this whole issue are located on the relevant JIRA ticket:

http://issues.fluidproject.org/browse/FLUID-3590

Justin and I tested the fix fairly extensively and I committed the fix this afternoon. Now we're on to the final stages of QA and documentation in preparation for the release of Infusion 1.2.

Huge thanks to Boz for figuring this one out and getting a fix in place so quickly.

Colin

On 2010-04-08, at 8:33 AM, Antranig Basman wrote:

> 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 - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://fluidproject.org/mailman/listinfo/fluid-work

---
Colin Clark
Technical Lead, Fluid Project
http://fluidproject.org




More information about the fluid-work mailing list