Accessibility

By the end of this page you will know what TrazoForms does for accessibility, and what real testing — not just design intent — found. Every published form aims for WCAG 2.1 level AA without extra configuration; you do not need to turn anything on.

Labels and descriptions

Every field has a label linked to it, even when you choose to hide it: a hidden label is only visually hidden, and screen readers still announce it.
Help text and error messages are linked to their field with aria-describedby, so they are read together with it.
Radio buttons and checkboxes are grouped in a <fieldset>/<legend>, including Consent with several checkboxes, so screen readers announce which question each option belongs to.
Name, address and email-confirmation fields give each part its own label.

Errors

Each error appears next to its field, in words, announced live (aria-live) as it appears.
An error summary at the top of the form lists every error with a link to its field, announced as an alert. On by default.
Errors are never shown by color alone: there is always text, and the summary also has an icon.
The form works without JavaScript, including validation and the confirmation message. Re-showing the form after a server-side error keeps what was already typed, and never re-marks a consent checkbox as accepted because of an unrelated error elsewhere.

Required fields

Whichever marker you choose (an asterisk, your own text or no visible mark), screen readers always announce that a field is required — validation uses the real HTML required attribute, not only an aria- one, so both the browser and assistive technology agree.

Motion and focus

Animations turn off automatically if the visitor’s operating system asks for reduced motion.
Radio and checkbox markers are hidden visually but stay in the accessibility tree and keyboard-focusable, with a visible 2px focus ring — wider than the WordPress admin’s own 1.5px, which was easy to miss.

Colors and progress

The eleven palettes are checked against the WCAG 2.1 contrast minimums, in light and dark mode, for text, help text, borders, buttons and error and success messages.
In multi-page forms (Pro), progress is also given as real text (“Step 2 of 3”), not only a visual indicator.
The character counter states how many characters are left; its change of color is only a reinforcement.

How this was actually tested

axe-core 4.13, against the nine templates and a multi-page variant, in light and dark mode, with WCAG 2.0/2.1/2.2 A and AA rules plus best practices: zero violations.
Lighthouse, against real forms on a development WordPress site: mobile scores of 98 (performance), 100 (accessibility), 96 (best practices) and 91 (SEO); desktop scores of 100 (performance) and 96 (accessibility). What kept the desktop accessibility score off 100 was the active theme’s own navigation markup, not the plugin.
Mobile layout at 375px width, across all nine templates: no horizontal overflow, every touch target above the 24×24px minimum, and text inputs at 16px so iOS does not zoom in when focusing them.
A real screen reader test, confirmed as passing by the plugin’s own team.

Known limitation

axe-core flags the File upload field’s own “Choose files” button as a second label competing with the field’s own label, since the field’s label already contains all the needed information. This has not been changed, because doing so risks hiding the button’s own accessible name instead. If this affects you, test your specific form with your own screen reader.

Your part

Some things depend on how you write the form:

Write labels that make sense on their own. “Name” is clearer than “Enter it here”.
Do not put essential instructions in the placeholder: it disappears when the person starts typing. Use the help text.
If you add images in an HTML block, give them alternative text.
If you choose a fixed frame background, check that the text is still readable in dark mode.

Next step

Continue to Languages and translation to see where TrazoForms translations come from.