Create accessible surveys
About accessible surveys
An accessible survey is one that people can complete with a screen reader, with a keyboard instead of a mouse, at 200% zoom or with limited color vision. Most of the work lies in how you build the questionnaire, not in the software. LimeSurvey gives you an accessible starting point, and eight decisions on your side keep it that way.
Do you have to?
More and more often, yes. Public sector bodies in the EU have been covered for years. Since 28 June 2025, the European Accessibility Act also applies to many private businesses that sell products or services to consumers in the EU, including companies based outside the EU. The technical standard it points to, EN 301 549, adopts WCAG 2.1 level AA, so that is the practical target.
Businesses with fewer than 10 employees and under 2 million euros turnover have a limited exemption. Even where you are exempt, a survey nobody can complete is a survey with missing data. The research reason and the legal reason point the same way.
What LimeSurvey gives you
The survey pages of LimeSurvey were built against the WCAG 2.0 guidelines and tested independently: all basic question types reached level AA, with two documented exceptions, file upload and map questions.
This testing dates from 2016 and predates WCAG 2.1. Treat it as a good foundation, not as a certificate: the platform does not stop you from building an inaccessible survey on top of it.
The survey pages use the ARIA attributes screen readers rely on: aria-labelledby and aria-describedby tie the question text and help text to the input fields, aria-hidden keeps decorative elements from being announced, and aria-live reads out validation errors when they appear.
Eight decisions when you build
1. Write the question text as the label. A screen reader announces the question text when the participant reaches the input. "How satisfied were you with the training?" works. "Please rate:" followed by a separate paragraph with the real question does not, because the paragraph is never announced with the input. Put the actual question in the question text and supporting detail in the help description.
2. Prefer question types that work. These types give assistive technology the most trouble:
| Question type | Problem |
|---|---|
| File upload | Failed accessibility testing |
| Map, point on an image | Failed testing, visual by nature |
| Ranking | Drag and drop is hard or impossible without a mouse |
| Slider | The current value is hard to hear and hard to hit |
| Large arrays | A screen reader announces row and column for every cell |
| Dipolar and tripolar scales | Complex to announce and to understand |
None of them is forbidden. Where a plain List (radio), Multiple choice or Short text answers the same research question, use it. If you need a location, offer a postal code field as an alternative to a map.
3. Keep arrays small, and let them wrap. This is the biggest accessibility problem in real surveys. An array of 10 rows by 7 columns is a wall of cells with a screen reader and unusable on a phone. Split it into shorter arrays, or ask one question per row. In Presentation > Theme options > Display options, set Wrap tables to Always on, or at least Small screens. Array tables then stack into a readable layout instead of scrolling sideways.
Click Presentation, the paint bucket icon in the left toolbar (1), and set Wrap tables under Display options (2).
4. Give every image an alt text. Select the text, click the three dots in the text toolbar, choose Edit as HTML and write the alt text into the image tag:
<img src="chart.png" alt="Bar chart, satisfaction rose from 60% to 78% between 2024 and 2026">
Describe what the image tells the reader, not what it looks like, in about one sentence. Purely decorative images get an empty alt="", so they are skipped instead of announced as "image". If a question asks about an image, the question text must describe it too, or the question cannot be answered without sight. See Format text in the survey editor.
5. Check your color contrast, do not trust your eyes. WCAG 2.1 AA asks for a contrast of 4.5:1 for normal text and 3:1 for large text and interface elements. Set your colors once in Presentation > Theme options (Font color, Background color, Question background color, Theme color) and test the combinations with the free WebAIM Contrast Checker. Light gray on white is the most common failure, usually from a brand palette nobody checked. Never let color carry meaning on its own: "Select the option marked in green" excludes color-blind participants, so say it in words.
6. Set the survey language, and consider plain language. The language tells a screen reader which pronunciation rules to use. A German survey read with English pronunciation is close to unintelligible. Set the base language in Settings > General, and translate properly instead of mixing languages in one version. German surveys can also offer German (easy): pair it with a simplified set of questions and you cover cognitive accessibility as well.
7. Show one thing at a time. In Settings > General, Format decides how much appears on one page. Question by question is the kindest setting for screen reader users, for people with cognitive disabilities and on phones: less to scan, less to get lost in, and errors stay next to the question that caused them. All in one is the hardest to navigate.
8. Say what is required, in words. Mandatory questions are marked visually. Make sure the question text or help description says so too, so it is announced and not only seen. The same goes for input rules: "Enter a date as DD/MM/YYYY" belongs in the help description, not only in an error message.
Note: Custom JavaScript is the most common way to break an accessible survey. Scripted show and hide, custom widgets and automatic page changes often trap the keyboard or change the page without the screen reader noticing. Use the conditions and question types of LimeSurvey wherever they do the job.
Test your survey before you send it
Three checks catch most problems, and none needs special software. Do them in the preview, before you activate the survey.
Keyboard only. Put the mouse away. Tab moves between fields, the arrow keys choose within a radio group or an array row, Space and Enter select. You must reach every field, always see which one has the focus, and reach the Next button. If you get stuck anywhere, that is a keyboard trap, and a blocker.
Zoom to 200%. Nothing may be cut off or overlap, and nothing may need sideways scrolling.
A screen reader. Five minutes with VoiceOver (Cmd+F5 on a Mac) or the free NVDA on Windows teach you more than any checklist. Listen for inputs announced without their question and array cells announced without their row.
Fix what you find and test again. All of this costs far less before activation than after.
Share your survey accessibly
- A plain survey link is the most reliable option. Participants get the full page, their own browser zoom and their own assistive technology.
- Embedding adds risk. A survey in an iframe inherits the problems of the host page: its focus order, its zoom behavior and its own accessibility failures. If you embed, test the embedded version separately.
- A QR code is not an access method. Always print or send the link next to it, for anyone who cannot scan.
- Write accessible invitations. Use meaningful link text instead of a bare URL, and put no information only into an image.
Tools worth having
LimeSurvey has no built-in accessibility checker. These free tools fill the gap:
- WebAIM Contrast Checker: checks your theme colors.
- WAVE: a first check of your live survey link.
- axe DevTools: a browser extension that finds ARIA and structure problems.
- NVDA (Windows) or VoiceOver (macOS and iOS): the only way to hear what you built.
Next steps
FAQ
Does LimeSurvey check my survey for accessibility?
No. Test your survey with the keyboard, at 200% zoom and with a screen reader, and run WAVE or axe DevTools on the live survey.
Which question types should I avoid?
File upload and map questions failed accessibility testing. Ranking, sliders, large arrays and dipolar scales are hard to use with a keyboard or a screen reader. Where List (radio), Multiple choice or Short text answer the same question, use them.
Where can I read the accessibility notes of LimeSurvey?
The LimeSurvey manual has a page on accessibility with the test results and the ARIA implementation: Accessibility in the LimeSurvey manual.