Tags: forms

203

sparkline

Thursday, January 19th, 2023

Three attributes for better web forms

Forms on the web are an opportunity to make big improvements to the user experience with very little effort. The effort can be as little as sprinkling in a smattering of humble HTML attributes. But the result can be a turbo-charged experience for the user, allowing them to sail through their task.

This is particularly true on mobile devices where people have to fill in forms using a virtual keyboard. Any improvement you can make to their flow is worth investigating. But don’t worry: you don’t need to add a complex JavaScript library or write convoluted code. Well-written HTML will get you very far.

If you’re using the right input type value, you’re most of the way there. Browsers on mobile devices can use this value to infer which version of the virtual keyboard is best. So think beyond the plain text value, and use search, email, url, tel, or number when they’re appropriate.

But you can offer more hints to those browsers. Here are three attributes you can add to input elements. All three are enumerated values, which means they have a constrained vocabulary. You don’t need to have these vocabularies memorised. You can look them when you need to.

inputmode

The inputmode attribute is the most direct hint you can give about the virtual keyboard you want. Some of the values are redundant if you’re already using an input type of search, email, tel, or url.

But there might be occasions where you want a keyboard optimised for numbers but the input should also accept other characters. In that case you can use an input type of text with an inputmode value of numeric. This also means you don’t get the spinner controls on desktop browsers that you’d normally get with an input type of number. It can be quite useful to supress the spinner controls for numbers that aren’t meant to be incremented.

If you combine inputmode="numeric" with pattern="[0-9]", you’ll get a numeric keypad with no other characters.

The list of possible values for inputmode is text, numeric, decimal, search, email, tel, and url.

enterkeyhint

Whereas the inputmode attribute provides a hint about which virtual keyboard to show, the enterkeyhint attribute provides an additional hint about one specific key on that virtual keyboard: the enter key.

For search forms, you’ve got an enterkeyhint option of search, and for contact forms, you’ve got send.

The enterkeyhint only changes the labelling of the enter key. On some browsers that label is text. On others it’s an icon. But the attribute by itself doesn’t change the functionality. Even though there are enterkeyhint values of previous and next, by default the enter key will still submit the form. So those two values are less useful on long forms where the user is going from field to field, and more suitable for a series of short forms.

The list of possible values is enter, done, next, previous, go, search, and send.

autocomplete

The autocomplete attribute doesn’t have anything to do with the virtual keyboard. Instead it provides a hint to the browser about values that could pre-filled from the user’s browser profile.

Most browsers try to guess when they can they do this, but they don’t always get it right, which can be annoying. If you explicitly provide an autocomplete hint, browsers can confidently prefill the appropriate value.

Just think about how much time this can save your users!

There’s a name value you can use to get full names pre-filled. But if you have form fields for different parts of names—which I wouldn’t recommend—you’ve also got:

  • given-name,
  • additional-name,
  • family-name,
  • nickname,
  • honorific-prefix, and
  • honorific-suffix.

You might be tempted to use the nickname field for usernames, but no need; there’s a separate username value.

As with names, there’s a single tel value for telephone numbers, but also an array of sub-values if you’ve split telephone numbers up into separate fields:

  • tel-country-code,
  • tel-national,
  • tel-area-code,
  • tel-local, and
  • tel-extension.

There’s a whole host of address-related values too:

  • street-address,
  • address-line1,
  • address-line2, and
  • address-line3, but also
  • address-level1,
  • address-level2,
  • address-level3, and
  • address-level4.

If you have an international audience, addresses can get very messy if you’re trying to split them into separate parts like this.

There’s also postal-code (that’s a ZIP code for Americans), but again, if you have an international audience, please don’t make this a required field. Not every country has postal codes.

Speaking of countries, you’ve got a country-name value, but also a country value for the country’s ISO code.

Remember, the autocomplete value is specifically for the details of the current user. If someone is filling in their own address, use autocomplete. But if someone has specified that, say, a billing address and a shipping address are different, that shipping address might not be the address associated with that person.

