Contacting the White House with a Screen Reader

As excited as I am to see the changing of the guard in the White House, I can't resist pointing out a few significant accessibility problems with the newly unveiled whitehouse.gov website.

The good news: There's a changing of the guard! So I'm hopeful and optimistic that these problems will be fixed. This isn't just blind optimism either. Videos on change.gov were initially not captioned, but the accessibility community raised the transition team's awareness of this issue, and the problem was promptly fixed.

The biggest accessibility problems I see are related to color contrast, particularly in the banner, and keyboard accessibility overall. There's no visible focus other than what's provided by the browser and in most browsers that's so minimal that it's of little value. Mouse users, note how easy it is to select an item from the navigation menu, just by hovering and clicking. Now try accessing these same features without a mouse, just by using the Tab and Enter keys. It's possible, but difficult and not at all efficient. There are lots of mouseless people who are effected by this: People with physical disabilities, people using a stylus, people using speech recognition, etc.

In my opinion, the biggest problem is the Contact Us form, and I'll dwell on that a bit here because it provides a perfect example of why it's important to use accessible markup on forms. It's a pretty straightforward form, with fields for first name, last name, email, address, city, state, zip+4, phone, subject, and message:

Screen shot of the White House Contact Us form

The problem with this form is that the labels appear beneath the fields they represent. This in itself wouldn't be a problem if they had used accessible markup. When a screen reader encounters a form field, it first looks to see if there is an HTML <label> element associated with that form field. If there isn't, the screen reader has to guess which label accompanies the field. For sighted users, it's clear that the text positioned immediately beneath a field is the label for that field, but if you strip all positioning away and read the form linearly, that's not so obvious. Most forms have labels before form fields, so that's what screen readers automatically assume. In this case, that erroneous assumption results in the screen reader reading the form incorrectly, which may in turn result in blind citizens either filling the form out incorrectly, or getting confused and not filling it out at all. Here's a summary of what happens when JAWS 9 reads this form (note that the word "Edit" is how JAWS identifies a form field):

  • For both First and Last Name fields, JAWS reads "Only these fields are required. All other fields are optional Edit"
  • For the E-Mail field, JAWS reads "Last Name Edit"
  • For the City field, JAWS reads "Address Edit"
  • For the first portion of the Zip+4 field, JAWS reads "State Edit"
  • For the second portion of the Zip+4 field, JAWS reads "Dash Edit"
  • No labels are read for any of the fields in the right column. JAWS just says either "Edit" or "Combo Box". Most screen reader users can probably figure out the State field since the combo box contains choices. The other fields require significantly more guesswork.
  • For the Message field, JAWS reads "Subject Edit"

The solution is simple, and again, I suspect it will be implemented soon and this blog post will be obsolete. Here's the current HTML code that's used to implement the First Name field, and the label associated with it. Note that I've stripped out most of the surrounding table tags, as they're not relevant to the point I'm making:

<input type="text" style="width: 192px;" id="ctl05_txtFirstName" maxlength="50" name="ctl05$txtFirstName"/>

<td class="fieldreq" id="ctl05_labeltxtFirstName">First Name</td>

To fix this, simply add a label element informing screen readers that "Last Name" is a label, associated with the form field having id="ctl05_txtFirstName", like this:

<input type="text" style="width: 192px;" id="ctl05_txtFirstName" maxlength="50" name="ctl05$txtFirstName"/>

<td class="fieldreq" id="ctl05_labeltxtFirstName"><label for="ctl05_txtFirstName">First Name</label></td>

Anyone else have feedback (negative or positive) for the Obama web team?

4 comments on “Contacting the White House with a Screen Reader

  1. Hi Terrill,

    Here it is 100 days later (almost) - and the problems of the contact form continue. As you pointed out here and as did Susan Gerhart, there was no labeling in the start.

    Rather than take your recommendation to use the label element, they used title attributes which is OK in my view. But they did no labels on the zip code fields, and no reporting of whether fields were "required" or not.

    By the way they handle "required" with a background image so the label element won't work for that.

    I wrote about in-page navigation @ http://jimthatcher.com/whitehouse.htm and have a more detailed report about basic problems which I would be glad to share.

    The contact form should be recoded with a foreground image for required (alt="required") and proper use of label tags. (They would still need a couple of title attributes (Zip+4 for example).

    It is depressing that this hasn't been fixed in the first 100 days.

  2. It's been a while since I've checked this, but I did so today and I see that the accessibility of the Contact the Whitehouse form has been partially fixed. The labels now are marked up appropriately with label elements. However, required fields are still identified with a CSS background image, so a screen reader user (and anyone else with CSS turned off) won't know which fields are required. For the record, the required fields currently are: First name, last name, email, zip code, subject, and message.

    There's also a required CAPTCHA, which I don't recall being there before. They are using reCaptcha, which includes an audio alternative, but it's very challenging to get that audio CAPTCHA right, and neither the audio nor visual CAPTCHA works for folks who are deaf/blind and is likely to be problematic for anyone who has difficulties processing a jumbled message, whether written or audible.

    Despite these problems though, it's much improved over the original version.