Building Better Forms™ by not taking away affordances

Don’t fiddle too much with your forms‘ look and feel. A small innocent-looking piece of CSS, even when combined with semantically correct HTML, could leave you with a degraded User Experience and make your forms less Accessible.

Yesterday I went to see Girl at Kinepolis. Whilst ordering tickets I ran into an issue though: after completing the payment form – or at least I think I had – it complained about some incomplete fields.

Can you spot the missing completed field(s)?

🤐 Insert sidenote here about the error message not being very distinguishable from the rest of the page, it blends in whilst it should stand out.

After scratching my head for a while, it turned out that I hadn’t selected a payment method. So I selected one, and could continue on forwards.

Oh, those were options for me to choose from!?

🤐 Insert sidenote here about the active payment method indicator being red, which mostly is used to visually indicate errors.

Today, the day after, I revisited the form as I wanted to know why I had missed the payment method in the first place. I work in web, so completing forms shouldn’t be an issue to me, right? I first thought they’d be using some crazy markup/JS combo, but the good thing about this form is that they’ve actually used radio buttons for the payment method selection.

<div class="method-list">
        <label class="method-list-item" data-method-list-item="">
            <input type="radio" name="PaymentMethod" value="BCMC--Ogone--CreditCard" class="method-list-item-input" required="">
            <span class="method-list-item-copy">
                    <img src="" alt="BCMC">
        <label class="method-list-item">
            <input type="radio" name="PaymentMethod" value="MasterCard--Ogone--CreditCard" class="method-list-item-input" required="">
            <span class="method-list-item-copy">
                    <img src="" alt="MasterCard">
        <label class="method-list-item">
            <input type="radio" name="PaymentMethod" value="Visa--Ogone--CreditCard" class="method-list-item-input" required="">
            <span class="method-list-item-copy">
                    <img src="" alt="Visa">
        <label class="method-list-item">
            <input type="radio" name="PaymentMethod" value="Maestro--Ogone--CreditCard" class="method-list-item-input" required="">
            <span class="method-list-item-copy">
                    <img src="" alt="Maestro">
        <label class="method-list-item">
            <input type="radio" name="PaymentMethod" value="MasterPass--Ogone--MasterPass" class="method-list-item-input" required="">
            <span class="method-list-item-copy">
                    <img src="" alt="MasterPass">

Great! As these elements are some of the basic building blocks of the web, they have built-in traits such as having the right semantics, being accessible, etc.

🏆 Extra bonus points for wrapping those inputs in a <label> by the way!

What’s going on then? Well, the “bad” thing about this form is that those radio buttons were visually hidden, as they’d been moved offscreen using a small piece of CSS — a not so uncommon technique:

