Questions answered by this guide
- Why doesn't JAWS read my Rise Tabs content?
- Are Rise Tabs blocks accessible?
- Should I use Accordion instead of Tabs for screen reader users?
- Are Rise Flashcards keyboard accessible?
- Does A11yCheck test Rise Tabs with JAWS?
What you'll learn
- Articulate's own "Choosing Accessible Components" guide lists Tabs, Accordion, and Flashcards as accessibility-supporting -- this is not an article about these blocks being broken
- Several Articulate Community threads describe JAWS reading a Tabs block's label but not its panel content -- a reported behavior, not an Articulate-confirmed defect
- A11yCheck has not independently reproduced this behavior and cannot run JAWS, NVDA, or any screen reader itself
- Testing with JAWS specifically, not only NVDA, is the one piece of advice this evidence directly supports
What's inside
Rise course builders troubleshooting Tabs, Accordion, or Flashcards accessibility, especially reported JAWS behavior
- 01The short answer
- 02What's confirmed vs. what's reported
- 03Tabs vs. Accordion
- 04Flashcards: a different, narrower risk
- 05How to test this yourself
- 06Common mistakes
- 07What A11yCheck can and can't check
- 08Verification checklist
Why it matters
Articulate officially lists Rise's Tabs, Accordion, and Flashcard blocks as accessibility-supporting components. Separately, several threads in Articulate's own community forum describe JAWS reading a tab's label without reading the panel content underneath it once a learner navigates in. Neither of these facts cancels the other out, and neither one is the whole story on its own. If your course reaches JAWS-using learners, this is worth testing directly and specifically, not assumed either way from a general accessibility claim or from a handful of forum posts.
When you'll encounter this
- You're deciding between Rise's Tabs and Accordion blocks for a section of parallel or categorized content.
- A course has come back from an accessibility or 508 review with a note about the Tabs block specifically.
- You're building a Flashcards interaction and want to confirm the flip works from the keyboard, not just a mouse.
- A learner or reviewer using JAWS has reported that a Tabs block seems to go silent after they select a tab.
Example
Custom-built tab interface vs. Rise's native Tabs block
✕ Incorrect
A course author needs a tabbed comparison and builds one from scratch using custom buttons and show/hide states, rather than Rise's own Tabs block, because it looks close enough visually.
A custom imitation has no guarantee of carrying the same ARIA roles or keyboard behavior the native block is built with. Whatever accessibility support the native Tabs block has, documented or reported, doesn't automatically transfer to a lookalike built from generic objects.
✓ Correct
The same comparison is built using Rise's native Tabs block, then tested directly, with keyboard alone and with a screen reader, rather than assumed to work because it looks right.
Using the native block is the only way to benefit from whatever accessibility work Articulate has actually put into it, and testing the result directly is what turns an assumption into an actual answer for this specific course.
Best practices
- Use Rise's native Tabs, Accordion, or Flashcards block, not a custom-built imitation.
- If your course reaches JAWS users, test with JAWS specifically, not only NVDA.
- Test the published course, not just the authoring preview.
- For Tabs, confirm the panel content itself is announced after selecting a tab, not just the tab's label.
- For Flashcards, confirm the flip fires from a key press alone, with no mouse involved.
Common mistakes
- Assuming Tabs and Accordion are interchangeable -- they signal different things to a learner (parallel options vs. sequential chunks), independent of any accessibility question.
- Building a custom imitation of Tabs or Accordion instead of Rise's native block.
- Testing only with NVDA and assuming JAWS behaves the same way.
- Treating a passing keyboard-reachability check as proof the screen reader announcement is also correct.
Practical checklist
- Built with the native Rise block, not a custom imitation.
- Tab and arrow-key tested for full keyboard operability.
- Tested with JAWS, with panel or body content specifically confirmed as announced, not just the tab or header label.
- Cross-checked with NVDA for comparison.
- For Flashcards, the flip itself confirmed to fire on a key press.
How A11yCheck reviews this
A11yCheck's accessibility scan checks keyboard reachability and accessible names for interactive elements it successfully reaches inside a Tabs, Accordion, or Flashcards block, as part of its general accessibility review. Reaching everything inside these blocks isn't guaranteed on every scan, navigating into and expanding Rise's interactive blocks is itself something the scan can partly succeed or partly fail at, which is why A11yCheck separately flags when an accordion, tab set, or flashcard wasn't fully expanded or navigated during a scan, as its own disclosed coverage note rather than folding it silently into the accessibility results. A11yCheck does not run JAWS, NVDA, or any screen reader, has no dedicated check for Tabs, Accordion, or Flashcards blocks specifically, and cannot determine whether a screen reader actually announces a tab panel's content or whether a card flip fires from a key press. Confirming the behavior described on this page requires testing with a real screen reader, not an automated scan.
Frequently asked questions
Is Rise Tabs officially confirmed as inaccessible by Articulate?
No. Articulate's own "Choosing Accessible Components" guide lists Tabs, Accordion, and Flashcards under components that support accessibility. Articulate's Accessibility Maturity Plan, which tracks specific known issues, lists no issue for any of these three blocks by name.
Where does the JAWS reporting evidence actually come from?
Several threads in Articulate's own community forum (E-Learning Heroes) have titles describing JAWS reading a Tabs block's label but not its panel content. Those threads were not directly accessible to us while researching this page, so what's reflected here is the general substance of those reports, not a word-for-word reading of the original posts, their exact dates, or any replies.
Has A11yCheck tested this directly?
No. A11yCheck has not independently reproduced the JAWS behavior described above, and doesn't run JAWS, NVDA, or any screen reader as part of its scan.
Should I use Accordion instead of Tabs to be safe?
If your content is genuinely parallel content a learner only needs one part of at a time, Tabs fits that structure. If you're specifically concerned about JAWS users, Accordion is the alternative more often mentioned in the reports above, though it isn't described as flawless there either, some of the same discussions mention an accordion header being read while the body text underneath is occasionally missed. Test whichever one you use.
Are Rise Flashcards keyboard accessible?
Articulate lists Flashcards as accessibility-supporting. The specific thing worth testing yourself is whether the card-flip fires from a key press alone, since a flip effect is easy to build so it only responds to a mouse.
Does A11yCheck's scan test Rise Tabs with JAWS?
No. A11yCheck's scan checks general keyboard reachability and accessible names for elements it reaches inside these blocks. It does not run JAWS or determine what a screen reader actually announces.
Related Guides
The Complete Guide to Rise 360 Accessibility→
Everything instructional designers need to know to make Rise 360 courses accessible, written for Rise specifically, not adapted from Storyline.
Accessible Names Guide→
What an accessible name is, why "Click here" fails, and how to write clear names for buttons and controls in Storyline and Rise.
How to Test eLearning with a Screen Reader→
A practical, no-fear guide to testing your own course with a screen reader, from your first NVDA install to knowing exactly what you're listening for.
NVDA vs JAWS vs VoiceOver: Which Should You Learn First→
NVDA (free, Windows), JAWS (paid, Windows), and VoiceOver (built into macOS and iOS, free) are the three screen readers worth knowing about for eLearning testing. For a first screen reader, and for most eLearning QA, NVDA on Windows with Chrome or Firefox is the right place to start.
What Screen Readers Announce in Rise→
Rise's native blocks generally announce well by default, that's one of the real advantages of building in a block-based tool. The gap almost always shows up in the same place: an Embed block carrying custom HTML that Rise has no control over.
Summary
Articulate officially lists Rise's Tabs, Accordion, and Flashcard blocks as accessibility-supporting components. Separately, several Articulate Community threads describe JAWS reading a Tabs block's label without reading its panel content, a reported behavior, not an Articulate-confirmed defect, and one A11yCheck has not independently reproduced. If JAWS-using learners matter for your course, test the block you use directly, with JAWS specifically and NVDA for comparison, using Rise's native block rather than a custom imitation either way.
Review your course before you publish it.
A11yCheck reviews Storyline and Rise courses for:
- Accessibility
- Course Quality
- Course Engagement
www.a11ycheck-dev.com