The accessible survey: forms everyone can finish

You can write clean questions and still lose the answer. If a respondent cannot see the label, or cannot tell which radio button they just selected, they do not send you bad data. They send you nothing. They are gone before the first chart loads. Accessibility is the part of survey design that decides who is even able to reply.

An inaccessible survey biases your results

About one in six people lives with a disability. More still are reading your form on a phone in bright sunlight, or filling it in one-handed on a train. Every one of them is a respondent you invited. When the form only works with a mouse and decent eyesight, the people it turns away are not a random slice. They differ from the people who get through, so their absence bends the result in a direction you cannot see or correct later. That is nonresponse bias, and it sits right next to the low-quality answers you already screen out: both are reasons a clean-looking export can still mislead you.

There is a legal side to this too. The European Accessibility Act has applied since 28 June 2025 and pulls many digital services toward a technical standard the rest of the field already uses: WCAG, the Web Content Accessibility Guidelines. Section 508 and the ADA do the same in the United States. The current version is WCAG 2.2, a W3C recommendation revised in December 2024. Level AA is what almost everyone means when they say "accessible". You do not have to memorise it. The checks below map onto it.

Give every field a real label

The most common survey-form mistake is using the placeholder as the label: a box with faint grey text reading "Your email" and nothing above it. It looks clean. Then the respondent starts typing, the hint disappears, and anyone who paused to think has lost the one clue about what the field wanted. The grey-on-white usually fails contrast too. Some screen readers never announce placeholder text at all, so the field comes out as "edit, blank".

A label is a visible piece of text tied to its input. Clicking it focuses the field, and a screen reader reads the two together. Keep it above the box. If you want to show a format or an example, put it in separate help text near the field. This is WCAG 3.3.2, and it costs one line of markup.

Matrix questions are where screen readers fall apart

A grid of statements down the side and a rating scale across the top is efficient on a wide monitor and painful through a screen reader. Sighted respondents glance at the column headings once, then work down the rows. A screen reader does not glance. It lands on the third radio button in row four and, unless you built the grid carefully, announces "radio button, not checked" with no hint of which statement or which point on the scale that is.

Every option in the grid needs an accessible name that carries both pieces: the row it belongs to and the value it represents. "The dashboard is easy to navigate, strongly agree" can be answered. A bare radio cannot. If you cannot guarantee that, split the matrix into separate questions, one statement each. That reads better on a phone too, where the grid was going to collapse anyway. More scrolling, far fewer misfires. Clear wording helps here: a matrix built from questions that each map to one decision is shorter to begin with.

Make every scale work from the keyboard

Star ratings and emoji sliders are usually the prettiest controls in a survey. They are also the least operable. Too often they are clickable images or bare divs with a click handler, so they work with a mouse and nothing else. A keyboard user tabs straight past them.

WCAG 2.1.1 is blunt: everything has to work from the keyboard. The reliable way to build a rating question is with real radio inputs styled to look like stars or numbers. The browser then gives you keyboard focus and arrow-key selection for free. Sliders are the hardest to get right, since the value has to be announced as it changes and reachable in single steps. For a 0-to-10 recommendation score, plain radios beat a slider every time. Take your hand off the mouse and try the question yourself.

Group the options so the question comes with them

Radio buttons and checkboxes are a set, and they have to be announced as one. When a group of options is not tied to its question in the markup, a screen reader reads each choice on its own: "Under 18. 18 to 24. 25 to 34." The person hears a list of ages with no idea what is being asked. Wrap each set so the question text becomes the group's name and the options sit inside it. Every option is then read as "How old are you, 25 to 34" and the question travels with the answer. That is the mechanics behind WCAG 1.3.1, invisible until someone cannot see the layout that was carrying the meaning.

Colour must never be the only signal

Colour is a hint on top of the message, and it disappears for a lot of people. A required field marked only with a red asterisk, or an error shown only by a red border, does not exist for a colour-blind respondent. Red-green colour blindness alone runs to about one in twelve men. Put a word next to the colour: write "required" rather than a lone asterisk, and mark a selected option with a tick rather than only a colour change. Check contrast while you are at it. Body text needs a ratio of at least 4.5 to 1 against its background under WCAG 1.4.3, and that faint placeholder grey almost never gets there.

Write errors that say what to fix

The worst moment in an inaccessible form: you cannot move on and you cannot tell why. A required question was missed, you press next, and the page sits there, or it scrolls somewhere you are not looking. For a screen-reader user who heard no announcement, the survey is now broken with no explanation.

Move focus to the first field that failed. A keyboard user then lands on the problem instead of hunting for it. Name the field and the fix in the error message itself: "Question 4 needs an answer before you can continue" beats "invalid input" every time. That is what WCAG 3.3.1 and 3.3.3 ask for: identify the error, suggest the fix.

Give revealed questions a voice

Conditional logic is one of the best things you can do for response quality, and one of the easiest to make inaccessible. When an answer reveals a follow-up, a sighted respondent sees it slide in. A screen-reader user, by default, does not: focus stays where it was, nothing gets announced, and an entire question can pass by unheard. If you branch a survey, make the new question announce itself and move focus to it. Keep hidden questions out of the tab order until they apply, so nobody tabs into an offscreen field. The same conditional logic and feedback that lifts response quality is what strands people when the reveal is silent.

Keep focus visible and in order

Tab order has to follow the order people read, so focus moves down the form the way the eye does, not off to some stray button. And the focused element needs a visible outline. Browsers give you one by default, and too many designs strip it out, leaving a keyboard user with no cursor. WCAG 2.2 added a related rule (2.4.11): whatever you focus must not be hidden behind a sticky header or a cookie banner. If your survey has a fixed top bar, make a focused field scroll clear of it.

Respect people's time and their thumbs

Some survey panels put a timer on a page or expire the session after a fixed period. A hard timeout punishes people who need longer: someone using a switch device, or someone reading every line through a screen reader. WCAG 2.2.1 asks you to warn before time runs out and let people extend it. On phones there is a physical problem too. A dense grid of tiny radio buttons is a target no thumb can hit cleanly, and WCAG 2.2 set a floor of 24 by 24 CSS pixels for an interactive target in criterion 2.5.8. Give the options room. If you use a drag-to-rank question, add a way to reorder without dragging, because a drag gesture is a barrier on its own.

Let the browser fill the boring fields

Demographic questions ask for the same things every form asks for: name, email, postcode, country. WCAG 1.3.5 says to tag those fields with their purpose, so the browser and any assistive tool can autofill them and save real typing for someone who finds it hard. WCAG 2.2 added a companion rule, 3.3.7, against making people re-enter information they already gave you in the same flow. If your survey collected an email on page one, do not ask for it again on page four. Every field you can prefill or drop is one fewer thing to fight through.

Test it the way a respondent would

This only works if you actually try it.

• Unplug the mouse and reach every question, every option and the submit button with Tab and the arrow keys.
• Turn on VoiceOver on a Mac or NVDA on Windows and complete one full run with the screen off.
• Zoom the page to 200 percent and see what overflows or hides.
• Run axe or Lighthouse for the mechanical checks, then trust the manual pass over the automated score.

Automated tools catch maybe a third of the issues. The rest need a person at the keyboard. Do this before launch, because once a survey is live its wording and structure are effectively frozen, and a fix mid-flight splits your data.