SCORM Experts / Building it

Accessibility does not come from the standard

A conforming package can be completely unusable.

The packaging standard says nothing about whether content can be operated by keyboard, read by a screen reader, or understood at a reasonable contrast. It describes the container, not the cargo. A package can be perfectly conformant and impossible for a substantial number of people to use, and it will import and report completion cheerfully throughout.

This surprises people because the two subjects are discussed in the same conversations and by the same teams. But conformance testing tools check the manifest and the tracking calls. They do not check whether the interaction that requires a precise drag is achievable without a mouse, and nothing in the import process will object.

The practical consequence is that accessibility has to be tested separately and deliberately, on the built package rather than on the design, because authoring tools frequently generate markup that undoes what the author intended. Keyboard operation and screen reader behaviour are the two checks with the highest yield, and both can be done by a person in an afternoon.

Where content is bought rather than built, this is a question to ask before purchase and to write into the arrangement, because it is very difficult to remediate a package you did not author and cannot open.

Where content is being commissioned rather than bought off a shelf, accessibility belongs in the specification alongside the licence terms and the source files, because it is far cheaper to require than to remediate. The specification does not need to be elaborate: keyboard operability, meaningful text alternatives, sufficient contrast, and no interaction that depends on precise pointer control. Those four cover most of what actually excludes people, and they are testable on delivery rather than taken on trust.