Forum Discussion
RISE - accessibility features
Good morning,
In September, we had an accessibility check conducted on one of our Rise courses. A number of issues were flagged, including in relation to colour contrast which I thought had been addressed. Some other issues include:
- colour contrast is fine for main text but is insufficient when it changes on mouse hover
- all pages are missing a page title
- sequence that screen readers read out content is often different from the visual presentation on the page
- links for screen readers directing to the wrong location (e.g. 'skip to main content' link directs to course menu, not main content)
- repetition in reading out some headings when using a screen reader
- screen reader links do not adequately describe their function (e.g. show/hide button reads out show/hide but does not explain what will be shown/hidden)
- no option to add alt text to logos
- screen readers cannot select radio buttons in multiple choice knowledge checks (pressing the space bar or enter key triggers the course menu button)
- radio buttons are too small
- quiz results are read multiple times when using a screen reader (e.g. "Your score Your score 47% Your score 47% 47%")
We love how simple it is to build beautiful, interactive courses in Rise, but like many others, if accessibility guidelines aren't met by the end of the year as promised, we're going to have to start using something like H5P instead.
I'd be happy to share the full accessibility report if that would be helpful. Our consultants have even explained how each issue can be fixed.
At some stage it would also be really useful if you could provide a list of which block types are accessible and which aren't (like H5P does: https://h5p.org/documentation/installation/content-type-accessibility)
Thank you.
Kind regards,
Ashley
Good findings Ashley, in this area of accessibility this is one of the most important function to design a Training for specific audiences. Why is this taking more than 3 years to provide these important features as per the eLearning guidelines. Articulate should implement these on priority basis, as always the answer to this is not positive and the end user were suffering to consume the content designed with the tool. Can we have a specific guidelines how to use blocks supported for accessibility purpose. And why is its taking so much time to remove the lesson header/customization?