The accessibility of HTML 5 autofocus
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.
Note that potential accessibility problems are not restricted to the HTML 5 use of autofocus; current JavaScript ways of doing it cause the same problems.
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 legend and 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 label and 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.
Enter 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.)
11 Responses to “ The accessibility of HTML 5 autofocus ”
My “caption” comment was light-hearted – I know some people don’t like captions on tables and thought you were one of them.
Forms aren’t my strong point, but I suppose what I was saying is that I think “the explanatory information is correctly outside the form element” is getting it wrong (semantically – not for the reason you describe). I’d expect to find it inside that element, and ATs to deal with that accordingly.
Imagine a situation where someone – for whatever reason – uses CSS or a Greasemonkey script to hide all forms; if that were me, I’d – logically – expect the description to be hidden too.
I’m with you on lists, though. I’ve always thought there should be an optional caption-like property for them.
P.S. Looking at the Salford Site (I wonder who made that..?), the description seems to be inside the form element.
On autofocusing, there are also usability issues to consider too, particularly if you autofocus on the first element of a form and it happens to be a select element. Then you get the fun thing of users arriving at a page and expecting to scroll the page with the mouse or keyboard and accidentally switching the select option instead but not noticing.
interesting that the newly fixed version has a different screenreader issue though in that my particular screenreader (JFW) recognises the form fields to be such in that it allows me to type in to them (the virtual cursor mode is disabled) but the screenreader doesn’t actually activate its “forms mode” EG the sound and splen “forms mode” alert aren’t given uless you use cursor keys to move away from and back to the field (tabbing doesn’t fix it), this is true for all fields – suspect it’s a JFW and ARIA suppport issue and actually although using jfw v10 I’m not using the latest build so just maybe… also note that your ‘content’ landmark seems to be end the end not the start of your content, EG before all the copywrite guff.
[...] Lawson hat in seinem Artikel The accessibility of HTML 5 autofocus bereits mit dem Attribut autofocus zu kämpfen. Mit diesem Attribut setzt man nach dem Laden der [...]
[...] and con’s of autofocus, however Bruce Lawson has already done a great job of explaining the issues around autofocus accessibility on his [...]
[...] that there are some accessibility concerns with autofocusing in general, and this won’t change those one way or the other, but in the [...]
[...] The accessibility of HTML 5 autofocus – Bruce Lawson [...]
I can see why you’ve chosen to do things the way that you have; but logically (and semantically) the descritption of a form surely belongs inside the form element?
“Caption” element, anyone?