Developing Accessible Web Applications

Posted on

Accessible web applications provide means for people with disabilities to view, understand, and perform all the major tasks with the application. In short, applications that are equally usable for everyone. It is one of the important factors to a successful application especially for enterprise software.

WAI, stands for Web Accessibility Initiative, is a group of individuals and organizations dedicate to improve the web accessibility. ARIA stands for Accessible Rich Internet Applications. WAI-ARIA refers to the Accessible Rich Internet Applications specification and its latest version is WAI-ARIA 1.0 published in 2011.

HTML is not made for achieving accessibility with its limited variation of tags and HTML5 addresses this issue with the semantic tags. I have a blog post about HTML5 semantic structure. Here are a few other things you should make sure when developing an accessible application.

Keyboard Navigation
Users should be able to navigate through the web application and perform available tasks with keyboard. Tabbing is the common way to get to the element. Make sure the order of tabbing is correct visually and logically but not all the elements should be included in the tabbing sequence. Imagine that you need to tab through all the cells in a table before getting to the next page action element. The elements with action should have the tabindex as 0 or positive values while the others should be set to -1. Besides tabbing, arrows keys with combination of control or shift keys are also used in keyboard navigation but since it’s not standard, they should be documented so the user will know about them. Users should be able to tell the focused element with border.

Use of Color
Using high contrast colors is not just for the need of people with color-deficient vision, it makes it easier and more comfortable to read the content for everyone. Also, applications should not rely solely on color to convey important meaning. For example, an warning message should not be just displayed in red but also needs the term “warning”.

CSS Sprites
CSS sprites are background images so they won’t be shown on high contrast mode. If you haven’t checked out HCM, you can switch to it with shortcut shift + left Alt + PrtScr on Windows. Labels should be provided for the missing sprite images and they should perform the some action as the image.

Role and States
A Screen reader used to just read out all content on the page but it is now enhanced with the ability to response to the semantic web. Adding roles and states to the document so the screen reader can focus on only the important elements so it’s easier to understood by the listeners. For example, a node with role as presentation, an image node or table node, means it is just for page layout and does not have actions specified. A check box’s state can be set as “aria-checked” and it will be picked up by the screen reader.

More detailed advice with examples can be found on WAI-ARIA 1.0 Authoring Practices. One of the reasons that enterprise software favors Dojo Web Toolkit is that all the widgets in the library have been tested for Dojo accessibility requirements and it’s well documented in each widget. Dijit can detect the high contrast mode and apply the style with class “dijit_a11y” so you should utilize that class to add additional styling for your custom widgets in HCM.


Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>