ScormStack: A Clean Scan vs. a Screen Reader

Update, November 6, 2026: ScormStack Responded

Their response

ScormStack thanked me for the report and listed the fixes they'd made. They wrote that their automated and keyboard checks pass, but that they aren't treating the report as resolved on the strength of those checks alone, and that "a clean FastPass result is not proof of accessibility." They gave permission to include their response here.

What I rechecked

I retested the main issues with NVDA and Edge on November 6 and checked the rest in the course's code. "Code" means I confirmed the change in the markup but haven't tested it with NVDA yet.

Drag-and-drop after the fixes

That's real progress: the item can be moved and dropped, and the result is announced. But a learner still hears "item-4" and "cat-3" rather than "Recursion" and "Advanced", so they can't tell what they're moving or where it landed without looking.

The new way to report a problem

ScormStack added an accessibility statement and a Contact page. Both point to a support chat. I tested it with NVDA:

• The chat takes focus when it opens, landing on the message box, and its buttons are labeled.
• A "Quick Actions" menu works with Tab and Browse Mode, but not with arrow keys.
• Writing in the evening, French time, I got a message that the team was offline and would email me. But the chat never asked for my email address, and I wasn't signed in.
• On the Contact page, NVDA started reading an "offline" alert, but the chat's autofocus cut it off, and I couldn't find the message anywhere on screen.

The chat is mostly accessible, and having a reporting route at all is a real improvement. But a learner who hits a barrier outside office hours still needs a way to be heard. An email address or a form alongside the chat would close that gap.

The rest of this page is the original teardown, kept as a record of what I found before ScormStack's fixes.

Summary

A colleague evaluating e-learning authoring tools asked me whether ScormStack lives up to its accessibility claims. In "ScormStack's WCAG Accessibility Support Was Built In From Day One" (opens in a new tab), ScormStack presents a FastPass accessibility report (opens in a new tab) as evidence of its platform foundation: 0 failures, 0 incomplete checks, 45 passed checks.

So I tested the exact course that report was run against, using NVDA, the way a learner who relies on a screen reader would. Plain content reads well. But every interactive block I tried had at least one screen reader problem. The matching activity can't be completed with a keyboard at all. The assessment block, which matters most for compliance training, isn't much better: feedback is silent in NVDA's Focus Mode, the answer options don't respond to arrow keys, and focus repeatedly lands somewhere other than where the learner needs to go next.

Why a Clean FastPass Isn't Enough

FastPass is a quick check in Microsoft's Accessibility Insights for Web. It runs automated axe-core rules, plus a short guided check of Tab stops. It's a good first step, and ScormStack's blog does acknowledge that it isn't a full WCAG audit. But automated rules can only test a portion of WCAG. They can confirm that an image has alt text, but not that the alt text is meaningful. They can confirm that an element has a role, but not that it behaves the way that role promises. They can't hear what a screen reader announces.

The blog goes on to say that accessibility "includes automated validation, manual keyboard testing, assistive technology testing", but the scan is the only evidence the post offers. Several of ScormStack's specific claims, on the blog and on its WCAG support page, don't hold up when tested with a screen reader.

What They Claim vs. What I Found

Claims are quoted from the blog post and from ScormStack's WCAG support feature page (opens in a new tab), which the site's menu labels "WCAG compliance".

No Clear Way to Report a Problem

Before publishing, I looked for a way to send these findings to ScormStack. There's no Contact page, and the WCAG support page has no accessibility contact or feedback link. The only contact form on the site is for enterprise sales.

The one general address I found, hello@scormstack.io, is listed in the privacy policy. That isn't where a learner who gets stuck in a course would think to look. A screen reader user who can't complete an activity has no obvious way to tell anyone.

An accessibility statement with a named contact and a feedback route is standard practice, and it's what makes a promise to "keep listening" real.

How I Tested

• Setup: NVDA (current release as of June 2026) with Microsoft Edge on Windows 11.
• Content: ScormStack's own preview course, the one named as the target page in its FastPass report. It includes text and images, flashcards, an open response question, a rating question, and a scored assessment.
• Approach: Navigated in both Browse Mode and Focus Mode, by arrow keys, Tab, and single-key navigation (headings, landmarks, form fields). Recorded what NVDA announced at each step.
• Scope: This is a teardown, not a full WCAG audit. It covers screen reader and keyboard behavior. It doesn't cover color contrast, reflow, or other visual criteria, and apart from the radio button markup, I didn't inspect the source code, so other causes I suggest are informed guesses.

Findings at a Glance

High means a screen reader user is likely to get stuck or misled during a core task. Medium means the task is possible but takes significant extra effort. Low means friction or noise. Items marked best practice aren't strict WCAG failures but still affect the experience.

