The short version
For new implementations, start by evaluating QTI 3. It combines the QTI and Accessible Portable Item Protocol (APIP) lines, uses markup designed for modern web delivery, expands shared vocabulary, and includes accessibility support in the current specification set.
Many institutions still rely on QTI 2.x. Existing item banks, learning management system (LMS) importers, publishers, and assessment vendors may depend on a 2.x profile. Keep support for those systems until a tested QTI 3 path can replace them.
Compare the decision factors
Markup and implementation model
QTI 3 element names use a qti- form that aligns with custom-element conventions in modern web development. That makes QTI markup more recognizable alongside browser component models, though a QTI player still has to parse and implement the specification.
Changing element prefixes is insufficient. Information-model changes, accessibility structures, metadata, CSS vocabulary, and processing behavior need explicit mapping.
Do not estimate migration from line-by-line XML differences. Estimate from item families, scoring rules, assets, extensions, and destination behavior.
Accessibility
QTI 3 incorporates work that previously sat across QTI and APIP. This gives new implementations one current specification set for item content and accessibility-related structures.
Neither version makes content or delivery accessible by itself. Authors still need meaningful alternatives and instructions. Players still need keyboard support, accessible names, focus management, contrast, error handling, and candidate-preference behavior.
When comparing products, test the same representative items in each proposed authoring and delivery path.
Styling and presentation
Portable assessment content needs enough styling information to preserve meaning without importing an entire product theme.
QTI 3’s shared vocabulary gives authors and delivery systems more common terms for presentation intent. A host still needs rules for package stylesheets and candidate-safe rendering. Product-specific CSS that assumes a source application shell remains a migration risk in either version.
Review content that relies on position, color, drag behavior, fixed dimensions, or local class names.
Interactions and extensions
For each required interaction, test whether the system meets the following requirements:
- Imports the item.
- Preserves declarations and metadata.
- Lets an author edit it without flattening.
- Renders it accessibly.
- Applies constraints.
- Scores known responses correctly.
- Exports it again without material loss.
Custom and portable interactions require special scrutiny. They can preserve specialized behavior, but they increase dependency on a host contract, JavaScript security policy, packaging, accessibility work, and destination support.
Packaging and transfer
Both strategies need disciplined package handling. Verify item references, assets, styles, namespaces, metadata, and path safety.
A transfer test should begin with a clean export and end with delivery and scoring in the receiving system. When round-trip preservation matters, re-export the item. Compare identifiers, content, response processing, assets, and accessibility information.
Certification applies to a named product, version, and role. It does not transfer automatically to a fork, a later release, or another component in the same product family.
Check current 1EdTech records. Even when an official program certifies a product, keep internal support matrices and interoperability tests because institutional content and integrated workflows can expose additional failures.
When to keep QTI 2.x
Keep supporting QTI 2.x if any of these conditions apply:
- A required delivery platform has stronger verified QTI 2.x support.
- A publisher or content source cannot provide reliable QTI 3.
- A high-value item bank contains extensions without an accepted QTI 3 mapping.
- A certification or contract names a QTI 2.x role.
- Migration evidence is incomplete.
You can keep a QTI 2.x import path while using QTI 3 as the internal format or export target.
When to make QTI 3 the target
Consider QTI 3 for new development when these conditions describe your project:
- Your institution is building or replacing an authoring pipeline.
- Accessibility and current standards alignment are central requirements.
- Public or internal implementation evidence covers the required item set.
- Destination systems pass representative import, delivery, scoring, and export tests.
- Your institution can retain originals and an exception process during migration.
Set a target date and list the tests that must pass before your institution moves new authoring to QTI 3.
A practical transition
- Inventory current QTI versions, profiles, and extensions.
- Select representative and high-risk items.
- Define the QTI 3 target profile and allowed loss.
- Convert and validate a pilot.
- Test authoring, delivery, scoring, accessibility, and export.
- Keep QTI 2.x pathways for named dependencies.
- Move new authoring to QTI 3 after the target path passes.
- After usage and exception data support the decision, retire legacy pathways.
Review usage and exception data before retiring a QTI 2.x path.
