A practical WordPress form testing checklist

Prepare a small set of test requests

Choose an ordinary successful request, one with an omitted required answer and one with a format error such as an incomplete email address. Add cases for each meaningful choice or condition. For uploads, prepare harmless sample files that exercise accepted and rejected formats and sizes.

Write the expected result before testing. For example, a missing reply address should lead to guidance at the appropriate question; a valid request should produce the intended confirmation and one corresponding entry. This makes it easier to distinguish a deliberate rule from unexpected behavior.

Complete the journey without a pointer

W3C's keyboard guidance requires functionality to be operable through a keyboard interface, subject to its stated exception. Begin before the form and use the keyboard to reach questions, make choices, correct an error and submit. Check where focus goes and whether it remains visible.

For screen-reader testing, have someone familiar with the chosen assistive technology read and complete the form. Check the question names, instructions, choice groups, errors and confirmation. Record the tool and browser used. If nobody performed that test, keep the result marked Not tested rather than inferring it from a visual check.

Inspect the states people actually reach

Capture the initial form, an error state and confirmation on desktop and mobile. Include long labels and a long sample answer. Enlarge text and inspect the actual page with its theme, header and any overlays. Check that instructions remain associated visually with their question and that no action disappears off-screen.

For steps or conditions, change an earlier answer after filling later questions. Inspect the resulting route and review screen. If saved progress is enabled, open its private return link in a fresh session and finish the request. These are separate scenarios from simply moving forward through an empty preview.

Follow the submission into the team's workflow

Run a normal staging submission to check entry storage, spam handling, attachments and notifications. Confirm that the expected team member can access the entry and that people without that access cannot. If a test enters a held or spam queue, investigate the cause before describing it as a lost submission.

Verify notification details using an inbox your team controls. A saved entry and an email are separate outcomes; provider acceptance does not prove inbox placement. Check the destination, reply behavior and confirmation wording against what happened. Remove test entries and files after verification, and repeat affected checks after a meaningful change.

Using Accessible Forms

Use the plugin's review tools during editing and a normal staging submission for the full service journey.

In Free: Free provides publication checks, private keyboard and theme previews, and an accessibility test record tied to a form revision. The private previews do not create entries or send notifications.

With Pro: Test Pro steps, conditional questions, real attachments and saved progress separately. A manual record documents reported checks; it is not accessibility certification.