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 colour vision. Most of the work is in how you build the questionnaire, not in the software — LimeSurvey gives you an accessible starting point, and about eight decisions on your side keep it that way.
Increasingly, 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 selling products or services to EU consumers — 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 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.
LimeSurvey's survey pages were built against the WCAG 2.0 guidelines and independently tested: all basic question types reached level AA, with two documented exceptions — file upload and map questions, which did not pass.
Be aware that this testing dates from 2016 and predates WCAG 2.1. Treat it as a good foundation rather than a certificate: the platform will not stop you from building an inaccessible survey on top of it.
Under the hood the survey pages use the ARIA attributes screen readers rely on: aria-labelledby and aria-describedby to tie a question's text and help text to its input fields, aria-hidden to keep decorative elements from being announced, and aria-live so validation errors are read out when they appear.
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 carrying the real question does not — the paragraph is never announced with the input. Put the actual question in the question title, and supporting detail in the help description.
2. Prefer question types that work. The ones that give assistive technology the most trouble:
| Question type | Problem |
|---|---|
| File upload | Failed accessibility testing |
| Map / point-on-image | Failed testing; inherently visual |
| Ranking | Drag-and-drop is hard or impossible without a mouse |
| Slider | Hard to hear the current value and hard to hit precisely |
| Large arrays | A screen reader must announce row and column for every cell |
| Dipolar / tripolar scales | Complex to announce and to understand |
None of these are forbidden. But where a plain List (radio), Multiple choice or Short text answers the same research question, use it. If you need a location, offer a postcode text field as an alternative to a map.
3. Keep arrays small, and let them wrap. This is the single biggest accessibility problem in real surveys. A 10×7 array 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 — it reflows array tables into a stacked, readable layout instead of forcing sideways scrolling.
4. Give every image an alt text. Select the text, open ⋮ → Edit as HTML, and write it in directly:
<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. Keep it to about a sentence. Purely decorative images take an empty alt="" so they are skipped rather than announced as "image". And if a question asks about an image, the question text must describe it too — otherwise the question cannot be answered without sight.
5. Check your colour contrast, don't trust your eyes. WCAG 2.1 AA asks for 4.5:1 for normal text and 3:1 for large text and interface components. Set your palette once in Presentation → Theme options (Font colour, Background colour, Question background colour, Theme colour), then test the combinations with the free WebAIM Contrast Checker. Light grey on white is the most common failure, and it usually comes from a brand palette that was never checked.
Separately: never let colour carry meaning on its own. "Select the option marked in green" excludes colour-blind participants — say it in words.
6. Set the survey language, and consider plain language. The language attribute tells a screen reader which pronunciation rules to use; a German survey announced with English pronunciation is close to unintelligible. Set the base language in Settings → General, and translate properly rather than mixing languages in one version. German surveys can additionally offer German (easy) — pair it with a genuinely simplified set of questions and you have covered cognitive accessibility as well.
7. Show one thing at a time. In Settings → General, the survey Format controls how much appears at once. 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 also says so, so it is announced and not merely seen. Same for input rules — "Enter a date as DD/MM/YYYY" belongs in the help description, not only in an error message.
And one thing to avoid: custom JavaScript is the most common way to break an otherwise accessible survey. Scripted show/hide, custom widgets and auto-advance regularly create keyboard traps, or change the page in ways a screen reader never announces. Use LimeSurvey's own conditions and question types wherever they will do the job.
Three checks catch most problems, and none of them need special software. Do them in preview, before activation.
Tab moves between fields, arrow keys choose within a radio group or array row, Space and Enter activate. You must be able to reach every field, always see which one has focus, and reach the Next button. If you get stuck anywhere, that is a keyboard trap — a blocker, not a nitpick.Cmd+F5 on Mac) or NVDA (free, Windows) on your own survey teaches you more than any checklist. Listen for inputs announced without their question, and array cells announced without their row.Then fix what you find and test again. All of this is far cheaper before activation than after.
LimeSurvey has no built-in accessibility checker, so borrow these — all free:
LimeSurvey's accessibility notes, including the testing results and ARIA implementation: https://www.limesurvey.org/manual/Accessibility