This page explains the new feature release of advanced accessibility options when authoring Multiple Choice Question types. Specifically, the business logic and suggested use-cases.

Visual example showing the checkbox to enable the new advanced accessibility options.

Introduction

At Learnosity, we not only continually strive to comply with the latest approved Web Content Accessibility Guidelines, but go beyond the requirements. We passionately believe that all students have the right to a great educational experience and are committed to removing any barriers to learning.

With the release of 2022.3.LTS we are excited to announce that we have gone the extra mile to enable authors to create more customized accessible experiences in Multiple Choice Question (MCQ) types). More complex responses, like tables and complex math, can now be configured to navigate with ease by screen readers and authors have more control of the whole screen reader behaviour on any response for MCQ. 

As leaders within the accessibility community, we want to emphasise that with this great control comes great responsibility. Use these advanced options only when necessary, the default behaviour, when the advanced features are not being used, should be sufficient for most cases. Please take in consideration our recommendations for the use of these controls and the implications when using these below.

How do these new features work? 

In order to explain the functionality of the feature, and the screen reader implications, we will take one example to demonstrate the user experience. 

Default behavior (Not using the advanced accessibility features)

When the advanced accessibility features aren’t being used, the default screen reader behaviour will mean that the content of the responses themselves aren’t navigable and that each response is read out all at once when selected. In most use cases this is preferred, especially when the content itself isn’t complex and the user wants to quickly skip between their options. 

In cases where the content is complex in nature this behaviour can cause confusion. For example, in the below instance each response is read out to the screen reader user, all at once. This can be quite difficult to make sense of or even remember what has been said at each response. 

Example of screen reader behavior on default, when the advanced accessibility features isn't being used.

Using the “Custom ARIA label” feature

The Custom ARIA can be used too explicitly set the assistive label that will be announced by screen readers. In other words, when navigating to each response using a screen reader the contents of this field will be read out instead of the visible response. See below as an example:

Example of screen reader behavior when content has been added to the "Custom ARIA label" textfield.

Using the “Visible content is navigable by a screen reader” feature

When selecting the checkbox “Visible content is navigable by a screen reader”, the content is announced and can be navigated with ease by a screen reader. Even if no content is added to the “Custom ARIA label” textfield, the available content will be announced by the screen reader. This is ideal for more complex content that requires more control by the user. For example, when the options consist of tables or more complex math equations. In cases like these it is more beneficial for the user to navigate the content for improved readability or understanding. See below as an example of this behaviour:

Example of screen reader behavior when the "visible content is navigable by screen reader" has been enabled.

Using both the “Visible content is navigable by a screen reader” and  “Custom ARIA label” feature

When selecting the checkbox “Visible content is navigable by a screen reader” as well as entering content into the Custom ARIA textfield, both the content of the options themselves and the custom ARIA content will be announced by a screen reader. Additionally the contents of the individual options will be navigable by a screen reader. See below as an example: 

Example of screen reader behavior when both the custom “Visible content is navigable by a screen reader” and  “Custom ARIA label” feature is being used.

Recommendations

Based on the functional explanation above, we can conditionally* recommend an approach by content type. See the below table for more details:

*Note that these recommendations are based on a generic use case and might not be applicable to all or more complex use cases. When using these features in combination with each other it may create an inconsistent user experience, which could result in confusing screen reader behaviour. 

Conclusion 

As demonstrated above, the new advanced accessibility features can be used in a variety of ways in order to get the desired results tailored to the particular content and needs. From ensuring accessibility on a simple image to making a complex table navigable by a screen reader. With these advanced features assessments can be made more understandable for everyone, when used with purpose in mind. We recommend that any content using these features are thoroughly tested using screen readers to ensure the desired results have been achieved. Refer to our recommendations and the sections outlined for a full understanding of using these features.