From LimeSurvey Manual


With the passing of the United Nation Convention on the Rights of Persons with Disabilities (CRDP) by the Dutch government in 2016 (and MANY countries before that) it has become the law to be inclusive. This holds for buildings, trains, school, etc, but also for the digital word such as website and forms. So it also holds for surveys. In short: the WCAG 2.0 guidelines should be honoured. See and / or for the Dutch market Also see the A11Y project

A good slide about accessibility : [1]

This problem is nasty/wicked as the diversity of impairments is huge. See for example At this moment making surveys for impaired people is (almost) not possible, because of many reasons:

  • Visual - Simple things like using [TAB] to move between questions / answers don’t work (at least not in v2.05/6).
  • Visual - Denis has created a plugin some years ago for v2.05. See but that is outdated.
  • Motor : Has LS been tested with assistive devices? (keybord navigation for example ? : yes : near OK with 3.0 for major question type)
  • Visual - The currently available templates have no adequate ways of dealing with the tools for visually impaired (screen readers, braille rules, spoken text) : this is FALSE in 3.0/develop. (Denis do it in develop, started in 2.5X ... and start 3.0)
  • Visual, cognitive - In LimeSurvey core there is no fall back mechanism for questions: when one question type is impossible for impaired users it should be served an alternative (either to be decided during development or during runtime) this is FALSE in 3.0/develop. : usage of sr-only, aria-hidden, ls-js-hidden-sr , no-js etc ...
  • Hearing - Out of the box LS offers little “sound”, but as media become more interactive, we expect survey to follow suit and we must reckon with more audio-visual survey and templates to support that.
  • Javascript / No-javascript
  • Low performance computer
  • Right to left

Competition and market opportunity

With the passing of inclusive laws in more and more countries besides governments other organisations will be gradually faced with demands to make their websites and surveys accessible for disabled people.

A quick search shows that up to recently FluidMonkeys and SurveyMonkey were WCAG compliant. With the demise of FluidMonkeys and given that SurveyMonkey is very inflexible there seems to be no open source tool that supports the WCAG standard. Their might be commercial tools that do but these are often very expensive and closed. Hence there is a market opportunity for LS to step in.


StoryConnect has a customer that would love to see this development. Harold has indicated to them that such project would entail 3 phases:

  • Definition
  • Development
  • Testing (iterative until it works).

This document belongs to the definition step. But it should be noted that Definition itself must be a funded project. So the question that remains is:

Can we define the scope of a project to develop a solution that makes it possible to use LimeSurvey for disabled people?

Please note that with scope we mean "actually work and tested with users". So this goes (far) beyond technical implementation/coding. It should work and be tested with people with disabilities.

Another thing to keep in mind: it is not preferred to drop question types. The challenge is to support ALL question types and only fall back to replacement/alternative question types when there is no chance of solving the issue. Else we run the risk of creating 2nd class users again OR we must simplify surveys for fully able users and that is not acceptable.

Things we may have to think of are:

  • Definition and prioritisation of groups of users: what different type of visually impaired people are there, what technical solutions for these people exist nowadays?
  • What solutions have already been developed for LS. What is their status, how mature are they?
  • What part of solution lies in:
    • template development,
    • core development,
    • plugin development
  • Should we aim for backward compatibility? Should we focus on supporting LS version 3 or also LTS 2.6.4LTS?

Development roles

It seems wise to consider development roles early on. A first shot:

  • Tammo ter Hark & Jan Ehrhardt - technical development
  • Tony Partner - technical development (front end)
  • Harold van Garderen c.s. - customer contact and access to testing community
  • Denis Chenu - sparring partner
  • Stefan Verweij - redevelopment of template and testing support
Question: who does architecture?

Possible tips for development

  • Design your application without gui in mind first (Logical order)
  • Use standard widgets (e.g. labeled text fields, Avoid homemade widgets, or else implement atk)
  • Keep it simple! (Not only to make screen reading easier, but to make life easier for all users too)
  • template: tab switching
    • Danger with keyboard trap (and js) : issue in french
    • We are in form : then ScreenReader move to form system (didn't know english word) : but screenreader user use TAB and ARROW, hear label/aria-labelledby/aria-describedby
  • template: testing for [ALT] settings for all images or forcing that.
    • Hard to force Adminuser to add alt each time. But alt='' is OK for accessibility (for decorative image)
  • template: black/white/high contrast. Switchable by user Browser have tools for this : must test with it
  • template: possibility to enlarge characters on screen Browser have tools for this : must test with zoom + and -
  • question types: which are doable, which aren’t? Difficult are in particular graphics questions like
    • Array : we must not use col-description etc : for screenreaders : browser are in FORM mode : usage of aria-labbeledby/aria-describedby : see table role group + tr roles radio-group + label of radio
    • sliders : already shown a text input with sr-onlt (if i remind).
    • scales, dipolars, tripolars, maps and XY image drops, (what is this question ?)
    • file upload questions.
    • Map question
    • Ranking question type already have 2 part : one with sr-only (and no-js) and one with aria-hidden. But : can be great to have activate/deactivate for motors disable users
  • Better usage of aria-live and role for errors
  • Show error's list at top of the page (with quick access) after submit
  • Show 'There is an error when try to submit' inside the title
  • Improve relevance system (hide/show) with aria-live

external tools:



Discussions on LS forum