.method-list-item-input {
    position: absolute;
    left: -99999px;

Even though the form is semantically correct (Yay! 🎉), that little piece of CSS unfortunately introduces two nasty side-effects:

  1. [#UX] Removed Affordance: When completing a form, a user scans for form controls which they need to complete. Since the payment method selector does not seem to contain any form controls, as it looks like a “Hey, here’s some logos of the supported payment methods for ya” kind of thing, the brain skips over it.
  2. [#A11Y] Removed focus indication When tabbing through the form you don’t know that the focus has hit the payment method radio buttons, so you unwillingly skip over it as you keep tabbing. This will give one the impression that they cannot complete the form without the use of a mouse. (It took me a while to figure out how you eventually can: when you’ve hit focus on the payment method selector, hit an arrow key to select one of the options)

Here’s a recording of me tabbing through the form, unknowingly skipping the payment method controls as I didn’t know it got focus:

Now, the fix to these side-effects is quite simple: Don’t try to be smart, and leave the radiobuttons be.

.method-list-item-input {
    /* position: absolute; */
    /* left: -99999px; */

See what I did there?

Sprinkle some CSS on top to make ‘m all a bit more beautiful (alignment, position, color) and you’re good to go:

Ah, these look like options to me!

💁‍♂️ Here’s the CSS I used, in case you were wondering:

.method-list-item {
    display: flex;
    flex-direction: column;
    align-items: center;
    border: 1px solid #bcbcbc;
    margin: 0.25em;
    padding: 0.25em 0.25em 1em 0.25em;

.method-list-item-input {
    /* position: absolute; */
    /* left: -99999px; */
    order: 2;

It adds an outline, adds some margin/padding, and visually moves the radio buttons below the logo (something which I personally find more pleasing). And yes, I know, those logos may be a tad smaller too …

Additionally, they could also add some extra CSS to visually indicate that the wrapping label.method-list-item has a focussed element within. This can be achieved using :focus-within (supported in all modern browsers except Edge):

label.method-list-item:focus-within {
  border-color: #2781a3;

Here’s a recording of me tabbing through the form with all mentioned CSS adjustments applied:

A small change, lifting this form from a 9/10 up to a 10/10, no?

For your own forms, you can use these simple tricks to quickly check them for the issues I just mentioned here:

  1. Tab through your forms (and your site in general) to see if you can access all controls.
  2. Controls should have a different look when they are focussed (e.g. so that you know they have focus)
  3. Think away labels and titles (or translate them to another language), and ask yourself if the meaning of the controls/elements still remain clear or not. (e.g. titles such as “Choose X” don’t indicate choice. Radio buttons / checkboxes / dropdowns do)

Of course those three won’t make a good form all by itself, as you can’t forget about other things the basics such as the use of good labels, grouping of controls, etc. — See Designing Better Forms for a good list of tips.

Here’s to good forms! 🥂

Did this help you out? Like what you see?
Thank me with a coffee.

I don't do this for profit but a small one-time donation would surely put a smile on my face. Thanks!

☕️ Buy me a Coffee (€3)

To stay in the loop you can follow @bramus or follow @bramusblog on Twitter.

Styling the select element

Scott Jehl, from Filament Group:

The select element has long been difficult to style consistently across browsers. To avoid its shortcomings in the past, we have used workarounds like styling a parent element, adding pseudo-elements, and even using JavaScript to construct a select-like control out of different elements that are easier to style. But workarounds are hard to maintain and use, not to mention the accessibility challenges that custom elements bring.

Recently, we’d seen some articles suggest that things haven’t changed a great deal with select‘s styling limitations, but I decided to return to the problem and tinker with it myself to be sure. As it turns out, a reasonable set of styles can create a consistent and attractive select across new browsers, while remaining just fine in older ones too.

Thanks to the appearance CSS property they’ve removed the native styling and were able to inject their own, all whilst retaining the behavior and semantics of the select itself (unlike JS implementations and other attempts). The result is quite nice:

Styling a Select Like It’s 2019 →
Styling a Select Like It’s 2019 (Demo) →

Form Design for Complex Applications

From complex ERP systems to Facebook, applications make meaning out of input. The form — in its many manifestations — provides a gateway for user submission. This article illustrates 13 different ways to present forms, and explores the future of data input.

Good overview and good naming conventions used: Modal, Multi-modal, Slideout, Popover, Inline, …

Form Design for Complex Applications →

👉 Whilst your at it, you might also want to check out 10 Rules For Efficient Form Design and Mobile Form Usability to properly layouting the elements of your forms, not doing stupid things (like using placeholders for labels), etc.

Death to Complexity: Advanced Search at Spokeo


Considering the nature of people search, filtering by parameters other than first and last name is crucial. ‘John Smith’ doesn’t really help you find who you’re looking for, but a 36 year old John Smith in Pasadena, CA, related to a Susan is damn specific, and will inform you quickly if we have the data you want.

Interesting to see how they made their Advanced Search more Simple.

Death to Complexity: How we Simplified Advanced Search →

Designing More Efficient Forms: Structure, Inputs, Labels and Actions


I see it happening a lot: forms without any structure, with wrong types of inputs, with no proper labels, with … – And that’s a bad thing. All the required HTML elements (<fieldset>, <input> types, <label>, etc.) are there, so why not use them?

This article has a nice writeup on how to properly create forms, and it’s backed by usability tests, eye tracking, and the like.

Designing More Efficient Forms: Structure, Inputs, Labels and Actions →

Adaptive Placeholders

See the Pen Adaptive Placeholder by Danny King on CodePen.

We’ve seen some floated labels before: when focussing a form field the placeholder seems to move towards a spot above the field.

Adaptive placeholders goes a step further by also allowing one to change the text when something was entered into the field.

Makes clever use of pointer-events: none;, the :valid psuedo-selector, and the adjacent sibling selector (viz. +).

Adaptive Placeholders →