Actions

Accessibility

From LimeSurvey Manual

Revision as of 13:46, 18 May 2017 by Tammo (talk | contribs) (Created page with "Introduction= 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 tha...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Introduction= 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 https://www.w3.org/TR/WCAG20/ and / or for the Dutch market www.drempelvrij.nl.

This problem is nasty/wicked as the diversity of impairments is huge. See for example http://a11yproject.com/posts/myth-accessibility-is-blind-people/. 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 https://www.limesurvey.org/forum/search?query=WCAG&childforums=1&ids=108342 but that is outdated. Motor - Has LS been tested with assistive devices? Guess not. Visual - The currently available templates have no adequate ways of dealing with the tools for visually impaired (screen readers, braille rules, spoken text) 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) 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.

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 support 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.

Challenge

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 what would be the scope to a project in which we develop a solution that makes it possible to use LimeSurvey for disabled people?

One 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

  • template: tab switching
  • template: testing for [ALT] settings for all images or forcing that.
  • template: black/white/high contrast. Switchable by user
  • template: possibility to enlarge characters on screen
  • question types: which are doable, which aren’t? Difficult are in particular graphics questions like sliders, scales, dipolars, tripolars, maps and XY image drops, file upload questions.

external tools:

Stories

Guidelines

Discussions on LS forum