Willkommen im Online-Support von SoSci Survey.

Hier bekommen Sie schnelle und fundierte Antworten von anderen Projektleitern und direkt von SoSci Survey.

→ Eine Frage stellen


Welcome to the SoSci Survey online support.

Simply ask a question to quickly get answers from other professionals, and directly from SoSci Survey.

→ Ask a Question

0 votes

Hello - this is going to be a longer post, as I received an in-depth analysis of a survey I created from a colleague who tests content for VI accessibility. We understand, of course, if these changes are not possible to do. I am also sending ahead that I personally don't understand many of the comments, but if I can do anything to help fix from my end, I will do my best!

(He tried the "accessible" version and the normal version for the survey and both seemed to have similar issues.)

1. Changing Tab order by tabindex attribute
Desc.: Many form elements and links contains tabindex attribute that changes an order of elements when going through them by Tab key. It could be very confusing for screen reader users because they will get elements in different order when going by Tab and when going by virtual cursor of a screen reader. See Using the tabindex attribute page for more information.
The best approach would be to place all elements in HTML code in the logical order and avoid changing Tab order by tabindex.

Note: Could this issue be coming up because I have some randomized questions in the survey?

2. Missing connection between invalid field and its error message
Desc.: When user activates the Next button but the input is invalid or some required answers are not filled in the error message appears above the form, i.e. “Please also answer this question – Your answer to this question is of importance to this study.” The problem is that screen reader doesn’t read the message in that moment so user doesn’t know why he or she doesn’t proceeds to the next step. When user finds the error message he or she doesn’t learn from its text which form field is problematic. So it’s difficult to find and correct invalid input with screen reader. We suggest following adjustments:
• All such error messages should be marked with role=”status” to force screen reader to read the message automatically when it appears.
• Text of error message should always contain name of the problematic element so user gets information where is the problem.
• Focus should ideally go automatically to the first invalid form elementso user doesn’t need to search it in the form.
• The error message is paired with the problematic form element by aria-describedby attribute so screen reader reads the error message automatically as the additional information when the form gets focus.

3. Marking up groups of select boxes or other elements
Desc.: There are groups of <select> boxes in the accessible version. For instance on the page “Ease of use of autonomous cars” there is a group that begins with “Please indicate your agreement to the following statements:”. These groups should be marked as groups in HTML so that screen reader can read automatically the label of group when user gets there. So <div> containing <select>* boxes should have the attributes role=”group” and aria-labelledby=[id of label]. The label “Please indicate your agreement...” should have the corresponding id.

4. Dynamic page titles
Desc.: All pages have the same title ‘Questionnaire’ ( tag in section). It would be much better when every page could have a unique title based on its content. The best way is to use text from main H1 heading as a beginning of page title, i.e. title ‘title ‘Data protection and consent to participate | Questionnaire‘ for the third page., title ‚Autonomous and connected vehicles | Questionnaire‘ for the fourth page etc. Another possibility can be showing a percentage of progress in the title – something like 6% done | Questionnaire‘. The page title is the first text that is read by screen reader on page load and a user should get information from the title that he or she proceed to the other page.

Note: I have a feeling I might be able to change this one from my side, but not sure where.

5. Visibility and Position of the button for disabling more accessible mode
Desc.: The button “Change to the accessible version” is visually hidden now. The button should be visible for low vision users (and The button for disabling accessible mode too).
Desc.: The button for disabling more accessible mode should be positioned at the same place the button for enabling it, that is, at the top of the page.

Note: this one is strange, for me they appear both at the very bottom of the page. I agree that they are hard to find though.

6. Missing markup for required form fields
Desc.: All the required form fields, including checkboxes, radio groups, edit fields etc., should have the aria-required=”true” attribute set on them. This ensures the require status of the field is conveyed to screen readers.

Thanks a lot for your help!

in SoSci Survey (English) by s002793 (335 points)
Thanks for sharing this analysis. However, I am not sure if the comments are simply the results from an automated site test (there are great browser plug-ins for that) or if these are actually correlated to problems encountered in pretests?

The reson for my question is the first note about the tab order: Actually, some of the tab order was specifically designed to support people doing the questionnaire via screen reader.

Also did we get quite positive feedback from surveys working with visually impaired persons. Therefore, before going and changing everything (there are good point that we will definitely change), I would like to understand the background of the notes.
For sure - so my colleague, who is part of the European Blind Union, tested it and said he used the following specs:

Tested using the following software
•    Screen readers: JAWS 2021.2011 and NVDA 2020.3.
•    Internet browser: Google Chrome 87.
•    Mobile platform: iOS 14.3.

I was actually surprised myself about the number of issues he encountered, since I saw that there was an accessibility option and your documentation on accessibility and so I had been very optimistic when I set up the survey. The survey is under the url CAV_survey if that also helps.
Would you mind, asking them for details about the first issue (tabindex). Expecially if there was a question where it actually caused trouble, and which one?

While it is still a good idea to improve SoSci Survey further (should be possible within few days), I am confident that many of the "issues" are mostly aesthetic details, and do not actually restrict usability with JAWS and other screen readers: If that was the case, I would have expected negative feedback from those surveys working with visually impaired persons.

Should my confidence be wrong, please do not hesitate to let me know. But, as I wrote, we will follow the recommendations anyway (except for the tabindex, unless we get further details on that). Making something better is always a good idea ;)
Thanks a lot! I asked again about the tab index issue, and the colleague said it was mostly on the “Data protection and consent to participate” page that I had set up (there are apparently some minor issues on other pages, but not too jarring).

He wrote:

*When tabbing on this page NVDA starts on “You can access...” link then continues to “Technical support” then to the address bar and then to checkboxes. JAWS starts on checkboxes but skips “You can access...” link. So, the behavior is inconsistent there and something is skipped in the first round of tabbing and user needs to go by Tab in other round from the address bar.*

I will try to see if redoing the page itself in a slightly different manner would improve the experience for him, and then that issue I would consider closed.
Thanks a lot for your efforts so far, I really appreciate it.

1 Answer

0 votes
 
Best answer

Again, thank you for the detailed feedback. We could implement most of the changes in the meantime (the update is installed on www.soscisurvey.de at the moment). Here is what is unchanged so far:

Changing Tab order by tabindex attribute

Not modified unless we have more reason to believe that this is actually an issue in questionnaires.

Text of error message should always contain name of the problematic element so user gets information where is the problem.
The error message is paired with the problematic form element by aria-describedby attribute so screen reader reads the error message automatically as the additional information when the form gets focus.

Both is on the wishlist now, but qill require significant changes. Not to be changed on the short term.

Dynamic page titles

We have changed that, but one can also change that in the "texts and labels" settings. For the questionnaire title, you may specify something like:

Questionnaire | page %pageNumber.rel%

The button “Change to the accessible version” is visually hidden now. The button should be visible for low vision users

The accessible version is optimized for screen readers, and may not be optimal for low vision respondents. Always displaying the button will, however, be a major issue for respondents with good vision, and I am very sure that researcher are not fond of such a solution.

Also it is very unlikely that respondings using a screen reader want to change back to the default display mode. Therefore, a button at the top of the page (carrying a significant amount of text) will not be optimal for them, as well.

For the moment, I do not have a good solution, here.

All the required form fields, including checkboxes, radio groups, edit fields etc., should have the aria-required=”true” attribute set on them

Most of them now have, however some more special question types do not.

Also, this flag is only set for questions/items that demand an answer, not for those probing an answer.

ago by SoSci Survey (160k points)
selected ago by s002793
...