Create Accessible Surveys (WCAG Guide)

Responsly forms meet WCAG 2.1 AA and WCAG 2.2 AA. This guide shows the settings that keep them there and fixes the issues that can still stop someone from completing your survey with a keyboard, screen reader, zoom, or low-vision settings.

Run it before publishing — whether you answer to WCAG 2.1 AA, WCAG 2.2 AA or Section 508, or simply want a form everyone can finish.

What the platform gives you

Every question type works with a keyboard (Tab, arrows, Space and Enter; Enter also moves to the next question). Screen readers hear each question’s title, description, required state and error message, and the next question is announced (“Question 3 of 10”). The page carries the form’s language, so screen readers pronounce it correctly. With Higher contrast on, texts and interface elements meet the 4.5:1 and 3:1 minimums.

The rest depends on how you build the questionnaire — question types, your own colors, image descriptions and a few form settings. That is what Make a form meet WCAG 2.1 AA and 2.2 AA and the checklist below are for. Start from a form or a survey and keep these settings as you design it.

Why accessible forms matter

Accessible forms are not only about compliance. They directly affect completion rate, response quality, and trust.

• Higher completion rates: more respondents can finish the survey without confusion or friction.
• Better data quality: clear labels and instructions reduce wrong answers and drop-off.
• Lower accessibility risk: your survey is easier to review against WCAG-based requirements.
• Better user experience for everyone: readable design and predictable navigation help all users, not only people using assistive technology.

In practice, accessible survey design often improves usability for mobile users, older users, and anyone completing a form in less-than-ideal conditions.

Accessibility principles to use as your checklist

You do not need to memorize formal standards language to improve form accessibility. Start with these four principles on every survey page:

1. Perceivable: text, controls, and feedback are easy to see, read, or hear.
2. Operable: users can navigate and complete the survey with keyboard-only input.
3. Understandable: questions, instructions, and error messages are clear.
4. Robust: the survey works reliably with assistive technologies and common browsers.

If one of these areas fails, the survey may still look correct visually but become difficult or impossible to complete for part of your audience.

Troubleshooting: common accessibility issues in forms

Issue 1: Low contrast makes questions hard to read

Symptoms

• Respondents say labels are hard to read.
• Buttons blend into the background.
• Mobile users need to zoom to understand the form.

How to fix

1. Use strong contrast between text and background.
2. Make buttons, links, and form controls clearly visible in all states.
3. Do not use color alone to communicate errors, status, or required fields.
4. Recheck readability on both desktop and mobile preview.

Check contrast with the accessibility audit

You do not need a separate contrast checker. When you create or edit a style in the Design tab, Responsly checks the colors the survey actually displays and shows the result under Accessibility audit:

• It measures four pairs: question text on the page background, answer text on the page background, answer text on answer fields, and button text on the button.
• It reports the weakest pair: WCAG AAA contrast OK (7:1 or more), WCAG AA contrast OK (4.5:1 or more), or a Low contrast or Very low contrast warning.
• Click the question mark next to the result to see the exact ratio and the level to aim for.

If you see a warning, darken the text or lighten the background until the audit reaches at least WCAG AA.

Turn on Higher contrast. Above the audit in the Design tab, Higher contrast darkens what the colors alone do not cover: the edges of fields and answers, placeholders, secondary texts (the page counter, scale labels, the estimated time), the error badge, and the chosen answer and keyboard focus. The colors of the style stay as they are. Without it, the default styles keep lighter placeholders and field edges, which fall below the WCAG minimums. With a background image, the audit includes the brightness setting but not the image itself, so check text over busy images by eye. More on styles: Theme design for surveys.

Expected result

Questions, answer options, and action buttons remain readable without zooming or guessing.

Issue 2: Screen readers do not provide enough context

Symptoms

• A field is announced as “edit field” without meaning.
• A respondent can tab through the survey but does not understand what each input is for.
• Image-based questions are confusing without text alternatives.

How to fix

1. Use explicit question labels for every field.
2. Keep placeholder text as support, not as the only instruction.
3. Add short helper text where the expected answer is not obvious.
4. Use descriptive alt text or a text equivalent when media is necessary for answering.
5. Replace vague link text like “click here” with specific action text.
6. If you use custom HTML or embeds, keep the structure semantic and avoid breaking accessible naming.

Expected result

A screen reader user can identify what each field means, what action is required, and what happens next.

Screen reader testing should include at least one real assistive technology pass before publish, for example NVDA, JAWS, VoiceOver, or TalkBack.

Issue 3: Keyboard navigation is broken

Symptoms

• The Tab key skips inputs or buttons.
• Focus disappears while moving through the survey.
• A respondent cannot reach the submit button without a mouse.

How to fix

1. Test the full survey using only keyboard: Tab, Shift+Tab, Enter, and Space.
2. Confirm that all interactive elements are reachable in a logical order.
3. Make sure the visible focus state is easy to see.
4. Avoid custom scripts or embed code that trap focus or reorder interactive elements.
5. Compare the embedded survey with the direct Responsly share link to see where the problem starts.

