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.
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-describedbyand markedaria-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.
The Accessible Forms block
Add the block, then add fields — text, email, number, message, dropdown, checkboxes and radio groups — each with a real label. Group choices get a proper fieldset and legend automatically.
+ → “Accessible Form” → add fields → publish
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.
[ananyoo_form id=“42”]
In the editor
Build the form right in WordPress.
Add fields, set which are required, and write your help text — all from the block, with no separate settings screen and no code.
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.
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.3Full 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.8Your 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 defaultSpam 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 CAPTCHARobust — 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 designStandards-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:
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 [ananyoo_form id="…"] shortcode — in a widget, a template, or another page. The accessible markup is identical both ways.
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.
GPLv2 or later · Free · No registration · No tracking
Built by Shivaji Mitra — Accessibility Consultant since 2003 · Kolkata, India
Part of the Ananyoo collection of WordPress accessibility plugins.