Forum Discussion
JAWS Accessibility Testing Feedback On Rise
Articulate has made a lot of progress making Rise more accessible. I recently had a colleague test a Rise course using JAWS. The course includes all the different accessible blocks Articulate recommends. Overall the content was functionally accessible.
We did notice that with flash cards you need to navigate into the card each time to access its contents. You may want to consider using ARIA polite to make it easier for people using screen reading software to access each card’s contents.
We also noticed that focus would be lost sometimes when the zoom button for images was selected or jumping between quiz questions.
The labeled graphic block opens a smaller window as each item is navigated. There can be too much content in that smaller window leading to the screen reader reading text that is not visible to the user. This can impact people who have low vision and use screen reading software.
Additional accessibility feedback includes an issue with the default pie chart view, which does not include labels. The pie chart slices rely on hover states to trigger labels, which are not keyboard focusable.
I just wanted to highlight this feedback to help Articulate continue to improve the accessibility of the Rise platform
Similar observation here with NVDA and Flashcards. The front of the card isn't read on focus -- I need to arrow-key into the card. The back of the card is read on flip; and on a return flip to the front, the front text is read.
Also, is there a way to change the "Click to Flip" wording to "Select to Flip"? That would be more in line with UX and accessibility best practices.
It would also be nice to have a way to enable the screen reader to announce something like "Card 1 of 3" so screen reader users can stay oriented within the interaction. I do specify before the Flashcard interaction how many cards there are so SR users know what to expect, but as far as I can tell, there's no way for them to know within the interaction where they are in the card count.
Hi Liz!
Thanks so much for your feedback regarding our flashcard's accessibility. I can see how it may not be obvious for users who are not familiar with the flashcards to use the down arrow key to interact and read through the card contents. Considering the nature of flashcards on the web in general is a custom widget, I thought I'd share how we designed our flashcards to be as accessible as we possibly can, and also how you can improve its accessibility as an author.
To help guide screen reader users in navigating the flashcard, we follow a natural reading order, preserving a meaningful sequence. In browse mode, the screen reader cursor would land:
1 - Flashcard's group to denote that it's entering the interaction
2 - the helper text "front of card" marks the side of the card the user is on, so they always have context on which side they are on.
3 - card content
4 - flip buttonIf the user doesn't flip, then the cursor would go to the next card on the list.
If the user flips, we have a mechanism to announce the back of the card contents while having a focus on the button so that users can readily flip to the front again.To enforce more accessibility in the flash card as an author, take advantage of the visual and accessibility labels found in Settings -> Labels:
In Buttons & Messages tab, look for the Flascards category. Change the label "Click card to flip" to make the button label more meaningful to screen reader users, such as "Flip button. Press enter to activate"
In the Screen Reader Announcements tab, look for the Flashcard category. Change the label for "Flashcard grid group label" to include instructions such as "Flashcards. Use the up and down arrow key to navigate".
As for announcing the card count, we are doing this in the code by using list semantics. Voice Over in Mac does announce the card count, however, NVDA & JAWS seems to not cooperate 😅.
Hope this helps! Cheers!
Marvie
Hi Marvie,
Thank you for sharing the information. I have found flashcards to work well using VoiceOver.
I'm glad you're working on adding the card count to NVDA & JAWS. I also think changing the default labels from click to select would be beneficial. Click mainly refers mouse users while select includes people who only use the keyboard or use screen reading software.
I really appreciate your help.
Auston
Hi there Auston!
We appreciate you taking the time to provide feedback to improve accessibility! I will log these as feature requests, and we'll update this thread if we make any changes.
Hi Hazel,
Thank you for all your help and I hope you have a great long weekend.
Hello Auston, thank you for the post on JAWS accessibility on 25th May. I am currently working on a project for my organisation where I am designing 4 (RISE 360) learning packages. I was asked to ensure the packages were accessible for screen readers and keyboard navigation. I've done much research via the Articulate feeds and sites about this and read most of the web pages. I have now designed a package and have only used blocks for: paragraph, 4-grid image grid, video with (cc), numbered list, image & text, tabs block, 2-column para, labeled graphic. I believe I've used the elements that comply with WCAG 2.1 AA. Reading from your original post here, JAWS would be ok with my RISE course. I haven't installed any SR software on my machine in case it effects the functionality of my pc. Given the blocks I've used, is there a need to install anything on my machine to test accessibility, or is there a way to share my course with someone who can test the accessibility aspect in a more authentic way. Appreciate your help.
HI Kim,
I'm sorry for not getting back to you sooner. If you are using only accessible Rise blocks there is a good chance that your course is compatible with screen reading software. I recommend ensuring that you are using headings to break up the content. This makes a long page of course content much easier to navigate. Also ensure that you are using alt text to describe any meaningful images or "" to hide decorative items. I am attaching a draft of a Rise checklist that might be useful.
Hi Auston, I have read the reports and information on Articulate about "accessibility". There's alot to absorb but it looks like I'm on the right track. Thanks for the ("") tip to hide decorative items, I will go back and do this! I will be adding video and some SL later so shall keep reading widely via Articulate. Grateful for the support!
