RISE - accessibility features

I would be happy to share my insights.  I am a long time customer with Articualte products and I enjoy working with them.

There are several nice online tools that will assess accessibility issues.  It would be nice if there was an option or a mode for Rise that would pass those tests.  Our primary considerations in this agency are good contrasting colors, voice assisted navigation, screen reader compatibility, and keyboard navigation.

The state (my employer) is enacting new policies that require all new training to meet these accessibility standards.  Since Rise does not meet the standards, I am violating policy when I use it.  I find Rise a much better option for rapid development on small projects, but it I will have to go back to using Storyline until accessibility standards can be met with Rise.

It would be nice if Rise provided the developer with some control over the color pallet, rather than just letting us choose one accent color.  Even if we just had a few canned templates to pick from.  It would also be nice if the end user had an option for selecting high contrast mode so that they could adapt the screen for their vision.

Thanks, Jim! That's tremendously helpful, and I shared it with my team too. I know screen reader support is on the list and we do have keyboard accessible navigation as detailed here. I'll keep you posted on any other news or updates, and you can also keep an eye on the “What’s New” page and our Rise Version history for all the latest and greatest! 

I wanted to share my win of the week. I work with a disability organisation and like Jim Larsen above, we are required to meet WCAG standards, and to do that we use a number of different authoring tools in our web and eLearning development. Despite Rise not being considered WCAG compliant, our accessibility testing has consistently returned a really low number of accessibility issues, which generally have come about as a result of design flaws.

The only slight challenges we've had to date has been the use of the Accordion interaction, labelled graphics and multi-select quiz questions (radio buttons are fine). 

Clever, thoughtful design ahead of any development taking place, i.e. designing for accessibility first, really helps us avoid any potential issues (eg no drag and drop activities etc) - an approach we use regardless of tool.

Love that story, Sharon and thank you for sharing! 

Can interactions, such as flash cards and sorting be done by a blind user using a screen reader? 

Hi  Beth - I'm in the process of doing some extensive testing in this space using JAWS screen reader. I've created a sample course that basically includes all of the available RISE functionality and we're testing to see which functions are problematic. I know that, for example, the multi-response questions are not but the multiple choice are. Happy to share the results once I get them - hopefully, next week.

We have adopted accessibility compliance as part of our production best-practices. Just making this comment so I may see updates on this thread. 

I just got my testing results back and I'm happy to share them with the community. 

My approach: 

I created a course and basically inserted one of every type of block there is in Rise. I applied as many accessibility considerations as I could in terms of contrast, alt text on images etc.

I shared the course with a colleague who is blind and uses  JAWS screen reading technology, and here's what we discovered:

What to avoid:

• image galleries and carousels  
• fill in the blank questions
• continue divider - the block seem to add a lot of  'noisy' script
• labelled diagrams - tab order just keeps looping between labels
• quiz block - hard to navigate,  each question is announced twice (use knowledge check instead) 
• quiz maker inserted as storyline block - 'noisy' script that could not be navigated
• step order process interaction
• timeline interaction - headings 'style' is a problem
• flashcard interaction
• any drag and drop - eg card sort interaction and question type
• multiple response questions

What worked well:

• buttons with links (but they 'appear' below in a screen reader announcement, not right as visually displayed)
• accordion - however, headings are problematic as often not in sequence
• single response radio button questions (but this is very limiting for non-vision impaired learners)
• Text, statement, quote, list functions
• file downloader
• two column text function
• image function - using alt text (alt text space not limited which is good)
• embedded video (provided video has closed captions)

Hopefully, this helps those of you who are keen to use Rise but still need to provide accessible eLearning. 

I'd welcome the chance to continue a best practice dialogue in this space and look forward to hearing about the approach that you are taking.

Hello, I'm using the "JAWSInspect" extension in firefox and I'm seeing unicode being added to the end of menu items.  attached is a screenshot, has anyone heard of extra code being added to menus?

In this case it's 

menuitem: Essential Information \ue93b"

it's like this for every item in the sidebar, is this part of a JAWS experience or the emulator?

Many thanks,

Is there a consolidated VPAT or other documentation that discusses the degree to which RISE is accessible in it's current iteration?  Trying to find this answer across multiple threads and product release notes is difficult, at best.