Hi Jelo,

cortxdp and me test moreAccessibility with SkeltonQuest, but i think all template can work here.

Denis

jelo wrote: Is there a certain template which ease accessibility? I am unsure if even every template will allow navigation and answering with keyboard only.

I have recently tested all templates of the Limesurvey Template Shop , here are some more findings:
- Navigation usually always works fine since that action is not template related but supported by Limesurvey by default.
- All questions besides the ranking question should support answering with keyboard if they use the default browser radio buttons/checkboxes.
- For a better accessibility you may want to use question by question survey mode because questions/items suddenly popping up due to conditions may be tricky for handicapped people.
- I am not sure about existing screen reader issues. Has anyone recently tested them?

- All questions besides the ranking question

Ranking question is totally accessible for screen reader in 2.06. See screenshot for more examplanation. Actually only "map" and "upload" question type are not tested/validated.

suddenly popping up due to conditions may be tricky for handicapped people.

Yes : it's the nreason we need to remove this awfull .hide()/.shown() function in ExpressionManager ....
But .hide/.shown is more for nojs accessibility (see www.filamentgroup.com/dwpe/ ) : screen reader are semi-compatible with .hide/.shown : if the question is after the conditions : it's OK for accessibility.
Issue it : condition after question : this must be tested/improved with more aria.

- I am not sure about existing screen reader issues. Has anyone recently tested them?

You know a societey who test actually plugin + SkeletonQuest. Don't have returned informatiion actually for me.

Denis

Mazi wrote: I have recently tested all templates of the Limesurvey Template Shop ,

All templates? Isn't TFR part of your shop? How could you navigate in that template?

The popups in Limesurvey should not be the default behavior. I never use them. To keep them off in the default the development will recognize issues when using Javascript popups for workarounds and certain questions more easily. I never understood why popup is default. The browser often allow to prevent display of there popups.

I have installed the plugin. The warning "Some system can not be deactivated" looks a bit awkward.


Any issues with version 2.06lts Build 160417?

Fixed in :
framagit.org/SondagePro-LimeSurvey-plugi...ba837137b9d84fe00261
github.com/SondagesPro/LS-moreAccessibil...ba837137b9d84fe00261

I know this thread primarily focuses on this template and its survey output being accessible and this may likely be a separate topic, but can anyone speak to the accessibility of the Limesurvey admin interface in developing surveys? I have a blind user that is looking to switch to a different survey software and I am checking on the accessibility of Limesurvey. Thanks.

lstrange wrote: I know this thread primarily focuses on this template and its survey output being accessible and this may likely be a separate topic, but can anyone speak to the accessibility of the Limesurvey admin interface in developing surveys? I have a blind user that is looking to switch to a different survey software and I am checking on the accessibility of Limesurvey. Thanks.

Hi,

I don't think actual version is really accessible, must be tested.

But your right on 2 points:
1. public part and admin part MUST be accessible
2. public and admin part accessibility are really different objectives (not same developper, not same prodution, not same system)

Then : i think the best solution is :
- Open/create a new topic about admin accessibility
- Create bug for admin accessibility if there are (we already fix bug for admin accessibility when it happend : i don't know if 2.5X is better than 2.6 for admin accessibility).

Hi,

I've been testing the 2.5x version without your plugin and I notice the extensive use of aria attributes instead of native tag and attributes. The use of aria-group instead of <fieldset>/<legend> or the use of aria-labeledby instead of <label for=...>. I would have liked that these elements were put in the core instead of a plugin since it's some basic form building practices.

2. Notes on ARIA use in HTML
2.1 First rule of ARIA use
If you can use a native HTML element [HTML51] or attribute with the semantics and behaviour you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.
www.w3.org/TR/2015/WD-aria-in-html-20150521/

I do not want to be rude but I think that it's a step backward in this regard.
I will reactivate your plugin and test it with this version.

Thanks

cortxdp wrote: I've been testing the 2.5x version without your plugin and I notice the extensive use of aria attributes instead of native tag and attributes. .....

I think 2.5X must not be used for accessibility. It's the reason why i completly rewrite all HTML fror develop/3.0 version, see tinyurl.com/z4fjkt2 , and about label : bugs.limesurvey.org/view.php?id=11449

I do not want to be rude but I think that it's a step backward in this regard.

I think same about 2.5X. Hope 3.0 are really beter than 2.5X and 2.6

I will reactivate your plugin and test it with this version.

No need : i know it don't work : framagit.org/SondagePro-LimeSurvey-plugi.../issues/8#note_41662

It's good to know. Thanks you for your work.

Is there a planned release date for V3.0? I have to know because we have survey release coming and we must be W3C compliant. If possible we would like not to have to patch our survey.

Many thanks

Hi , Carsten spoke of January for alpha release.

You can do some test on some question type here testing.sondages.pro/answershtml/


The home page are broken currently but question must work