The state of web accessibility in the JavaEE world

| akquinet tech@spree

This post is intended to give an overview of the state of web accessibility (a11y) in general and within the JavaEE world in particular. The first section outlines the how and why of accessibility, followed by an introduction to web accessibility. The next section deals with common a11y problems in an average JSF web application. Finally, we summarize the current state of a11y in JavaEE.

a11y – why should you care?

There are many reasons why you should care about a11y but probably the most important one is simply because you can make a real and significant difference in the lives of people – people that have a hard time even without inaccessible applications!

But just in case improving other peoples live is not enough to convince you, there are many more reasons. For example, by not excluding people with disabilities, you are targeting a bigger audience and therefore many more customers. Caring about a11y can therefore directly improve business.

Additionally, many nations have laws in place prohibiting the exclusion and discrimination on the basis of disability. The German Behindertengleichstellungsgesetz (BGG) for example mandates that all web sites in the public sector must conform to the rules of the Barrierefreie Informationstechnik Verordnung 2.0 (BITV 2.0) (roughly translates to Accessible IT Act). Although this does not require private entities to provide accessible web pages, it is highly recommended. Therefore new or updated web applications created for the public sector must be accessible in Germany and most other European countries.

And there are not only legal and business reasons to consider a11y. Usually, an accessible web application also provides a better user experience for users without disabilities. The use of strong contrasts for example, creates more readable pages for people with good vision and for people with visual challenges alike. Or consider the inclusion of common keyboard shortcuts for certain actions on a page. They not only make it easier to use the site without the use of pointing devices – they also make it more pleasant for power users!

You can find more information about why accessibility matters on “Accessible Culture”.

a11y in the era of the web

For most people these days, using a computer means using a web browser. A lot of day to day tasks like writing emails or creating spreadsheets can easily be achieved with web applications. But how accessible is a common web application?

A well written web application, even an interactive AJAX heavy one, can be fully accessible to completely blind users. On the other hand, a badly written web site can make no sense at all to a person without good vision and locomotive skills. Even people with these skills can get lost in a bad user experience. How often have you been lost in the checkout process of a badly designed web shop?

But let’s take a step back and look at what assistive technologies exist today to make web sites more accessible.

Mostly text

Most traditional web sites are text heavy. Navigation usually works via text links inside of the web page. Those links lead to other pages. Input is handled via textual input forms. This rather simple interaction model makes a11y easy. All modern web browsers can easily scale the text rendering to adjust font size for people with impaired vision. Scaling usually creates some minor layout issues but the web site in general remains perfectly usable.

People that need further support can either use a braille display or a screen reader. Both of these technologies use more or less the same approach. They take the HTML DOM (basically the page source), strip or replace items that make no sense without visualizing them (images for example get replaced by their alt texts) and create a pure textual representation of the web site. This textual representation of the web site is either fed to the braille display or read aloud by the screen reader.

The main focus of this post lies on screen reader technologies. Screen readers are available for every major platform and they are easy to use even for people without disabilities. Learning to read Braille with your fingers on the other hand would be quite a task.

Currently, there are four major screen readers:

With each of those ScreenReaders, visually impaired users have a decent chance of consuming well written web pages.

Helping the screenreader

But what makes a web site work well with screen readers? To get a good first impression, just unplugging the mouse and trying to use a web site will quickly show problematic areas. If it is impossible to use a website only with the keyboard while looking at it, it is certainly not easier without visual support. Basic focus handling and a navigation that does not depend on hover effects are a requirement here.

To further help screen readers, always use the actual tag along with its ‘for’ attribute to give inputs labels (instead of just visually placing a div or span as a label next to the input). Real labels help screen readers identify inputs and also provide a larger click target for check- and radio boxes.

Another low hanging fruit on the way to great a11y is the ‘alt’ attribute of images. Always give images a meaningful alternative description. Images with an empty alt-tag will have their full filename read to the user. This is a nice way to drive the user mad, especially with generated filenames. If no meaningful alt-text can be found for an image, just leaving the attribute empty will make the screenreader not read anything. Therefore an empty alt is always better than no alt-text at all. However, images without a clear alt-text are usually only decorative elements. Such images are better inserted via CSS instead of being placed in the HTML anyway, because they are not part of the semantics of the page.

Just following these three guidelines (make the page usable with only the keyboard, use real labels and always set meaningful alt texts) is a great starting point for accessible static web pages in all browsers and screen readers.

It’s the browser wars all over again

When comparing the output of each of the available screen readers, it is obvious that there are huge differences, and not just regarding their synthetic voices. When websites are just slightly more complex, their output differs significantly. Although there are efforts on standardizing screen reader behavior, we are just not there yet.