On the subject of billing, if your form accepts credit card details, definitely use autocomplete. The values you’ll probably need are:

  • cc-name for the cardholder,
  • cc-number for the credit card number itself,
  • cc-exp for the expiry date, and
  • cc-csc for the security again.

Again, some of these values can be broken down further if you need them: cc-exp-month and cc-exp-year for the month and year of the expiry date, for example.

The autocomplete attribute is really handy for log-in forms. Definitely use the values of email or username as appropriate.

If you’re using two-factor authentication, be sure to add an autocomplete value of one-time-code to your form field. That way, the browser can offer to prefill a value from a text message. That saves the user a lot of fiddly copying and pasting. Phil Nash has more details on the Twilio blog.

Not every mobile browser offers this functionality, but that’s okay. This is classic progressive enhancement. Adding an autocomplete value won’t do any harm to a browser that doesn’t yet understand the value.

Use an autocomplete value of current-password for password fields in log-in forms. This is especially useful for password managers.

But if a user has logged in and is editing their profile to change their password, use a value of new-password. This will prevent the browser from pre-filling that field with the existing password.

That goes for sign-up forms too: use new-password. With this hint, password managers can offer to automatically generate a secure password.

There you have it. Three little HTML attributes that can help users interact with your forms. All you have to do was type a few more characters in your input elements, and users automatically get a better experience.

This is a classic example of letting the browser do the hard work for you. As Andy puts it, be the browser’s mentor, not its micromanager:

Give the browser some solid rules and hints, then let it make the right decisions for the people that visit it, based on their device, connection quality and capabilities.

Tuesday, December 20th, 2022

Network effect

Mastodon is not a platform. Mastodon is just a tiny part of a concept many have been dreaming about and working on for years. Social media started on the wrong foot. The idea for the read/write web has always been different. Our digital identities weren’t supposed to end up in something like Twitter or Facebook or Instagram.

Decentralisation, Federation, The Indie Web: There were many groups silently working on solving the broken architecture of our digital social networks and communication channels – long, long before the “web 3” dudes tried to reframe it as their genius new idea.

I’ve been a part of this for many years until I gave up hope. How would you compete against the VC money, the technical and economical benefits of centralised platforms? It was a fight between David and Gloiath. But now Mastodon could be the stone.

Saturday, November 26th, 2022

How to Weave the Artisan Web | Whatever

Wouldn’t it be nice to have a site that’s not run by an amoral billionaire chaos engine, or algorithmically designed to keep you doomscrolling in a state of fear and anger, or is essentially spyware for governments and/or corporations? Wouldn’t it be nice not to have ads shoved in your face every time you open an app to see what your friends are up to? Wouldn’t it be nice to know that when your friends post something, you’ll actually see it without a social media platform deciding whether to shove it down your feed and pump that feed full of stuff you didn’t ask for?

Wouldn’t that be great?

Tuesday, October 25th, 2022

Get Blogging!

Your easy guide to starting a new blog.

A blog is an easy way to get started writing on the web. Your voice is important: it deserves its own site. The more people add their unique perspectives to the web, the more valuable it becomes.

Thursday, October 13th, 2022

Progressively enhance for a more resilient web :: jjenzz

I realised, progressive enhancement isn’t only about supporting that 1%. It’s about testing your app without JavaScript to ensure 100% of your users have a more performant, usable, available, and resilient experience.

A really good explanation of progressive enhancement as an approach to building anything on the web:

Progressive enhancement does not mean you need to provide the exact same UI without JavaScript. The enhanced experience should be better and it should do more, otherwise the enhanced experience is not needed at all. It enhances a degraded experience that also allows the user to accomplish their goal. For example, entering a postal code manually into a text box might be the degraded experience, and the progressively enhanced experience would prefill the text box based on Geolocation data.

Thursday, September 8th, 2022