Responsly forms show a clear ring around the answer that has the keyboard focus. With Keyboard hints on, each answer also shows the letter that picks it, and “press Enter ↵” appears next to the button:

See also: Website embedding.

Expected result

Respondents can start, navigate, answer, review, and submit the survey without using a mouse.

Issue 4: Required fields are unclear or frustrating

Symptoms

• Respondents submit the form and get repeated validation errors.
• Users do not know which questions are required.
• Error feedback appears too late or is too vague.

How to fix

1. Mark required questions clearly and consistently.
2. Add short instruction text near the start of the survey if required fields are used throughout.
3. Write specific validation messages that explain both the problem and the fix.
4. Avoid making too many questions mandatory unless they are truly necessary.
5. Make sure required state is communicated in more than one way, not by color alone.

Expected result

Users understand what must be completed before submit and can recover quickly if an error appears.

Issue 5: The content is technically correct but still hard to understand

Symptoms

• Drop-off is higher in longer or more complex sections.
• Respondents send clarifying questions.
• Users hesitate on questions that combine multiple requests at once.

How to fix

1. Rewrite long prompts in plain language.
2. Split multi-part questions into short, separate questions.
3. Avoid internal jargon, abbreviations without context, and ambiguous wording.
4. Group related questions into a clear step-by-step flow.
5. Keep answer choices short and easy to scan.

For setup basics, see How to create a survey.

Expected result

Respondents move through the form faster and with fewer misunderstandings.

Issue 6: The direct survey works, but the embedded version does not

Symptoms

• The hosted survey behaves correctly, but the embedded version does not.
• Focus order changes after embedding.
• Styles or scripts from the parent website reduce readability or break navigation.

How to fix

1. Test the direct survey URL first.
2. Test the embedded version separately on the target page.
3. Check whether custom CSS changes contrast, spacing, or focus visibility.
4. Review scripts that manipulate modals, containers, scrolling, or tab order.
5. If the direct link works and the embed fails, treat the host page as the source of the issue.

Expected result

You can isolate whether the accessibility issue comes from the survey itself or from the website environment around it.

Question types that need extra care

Make a form meet WCAG 2.1 AA and 2.2 AA

Responsly forms meet WCAG 2.1 AA and WCAG 2.2 AA with these settings:

1. Design → Higher contrast: on. Check that the Accessibility audit shows WCAG AA or AAA.

2. Settings → Disable One-click: on. With One-click, choosing an answer moves to the next question at once, without warning.

3. Settings → Time limit for completing the form: off. The time runs out without a warning and cannot be extended.

4. End page → Automatic redirect: off. It moves the respondent to another page after a few seconds, with no way to stay. Use Add redirect button instead, so the respondent decides when to go.

5. Settings → Hide Back button: off. Respondents can go back and correct an answer.

6. Picture choice: keep the labels visible (leave Hide labels off) and turn on Enlarge pictures when details matter. A magnifier button shows each picture larger; the answer is still chosen on the page.

   

   

   

7. Images and videos: describe what matters in an image in the question text, and use videos with captions.

8. Signature question: it needs a mouse or a finger. When a signature is required, offer another way too, for example a text question for the full name.

9. Settings → Keyboard hints (optional): shows the letter that picks each answer and “press Enter ↵” next to the buttons, on computers.

   

What the form does on its own: every question type works with a keyboard (Tab, arrows, Space and Enter; Enter also moves to the next question), screen readers hear each question’s title, description, required state and errors, the next question is announced (“Question 3 of 10”), and the page is in the form’s language, so screen readers pronounce it correctly.

Pre-publish accessibility checklist

Before launching, run this quick QA pass:

• Confirm Higher contrast is on and the Accessibility audit in the Design tab shows WCAG AA or AAA, and that text is readable on desktop and mobile.
• Check that One-click, the time limit and the automatic redirect are off.
• Navigate the complete survey using keyboard only.
• Verify that every question has a clear label.
• Check helper text, required state, and validation messages.
• Confirm images or media have a useful text alternative when needed.
• Test both the direct survey link and the embedded version.
• Complete one full submission as a new respondent from start to finish.
• Run at least one screen reader pass on a real device.

If your team uses accessibility goals, save this checklist as part of your normal survey QA process instead of treating it as a final review step.

For end-to-end checks, see Testing the survey.

Common mistakes that reduce accessibility

• Choosing branding styles that reduce readability.
• Using placeholder text instead of clear labels.
• Publishing without keyboard-only testing.
• Writing long, multi-purpose questions.
• Using vague error messages.
• Assuming the embedded version behaves exactly like the direct-link version.
• Adding custom code before validating the basic survey flow.

What a good accessible survey looks like

A survey that holds up in real conditions usually has:

• clear labels for every field,
• readable contrast,
• visible keyboard focus,
• short instructions,
• specific validation feedback,
• logical question order,
• testing in both hosted and embedded environments.

The platform covers the technical side; these are the decisions it cannot make for you. Test with real assistive technology before publishing.

Final recommendation

Treat accessibility as part of survey QA, not as a final cosmetic pass.

The best accessible online forms are clear, easy to navigate, screen reader friendly, keyboard accessible, and tested in real conditions before they go live.

FAQ