SwingLabsAccessibility

A concise explanation about what coding for Accessibility is all about. Written by Steven Coco and originally posted to the appframework (aka JSR-296) mailinglist

Core Rules

It really is as easy as they say it is! It is nothing more than a few rules; but they are simple and easy to cover. They are really just like the Web accessibility guidelines. That one page in the tutorial contains all the details.

Accessible provides two L17N^? resources to the user: the accessibleName and the accessibleDescription. Control names and descriptions explain the purpose of the control and what the program does when it is invoked.

As the impaired user traverses the interface, each focusable component can cough up a name and a description.

All standard components provide these automatically from normal component values: the button text is used as the accessibleName, and the toolTipText is used as the accessibleDescription.

For components properly written to support Accessible, you need to provide no extra resources, and you need to do no work whatsoever, provided you have set text and toolTip on the component.

For components that do not have text or a toolTip to be used in this way, you simply still put that into your resource bundle and you directly set the accessibleName or accessibleDescription in lieu of the text or tooltip. And if the text or toolTip has been set, then explicitly setting an accessible property will override any default.

Example: A JSlider has no text that you'd set on it. Instead you still assign it some "name", put that into your resource bundle, and then set that as the accessibleName. --- The slider's toolTip will still be used for the accessibleDescription.

That's the whole of the core rules.

Specifics

Make sure you set components without such information as not focusable. This really comes under the rule of do not include extraneous information. As I mentioned with icon/image descriptions, they should not be arbitrarily set. The Web accessibility guidelines actually cover this aspect. But, it becomes clear after you have done work for the impaired directly: redundant information creates a moving target since they can only rely on focusing components, one by one, as presented to them.

Image descriptions are only appropriate for images that have meaning within context; probably not very often at all for software programs. These come into play if the image is used like an illustration: if it provides information that is not available from another part of the program, you need to write a description of this illustration, and that description needs to become available to the user: "The figure shows that the mouse has two buttons: one on the left, and one on the right".

A contrived example: This can be accomplished by using a JLabel, setting its accessibleName to something like "Figure 1", and setting its accessibleDescription to the figure's description.

But notice that for an icon on a toolbar button, the image itself needs no such description. The button will have its normal description in its toolTip: this describes the button's function. We are here talking about an explicit description of the picture itself. You should not strive to provide these since they are redundant: it does the user no good to find out that the icon is "A pair of scissors", and as I mentioned it would just make it harder for them by creating what seems to be a moving target, and just one more focusable item to traverse on the way to finding a control that does what thy want.

And more so, you should ensure that such a description does not inadvertently wind up being used as the accessibleDescription -- or toolTip -- of the button. This is what I mentioned before where I thought I saw some code extracting the image file's description and arbitrarily using it for some purpose. I don't remember what that was now. It may have been nothing too.

Taking this further, you could instead strive to provide extra-large icons for visually impaired, but not blind users. And maybe switch them to high-contrast icons. Same thing for the look and feel. --- You can just make a new look and feel that is high contrast and uses those icons, and allow them to select that LAF. The tutorial has a very rudimentary example LAF that is high-contrast. (I think: if not in the tutorial then on java.sun.com.) There may also be some available for free.

A name for a certain component should be attached in a sensible place: when you make a panel with a titled border, Swing will use that title to provide an accessibleName for the panel when it is traversed. This is sensible when the panel contains several controls, and the title usually names the group. But if you so happen to have used that panel only for aesthetic reasons to get the title to decorate a single component, then instead set that panel as not focusable, and explicitly set the accessibleName on the single component -- and this can be the very same resource used for the panel title. This will not confuse the user, and they will be able to get the control's name while they have the focus on it instead of having to traverse focus to find the name, and then possibly getting lost on the way back.

That is an example of the UI being out of direct sync with the accessibility interface; and it's the same thing as the problem with tables in web sites. Components that serve no purpose should not be traversable and should not cough up any accessible information since they are useless. GroupLayout helped that a lot by reducing even more the number of "struts" and gunk that you might otherwise need to use.

Tools

As for tools: the number one thing is to have a good visual JavaBean designer you can use to build your interface. I so happen to use NetBeans, which still has enough quirks that can cause you to have to work around the designer, but overall it goes a very long way for me. You can simply view your component tree and inspect the properties that are set. It will show you what the end accessibleName and accessibleDescription are for each component. And you can check enabled and focusable properties, and focus traversal, etc. Then you can also get those tools mentioned in the Tutorial and instrument your app or prototype to double-check and get a clearer picture.

A note about eclipse:

I just by coincidence last night grabbed the latest version and ran it to see if I could get some help with a form NetBeans could not handle. That visual designer property sheet did not show the accessible properties! That is a killer. That is extremely important. I actually could not use that GUI builder for regular work.

Well, so anyway, as I mentioned I think it would be very high on the usefulness list to enable automatic resource injection of an explicitly given accessibleName or accessibleDescription; to enable the kind of component setup I described above.

I am still actually not 100% clear about the image description: I'd like to know for sure what ImageIcon does with its given description, and if Swing uses this automatically somewhere.

Hope that helps. Ciao, Steev Coco.