Final kick in the nuts re. focus - keyboard-a11y plugin

[Antranig Basman]

Following on from my previous posting reporting on focus handling issues provoked by our recent jQuery 
upgrade that I reported on at 
http://fluid.2324889.n4.nabble.com/Breaking-changes-in-recent-versions-of-jQuery-focus-handling-td8867.html 
I have what is hopefully a final round of reports and also in this case queries.

After the merge of both https://github.com/fluid-project/infusion/pull/448 and 
https://github.com/fluid-project/infusion/pull/437 for http://issues.fluidproject.org/browse/FLUID-5241 and 
http://issues.fluidproject.org/browse/FLUID-5204 http://issues.fluidproject.org/browse/FLUID-5185 we have a 
framework image which is basically up to date and working, but the combination of the two pull requests have 
precipitated a failure in our test cases for keyboard-a11y-tests.js on all versions of IE.

In some sense the failures are "benign" in that the real implementation is working on this platform, but 
they raise a few philosophical and practical issues that we would need to talk through. This is following on 
from an end-of-day conversation archived at https://botbot.me/freenode/fluid-work/2014-02-06/?tz=America/Denver

The root cause is a familiar one, just better understood - the recent version of jQuery now only relays 
"faithful" focus messages resulting from the browser rather than "fake" ones as it has for many years, which 
used to synchronously relay attempts to trigger focus events into listeners for them.

This creates particular problems for our keyboard accessibility tests, since these rely on focus triggering 
not only in the test cases, but also in the implementation. To recap, the "selectable" widget, when 
receiving focus on a "container" node, responds my immediately throwing focus onto the first of a set of 
managed container elements - this shortcut saves one interaction cycle for those using the keyboard or other 
equivalent.

Part of the work for FLUID-5185 involved progressively rewriting our tests in the new "asynchronous style" 
for which there seems now little alternative for keyboard-a11y. Our alternatives for the other tests might 
have involved the use of jQuery.triggerHandler which was jQuery's recommendation for restoring the old 
framework behaviour - and is the approach used, for example, in the jquery.simulate plugin: 
https://github.com/jquery/jquery-simulate/blob/master/jquery.simulate.js - however, it would seem 
inappropriate to import this whole plugin as part of the implementation strategy of another widget, and it 
even seems inappropriate (to me) to try to restore the old "event fakery" by calling $.triggerHandler() as 
part of the implementation of keyboard-a11y - if for no other reason that this will restore odd pathologies 
such as being notified of focus events twice (once for the fake handler trigger, and once for the real focus 
event). However, I'm open to, say, improving our existing jqUnit.simulateFocus method (currently in 
jqUnit-browser.js, as part of the FLUID-5185 work) to being a first-class core framework method which would 
restore the old jQuery behaviour and allow us to retain our old tests.

The other option is to accept the variability of focus relay across browsers as "part of the environment" 
and rewrite all the tests in keyboard-a11y-tests.js to use the IoC testing framework which was designed 
precisely to abstract over asynchrony issues of this kind. This will further reduce the viability of these 
tests from the point of non-Infusion users but I believe this counts for very little at this point (see below).

So either A) upgrade jqUnit.simulateFocus to a standard core utility which we use everywhere, OR B) fall 
back on standard $.focus() everywhere and rewrite the keyboard-a11y tests to use IoC testing.

The philosophical issue relates to what we believe our tests assure... and how "portable" we expect their 
effects to be. I think there are good grounds for wanting tests of our browser widgets to be "as faithful as 
possible" wrt their browser environment, given part of their purpose is to reduce the burden of acceptance 
testing. However, tests which have environmental dependencies are philosophically dubious, and it might be 
worth starting to think more clearly about the roles of our different tests and perhaps separating out those 
tests into a different area which are expected to execute differently (whilst still passing) on different 
browser platforms.

The other issue relates to our keyboard-a11y plugin itself. I think it's fair to say that if we were to 
write this today, we would not write it in the way we did in 2008. I think it's become clear to us that the 
"instance-free, model-free" idiom for jQuery UI plugins doesn't meet our goals as a community, and one sense 
in which this became apparent just now was the way in which our plugin doesn't expose the events and model 
state that we now expect from a Fluid component makes it harder to write credible and reliable tests for it. 
I propose that for Infusion 2.0 we eliminate both the "special status" of jquery.keyboard-11y.js itself 
(since it's perfectly clear after 5 years that it remains of no interest to anyone in the wider jQuery 
community) and its implementation in favour of producing a standard model-based and framework-aware version 
of it. I think this will become even more important as with the merging of the FLUID-3674 branch and 
subsequent work we will be working in a more and more "model-driven" idiom.

Cheers,
A.