Future Web Accessibility: New <input> Types in HTML5

This is the third 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 defines 13 new values for the type attribute of the HTML <input> element (search, tel, url, email, datetime, date, month, week, time, datetime-local, number, range, and color).

While it remains to be seen how each of the new input types will be rendered or handled by web browsers (see the next few sections for some likely possibilities), any special user interface or formatting applied will be entirely at the UI level. In other words, these are all just plain text fields underneath, and will be exposed to scripting and sent in GET and POST fields as such. In cases (such as the date and time types) where HTML5 dictates that the data be internally stored or represented in specific ways, it uses existing standard formats so that modifications to server-side code and client-side scripting (if necessary at all) will be minimal.

Since it has always been the (well obeyed) rule in HTML that an <input> element with an unrecognized type attribute should be considered to have type=”text”, user agents that don’t officially support these new input widgets will present them to users as standard text fields–which is what we usually use to get these types of data in web forms now. So, for the most part, this is a perfectly backwards-compatible change, and shouldn’t cause any problems (accessibility or otherwise) other than people with newer user agents possibly getting some cool new stuff that nobody had before.

As far as the platform accessibility APIs (through which web browsers communicate information about a web document to assistive technology) are concerned, the default behavior (calling everything a standard text field) shouldn’t cause any concerns unless web authors start using these extended input types as the sole and only way of informing a user what a particular form element is for (but that isn’t likely–the requirement that all form elements have labels isn’t going away). However, a higher level of accessibility could be achieved by mapping the new input types to different appropriate platform accessibility roles and states, which is currently being worked on by at least one major browser vendor. Newer version of screen readers and other AT might also include their own specific support for the extended input fields above and beyond what is presented in the default accessibility APIs, by directly querying information from the HTML DOM nodes. However, it’s still too early in both cases to see how all the details will be worked out and what the final situation will look like.

Search Input Type

The search input type represents a text field functioning as a search box. The HTML5 spec says,

“The difference between the Text state and the Search state is primarily stylistic: on platforms where search fields are distinguished from regular text fields, the Search state might result in an appearance consistent with the platform’s search fields rather than appearing like a regular text field.”

In most cases, this isn’t hugely exciting, though it will help your web apps look a little more like native apps on certain platforms. However, the possible usability and accessibility benefits are pretty big, as it would allow assistive technologies to provide a single command or keystroke that automatically focuses the search box on the current page, regardless of where it might be found in the content. Web browsers could even integrate the search field from the currently-viewed site into the browser’s own search widget, providing an easy way to access the search functionality on any site with an HTML5 search field from one consistent place.

Eventually, having <input type=”search”> could mean that search input fields no longer require an explicit label (something that would make a lot of web designers very happy), but not until browser and assistive technology support for HTML5 forms is complete.

Tel, URL, and Email Input Types

At the most basic level, the tel, url, and email input types (which represent telephone numbers, web URLs, and email addresses respectively) could merely be displayed a bit different by a web browser, or specially styled by authors in CSS. More complete support would include input validation, whereby user agents could require that text inputted into forms representing URLs and email addresses actually be a valid item of the given type. Additionally, there is potential for integration with other data sources, whereby (for example) user agents could provide a mechanism for obtaining email addresses or phone numbers from a browser or platform address book to populate tel and email input fields.

The accessibility of these browser-based interactions will be the responsibility of the browser vendors, which means that it will likely be pretty good. As before, accessibility could be increased if user agents expose the type data to AT and the AT passes it along to the user, but even without that there shouldn’t be any concern for decreased accessibility as long as all form elements continue to have appropriate labels defined.

Date and Time Input Types

Six of the new input types deal with dates and times in one form or another: datetime, date, month, week, time, and datetime-local. The meanings of these should all be clear from their names except for the last one, which represents a “local” datetime value without a particular time zone associated (all the other types are expected to include a time zone or be in GMT/UTC).

It can be expected that web browsers and other user agents will present these input fields as small inline or popup calendar/clock widgets to allow easy reading and setting of the appropriately-typed values, as is currently done by many websites today using scripting. As before, this can be expected to be a significant accessibility gain, since these browser-supplied widgets are likely to be very accessible, whereas the current generation of “homemade” and library-supplied widgets vary greatly in their accessibility. Additionally, the use of a single date selection interface across all websites will decrease the cognitive load of many web forms, since users won’t have to figure out a new widget every time they need to enter a date on a new site.

During the transition period, when some users have HTML5-capable web browsers and others do not, sites that currently use script-based calendar widgets will need to find some way of detecting the difference and only showing the custom boxes in the latter case. Websites that use multiple widgets to input a date (such as select boxes for month and day input, and a text field for the year) might wish to use scripting to show the single HTML5 control to users of newer browsers, and the old group of controls to everyone else. Other than that concern, usability and accessibility can only be increased by using HTML5 for datetime related form input, and web authors can start doing so right now.

Currently only newer versions of Opera officially support the date and time input types (and supply appropriate widgets), but other major browsers are expected to add them soon.

Numerical Input Types

The number and range input types represent the input of limited-range numerical values, and will most likely be presented by browsers as spinboxes (a little text box with up and down arrow buttons to the right of it) and slider controls respectively. Since these widgets correspond directly to native OS widgets and platform accessibility roles, the accessibility of both should be great. Converting text input fields to these numerical fields shouldn’t create any new accessibility problems, and have the dual gains of simplifying the instructions and cognitive load of forms that use them.

Color Input Type

The color input type might seem like a very odd thing to include in HTML, but with the increasing number of design and photo-editing apps on the web it will likely see its share of mainstream use. Jokes about blind people picking colors aside, we should get the same result as before: any browsers implementing this (none have yet, but it’s still early) will very likely do so in an accessible way, probably more so than most script-based color pickers in use today.

The Bottom Line

13 new input types in HTML5. All conveniently default to text older browsers. User agent support currently limited, but expected to increase. Potential for increased form accessibility in most cases, especially as browser-supplied data-selection widgets take the place of current script-based ones. Cognitive load of web forms potentially decreased due to consistency and self-validation of browser input widgets.

Further Reading

• States of the type attribute – HTML5 [whatwg.org]
• A Form of Madness – Dive Into HTML5 [diveintohtml5.org]
• HTML5 Input Types | 456 Berea Street [456bereastreet.com]