Future Web Accessibility: HTML5 <input> Extensions

This is the fourth in a multipost series about the immediate and likely future of web accessibility. Each week or so I’ll discuss a different upcoming technology, tag, platform, or system from an accessibility perspective. Additions, corrections, or further thoughts are welcome in the comments.

Previous posts: HTML5 <video>, HTML5 Semantic Elements, New <input> Types in HTML5.

HTML5 <input> Extensions

In addition to the new <input> types (the subject of my previous post), HTML5 also adds four new attributes to all input elements that have a potential accessibility impact: autofocus, placeholder, required, and pattern. These all represent features and functions people have been using in web apps for years via scripting, but now allows them to be codified directly in HTML.

Browser Support

Browser support for these attributes is currently limited, though all browsers but Internet Explorer have some level of support for at least one of them (and can therefore be expected to implement most if not all of them eventually). In the mean time, existing script-based solutions can be used alongside the HTML5 attributes, with the addition of some browser capability detection so that the script doesn’t run if the browser supports the corresponding HTML5 function.

Accessibility

In general, we should be able to expect that the browser-supplied interfaces to this functionality will generally be more accessible than most (if not all) of the scripting-based solutions currently in use.

Form Autofocus

The autofocus attribute allows web authors to specify that a particular form element should receive input focus as soon as the containing page is loaded, so that you can start typing immediately without having to specifically click on or tab to that control. Script-based autofocusing is extremely common today, but suffers from a number of problems, including the fact that there is no way to turn it off. With the autofocus attribute, web browsers and other user agents can give people the ability to disable this feature, either on a specific website or for the entire web.

Note that there are some accessibility concerns with autofocusing in general, and this won’t change those one way or the other, but in the cases where doing so is generally a good thing, the HTML5 autofocus attribute provides an easier, simpler way of making it happen.

Placeholder Text

A very long time ago (at least in web terms), using placeholder text in HTML input fields was considered an accessibility requirement. These days, it’s mostly done with usability in mind, whereby an input field or textarea contains by default a short phrase or sentence describing the purpose of the field in more detail, the which text is automatically removed by scripting when the input field received focus (and sometimes, depending on the script used, restored when the field is blurred if the user didn’t type any text into it).

The HTML5 placeholder attribute allows web authors to specify placeholder text directly in the form’s markup and have the showing, hiding, and styling of it automatically handled by the user agent. This saves the author the trouble of having to use a script-based placeholder solution, and allows browser vendors to expose placeholder text to assistive technology in a consistent way. Additionally, widespread use of the placeholder attribute (in place of existing scripts) would ensure that placeholder text had a consistent look and behavior across the web, another small (but big in context) win for usability and cognitive load.

Assuming browsers that support the placeholder attribute do so in an accessible way, the only major accessibility concern is that some web authors could mistakenly feel that input elements with placeholder text can be left without explicit labels, something explicitly forbidden by the HTML5 spec. However, we haven’t seen much of this today (where placeholder text via scripting is already very common), so it isn’t likely to become a big issue.

Input Validation

The ability to express form element requiredness in markup has been possible with ARIA for some time now, and is even supported in most modern browsers and screen readers. This is much better than the old “append an asterisk to the label text” method (or even worse, the inaccessible “style the label bold or red” method) because it allows user agents and assistive technologies to explicit and unmistakably inform the user that a particular field is required. HTML5 goes a step further by adding a required attribute directly to the HTML syntax (no ARIA required), with the idea that browser will not only display required form elements differently (and pass this information on to AT), but automatically provide error messages (in an accessible way, we assume) when someone tries to submit a form without first filling in all the required values.

The HTML5 pattern attribute goes beyond mere requiredness by saying that a particular input field must have a value that matches a certain author-defined regular expression. This allows forms to accept tightly-formatted data (such as a credit card number) with automatic browser-supplied client-side validation and error reporting. Not only will this make for a consistent user experience across the web, it will speed up the process of creating an accessible web form, and should also make it way less annoying to do (writing client-side form validation code is one of the most boring, mundane, no-fun parts of the entire web application development process).

For the benefit of those filling out the form (including those doing so via assistive technology) the spec requires that, when using the pattern attribute, you also add a title attribute that explains the details of the pattern being matched against.

If the required and pattern attributes aren’t sufficient for a particular use case, HTML5 provides an interface for accessing the form validation functions via scripting. For example, the spec contains some demonstration code showing how the browser-based validation methods could be used to verify that a “password” field and a “repeat password” field have identical values.

As usual, this won’t be completely usable on the open web until all major browsers and assistive technologies support it completely, but if and when that happens, the accessibility gains will be significant. Instead of a dozen different conventions for indicating form validity and another dozen for displaying the related error messages, we could have a single browser-based system that would be reliable and consistent everywhere.

The Bottom Line

HTML5 input extensions provide markup-based solutions to common form functions currently implemented with scripting. Usually a good thing for accessibility, at least assuming browser and AT vendors take advantage of the potential.

Further Reading

• Autofocusing a form control – HTML5 [whatwg.org]
• The placeholder attribute – HTML5 [whatwg.org]
• The required attribute – HTML5 [whatwg.org]
• The pattern attribute – HTML5 [whatwg.org]
• A Form of Madness – Dive Into HTML5 [diveintohtml5.org]
• The accessibility of HTML 5 autofocus – Bruce Lawson [brucelawson.co.uk]