If your survey goes out to the public, to students, to patients or to staff, some of the people receiving it will have a visual, motor or cognitive disability. Universities, hospitals and public bodies are often required to show their research is accessible before it is approved.
Some of this PaperSurvey handles for you. The rest is in how you design the survey, and this article covers both.
What PaperSurvey does automatically
This section is about the survey a respondent fills in on the web, which is the part an accessibility office normally tests.
Readable colours, whatever brand colour you pick. A pale brand colour can leave button text, headings or a checked option unreadable. Where your colour is used for text, we move it along its own shade just far enough to meet the WCAG 2.1 AA contrast minimum, so it still reads as your colour. Fills, borders and tints keep the exact value you chose.
Readable defaults everywhere else. Helper text, placeholder text, validation messages and the outlines of inputs, checkboxes and radio buttons all meet the AA minimum, rather than the lighter greys most form libraries ship with.
A contrast warning in the editor. If you pick heading colours that do not contrast enough with each other, the editor tells you before you publish and suggests one that works.
Keyboard access all the way through. Every control can be reached and operated with Tab, the arrow keys, space and Enter, including the drawing area alternative described below. There is a skip link at the top of each page so a keyboard user does not have to tab past the header on every page.
A focus outline you can actually see. The outline marking where you are is a fixed, high contrast one. It does not get paler when your brand colour is pale.
Focus and announcements that keep up with the form. Moving to the next page puts you at the top of that page instead of leaving you at the bottom of the last one, and says which page you are on. If a submission fails validation, the error is announced and you are taken to the first question that needs attention, rather than silently scrolled.
Questions, answers and errors that are properly connected. Each question is tied to its input, required questions are marked both visibly and for assistive technology, and a validation message is linked to the question it belongs to. In a grid, every checkbox and radio button is named by its row and its column, so a screen reader announces "Friday, Morning" rather than an unlabelled control.
A typed alternative to the signature box. Signing by drawing needs a mouse, a stylus or a finger. Anyone who cannot use one can type their name instead, and it is stored the same way.
The correct language on the page, including right to left where the script genuinely reads that way, so a screen reader uses the right voice and pronunciation.
Spam protection that does not put a puzzle in front of anyone. Web surveys are protected by checks a respondent never sees or interacts with. A CAPTCHA is an accessibility barrier in its own right, so there is not one by default. If a particular survey starts attracting spam you can switch on an extra challenge for that survey alone, in Web Survey settings. Switching it on has a privacy consequence as well as an accessibility one: the challenge is provided by Cloudflare, so each respondent's browser contacts them and passes their IP address. If you publish a privacy notice for the survey, or you hold a data processing agreement listing who handles respondent data, add Cloudflare to it before turning this on.
Designing an accessible web survey
Write the question so it stands alone. A screen reader reads the question text; it does not convey layout. "Which of these applies?" only works if the reader can see what "these" refers to. Name it in the question.
Use the helper text field for instructions, not a heading placed above the question. Helper text is read out as part of the question; a separate heading may not be.
Do not rely on colour alone to carry meaning. If red means a problem, also say "problem" in words. Around one man in twelve has some form of colour vision deficiency.
Keep required questions genuinely required. Every required question a respondent cannot answer is a dead end, and someone using assistive technology hits those dead ends most often.
Be careful with long grids. A grid with many rows and columns is one of the hardest structures to complete with a screen reader. If a grid is long, consider splitting it into separate questions.
Give a plain contact route. Include an email address or phone number in the survey introduction for someone who cannot complete it as presented. This is often the single thing an ethics committee or accessibility office looks for.
Designing an accessible paper survey
Paper has its own constraints, and small changes make a large difference.
Increase the font size. Large print usually means at least 16pt, and 18pt or larger for readers with low vision. You can set the font size for the whole survey in the design settings.
Increase the checkbox size. Larger boxes are easier to see and easier to mark accurately for someone with a tremor or limited fine motor control. Anything from 5mm upwards is a noticeable improvement, and it also helps recognition accuracy.
Keep contrast high on paper. Black text on white paper is the most readable combination. Coloured backgrounds behind text, and light grey text, are both much harder to read, and they also reduce scanning accuracy.
Give more writing space. Open-ended questions with generous lines are easier for someone with a motor impairment, and handwriting that stays inside the box is transcribed more accurately.
Avoid dense two-column layouts where the reading order is not obvious.
Offer a large-print version. You can create a second version of the same survey with a larger font and larger boxes. Both versions collect into the same dataset, so you do not have to merge anything afterwards.
Offering an alternative format
The most robust approach is to offer the same survey more than one way. PaperSurvey lets you collect on paper and on the web from the same survey, and every response lands in the same place.
A common pattern that works well:
- The web survey, for anyone using a screen reader or their own assistive technology, which is usually the most accessible option because the respondent already has their device set up the way they need it.
- A standard paper version.
- A large-print paper version for anyone who asks.
- A way to complete the survey with help, for example a member of staff entering answers on the respondent's behalf.
State in the invitation that alternative formats are available and how to ask for one.
Testing before you send
Try the web survey with the keyboard only. Put the mouse aside and complete it with Tab, arrow keys, space and Enter. If you get stuck, so will someone who has no choice.
Zoom the page to 200 per cent. Text should reflow and stay readable rather than overlapping or disappearing.
Print the paper version and read it at arm's length. Small text and small boxes are much more obvious on paper than on screen.
Ask someone else to complete it. The fastest way to find the confusing question is to watch one person try to answer it.
Proving it, if somebody asks
An ethics committee, an accessibility office or a procurement team may want more than an assurance. There are three levels of evidence, and it is worth knowing what each one is actually worth.
Run an automated checker on your live survey. Open the survey link in Chrome or Firefox and run one of these against it:
- axe DevTools, a free browser extension from Deque
- WAVE, a free browser extension from WebAIM
- Lighthouse, already built into Chrome under the Accessibility category
Each produces a report naming the rule, the element and the fix, and you can save or print it. Point it at your own survey link rather than at our marketing pages, because what matters is the page your respondents actually open.
Be careful how you describe the result. Automated tools reliably catch only a portion of the problem, commonly put at around a third: they can see a missing label or a failing colour, and they cannot tell whether your question text makes sense out of context, whether the tab order is logical, or whether a grid is comprehensible when read aloud. A clean automated report is worth having and is not the same as a conformance claim.
Do a short manual pass, which is where the rest of the issues are. Fifteen minutes covers most of it:
- Complete the survey using only the keyboard. Tab, Shift and Tab, arrow keys, space and Enter. If you cannot reach a control or cannot see where you are, neither can your respondent.
- Zoom the browser to 200 per cent and check nothing is cut off or overlapping.
- Turn on the screen reader you already have. VoiceOver on a Mac is Command and F5, Narrator on Windows is Ctrl, Windows key and Enter. Listen to whether each question announces the text you would expect.
Write down what you did and what you found. A short note saying "completed by keyboard only and with VoiceOver on 4 March, no blocking issues" is more convincing to an accessibility office than a tool report, because it is the test they would have run themselves.
Ask us for what we can evidence. We can tell you which parts of the respondent form have been tested and against which success criteria, and what we know is still outstanding. See below.
If your organisation requires a formal accessibility report
Universities and public bodies in the United States often ask suppliers for a VPAT, an accessibility conformance report against Section 508 and WCAG. Write to hello@papersurvey.io with what your procurement process needs and we will tell you what we can provide and where we currently stand.
We would rather tell you plainly what is and is not covered than hand over a report that does not survive testing.
What this covers, and what it does not
The work described above is about the survey your respondents fill in. That is deliberate: it is the part a person outside your organisation has to be able to use, and the part an accessibility office will test.
The area where you build surveys and read results is a different matter. It is used by your own staff rather than by respondents, and it has not been through the same review. If somebody on your team needs to build or analyse surveys with a screen reader or by keyboard alone, write to us first and tell us what they need, so we can tell you honestly whether it will work for them today.