Hi Again! I’m starting over on keyboard accessibility. To hopefully make it easier, I’m starting with something very simple: an out-of-the-box multiple choice question using the “blank” theme.
I have enabled tab order and can see the focus indicator. After selecting a choice, I tab to the submit button (built into the MCQ). Pressing Enter (or spacebar) when the submit button is focused shows its “pressed” state, but does not actually submit (the only change is the pressed state).
Do I need to do some extra step to make a submit button keyboard accessible?
Thank you again!! (project attached in case that helps)
P.S. This seems to be the same with all buttons (using the built-in button feature or a shapes that are used as buttons), whether the action is to submit or to continue or whatever.
Add event-action to the key stroke (Events - Actions > Add On Click event > Submit action).
By doing so, after selecting a choice and pressing Enter, the question will be submitted, and the feedback layer will appear.
For more information about working with key stroke, take a look at this tutorial:
I also suggest adding an animated timer object to the Correct and Incorrect feedback layer. (View tab > Feedback Master)
The time will count down, hide the feedback layer, and proceed to the next slide.
You can make the animated timer invisible by setting its Opacity to 0.
Perfect! Thank you so much, Thuy! A+ support as usual.
Is there a list somewhere of which interactions are keyboard accessible by default, which require workarounds, and which can’t be made accessible?
Are any improvements in accessibility features on the roadmap for the software? With more countries requiring WCAG Level AA, it would be tremendously helpful!
At the moment, we don’t have a comprehensive public list that categorizes all interaction types based on their default keyboard accessibility. However, here’s a general guideline:
Keyboard Accessible by Default:
Common interactions such as keystrokes, checkboxes, and text entries are generally accessible via keyboard.
You can also use the keyboard to submit questions’ radio buttons as guided in the previous thread.
Require Workarounds or Not Fully Accessible:
Interactions like drag-and-drop or some custom event-based elements may need additional scripting or alternate workflows to be fully keyboard accessible.
We completely understand the growing need to meet WCAG Level AA standards, especially as accessibility regulations become more widely enforced in many countries. We have many other priority tasks that need to be completed, so we don’t have a specific timeline for implementing and enhancing accessibility features.
If you have particular features or use cases in mind, we’d love to hear more, @Chante
I’m starting over on keyboard accessibility. To hopefully make it easier, I’m starting with something very simple: an out-of-the-box multiple choice question using the “blank” theme.