TIL: You Can Access A User’s Camera with Just HTML

The capture attribute is pretty nifty—and I just love that you get so much power in a declarative way:

<input type="file" accept="image/*" capture="environment">

Tuesday, August 30th, 2022

Bring Focus to the First Form Field with an Error :: Aaron Gustafson

A handy little script from Aaron to improve the form validation experience.

Saturday, June 4th, 2022

The ‘Form’ Element Created the Modern Web. Was It a Big Mistake? | WIRED

Paul Ford:

The web was born to distribute information on computers, but the technology industry can never leave well enough alone. It needs to make everything into software. To the point that your internet browser is basically no longer a magical book of links but a virtual machine that can simulate a full-fledged computer.

Tuesday, May 17th, 2022

I Replaced My Native iOS App with a Cross-Platform Web App and No One Noticed

It turns out that in 2022, for a lot of apps, the dream of write once run anywhere has finally arrived.

Every year browsers and web technologies become more capable and more powerful. Every year there are more kinds of app that you can make cross platform.

So before you start your next project, why don’t you take a look at cross platform web apps. Maybe they aren’t right for your project, but maybe, like me, you’ll discover that you can code once and run everywhere. And I think that’s amazing.

Thursday, May 5th, 2022

Notes from a gopher:// site - daverupert.com

The result of adding more constraints means that the products have a broader appeal due to their simple interface. It reminds me of a Jeremy Keith talk I heard last month about programming languages like CSS which have a simple interface pattern: selector { property: value }. Simple enough anyone can learn. But simple doesn’t mean it’s simplistic, which gives me a lot to think about.

Wednesday, April 27th, 2022

The lost thread

Twit­ter’s only con­clu­sion can be abandonment: an over­due MySpace-ification. I am totally con­fi­dent about this prediction, but that’s an easy confidence, because in the long run, we’re all MySpace-ified.

What Robin said.

Monday, April 25th, 2022

UI Pattern: Natural Language Form

I only just found this article about those “mad libs” style forms that I started with Huffduffer.

Thursday, April 14th, 2022

A Web Renaissance

Thanks to the mistrust of big tech, the creation of better tools for developers, and the weird and wonderful creativity of ordinary people, we’re seeing an incredibly unlikely comeback: the web is thriving again.

Smart analysis from Anil, though I’m not sure I’d agree with his emphasis on tools and frameworks—it’s the technology built into browsers that has really come along in leaps and bounds, allowing people to do more with less code.

But then there’s this:

So if we have the tech, then why hasn’t it happened already? The biggest thing that may be missing is just awareness of the modern web’s potential. Unlike the Facebooks and Googles of the world, the open, creative web doesn’t have a billion-dollar budget for promoting itself. Years of control from the tech titans has resulted in the conventional wisdom that somehow the web isn’t “enough”, that you have to tie yourself to proprietary platforms if you want to build a big brand or a big business.

True! Anil also points to an act of rebellion and resistance:

Get your own site going, though, and you’ll have a sustainable way of being in control of your own destiny online.

Wednesday, March 30th, 2022

Make Beautifully Resilient Apps With Progressive Enhancement

You had me at “beautifully resilient apps with progressive enhancement”.

This is a great clear walkthrough of enhancing a form submission. A lot of this seems like first principles to me, but if you’ve only ever built single page apps, then thinking about a server-submission process first might well be revelatory.

Sunday, March 20th, 2022

🐠 Robin Sloan: describing the emotions of life online

Obviously, no one does this, I recognize this is a very niche endeavor, but the art and craft of maintaining a homepage, with some of your writing and a page that’s about you and whatever else over time, of course always includes addition and deletion, just like a garden — you’re snipping the dead blooms. I do this a lot. I’ll see something really old on my site, and I go, “you know what, I don’t like this anymore,” and I will delete it.

