Text input fields

Okay, it’s time to talk about text input fields and what you actually need to know about them right now.

This information is adapted from atomica11y.com, atomica eleven y.com, and from thebookonaccessibility.com.

Now, you notice this lesson isn’t titled accessible text input fields, because if you create something that’s not accessible, you didn’t really create a text input field. You just created crappy decoration, and that’s not what we’re here to do today.

Now, we can’t possibly cover every accessibility nuance and rule about text inputs. In fact, text inputs are significantly more complex than can be covered in any single lesson. But we’re going to cover the practical basics so that you will have an understanding that there are requirements you do need to follow for text inputs. When you have questions as you design or develop text inputs, you will come back to this information at atomica11y.com for demos, code examples, and all the rules to learn more.

To be sure that we’re talking about the same thing, when we say a text input field, we a field that you can type characters into. That might be a simple text field. It could be a number field, maybe an email address, a phone number, a password.

These are all examples of input fields. To make a text input field accessible, we must be certain we don’t create any barriers for these disabilities, beginning with low vision. When we’re talking about people with low vision, we’re talking about people who are using their smartphones, they’re using their desktop devices, but they may be changing the default text size. They may be using magnification tools. On a handheld device, they may be pinching and zooming in. You’ve all experienced this anytime you’ve taken your smart device outside and tried to read it in the sun. It was suddenly very difficult to read. Not everyone perceives color the same way. One in twelve men and one in 200 women have what we would commonly call color blindness and have difficulty identifying specific colors. For people with motor disabilities, we’re talking about people who may be using a mouse or tapping on their handheld device but can’t do so precisely or are unable to use a mouse or tap on their screen. So they may be using a keyboard, a Switch device, which is something akin to a game controller, or a voice command to control their device. And when we’re talking about blindness, we’re talking about people who are using their smartphone, they’re using their desktop device, but they’re using an application called a screen reader to read what’s happening to them on the screen in combination with a keyboard or on a handheld device using a series of swipes and taps in specific sequence to use their device.

We also need to discuss cognitive disabilities. People who are using a smartphone who are using their desktop device but may have difficulty remembering certain information. They may have difficulty with complicated processes and simply need more time to enter information. We all experience this ourselves. Perhaps we’re distracted because we’re in a noisy situation, maybe an airport terminal, or maybe we have another person in our household that needs our attention. Maybe we’re drowsy from a cold medication we’re taking. Anyone who is entering information into a form using a language that’s not native to them will certainly need extra help to remember their words, make sure they understand complex processes, and take additional time to be certain they enter everything correctly.

For people with low vision, it’s important that we make sure that text can resize up to 200% with no loss of information. Now, this is different from hitting Command or Control plus on your browser. This is literally changing the default size of text on your device. People who utilize this accessibility feature on their smartphone would probably say they don’t even have a disability. They’re just bumping up the text size so they can see things a bit more clearly.

Text must have a minimum contrast ratio of 4.5 to 1. Any status indicator must have a contrast of 3 to 1, and any border around the input must have a 3 to 1 minimum contrast ratio.

We must maintain a container around the input. Minimalistic inputs like this create barriers for people with low vision. While you and I, as sophisticated designers, have seen this pattern before, many people have not and do not immediately understand that this is an input. Many people simply see that as a horizontal line. Let’s avoid this pattern. For people with low vision using a magnification tool, this problem becomes especially stark. It’s very difficult to understand the context of this line and understand that it is an input. But if the input has a border all the way around that contains the input, it’s immediately obvious that this is a text input.

The width of the input should reflect the expected text that will be placed inside of it. If you know that a security code is a certain number of characters, make the input accommodate that number of characters and not more. By offering this affordance to the user, it makes it easier to understand what should be entered at a glance and reinforces the text labels already in place.

We cannot use color as the only means of conveying information. For people with red-green color blindness, it’s impossible to tell which of these is success and which of these is in an error state.

For people who have difficulty tapping their screen or using a mouse precisely, we want to provide a generous click or tap target area that includes the label and is no smaller than 24 by 24 pixels to meet AA requirements. To meet WCAG AA requirements, the click or tap target area is no smaller than 44 by 44 pixels.

For people using assistive technology, there is a specific set of keyboard actions or touch screen gestures that we must follow to make our text inputs accessible. For someone using the keyboard or a screen reader in combination with the keyboard, they will use the tab key to move focus to the input field, and then they are able to begin typing. On a handheld device, using a screen reader swiping left or right moves focus to the input, and upon doing so, the keyboard will appear on screen.

Screen reader output will vary slightly by screen reader and platform. Every text input must have a name that makes its purpose clear. It will identify itself as text input or something similar. And as a group, any hint descriptions or errors are read after the label automatically, and a related group of inputs will include a name for the group. Text inputs can have different states like being required, they could be disabled, they can also be valid or invalid. All of these should be available to the screen reader.

For people with motor disabilities, we want to make sure that we’re accommodating keyboard usage. To meet AA requirements, the focus indication must be visible in some way. To meet AAA requirements, the focus indication must have a three to one minimum contrast ratio against the default and adjacent elements. It’s almost always easier to follow AAA guidance and add something like this thick black outline around all inputs rather than trying to design something custom per different input type.

