Moving Focus for Accessibility 1.1.3

C. Blouch

June 14, 2006

Introduction

Files

Solution

Test Environment

1. Clicking on "Add 2nd DIV" inserts a dynamically created DIV between the header and footer DIV. The content of this DIV is controlled by the HTML in the green edit box. You can modify the HTML at will and any additional DIVs you create will contain what is currently in the green box.
2. Clicking on "Move Focus" will look for a DOM node with a class named in the white box. In the pre-populated example HTML I used "lookatme" as the class on the first LI. So clicking "Move Focus" will move the browser's focus to the DOM object with the class shown in the white box. In practice you could be getting a handle to the DOM object by any number of means besides the class.
3. "Delete 2nd DIV" does just that. You can Add as many DIVs as you want and Delete removes the 2nd instance up until there is nothing left but the header and footer.
4. Several 'honeypot' links are provided right below the main action links so if focus doesn't move as expected chances are good you will land on "This is not the link you are looking for".
5. All internal actions are logged in realtime in the little darker-blue log box. This makes it easier to understand how the code works by gaining visibility into what happened and when. Because web applications are doing Ajax, JiLL or Datapipe operations, using alerts will often times mask bugs by forcing asynchronous operations in to a synchronous sequence. Realtime logging eliminates this side-effect when debugging.

How it Works

var move_focus_obj;
function move_focus(dom_object,tabvalue){
	var focus_exceptions={A:1,AREA:1,BUTTON:1,INPUT:1,OBJECT:1,SELECT:1,TEXTAREA:1};
	if(	tabvalue ||
		(!focus_exceptions[dom_object.nodeName] && 
		(dom_object.getAttribute("tabIndex")==null || !dom_object.getAttributeNode("tabIndex").specified))
	)
	{
		if(!tabvalue)tabvalue=-1;
		dom_object.setAttribute("tabIndex",tabvalue);
	}
	if(document.all)dom_object.focus();
	move_focus_obj=dom_object;
	setTimeout("move_focus_obj.focus()",0);
}

1. The move_focus_obj is a global var used to temporarily hold a node pointer for focusing later as part of a setTimeout hack (described later).
2. The first parameter passed in is a DOM object. We don't care how you got the object. You could have used document.getElementByID("SomeID") or document.getElementsByTagname(object,"div")[3] or whatever. All this function cares about is that the node exists in the DOM and you want focus moved to it.
3. The second parameter is an optional value to set tabindex to. If the optional tabvalue has been passed in we ignore all the other checks and assume the user wants to set a specific tabindex value before we set focus on that node. If this value is not passed in then we assume it should be set to -1 and do the other checks for node validity.
4. If we're not using a passed-in tabvalue then we check to make sure the node is the type that needs the tabindex attribute. We do this by checking the .nodeName of the object and using that as the index into our exception array. If it is found in the array we fall through and just leave the node alone. Otherwise we continue with our 'safety' checks.
5. Before we go adding tabIndex to this node we need to make sure that it doesn't already have a tabIndex attribute. Of course IE does some winky things so we have to do some special stuff.
   
   Firefox
   .getAttribute("tabIndex") returns a null when there is no tabIndex, so if we get a null then we can go ahead and add tabIndex to the node.
   If .getAttribute("tabIndex") doesn't return a null then there is a an existing tabIndex so we leave things alone.
   
   IE
   Unfortunately in IE .getAttribute("tabIndex") returns a 0 even when the tabIndex attribute does not exist. Therefore we don't know if there was no tabIndex attribute or if it was set legitimately to 0 elsewhere. To get around this we check .getAttributeNode("tabIndex").specified to see whether the tabIndex value was specified or is just a browser default value. If the node has no tabIndex attribute the first part of if should resolve to false in IE as 0!=null but the second part should be true because tabIndex is being set to 0 as a browser default, not by the HTML or a script. Therefore we go ahead and add a tabIndex.
   
   Note:
   Doing a getAttributeNode().specified in Firefox when there is no tabIndex breaks because we would be attempting to invoke the .specified method on null, but this should never happen because of the way the if is constructed.
   If the node's tabIndex is null the first part of the if should evaluate to true, causing execution to immediately flow into the body of the if, avoiding the attempt at invoking methods on null in the latter half of the if.
   If the node's tabIndex is not null then the both the .getAttribute("tabIndex") and !getAttributeNode("tabIndex").specified should evaluate to false leaving the existing tabIndex alone. In the case of FireFox, because the node's tabIndex is not null the getAttributeNode("tabIndex").specified works fine.
   
   Also note:
   tabIndex parameter passed into the getAttribute and getAttributeNode methods must have the capital "I" to work in IE, even though the html is specified as tabindex. Firefox appears to be happy either way.
6. Now that we have figured out if there was a tabIndex for this node we can set one if needed. We used a -1 if no particular value was passed in.
7. After all that, with a tabIndex in place, you would think we could just invoke .focus() on the node. As it turns out there is a bug in IE where sometimes it can't seem to focus on newly created DOM nodes for a brief period of time. We get around this by calling the .focus() method twice when in IE. We protect other browsers from this total hack by checking for document.all before doing the second focus.
   
8. The regular .focus() also has issues in that some browsers seemed to be unable to find the node to focus on and would instead scroll the page around. To hack around this we store the object in the global var and then do a 0ms setTimeout on invoking the .focus() method on this global var. It has to be global because when setTimeout wakes up the function it calls will be in the global scope, not in the move_focus() function scope, so we had to make sure the pointer to the DOM node was in the global scope. Note that this bug only appeared on more complex pages so you might be able to get away without it, but you've been warned.

My Theory:
The aol.com folks found that, on their complex page, using setTimeout to delay the .focus() invocation (a common workaround) would sometimes fail even when waiting up to 1500ms. I suspect this issue is being triggered by garbage collection going on after the innerHTML update, which interferes with the completion of the DOM updates. This would cause a brief delay between the return of control to the JS thread and the new DOM objects actually being available. As the page becomes more complex and garbage collection takes longer the timing gap between completion of the innerHTML update and DOM objects actually being available for manipulation grows. Maybe these .focus() hacks triggers the garbage collection causing them to block until the collection is complete, allowing them to execute normally after that.


9. We currently do not remove the tabindex="-1" attribute. Having it does not hurt anything visually or with tab order and doing less DOM node attribute create/destroy operations means less potential for hitting a memory leak or other subtle bugs. I'm also concerned that removing the attribute would cause focus to be removed from the element in some combination of browser and screen reader. If a bad side effect was discovered it would be rather easy to reset the attribute to null for FF or 0 for IE after moving focus.

Big Huge Caveat

MSAA Inspector

Test Cases

Other special coding techniques

• As usual, the HTML has no JS other than the one include of focus.js in the head.
• Several often used DOM manipulations are optimized into shorthand wrapper functions at the top.
• All onclick handlers are added by the JS library. This is usually done with code like this:
  

  
  document.getElementById("some_item_id").onclick=function_name;
  

  If you are not familiar with onclick behaviors, the return false at the end of each function tells the browser to not follow the link specified in the href=. If you see pages which keeps adding a # to your URL, somewhere they forgot the return false bit or there was an error in executing the JS, which fails over to following the href link.
• As in other examples, this one uses the updated Add Event ae()function to add the init function i() to the onload event for the window. This keeps the addition of our onload handler from clobbering any other window.onload events that are already setup and it eliminates this bit of JS from the <body> tag.
• All these techniques make it simpler to add progressive enhancements to a page. An integrator can simply include the JS file and does not need to modify the HTML

Browser Support

Version History