But that’s care. Both adding things and deleting things. Basically the sense of looking at something and saying, “is this good? Is this right? Can I make it better? What does this need right now?” Those are all expressions of care. And I think both the relentless abandonment of stuff that doesn’t have a billion users by tech companies, and the relentless accretion of garbage on the blockchain, I think they’re both kind of the antithesis, honestly, of care.

Tuesday, January 4th, 2022

The UI fund

This is an excellent initiate spearheaded by Nicole and Sarah at Google! They want to fund research into important web UI work: accessibility, form controls, layout, and so on. If that sounds like something you’ve always wanted to do, but lacked the means, fill in the form.

Wednesday, October 20th, 2021

“The internet wasn’t designed to breach national boundaries” - Rest of World

Say you’re into the indie web without saying you’re into the indie web…

The internet wasn’t really convenient in 1994 or 1995, but it was a very collaborative space.

There was a moment where we replaced this idea of the internet being a medium that we can all write to and participate in to one that is mediated. That happened at some point after social networks started to arrive and when the smartphone started to arrive. It’s a combination of the nature of those platforms and the prevalence of the technologies, which meant the economic rewards of getting this right rose significantly.

And so there’s a really distinctly different feel in the 2013, or 2014, internet to the one that you might have had in 1997, or 1998. It’s not just that it’s easier and I’m yearning for a world of cars with manual choke and manual transmission and crank-up starter handles, but it’s that the programmability of the internet and its endpoints has turned into something that is increasingly permissioned by major platforms.

Tuesday, October 5th, 2021

Build a Better Mobile Input

This is such a handy tool for building forms! Choose different combinations of type, inputmode, and autocomplete attributes on input elements and see how that will be conveyed to users on iOS and Android devices.

Tuesday, September 14th, 2021

Accessibility testing

I was doing some accessibility work with a client a little while back. It was mostly giving their site the once-over, highlighting any issues that we could then discuss. It was an audit of sorts.

While I was doing this I started to realise that not all accessibility issues are created equal. I don’t just mean in their severity. I mean that some issues can—and should—be caught early on, while other issues can only be found later.

Take colour contrast. This is something that should be checked before a line of code is written. When designs are being sketched out and then refined in a graphical editor like Figma, that’s the time to check the ratio between background and foreground colours to make sure there’s enough contrast between them. You can catch this kind of thing later on, but by then it’s likely to come with a higher cost—you might have to literally go back to the drawing board. It’s better to find the issue when you’re at the drawing board the first time.

Then there’s the HTML. Most accessibility issues here can be caught before the site goes live. Usually they’re issues of ommission: form fields that don’t have an explicitly associated label element (using the for and id attributes); images that don’t have alt text; pages that don’t have sensible heading levels or landmark regions like main and nav. None of these are particularly onerous to fix and they come with the biggest bang for your buck. If you’ve got sensible forms, sensible headings, alt text on images, and a solid document structure, you’ve already covered the vast majority of accessibility issues with very little overhead. Some of these checks can also be automated: alt text for images; labels for inputs.

Then there’s interactive stuff. If you only use native HTML elements you’re probably in the clear, but chances are you’ve got some bespoke interactivity on your site: a carousel; a mega dropdown for navigation; a tabbed interface. HTML doesn’t give you any of those out of the box so you’d need to make your own using a combination of HTML, CSS, JavaScript and ARIA. There’s plenty of testing you can do before launching—I always ask myself “What would Heydon do?”—but these components really benefit from being tested by real screen reader users.

So if you commission an accessibility audit, you should hope to get feedback that’s mostly in that third category—interactive widgets.

If you get feedback on document structure and other semantic issues with the HTML, you should fix those issues, sure, but you should also see what you can do to stop those issues going live again in the future. Perhaps you can add some steps in the build process. Or maybe it’s more about making sure the devs are aware of these low-hanging fruit. Or perhaps there’s a framework or content management system that’s stopping you from improving your HTML. Then you need to execute a plan for ditching that software.

