skip to content

Ananyoo Accessible Forms Plugin

Free, WCAG 2.2 AA accessible forms for WordPress — real labels, screen-reader-announced errors and full keyboard support.

Accessible Forms · WordPress plugin

Accessible Forms — built to get the errors right, too.

Most form plugins are accessible right up until something goes wrong — then they fail silently: a red border a screen reader never announces, an error message no one can find, focus left stranded at the bottom. Accessible Forms is built the opposite way: real labels, an error summary that takes focus and is announced, inline messages tied to each field, and entries stored safely in your own database. The result is accessible forms that keep working when it matters most. And they scale up gracefully: longer forms become short, guided steps, and file uploads stay switched off until you allow them — without ever losing accessibility.

Free · GPLv2 · No tracking · WordPress 6.5+ · PHP 7.4+

Why it’s different

What Accessible Forms gets right

  • Real labels and grouped fields — never a placeholder standing in for one.
  • Errors are announced to screen readers, not just shown in red.
  • Full keyboard support with a clear, visible focus ring.
  • Entries stay in your own database — no third-party service.
  • No forced tracking, and no squint-at-the-letters CAPTCHA — Turnstile and Akismet stay optional.

2 ways

Block + shortcode

WCAG AA

Built to

Your DB

Entries stored locally

Optional

Trackers · external calls

Why this exists

Forms are where accessibility quietly breaks.

A form can look perfect and still lock people out the moment it matters. Placeholder text used instead of a real label, so the field is unnamed for a screen reader. Required fields flagged only by a red outline — invisible to anyone who can’t see colour. An error message that appears visually but is never announced, with focus left at the submit button instead of moving to the problem. These are among the most common accessibility failures on the entire web, and they all happen at the worst possible moment: when someone is trying to reach you. Accessible forms have to handle that moment, not just the easy path.

Accessible Forms is built so the error path is as accessible as the happy path.

The part most plugins get wrong

Errors that everyone can find and fix.

When a submission fails, the plugin follows the pattern accessibility specialists recommend — an error summary at the top, plus a clear message beside every field that needs attention.

  • A summary box takes focus and is announced, so the problem is heard, not just shown.
  • Each summary item is a link that jumps focus straight to the field it’s about.
  • Every field message is tied to its input with aria-describedby and marked aria-invalid.
  • Errors are never colour-only — there’s an icon and wording too.
  • Fix a field and its message clears, and it drops out of the summary, as you go.

Two ways to add a form.

Build accessible forms visually in the editor, or drop one anywhere with a shortcode — the accessible markup is identical either way.

In the editor

The Accessible Forms block

Add the block, then add fields — text, email, number, message, dropdown, checkboxes, radio groups, a file upload, even a step break for multi-step forms — each with a real label. Group choices get a proper fieldset and legend automatically.

// Block inserter
+ → “Accessible Form” → add fields → publish
Anywhere

A simple shortcode

Already built a form? Reuse it anywhere — a widget area, a template, or another page — by id. Same accessible output, no duplication.

// Any post, page or widget
[ananyoo_form id=“42”]

Now does even more

Accessible forms that grow with you — without dropping accessibility.

A contact box is only the start. When your forms get longer, need a file, or you just want a second pair of eyes while you build, these accessible forms keep every step usable for everyone — no accessibility lost as your forms grow.

Multi-step forms

Add a “step break” and a long form becomes short, numbered steps — with a progress marker, Previous and Next buttons, a spoken “Step X of N”, and focus moved to each step as it opens. Turn JavaScript off and the whole form still works as one page, so nobody is left out.

Focus managed · announced

File uploads, off by default

Let people attach a document — safely. A file field can be added any time, but nothing can be uploaded until you switch uploads on. Each field has its own size limit and its own list of allowed file types, and every file is checked on the server before it is saved.

Safe by default

Live accessibility check

A panel beside the builder reviews your form as you work — flagging a missing label, an empty step, a dropdown with no options and more. Each result shows a symbol and a word, never colour alone, so you fix issues before they ever reach a visitor.

Build it right

Accessible email notifications

Both your notification and the visitor’s confirmation go out as accessible HTML email — a real data table with row headings, an alt-text logo and a plain-text version for every inbox. Set header, body and footer colours with a live contrast check, and write the wording for each form.

Contrast-checked · per form

In the editor

Build the form right in WordPress.

Add fields — now including a file upload or a step break for multi-step forms — set which are required, and write your help text, all from the block, with no separate settings screen and no code.

The Accessible Forms block in the WordPress editor — building accessible forms with required fields, labels and help text
An illustration of the Accessible Forms block in the editor — add fields, mark them required, and set labels and help text from the sidebar.

Built on the parts most forms skip.

Every feature of Accessible Forms maps to a real WCAG success criterion — because it was designed by an accessibility consultant, not retrofitted.

Real labels, properly grouped

Every field has a visible <label> tied to its input — never a placeholder standing in for one. Radio and checkbox choices are wrapped in a fieldset with a legend, so the group’s question is announced with each option.

WCAG 1.3.1 · 3.3.2 · 4.1.2

