Testing accessible survey forms: routes, errors & success

Test the respondent-facing survey from its link through every question, error and completion screen; a template or vendor accessibility statement cannot show how the rendered questions, theme and settings work for respondents. Use WCAG 2.2 as the reference, and record expected results, harmless answers and what happens. The keyboard-focus check maps to 2.4.7 Focus Visible (Level AA).

Treat this as a first review: W3C describes simple checks as a rough indication, not a complete evaluation. More assessment is needed for a definitive, comprehensive evaluation.

Key WCAG 2.2 criteria for accessible surveys

Prepare routes that reveal barriers

Include a required choice, an optional text answer, a question shown only on one route and a final Submit action. If the survey uses a rating scale or matrix, include it in the check. State what each scale point means; respondents should not have to guess whether “1” is best or worst.

Prepare the shortest and longest legitimate routes, plus a route with an invalid or missing answer. Use the respondent-facing link or a safe staging equivalent. Editor preview controls can differ from the page a respondent receives.

Follow each route with keyboard and screen reader

Starting at the survey link, use a keyboard to reach every question, answer option, navigation control and Submit button. Check that focus is visible, follows a sensible order and does not become trapped when a conditional question appears. WCAG 2.2 criterion 2.4.7, Focus Visible (Level AA), requires a mode where keyboard focus is visible.

If Back is available, change an earlier answer and check that the new route makes sense. Check that focus remains visible as you move through the rendered survey.

Use a screen reader to hear how each question, option and required instruction is announced. Check that each control has an announced label that describes its purpose; visually nearby text alone does not establish that a label is associated with the control.

Related choices should have a clear shared question. W3C guidance recommends grouping related controls visually and in the code, for example with fieldset and legend. Check whether a newly displayed question is discoverable and whether progress or a change of page is understandable.

One screen reader session is evidence about that setup, not a certification across devices or assistive technologies. Include respondents with relevant access needs in a later review where possible.

Check errors and completion in context

Leave a required answer blank and enter an invalid value where validation is available. Check whether the message identifies the question, explains a correction and can be found with keyboard and screen reader. Confirm that other answers remain where appropriate.

W3C recommends concise, clear error messages with simple instructions for resolving the problem. If errors are listed, check that each refers to the relevant control’s label, explains the error and how to correct it, and links to that control.

Submit a valid route and look for a clear success message. W3C form guidance recommends feedback that confirms whether submission succeeded or errors occurred.

Repeat the survey on a narrow phone screen and with enlarged text. Look for clipped answer choices, instructions that appear too late and controls that cannot be reached. If the survey is embedded on a site, check the complete embedded page as well as the standalone survey.

After a correction, repeat the affected route from its start. If an intended respondent still cannot complete an essential survey, offer another accessible way to respond and explain how it handles their information. Do not describe the survey as accessible because one scan or one path passed.

Error messaging: expected vs. observed