Sarah Jane Hong

Home / portfolio / Orion


Web accessibility evaluation for an open source project

Orion is an open source platform for cloud-based development; a project under the Eclipse Foundation.

I assessed the platform's web accessibility through a pilot iteration of the Facebook Open Academy program in conjunction with the Eclipse Foundation.


Web accessibility is something that is easily overlooked in web development, and I myself had previously no experience in this area. As such, my first step was to understand how my target audience interacted on their desktop computers / laptops with assisted devices. I had to familiarize myself with a screen reader, specifically VoiceOver, the built-in version for OS X. I found it very unnatural at first, as I was tempted to use my mouse to navigate instead of listening to an automated voice and maneuvering with hot keys.

Following that, I ran an initial accessibility assessment of the current platform with VoiceOver with a simple list of common tasks I curated. These included, but are not limited to, navigating through the various tabs (the structure of the website), creating a project, checking out a repository, seeing commit logs, and filling out forms.

Goals and Tasks

After the initial assessment, I made a list of improvements to be made based on errors found and unintuitive actions/responses. A sample is found below.

Web Accessibility Assessment

  • Missing WAI-ARIA for entry fields in form.
  • Screen reader does not annouce that user is on Orion home page, immediately asks "Have an account?" with no context.
  • Warnings and errors on sign-up/login page are not detected.
  • Screen reader does not detect "Forgot Password?" link.
  • Actual action does not correspond with existing alt-text; confusing.
  • Alt-text not present for images.
  • Links that leave Orion domain should communicate that to user.

While some of these errors can be easily detected by viewing the screen, it is not safe to assume that all users will be able to. Some users who require a screen reader may be legally blind and thus the responses (or lack thereof) associated with each action may not be as obvious.

My goal was to improve upon the accessibility of the platform for users that required use of screen reader. A list of the specific goals can be read below.


  • To allow for greater logical structure when the user navigates around the website.
  • To increase awareness of the system's status (detection of errors, alerts/warnings, confirmations).
  • To enable keyboard interaction for all controls.
  • To make visual focus evident when tabbing around elements on website.


In order to accomplish the goals set out, I need to tailor the JavaScript so as to provide ARIA state info where needed and to add semantically appropriate HTML elements where possible. Below are some examples of this process.

1. Increasing Semantics

WAI-ARIA is used to enrich accessibility on the internet. This was lacking in some of the form fields. In this specific case, it was missing for the username and password fields of the form. By adding aria-required and aria-invalid, these attributes allow the screen reader, and by extension the user, to have more semantic context. A snippet of the code is displayed below for illustration.

<input type="text" name="login" id="login" placeholder="username" title="Username" autocomplete="on" autofocus="autofocus" spellcheck="false" aria-required="true" aria-invalid="true"/>

Using WAVE to test the changes, it confirmed that WAI-ARIA was now present for these form fields.

2. Improving Logical Structure

Sometimes forms can be poorly marked-up or organized. When tabbing through sections of the website, users that do not require screen readers are able to visually make the link between form labels and their corresponding values. For example, the label "Name" beside a text entry field is asking the user to input their name. However, for users that require a screen reader, this link is not obvious or even seen in some cases. The screen reader will simply ask for the user to input text into the field, but the user will have little or no context as to what is required.

There needs to be a way to link the label with its value in the HTML document, so that the screen reader can detect this and relay the information back to the user. This can be done by adding for="ID", where ID is the id of the associated element that the label is for.

<tr> <td> <label for="site-editor_name"></label> </td> <td> <input id="site-editor_name" value="orion" pattern="\s*\S+\s*" required="required"></input> </td> </tr>

Testing the changes with WAVE shows that this edit correctly makes the link between the labels and the form fields.


3. Making The System's Status Evident

When an error occurs, a user is notified with some associated text that is visible on the screen. However, this warning was not detected by the screen reader in some cases. This can cause for confusing interactions for a user that cannot view the screen, and thereby is unaware of the warning. For example, if the user entered the wrong password,the message "Invalid user or password" is displayed. If this change in the DOM is not detected by the screen reader, the user may be confused as to why they have not made it pass the login page.

In Orion, warnings are displayed dynamically. In order for the screen reader to capture this change in the DOM, I added the aria-live and tabindex attributes to the div.

<div id="errorMessage" aria-live="assertive" tabindex="0"> Invalid user or password </div>

In the code above, tabindex=”0″ allows the div to receive focus from the screen reader. Also, when the text inside the div is changed, aria-live=”assertive” lets the screen reader become aware of the text change and will read it aloud.

Testing the changes with WAVE shows that the warning message is now accessible.


Evalution of the changes were done in two parts. An intial screening was done with WAVE to see if the pages of the website met web accessibility standards. Secondly, I would personally run through the changes using VoiceOver and only a keyboard (no mouse-computer interaction) to see if all elements were accessible by keyboard and to see if the appropriate responses occured given an associated action. Due to time and resource constraints, I was unable to evaluate the changes with a sample of users from the target audience. However, my changes were reviewed by web accessibility experts who were working on the Orion project.

Future Improvements

The above was done with WAVE toolbar for Firefox, and tested with VoiceOver on a OS X. There is still work to be done with cross-browser compatibility issues and testing the effects with various screen readers.

Notes: This is done in accordance with UCOSP.