A more accessible checkbox
At South by Southwest in 2008, during a visit to the Knowbility.org booth, we got a demo of the JAWS screen-reader software using parts of our own PatientsLikeMe website. JAWS, along with NVDA and VoiceOver are some of the better known tools available for users with low-vision or visual-impairment — had we done a good enough job for an actual user to navigate our site using this assistive technology? This actual user, Fred Hunt, went through our homepage, our sign-up page, and our login page. What would he say? Fred’s verdict: pretty good marks overall, with one caveat: a deficiency in our implementation of checkboxes.
Take, for example, The PatientsLikeMe login form:
The screen-reader reads the form elements in DOM order, so for the first field in the form, Username or Email, the reader would say something like:
“username or email, edit text“
Navigating further through the form, the screen-reader would then say:
“password, secure edit text”
Still makes sense. Further still through the form:
“checkbox unchecked, remember me on this computer“
Hold-up. That one didn’t make as much sense.
For this checkbox we have the swapping of the order of the control (a checkbox that is unchecked) and the question asked by the form (“do you want your username to be remembered on this computer?“) — a departure from the pattern as read in other form controls by assistive software.
This reversal of order might seem like a small difference, but it was enough for Fred to mention it. Since we operate a patient-focused website, it is very important to us that we provide the most accessible user experience for every user, regardless of ability. As such, Fred’s critique stung.
It’s obvious once you think about it: reading the associated text of the checkbox before the form control provides better context. What follows is how we got the screen-reader to say “remember me on this computer, checkbox unchecked“. Hopefully, this provides an improved user experience for users of such assistive technology.
Less talk, more markup
A common pattern seen in form inputs like radio buttons and checkboxes is a corresponding label tag with a matching for attribute with the input ID.
The structural markup for these controls can be seen in a couple of ways.
e.g., input, then label as adjacent sibling. A staple of user interface design.
<input id="remember-me" type="checkbox" /> <label>Remember me</label>
e.g., label as parent of input with label text following input.
<label> <input id="remember-me" type="checkbox" /> Remember me </label>
Makes you wonder why this differs from the standard layout for controls like text boxes, where the label always precedes the input? Aesthetics would be my guess*. With an array of radio controls of varying text length, the jaggedness would prevent the inputs from lining up were they at the end of the labels.
* Why this is a guess: Looking through the Apple Human Interface Guidelines and Windows User Experience Interaction Guidelines did not yield a single mention of the order of input and label for a checkbox.Unfortunately, neither of the above approaches do anything to address the reversed order of label and input. So, we did it like this:
e.g., label as parent of input with label text preceding input.
<label for="remember-me"> Remember me <input id="remember-me" type="checkbox" /> </label>
This technique requires some CSS intervention of the absolutely positioned kind to get it to look “normal”. Let’s take our approach of choice and add a classname of “accessible”.
<label class="accessible" for="remember-me"> Remember me <input id="remember-me" type="checkbox" /> </label>
Now with the DOM structure in a good place for screen-readers, let’s fix up the visual presentation with CSS to match our expectations for how checkboxes and labels look in our web form.
label.accessible {
position: relative;
padding-left: 22px;
}
label.accessible input {
position: absolute;
left: 0;
top: -3px;
}
Quite simply, we’re padding the left side of the label and positioning the input in that gap. This technique, of course, also applies to radio buttons. With very little effort on our part, we’ve made things a little easier for our screen-reader audience.