Accessible forms: what UX design and AI have in common
Forms are the stepchild of every website
I've been doing website audits for over twenty years now. And if there's one thing that's consistently bad, across all sectors, it's forms.
Beautiful hero section. Carefully constructed blog posts. Neatly structured navigation. And then? A contact form with three unlabeled `` elements and a button called "Submit."
Every single time.
It's like building a birdhouse with a perfect roof and walls, but forgetting to put an opening in it. Looks great. Doesn't function.
That's a problem on three levels simultaneously: for users with visual impairments using a screen reader, for search engines assessing page structure, and for AI models trying to understand what your page asks and offers.
The good news? Fixing it isn't rocket science. It's discipline. And the right HTML knowledge.
The basics that must never be missing
An accessible form isn't a special form. It's simply a correctly built form. Period. These elements must always be present:
- Every ``, `
- Use `
- Error messages are linked to the specific field via `aria-describedby`. Not just visually visible, also programmatically.
- Required fields are marked with `required` and `aria-required="true"`. Not just with an asterisk in the label text.
- The tab order follows a logical reading order: top to bottom, left to right.
At a Kobalt client in healthcare, nine out of ten form fields had no associated label. A screen reader announced everything as "edit, blank." Completely useless for someone who is blind. After correction: all fields labeled, Lighthouse Accessibility score from 54 to 91. In an afternoon.
What AI models see when they read your form
But wait. Why would AI crawlers care about your form? Good question. I had to think about it myself for a moment.
AI crawlers read forms differently from humans. But they do read them. And what they extract:
- The `
- The `
- The button text makes a difference. "Request a consultation" communicates something entirely different from "Submit."
- The `action` attribute and HTTP method (GET vs POST) are technical signals about how the form works.
- Autocomplete attributes like `autocomplete="email"` provide additional semantic context.
All these signals together help AI models understand what the page does. A well-built contact form on a consultancy page communicates: "Here you can request a conversation with an expert." A poorly built form communicates: nothing.
And that difference? It counts.
Concrete improvements you can implement now
Enough theory. Here's your checklist, ordered from easy to harder:
- Check that every input field has a `
- Replace placeholder text as the only indication with a real `
- Group related fields in a `
- Write meaningful button texts. "Submit request" or "Schedule a call" tells much more than "Submit."
- Add `autocomplete` attributes to fields asking for personal information: name, email, phone, address.
- Test your form with a screen reader. VoiceOver on Mac, NVDA on Windows, or use the Accessibility tab in Chrome DevTools. It takes five minutes and it's an eye-opener.
Never use `aria-label` as a replacement for a visible `
Want to know how your forms (and the rest of your site) score for AI? Run our free AEO scan at aeo-expert.nl, or contact Kobalt for a full audit.
An accessible form is not a form with extra code. It's a form that is correctly built. For people and for machines. Anyone who makes that distinction is simply building a bad form.
Frequently asked questions
Does form accessibility directly affect my AEO score?
Yes, via two routes. First, it improves your Lighthouse Accessibility score, which correlates with AEO score (as I showed in an earlier article). Second, well-labeled forms give AI models additional context about your page structure and intent. Forms are often the most interactive elements on a page. If those are well constructed, that signals quality across the board.
What is the difference between aria-label and aria-labelledby?
`aria-label` adds an invisible text label that is only read by assistive technology. `aria-labelledby` refers to an existing element on the page that serves as a label. The preference goes to `aria-labelledby`, because it reuses visible text and thus connects the visual and semantic context. Use `aria-label` only when there truly is no visible alternative.
Should every form use a form element?
Yes. Always. A `
How does your website score on AI readiness?
Get your AEO score within 30 seconds and discover what you can improve.