The Matching Activity

Matching activity can't be completed with a keyboard

WCAG: 2.1.1 Keyboard (A); 4.1.2 Name, Role, Value (A) · Severity: High · Found: November 2026 recheck

The "Match Related Items" block asks learners to "draw lines to match the related items between the two columns." With a keyboard, I could pick an item up and put it down, but nothing in between worked. Arrow keys produced no announcement and no visible movement, and every drop ended with no match made. In over a minute of trying, I couldn't complete a single match.

Almost every announcement in that clip has a problem of its own:

• Raw HTML in the names. Each item's aria-label includes its markup, for example "Match item: <p>Respiration</p>", so NVDA reads out "less p greater" around every term.
• An untranslated placeholder. Where the keyboard instructions should be, NVDA reads the internal text key matching.keyboard_hint.
• Internal IDs instead of names. Pick-up and drop announcements name the item "left-2" rather than "Transpiration", and never say where the item is or which definition it's over.
• Contradictory instructions. The label says "Space or Enter to select and match". A hidden description says to pick up with Space, move with the arrow keys, and drop with Space. Neither approach makes a match.
• French in an English course. The progress counter reads "1 sur 3 réponses" with English pronunciation (see the language finding).

The instructions ("To pick up a draggable item, press the space bar…") and the "Picked up draggable item" / "was dropped" announcements match the defaults of dnd-kit, a popular drag-and-drop library. dnd-kit expects developers to replace those defaults with announcements that name the item and its drop target. Here they've been left as they are, on an activity that matches items by drawing lines, not by moving them.

Fix: Give the matching activity a non-drag alternative that works by keyboard and screen reader. For example, select a term, then select its definition, with each step announced: "Respiration selected. Now choose its match." Then "Respiration matched with Process of converting glucose to energy." Use plain-text names, finish the translations, and test the result with NVDA and JAWS.

The Assessment Block

Assessment feedback is silent in Focus Mode

WCAG: 4.1.3 Status Messages (AA) · Severity: High

After choosing an answer and pressing Submit in Focus Mode, NVDA says nothing. The feedback is on the page, but the only way to find it is to switch to Browse Mode and arrow around. In Browse Mode the feedback is read right away, which suggests it isn't exposed as a status message and only gets read because Browse Mode follows the page change. The feedback also appears beside the selected answer, above the Submit button, so reaching it means moving backward and then past the now-unavailable answer options again.

Answer options don't behave as a radio group

WCAG: 1.3.1 Info and Relationships (A) · Severity: Medium

Standard radio buttons are one Tab stop: you Tab into the set and use the arrow keys to choose. Here each option is its own Tab stop and has to be selected with Space. A keyboard user gets a different, slower pattern than every other form they use.

The code explains why. Each answer is a div given role="radio", and each one is its own Tab stop. Trimmed to the parts that matter:

<div data-slot="assessment-choices">
  <div role="radio" aria-checked="false" tabindex="0"
       aria-labelledby="…choice-1-1-label">…</div>
  <div role="radio" aria-checked="false" tabindex="0"
       aria-labelledby="…choice-1-2-label">…</div>
  …
</div>

Three things are missing. The wrapper has no role="radiogroup", so assistive technology isn't told the four answers belong together. Nothing connects the group to the question it answers. And every option has tabindex="0", when the radio pattern calls for only the selected (or first) option to be in the Tab order, with arrow keys moving between options. Native <input type="radio"> elements sharing a name and wrapped in a <fieldset> with a <legend> would provide all of this for free.

Focus lands in the wrong place after key actions

WCAG: 2.4.3 Focus Order (A) · Severity: Medium

• Try Again: focus stays on the attempts-remaining message. The learner has to move backward to find the answer options.
• View Results: focus jumps to the "Review Questions" button, past the results themselves.
• Edit Response (open response question): focus goes to the Submit button instead of the text box the learner wants to edit.

Results aren't announced, and the score isn't labeled

WCAG: 4.1.3 Status Messages (AA); 1.3.1 Info and Relationships (A) · Severity: Medium

After View Results, nothing is announced. Navigating back to the results, NVDA reads:

"Assessment passedRequired: 60%" / "100%" / "1/1 Correct"

"Assessment passed" and "Required" run together as one line, and "100%" has no label, so a learner has to guess that it's their score. Clearer: "Assessment passed. Required: 60%. Your score: 100%. You got 1 of 1 correct."

Question heading reads only "1/1"

WCAG: 2.4.6 Headings and Labels (AA) · Severity: Low

