A repository of styled and “styled” form control patterns, and how they are announced by screen readers.
Form controls are necessary in many interfaces, but are often considered annoying, if not downright difficult, to style. Many of the markup patterns presented here can serve as a baseline for building more attractive form controls without having to exclude users who may rely on assistive technology to get things done.
I recently embarked on improving the client-side form validation for a client. There were about 400 lines of form validation code stuffed inside a 1000 line
form_helper.js. I looked for lightweight form validation scripts but after some hemming and hawing I decided to try my hand (again) at native HTML5 Form Validation.
If you’ve ever experimented with HTML5 Form Validation, you’ve probably been disappointed. The out-of-box experience isn’t quite what you want. Adding the
requiredattribute to inputs works wonderfully. However the styling portion with
input:invalidsorta sucks because empty inputs are trigger the
:invalidstate, even before the user has interacted with the page.
I finally sat down and spent a couple days trying to make HTML5 Form Validation work the way I want it. I had the following goals:
- Leverage browser-level feedback, free focus management and accessible labelling
- Only validate inputs on submit
- Styling with
With this wishlist in hand, I set off and found a solution that works with only 6 lines of code.
Web forms are complex beasts. There are a lot of field types to remember, each with dozens of attributes. It’s hard to know which is the right way to go, especially when presented with a choice between two seemingly similar options for disallowing a field to be edited:
TL;DR: If you really need it, which you probably don’t,
readonlyis what you want.
The Key Difference
So why do we have two attributes that do the same thing? Unfortunately this is where developers often get confused: the user experience is the same, but the mechanics are quite different.
Fields marked as
readonlyare collected along with all of the normal field values in a form submission (“successful controls” in the spec). The only difference between a
readonlyfield and a regular field is the user experience.
Fields marked as
disabledare ignored when collecting values from the form. In a traditional form submission, the action page would never receive values for a
disabledfield, regardless of whether it has a
This seems like it could be a useful tool:
Increase your form conversions by fixing common usability issues
Copying text to the clipboard shouldn’t be hard. It shouldn’t require dozens of steps to configure or hundreds of KBs to load. But most of all, it shouldn’t depend on Flash or any bloated framework.
That’s why clipboard.js exists.
The intersection of rushed (or careless) development and unintended consequences:
We’re doing a story about people that have names that websites and computers don’t seem to like - for example, we spoke to a guy named William Test, and a woman named Katie Test, both of whom can’t seem to keep a hotel or airplane booking because the name “test” is flagged by internal systems.
We also spoke to a guy named Christopher Null who had the same problem, and woman named Joan Fread, who can’t use paypal because her last name is the same as a PHP command.
I’m curious if there’s anyone in the dev community that is thinking about this, and how to deal with it. Is it even considered a problem? Is the population that this affects so small that people don’t even think about it?
tabindexof the focused element to “0” ensures that if the user tabs away from the widget and then returns, the selected item within the group retains focus. Note that updating the
tabindexto “0” requires also updating the previously selected item to
tabindex="-1". This technique involves programmatically moving focus in response to key events and updating the
tabindexto reflect the currently focused item. To do this:
Bind a key down handler to each element in the group, and when an arrow key is used to move to another element:
- programmatically apply focus to the new element,
- update the
tabindexof the focused element to “0”, and
- update the
tabindexof the previously focused element to “-1”.
Here’s an example of a WAI-ARIA tree view using this technique.
For a more visual explanation, see the following video by Rob Dodson:
Early in the development of GOV.UK we observed in research how a majority of users would click on radio button or checkbox controls rather than on their labels, despite the fact that the labels are much bigger and therefore easier to click (see Fitt’s Law).
We reasoned that this was because users didn’t know whether or not they could click on the labels. Many websites don’t let you click on labels, so choosing to always click on the control is perfectly rational user behaviour.
First we thought we’d try to make it really obvious that you could click our labels, so we coloured them grey and made them respond to the mouse hovering over them.
We thought this would work, so we rolled out the design across services on GOV.UK. We saw again and again though in lab research that most users still clicked on the controls.
In our latest iteration we’ve replaced the native browser controls with custom ones, which all our supported browsers will get.
We’ve also removed the grey background, as it did not have the effect on user behaviour that it was intended to.