Forms

Let’s talk about forms and what you actually need to know right now. This information is adapted from atomica11y.com by Charlie Triplett. Customized Enterprise trainings are available from thebookonaccessibility.com.

Now, you’ll notice this training isn’t called Accessible Forms because if you make a form that’s not accessible, you didn’t create a form, you just made crappy decoration that doesn’t work for everybody. And that’s not what we’re here to do today.

We can’t possibly cover any every rule and nuance about forms. They’re very complex and a very common barrier to people with disabilities. But we can cover the practical basics. There are complete criteria and demos on atomica11y.com atomic A eleven Y.com for design, web, iOS and Android.

To make sure we’re on the same page. A form contains input fields that collect information. So you might have a long form, something like shipping information or some sort of purchase flow. You might have a search input that is in a search form. You could have a sign in feature for your app. All of these are inputs that are collected inside of a form.

To make sure our forms don’t create barriers for people, we want to begin by designing them for people with low vision. People with low vision use desktop or smartphone devices, but they may be increasing the font size on their device. They could be using a magnification tool, or they may simply be pinching and zooming in to get a better look at content.

1 in 12 men and 1 in 200 women have difficulty perceiving the differences between colors. For the rest of your career, you will need to design for people who have what is commonly called colorblindness.

People with motor disabilities may be using a mouse or a trackpad, but may have difficulty doing so with precision. Or they may be using a keyboard or a switch device, which is something kind of like a game controller or even voice command to control their machine.

People who are blind or have very low vision are using their desktop device. They’re using their smartphone, but they’re using an app called a screen reader that reads what’s happening on screen to them in combination with a keyboard or a series of swipes and taps and gestures on their mobile device.

For people with cognitive differences, we want to accommodate people who may have difficulty remembering content, completing complex tasks, or may need just additional time to complete an operation. We could also be talking about someone who is just drowsy and using a cold medication, or someone who doesn’t speak the language that this form is written in or someone who’s distracted by some other problem.

Beginning with low vision, we must make sure that our forms accommodate people who have resized the default size of text up to 200% with no loss of information. This is different from just hitting command or Control plus on your browser and zooming in in that way. People who adjust the default text size on their device would probably say they don’t have a disability, they just like for the text to be easier to read.

Text must have a contrast of at least 4.5 to 1. Any meaningful graphics or status indicators must have a 3 to 1 minimum contrast ratio. And the border around our input fields must have a 3 to 1 minimum contrast ratio. And that border must go all the way around the input. This is incredibly crucial for people who are using magnification tools. Without the border, it’s difficult to understand this is an input. Our forms should follow the format of fields and labels and descriptions all being stacked vertically on the screen.

And we want to left align content. Don’t place labels or buttons in the far right or center of the page. People scan content starting on the left side and moving their eyes from the left to the right when you put content on the right side. It’s also very difficult for people who are using a magnification tool. People who are zoomed way way in on their screen will have difficulty finding inputs or controls that are on the far right or center of the page.

For people with low vision and cognitive differences, fields should afford entry of expected input. So if you know a certain number of characters are expected for an input, let the input field reflect that.

For people who are colorblind, we cannot use color as the only means of conveying information. People with red green colorblindness would not be able to tell the difference between success or error states of these two inputs.

When things go wrong, error messages should help people correct errors. Messages must explain what’s wrong and how to fix it without blaming the user. Let’s spend less time creating the perfect alert icon and more time writing thoughtful UX messaging that helps people correct what is wrong.

For people using assistive technology, there is a specific set of actions that we must accommodate. For people using the keyboard, when they press the tab key, nothing happens to the form itself because forms are not focusable, only the controls inside are focusable. But for someone using a screen reader in combination with a keyboard, they are able to use shortcuts that allow them to navigate through the page and discover forms.

The same is true for people using a mobile screen reader. They are also able to use shortcuts to discover forms. When screen reader shortcuts are used to locate a form, it must declare itself as a form and it must have a name that is clear.

Forms do not receive keyboard focus. Only the controls inside receive keyboard focus. To meet AA standards, this focus must be visible in some way, but it’s often easier to meet AAA requirements and have a blanket 3 to 1 minimum contrast ratio against default and adjacent elements.

Screen readers can collect forms and inputs into a single menu. 8 Item Shipping Information Group Name Edit Text Address Line 1 Edit Text Address Line 2 Edit Text Using the form shortcut menu. We heard the name of the form and we understood what its purpose was, and we understood that it was a form.

Forms must have a name and there are two ways to do this. One is using the ARIA labeledby attribute that points to a specific component that labels the form. In this case, it’s the shipping information legend. It is also perfectly reasonable to use an ARIA label to label the form, in this case payment information.

When something goes wrong, we must make sure that it’s easy to identify, find and fix the errors. But that doesn’t mean a complex validation for every single form. In this case, it’s reasonable to expect the user to be able to traverse back into the form and correct an error when they discover it can’t be submitted.

Longer forms can use more complex validation. In this case, when the user doesn’t enter anything into each field, creating many invalid entries, and then hits the submit button, focus is moved to the first input that needs to be corrected.

It is also acceptable to collect all of the errors into a single group, allowing the user to identify and go individually to each input as this collection does.

Let’s make sure we’re not doing weird stuff in forms. Don’t make every input field the full width of the form. You’re creating a form to be filled in. It’s not a concert poster. Let input fields be the width of the content you expect to be placed inside of them.

Avoid two column form layouts.These are a menace for all users, not just people with disabilities. For someone using magnification tools, multi column forms are especially difficult to use. As you can see, someone must navigate left to right, right to left, creating this zigzag pattern as they move across the form. Locating inputs across the form is not easy as simply scrolling up and down because they must move right to left, left to right. Coming now to the end of the form, the user begins to look for the submit button because of the zigzag pattern that has already been established. It’s very easy for them to click something like this reset button and remove all of their progress from the form when the submit button was actually placed down in the lower right hand corner.

When is it reasonable to break the rules and deviate from accessible patterns? Maybe you saw Apple or Google do something? Just because Apple and Google are big successful companies doesn’t mean everything they do had people with disabilities in mind from the beginning. Maybe your manager thinks that something that’s inaccessible is a really cool design and that really pops. As a designer, as a developer, it’s your responsibility to advocate for people who are using your application, and that includes all people. Let’s do the right thing. Maybe someone is saying that we’re on a tight deadline and we just don’t have time for all this accessibility stuff. That’s nonsense. It doesn’t take any longer to create an accessible form than it does to create an inaccessible form. Maybe the devs said that it’s just not possible to make this form accessible. There are plenty of examples of accessible forms on AtomicA11y.com they can use to understand how to make an accessible form. Maybe someone is saying we want to get all of this content above the fold and so we need to make a multi column form. Getting content above the fold is an idea from the web from over 25 years ago when people didn’t know how to scroll. You can give your users some credit and understand that they know how to scroll up and down to traverse the form.

And that’s the end. Go forth and come back to atomica11y.com when you need help. And if you’re looking for customized enterprise trainings, those are available from thebookonaccessibility.com. Thank you.