Accessible QTI 3 authoring: from item design to delivery

Set the review scope

Use this guide when your institution approves new assessment items or remediates an existing bank. The review follows the item from the editor into the system candidates use. The general QTI authoring guide covers declarations, scoring, and packaging; this guide covers the accessibility decisions within that process.

Assign an item author, an accessibility reviewer, and a delivery-system owner. The author supplies content and alternatives. The reviewer checks whether people can use them. The delivery owner verifies that the exported item works with the institution’s candidate interface and accommodation settings.

1EdTech’s accessibility guidance describes this shared responsibility: QTI can carry accessible content, but authors must create it and delivery applications must make it work.

Define what the question measures

Write a short statement of the skill or knowledge the item assesses. Use that statement when choosing an interaction or an alternative presentation.

For example, an item that asks candidates to order laboratory steps may assess their understanding of the sequence. Moving those steps with labeled buttons can preserve that task. An item that asks candidates to interpret a graph needs closer review: a description that states the conclusion could give away the answer.

Record what information each candidate receives, what action demonstrates the skill, and which changes could alter the assessment. When a text presentation would invalidate a test, WCAG’s non-text-content guidance allows descriptive identification rather than a full text equivalent. That exception does not resolve the institution’s decision about an appropriate alternative assessment.

Review the editor and its output

An author with a disability must be able to create, correct, preview, and export the item. The authoring tool must also help authors preserve accessible content. These are the two areas addressed by Authoring Tool Accessibility Guidelines (ATAG) 2.0.

Try the ordinary editing workflow with a representative item. Check whether an author can add an image description, set language, edit instructions, repair a validation error, and export without editing raw XML. Then reopen the item and inspect the export. Record any field that the editor removes, rewrites, or hides from the reviewer.

Make instructions and alternatives part of the item

Keep instructions close to the response they govern. State required selections, limits, and units explicitly. Use meaningful headings and table headers, identify language changes, and avoid instructions that depend only on color or position. Check these features against WCAG 2.2.

For a graph or diagram, provide a short identification and a detailed description where needed. The description should preserve the information relevant to the task without adding an interpretation the candidate is expected to make. W3C’s complex-image guidance explains ways to associate short and long descriptions with an image.

Include required captions, transcripts, audio descriptions, and math representations in the item review. Check their accuracy with a subject specialist. Store each supporting asset with a stable reference and verify that it survives export. A transcript available only in the editor’s media library will not help a candidate in another system.

Test response entry, correction, and feedback

Have the reviewer complete each response without a mouse. Check visible focus, instructions, control names, selected values, and the ability to change or clear an answer. Submit an incomplete response and verify that the message identifies the problem without losing entered work.

For dragging interactions, test a separate pointer path that does not require dragging, such as selecting an object and then its destination. Keyboard support alone does not meet the single-pointer requirement described in WCAG’s dragging-movements guidance.

Compare the recorded response and score across input methods. A keyboard alternative that selects a different identifier or changes the order of answers can change the result. Include correct, incorrect, unanswered, and partially completed responses in the review.

Test feedback at the intended time. Candidates should receive the approved explanation after a valid submission, and an unsuccessful scoring operation should not present an apparently final result. Check response restoration as well: a candidate who returns to a saved item needs the same value, instructions, and permitted feedback.

Verify approved supports in delivery

QTI 3 supports Personal Needs and Preferences (PNP) data and catalogs of alternative or supplemental content. These can support features such as spoken content and language alternatives. Your institution decides which supports apply; the delivery system must resolve and present them. 1EdTech explains PNP and QTI supports.

For each required support, record the content asset, the enabling preference, and the expected candidate behavior. Test both an enabled and a disabled case. If the support cannot load, decide how the assessment pauses or provides help before launch. Keep private candidate and accommodation records outside the portable item package.

Test the item within the complete assessment process. Extra time, breaks, sign-in, navigation, and submission depend on the host service. The secure assessment delivery guide covers those responsibilities.

Use public tests to define acceptance checks

Longsight’s September 28 review of qti3 includes browser tests for keyboard response entry, accessible control names, focus, response limits, and feedback. The QTI implementation matrix links the reviewed code and the test report.

One example is the ordering-interaction test. It uses keyboard controls to reorder choices and checks the recorded response. The validation tests check how unanswered controls connect to error messages. These are useful starting points for an institutional acceptance test.

Your reviewer must still use the supported browser and screen-reader combinations to finish the task. Our automated review did not use screen readers or test your institution’s editor and delivery service. The repository’s manual review scripts provide procedures for that additional work.

Check the exported package

Run this sequence with one approved sample from each item family, including your most complex items:

1. Record the source item revision, required supports, expected responses, and scores.
2. Export the item and its supporting assets from the editor.
3. Run the separate checks in the QTI validation guide.
4. Import the package into the intended destination system.
5. Repeat the accessibility tasks and scoring cases against that imported copy.
6. Record losses, defects, owners, and retest results before approval.

Repeat the check after editing an imported item. A successful first import does not show that the receiving editor preserves descriptions, language, catalog references, or response rules when saving a revision.

Record approval and unresolved barriers

Keep the item revision, destination version, browser and assistive technology, reviewer, date, expected behavior, and observed result. Name the owner and retest date for each barrier. Record an untested workflow as untested.

Use the accessible QTI authoring worksheet for the review. If you are selecting a supplier, use the accessible assessment procurement guide to put the required evidence and remediation responsibilities into the evaluation.

For a QFlowLearn evaluation, take the same samples through its authoring workflow. For help defining your institution’s review scope, contact Longsight.