The word "Question" is plain text, and the heading is just "1/1". Someone jumping by heading lands on "heading level 2, 1/1" with no idea what it is. "Question 1 of 1" as the heading fixes it.

What the Assessment Should Do

Rather than leave the vendor with a list of problems, here is the flow a screen reader user would expect from a quiz block:

1. The answer options are one radio group. Tab moves into the group; arrow keys choose an answer.
2. Tab moves from the group to Submit.
3. On Submit, the result ("Correct" or "Incorrect", plus any feedback) is announced automatically, in both Browse and Focus Mode. The feedback sits after the Submit button in reading order, or in a dialog that manages focus properly.
4. On Try Again, a status message announces the attempts left (for example, "Attempt 2 of 3") and focus returns to the answer group.
5. On View Results, the results are announced, with every number labeled.

Content Blocks

Internal block names and IDs are announced as regions

WCAG: Best practice · Severity: Medium

Every block in the course is a named region, and the name is ScormStack's internal block type and ID. Even a purely decorative separator gets announced, and every block is also reported as "clickable". The main landmark is announced as "Slide Intro Block" instead of just "main". Because the ID comes in the same breath as the role and state, the announcement is long and the useful part is easy to miss. It's noise a learner hears on every block, on every page.

Fix: Don't name blocks as regions. Keep landmarks for real page structure, mark decorative separators as decorative, and leave block IDs out of anything assistive technology reads.

Image alt text is a file path

WCAG: 1.1.1 Non-text Content (A) · Severity: Medium

A "happy customers" image was announced as "Click to enlarge: media/happy_customers_u1l44wk.png". A file name tells the learner nothing. The tool should prompt authors for alt text, let them mark images as decorative, and never fall back to the file path.

"Click to enlarge" gives no feedback

WCAG: 4.1.2 Name, Role, Value (A) · Severity: Medium

Pressing an image's "Click to enlarge" button produced no announcement, no dialog, and no change in focus. Whatever it does visually, a screen reader user can't tell it did anything. That matters for low-vision NVDA users who would actually use a zoom feature, a group that will grow as NVDA adds built-in magnification.

Flashcard pagination doesn't say which card is current

WCAG: 4.1.2 Name, Role, Value (A) · Severity: Low

The Previous and Next buttons are done well: they're correctly announced as unavailable at either end. But the numbered buttons all read "Go to card 1", "Go to card 2" and so on, with no indication of which one is current. All three cards can also be read just by arrowing down, so it's unclear what the pagination is for. If the flashcards are meant to work like a carousel, the cards not on display should be hidden from screen readers too.

Single-choice rating uses toggle buttons

WCAG: Best practice · Severity: Low

The "How do you feel about this content?" question uses toggle buttons, and pressing one turns the others off. That is radio button behavior. Toggle buttons tell a screen reader user each option is an independent on/off switch, so they can't predict what pressing one will do. A radio group communicates "pick one" and supports arrow keys.

Course Shell

French player controls are read with an English voice

WCAG: 3.1.2 Language of Parts (AA) · Severity: Medium · Found: November 2026 recheck

The course is marked as English (<html lang="en">), but parts of the player are in French: the Submit button reads "Envoyer", navigation reads "Suivant" and "Précédent", the attempts counter reads "3 essai(s)", and the objectives heading reads "Objectifs d'apprentissage". None of it is marked as French, so NVDA reads it with English pronunciation and the words come out garbled. A learner who doesn't read French also can't tell what the Submit button does.

This is a Level AA failure on the same page the FastPass report shows with 0 failures. Automated rules can check that a page declares a language, but not whether the text matches it.

Fix: Translate the player's interface into the course's language. If mixed languages are intended, mark each French phrase with lang="fr".

Leftover busy indicator and two H1s

WCAG: Best practice · Severity: Low

• Right after the course title, NVDA announces "Course Progress Busy Indicator". The loading spinner seems to stay in the accessibility tree after loading finishes.
• The progress text reads as one run-on string: "0% COMPLETEDSCORE: 100%".
• The course title ("Test") and the lesson title ("Welcome to Test!") are both H1s. A single H1 makes the page outline clearer.

What Works

• Plain text content reads cleanly.
• Flashcard Previous and Next buttons correctly report when they're unavailable.
• Flipping a flashcard updates its instructions to say which side is showing.
• The open response question does announce "Response saved" after Submit, as a polite status message.
• In Browse Mode, assessment feedback is read immediately after Submit.

Related Work

Like my ClickUp review, this is one of a series of teardowns comparing vendors' accessibility claims with what users actually experience.

• ClickUp: Accessibility Platitudes vs. Practice (Substack, opens in a new tab)
• Back to the portfolio