The consensus is that it’s safe now to use the new HTML5 input types and attributes and that they offer some clear usability benefits like improved UI and baked-in validation. Most modern browsers support them (see Quirksmode, User Agent Man and wufoo), and those that don’t, fall back to the text type input. But how usable and accessible are the new inputs for keyboard only and screenreader users? In part 1 of this post I do some testing. I would like to be able to say that I tested a comprehensive range of browsers and screenreaders. I didn’t. Instead I looked briefly at NVDA and VoiceOver on four browsers to see what issues arose for developers. In part 2, I look at solutions to some of the issues identified.
- Mac OSX: Safari 5, Firefox 9, Opera 11, and Chrome 16; screenreader – VoiceOver with Safari.
- Windows XP (run via VMWare on Mac): Firefox 9, Opera 11, and Chrome 15; screenreader – NVDA with Firefox.
HTML5 inputs tested:
time, datetime, date, week, month, email, url, number, color, range and tel.
Firefox renders all the inputs as ‘text’ type in appearance. This is true for Mac and Windows versions. The ‘required’ attribute is supported and the submission of a non valid form triggers baked-in validation. All invalid inputs are outlined in red. Note that setting the box-shadow or -moz-box-shadow properties in this browser suppresses this red outline. An error is reported via an alert positioned just below the invalid input. Focus is placed in the input.
In Firefox only the ‘email’ and ‘url’ type inputs require specific data types or formats. The error messages triggered are:
- for an empty input, ‘Please fill out this field’.
- for an invalid email, ‘Please enter an email address’.
- for an invalid URL, ‘Please enter a URL’. It is worth noting that to be valid, a URL has to include the protocol (ie http). So some guidance to the user is necessary here.
NVDA handling of the ‘required’ attribute is effective if a little quirky. When an empty input with the required attribute receives focus the screenreader announces that it is required, but also that it is ‘invalid’, even before the form is submitted. The full announcement is, the label followed by, ‘edit invalid entry required autocomplete blank’.
‘Required’ is announced only once even when both required and aria-required attributes are used as in this code example:
<p><label for="tel">Tel: </label> <input type="tel" id="tel" required aria-required="true" /> </p>
That’s good. However if, as is often recommended, a ‘required’ advisory is included somewhere in the label (to cater for non ARIA browser and screenreader combinations), then depending on the method used ‘required’ might get announced more than once. I outline some more or less successful solutions to this in part 2 of this post. Of course hearing twice that a field is required is preferable to not hearing it at all.
When an invalid form is submitted NVDA announces the resulting alert and error message.
In Chrome the new input types behave and appear much as they do in Firefox 8. The exceptions are the ‘number’ and ‘range’ type inputs.
The ‘number’ input resembles a text input with the addition of up and down arrow controls inside the input and aligned right. Data can be entered by typing, via mouse and by using keyboard up and down arrows. The ‘step’ attribute is supported and when the up and down arrows are activated either via keyboard or mouse, the input’s value is incremented or decremented by the step value. If the ‘step’ attribute is set this affects the validation. So if the step is set at ’3′ and a user types a number that is not a multiple of 3 then on submission the error alert is ‘Invalid value’.
The ‘range’ type input is a slider with no numeric information exposed.
Neither screenreader tested performed well with Chrome 16. I think it’s unlikely that many users would work with this browser and either NVDA or VoiceOver.
Safari 5 on Mac OSX
Safari generates distinct UI for the time, date, week, month, number and range inputs. They are keyboard accessible and, apart from the range type, allow text entry too.
The time, date, week, month, and number types are rendered in appearance as text boxes with up and down arrow controls to the right hand side, just outside the text box. The date, week, month, and number types support the step attribute and increment or decrement by the step value when these arrow controls are used either via keyboard or mouse. If there is no step value, then the arrows increment or decrement default current date, week, and month values and a zero default number value by one. The required attribute is recognised by VoiceOver, but Safari doesn’t do any baked-in validation. Users can enter anything directly into the text box part of the new inputs unconstrained either by the step values, or by the required attribute. However when an input has a required attribute, in the desktop version of Safari at least, the jQuery validate plugin (I tested version 1.8) does not work.
VoiceOver announces that all inputs, apart from the range type, are text inputs. So when a user tabs to an input with the required attribute she will hear the label then, ‘required edit text’. If, after a short pause, nothing is entered into the input, VoiceOver announces, ‘You are currently in a text field inside of a HTML content. To enter text in this field, type’. Data entered into the time, date, week, month, and number type inputs via the arrow controls eith via mouse or keyboard is rarely announced. The only way I could consistently access values entered or updated via the arrow controls was to use VoiceOver commands to navigate back and forth from the input label to the input. When the input was re-entered VoiceOver would usually give misleading information about the cursor position. So Apple seems to have decided that the most usable option for people using VoiceOver is that the new inputs be treated like text inputs. When data is typed in VoiceOver announces it very clearly. It was extremely good with the range input providing more feedback than a sighted user would receive. VoiceOver also announces placeholder values.
Opera has distinct UI for the time, date, week, month, number, color and range input types.
The time input type looks like a text input with the addition of up and down arrow controls to the right hand side. The input contains a colon which hints at the appropriate format.
Only numbers can be typed into this input, other characters are not accepted. A press on the keyboard down arrow places the default time – midnight, 00:00, in the input. Additional presses decrement the value. The up arrow increments it. The step attribute is supported and if set, even to ’1′, changes the input so that two colons appear, and a press on the keyboard down arrow generates a value in the format 00:00:00. The required attribute is supported. If the input is empty, or data typed in doesn’t match the format generated by the presence or absence of the step attribute, or the data is invalid, then focus is placed in the input, the entered data is removed and an alert, ‘This is a required field’ is triggered.
The date, week and month type inputs resemble select controls.
But they behave differently. And mouse users and keyboard users get different experiences. When keyboard users focus on these inputs for the first time, when no values are entered, and enter data via the up, down, left and right arrows they enter a value one above or below the current date, week, or month. The down arrow on these inputs increments the values, whilst the up arrow decrements them. This behaviour is counter-intuitive, and inconsistent with the time input type which works in the opposite way.
Mouse clicks on these inputs trigger date-pickers. I couldn’t find a way to trigger them via the keyboard. Mouse users can click on a ‘Today’ button which will insert the current value.
The step attribute is supported, but whilst it constrains the values in the date-pickers, it has no effect for keyboard users entering a value via the keyboard up and down arrows.
For keyboard users, values are incremented by one, irrespective of what the step value might be. But a step value of 3 for example on the date type input, means that only multiples of 3 are selectable on the date-pickers.
The required attribute is supported. If the step attribute is used, this affects the validation. So with a step value of ’3′, a date value (entered via the keyboard) which is not a multiple of 3, triggers the alert, ‘The date 2012-01-31 is not allowed for this form. Only certain dates are allowed for this field’.
The email and url input types support the required attribute. A valid URL requies a protocol
The number input can be typed into. Values can be entered by clicking on the arrows control to the right of the input, or via keyboard up and down arrows. Here, the arrows increment or decrement the data value in the more usual way – up increases it down, decreases it. Step, max, and min attributes are supported. The error message triggered by typing in non-numeric values is a not terribly helpful, ‘This is a required field’. A number typed in, which is not a multiple of the step value, triggers ‘The number ‘, n ‘ is not allowed for this form. Only certain numbers are allowed for this field’.
A mouse click on a color type input, or pressing return when it is focused, generates a color palette. The palette is largely keyboard navigable, apart from an ‘Other’ button, which I could access only via the mouse. A click on the ‘Other’ button triggers on a Mac, the OS’s native color picker. It is not possible to type into a color input type. There appears to be no baked-in validation for the color input type.
Neither VoiceOver or NVDA worked effectively with Opera and it is highly unlikely that these combinations would be used in practice.
- There are some usability issues with Opera date, week, and month inputs which behave counter intuitively and, when compared with similar Opera controls, inconsistently. This affects mouse and keyboard users. The datepicker pop-ups are mostly keyboard accessible once generated with a mouse click! But they can’t be triggered by the keyboard unlike, say, the jQuery Datepicker widget which pops up when an input is focused via mouse or keyboard. There are some accessible widgets in development like Dijit datepicker and extjs datepicker
- On long forms with a lot of required fields, baked-in validation via alerts might not be the most accessible way to handle and report errors.
- The browsers which worked best with screenreaders, Safari and Firefox, provided the least support for the HTML5 inputs. Opera provides the most support but is probably the least accessible as far as assistive technology is concerned.
- The range input type needs additional code to be usable and accessible in all browsers.
Part 2 will follow soon.