Form Accessibility: Every Gate Should Open for Everyone

The gate that sticks

Every meaningful interaction on the web eventually leads to a form. Searching, subscribing, purchasing, contacting, logging in. Forms are the gates between browsing and doing. When a form isn't accessible, the gate sticks, and the people on the other side can't get through.

Form accessibility failures are especially costly because they happen at the point of conversion. A user who navigated your entire site successfully, read your content, and decided to take action gets stopped at the last step. That's not just an accessibility problem. It's a business problem.

Labels are not optional

The most fundamental form accessibility requirement is also the most commonly violated: every input needs a programmatically associated label. Not a placeholder. Not a heading above the group. A <label> element with a for attribute matching the input's id.

Placeholders disappear when the user starts typing, leaving them with no reference for what the field expects. Floating labels that animate into a smaller size on focus are a visual compromise. They're often too small to read and can confuse screen readers depending on implementation.

The pattern that works everywhere: a visible label above or beside the input, properly associated in the markup.

Group related fields

Radio buttons and checkboxes that belong together need a <fieldset> with a <legend>. Without this grouping, a screen reader user hearing "Yes, No" has no idea what question they're answering. The legend provides that context: "Do you want to receive email updates? Yes, No."

Address blocks, payment sections, and any logical grouping of fields benefit from the same pattern. It's the difference between handing someone a sorted seed tray and dumping loose seeds on the table.

Error handling that helps

When a form submission fails validation, three things need to happen for accessibility:

• Announce the error. Use aria-live="polite" or role="alert" to ensure screen readers announce when errors appear. Silent visual indicators help no one who can't see them.
• Identify the field. Each error message should be associated with its input via aria-describedby, so the user hears the error when they focus the problem field.
• Move focus. After submission fails, move focus to either a summary of errors at the top of the form or to the first invalid field. Don't leave the user stranded at the submit button wondering what went wrong.

Required fields need more than an asterisk

A red asterisk next to a label communicates "required" to sighted users who know the convention. For screen reader users, add aria-required="true" or the HTML required attribute to the input. Both approaches announce the field as required when it receives focus.

Custom controls carry a heavier burden

Native HTML form elements (<select>, <input type="checkbox">, <input type="radio">) come with built-in keyboard support, focus management, and screen reader announcements. Custom-styled replacements need to replicate all of that behavior manually through ARIA roles, keyboard handlers, and state management.

Before you replace a native element with a custom component, ask whether the visual improvement justifies the accessibility debt. Sometimes a well-styled native <select> is the better harvest: reliable, tested, and universally understood.

Test the path, not just the field

Form accessibility isn't just about individual inputs. It's about the entire flow: from finding the form to completing it to understanding the result. eiSEO catches the structural issues: missing labels, absent fieldsets, improperly associated errors. But the full test means filling out your own form with a keyboard and screen reader, start to finish, and asking: would I be able to do this if I couldn't see the screen?

Every gate on your property should open for every visitor. No exceptions.