One can’t help but be reminded of the early browser wars where it was basically impossible to create web sites that looked and functioned the same on all major browsers. In the same way, focussing on just one screen reader may not yield the same results on the other readers. But it is very likely to at least improve their output significantly as well. Therefore it is hugely preferable to focus on at least one screen reader instead of giving up and ignoring a11y completely.

A quick introduction to VoiceOver

VoiceOver is a system wide feature of every Mac OS X (and iOS) system. It is free, installed by default and therefore widely available. Also, Apple is putting serious effort into improving it constantly. The recent version of OS X 10.8 had lots of a11y improvements (VoiceOver Improvements).

To enable VoiceOver on OS X just press CMD-F5. A friendly voice will inform you that VoiceOver is now active. A thorough list of VoiceOver keyboard shortcuts can be found on Apple’s support site. Don’t be intimidated by the length of that list. You only need a few basic commands. The rest is for power-users to navigate quickly around the screen without seeing it. The default VoiceOver (VO) Keys are CTRL-ALT. Pressing VO-Space interacts with the currently read item. VO-Left and VO-Right navigate to the next and previous items. Use VO-Shift-Down is used to focus in on an item.

One other nice feature for developers is the screen curtain. Activate it via VO-Shift-F11. It blanks the entire screen. Try activating the curtain and navigate your current web app, the app that you should know best, to get an idea about how accessible it is. There is a good chance that you will get completely lost (or drive your coworkers crazy if you don’t use headphones).

a11y 2.0

Web sites today aren’t just static pages anymore. Web applications make heavy use of AJAX to update their content and sometimes even to avoid page navigation in single-page web apps. Items are often used as input controls that aren’t actually input controls (clickable divs as buttons and sliders for example).

To common users, this is no problem. The user usually sees the content change on the page or the visible clues that a div is clickable. But what about the user who can’t see anything – at all?

Screen readers can’t just announce each and every HTML DOM change happening on a page. Out of context, this would be much more irritating than helpful. Are visually impaired users unable to use such web application? Mostly yes, they are. Unless the developer of those applications takes special measures to help them.

As part of the HTML5 spec, the Web Accessibility Initiative is creating a standard for Accessible Rich Internet Applications (ARIA). The ARIA standard defines special attributes to aid screen readers in presenting accessible versions of the page. Furthermore it also defines how assistive technologies (usually screen readers) should react to those attributes. This will, in the long run, make it easier to create web applications that work very similarly in all compliant screen readers. Currently none of the available screen readers support all of ARIA and the supported subsets aren’t necessarily overlapping.

A comprehensive introduction to ARIA could easily be a series of blog posts on its own. Therefore we will only give a very short introduction to the most relevant ARIA attributes here.

ARIA Roles

ARIA defines a set of roles that can be used to declare a semantic structure in the HTML. Along with some of the more semantic HTML5 tags like <header> and <footer>, this can give users without vision a clear idea of where in the page they are and support them via quick navigation features of their screen readers. There are defined roles for the document structure (like heading, list or article), roles for navigational landmarks (like navigation, search or main) and roles for widgets (like menu, dialog or button). The widget roles are especially important when non-input components such as divs are used as inputs. The roles are used the way any other attribute is used:

…
<ul class="navigation-menu" role="navigation">
	<li><a href="#main">Start</a></li>
</ul>
…

A complete list of roles is available here.

ARIA Live Regions

The second, very important set of ARIA attributes are live regions. Live regions are crucial for AJAX-heavy applications. Regions are areas in the DOM that get watched for updates. It is possible to define how screen readers are supposed to read changes to a region. Anything on a page can be a region and pages can have more than one region. It is important to realize that updates to regions will be announced but they will not get focus. Separate focus handling might be necessary. A live region is created via the ‘aria-live’ attribute:

<div class="user-feedback-area"></div>

The aria-live attribute has three possible values: off, polite and assertive. Off is also the default. In that state, updates won’t be announced. Polite regions will wait until the screen reader is finished announcing whatever it is currently announcing. The third setting, assertive, will make the reader interrupt its current announcement (if any) and immediately read the changes. This should not be used lightly because the interruption can be very confusing. There are two more attributes ‘aria-atomic’ (values: false|true) and ‘aria-relevant’ (values: additions|removals|text) that give more control over the type of announcements. Atomic regions are always read in their entirety whereas for non atomic regions only the changes are read to the user. The relevant tag can be used to only announce additions or removals. A good example for such a region would be a chat box, where only additions are interesting to the user and it is not helpful to always read the entire conversation. Therefore a chat box should be marked with ‘aria-live=”polite” aria-atomic=”false” aria-relevant=”additions”‘

