Why isn’t a placeholder good enough as a field label?

A placeholder isn’t programmatically a label, so many screen readers don’t announce it as the field name, and it disappears the instant someone starts typing — taking the only hint with it. It also typically fails colour-contrast requirements because placeholder text is rendered in a low-contrast grey. WCAG asks for a persistent, associated label (a or a legend). This builder always emits one and lets you use the placeholder only for an example value, which is its actual purpose.

Why are my radio buttons wrapped in a with a ?

A group of radio buttons (or related checkboxes) answers a single question, so it needs a single group name. The / pattern provides exactly that: assistive tech announces the legend as the group’s name and then each option, so users hear “Shipping speed, Standard, radio button, 1 of 3” instead of three orphaned controls. Individual elements on each option still name the options themselves. A single yes/no checkbox doesn’t need a fieldset and the builder won’t add one.

What is autocomplete and why does the tool nag me about it?

WCAG 2.1 added Success Criterion 1.3.5 (Identify Input Purpose), which asks that fields collecting common personal data expose their purpose with the HTML autocomplete attribute — autocomplete="email", "name", "tel", "postal-code", and so on. This lets browsers and password managers fill the field, and helps users with cognitive disabilities who rely on autofill. When a field’s name or label looks like a known purpose (e.g. “email”) but has no autocomplete token, the audit suggests the right one.

How does the generated error handling work?

Each field is generated with an empty error paragraph that already has role="alert" and aria-live="polite", and the field’s aria-describedby points at both its help text and that error element. When your validation fills the error text in, the screen reader announces it immediately and the message is associated with the field. The form also includes a focusable error-summary region at the top (also role="alert"): a common pattern is to populate it with a list of links on submit and move focus to it so users learn what went wrong without hunting.

Does it generate React/JSX as well as plain HTML?

Yes. Toggle the output to JSX and the markup uses htmlFor instead of for, className instead of class, and self-closing inputs — ready to paste into a React component. ARIA attributes, aria-describedby, and autocomplete are identical across both dialects. The HTML output includes novalidate on the form so your own scripted validation and the accessible error pattern take over from the browser’s default bubbles.

Is the generated form ready to submit data?

The markup is structurally complete and accessible — labels, names, required attributes, and a submit button are all there — but it doesn’t include an action, method, or back-end. It’s scaffolding: drop in your endpoint and validation logic. The point of the tool is to get the accessibility semantics right (labels, grouping, descriptions, error wiring, input purpose) so you don’t have to remember every ARIA detail each time you build a form.

Accessible Form Builder

Build a form visually and get markup that’s genuinely accessible — not just an input next to a div. Every field is tied to its <label for>; radio and checkbox groups are wrapped in <fieldset><legend>; help text and an inline error region are wired with aria-describedby; required fields get aria-required; and a focusable error-summary sits at the top. It emits the right type/inputmode and an autocomplete token per field for WCAG 1.3.5, in HTML or JSX, and audits your form for the bugs people ship every day.

About this ToolHow it works, benefits & use cases

Most “form builders” hand you an input sitting next to some text and call it accessible. This one emits markup that a screen reader can actually use. Add fields visually — text, email, password, phone, URL, number, date, textarea, select, radio groups, checkbox groups, or a single checkbox — and the generator ties every control to a real <label for>, wraps radio and checkbox sets in <fieldset><legend>, wires help text and an inline error region through aria-describedby, marks required fields with both the native required attribute and aria-required, and drops a focusable error-summary region at the top of the form. It also sets the right type and inputmode for each field and emits an autocomplete token (WCAG 1.3.5, Identify Input Purpose) so browsers and password managers can fill it. A live preview renders the form as you build it, an audit panel flags the classic mistakes (missing labels, placeholder-as-label, known fields without autocomplete, choice groups without a fieldset, duplicate names), and you can copy the whole thing as HTML or JSX. The full configuration is captured in a shareable URL.

How to Use

1Give the form a title — it becomes the form’s <h2> heading and accessible name via aria-labelledby.
2Add fields and pick a type for each; the editor shows only the relevant options (e.g. an options list for selects and groups).
3Set the label and name, toggle Required, and add help text — it’s wired to the field with aria-describedby.
4For known fields, choose an autocomplete token (email, name, tel, postal-code…) so the form satisfies WCAG 1.3.5.
5Reorder fields with the up/down controls, watch the live preview update, and read the audit panel for issues.
6Toggle HTML or JSX, copy the generated markup, or share the URL.

Key Benefits

