Last week, I published an HTML 5 contact form WordPress plugin that used the HTML
autofocus attribute to put the focus into the first form field.
Marc Aplet commented about the accessibility of doing that, for which I am very grateful as it made me think more deeply about it. Thanks to those on twitter who helped me further with my thinking.
I believe that autofocussing into a form is a usability win for most people if the purpose of the page is that form—for example, the Google hompage. So, I wouldn’t autofocus into the search box or comment field on this page because the primary purpose of this page is discussing this article which requires prior reading. Most people are lurkers, not commenters, so it’s against usability to autofocus into the comment form. But a contact form is the primary purpose of a contact page, and it saves users a keystroke to put the caret into the first field—particularly usable for mobile phone users.
However, screenreader users find themselves dumped in the middle of a form, potentially without context (athough it’s always possible to tell the screenreader to repeat the
title of the page, and we all give our pages useful titles, don’t we?).
Moreover, many forms have explanatory or introductory information preceeding them. My contact form does, although that’s somewhat flippant. A better example is Salford University’s Online Staff Directory Quick Search Page. The explanatory information is correctly outside the
form element, as JAWS and (I think) Windows-Eye ignore any text that’s not inside
label elements when they’re in Forms mode.
What we need, then, is a way to associate some explanatory descriptive text that’s outside the form with the form itself (in a similar way that
input are explicitly associated). Then a screenreader user could be alerted to the presence of this descriptive material by this programmatic association, and optionally choose to have it read out to them.
aria-describedby. The ARIA spec says
An accessible description may be computed by concatenating the text equivalents for nodes pointed to by an aria-describedby attribute on the current node.
So, I recoded the plugin (download it; it’s at your own risk etc) so that the descriptive matter is enclosed in a
div id="form-description". The
form element has the attribute
aria-describedby="form-description" (because the description is for the whole form).
I don’t know if any screenreaders offer a keystroke to query this information yet (it’s over a year since I’ve been near a screenreader), but as the vendors have worked closely with the WAI-ARIA authors I imagine it won’t be long.
I also amended the plugin so that it has a belt-and-braces approach to the form fields that are required. In addition to the HTML 5
required attribute, I’ve added
aria-required="true" as this is probably closer to implementation by screenreader vendors.
Because there are already two programmatic methods of indicating that a field is required, I’ve removed the traditional method of including an asterisk in the markup, as it’s possible to style the form fields with CSS—I’ve used a thick black border. (I tried to use attribute selectors to generate the string “required” immediately after the form field, but that gets surrounded by the field border rather than living outside it. The result is minging, even by this site’s low design standards.)