Accessibility

What is accessible today, how it is enforced in code, and what remains: the published course output, the authoring tool itself (ATAG), and the automated checks that gate regressions.

Last reviewed October 3, 2026

Scormbusters treats accessibility as a property of the product, not a checkbox in a marketing table. This page states what we support, how it is enforced in code, and what is not done yet. It covers two different things, because they are different things:

The output — the courses you publish (in-app player, SCORM/HTML5 exports) that learners experience.
The authoring tool — the editor itself, which an author using a screen reader or keyboard must be able to operate. (Most vendors publish nothing about this; ATAG — the Authoring Tool Accessibility Guidelines — is the relevant standard.)

Published output

Target: WCAG 2.1 AA, with WCAG 2.2's dragging-movements criterion (SC 2.5.7) treated as in scope even though most of the industry formally concedes it.

What is implemented and enforced by code today:

Drag interactions work without dragging, by pointer *and* by keyboard. Matching and sortable are select-then-place: tap the thing, tap where it goes. Dragging is one route to that, a single tap is another, Enter/Space is a third. The distinction matters and is the one most conformance reports get wrong — **SC 2.5.7 asks for a single-pointer alternative, not a keyboard one**. Someone on a head pointer or a switch-adapted mouse can press but cannot drag, and a keyboard path does nothing for them; that satisfies SC 2.1.1 and leaves 2.5.7 failing.

Until 2026-09-17 this page claimed 2.5.7 on the strength of the keyboard path alone. That was wrong, and it is recorded here rather than quietly edited. The single-pointer path now exists and apps/web/lib/__tests__/dragging-alternatives.test.ts fails if either block loses it. The leading desktop authoring tools mark this criterion "Does Not Support" in their own reports.

Block hotspot and categorise questions need no pointing or dragging. hotspot_question is answered by choosing areas by name from radios (or checkboxes when several are right); the picture is outlined and numbered to match, and clicking an area only picks its choice. categorize is a labelled drop-down per item. After checking, each choice and item says in words whether it was right and where it belonged. Captivate hotspot and drag-and-drop questions import into them, and the editor's checker flags areas with no descriptive name.
Scenes matching, sequence and hotspot questions need no dragging at all. They are what Storyline and Captivate drag-and-drop and hotspot questions import as. Every step is a single tap on a native control — a dropdown per item, Move up / Move down buttons, a radio button per area of the picture — so they are operable by single pointer and by keyboard alike, announced by what they are, graded the same in preview and in the LMS, and reported as SCORM matching, sequencing and choice interactions. A hotspot is answered without sight by choosing among its areas by name, so preflight warns when an area is called only "Area 2" or the picture has no description.
Captions are rendered wherever they are stored (SC 1.2.2) — in the player and in exports.
Focus visibility in exported packages (SC 2.4.7).
Correctness is never color-only — fill-in-blank and quiz feedback carry text/iconography, not just red/green (SC 1.4.1, 1.3.3).
Language declared from the course locale, not hardcoded (SC 3.1.1).
`prefers-reduced-motion` respected in the player and exports.
Editor-side audit: the Scenes editor ships a WCAG audit panel (alt text, tab order, contrast, reading order) and scene objects carry first-class accessibility fields (alt text, ARIA attributes, focusability, tab order).

Known gaps in the output today:

A formal, third-party-audited ACR (Accessibility Conformance Report) has not been produced yet. The intent is a WCAG-EM-scoped audit published on this site — not a PDF on a file-sharing link.
Scenes' free-form drag_item / drop_zone objects can be operated without dragging (select an item, then a zone) in both players, but they are not scored or reported to the LMS. For anything graded, use a matching or sequence question; the importers already do.

The authoring tool itself

Target: ATAG 2.0 Part A (the authoring UI is accessible) and Part B (the tool helps authors produce accessible content).

On 2026-09-17 the authoring UI was audited against WCAG 2.2 AA and ATAG 2.0 Part A, and it failed several Level A criteria. What that audit found and what has been done about it, rather than a summary that flatters either:

The Scenes canvas was unusable without a mouse. Objects rendered as bare divs with no tab stop, so an object could not be selected — and every other gesture in the editor, including the whole properties panel, operates on a selection. Slide and layer rows were non-focusable onClick divs, so there was no way to change slides. Reordering was HTML5 drag-and-drop, which is never keyboard-operable.

Now: objects are tab stops that announce their type and selection state, Enter selects, Shift+Enter extends, F2 edits text, arrows move and Alt+arrows resize. Slide and layer panels are listboxes with roving tabindex — arrows navigate, Alt+arrows reorder, F2 renames, Delete removes. Tested in apps/web/lib/__tests__/editor-keyboard.test.ts.

About 45 Properties-panel controls had no name. The captions beside them were spans, so a screen reader announced "edit blank" for X, Y, width, height, rotation, every colour and all sixteen selects. The panel's input primitives now require a name in their type signature, so a control cannot ship without one.

Text contrast failed systemically. text-gray-400 was the most-used text colour in the app at 2.5:1 on white, and it was also the placeholder colour — so on placeholder-labelled fields the only visible name was the least readable text on the page. The dark course sidebar reached 1.22:1. Corrected across 68 files and held by apps/web/lib/__tests__/contrast.test.ts, which computes the ratios rather than trusting a convention.

The app now ships a dark theme (system preference by default, with a manual override). Dark is not exempt from the same bar: the design tokens live as paired light/dark values, text and surface roles are split where one value cannot pass as both (an accent that is a button ground needs 4.5:1 under white label text *and* 4.5:1 as link text on the page ground — in dark mode those constraints exclude each other, so text-cobalt and bg-cobalt resolve to different values), and the contrast test asserts every token pairing the UI uses — ink on all three grounds, white labels on every accent, accent text on grounds and washes — in both themes.

Nothing was ever announced. The app-wide toast — the only feedback channel, covering every save, publish and delete — had no live region. Sign-in, sign-up and password-reset errors were unassociated coloured text, so a screen-reader user who mistyped a password heard silence. Both fixed.

Also fixed: a skip link with a target on every page that has a main landmark; page titles on all 51 pages (7 had them); and single-character tool shortcuts no longer fire while the author is typing into slide text, which was both a functional bug and an SC 2.1.4 failure.

Not yet done, stated plainly:

**No ACR or VPAT is published for the authoring tool, and publishing one today would be premature.** The remediation above is recent and unaudited by anyone outside the project. The intent is a third-party WCAG-EM assessment, published on this site, with honest "Partially Supports" rows — not a self-graded PDF.
Freeform canvas editing without sight remains an unsolved interaction problem across the industry. Keyboard operability is not the same as a good screen-reader experience, and we claim only the first.
A full screen-reader pass (NVDA, JAWS, VoiceOver) has not been run.
Remaining known gaps are tracked per-criterion with file references in the project's internal pre-deploy log.

Why this page exists

No mainstream authoring vendor publishes a conformance report for its authoring application — only (sometimes) for published output, and those reports concede keyboard access for the interactions that matter most in eLearning. Accessibility procurement teams deserve better than that, and every claim here can be checked against an exported course, which keeps this page honest.

If you find an accessibility defect, please open an issue — they are triaged as bugs, not feature requests.

The public, always-current version of this page is /accessibility-conformance on the marketing site (the domain is deployment-configured); this file is its working copy in the repository.