RISE - accessibility features

Jan 22, 2018

One year ago there was a discussion around accessibility -  WCAG AA, WAI-ARIA Labels, Section 508, DDA, Equality Act and Screen Reader Supports.

It was noted that Articulate were working on this and that there would be further developments in this regard. Have the accessibility issues been addressed. This is important for me as I am about to develop a course and would like to use RISE rather than Storyline. 

Thank you 



124 Replies
Ashley Terwilliger-Pollard

Hi Colette, 

We've been releasing Rise features and fixes throughout the past year, and you can see a full listing of those here in the Rise Version history.

Some things we've already implemented:

  • can improve accessibility for learners with screen readers by adding alternate text to images 
  • we changed the text contrast which darkened/lightened some colors in the UI to create stronger contrast (this is not author controlled) 
  • we’ve verified that Rise text can safely zoom to 200% without breaking the design, a key accessibility need

We've got a few other accessibility features in the pipeline, and my colleague Mike offered a great overview of what's coming up next with keyboard navigation here. 

Please keep the feedback, ideas and accessibility needs coming! It's all valuable for our team as they continue to plan out the next features and updates. 

Ashley Terwilliger-Pollard

Hi Nathan, 

We’ve been working hard on the accessibility features in Rise. And our ultimate goal is to be Web Content Accessibility Guidelines (WCAG) compliant.

We’ve built Rise to follow Accessible Rich Internet Applications (ARIA) standards for common navigation features, such as buttons, links, and forms. For custom features that aren’t covered by ARIA, such as interactive markers and sorting activities, we’ve focused on making the custom keyboard navigation feel natural and intuitive.

We do not yet provide full keyboard navigation support for learners who require a screen reader, but we are actively working on this.

As part of our plan to get to be WCAG compliant, we’re also hiring a 3rd party consultant to do a full audit. We’ll then produce a WCAG compliance document.

We appreciate your patience as we continue to work to meet the needs of all your learners and will continue to update you as we make progress in this area.

Ashley Terwilliger-Pollard

Hi David,

Our team is still working on these features and making progress but since my last post, we have yet to release additional features. As soon as we do, we'll post in as many forum discussions as we can so that you'll know right away! 

Another option is to keep an eye on the Rise Version history and the “What’s New, What's Next" page! 

Jim Larsen

In my experience, one of the greatest problems with RISE and accessibility is the low contrast between text and background, and low contrast between triggers and background.  In my limited experience I am finding that I cannot see features on the screen at all, such as radio buttons.  The low contrast causes my eyes to strain, and I have pretty good vision.  I find that the low contrast also makes the flash cards get skipped by users because they can't make out the outlines and the triggers on screen.

I disagree with the current low contrast fad in interface design that is trending with so many products.  If normal-sighted people can't make out the radio buttons on screen, how are the visually impaired going to be able to make use of it?

Jim Larsen

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.

Ashley Terwilliger-Pollard

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! 

Sharon English

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.

Sharon English

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.

Sharon English

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.

jeff wright

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,