First step in accessibility

Michael Vogt
On Jul 8, 2013 11:25:00 AM

I wrote an introduction to WAI-ARIA blog post awhile ago. With Vaadin 7.1 comes now the first little step towards being able to develop accessible Vaadin applications using WAI-ARIA. With this, Vaadin components start to be accessible by applications like screen reader and devices like braille displays. Thanks go to Marco Zehe from Mozilla and Jari Mikola from NKL (Finnish Federation of the Visually Impaired) who provided invaluable feedback and tested if the implementation works for certain setups.

We started to target Internet Explorer 8 as the minimal browser requirement. But we ran into so many problems, that we now only check with Internet Explorer 10, to make sure it is usable. So the main browser we implement for is the current version of Mozilla's Firefox. Testing is done mostly with JAWS 14 from Freedom Scientific, occasionally with NVDA.

The selection of components to work on was based on a customer project. It was decided to start from the inside out

New for Vaadin 7.1

The components that have been enhanced in this way for Vaadin 7.1 are:

  • Button
  • TextField
  • PasswordField
  • TextArea
  • DateField
  • CheckBox
  • ComboBox
  • ButtonGroup
  • Tree
  • Tooltip

Most of this functionality should be available automatically on the client side. Only when additional information is needed, the server side was changed, to allow the application developer to provide it. Additional API calls so far are:


setIcon(Resource icon, String iconAltText)
setIconAlternateText(String iconAltText)


setItemIcon(Object itemId, Resource icon, String altText)
getItemIconAlternateText(Object itemId)
setItemIconAlternateText(Object itemId, String altText)

setIcon(Resource icon) is extended, to make sure, an alt="" attribute is added to the Element.

The rest of the work that was done helps assistive devices (i.e. Screen Reader) to recognize the widgets and announce them correctly to the user. For the Button, a role=button attribute was added to the container element. To make sure that the separate states are recognized by assistive devices, state attributes like aria-disabled="<true/false>" were added. These states are updated automatically.

So the HTML for a disabled Button looks like this: <div tabindex="-1" role="button" class="..." aria-disabled="true">…</div>

For the above mentioned form elements, the valid- and required states are handled using a new client side class AriaHelper, which contains static functions to handle these states correctly. When you create your own client side Widgets, this class should make some general things easier. I'd expect that additional functionality is added to this class as we continue working on accessibility.

The provided functions are:

handleInputInvalid(Element element, boolean invalid)
handleInputInvalid(Widget widget, boolean invalid)
handleInputRequired(Element element, boolean required)
handleInputRequired(Widget widget, boolean required)

Just provide the Widget or Element that should be declared invalid or required for assistive devices together with the respective state.

In case the WAI-ARIA attributes need to be added to a special Element inside your Widget, we introduced new interfaces to handle this:


When implementing these interfaces, you can provide the correct Element that should receive the WAI-ARIA attributes to the AriaHelper functions.

The final additions are functions that help to handle Captions, called labels in HTML. The function in AriaHelper for this is

bindCaption(Widget widget, Element captionElement)

Provide the Widget or Element the caption should be bound to, together with the Element of the Caption. The details for doing this are handled by the function. It adds an HTML for="<id>" attribute to the caption and an aria-labelledby attribute to the Widget and makes sure required id's are available.

A TextField with Caption looks like this:

<div class="v-caption" id="gwt-uid-15" for="gwt-uid-16">...</div>
<input type="text" class="..." id="gwt-uid-16" aria-labelledby="gwt-uid-15">

The function for the ID handling is ensureHasId(Element element) which is also part of the AriaHelper class.

There are 2 tickets in trac related to this functionality:

  • Use <label> for caption element
  • Correct ID handling

Prepared for Vaadin 7.2

That's it for Vaadin 7.1. As I said, a small start. But the work is already continued for Vaadin 7.2, which will provide accessibility for:

  • TabSheet
  • (Sub)Window
  • Notification

The implementations for these are hopefully soon in the master branch in the Vaadin Git repository, so feel invited to check them out. Up to date information about the state of accessibility for Vaadin will be provided in the dev team Wiki.

As WAI-ARIA is based on attributes on DOM Elements, a little add-on I wrote might help you to go even further. It allows you to add an attribute to the root Element of a Component. When there is interest, I am happy to extend its functionality.

Feedback welcome

Hope this gave you an idea about the state of the accessibility as it is right now for Vaadin. What do you think?

The current implementation and selection of Components so far was based on a customer project. We are very interested to hear from you if these cover your needs, and what we can do for you to offer even better accessibility.

Tip at the end, which I already heard at so many places. Now I know what this actually means: Making an existing source base accessible is incredibly hard. It will save you a lot of trouble when you have accessibility in mind from the start.

Michael Vogt
You haven't yet written a blog author profile for yourself. Go to My Account page to write a short description of yourself.
Other posts by Michael Vogt