public interface Accessibility
ARIA is a standard from the WAI (Web Accessibility Institute) that allows modern Ajax applications to add semantic markup to the HTML used to create modern Ajax interfaces to enable screen reader support. This semantic markup allows a screen reader to identify the function and state of complex components such as load-on-demand lists and trees even though they are composed of simple elements such a <div>s.
Note that ARIA support is the correct way to evaluate the accessibility of a web application. Standards which apply to a web site, such as ensuring that all interactive elements are composed of native HTML anchor (<a>) or <form> controls, cannot and should not be applied to a web application. A web application's accessibility must be evaluated in terms of its ARIA support.
By default, Smart GWT components will write out limited ARIA markup sufficient to navigate basic menus and buttons. Full screen reader mode is not enabled by defaut because it has a small performance impact and subtly changes the management of keyboard focus in a way that is slightly worse for unimpaired users.
The limited ARIA support which is enabled by default is intended to allow a screen reader user to navigate to a menu to enable full screen reader support. This is analogous to a partially visually impaired user ariving at a site with normal theming and needing to switch to a high-contrast skin.
To enable full screenReader mode, call
isc.setScreenReaderMode() before any
Smart GWT components are created or drawn. This implies that if an end user dynamically
full screen reader support, the application page must be reloaded, as an any existing
not have full ARIA markup.
For an overview of ARIA, see http://www.w3.org/WAI/intro/aria.php.
To completely disable ARIA markup, call
any components are drawn.
Recommended Screen Reader Configuration
The recommended configuration for screen reader use is the most recent available release of Firefox and either the JAWS or NVDA screen reader.
While WAI-ARIA markup is provided for other browsers, support for WAI-ARIA itself is known to be limited in current release versions of IE and other browsers supported by Smart GWT.
While Smart GWT enables accessible web applications to be created, it is always possible for an application to violate accessibility standards. The following is a brief and not exhaustive list of concerns for application authors:
ariaRoleappropriately. For a list of ARIA roles, see http://www.w3.org/WAI/PF/aria/roles#role_definitions. Note that in most cases you will not need to modify the default ariaRole written out by the Smart GWT framework with screenReader mode enabled.
HTMLFlow(whose default ARIA role is "article") and ensure the HTML itself is accessible (for example, has "alt" attributes on all images which are semantically meaningful)
ARIA states(see http://www.w3.org/TR/wai-aria/states_and_properties) to be written out with the HTML for a component.
"menuitem"and (if it launches a sub-menu), also the "haspopup" aria state. The code for this would be something like:
myButton.setAriaRole("menuitem"); myButton.setAriaState("haspopup", true);
Known Screen Reader bugs / quirks
JAWS: By default, JAWS treats a web page as a web document - text interspersed with graphics,
links, etc. - and not as an application consisting of form controls, interactive buttons,
lists, and so on. To enable application mode in JAWS, it is necessary to add
to the <body> tag. See
Freedom Scientific Bulletin 1404 - In ARIA, what is the difference in how JAWS
treats role="application" and role="document"?