Description
Ananyoo Accessible Forms builds contact and lead forms that conform to WCAG 2.2 Level AA out of the box. Instead of bolting accessibility on afterwards, every form is generated with correct semantics from the start: a real <label> for every control, fieldset/legend for grouped inputs, an error summary that takes focus, inline errors tied to their field with aria-describedby and aria-invalid, and a status region that announces success.
Developed by Shivaji Mitra (M/S. Anblik).
Live demo: Try the accessible forms demo »
Why this plugin?
Most popular form plugins can be made accessible, but they do not start that way — you have to know exactly which settings to change and which markup to fix. This plugin makes the accessible result the default, so a form added by a non-expert is still usable by keyboard and screen-reader visitors, on the smallest phone, in high-contrast mode.
Key features
- Accessible by construction — label per field, fieldset/legend for radio and checkbox groups, required state exposed to assistive tech.
- Error summary with managed focus — on a failed submit, an
role="alert"summary lists each problem as a link to the field, and focus moves to it (WCAG 2.2 SC 3.3.1, 2.4.3). - Values kept on error — visitors never retype a whole form because one field failed (SC 3.3.7 Redundant Entry).
- Accessible anti-spam, no puzzles — an invisible honeypot plus a submission-time trap stop bots without a CAPTCHA, satisfying SC 3.3.8 Accessible Authentication.
- Reusable forms — each form is stored once and can be placed on many pages by ID.
- Stored entries — every submission is saved so nothing is lost if an email fails. List, search, trash and restore using the native WordPress screens.
- Spam quarantine — suspected spam is moved to a recoverable Spam view, not deleted, so false positives can be restored.
- Block and shortcode — insert the Accessible Form block, or use
[ananyoo_form id="123"]anywhere, just like a classic contact form. - Any-SMTP delivery — notifications are sent through
wp_mail(), so any SMTP plugin you already use handles deliverability. - 3 px focus ring, 44 × 44 targets — meets WCAG 2.2 SC 2.4.11/2.4.13 and 2.5.8 by default (both adjustable).
- Reflows cleanly at 320 px, respects prefers-reduced-motion, and supports Windows High Contrast / forced-colors.
- Works without JavaScript — the server validates and re-renders; JavaScript only enhances focus handling and adds an early client-side check.
- Clean uninstall option — off by default (your data is kept). Turn it on to remove every form, entry and setting when the plugin is deleted.
Links
- Plugin home & documentation
- Live demo
- More accessibility plugins from Ananyoo — further WordPress accessibility plugins are in active development.
- Support & contact
Privacy
This plugin stores the entries you receive in your own WordPress database and sends notification emails through your site’s own mail system (the standard wp_mail() function). It does not send your data to any third-party service and adds no tracking or front-end links of its own. If you enable the optional Cloudflare Turnstile support, the separate companion plugin you choose handles that request.
Screenshots







