---
title: "Accessible Forms: The Changes That Matter Most"
slug: accessible-forms-guide
description: "Labels, focus order, error messaging and touch targets — the accessibility fixes that affect the most people on web forms, and how to check them without specialist tooling."
publishedAt: "2026-08-21"
author: "Instaform Team"
tags: ["forms", "guide", "design"]
locale: en
---

Form accessibility is often treated as a compliance exercise, which is a shame, because the changes that help disabled users are the same ones that reduce abandonment for everyone. A form that works with a screen reader is almost always a form that works better on a phone in bright sunlight.

Here is what actually moves the needle, roughly in order of how many people it affects.

## Label every field, visibly

Placeholder text is not a label. It disappears when the user starts typing, which means anyone who is interrupted mid-form loses the context for what they were entering. It also typically fails contrast requirements, and screen readers treat it inconsistently.

Use a visible `<label>` associated with the input. If your design is tight on space, a small label above the field costs less than the support email from someone who could not tell which box wanted their surname.

This single change fixes more real problems than any other item on this list.

## Make focus visible

Keyboard users navigate with Tab, and they need to see where they are. Removing the focus outline because it looks untidy makes a form unusable without a mouse.

If the default outline clashes with your design, restyle it — do not remove it. A two-pixel ring in your brand colour satisfies both concerns. Then Tab through your own form once, start to finish, and confirm you can always tell where you are.

## Put errors next to the field, in words

Colouring a border red communicates nothing to a screen reader and nothing to a colourblind user. Errors need to be text, adjacent to the field they concern, and associated programmatically with `aria-describedby`.

The wording matters too. "Invalid input" tells the user they are wrong; "Enter a date in the format DD/MM/YYYY" tells them what to do. The second one is shorter to act on and reduces repeat failures — which is why error text is as much a conversion issue as an accessibility one. Our notes on [reducing form abandonment](/blog/reduce-form-abandonment) cover the conversion half of this.

## Size touch targets properly

Interactive elements should be at least around 44 by 44 pixels. This matters for people with motor impairments and for everyone using a phone one-handed on a moving train.

Radio buttons and checkboxes are the usual offenders, because the input itself is small. Make the whole label clickable — it is one attribute and it roughly triples the target area. This matters most on forms people complete on a phone, which for [event registration](/use-cases/event-registration) is the overwhelming majority.

## Keep the tab order logical

Tab order follows DOM order. If your CSS moves fields visually — a two-column layout that reflows, say — the keyboard order can end up unrelated to the visual one, which is deeply confusing.

Avoid positive `tabindex` values entirely; they override document order and are almost always a mistake. Fix the DOM order instead.

## Do not rely on colour alone

Required fields marked only with a red asterisk, or validation shown only as a green border, exclude a meaningful share of users. Pair every colour signal with text or an icon.

The quick check: view the form in greyscale. If you cannot tell what is required or what failed, neither can a colourblind user.

## Announce dynamic changes

Conditional fields that appear based on an earlier answer are useful, but a screen reader will not mention new content unless you tell it to. Use an `aria-live` region for anything that appears, disappears or updates after load.

The same applies to submission states. A spinner that is purely visual leaves screen reader users unsure whether their submission went through, which is how you get duplicates.

## How to check without specialist tools

You do not need an audit to catch most of this:

1. **Tab through the whole form.** Can you always see where you are and reach everything?
2. **Zoom to 200%.** Does the layout hold, or do fields overlap?
3. **View it in greyscale.** Is required-vs-optional still clear?
4. **Submit it empty.** Are the errors specific, textual, and next to the fields?

Four checks, a few minutes, and they catch the majority of real-world problems. Anything built on our [form templates](/templates) starts with labels, focus states and error association already in place, which removes most of the work before you begin.