Way back in January I watched a Google tech talk video Lego Engineering: from kindergarten to college. The talk stresses the importance of teaching engineering in schools. A few days later at breakfast I started talking with my oldest daughter, Alexandria, about engineering and what it is that engineers do. I said that engineers use what they know about science and how things work to find solutions to challenges. I threw out a challenge as an example: Build the tallest possible tower that fits in our house and then build a robot to climb it. It was just an example but she got really excited about the idea. “Can we build it. Can we. Can we.” she said. I said “sure”.

In March I posted a preview of the robot with a picture and promises of more details to come. Its taken me way to long to finally write it up. The robot has been done since May and has made a dozen or so ascents. Making the video is what caused the delay.

Here is what I remember of the process.
Continue reading…

Using positioned background images (a.k.a CSS Sprites) has a number of benefits:

• Performance. One of the performance recommendations made by Yahoo’s performance team is to reduce HTTP requests. One way to do this is using the CSS Sprite technique — combining many images into a single background image.
• Skin-ability. With the img tag the image URL is in HTML markup where it is hard to change. With CSS Sprites the image URL is in a CSS file making it more convenient to change. Sure you can change the contents of the original file but there are reasons for changing the URL. It is not as easy to move the images to a different server or group them in different image files when the URL is not in CSS.

However there are drawbacks. The biggest is accessibility, specifically high contrast mode. In high contrast mode all background images and colors are ignored — replaced with high contrast colors such as white on black or black on white. The other issue is that background images are not always printed.

The prevailing accessibility advice is to not use background images for functional images. The underlying problem is that there is no way in HTML/CSS to identify a background image as being functional. They are all considered decorative. It is also true that not all img tag images are functional but again there is no way to distinguish them for the purpose of high contrast mode. So high contrast mode makes a reasonable assumption that background images are decoration to be removed and img images are functional and must be shown. From here on I’ll call functional images icons. They either convey important information or are interactive (like a toolbar button for example).

I have seen recommendations that functional background images should be replaced with text when high contrast mode is detected. This does not seem right to me at all. A desktop app does not change its toolbar button icons to text in high contrast mode. The assumption is that icons are already designed to have reasonable contrast.

It also just feels right to me that the icon URLs should come from CSS.

Since I care about performance and accessibility I’m not happy with this conflict. I want a solution that puts the icon URL in CSS, works in high contrast mode and allows me to combine icons into a single image file. Here is what I came up with.
Continue reading…

While working on some accessible UI widgets I found strange behavior in IE8 related to when it does or doesn’t show the focus outline around an element that has focus.

When you use the focus method to set focus to a focusable element the expectation is that, in the absence of css rules to the contrary, the browser will show a focus outline around the element using its default style. This is what happens in Firefox, Chrome, and Safari. (Opera has its own set of focus problems which I didn’t investigate fully.)

There are a number of elements that are naturally focusable, such as inputs and anchors. In addition any element with a tabindex attribute equal to -1 is focusable. If the tabindex is non-negative then it is focusable and in the tab order. My test case uses list elements with tabindex of -1 or 0. I suspect that the same is true of other elements using tabindex.

Older versions of IE (I tested IE6 and I believe IE7 works the same in this regard) had some strange additional requirements beyond just calling focus. The outline would not be shown if the focus method was used to give focus to an element with a tabindex of -1. So before setting focus you would have to set the tabIndex to zero (or a positive number).

elem.tabIndex = 0;
elem.focus();


Also if you click on an element with tabindex of -1 no outline is shown unless the className is updated (even if the value doesn’t change). Perhaps other style changes would work as well.

IE8 adds some new bizarre behavior. First if css is used to set an explicit outline style on the elements (either directly or inherited) then the old IE quirks mentioned above go away as well as the new IE8 problem described below. Setting your own outline style for focus isn’t a good idea unless you are giving your whole web app a focus style makeover. I think it is best to stick with the default styles since it is what the user is probably used to. There is also the problem of old browser like IE6 not supporting the outline style.

If the className of the element receiving focus is updated in the onfocus handler while the tabIndex is -1 then no focus outline is shown. Assuming that the tabIndex is -1 and addClass is a function that adds a class to the className, one would expect the following two lines of code could be executed in either order.

addClass(elem, "myfocus");
elem.tabIndex = 0;


In IE8 setting the tabIndex to zero must be done first or the outline is not shown. This is exactly what tripped me up. If I just happened to write the statements in the opposite order I would never have discovered these oddities.