While on other controls, keyboard focus doesn’t appear when someone is using a mouse. For text inputs, focus always appears. There is no difference between keyboard focus and clicking on a mouse to focus an input. Whether someone is using a mouse, a keyboard, or a Switch device, there will be a visible focus state, and that’s okay. Text input fields, by default, have a focus outline. The reason for this is to help everyone understand what they’re typing into and stay focused on that field. Do not try to remove this for people using a mouse. It actually feels very unnatural to type into a text input that is giving you zero feedback that it is ready to receive that input.

It’s important designers define the type of input, especially for mobile devices. This helps people by bringing up the correct keyboard on a mobile device. As you can imagine, type equals text brings up the text keyboard. Type equals email brings up the text keyboard with an @ symbol. Or type equals tel for telephone brings up the numeric keypad.

Number inputs are very complex, and we can’t use type equals number unless we’re actually expecting an integer from the user. Instead, we use a combination of type equals text, input mode equals numeric, and a pattern to create a number input.

Input fields can also have autocomplete attributes. These are the clues that your browser uses to autofill your information that it has stored about you. This is exceedingly helpful for people with motor disabilities, especially if they’re using a Switch device, and for people with cognitive disabilities who have difficulty remembering information.

Let’s listen to a screen reader read a basic text input field. The best NATO letter is example Alpha Bravo Charlie. Edit text, main. The second NATO The letter is required. Required Invalid data. Edit text. For each of those inputs, you heard its name, you heard it identify itself as some type of text input, hint descriptions were read after the label, and the input that was required declared itself as required. There are more screen reader examples, platform examples, and device examples at atomica11y.com.

An input field must have a name. This is more than just bold text up above the input. It is composed of a label using a for attribute referencing the ID of the input. Likewise, the hint description is referenced by the input itself using aria-describedby. This is what allows all of this text to be read by the screen reader when the input field is in focus.

A group of inputs can be placed inside of a field set, which is a set of fields. By giving the field set a name with the legend element, each of these inputs can also describe the group that it is in.

Now, let’s avoid doing weird stuff.

Never use placeholder text as a label. That is simply not allowed. It is difficult for people using a screen reader to understand what the name of the input is after they’ve entered information into it. It is also difficult for people who have difficulty remembering after they’ve entered information into it. Remember, the placeholder text disappears after you begin typing. After that point, there is nothing to indicate what the name of the input is. We also don’t use placeholder for helper descriptive text. That is also not allowed.

And don’t put helper descriptions in a tool tip. We don’t use tool tips or modals just to save space. We want to write a tight UI and trust that people know how to scroll.

We don’t need to make helper text or error text super small. If it’s worth being there, it’s just as important as the label. Making text smaller is not a content strategy.

Don’t break inputs with tiny floating labels. And I am looking at you, material design. So here we an email input, and when it’s in focus, the label floats up above the actual input. So what’s so wrong with this? First of all, this particular input does every weird thing we don’t want. It doesn’t have a border all the way around the input. It has made the helper text small and injecting more helper text into the placeholder. And now it’s making the label small as well. This makes it difficult to read for people with low vision. The other thing we must remember is that by floating the label in front of the input, By default, the input is now broken, and we must use heavy, heavy JavaScript to move the label above the field in order to make it even usable. Even more scripting is required to decide when to move it back during its different states, and this scripting must be maintained forever. To be frank, most UI developers are not sophisticated enough to build an accessible component like this. Lastly, what eventually happens is everyone misunderstands this label as placeholder text when it is not, leading to placeholder text being used as a label. Essentially, it takes an input that already worked, breaks it, and then uses JavaScript to fix it again. Why would you do that?

Don’t wrap the entire label input and helper text description in a focus outline. Nobody is asking for that. The entire point of the focus outline is to make it clear what you are interacting with. You are not interacting with the label and the description. You are only interacting with the text input field.

Look, your form is not a concert poster, so don’t make every input fill the entire width of the form. Utilize the principle of affordance and make inputs reflect the amount of content they are intended to receive.

When can we deviate from accessible patterns? Well, maybe you saw Apple or Google do something. But just because Apple and Google are big, successful companies, doesn’t mean everything they do has people with disabilities in mind. Maybe your manager thinks an inaccessible pattern just looks way cooler than an accessible pattern. But look, as a designer, as a developer, it’s your responsibility to advocate for people with disabilities who are using your product. So let’s do the right thing. Maybe people are saying, We’re on a tight deadline, and there’s just not time to make an accessible text input. But that’s just nonsense. It doesn’t take any longer to make an accessible text input than it does to make an inaccessible text input. Maybe the devs are saying it’s just not possible to add accessibility to this. That’s nonsense. There are plenty of examples on atomically.com that will give them everything they need to code an accessible input. Maybe you’re being pushed to put helper text inside tooltips just so you can get content above the fold. Listen, the idea of getting content above the fold originates from the early 2000s before people knew how to scroll. Back then, it was very important that you got all the content in the first view of the web page because people might not see it. You can trust that your users know how to scroll, and you can leave this outdated idea behind.

And that’s the end. Go forth and come back when you need help. You can always find more information on atomica11y.com. And if you’re building an enterprise accessibility program, TheBookOnAccessibility.com is for you. Thank you.