Accessible Forms · Live demo

Accessible forms that work for everyone.

Built to WCAG 2.2 AA by construction — try every form by keyboard or screen reader, on any device.

✓WCAG 2.2 AA
✓Block & shortcode
✓Keyboard & screen-reader ready
✓Reflows to 320px
✓No third-party scripts

Full example

Enquiry form — every field type

One form showing text, email, telephone, web address, number, dropdown, radio buttons, checkboxes, a paragraph field and a consent checkbox — each correctly labelled and grouped.

Tip: Submit the enquiry form empty. Watch the error summary appear, take focus, and link straight to each field — the behaviour a screen-reader user depends on.

Reusable

The same engine, different jobs

Each form is stored once and placed by ID, so a short newsletter sign-up and a longer feedback form share the same accessible foundation.

Not block-only

Two ways to place a form

Use the block in the editor, or the shortcode anywhere shortcodes work — the Classic Editor, widgets, and page builders such as Elementor, Beaver Builder and Divi. Both render the identical accessible markup.

Shortcode (works everywhere)

Paste this into any page, post, widget or page-builder shortcode element.

[ananyoo_form id="123"]

Block (Gutenberg)

Add the Accessible Form block and pick your form from the dropdown. No code, same result.

Insert block → “Accessible Form” → choose form

Background

Why accessible forms matter

A form is usually where a visitor becomes a customer — an enquiry, a sign-up, a support request. When a form is hard to use, that visitor simply leaves. Accessible forms remove the common barriers: an input with no real label, an error shown only in red, a control too small to tap, or a focus order that jumps around. Built well, the same form serves a mouse user, a keyboard-only user and a screen-reader user equally.

These accessible forms follow the WCAG 2.2 guidelines from the start rather than as an afterthought. Every field is labelled and programmatically associated, grouped controls use a fieldset and legend, errors are described in words next to the field and in a summary that takes focus, and your answers are preserved when something needs fixing — so nobody retypes a whole form because of one mistake.

You can see this approach applied in real projects in our web accessibility case study, read more about the Accessible Forms plugin, or contact M/S. Anblik to discuss your own site. You can also browse more accessible plugin demos on this site.

Questions

Accessible forms: common questions

Do accessible forms need a CAPTCHA?

No. A puzzle CAPTCHA is itself a barrier. These forms stop most bots with an invisible honeypot and a submission-time check, which add no effort for real visitors and meet WCAG 2.2 Accessible Authentication.

Will these forms work without JavaScript?

Yes. On a live site the server validates and re-shows the form with your values kept and the errors listed. JavaScript only enhances focus handling and adds an early check. Accessible forms should never depend on scripts to be usable.

Can I use these forms outside the block editor?

Yes. A shortcode places any form in the Classic Editor, in widgets, and in page builders such as Elementor, Beaver Builder and Divi. The block and the shortcode produce the same accessible markup.