Blocks
This plugin provides 1 block.
- Accessible Form Embed a WCAG 2.2 AA accessible form by Ananyoo.
Installation
- Upload the plugin to the
/wp-content/plugins/directory, or install it from the Plugins screen. - Activate it. Three ready-to-use example forms are created automatically: an enquiry form (showing every field type), a newsletter sign-up, and a quick feedback form.
- Go to Ananyoo Accessible Forms to edit fields, or create a new form.
- Copy the form’s shortcode (e.g.
[ananyoo_form id="123"]) into any page or post, or add the Accessible Form block and choose your form. - Set the notification email under Ananyoo Accessible Forms Settings. For reliable delivery, use any SMTP plugin.
FAQ
-
Do I need a CAPTCHA?
-
No. The built-in honeypot and submission-time trap stop most bots without asking visitors to solve a puzzle, which keeps the form accessible. The plugin deliberately does not bundle a CAPTCHA, and never uses image-puzzle CAPTCHAs, which create barriers for many disabled visitors.
If your forms attract heavy, targeted spam and you want an extra layer, the most accessible choice is Cloudflare Turnstile — in its “Managed” / interaction-only mode it verifies most visitors invisibly, with no puzzle to solve. Add it with a dedicated Turnstile plugin (for example, “Simple CAPTCHA Alternative with Cloudflare Turnstile”). See the next question for connecting it to these forms.
-
How do I add Cloudflare Turnstile (or another CAPTCHA) to these forms?
-
The easiest way is automatic. Install the free “Simple CAPTCHA with Cloudflare Turnstile” plugin (by RelyWP) and add your Turnstile keys. These forms then detect it and show the Turnstile challenge by themselves — no code, no shortcode. A failed or missing challenge is reported through the same accessible error summary as any other field, with the visitor’s answers kept. You can switch this off under Ananyoo Accessible Forms Settings.
Importantly, this plugin still loads no third-party script itself; the companion plugin renders and enqueues the Turnstile widget. So this plugin makes no external requests on its own.
Prefer a different CAPTCHA, or want full control? Two hooks are also available:
do_action( 'ananyoo_aaf_before_submit', $form_id, $uid, $errors )— fires just before the submit button, inside the form. Use it to output a verification widget.apply_filters( 'ananyoo_aaf_validation_errors', $errors, $raw, $fields, $form_id )— return a non-emptyname => messagearray to reject a submission. The message then appears in the accessible error summary and beside the form.
Developers can also disable the built-in Turnstile integration with the
ananyoo_aaf_use_turnstilefilter (returnfalse). -
Does the plugin make external requests or track anything?
-
No. By itself the plugin makes no external/HTTP requests and includes no analytics or tracking. (If you add a third-party CAPTCHA plugin, such as Cloudflare Turnstile, that plugin handles its own requests and data under its own privacy terms.)
-
Are submissions stored if the email fails?
-
Yes. Every valid submission is saved as an entry before the email is sent, so a mail problem never loses a message.
-
Will deleting the plugin remove my data?
-
Only if you choose to. The clean-uninstall option is off by default, so your forms and entries are kept. Enable it under Settings if you want everything removed on delete.
Reviews
There are no reviews for this plugin.
Contributors & Developers
“Ananyoo Accessible Forms – Contact Form & Entry Storage” is open source software. The following people have contributed to this plugin.
ContributorsTranslate “Ananyoo Accessible Forms – Contact Form & Entry Storage” into your language.
Interested in development?
Browse the code, check out the SVN repository, or subscribe to the development log by RSS.
Changelog
1.1.2
- Shortened the admin sidebar menu label to “Accessible Forms” for a cleaner menu, consistent with the other Ananyoo accessibility plugins. The directory name is unchanged.
- Readme: linked the live demo and added Links and Privacy sections. No functional changes.
1.1.1
- Coding-standards: unified all custom identifiers under the distinct “ananyoo_aaf” prefix. The two custom post types, the spam post status, the entry-manager capability, the Quick View admin-ajax action and its nonce, and all post-meta keys now use the full prefix, avoiding any short or inconsistent names that could collide with other plugins.
1.1.0
- Renamed the plugin to “Ananyoo Accessible Forms – Contact Form & Entry Storage” so the name leads with the Ananyoo brand and is distinctive (slug: ananyoo-accessible-forms).
- Coding-standards: the “Add New” rule on the Entries screen is now served from the enqueued admin stylesheet instead of an inline style block.
- Hardening: POST data passed to the ananyoo_aaf_validation_errors filter is now sanitised before any third-party callback receives it.
- Hardening: the sender name shown in the Entries list (via the the_title filter) is now escaped at the source.
1.0.9
- Notification email subject is now “Form Name: Subject” — the form’s title followed by the value of the submission’s subject field (for example, “Enquiry Form: General enquiry”), replacing the old “[Site] New form entry: …” line. When a form has no subject field, or it is left blank, the subject is just the form name.
- The three sample forms created on a fresh install are now titled in Title Case — “Enquiry Form” (previously “Enquiry form — every field type”), “Newsletter Sign-up” and “Quick Feedback”. Existing forms are unaffected.
- No accessibility, settings or visual changes.
1.0.8
- Accessibility (WCAG 3.3.1 / 2.4.3): on a failed submission, keyboard focus now moves to the FIRST field with an error — never to the error summary — so the screen reader announces that field’s own message (via aria-invalid + aria-describedby) and the visitor lands exactly where they can fix it. On a form with many fields, this avoids making the user step past a long list of errors before reaching the first one. Applies to both the client-side check and the server-rendered result after a no-JavaScript submit.
- The error summary at the top is now a plain, visible overview with jump-links to each field, rather than an assertive alert that takes focus. It still appears only after a failed submission, lists every error, and updates live as fields are corrected — it just no longer competes with, or delays, the announcement of the field that focus lands on.
- No settings or visual-design changes.
1.0.7
- Accessibility: error-summary links now move keyboard focus to the matching field on every path. The server-rendered summary previously only scrolled (focus moved only on the JS-built summary); a single delegated handler now covers both, and grouped radio/checkbox fields focus their first option.
- Accessibility: the group
<
fieldset> now carries the field id, so the summary link for a radio/checkbox group resolves correctly (it pointed at a non-existent target before).
* Accessibility: correcting a field now updates the error summary live — the fixed field’s line is removed from the summary (and the summary disappears once all errors are resolved), matching the inline message that already cleared.
* No settings, markup-structure or visual changes beyond the fieldset id.
1.0.6
- Getting Started screen: added a “Managing your entries” section covering the entries list columns, the Quick View / View / Trash actions, and the Yes/No display, so the in-plugin help reflects the current features.
1.0.5
- Single checkbox / consent values now display as “Yes” (or “No”) instead of “1” in the entry view, the Quick View popup and the email notification, so they read clearly.
1.0.4
- The Sender column now shows the submitter’s name computed from the submission data, so existing entries read cleanly too (not only newly titled ones).
- New: a “Quick View” row action opens the entry in an accessible modal dialog without leaving the list. Focus moves into the dialog, Escape closes it, focus is trapped while open and returned to the link afterwards, and it falls back to the full View page when JavaScript is unavailable.
1.0.3
- Entries list improved: the read-only Edit and Quick Edit row actions are replaced by a clear View action (Trash is kept); the first column now shows the Sender name and links to the entry; and new Subject and IP columns are added, with the form name kept in its own column.
- New submissions are now titled by the sender’s name rather than “Form name — value”, so the entries list reads more cleanly.
1.0.2
- Improved: in the single-entry admin view, the “Received … from IP …” submission metadata is now shown as a centred band, set apart from the field/value table with space above and below, so it reads clearly as information about the submission rather than a submitted value. (The entry-view styles now load on the entry screen too.)
1.0.1
- Fixed: the URL/website field rejected valid web addresses. Validation now checks the address format instead of performing a live host lookup, so addresses such as https://www.example.com are accepted.
- Fixed: required and format error messages no longer show a stray full stop when a field label is written as a sentence (for example a consent line), so the wording reads cleanly.
1.0.0
- Initial release.
- Accessible forms built to WCAG 2.2 AA by construction: a real label per field, fieldset/legend for radio and checkbox groups, and the required state exposed to assistive technology.
- Error handling with managed focus: a
role="alert"summary that links to each field, plus an inline message under every invalid field tied to it witharia-describedbyandaria-invalid. Focus moves to the single field when there is one error, or to the summary when there are several. - Specific, action-led messages, including format suggestions for email, web address and number fields (WCAG 2.2 SC 3.3.3).
- On-blur checking that validates a field once the visitor has used it and clears the message live as it is fixed; the form still validates fully on submit and on the server, and works with JavaScript disabled.
- Values kept on error (SC 3.3.7), a 3 px focus ring and 44 x 44 targets by default (both adjustable), clean reflow at 320 px, and reduced-motion and forced-colors support.
- Accessible anti-spam with no puzzles: an invisible honeypot and a submission-time trap, plus a recoverable spam quarantine. Optional, automatic Cloudflare Turnstile when the free “Simple CAPTCHA with Cloudflare Turnstile” plugin is active (this plugin loads no third-party script itself); hooks (
ananyoo_aaf_before_submit,ananyoo_aaf_validation_errors) allow any other CAPTCHA. - Reusable forms placed by ID via the Accessible Form block or the
[ananyoo_form id="123"]shortcode; submissions stored as entries; notifications throughwp_mail()for any-SMTP delivery; and an optional clean uninstall. - Three ready-to-use example forms created on activation: an enquiry form (every field type), a newsletter sign-up, and a quick feedback form.
