Just announced: Level Access and eSSENTIAL Accessibility agree to merge! Read more.

Google’s Web Toolkit (GWT) and enhanced version GXT provides a framework for creating Ajax enabled sites and applications. Beginning with version 1.5 (the current version is 2.2) the toolkit has provided a framework for accessibility support through the Accessible Rich Internet Applications specification (ARIA). This post will provide some information about my initial review of accessibility in GWT.

GWT is a compiled framework that is written in Java. An Eclipse environment is typically used to generate GWT code. While the toolkit does provide the ability to directly set HTML code for a widget, accessing the actual DOM, CSS, and HTML is more abstract than other toolkits such as JQuery. As a whole, the GWT widgets seem to use more generic containers such as DIVS and thus rely more on ARIA to provide accessibility than the JQuery toolkit. This is compared to the Jquery widgets that are rendered are more lightweight and tend to use more standard HTML. For example, the Jquery ToggleButton uses a standard checkbox hidden behind the facade of a button. Assistive technology knows how to work with a standard checkbox. The GWT ToggleButton uses a DIV. Because of that ARIA must be used to expose states and roles.

ARIA is not as well supported yet by assistive technologies and browsers. For example, when a DIV is used some of the standard methods such as the onClick event are not triggered programmatically by the user agent when the enter key/space bar is pressed. This can be compensated by using an onKeyDown event. However, assistive technologies such as screen readers use virtual navigation modes where the enter and space bar are trapped and not sent through to the browser. Instead the assistive technology must call the click event on the element — and it determines whether to send this event based on the HTML element type and whether ARIA is present. These factors make the process of getting solely ARIA based widgets to work with assistive technologies like screen readers complex.

There are accessible widgets that are provided directly in the toolkit, however, others only partially support accessibility, and still others require that the developer add in accessibility by extended the widget or by setting accessibility properties on the instance of a widget. Because GWT is a compiled toolkit, when GWT is used, the whole application is generally written using that toolkit. When some other toolkits are used, many elements used in applications may be from the toolkit but others are not and use standard HTML/XHTML.

The following GWT widgets use standard HTML elements: Button, RadioButton, CheckBox, TextBox PasswordTextBox, TextArea, Hyperlink, ListBox. Other widgets such as push button and ToggleButton use DIV elements with a tabIndex of 0 set with some ARIA attributes. However, the ARIA attributes appear to be only partially implemented. For example, the PushButton does not appear to set the aria role of “button”. Still other widgets such as the DatePicker lack the internal keyboard support needed for such as widget. The Tree widget has many of the ARIA properties in place such as the roles of “tree” and “tree item”, a tabIndex, but lack the complete ARIA states to make the tree completely functional for the user of a screen reader.

Finally, testing for accessibility is an interactive process of making a change and seeing how it responds to assistive technology. Thus, recompiling and GWT application and testing with multiple assistive technologies after changes can be a more involved process.

It is exciting to see many toolkits embracing accessibility and support of the ARIA technical specification. In the short term applications created in GWT and ARIA based are likely to face obstacles in functional accessibility due to support by the user agents that are in place within an organization, the assistive technology and version being used, as well as the complexity of creating widgets that must support all accessibility aspects, visual and programmatic focus, identity, state, role, events, keyboard access, visual appearance, and so on. These challenges will be dimished over time as ARIA support increases and newer user agents become standard with organizations including the US Government.

Information on the Google Web Toolkit can be found on the Google Web Toolkit Site