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. Also see the A11Y project http://a11yproject.com/.

A good slide about accessibility : [1]

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? (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.

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 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:

Stories

Guidelines

Discussions on LS forum

LimeSurvey 3 and WCAG objective

One of objective of LimeSurvey 3 was WCAG respect guidelines. This was done in december 2016 for answers part and a lot of public page. Nothing was tested in admin part.

test was done using https://tanaguru.com/ and except upload question type and map question type : all basic question ger the WCAG level 2. Some fix must be done for hiding/swo question (usage of aria-live) and error/success

Accessibility

From LimeSurvey Manual

(Redirected from Accessibity)

Contents