React Forms: Using Refs

React provides two standard ways to grab values from <form></form> elements. The first method is to implement what are called controlled components (see my blog post on the topic) and the second is to use React's ref property.

Controlled components are heavy duty. The defining characteristic of a controlled component is the displayed value is bound to component state. To update the value, you execute a function attached to the onChange event handler on the form element. The onChange function updates the state property, which in turn updates the form element's value.

(Before we get too far, if you just want to see the code samples for this article: here you go!)


Interesting Takes on Log in / Sign Up Forms

A roundup of simple forms that have interesting UI interactions and animations.

I can't guarantee the final demo for each of them is perfectly accessible or measurably improves UX or anything, but that doesn't mean that you can't take inspiration from the ideas and make sure your implementation of them does.

Build (Custom Styled) Online Forms with Wufoo

Need to put a form on a website? I've been using Wufoo to do that for a decade. It's so simple. Just drag and drop the fields you need and select the options you want. Even things that could be complex aren't, like adding logic (e.g. if they select this, show that) or pagination. Never worry about spam. Never worry about losing data, since it's all stored right in Wufoo itself (with API access!).

There are too many features to explain right here (OK two more: payments! reports!). One of my favorites, though, which might appeal to all y'all CSS people: you have complete CSS control over the forms you build. Let's take a look at how that works.


The Art of Labeling

There's a lot of neat tricks in this video by Rob Dodson where he focuses on accessibility tricks in Chrome's DevTools. A few notes:

  • Chrome DevTools has an experimental feature to help with accessibility testing that you can unlock if you head to chrome://flags/ and turn on in the DevTools settings.
  • Wrapping an <input type="checkbox"> in a <label> gives the input a name of the text in the label, even without a for attribute.
  • The aria-labelledby attribute overrides the name of the element with the text taken from a different element, referenced by ID. It can even compose a name together from multiple elements, including itself.
  • Adding tabindex='0' to an element will make it focusable.


:indeterminate is a pseudo-class selector in CSS named for a state that is neither checked nor unchecked. It's that in-between state that we might consider the "Maybe" between "Yes" and "No" options. The state is not fully determined, hence the name: indeterminate.


Alternatives to Placeholder Text

Andrew Coyle on when to use <input placeholder>:

  • Don't use them as a label
  • Don't use them as a secondary label
  • Don't use them as example input
  • Don't use them as helper text

Which amounts to pretty much: "Don't use them". Notice there are no examples of good use cases, and even the examples in the "Do" graphics just say "Placeholder Text", which isn't exactly demonstrative of usefulness.

I wonder if placeholder text will fall completely out of favor.

It reminds me of float labels. Float labels were a fun little fling, but they aren't actually useful. The reason you'd reach for them is when you're so space-limited that you can't show a regular label beside the input. But you can't actually ever remove the label, just move it. So if the label is still there and readable, why not just leave it there the whole time?

[WebKit now has] HTML Interactive Form Validation

Chris Dumez:

WebKit did not support HTML interactive form validation, which occurs on form submission (unless the novalidate attribute is set on the <form> element) or using the reportValidity() API. We are pleased to announce that this is now implemented in WebKit and enabled in Safari Technology Preview 19. Upon interactive form validation, WebKit will now check the validity of all form controls in the form

Form validation in Safari has long been a bummer. It didn't even stop the submission of forms with invalid data. Hip hip hooray for that getting better! It will now prevent form submission and display a visual error:

I also only just heard about reportValidity(). It's just like checkValidity(), except that in addition to returning true or false about the validity, it also triggers the UI:

If there is at least one form control that violates a constraint, WebKit will focus the first one, scroll it into view, and display a bubble near it with a message explaining what the problem is.

See the Pen checkValidity vs reportValidity by Chris Coyier (@chriscoyier) on CodePen.

After creating that demo for testing, I saw Chris Dumez had already created his own.

I imagine this will trickle down to iOS at some point? Not sure how that works.

Radios and Checkboxes on GOV.UK

An interesting journey of form UX, documented by Tim Paul. It started with browser defaults. It's unclear why that wasn't working. But interestingly, an alteration that included giant label-based click areas in color-offset boxes didn't help. What actually helped was bigger (and custom) radios and checkboxes.

So far they’ve tested really well. In research, people of all confidence levels are clicking these controls quickly and easily.

I used to think the size of SurveyMonkey radios was awkwardly large. Now I think it's probably a smart move.

An Intro to Monkey Testing with Gremlins.js

A common idiom in our industry is, "You never can predict how the user will use your product once they get it in their hands." If you've ever watched a stakeholder use a website or web application for the first time, you may know this firsthand. I can't count the number of times I've seen a user seemingly forget how to use websites on a mobile device, or try to use it in a way that makes you think, "But no one would actually do that in real life!"



I absolutely love this idea from Thoughtbot. Just like automated tools that check your HTML for syntax, formatting, validity, or whatever else, FormLinter checks your <form> HTML for best practices. Things like every input having a label, using correct input types, required fields, and more.

Ben Orenstein:

Doing all these things right is worth the effort: improvements like these improve accessibility and increase conversions. However, checking this sort of thing by hand is tedious and error-prone.

We were testing some forms in the ol' CSS-Tricks team chat and it was doing what it said on the box. On Geoff's personal site, it gave his contact form a "B" for not having matching labels for inputs and not having any fields required (seems like a fairly high grade?). The form was output from the mega-popular "Contact Form 7" for WordPress, also a bit surprising.

Many of the forms we tested bombed the app though. No word on that. Might be an HTTPS thing?