Accessible Forms for the Visually Impaired

If you're like most developers, your goal is to create the most confusing and frustrating experience for your user audience. While I hope you read that last line with a double-take, that's just the type of environment we produce for users with disabilities when we don't consider accessible design. Some claim it's too difficult or that the demand just isn't great enough to warrant the extra effort, however just a few simple concepts make all the difference. This is the first in a series of posts that will address basic and relatively easy to tackle barriers through the use of good HTML markup. Steps taken to ensure usability of web interfaces by people with disabilities also make the site better for all users (example: use of meaningful alt tags on images further optimizes your site for SEO in addition to ensuring images are accessible to screen reader software). This post focuses on the ability of people who are blind or visually impaired to navigate HTML forms.

Visual Disabilities

At first glance, the principles of accessible design can look daunting. When I first started researching accessibility, I have to admit that I felt the same way too. However I quickly realized that it wasn't the thought of me developing for accessibility that was daunting, it was the thought of using the site I produced without accessible design. When I experienced the web using just the keyboard and screen reader software used by the blind to interact with mainstream web browsers, it became very clear that my job as a developer is ultimately to ensure my site communicates effectively through the use of good markup, and doesn’t solely rely on one’s ability to click through with a mouse.

When we consider developing accessible web interfaces, it's important to understand the approaches blind and low vision users employ to interact with content. Screen reader users require a robust keyboard interface. In the case of forms, tab order must be logical as browsers allow use of Tab and shift+Tab to move forward and backward between form controls and other actionable elements (links for example). In other words, developing a form that can be used effectively from the keyboard is as critical as any interaction achieved through a mouse. Beyond keyboard access, required tasks to complete the form must be understood. One important difference between blind and sighted users is that blind users interact with a site in a linear fashon while most sighted people take in the page at a glance. With HTML forms, the screen reader user needs to clearly understand the desired information. Communicating effectively entails a wider range of concepts such as providing meaningful alternative text for images and not relying solely on color to convey your message, just to name a few. These concepts are all very important but to truly understand their impact, check out the following.

Example: Developing a Form

For this example, we're going to develop a simple form which will capture some data for a simple survey. Taking the perspective of a visually impaired user, we're going to be relying on a screen reader (JAWS on Windows XP Pro in this case) to guide us through the completion of the form. The source code for this form is shown in Listing 1.

Listing 1 - Default form source code
    
<form action="process.php" method="post">

    Name: <input type="text" name="name" value="" /><br/>
    
    E-mail Address: <input type="text" name="emailAddress" value="" /><br/>

    
    Sex:<br/>
    
    <input type="radio" name="sex" value="male" /> Male<br/>
    <input type="radio" name="sex" value="female" /> Female<br/>
    
    Favorite Languages:<br/>

    <input type="checkbox" name="favoriteLanguage" value="english" /> English<br/>
    <input type="checkbox" name="favoriteLanguage" value="spanish" /> Spanish<br/>
    <input type="checkbox" name="favoriteLanguage" value="javascript" /> JavaScript<br/>

    
    <input type="submit" value="Submit" />
    
</form>

This is pretty straightforward, everything looks valid and makes sense, right? Take a look at the video recording which demonstrates the use of this form with a screen reader.

This video simply walked through the form controls using the tab key. You can see that as each field is brought to focus, the screen reader does not offer anything of additional value. It simple says what type of control it is and goes about its business. Let's change this, it only takes a few extra tags.

The next form takes the information from Listing 1 and expands it to include other tags which are essential for effective use with a screen reader. This new code is shown in Listing 2.

Listing 2 - Accessible form source code
    
<form action="process.php" method="post">

    <label for="txtFld-name" accesskey="n">Name:</label>

    <input id="txtFld-name" type="text" name="name" value="" />
    <br/>
    
    <label for="txtFld-email" accesskey="e">E-mail Address:</label>
    <input id="txtFld-email" type="text" name="emailAddress" value="" />
    <br/>

    
    <fieldset>
        <legend accesskey="s">Sex</legend>
        <input id="rdo-sex-male"   type="radio" name="sex" value="male"   /> <label for="rdo-sex-male">Male</label><br/>
        <input id="rdo-sex-female" type="radio" name="sex" value="female" /> <label for="rdo-sex-female">Female</label>

    </fieldset>
    
    <fieldset>
        <legend accesskey="l">Favorite Languages</legend>
        <input id="cbx-lang-english" type="checkbox" name="favoriteLanguage" value="english" />
        <label for="cbx-lang-english">English</label>

        <br/>
        
        <input id="cbx-lang-spanish" type="checkbox" name="favoriteLanguage" value="spanish" />
        <label for="cbx-lang-spanish">Spanish</label>
        <br/>
        
        <input id="cbx-lang-javascript" type="checkbox" name="favoriteLanguage" value="javascript" />

        <label for="cbx-lang-javascript">JavaScript</label>
    </fieldset>
    
    <input type="submit" name="submit" value="Submit" />
    
</form>

The changes in Listing 2 are comprised of three major changes:

1. The new form incorporates label tags to describe what a form control is.
2. The accesskey attribute is used to create 'hot keys' for tasks. This is normally accomplished on Windows via the Alt key followed by the access key. I'm using a Mac and the key sequence is actually Ctrl followed by the access code.
3. fieldset and legend tags are used for grouping and relating like data.

Since this is a form, tabbing through the form is natural. However without the descriptions obtained via labels to form controls, the form loses all meaning and you lose touch with the user. Check out this video recording which alleviates the problems from the prior video.

As the form is being tabbed over, you can hear the useful descriptions provided by the label tag for the screen reader. At the end of the form, notice that I used a shortcut access key to bring focus back to the name field. Just a couple of added tags make all the difference.

Conclusion

I hope this demonstration sets you on the path to ensure your site is a welcome experience for all users, including people who are blind or visually impaired. For more information on the topics covered here, check out the following resources:

• AOL Developer Network - Accessibility Topic Center
• AOL AXS JavaScript Library
• Web Accessibility Initiative
• Web Accessibility Guidelines
• Accessible Rich Internet Applications Workgroup

This entry was written by Brice Mason.