jQuery UI Dialog Accessibility

jQuery UI is an amazing product. It’s not because it offers the best features, or that it offers the best solution, it’s that it offers a large degree of support for years to come. Which is saying a lot for something that is nothing more than JavaScript. It’s certainly something that many enterprises have begun to look at and look for in the development world. At my job at Coventry Healthcare, I’m responsible for the User Interfaces and generally the User Experience across some very highly visible web applications. One of the most recent developments in our line of business is the risk of not having an accessible site (we fall under Section 508 guidelines because of our Medicare/Medicaid users). jQuery UI has literally allowed me to very easily create and maintain large amounts of code so that I can spend more time making sure that it follows WCAG 2.0 and WARIA (which should cover us for S508).

So recently I discovered a very nasty bug dealing with jQuery UI dialog (withe modal:true) widgets that seems to only occur in Internet Explorer. It goes like this: If you are using a dialog with a screen reader, your main mode of navigation is with the keyboard. This is typically driven via the focus on elements. In jQuery, focus is demanded on the dialog because of the modal command. You are unable to focus on anything other than the dialog and it’s elements. Here’s the issue however, jQuery successfully can keep focus on the dialog in all browsers tested (FF, Safari, Chrome) so that the focus cannot leave the dialog. However in Internet Explorer (6, 7 and 8 ) your focus can get to the address bar, simply by tabbing to it. Once in the address bar, jQuery is no longer able to track and handle the focus, so inevitable, after tabbing through the menu, focus come back to the window. But instead of going to the dialog, it goes to the first element that can be tabbed to, which is undoubtedly BEHIND the modal dialog. jQuery, subsequently locks the tabbing at this point, most likely because you have focus on and element that is unable to be focused (in jQuery’s dialog algorithm).

So I cannot have this as that would literally cut 75% of my users from being able to use just a keyboard with the sites I’m maintaining. So I had to find a solution. First, IE seems to be the only browser with this issue and it has something to do with the fact that the focus moves out of the DOM’s control (out of jQuery’s control). But the focus would always at least get back to the first element that could be tabbed to, and then lock. So I devised a plan. What if the first element, when focused, looks for an open dialog and if it is there, focuses on that dialog? So I tried it out, like this.

$(document).ready(function() {
    $(":tabbable:first").focus(function() {
           $(".ui-dialog:visible:last :tabbable:first").focus();
    })
});

Amazingly enough, this is the exact solution to the issue. This is how it reads.

1. On page load
2. Get the first element that can be tabbed to in the body
3. When this element gains focus, check for a visible dialog
4. Take the visible dialog that is last (the last one drawn in the html) and get the first element that can be tabbed in it
5. give focus to that first element.

Now, in IE, when focus returns to the document, it goes to the dialog box, specifically, the close icon on the dialog box, thereby not breaking the fact that there a modal open on the page.

Now, there are some issues with this. For one, the code is just assuming that the last dialog in the html that is visible is the one that is to be focused on. Quite frankly, that’s what I need it for, as I try not to overlay dialogs, and when it do, the newest one is normally always on top. However, there are times where you may swap between two dialogs, and the one that is on top is not the last dialog in the html, you would still have this issue in this case. But for probably the other 95% of the cases, this is a clean and easy way to ‘fix’ the accessibility issue in IE with jQuery UI dialog modals.