The WAI has more information about live-regions.

Note, that in the current version of VoiceOver, live regions only work when they are in the original page source. It is therefore currently not possible to add further regions to the page via AJAX calls. They will just be silently ignored. This is a big limitation for single page apps and will hopefully change in the future.

Accessible JSF?

How does all this apply to JSF? And what is JSF anyways? JSF is the recommended view technology for creating web interfaces in the JavaEE stack. JSF is a component-based web framework. It abstracts away most of the web-specific markup with JSF-specific components. JSF comes with a fairly basic set of components for layout, forms and data output. Those components are later rendered into HTML markup and often assist JavaScript. The actual generated markup of a component is an implementation detail of the component.

As long as the available components are sufficient to fulfill the requirements of the frontend, this enables developers to quickly produce complicated markup without having to understand the inner workings of those components. A few lines of JSF markup often generates hundreds or thousands of lines of HTML.

It is also possible to create custom components, but since JSF components are much more involved than pure templating (e.g. data binding, integration in the JSF live cycle, supporting scripts etc.), the creation of components can get a bit complex. However, there are many component libraries available that extend and expand the standard components with sometimes highly sophisticated widgets. The two biggest component suites at the moment are Rich Faces and Prime Faces.

This component based approach is one of JSF’s main selling points. But when it comes to a11y, it is also JSF’s Achilles’ heel. The developers have little influence on the generated HTML. Therefore it is not always possible to attach the ARIA attributes at the right places in the HTML. The a11y of a JSF application depends completely on the accessibility support of the chosen component suites. The default components available in all standard JSF implementations are not accessible. But as of JSF 2.2, which was finalized earlier this year, it is now possible to pass custom attributes through to the generated markup of most components. This new feature is called pass through attributes and finally allows JSF developers to place the appropriate ARIA attributes in the right places with ease. Before JSF 2.2, the placement of custom (i.e. ARIA) attributes onto the generated markup of most components was a highly involved process requiring lots of boilerplate code.

Sadly, pass through attributes have not yet arrived in the current stable Rich Faces and Prime Faces versions. Their a11y support is currently not good enough to create truly accessible rich web applications, even though they both wrap jQuery UI components for many of their widgets. jQuery UI itself is constantly improving their ARIA support, but the JSF libraries usually lag some versions behind and therefore have a disadvantage when it comes to a11y. And apart from using jQuery UI internally, it appears as if a11y and ARIA support is not yet a prime focus of either Rich Faces or Prime Faces.

This leaves JSF developers in a bad position regarding a11y. Today’s primary web frontend technology for JavaEE applications is less than helpful in creating accessible, modern web applications. The native JSF components enable the basic creation of accessible web applications but the feature rich component suites give the developers too little control over the generated markup too make use of most of their components.

To create an accessible web application with current JSF 2.2 technologies, one would have to create a complete set of custom UI components that incorporate ARIA and other best practices of a11y. However, this is not an easy task. Creating components is a complex and somewhat error prone task. For most projects, the overhead in creating a suite of components is simply not feasible. Nevertheless it is promising, that JSF 2.2 finally allows custom attributes and therefore enables ARIA compliant applications. It remains to be seen how fast the big component suites adapt to the new possibilities.

JavaEE and a11y. Not quite there yet?

Does that mean it is not possible to create modern, highly accessible web applications with JavaEE as long as there is no JSF component suite with a clear focus on a11y?

Not at all. But we have to accept that from a technological perspective, JSF is currently not a great choice for creating accessible web applications. Luckily, JavaEE provides alternatives to JSF.

In the view of the author, currently, the best way to achieve truly accessible, modern web applications within a JavaEE environment is to use client-side frontend technologies, that give much more fine grained control over the generated HTML.

One such approach would be to use the JAX-RS API from JavaEE to create a RESTful JSON API and build the actual frontend with a client side MVC framework like angular.js. While angular.js itself does not provide UI widgets, it enables effortless integration of existing UI widget libraries that have decent ARIA support. And via the directives feature of angular it is very easy to create reusable widgets that have a11y in mind from the beginning. This combination gives you the full power of JavaEE on the server and a high level of fine grained control over the generated markup in the browser, enabling the creation of truly accessible, yet highly interactive web applications.

If you have any feedback or questions regarding accessible web applications, JavaEE or angular.js, feel free to contact us!

One thought on “The state of web accessibility in the JavaEE world”

Comments are closed.