Errors that are announced, not just shown

On a failed submit, a focus-managed summary is announced and links to each problem; every field message is wired to its input and carries an icon and wording, so no error depends on seeing a colour. Focus moves to the summary (or straight to the field, if there’s only one).

WCAG 3.3.1 · 3.3.3 · 1.4.1 · 4.1.3

Full keyboard, visible focus

Every field, the submit button and every summary link is reachable and operable by keyboard, in a logical order, with a clear focus ring. Controls and tap targets are sized for people who find small targets hard to hit.

WCAG 2.1.1 · 2.4.7 · 2.5.8

Your data stays yours

Submissions are saved as entries in your own WordPress database and emailed to you — readable in the admin with a keyboard-friendly quick view. No third-party form service, no tracking by default, and no external request unless you switch on the optional Cloudflare Turnstile or Akismet.

Private by default

Spam stopped without a barrier

A hidden honeypot field and a timing check catch most bots invisibly — no squint-at-the-letters CAPTCHA that locks people out. If you need more, two accessible options can be switched on: Cloudflare Turnstile for a real-time challenge, or Akismet to check submissions and quietly quarantine suspected spam under Entries.

No inaccessible CAPTCHA

Robust — even with JavaScript off

The script is a progressive enhancement. With JavaScript disabled, the server still validates the submission, re-shows the form with the values kept, and renders the same error summary and inline messages — so the form always works.

Robust by design

Standards-based

Built on the W3C’s accessible-forms guidance.

Rather than inventing custom behaviour, Accessible Forms follows the W3C’s published “Forms” tutorial and the WAI-ARIA practices for labelling, grouping and error handling — the same references accessibility specialists test against. The success criteria it’s built around:

1.3.1 Info & Relationships 1.4.1 Use of Color 1.4.3 Contrast 2.1.1 Keyboard 2.4.3 Focus Order 2.4.7 Focus Visible 2.5.8 Target Size 3.3.1 Error Identification 3.3.2 Labels or Instructions 3.3.3 Error Suggestion 4.1.2 Name, Role, Value 4.1.3 Status Messages

Frequently asked questions

How are validation errors shown?

Two ways, together. On a failed submit, an error summary appears at the top of the form, takes focus and is announced to screen readers, with a link to each field that needs fixing. Beside every affected field there’s also an inline message, tied to the input with aria-describedby and marked aria-invalid, with an icon and wording so nothing relies on colour. Fix a field and its message clears and leaves the summary automatically.

Block or shortcode — which should I use?

Either. Build the form with the Accessible Forms block in the editor, then place it on the page directly, or reuse it anywhere with the shortcode — in a widget, a template, or another page. The accessible markup is identical both ways.

Can I split a long form into steps?

Yes. Add a “step break” where you want one step to end and the next to begin, and the form is shown one step at a time — with a numbered progress marker, Previous and Next buttons, a spoken “Step X of N”, and focus moved to each step as it opens. Each step is checked as you go, and if JavaScript is off the whole form simply appears as one page, so nobody is left out.

Can visitors attach a file — and is it safe?

Yes, and safely. You can add a file field at any time, but uploads stay switched off for the whole site until you turn them on — so a form never accepts a file before you are ready. Each file field has its own maximum size and its own list of allowed file types, and every upload is checked on the server for size and type before it is saved.

Does it check my form’s accessibility while I build?

As you build, a panel beside the form reviews how it is set up and points out things to fix — a field with no label, an empty step, a dropdown with no options, and more. Each result is shown with a symbol and a word, never colour alone, so you can catch problems early. It complements testing with a real screen reader and keyboard; it does not replace it.

Where do submissions go?

Into your own WordPress database, saved as entries you can read in the admin, and emailed to the address you choose. Accessible Forms keeps your submissions on your own site — there’s no third-party form service in the middle, so your visitors’ data stays with you.

How is spam handled without an inaccessible CAPTCHA?

By default, a hidden honeypot field and a submission-timing check stop most bots without asking a real person to do anything — so there’s no distorted-text puzzle to fail. If you want a stronger layer, two accessible options can be switched on: Cloudflare Turnstile for a real-time challenge, or Akismet for content-based filtering that quietly keeps suspected spam under Entries so real users are never bounced.

Does it work without JavaScript?

Yes. The client-side checks are an enhancement; the server always validates. With JavaScript off, a failed submission reloads the form with your values intact and the same accessible error summary and inline messages — nothing is lost.

Will it track visitors or slow my site?

No. There’s no tracking and no phone-home by default, scripts are vanilla JavaScript with no build step, and assets load only on pages with a form. The only external requests possible are Cloudflare Turnstile and Akismet, and only if you turn them on.

Add accessible forms in minutes.

It’s free on WordPress.org. Install from Plugins → Add New, search for Accessible Forms, add the block (or use the shortcode), and you have a form that works for everyone — errors and all. Accessible Forms is part of our collection of WordPress accessibility plugins, and pairs perfectly with the WordPress ADA-compliance theme.

GPLv2 or later · Free · No registration · No tracking