Note that in all cases focus is actually set correctly it is just the visual indication of focus that is wrong - but thats the important part of focus.

I created a test page that allows playing around with these rules. It is also an example of how focus can be managed with a roving tabindex. If you play with this page in different browsers you will notice that in Firefox (versions 2 - 3.5) , Chrome, and Safari 4 (I tested on Windows) it doesn’t matter what options are checked, the behavior is correct. In IE you can play with the options to see which combinations work.

I wonder if this is intentional in IE8 or is something that will get fixed in a point release.

I mention Oracle in this post so as a reminder: my views are my own and do not necessarily reflect the views of my employer.

One nice thing about working at Oracle is that they take accessibility seriously. I have worked on web apps before that were supposed to be accessible but this is the first company I have worked for where I could actually get my hands on a (non-demo-mode) JAWS screen reader to do my own testing. You can try to follow all the best practices but you really do need to test with a screen reader to know how well you have done.

I have found that keyboard accessibility and screen reader accessibility are somewhat at odds.

If you do the right thing for keyboard accessibility (i.e. managing focus) and don’t use WAI-ARIA at all then you have a chance of being accidentally partially accessible in JAWS and probably other screen readers. This is assuming that you follow best practices for being accessible to screen readers (use label correctly, use native form controls – links, checkboxes etc. in semantically appropriate ways).

The problem is that all your keyboard/focus management logic is in vain since you are probably going to use arrow keys and JAWS is not going to give them to you (JAWS uses many keys for itself). The reason you have any chance of success is because the normal screen reading behavior of the arrow keys may be close enough and using native form controls will allow JAWS to access them in a reasonable way. How well it works will depend on the details of your rich control. The best you can do is to try to find the right balance between normal use and screen reader use. This should work OK with older browsers and screen readers depending on the various bugs and odd interactions between various browser and screen readers.

The other option is to go the full WIA-ARIA route. By using the appropriate ARIA roles and states and properties you can get JAWS version 10 (and presumably other new ARIA aware readers) to give you the keyboard keys you need. For this to work you need very recent versions of browser and JAWS. I have had some initial success with JAWS 10 and FF3.5. It looks like this approach will provide the very best functionality for all users. I have not yet tried the combination of JAWS 10 and IE8. The trouble is that the combination of JAWS 10 and IE7 works quite badly when you use ARIA. JAWS seems to get some of the ARIA information like roles but doesn’t get enough to work correctly. It gives up the keyboard keys but then doesn’t handle the ARIA based changes and therefore the normal JAWS arrow key functionality doesn’t work either. This is the worst possible behavior. Presumably older versions of JAWS that don’t know anything about ARIA will work fine with IE7 even if the rich control uses ARIA provided the ARIA support is on top of non-ARIA techniques mentioned previously. I have not yet tested this combination.

To me this means that if you are adding on to an existing app that must support older browsers or screen readers then using ARIA probably isn’t worth it yet. But if you are starting a new app that wont be released for a while then using ARIA is the way to go. You can still support older browsers but you would have to require that for screen reader accessibility an ARIA aware browser and reader must be used.

Another possible solution is to have an option to turn WAI-ARIA support on or off. I don’t like this because of the added complexity of implementation and testing.

Here are some resources that I found very useful in my recent accessibility work: Improving Accessibility Through Focus Management, WAI-ARIA Best Practices, and Delegating the focus and blur events.

Since my last post where I presented a number of ideas on a declarative domain specific language for implementing web applications, I learned about the language oriented programming paradigm.

I recommend reading “Language Oriented Programming” by M. P. Ward. It also claims programmer productivity as a benefit of what it calls the “middle-out” development style.

In a couple of recent posts I have argued that a higher level language is needed to
provide a significant boost to programmer productivity in the area of web applications. This is a topic I have been thinking about for many years. I’ve worked out some aspects of what I think the language should be. A little over a year ago I even started implementing a parser for the language in ANTLR. I worked on it for a few weeks before moving on to other higher priority projects. Higher priority simply means something more interesting caught my eye. It’s finally dawning on me that I’m not going to get a big enough block of free time to work on this any time soon. I guess I prioritize the smaller projects that have a better chance of getting finished.

Instead of mothballing the project completely I’m going to share some ideas from it. This his may be of interest to others and who knows, I may get back to it from time to time.
Continue reading…