I never thought of combining the
datalist element with
input type="color"—it’s pretty cool that it just works!
Thursday, April 23rd, 2020
I never thought of combining the
Monday, April 20th, 2020
Here’s one simple, practical way to make apps perform better on mobile devices: always configure HTML input fields with the correct
autocompleteattributes. While these three attributes are often discussed in isolation, they make the most sense in the context of mobile user experience when you think of them as a team.
This is an excellent deep dive with great advice:
You may think that you are familiar with the basic
autocompleteoptions, such as those that help the user fill in credit card numbers or address form fields, but I’d urge you to review them to make sure that you are aware of all of the options. The spec lists over 50 values!
Monday, April 6th, 2020
Chromium browsers—Chrome, Edge, et al.—are getting a much-needed update to some interface elements like the
progess element, the
meter element, and the
color input types.
Monday, March 23rd, 2020
This is a great walkthough of making a common form pattern accessible. No complex code here: some HTML is all that’s needed.
Friday, February 28th, 2020
Some solid research here. Turns out that using
input type=”text” inputmode=”numeric” pattern="[0-9]*" is probably a better bet than using
Friday, February 14th, 2020
Chris takes two side-by-side deep dives; one into the
a element, the other into the
Even if you think you already know those elements well, I bet there’ll be something new here for you. Like, did you know that the
button element can have form over-riding attributes like
Monday, February 10th, 2020
It’s now easier than ever to style form controls without sacrificing semantics and accessibility:
The reason is that we can finally style the ::before and ::after pseudo-elements on the
<input>tag itself. This means we can keep and style an
<input>and won’t need any extra elements. Before, we had to rely on the likes of an extra
<span>, to pull off a custom design.
The demo is really nice. And best of all, you can wrap all of these CSS enhancements in a feaure query:
Hopefully, you’re seeing how nice it is to create custom form styles these days. It requires less markup, thanks to pseudo-elements that are directly on form inputs. It requires less fancy style switching, thanks to custom properties. And it has pretty darn good browser support, thanks to
Saturday, January 25th, 2020
The many ways of improving a single form field in HTML.
I love these kinds of deep dives into markup!
Friday, January 10th, 2020
We have to stop confusing the excesses of capitalism with the hallmarks of quality. Sometimes Google aren’t better, they’re just more pervasive.
cough AMP cough
Friday, November 22nd, 2019
Sacha Baron Cohen’s Keynote Address at ADL’s 2019 Never Is Now Summit on Anti-Semitism and Hate | Anti-Defamation League
On the internet, everything can appear equally legitimate. Breitbart resembles the BBC. The fictitious Protocols of the Elders of Zion look as valid as an ADL report. And the rantings of a lunatic seem as credible as the findings of a Nobel Prize winner. We have lost, it seems, a shared sense of the basic facts upon which democracy depends.
Thursday, September 19th, 2019
When I liveblogged Jason’s talk at An Event Apart in Chicago, I included this bit of reporting:
Jason proceeds to relate a long and involved story about buying burritos online from Chipotle.
Well, here is that story. It’s a good one, with some practical takeaways (if you’ll pardon the pun):
- Use HTML5 input features
- Support autofill
- Make autofill part of your test plans
Tuesday, August 27th, 2019
Web Forms: Now You See Them, Now You Don’t! by Jason Grigsby
Jason is on stage at An Event Apart Chicago in a tuxedo. He wants to talk about how we can make web forms magical. Oh, I see. That explains the get-up.
We’re always being told to make web forms shorter. Luke Wroblewski has highlighted the work of companies that have reduced form fields and increased conversion.
But what if we could get rid of forms altogether? Wouldn’t that be magical!
Jason will reveal the secrets to this magic. But first—a volunteer from the audience, please! Please welcome Joe to the stage.
Joe will now log in on a phone. He types in the username. Then the password. The password is hodge-podge of special characters, numbers and upper and lowercase letters. Joe starts typing. Jason takes the phone and logs in without typing anything!
The secret: Jason was holding an NFC security key in his hand. That works with a new web standard called WebAuthn.
Passwords are terrible. People share them across sites, but who can blame them? It’s hard to remember lots of passwords. The only people who love usernames and passwords are hackers. So sites are developing other methods to try to keep people secure. Two factor authentication helps, although it doesn’t help us with phishing attacks. The hacker gets the password from the phished user …and then gets the one-time code from the phished user too.
But a physical device like a security key solves this problem. So why aren’t we all using security keys (apart from the fear of losing the key)? Well, until WebAuthn, there wasn’t a way for websites to use the keys.
A web server generates a challenge—a long string—that gets sent to a website and passed along to the user. The user’s device generates a credential ID and public and private keys for that domain. The web site stores the public key and credential ID. From then on, the credential ID is used by the website in challenges to users logging in.
There were three common ways that we historically proved who we claimed to be.
- Something you know (e.g. a password).
- Something you have (e.g. a security key).
- Something you are (e.g. biometric information).
These are factors of identification. So two-factor identification is the combination of any of those two. If you use a security key combined with a fingerprint scanner, there’s no need for passwords.
The browser support for the web authentication API (WebAuthn) is a bit patchy right now but you can start playing around with it.
There are a few other options for making logging in faster. There’s the Credential Management API. It allows someone to access passwords stored in their browser’s password manager. But even though it’s newer, there’s actually better browser support for WebAuthn than Credential Management.
Then there’s federated login, or social login. Jason has concerns about handing over log-in to a company like Facebook, Twitter, or Google, but then again, it means fewer passwords. As a site owner, there’s actually a lot of value in not storing log-in information—you won’t be accountable for data breaches. The problem is that you’ve got to decide which providers you’re going to support.
Also keep third-party password managers in mind. These tools—like 1Password—are great. In iOS they’re now nicely integrated at the operating system level, meaning Safari can use them. Finally it’s possible to log in to websites easily on a phone …until you encounter a website that prevents you logging in this way. Some websites get far too clever about detecting autofilled passwords.
Time for another volunteer from the audience. This is Tyler. Tyler will help Jason with a simple checkout form. Shipping information, credit card information, and so on. Jason will fill out this form blindfolded. Tyler will first verify that the dark goggles that Jason will be wearing don’t allow him to see the phone screen. Jason will put the goggles on and Tyler will hand him the phone with the checkout screen open.
Jason dons the goggles. Tyler hands him the phone. Jason does something. The form is filled in and submitted!
What was the secret? The goggles prevented Jason from seeing the phone …but they didn’t prevent the screen from seeing Jason. The goggles block everything but infrared. The iPhone uses infrared for Face ID. So the iPhone, it just looked like Jason was wearing funky sunglasses. Face ID then triggered the Payment Request API.
The Payment Request API allows us to use various payment methods that are built in to the operating system, but without having to make separate implementations for each payment method. The site calls the Payment Request API if it’s supported (use feature detection and progressive enhancement), then trigger the payment UI in the browser. The browser—not the website!—then makes a call to the payment processing provider e.g. Stripe.
E-commerce sites using the Payment Request API have seen a big drop in abandonment and a big increase in completed payments. The browser support is pretty good, especially on mobile. And remember, you can use it as a progressive enhancement. It’s kind of weird that we don’t encounter it more often—it’s been around for a few years now.
Jason read the fine print for Apple Pay, Google Pay, Microsoft Pay, and Samsung Pay. It doesn’t like there’s anything onerous in there that would stop you using them.
On some phones, you can now scan credit cards using the camera. This is built in to the operating system so as a site owner, you’ve just got to make sure not to break it. It’s really an extension of autofill. You should know what values the
autocomplete attribute can take. There are 48 different values; it’s not just for checkouts. When users use autofill, they fill out forms 30% faster. So make sure you don’t put obstacles in the way of autofill in your forms.
Jason proceeds to relate a long and involved story about buying burritos online from Chipotle. The upshot is: use the
pattern attributes correctly on
input elements. Test autofill with your forms. Make it part of your QA process.
So, to summarise, here’s how you make your forms disappear:
- Start by reducing the number of form fields.
- Use the correct HTML to support autofill. Support password managers and password-pasting. At least don’t break that behaviour.
- Provide alternate ways of logging in. Federated login or the Credentials API.
- Test autofill and other form features.
- Look for opportunities to replace forms entirely with biometrics.
Any sufficiently advanced technology is indistinguishable from magic.
—Arthur C. Clarke’s Third Law
Don’t our users deserve magical experiences?
Saturday, August 3rd, 2019
This is about designing forms that everyone can use and complete as quickly as possible. Because nobody actually wants to use your form. They just want the outcome of having used it.
I was chatting with Rachel at work the other day about conversational forms, and I mentioned that I kicked that whole thing off with the mad libs style form on Huffduffer. Here’s the research that Luke later did on whether this style of form could increase conversion.
Sunday, July 21st, 2019
In some situations, a date picker is overkill:
I have relied on plain text inputs as date fields with custom validation for the site, typically using the same logic on the client and the server. For known dates — birthdays, holidays, anniversaries, etc — it has tested well.
Tuesday, July 16th, 2019
Greg has done a lot of research into developer frustrations with customising form controls.
My current thinking in this space, and I know some folks will find this controversial, but I think we should completely standardize in-page form controls with no limitations on their styling capabilities. What do I mean by in-page controls? I am referring to any form control or component that is rendered within the content process. This standardization would include the sub-parts and their related states and how these are exposed (probably through CSS psuedo classes or HTML attributes). This will enable the shadow-dom to be encapsulated while providing web developers with a consistent experience to adjust to match their brand and needs of their site/application.
Thursday, July 4th, 2019
It’s all fun and games until you realise that everything in here was inspired by actual interfaces out there on the web.
Monday, April 29th, 2019
Monday, April 8th, 2019
When we hide content, there’s a greater risk the user won’t see it. There’s a higher reliance on digital literacy and it’s generally more labour intensive for the user.
Worse still, sometimes we kill off essential content.
Sunday, April 7th, 2019
I got a message from a screen-reader user of The Session recently, letting me know of a problem they were having. I love getting any kind of feedback around accessibility, so this was like gold dust to me.
They pointed out that the drag’n’drop interface for rearranging the order of tunes in a set was inaccessible.
Of course! I slapped my forehead. How could I have missed this?
It had been a while since I had implemented that functionality, so before even looking at the existing code, I started to think about how I could improve the situation. Maybe I could capture keystroke events from the arrow keys and announce changes via ARIA values? That sounded a bit heavy-handed though: mess with people’s native keyboard functionality at your peril.
Then I looked at the code. That was when I realised that the fix was going to be much, much easier than I thought.
I documented my process of adding the drag’n’drop functionality back in 2016. Past me had his progressive enhancement hat on:
One of the interfaces needed for this feature was a form to re-order items in a list. So I thought to myself, “what’s the simplest technology to enable this functionality?” I came up with a series of
selectelements within a form.
The problem was in my feature detection:
There’s a little bit of mustard-cutting going on: does the
dragulaobject exist, and does the browser understand
querySelector? If so, the
selectelements are hidden and the drag’n’drop is enabled.
The logic was fine, but the execution was flawed. I was being lazy and hiding the
select elements with
display: none. That hides them visually, but it also hides them from screen readers. I swapped out that style declaration for one that visually hides the elements, but keeps them accessible and focusable.
It was a very quick fix. I had the odd sensation of wanting to thank Past Me for making things easy for Present Me. But I don’t want to talk about time travel because if we start talking about it then we’re going to be here all day talking about it, making diagrams with straws.
I pushed the fix, told the screen-reader user who originally contacted me, and got a reply back saying that everything was working great now. Success!