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.)

15 Responses to “ The accessibility of HTML 5 autofocus ”

Comment by Andy Mabbett

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? ;-)

Comment by bruce

Thing is, there isn’t a caption element for forms in html4 or 5. Although maybe legend as a child of the form element could describe the whole form – eg when not inside a fieldset.

Even if the HTML 5 crew could be persuaded to allow a caption/ summary/ legend on a form element, it wouldn’t repair HTML 4 sites, while “repairing” HTML 4 is exactly why ARIA exists – and will continue to work with HTML 5.

I don’t have a particular problem with the fact that a description isn’t inside the form; for example, we have label and input which can be on the same level rather than nested. Conceptually similar, we don’t put a heading inside a list (there is no “lh” element for “list heading”).

Comment by Andy Mabbett

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.

Comment by Matt Machell

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.

Comment by adrian_h

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.

Comment by Stomme poes

Form information/description/instructions belong outside (preferably before) the form. This keeps the legend short (a must), and prevents long paragraphs of text inside something the user expects to just fill in. I have forms with long bouts of “help text” and frankly it’s annoying and slows users down (too bad I can’t remove it). I include stuff like “Required fields marked by (something) also before and outside the form.

Using CSS to style required fields means anyone not getting the styles miss that important information. And any readers who understand the ARIA required role, it should just override the HTML5 required attribute. Does that mean anything for browsers (if they do validation and check for required fields filled while the user is making use of ARIA roles?)?

Autofocussing would be better a setting users can choose themselves for the sites they visit most: say, Google search or a web-based mail site or someplace they always log into first… rather than something set by authors. I don’t like the idea of losing my control of my cursor or my focus. If I’m on a new-to-me page I may not realise where the hell I am right away! Keeping Javascript off helped this, but won’t help when it’s built into the markup. Like bookmarks, I better like the idea of users setting this attribute instead. We know which pages we want to skip to a form field and which ones we don’t.

Comment by Kevin Chao

Currently, Leve a Reply is a H3, but not an ARIA landmark. Is this expected? Is it necessary to have (required) next to name field, considering that with Firefox and NVDA, arrowing or read current line on edit field reports: “edit, invalid entry, required, has autocomplete, blank”. I’m in favor of cutting out redundacy and any unneeded level of verbosity. With focus in name field, TAB goes to privacy policy link, another TAB will go to email field, “privacy policy” seems to be part of field label, making it overly verbose and messy. In addition, Email field has same issue as name field, where required is spoken twice, once in edit box label and part of edit box. It’s only needed once, which is in edit box. With focus in website, TAB to comment field, which is read as “edit, invalid entry, multiline, required”. Edit box label should be part of edit box like it was in all previous fields, including website. Report current control, NVDA+TAB does not report edit box label. Only thing that is reported differently with NVDA+TAB over pressing TAB to go to edit box is “focused is in between “edit” and “invalid entry”. While HTML5 and ARIA are great, it’s nearly impossible to find examples to test that do not have bugs in the code itself.

Comment by Stomme poes

Kevin:
>>Currently, Leve a Reply is a H3, but not an ARIA landmark.

What landmark would it be? I can’t think of one that would fit, and not sure if a comment form should need a landmark.

>>Is it necessary to have (required) next to name field, considering that with Firefox and NVDA…

Labels should state whether something is required, yes. Not everyone has a screen reader to tell them there’s a “required” attribute on an input. Labels are also used by sighted people using graphical browsers.

If all AT universally announced that a field was required, then authors could maybe decide to leave the attribute off the inputs and leave it in the labels, who should be accessible to *everyone*.

Also, announcing to a user the moment they touch an input that it’s invalid is stupid and annoying. It’s like telling someone they fail before they’ve even tried, or pointing out the obvious (“the field is currently empty”). It should not be considered invalid until the user has left.

Autocomplete is going to be a problem if all HTML5-parsing browsers make it default. Great, every single e-commerce form now needs to add autocomplete=”off” to everything just to stop the idiocy that is “automatically adding in credit card numbers” and other junk public computers with caching-on browsers would store. Oh the joy.

Oh and I’m still waiting for my promised ability to turn autocomplete and autofocus off on my end. I can turn Javascript off, but haven’t found a way to turn off autofocus or autocomplete. Which one is more accessible? The one *I* can control, and I don’t mean “control by spending 15 minutes crawling through some config file that the browser decides to overwrite next time I start up anyway” either.

Old article, things have changed, maybe it’s time for an update?