Check WordPress form accessibility

A form can look polished and still block the person trying to use it. A missing label, invisible keyboard focus, vague error, or silent confirmation can turn a simple request into an abandoned task.

This WordPress form accessibility checklist gives site owners a practical QA pass for labels, keyboard use, errors, confirmations, zoom, and assistive technology. It is a release check, not a substitute for a full accessibility audit.

Start with the task, not the form builder

Name what a visitor is trying to finish: request a quote, report a problem, apply for access, or ask a question. Then test the complete task on the real page where the form appears.

Do not stop at the editor preview. Theme styles, page-builder containers, cookie banners, sticky headers, caching, and third-party scripts can change the experience after the form is embedded.

The accessibility check ends after the visitor receives a clear result, not after the Submit button is pressed.

Complete the form with a keyboard

Reload the page and put the mouse aside. Use Tab and Shift+Tab to move through the form. Use Space for checkboxes and buttons where appropriate, arrow keys for grouped choices, and Enter to submit when the form supports it.

• Focus should move in the same order the questions are read.
• Every focused control should have a visible indicator.
• Conditional questions should appear in a place the visitor can discover.
• Date pickers, upload controls, and custom selects must work without a pointer.
• A keyboard user should not become trapped inside a widget or modal.

If the order is wrong, fix the structure rather than adding positive `tabindex` values to force a new route. Re-test after every conditional-logic change.

Check labels and instructions in context

Each control needs a label that explains its purpose. Placeholder text is not a dependable replacement: it disappears when someone types, may have weak contrast, and may not give assistive technology the same useful relationship.

The W3C guidance on labeling controls explains why labels should be associated with their fields and how that connection helps screen readers, speech input, and people who benefit from a larger clickable target.

• Required fields should be identified in text, not by color or an asterisk alone.
• Format rules should appear before the error happens when the rule is not obvious.
• Related radio buttons and checkboxes should have a clear group label.
• Help text should be specific enough to change the answer, not generic reassurance.

Clear labels also make staff review easier. If the same question produces unclear answers, use the guide to fixing form questions that AI keeps flagging as an improvement loop, not as proof of accessibility.

Trigger every important error

Submit the form empty. Enter an invalid email address. Exceed a length limit. Try a blocked upload type. Skip a required conditional field. Each error should explain what happened and how to fix it.

The W3C input-validation tutorial recommends giving errors in text, identifying the affected fields, and offering correction guidance. Do not rely on a red border or an icon alone.

The guide to writing WordPress form errors people can fix turns that principle into a practical copy review.

• Move or announce focus so the visitor can find the error summary or first invalid field.
• Keep valid answers when the form reloads.
• Connect each field-level message to its control.
• Write a correction, such as “Enter a date in MM/DD/YYYY,” instead of “Invalid value.”

Verify the success state

A successful submission needs a visible and programmatically discoverable result. The visitor should know that the form was received, what happens next, and whether a copy was sent.

The W3C user-notification guidance covers feedback after submission and errors. Test the confirmation with the keyboard and a screen reader. If the message appears above the viewport or inside a region that is not announced, a visitor may submit again because nothing seemed to happen.

Also check failure states outside the form itself: a blocked network request, an expired nonce, a server error, or an unavailable integration. A technical message should not expose stack traces, secrets, or private configuration.

Test zoom, reflow, and mobile input

At desktop width, zoom to 200 percent and complete the form again. Text, labels, errors, and buttons should remain readable without horizontal scrolling for the main task. On a narrow screen, check that controls fit the viewport and that the on-screen keyboard does not hide the active field or Submit button.

• Long labels and error text should wrap without covering controls.
• Tap targets should have enough space to avoid accidental choices.
• Orientation changes should not reset completed answers.
• Autofill should not make labels disappear or text unreadable.

Use assistive technology for a bounded check

Run the form with a screen reader available to your team. Listen for the form name or heading, field label, required state, instructions, current value, error, and final confirmation. Try speech input if custom controls are part of the critical path.

One tool, browser, or tester cannot prove that a form meets every user’s needs. Record what you tested, the browser and assistive technology version, the tasks completed, and the issues still open. The WordPress Accessibility Handbook is a useful reference for broader WordPress work.

Keep AI review in the right role

AI can help review submitted content after the form itself works. For example, Content Quality Validation can assess configured content criteria, and Missing Information Review can flag gaps in a supported submission.

Neither result proves keyboard access, correct labeling, screen-reader output, contrast, focus behavior, or legal compliance. Keep the original submission visible and route accessibility decisions to people with the right expertise.

A 30-minute release check

1. Complete one valid submission with only the keyboard.
2. Read every label, instruction, choice group, and button out of context.
3. Trigger required, format, length, and upload errors.
4. Verify focus and announcements for errors and success.
5. Repeat the task at 200 percent zoom and a narrow mobile width.
6. Run a bounded screen-reader check and record the exact setup.
7. Re-test after any form, theme, script, cache, or plugin change.

Add this pass to the same release routine you use to test form automation before client rollout. The WordPress.org listing remains the current source for Sentient Forms support boundaries.