tamsiewest wrote: …
We are running version 2.73 (waiting to change until the 4.0 roll-out).
…

2.73 have a lot of a11y issue, it's one reason i work to improve totally a11y on 3.X.

Currently, my advice
- You are OK to check for specific issues in your instance : use the last 3.X version , and you can try gitlab.com/SondagesPro/SurveyThemes/skelvanilla
- You want a really stable version workinh on php5.6 : get github.com/SondagesPro/LimeSurvey-Sondag...ree/2.06_SondagesPro + gitlab.com/SondagesPro/coreAndTools/moreAccessibility plugin , and gitlab.com/SondagesPro/SurveyThemes/SkeletonQuest for template

Thank you for your prompt reply. We are not in a position at this time to change Limesurvey versions, as we have multiple surveys running or about to run. We have attempted to move to 3.0 in the past and were not happy with the results. Can you tell me what file in our current installation needs to be modified to add the /label tag?

SkelVanilla is a survey theme for LimeSurvey 3 and up.
It add a11y related feature

1. Usage of aria-hidden and hidden attribute for relevance ( and aria-live polite when it's updated)
2. Usage of aria-live (polite) for any HTML updated
3. Adding help and tips in aria-described-by
4. Usage of validity (setCustomValidity) for question with input error.
5. Adding error on title when the page have error when loaded.

More to come.

Please try and report issue's on gitlab repo (or framagit repo if you can not access to gitlab).

Hello team!
This thread has not seen any traffic in over 8 months. Is this the best way to follow the a11y of LimeSurvey related to WCAG?

No : best way is to report issue about a11y

My overall question is that our respondents will come from all abilities. We will need to report to accessibility teams on the availability of using LimeSurvey for them. However, I do not see any pages or wikis or anything that report on how accessible the tool is for admins or for respondents. Or, if it is more accessible in some modes versus others. E.g. screen readers, keyboard only, low vision, etc.

This is what I am looking for. I cannot just have every single user with an issue suddenly start coming here to submit bug requests. We don't have any bugs. We want to know the accessibility level of the application please.

rachellerena wrote: My overall question is that our respondents will come from all abilities. We will need to report to accessibility teams on the availability of using LimeSurvey for them. However, I do not see any pages or wikis or anything that report on how accessible the tool is for admins or for respondents. Or, if it is more accessible in some modes versus others. E.g. screen readers, keyboard only, low vision, etc.

This is what I am looking for. I cannot just have every single user with an issue suddenly start coming here to submit bug requests. We don't have any bugs. We want to know the accessibility level of the application please.

Currently : no team offered a complete accessibility report.

We offer LimeSurvey freely and don't have money to pay such report

Sorry …

An intersting article

Web accessibility overlay tools: lies and gum balls

We test all of our enterprise applications with a top a11y community recommended FREE tool. Currently, we use the SiteImprove plug-in for Chrome. It would be helpful if this could be applied before new releases are deployed.

It would be helpful if this could be applied before new releases are deployed.

As Limesurvey is a open source software, testing depends mainly on its users (like you and me). Before a new version of LS comes out, there are usually Alpha Releases, then Beta Releases, then Release candidates. During this time it would be the right time to test the software before its release and report any bugs, security issues or issues with a11y, so it can be corrected until the final release.

Unfortunately, there are many users out there that just use Limesurvey but never give back. Resources are limited and testing seems to be highly unpopular with users. It is always a struggle to get enough people to test the alpha and beta releases, as well as the release candidates.

So I can understand that the focus is first focused on bugs that block usage for anyone and a11y gets on a back burner. This might be sad, but unfortunately this is the situation. If you want to improve this, ask your colleagues and users to test as much as possible before each release. Setup a test environment and let them try to break it. At the end of the day, the software is provided for free. I feel the least we can do is help the developers where we can with translations, bug testing, etc.

holch wrote: So I can understand that the focus is first focused on bugs that block usage for anyone and a11y gets on a back burner.

It's partially true : if there are a11y issue reported : i fix it urgently …

And whole single question page are checked on www.tanaguru.com/ in 3.0.0.alpha.
Sometimes it was broken after

But about rachellerena poste : she talk for a NON FREE extension … where you need to register and to register : you need to entre in a form inside a iframe …


Some extension i use :
addons.mozilla.org/fr/firefox/addon/wave-accessibility-tool/ Needed one
addons.mozilla.org/fr/firefox/addon/wcag-contrast-checker/ quick and great
addons.mozilla.org/fr/firefox/addon/headingsmap/ quick
addons.mozilla.org/fr/firefox/addon/visual-aria/
addons.mozilla.org/fr/firefox/addon/axe-devtools/

It's partially true : if there are a11y issue reported : i fix it urgently …

I know that you are doing an excellent job fixing those bugs, which is why I focused on the testing.

And Open Source Projects like Limesurvey depend heavily on the support of the community, which is why I wanted to explain a little bit that users are required to help with the testing. They can contribute a lot to the project and speed up the development process by giving back with bug testing, translations, etc. At the end of the day, the project needs resources to cover everything. And especially things like a11y, which generally "do not pay the bills", the help of the community is even more important.