Every field gets a real <label for> tied by id — never a placeholder masquerading as a label
Radio and checkbox groups are wrapped in <fieldset><legend> so the group has one shared accessible name
Help text and a per-field role="alert" error region are wired with aria-describedby
Required fields get the native required attribute plus aria-required and a visible marker
A focusable error-summary region (role="alert", aria-live) sits at the top of the form
Correct type/inputmode and an autocomplete token per field for WCAG 1.3.5 (Identify Input Purpose)
Live audit catches missing labels, placeholder-as-label, missing autocomplete, group-without-fieldset, and duplicate names
Copy as HTML or JSX, with a shareable URL that captures the whole form

Common Use Cases

Scaffolding a contact, signup, or checkout form whose fields are correctly labelled and grouped
Adding autocomplete tokens to an existing form to pass WCAG 1.3.5 and enable browser autofill
Getting a fieldset/legend pattern for a set of radio buttons or checkboxes without writing it by hand
Producing a reference example of an inline error pattern (aria-describedby + role="alert") and error summary
Generating accessible React/JSX form markup with htmlFor and self-closing inputs

Generated form

Accessible markup — HTML

<form id="contact-us" class="accessible-form" aria-labelledby="contact-us-title" novalidate>
  <h2 id="contact-us-title">Contact us</h2>
  <p class="form-intro">Send us a message and we’ll get back to you.</p>
  <div
    id="contact-us-errors"
    class="error-summary"
    role="alert"
    aria-live="polite"
    tabindex="-1"
    hidden
  >
    <h3>There’s a problem</h3>
    <ul></ul>
  </div>
  <div class="field">
    <label for="name" class="field-label">Full name <span class="req" aria-hidden="true">*</span></label>
    <input type="text" id="name" name="name" required aria-required="true" autocomplete="name" aria-describedby="name-error">
    <p class="field-error" id="name-error" role="alert" aria-live="polite"></p>
  </div>
  <div class="field">
    <label for="email" class="field-label">Email address <span class="req" aria-hidden="true">*</span></label>
    <input type="email" id="email" name="email" required aria-required="true" autocomplete="email" inputmode="email" aria-describedby="email-help email-error">
    <p class="field-help" id="email-help">We’ll only use this to reply.</p>
    <p class="field-error" id="email-error" role="alert" aria-live="polite"></p>
  </div>
  <div class="field">
    <label for="message" class="field-label">Message <span class="req" aria-hidden="true">*</span></label>
    <textarea id="message" name="message" rows="4" required aria-required="true" aria-describedby="message-error"></textarea>
    <p class="field-error" id="message-error" role="alert" aria-live="polite"></p>
  </div>
  <button type="submit" class="submit">Contact us</button>
</form>

Live preview

Contact us

Send us a message and we’ll get back to you.

Full name

Email address

We’ll only use this to reply.

Message

No accessibility issues found

Form

Title (becomes the form’s heading + accessible name)

Intro / description (optional)

Fields (3)

Field 1Text

Type

Label

Name

Autocomplete (WCAG 1.3.5)

Placeholder (example value, not the label)

Help text (→ aria-describedby)

Required

Field 2Email

Type

Label

Name

Autocomplete (WCAG 1.3.5)

Placeholder (example value, not the label)

Help text (→ aria-describedby)

Required

Field 3Textarea

Type

Label

Name

Autocomplete (WCAG 1.3.5)

Placeholder (example value, not the label)

Help text (→ aria-describedby)

Required

An input next to text isn’t a labelled field

A screen reader only announces a field’s name when the <label> is programmatically tied to it — usually with for/id. A placeholder isn’t a label: it disappears the moment someone types, fails colour-contrast, and isn’t reliably read. This builder always emits a real label, wires help text and an inline error region through aria-describedby, and adds an autocomplete token so browsers and password managers can fill the field (WCAG 1.3.5).

What it gets right that hand-rolled forms miss

Groups — radio and checkbox sets are wrapped in <fieldset><legend> so the group has one shared name.
Required — both the native required attribute and aria-required, plus a visible marker.
Errors — a per-field role="alert" region tied by aria-describedby, and a focusable error-summary at the top of the form.
Input purpose — the right type/inputmode and an autocomplete token per field.

Was this tool helpful?

Share Your Experience

Help others discover this tool!

Share on

Accessible Form Builder

How to Use

Key Benefits

Common Use Cases

Live preview

Contact us

Form

Fields (3)

Field 1Text

Field 2Email

Field 3Textarea

An input next to text isn’t a labelled field

What it gets right that hand-rolled forms miss

Was this tool helpful?

Share Your Experience

Related tools

Frequently Asked Questions - Accessible Form Builder