Rise accessibility issues with screen readers

Mar 31, 2020

We are accessibility testing a Rise that we have created. It contains basic text blocks, many videos, and a dozen single choice and multi-choice knowledge checks. Our tester is finding that:

From what I can see while doing the screen reader testing, they [Articulate] are using ARIA incorrectly and the markup produced is problemmatic for both screen reader users, and non screen reader users who depend on the keyboard (i.e. who cannot use a mouse). So what I believe is happening is this:they are creating checkboxes and radio buttons themselves from divs/spans/svg elements, then they are sticking the data they get from this hand-built UI into HTML input elements which are hidden with CSS display:none! My suspician is that this is because they don't like the look of HTML input elements and can't use CSS to style them as they desire.

 - They apparently have made it work for sighted keyboard-only users, but those using a screen reader will have trouble.

 - via screen reader, tabbing does not work; tab order is messed up and because of bad ARIA the screen reader cannot read their checkbox / radio button elements on focus

- using screen reader navigation, it is possible to navigate to the radio buttons (true / false choices) and check one and get correct feedback

- the (check all that apply) checkbox assessments can be completed by clicking on the corresponding label text, but you can't read the actual state of the control (checked vs. unchecked), making it tricky to know what you've actually chosen

 Could you get back to us with your accessment of the issue. Thanks! 

4 Replies
Lea Agato

Hello everyone! I’m happy to share our Rise 360 Accessibility Collection, which includes the VPAT to describe how Rise 360 conforms to WCAG 2.1 Level AA criteria.

We also updated our roadmap to include Rise 360 features we’re continuing to develop to better support WCAG.

Let me know your questions and experiences building accessible courses for all!