Accessible assessment procurement: requirements you can test

Test the full assessment workflow

Test accessibility during authoring, import, delivery, feedback, reporting, and export. An accessible item may still fail in a delivery system with poor focus management or incorrect time accommodations. An accessible interface cannot repair an inaccessible question.

Map all of the following workflows that are in scope:

• Create and revise an item.
• Import an existing bank.
• Add alternatives, instructions, and support materials.
• Preview with candidate preferences.
• Assemble and schedule an assessment.
• Launch from the learning management system (LMS).
• Navigate, answer, review, and submit.
• Receive validation, feedback, and scores.
• Review results as an instructor or administrator.
• When the contract ends, export content and evidence.

Put each workflow into the requirements and test plan.

Name the standard and scope

Unless your institutional policy sets a stronger target, require WCAG 2.2 Level AA for web content and candidate-facing interfaces. Name the product version, surfaces, browsers, assistive technologies, and exceptions covered by the supplier’s evidence.

WCAG conformance applies to complete pages and processes. Do not accept a statement that only a component library or marketing demo meets the standard.

For authoring, use the Authoring Tool Accessibility Guidelines (ATAG) 2.0 as a framework for two questions:

1. Can authors with disabilities use the authoring tool?
2. Does the tool help all authors produce and preserve accessible content?

Even when ATAG conformance is not a contract requirement, those questions reveal whether accessibility is part of the workflow.

Require test results

“Accessible,” “supports screen readers,” and “designed to WCAG” are not test results.

Request the following evidence:

• A current accessibility conformance report with product and version
• Unresolved exceptions and remediation dates
• Automated test scope and rules
• Manual keyboard test scripts and results
• Assistive-technology combinations and results
• Usability research involving people with disabilities, where available
• Representative QTI items and expected behavior
• Defect examples showing triage, fix, and retest
• Accessibility documentation for authors and administrators
• Release controls that prevent regression

Your institution should be able to reproduce important results in a sandbox.

Test representative item families

Choose items by interaction model and risk. Include the following item families:

• Single and multiple choice
• Text entry and extended text
• Ordering and matching
• Drag, pointer, and coordinate interactions
• Math and scientific notation
• Images with short and long alternatives
• Audio and video
• Tables and structured passages
• Validation errors and response limits
• Timed assessments
• Saved attempts and return visits
• Feedback and score review

Do not replace the hard interactions with a simple multiple-choice demo.

Verify keyboard operation

Every action needs a keyboard path. Test entry into the assessment, item navigation, response entry, review flags, validation, submission, dialogs, help, and exit.

Check the following keyboard behavior:

• Focus is visible and follows a logical order.
• Instructions explain nonstandard keys.
• Focus does not move unexpectedly.
• Drag-and-drop has a keyboard alternative.
• Timeouts and updates do not strand focus.
• Errors move or point to a useful location without losing the response.
• Keyboard shortcuts do not conflict with assistive technology.

Record the expected focus sequence in acceptance tests for complex interactions.

Verify names, roles, states, and instructions

Screen reader output should identify the prompt, interaction, available choices, constraints, current value, validation state, and feedback without forcing the candidate to infer the visual layout.

Test at least the combinations named in your institution’s support policy. Different browser and screen reader pairs can expose different problems, particularly around forms, live updates, and custom widgets.

One correct screen-reader announcement is not enough. Test whether the candidate can finish the workflow.

Evaluate authored content

The system should prevent or flag the following content barriers:

• Images without meaningful alternatives
• Links with unclear purpose
• Headings used for visual size rather than structure
• Tables without usable headers
• Instructions based only on color, position, or shape
• Media without captions or transcripts
• Low contrast in authored colors
• Math that becomes an image without equivalent meaning
• Inaccessible custom interaction markup

The author must be able to fix the problem without editing raw XML. Imported accessibility information should survive editing and export.

Separate preferences from content

Question and Test Interoperability (QTI) 3 includes support related to Personal Needs and Preferences (PNP), but your institution still owns sensitive candidate records, accommodation decisions, consent, and policy.

Ask which system stores preference data, who can read it, how the system sends it to the delivery service, which preferences the service applies, and what happens when an item conflicts with a preference.

The supplier should not imply that QTI itself grants accommodations or resolves institutional policy.

Test zoom, reflow, contrast, and motion

Candidate interfaces must remain usable at required zoom and viewport sizes. Test content reflow, sticky controls, dialogs, tables, response options, and item navigation.

Check operating-system contrast modes where they are in scope. Do not rely on color alone for selected, correct, incorrect, or disabled states. Respect reduced-motion preferences and avoid motion that is essential to understanding an item.

Cover time and interruption

Time limits and lost session state can prevent a candidate from completing an assessment.

Require evidence for the following time and interruption behavior:

• Warning before a timeout
• Extending or disabling time according to policy
• Preserving responses during network interruption
• Resuming after authentication or device failure
• Announcing time changes without constant interruption
• Handling extra-time accommodations across LMS and assessment boundaries
• Providing human support without exposing answers or candidate data

Test these paths in both the assessment product and the integrated institutional environment.

Check exported content

Your institution should be able to export items with alternatives, support materials, language, metadata, response processing, and assets intact.

Provide suppliers with representative sample content during evaluation. Validate the returned package and import it into another relevant system. Compare the content and candidate behavior.

1EdTech recommends current QTI certification for relevant authoring and delivery roles in procurement guidance. Verify any claimed certification in the current 1EdTech listing and confirm that it applies to the proposed product and version.

Write remediation terms

The contract should define the following remediation terms:

• Severity based on user impact
• Acknowledgment and remediation targets
• Temporary workarounds
• Retest responsibility
• Communication to affected users
• Regression handling
• Access to release notes and known issues
• Escalation when a high-impact barrier remains

Require a named owner on both sides. A backlog without dates does not protect candidates.

Run institutional acceptance tests

Use supplier reports to plan your own tests. Run those tests with your LMS, identity system, supported browsers, content, accommodation process, and support model.

Keep the acceptance suite and run it against later releases.