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.
💵 This linked article is stuck behind Medium’s metered paywall, which may prevent you from reading it. Open the link in an incognito window to bypass Medium’s ridiculous reading limit.
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,
Josh W. Comeau, on embracing modern image formats to ship less bytes to browsers. As not all browsers understand all image formats (Apple/Safari for example doesn’t support .webp, an image format developed by Google) he resides to the picture element with various sources set.
I’ve always abided in the idea that “HTML is accessible by default and then we come along and mess it up. But that’s not always the case. There are some cases where even using plain ol’ HTML causes accessibility problems.
I’m going to start rounding up those HTML shortfalls in this here post as a little living document that I can personally reference every time I write some HTML.
Let this be an actionable list for browser vendors/spec writers to work on.
Until now, the GOV.UK Design System date input component used the HTML element <input type="number" /> to provide a number keypad when a user enters dates.
However, we recently moved away from <input type="number"> to <input type="text" inputmode="numeric" pattern="[0-9]*">
Something we already knew, but that’s now written down by Adrian Roselli in a nice post:
Regardless of what accessibility conformance level you target, do not arbitrarily open links in a new window or tab. If you are required to do so anyway, inform users in text.
Great to see that the statement is backed by the Web Content Accessibility Guidelines (WCAG):
WCAG Link targets fall under Guideline 3.2: Predictable, and state that web pages must appear and operate in predictable ways. Specifically, Success Criterion 3.2.5: Change on Request states that changes of context (such as new pages or windows) must be initiated only by users and that users can disable them otherwise.
And if you do need to use a new window/tab also add rel="noopener noreferrer" for security reasons.
// Seven different types of CSS attribute selectors
// This attribute exists on the element
[value]
// This attribute has a specific value of cool
[value='cool']
// This attribute value contains the word cool somewhere in it
[value*='cool']
// This attribute value contains the word cool in a space-separated list
[value~='cool']
// This attribute value starts with the word cool
[value^='cool']
// This attribute value starts with cool in a dash-separated list
[value|='cool']
// This attribute value ends with the word cool
[value$='cool']
The contains selector becomes really powerful when building a JavaScript filter: such a CSS selector can be passed directly into document.querySelectorAll. The yielded result will immediately contain to correct selection, instead of looping over all items that and checking them one-by-one.
