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.
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.
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.
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!
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?
I appreciate you sharing your experience here with us, Jim and I know our team is working on some additional updates for accessibility. We'll let you know as soon as those features are ready and would love to hear additional insights on how we can improve!
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.
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.
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.
From all of the above, if I could have just one wish:
The ability to apply a CSS style for headings would be an amazing win. Many of the blocks have hard-coded heading styles that aren't editable as part of the design process, which causes many tab order and sequence problems.
Hi Sharon, a huge thank you for sharing your results. I too am about to complete an accessibility exploration of Rise blocks, so your findings are very helpful.
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?
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.
124 Replies
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:
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.
Is there a ballpark release date yet for when Rise will support screen readers?
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.
Hi Ashley, has there been any further progress on this since your last post?
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!
I know you said Rise isn't fully WCAG compliant yet, but do you know if it is Level A WCAG compliant?
Hi Andre,
Thanks for checking in! I don't have an update yet on our compliance with WCAG, but as soon as we do we'll let folks know here!
Hi Ashely - any update with the WCAG compliance?
Hi Virginia,
No news yet, but once we have an update I promise we'll share in these ELH discussions and update our Rise Version history, and our “What’s New” page.
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?
I appreciate you sharing your experience here with us, Jim and I know our team is working on some additional updates for accessibility. We'll let you know as soon as those features are ready and would love to hear additional insights on how we can improve!
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.
Fantastic! I would love to hear the results of your evaluation. beth.case@louisville.edu
We have adopted accessibility compliance as part of our production best-practices. Just making this comment so I may see updates on this thread.
Hi Sharon - Do you have any results to share?
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:
What worked well:
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.
From all of the above, if I could have just one wish:
Hi Sharon, a huge thank you for sharing your results. I too am about to complete an accessibility exploration of Rise blocks, so your findings are very helpful.
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.