Text fields are probably one of the most used interface components; contact forms, payment details, account creation, lead generation. Users definitely need to interact with text fields when using your product. The purpose of this post is to highlight some of the key guidelines which I follow when it comes to designing better text fields.
It’s pretty basic things that, unfortunately, a lot of people seem to forget.
Too often folks will grab ARIA first to provide an accessible name for a thing. Or they may sprinkle hidden content around a form. In most cases the impact of those decisions is unknown. The assumption that they do the same thing, give the same output to all users, is wrong.
In short, here’s the priority he follows when assigning an accessible name to a control:
Native HTML techniques,
aria-labelledby pointing at existing visible text,
On Netlify, any HTML form can instantly accept submissions—no backend code or infrastructure required. As soon as your form is deployed, you start seeing submissions appear in your Netlify dashboard.
Just add the netlify attribute to any form and everything gets wired up automatically.
Netlify will automatically create some backend code to handle the form submissions. The submissions will be stored and then shown in your control panel. Comes with a free tier of 100 submissions/month.
There are plenty of opportunities for friction in the user experience when logging in, particularly while entering a two factor authentication code. As developers we should be building applications that support the need for account security but don’t detract from the user experience. Sometimes it can feel as though these requirements are in a battle against each other.
In this post we will look at the humble <input> element and the HTML attributes that will help speed up our users’ two factor authentication experience.
The final markup to trigger the correct keyboard and have the browser autocomplete the received SMS code is this:
24ways – the advent calendar for web geeks – is back! First post is “Making a Better Custom Select Element” in which Julie Grundy tries to create an accessible Custom Select Element:
Sometimes, I can’t recommend the select input. We want a way for someone to choose an item from a list of options, but it’s more complicated than just that. We want autocomplete options. We want to put images in there, not just text. The optgroup element is ugly, hard to style, and not announced by screen readers. The focus styles are low contrast. I had high hopes for the datalist element, but although it works well with screen readers, it’s no good for people with low vision who zoom or use high contrast themes.
🤔 I found this one highly interesting to read as I tend to do the exact opposite when it comes to placing buttons. Inspired by macOS I place the primary button on the right, the secondary button to the left of the primary one, and the cancel option at the very left.
I’m wondering what Johan (Interface Designer) and Roel (Digital Accessibility Nerd) their take is on this …
UPDATE 2019.09.18: Thanks to (requested) input by Johan/Roel/Xavier we can safely conclude that the mentioned guidelines are not perfect.