upa - home page JUS - Journal of usability studies
An international peer-reviewed journal

Investigating the Accessibility and Usability of Job Application Web Sites for Blind Users

Jonathan Lazar, Abiodun Olalere, and Brian Wentz

Journal of Usability Studies, Volume 7, Issue 2, February 2012, pp. 68 - 87

Article Contents

Action Items to Improve the Usability of Application Web Sites for Blind Participants

From the usability evaluation by the 16 blind participants, patterns emerged of common problems in the online employment applications. Based on the usability testing, the feedback by participants, and the categories of problems that participants faced, we created a list of five suggested action items to improve usability specifically for blind users on employment Web sites. In the following sections, we provide five action items that would both improve usability for blind users as well as other user populations. All of these items are actionable, with minor technical changes that would lead to great improvement for blind users.

Design introduction pages that are accessible

A number of sites had introduction pages as the entrance to the job application process that were inaccessible to screen-reader users and had no textual equivalents. For instance, a few Web sites had a flash-based job search page, without any textual equivalents. There was no way to search for a job unless you could see the screen and could use a mouse pointer. For example, a Web site required users to click on a map to choose which region/country you wanted to apply for a job on, and then if you chose the US, you were then required to choose a state (see Figure 3). There were no textual equivalents for choosing the job region or state, although this would be easy to design accessibly, using a drop-down menu list. These features may seem visually appealing, and they could stay on the Web site, however, textual equivalents need to be added so that users who cannot use pointing devices could also access the information. The key problem with these features is that they are at the entry point of the entire employment process, so that if you cannot utilize these features, you cannot go any further in the application process. These entry points essentially prevent blind users from applying for jobs at these companies.

Figure 3

Figure 3. Web site where the participants must click on a map, and there is no textual equivalent for screen-reader users or those unable to use a mouse pointer

Provide accessible feedback on data entry problems

All online employment application processes required users to fill out online forms, and this was expected. However, there were instances on multiple sites where the feedback on data entry forms was inaccessibly provided when data fields were filled out incorrectly, as recorded in Table 1. Inaccessible methods for providing feedback included highlighting the incorrectly filled-out field in red or providing feedback only in an inaccessible mouse-over. On one employment site (see Figure 4), the participants were prompted in a dialog box that they should hover over the problematic data entry fields with their mouse to learn what the problem is. A similar problem was noted on other Web sites, (e.g., see Figure 5) where the participants were given information about the data entry problem only through the use of a mouse-over on fields that were marked with a red exclamation point.

Figure 4

Figure 4. Feedback on a Web site about an incorrectly filled-out data entry form was provided in an inaccessible manner. The dialog box notes that, to find out what the error was, the participant should hover over the field with their mouse.

Figure 5

Figure 5. Feedback on the data entry from a Web site was provided only by doing a mouse-over where a red exclamation point was indicated as a field with incorrect data entry.

Provide accessible feedback regarding participant progress through the application

Typically, there are a number of steps that an applicant must complete before they can formally submit an application. Unlike e-commerce sites, where there is a standard and simple process (place items in the shopping cart, and then go to the checkout), submitting a job application is a much longer process, requiring as many as 10 different steps, and the actual steps vary widely from site to site. Unfortunately, the status feedback on participant progress through the sites we tested tended to be inaccessible, that is, the feedback was provided only graphically, through the use of shading, shapes, or colors, rather than a simple textual declaration saying “you have completed step 3 (previous employment) out of 9 steps” or something similar. Because the steps varied so widely from site to site, it was unrealistic to expect participants to know how many steps were involved or which steps were involved. Figure 6 displays progress indicators from three different sites, which show the various steps in the job application process, but show the data in an inaccessible manner.


Figure 6

Figure 6. Progress indicators from different Web sites, which show the progress in an inaccessible manner that is unusable to screen-reader users

Use links that are unique and identifiable when listened to using a screen reader

A number of Web sites had link text that was listed as “click here” or “click here to read more.” When a screen reader user listens to these links using the JAWS links list feature, all of the links sound exactly alike and are identical and not individually identifiable. This is easy to fix, instead of having all links read “click here,” developers should designate the actual job titles as the links. On one of the Web sites, all of the job listings had links titled “more info,” and on another Web site, all of the job listings had links titled “click here to read more” (see Figure 7). The outcome of that design decision is presented in Figure 8, where the JAWS links list displays a list of links, and the participant therefore hears a list of links titled “click here to read more.”

Figure 7

Figure 7. A list of job links that all have the same text: “click here to read more” which would be meaningless to screen-reader users

Figure 8

Figure 8. The JAWS links list on a Web site job listing, where all jobs have the same link title, which was confusing and meaningless to screen-reader participants

Use appropriate markup for lists and groups of questions

Users of screen readers rely on the Web design code (such as HTML) to provide appropriate information about the structure of information presented on the screen. For instance, headers (such as H1, H2, H3) provide information about the meaningful headings on the Web page, which allow users to navigate through those headings. Rather than presenting content with the goal of how it will appear visually, it is important to provide content with the goal of coding to indicate meaning and structure. Figure 9 provides an example of a problem where the participants are not hearing the questions and the answers together, but are hearing all of the seven questions listed together, and then the answers are read together. Developers sometimes use tables for visual layout, and this can confuse screen-reader users who count on structured Web design code to understand the meaning and relationship between items on the Web page.

Figure 9

Figure 9. Example where participants were not hearing the questions and the answers read together, but were hearing all of the questions first, and then all of the answers.


Previous | Next