Multiple choice, multiple response questions are not accessible via the keyboard alone (Articulate Rise)

Aug 25, 2023

We have an issue in a course that we're developing where we got this as feedback from the accessibility team. We were not able to able to find a fix for this.

Is there a fix for this that we are unaware of or one in the pipeline in the near future?

This supports not only screen reader users but non-screen reader users who cannot, for whatever reason, use the mouse. Also, all responses must be properly labeled. This means, among other things, that the appropriate text must be programmatically associated with each response such that the screen reader will announce the correct text when that response field gains focus.
For instance, when the first response to a question gains keyboard focus (usually by tabbing to it), the entire question text is read, followed by the label on the first response, which is good behavior. However, when focusing on the first response to the next question, instead of reading the question text, the first question is read, followed by the label of the first response of the second question. This is clearly incorrect behavior. This is a case of incorrect labeling and needs to be corrected. Keyboard focus does move to the proper place via the tab key, but the wrong text is announced by the screen reader!This is due to the aria-labelledby attribute on the second question's answer group container having the incorrect value.
Also, the actual container for the question text of question 2 has the same ID as the first: id="q-cjpsqhi29000q3g6f99thm96g" (an example from a course) which is also clearly incorrect (id strings must be unique within the same html document)!


Two types of multiple choice questions
There are generally two types of multiple choice questions:

  • Choose one (uses radio buttons to register response)
  • Most of the assessments of type "choose one" are properly labeled.
  • Choose many (uses checkboxes)
  • none of the "choose many" questions) are properly labeled.
  • each checkbox should have it's own label (i.e. what response does this represent)
  • for the most part, this is done correctly
  • the group as a whole should have a label, which is generally the text of the question itself
  • this is done for both question types, but does not work for "choose many" types because they are not marked up correctly

How it is done The "choose one" questions have this form:

<p id="question1">this is a "choose one" type question</p>
<div role="radiogroup" aria-labelledby="question1">
<div role="radio" aria-labelledby="id-of-response1-label"></div>
<div id="id-of-response1-label">response one text</div>

Unlike the radio button role, the checkbox role must place the text associated with each checkbox inside the element with role="checkbox" as shown below; elements with radio button role can place their label inside the element, or they can reference external labels as is done already in these courses.

<p id="question1">This is a "choose many" type question</p>
<div role="group" aria-labelledby="question1">
<div tabindex="0" role="checkbox" aria-checked="false">response one text</div>
1 Reply
Marvie Mulder

Hi Articulate 3,

Except for Matching, the rest of our knowledge check blocks (Multiple Choice, Multiple Response & Fill-in-the-blank) blocks are fully accessible by screen readers or by keyboard alone. We are following the standard keyboard support for radio buttons and checkboxes. Let's take Multiple Choice as an example. When you tab to the radio button, the spacebar is used to select the radio button, down/up arrow to cycle through the options. For Multiple Response checkboxes, you tab to go through each option, and spacebar to select it. I'm curious to know what did not work for you. Please let us know!

Regarding the aria-labelledby pointing to a duplicate ID, I believe you might be hitting a bug where the question ID is always the same if the MC is inserted from a template. If that's the case, then the good news is we've already fixed this. Please give it another try and let me know how it goes.

In regards to your multiple response feedback, I do agree that we can definitely improve this further with your suggestions of grouping the checkbox list, as well as putting the label in the <div> that holds the checkbox. We have a slightly different implementation due to some constraints, but these checkboxes are programmatically associated with its label. Overall, it doesn't prevent users from understanding and operating the content. 

Hope this helps shed some light. Let me know what you think and I'll go ahead and get a ticket going for these improvements!