geedew :: Web Design, Programming, Professionalism » HTML

jQuery UI Dialog Accessibility

Drew — Fri, 26 Feb 2010 02:52:17 +0000

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.

On page load
Get the first element that can be tabbed to in the body
When this element gains focus, check for a visible dialog
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
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.

Usability and a Simple JavaScript hovering menu

Drew — Sun, 06 Dec 2009 02:20:11 +0000

Many web developers ask ‘what is usability?’. This is one of those topics that I can explain, but it may be easier to demonstrate. My this experiences have led to some principles; one of them is that if I’m going to build it, it must be usable. Unfortunately, many sites that I like, that tout usability, screw up one important concept that annoys me greatly.

I ask myself, “when using a menu, why do I have to drag my mouse from one button to the next, and fear losing the menu if I cross it’s border anywhere?” Some menus are just annoying because they disappear mid mouse move, some are extremely hard to use because of several layers of menus, some I have resorted to using `tabs` to get to the correct menu item. It’s unfortunate that people can’t get this right.

I have a simple fix that hopefully sharing it will help others. It’s basically a menu that buffers the time you are hovering, that way if you mistakenly move your mouse into the wrong area, you have a brief period of time to correct yourself.

Start with the HTML code:


	ONE
	
		one
		two
		three
		four
	
	
	TWO
	THREE
	
		one
		two
		three
		four
	
	
	FOUR
	
		one
		two
		three
		four

The menu is a simple list within a list. There are essentially only four main list items; ONE, TWO, THREE and FOUR. Each of this list items has their own list of list items generically named one, two, three and four. I personally stick with lists as my menu’s of choice because they degrade gracefully in case of CSS/JavaScript issues.

This list by itself isn’t much, in fact it’s not even a menu. CSS will be needed to really make it work correctly.


#menu li {
	list-style:none;
	float:right; /* Makes IE 6,7,8 act like FF */
	position: relative;}
#menu li a {
	display:block;
	width: 160px;
	height:35px;
	margin-top: 5px;}
#menu li a span{
	padding-left:10px;
	line-height:2.8em;
	color: #000000;
	font-weight:700;}
#menu li a:hover {
	font-weight:bold;}

#menu li ul li a:hover span{ color: #222222; }

	#menu li ul {
		margin:0px;
		position:absolute;
		left: 160px;
		top:-90px;}
	#menu li ul li {
		padding:0px;
		border:0px;
		border-collapse:collapse;
		margin:0px;
		height:34px;}
	#menu li ul li a{ margin:0px;padding:0px;border:0px;}
	#menu li ul li a span{
		display:block;
		padding-top:7px;
		font-weight:100;
		line-height:1em;
		font-size: 83%;}

This is some simple CSS that will make the UL/LI lists to really act like lists. Now the only issue is that you need it to act like a list. So the final piece of code to this puzzle is to add some JavaScript. I am using the jQuery library as my choice for creating this script, so it’s necessary to have that package (1.3+) installed for this to work. You can drop this script into the footer element inside of ‘script’ tags so it will run. It will run automatically on page load.

$(document).ready(function() {
	/* Setup the Menu */
	$("#menu > li > ul").hide();

	$("#menu li.nav").hover(
		/* on mouseover */
		function(e) {
			hoverMenu = this;
			if(this == closingMenu) {
				clearTimeout(closeMenu);
				clearTimeout(openMenu);
				$(this).find("ul:first").show("fast");
			} else {
				var newMenuOpen = function() {
					$(hoverMenu).siblings(".nav").find("ul:first").hide();
					$(hoverMenu).find("ul:first").show("fast");
				}
				openMenu = setTimeout(newMenuOpen, 500);
			}

		},
		/* on mouseout */
		function(e) {
			closingMenu = this;
			var closeMenu = function() {
				$(closingMenu).find("ul:first").fadeOut("fast");
			}
			closeMenu = setTimeout(closeMenu, 500);
		}
	);
});

The final product is quite a nice and simple dynamic menu that adds just the right touch of usability. Now, typically, I would never say that a menu with sub menus popping up everywhere is something of a usability menu system, it’s not. But sometimes, a nice menu like this is needed, especially if there is a lot of information and ‘drill downs’ that need to be accessed quickly. In any case, you can see my demo here. Leave some comments if you have any questions, and enjoy! You can also see a fully implemented version at Xcessorries Squared.

Scribd and Slide mode : Why is my height wrong?

Drew — Thu, 30 Jul 2009 05:06:02 +0000

While recently using Scribd‘s services, I came across a very nasty bug, and a nice clean fix. Scribd allows developers to tap into a great, but somewhat basic API. One of these settings allows a developer to set a default ‘mode’ before the API then builds the flash calls necessary to display the document. The issue comes up when you choose the ‘slide’ mode as the loading view. No matter what ‘height’ you set, with ‘auto_size’ set to false, the height will adjust to the wrong height.

You can jump to the code here, or continue.

I started by writing some simple code that follows the API.

scribd_doc.addParam( 'mode', 'slide' );
scribd_doc.addParam( 'height', 800 );
scribd_doc.addParam( 'width', 600 );
scribd_doc.addParam( 'jsapi_version', 1 );
scribd_doc.addParam( 'auto_size', false );
scribd_doc.write( 'flash_catalog' );

Where ‘flash_catalog’ is the container div of the Scribd PDF.

This however led me to have a height that follows the default rules (width multiplier of 85/110) where the height matches how much space is in the window. So I progressed further with this code.

var oniPaperReady = function(e){
 $("#flash_catalog embed")
.attr("wmode","transparent")
.hide()
.css({"height":"800px", "width":"600px"})
.show();
}

scribd_doc.addEventListener( 'iPaperReady', oniPaperReady );
scribd_doc.addParam( 'mode', 'slide' );
scribd_doc.addParam( 'jsapi_version', 1 );
scribd_doc.addParam( 'auto_size', false );
scribd_doc.write( 'flash_catalog' );

So now I am dropping in a listener in the API to wait for the document to load. I then hide the ‘embed’ flash information, then add the height and width, then re-show the flash element.

You may notice, I’m using jQuery, in which you can do the same thing with regular JavaScript, although quite a bit more complicated (ask if you really really need that code).

An astute reader would also notice one thing, I’m not adjusting for an ‘object’ tag, only the ‘embed’ tag (the difference for flash between different browsers). I figured out this novice mistake while testing in Internet Explorer. Here’s the finished code, that works, removing the nasty height issue.

var scribd_doc = scribd.Document.getDoc( #######, 'key-*******************' );

var oniPaperReady = function(e){
$("#flash_catalog embed")
.attr("wmode","transparent")
.hide()
.css({"height":"800px", "width":"600px"})
.show();

$("#flash_catalog object")
.attr("wmode","transparent")
.hide()
.css({"height":"800px", "width":"600px"})
.show();
}

scribd_doc.addEventListener( 'iPaperReady', oniPaperReady );
scribd_doc.addParam( 'mode', 'slide' );
scribd_doc.addParam( 'jsapi_version', 1 );
scribd_doc.addParam( 'auto_size', false );
scribd_doc.write( 'flash_catalog' );

The final word; I’m adding the transparent mode so that I can then have a menu that drops on top of the flash. This works very well!