If you get feedback about colour contrast issues, just fixing the immediate problem isn’t going to address the underlying issue. There’s a process problem, or perhaps a communication issue. In that case, don’t look for a technical solution. A design system, for example, will not magically fix a workflow issue or route around the problem of designers and developers not talking to each other.

When you commission an accessibility audit, you want to make sure you’re getting the most out of it. Don’t squander it on issues that you can catch and fix yourself. Make sure that the bulk of the audit is being spent on the specific issues that are unique to your site.

Thursday, September 9th, 2021

Accent all areas

Whenever a new version of Chrome comes out, there’s an accompanying blog post listing what’s new. Chrome 93 just came out and, sure enough, Pete has written a blog post about it.

But what I think is the most exciting addition to the browser isn’t listed.

What is this feature that’s got me so excited?

Okay, I’ve probably oversold it now because actually, it looks like a rather small trivial addition. It’s the accent-color property in CSS.

Up until now, accent colour was controlled by the operating system. If you’re on a Mac, go to “System Preferences” and then “General”. There you’ll see an option to change your accent colour. Try picking a different colour. You’ll see that change cascade down into the other form fields in that preference pane: checkboxes, radio buttons, and dropdowns.

Your choice will also cascade down into web pages. Any web page that uses native checkboxes, radio buttons and other interface elements will inherit that colour.

This is how interface elements are supposed to work. The browser inherits the look’n’feel of the inputs from the operating system.

That’s the theory anyway. In practice, form elements—such as dropdowns—can look different from browser to browser, something that shouldn’t be happening if the browsers are all inheriting from the operating system.

Anyway, it’s probably this supposed separation of responsibility between browser and operating system which has led to the current situation with form fields and CSS. Authors can style form fields up to a point, but there’s always a line that you don’t get to cross.

The accent colour of a selected radio button or a checkbox has historically been on the other side of that line. You either had to accept that you couldn’t change the colour, or you had to make your own checkbox or radio button interface. You could use CSS to hide the native element and replace it with an image instead.

That feels a bit over-engineered and frankly kind of hacky. It reminds me of the bad old days of image replacement for text before we had web fonts.

Now, with the accent-color property in CSS, authors can over-ride the choice that the user has set at the operating system level.

On the one hand, this doesn’t feel great to me. Who are we to make that decision? Shouldn’t the user’s choice take primacy over our choices?

But then again, where do we draw the line? We’re allowed over-ride link colours. We’re allowed over-ride font choices.

Ultimately I think it’s a good thing that authors can now specify an accent colour. What makes me think that is the behaviour that authors have shown if they don’t have this ability—they do it anyway, and in a hackier manner. This is why I think the work of the Open UI group is so important. If developers don’t get a standardised way to customise native form controls, they’ll just recreate their own over-engineered versions.

The purpose of Open UI to the web platform is to allow web developers to style and extend built-in web UI controls, such as select dropdowns, checkboxes, radio buttons, and date/color pickers.

Trying to stop developers from styling checkboxes and radio buttons is like trying to stop teenagers from having sex. You might as well accept that it’s going to happen and give them contraception so they can at least do it safely.

So I welcome this new CSS condom.

You can see accent-color in action in this demo. Change the value of the accent-color property to see the form fields update:

:root {
  accent-color: rebeccapurple;
}

Applying it at the document level like that will make it universal, but you can also use the property on an element-by-element basis using whatever selector you want.

That demo works in Chrome and Edge 93, the current release. It also works in Firefox 92, which literally just landed (like as I was writing this blog post, support for accent-color magically arrived!).

As for Safari, well, who knows? If Apple published a roadmap, then developers would have a clue when to expect a property like this to land. But we mere mortals cannot be trusted with such important hush-hush information.

In the meantime, keep an eye on Can I Use. And lack of support on one browser is no reason not to use accent-color anyway. It’s a progressive enhancement. Add it to your CSS today and it will work in more browsers in the future.