QTI v3 Best Practices and Implementation Guide
Question & Test Interoperability (QTI) 3.0 Best Practices and Implementation Guide
Spec Version 3.0
| Document Version: | 1.0 |
| Date Issued: | 1 May 2022 |
| Status: | This document is made available for adoption by the public community at large. |
| This version: | https://www.imsglobal.org/spec/qti/v3p0/impl/ |
IPR and Distribution Notice
Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the specification set forth in this document, and to provide supporting documentation.
1EdTech takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on 1EdTech's procedures with respect to rights in 1EdTech specifications can be found at the 1EdTech Intellectual Property Rights webpage: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf .
The following participating organizations have made explicit license commitments to this specification:
| Org name | Date election made | Necessary claims | Type |
|---|---|---|---|
| CITO | March 11, 2022 | No | RF RAND (Required & Optional Elements) |
| HMH | March 11, 2022 | No | RF RAND (Required & Optional Elements) |
Use of this specification to develop products or services is governed by the license with 1EdTech found on the 1EdTech website: http://www.imsglobal.org/speclicense.html.
Permission is granted to all parties to use excerpts from this document as needed in producing requests for proposals.
The limited permissions granted above are perpetual and will not be revoked by 1EdTech or its successors or assigns.
THIS SPECIFICATION IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE IMPLEMENTER'S OWN RISK, AND NEITHER THE CONSORTIUM, NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS SPECIFICATION.
Public contributions, comments and questions can be posted here: http://www.imsglobal.org/forums/ims-glc-public-forums-and-resources .
© 2022 1EdTech Consortium, Inc. All Rights Reserved.
Trademark information: http://www.imsglobal.org/copyright.html
Abstract
The 1EdTech Question and Test Interoperability® (QTI®) specification is a technical standard for digital interchange of assessment content (items and tests), assessment usage data and results reporting. Use of QTI 3.0 enables assessment materials to be exchanged digitally among a wide variety of products, such as item/test authoring products, item banks, and test delivery systems [QTI-OVIEW-30].
QTI 3.0 is based on the well established QTI standard that has been used internationally for two decades and 1EdTech Accessible Portable Item Protocol® (APIP®). QTI 3.0 adds support of digital delivery options for a range of common accessibility needs and enables transform-free authoring to delivery workflow. Implementations of QTI 3.0 may require use of related standards, including the 1EdTech Content Packaging 1.0 specification, and the AccessForAll® (AfA) 3.0 specification.
This document is the QTI 3.0 Best Practices and Implementation Guide (BPIG). The BPIG consists of six sections describing the various structures and features of QTI and how to best implement them in your assessment products.
1. Introduction
The main purpose of the Question and Test Interoperability® (QTI®) specification is to define an information model and associated binding that can be used to represent and exchange assessment content. While the QTI specification is the primary method of interoperability, QTI 3 introduces a greater amount of delivery interoperability through new formatting and behavioral expectations for interactions.
This document contains examples of QTI 3. Many of the examples are illustrated by screenshots or rendered views of the items, which are designed to illustrate how a system might implement the specification. This is a guide to best practices for QTI 3 implementation, and examples are for illustrative purposes.
Each section of this document introduces a new aspect or feature of the specification, starting with the simplest constructions and continuing to more intricate examples.
1.1 Scope and Context
The 1EdTech QTI work specifically relates to content providers (that is, question and test authors and publishers), developers of authoring and content management tools, assessment delivery systems and learning management systems. The data model for representing question-based content is suitable for targeting users in learning, education, and training across all age ranges and national contexts.
Common acronyms and terms with definitions related to assessment are included in the QTI Terms and Definitions document [QTI-TERM-30].
1.1.1 Relationship to 1EdTech Standards
QTI 3 brings together QTI 2.x and Accessible Portable Item Protocol® (APIP®) [APIP-IMPL-10] accessibility and accommodation features into a single assessment specification.
QTI 3 uses an 1EdTech Content Packaging [CP-12] specification profile to package and exchange assessment content. 1EdTech AccessForAll™ [AFA-30] specifications are used to support accessibility functionality.
The QTI 3 project group has also produced an assessment metric profile in connection to the 1EdTech Caliper Analytics® [CALIPER-11] specification.
The 1EdTech Competencies and Academic Standards Exchange® (CASE®) [CASE-10] specification is used to exchange information about learning and education competencies. CASE can also transmit information about rubrics, criteria for performance tasks, which may or may not be aligned to competencies. An example of CASE being used with a QTI package is included in BPIG section 6.
In QTI, Learning Tool Interoperability® (LTI®) [LTI-13] can be used to launch a specific interactive experience for candidates. However, externally launched tools may be blocked during assessment sessions depending on the security protocols of the assessment. The recommended practice is to use LTI only when standardized QTI approaches have been exhausted.
1.1.3 Interoperability in QTI 3
The QTI 3 standard is intended to foster interoperability of assessment-based content packages. The QTI 3 standard is comprised of a collection of specification documents designed to ensure that the exchangeable package of assessment content adheres to a rigorous set of file structure expectations. QTI 3 introduces new assessment, section, and item specifications as well as a new QTI 3 Content Package profile (based on the 1.2 version of the 1EdTech Content Package specification).
This revised item specification is enforced by a newer, more rigorous conformance process. User experience interoperability will enable content authors to produce questions and tests that render and behave consistently across systems implementing QTI 3. The resulting specification eases adoption by adding unambiguous content structural markup and accessibility information to QTI 3. The use of web-based markup (HTML5) describes assessment content and semantics, and CSS can describe how the content will be displayed to candidates, in terms of layout, colors, and animations. This helps eliminate rendering inconsistencies across platforms, and enable content authors to communicate specific formatting and rendering expectations for assessment delivery interfaces.
Delivery systems are expected to use the information supplied in the QTI 3 standardized exchange formats, but can elect to use proprietary or other delivery-focused formats during content rendering and data collection.
Within the content package exchange, there may be interoperability issues surrounding specific file formats (e.g., mime types) for some supporting media files or custom interaction code. The QTI 3 standard allows for the use of any media type at this time, so interoperability between vendors may require agreement on the provision of specific file formats. Likely areas where that would occur within the content are pre-recorded media files (audio or video-only, or audio with video) as part of an item stimulus or prompt, or as alternative or supplemental support content for specific support needs. The QTI 3 standard allows for the provision of multiple file formats, which could reduce run-time file-format incompatibility issues.
QTI 3 supports bi-directional text, Ruby Markup https://www.w3.org/International/articles/ruby/ , and vertical text (via CSS) to support internationalization.
Interoperability for QTI 3 is also supported by the use of an 1EdTech governed conformance and certification process, which employs 1EdTech provided online automated validation tools, and requires certified systems to demonstrate validation. The validation tools assist organizations by examining exchange files for structural consistency against the QTI 3 standard. (See the QTI 3 Conformance and Certification [QTI-CERT-30] documentation.)
1.1.4 Packaging
QTI uses the 1EdTech Content Packaging specification for organizing, describing, and exchanging assessment content. Section 6 of this document provides examples of 1EdTech Content Packaging for metadata and variants.
1.1.5 Future Scope
The 1EdTech members contributing to the development of the QTI 3 specification regard this version 3 as a definitive set of features and functionality relating to Web and accessibility standards that should not require significant iterative updates or changes. Correction of errors is an expected part of any specification maintenance, but the QTI project group hopes version 3 meets market demands and will not require major additions or changes in scope.
1.2 Structure of this document
This Best Practices and Implementation Guide is organized to provide an introduction to implementing QTI, constructing a QTI 3 open standards-based solution, a description of the Item and Test models at the core of QTI content, how the content interacts with the Personal Needs and Preferences of students, and how packaging brings it all together. Example markup, screenshots of rendered QTI, and details about best practices in adopting the standard are provided in this best practices guide.
1.3 Conformance Statements
This document is an informative resource in the Document Set of the 1EdTech Question & Test Interoperability (QTI) v3.0 specification [QTI-OVIEW-30]. As such, it does not include any normative requirements. Occurrences in this document of terms such as MAY, MUST, MUST NOT, SHOULD or RECOMMENDED have no impact on the conformance criteria for implementors of this specification.2. Structure of QTI 3 Assessment Content
The purpose of this section is to give a broad overview of the structure and conventions used when constructing a QTI 3 solution. The specifics of the various QTI 3 features are enumerated in the sections that follow.
The exchange of QTI 3 content can vary significantly in scope, ranging from the exchange of a package containing a single assessment item to multiple tests with various subsections, thousands of assessment items, and shared stimulus content.
QTI 3 Assessment content is exchanged in a content package, using the standardized structure of the assessment structures, including tests, sections, test-parts, shared-stimulus, and items, as well as any of the content resources (like images and media), metadata, usagedata and stylesheet references. See Section 6 for more information on content packaging for QTI 3.
Given the complexity of assessment content, the QTI 3 standard allows for fairly simple interactions and content, as well as more complex interactions and assessment structures. The needs of the assessment program generally dictate which of the many QTI 3 features are used in the exchanged content. Conformance and certification for QTI 3 features is discussed in separate documentation, QTI 3 Conformance and Certification [QTI-CERT-30].
An assessment program can optionally create content that includes additional, dormant content that is selectively presented to candidates based on their user profile. In these cases, there is a dependency between the authoring systems creating the additional content, registration systems that allow for candidates to indicate their assessment needs and preferences, and the delivery system which uses the candidate profiles to present the dormant assessment content to specific candidates.
See AccessForAll 3.0 and the QTI 3 Profile Section 5: Personal Needs and Preferences for more information on personalizing the assessment experience for candidates.
An QTI 3 assessment delivery system presents assessment content to candidates using QTI 3 for presentation of content, instructions for data collection, response processing, and scoring. There are many different ways to configure a delivery system, and QTI 3 does not dictate the architecture of these systems. The purpose of QTI 3 is to provide standardized content exchange and some basic user experience delivery expectations.
QTI 3 content is exchanged in standardized files using XML structure, where candidate-facing content is represented using a combination of HTML and XML (for the interactions). The content files may also contain template information, feedback content, or additional dormant content for specific candidates based on their Personal Needs and Preferences (PNP). QTI 3 content may reference external "web content" files, such as images, video, or audio files, which can be packaged with the QTI 3 content files to create a QTI 3 content package.
The test structures may include further information about the structure of test, including the order of possible parts, sections, and items, or even adaptive testing information, as well as outcomes processing information. The test structure may also include instructions or information which is intended to be delivered to the candidate. All tests must contain at least one test part, and all parts must contain at least one section. Sections can contain further sections, which is referred to as "nested sections" in QTI. Adaptive testing includes staged adaptive by using preconditions and branch-rules or by using an external (IRT-based) adaptive algorithm (newly introduced in QTI 3). See Section 4 for more information on the Test structure. See Section 4.3 and 4.4 for more specifics around test parts and sections.
Assessment items contain the bulk of the content that is presented to candidates, and it is the only structure which allows for candidates to respond to questions via interactions. The assessment items also contain the response processing and outcome variables which provide the correct (or partially correct) responses and how to score those responses. See Section 3 for a complete description of the assessment item structure.
Assessment items often relate to a common, shared stimulus. This shared stimulus is contained in a stimulus structure, and is referenced from an assessment item. See Section 3.7.7 for more specific information on Shared Stimulus content.
The sequence and structure of any valid QTI 3 file (tests, parts, sections, items, and stimulus) included in a content package is regulated by its associated XML Schema Definition (XSD). QTI 3 does leverage a number of W3C standards (HTML, MathML, CSS, SSML to name a few) which cannot be completely validated using the 1EdTech validators. When using these related standards, the expectation is that implementers will follow the best practices recommended for each of the standards.
The content package also provides the mechanism for resolving hrefs used in QTI content to the actual resources providing that content. In many cases the content package may resolve a href (e.g. "items/item1.xml") to a URL relative to the base href of the content package, but there are some advanced content packaging use cases which may resolve the href to a variant of the resource (e.g. a file with the item translated to a different language) or may indicate that the resource is not directly rendered by the delivery engine, but must instead be LTI launched. For more information on QTI content packages see Section 6.
2.1 Metadata
QTI 3 makes use of the following metadata standards: QTI, Learning Object Metadata (LOM), and curriculum standards.
2.1.1 QTI Metadata
This allows metadata specific to QTI 3 to be added to a QTI 3 item resource in the imsmanifest.xml file.
Full details of the QTI 3 metadata model can be found in the 1EdTech QTI Metadata Information Model and XSD Binding Version 3.0 document, but some of the defined metadata fields cover:
- the interaction types used in the item
- whether the item is a composite item
- whether the item is time dependant or not
- whether the item is adaptive or not
- whether the item will generate feedback or not, and if the feedback is adaptive
- whether the item makes a model solution available
- whether the item is a concrete instance or a template used to create a concrete instance
- how the item will be scored, by QTI response processing, by a human or by some form of external machine scoring
- some information on the tool used to author the item
2.1.2 LOM Metadata
Metadata following the 1EdTech QTI 3 profile of IEEE LOM can also be included, as well as the LOM metadata which can be applied to learning resources generally. This profile provides some rules on how to map QTI concepts to standard LOM fields. For example, that the test or item identifier should be present as an identifier in the LOM metadata. This profile also adds some additional QTI specific vocabularies as an extension to LOM. For example, it supports the Resource Discovery Network Resource Type Vocabulary (RDN/LTSN).
2.1.3 Curriculum Standards Metadata
This allows learning standards and 1EdTech CASE (Competencies and Academic Standards Exchange) identifiers to be associated with a test or item. See the example in section 6.4 on support for CASE in QTI.
2.2 Markup Languages
2.2.1 XML
The QTI Information Model [QTI-INFO-30] is defined as an eXtensible Markup Language (XML) instance and bound by a set of XML Schema Definition (XSD) files. XML is a W3C Recommendation designed to store and transport data and provides the flexibility and extensibility necessary for QTI assessment content or data to be easily organized and exchanged.
2.2.2 HTML5
Beginning in version 2.2, QTI added a select group of HTML5 elements to the standard. These elements were primarily chosen to increase the accessibility of the assessment content. QTI 3 continues to use a subset of the the complete HTML5 specification to maintain the interoperability of the content being exchanged.
In QTI 3, there is an increased emphasis on the use of HTML5 markup. While the class attribute has been available in previous versions, the use of specific QTI standardized presentation classes was developed to increase rendering interoperability. This new approach uses classes where appropriate: for specifying styling information (presentation). An enumerated, shared vocabulary of styles (prefixed by the qti- prefix) will be maintained outside of the QTI specification (schema) to improve interoperability of styling information. See Section 3 for more details.
If a certain style does not exist in the shared vocabulary while authoring assessment content, a custom one can be used; if this happens frequently for a specific style, the style is a candidate for inclusion in the shared vocabulary.
For specifying behavior (semantics) outside of the existing QTI attributes, custom data attributes ( data-) should be used. In case a certain data- attribute is used frequently, and becomes a best practice, it is a candidate for promotion to a built-in attribute, part of the QTI schema.
The new standardized QTI presentation classes and attributes use a "qti" prefix in their naming in the hope of preventing class naming conflicts. For all standardized QTI presentation classes, the names begin with "qti-"; for example "qti-labels-decimal" (used for interaction choices). For standardized custom attributes related to presentation, the attribute names begin with "data-qti-"; for example "data-qti-max-selections-message."
The use of these QTI-specific classes and attributes is generally described in the interactions or features for which they are intended. A full list of all standardized QTI vocabulary is included in Appendix B.
2.2.3 CSS3
QTI 3 does allow for the inclusion of Cascading Style Sheets (CSS) version 3 in content files to transfer the preferred rendering and behavior for test presentation. However, given the complexities of cascading styles, features such as @import and image references, and their possible conflict with delivery system default styles, the automatic acceptance of stylesheets is not required by certified QTI systems. Some assessment programs may, at their own discretion, create and demand support for their own stylesheets as part of the agreed upon scope of work for a particular contract or program.
Associating a stylesheet with an item, a test, a section, a rubric block, template block, feedback structure, or stimulus to control appearance involves using the QTI stylesheet element within the content structure.
There are specific sequential places within a given QTI XML file that can reference stylesheets, and some substructures within the XML files can also reference stylesheets. In each instance, multiple stylesheets can be listed, with the expectation that the styles "cascade" – where stylesheets listed after other stylesheets override previous stylesheets. However, there are instances where stylesheet references are made within nested nodes of the content, and the stylesheet within these nested nodes are meant to be scoped to that node only, and not intended to apply to any other content. For example, assessment items can contain references to stimulus, where the stimulus has a reference to a stylesheet. In this case, the stylesheet within the stimulus is intended only for that stimulus, and not applied to the item content. Similarly, if a stylesheet reference is made from within a rubric block within the qti-item-body node, the stylesheet for the rubric block is scoped only to that specific rubric block, and not for any other rubric blocks within that item, or the item content itself.
Adding a reference to a stylesheet is done by referencing the stylesheet from your file, as shown in the example below.
<qti-stylesheet href="style/custom/your-styles.css" type="text/css" />Disclaimer: some systems will reject custom CSS as part of item content to maintain overall visual consistency. Only use custom CSS on the item-level as a last resort. Alternatively, please use the QTI 3 CSS Shared Vocabulary (see Section 3.6.2) and the QTI 3 Item Shared Vocabulary to improve interoperability and visual consistency. The use of these QTI-specific classes and data attributes is generally described in the interactions or features for which they are intended. A full list of all standardized QTI vocabulary is included in Appendix B.
QTI 3 does not support the use of CSS 3 Speech.
Note that as well as CSS introduced by item authors or QTI authoring systems via the stylesheet element, a qti-portable-custom-interaction would be able to dynamically insert CSS at run time into the HTML markup associated with the interaction. It is recommended that any such CSS generated be scoped to the interaction.
2.2.4 MathML
QTI 3 permits the use of MathML version 3 directly within the portions of the XML files that use HTML5 markup.
The simple example below illustrates the inclusion of a mathematical expression marked up with MathML into an item.
|
Note that schema location and namespaces may not be included in the examples here for ease of reading.
Note about 1EdTech hosts schemas from external namespaces for efficient validation. Perhaps recommend the use of a catalog for local validation
2.2.5 Other Specialized Markup Languages
Specialized markup languages such as Chemical Markup Language (CML) exist for many domains that have a need for computer aided assessment. For that reason, integrating such markup languages with QTI is desirable. Other markup languages include MathML, SVG, and SSML.
A markup language that is widely supported by browsers is Scalable Vector Graphics [SVG]. While direct markup is not supported in the QTI 3 qti-item-body structure at this time, it is easy to include via HTML's 'img' or 'object' tag. Domain specific languages such as CML can often be rendered as SVG, thus providing a convenient way to integrate material with QTI 3.
At present, QTI's qti-printed-variable can be used within MathML and HTML.
A feature that is under consideration for future inclusion is the use of SVG and other languages via HTML 5's 'embed' tag [html5]. The use of this tag is not currently supported either within or outside HTML's 'object' tag.
2.2.6 SSML & PLS
There are two different methods for providing pronunciation information in assessment content that could be consumed by Text-to-Speech (TTS) software (and by extension Screen Reader software) in QTI 3. They are:
- PLS
- SSML
See Section 5 for examples that use SSML & PLS pronunciation.
2.3 QTI 3 Conventions
2.3.1 Use of data- attributes
The custom data-* attribute extends QTI 3.0 to support additional features. When defining a custom attribute, the best practice is to utilize clear naming conventions that describe what the attribute does in order to support interoperability. Documentation for your items should also include detailed information about intended use of custom attributes. Below is an example item with documentation on how each custom attribute is intended to be used.
Example of possible use cases:
In this example qti-hottext element:
|
data-group-name allows for radio button group assignment.
data-deselection-allowed sets whether or not students can deselect that option.
data-don't-word-wrap defines if that option is allowed to wrap onto a new line.
2.3.2 Markup Styles and Conventions
QTI 3 introduces a limited number of shared CSS style names and conventions for use by authoring and delivery systems. See section 3.6.
By implementing these shared styles and conventions, QTI 3 authoring and delivery platforms can safely import/export – or render – items while preserving certain presentation characteristics without using custom stylesheet injection. Note that all of the shared styles are prefaced by the "qti-" string so as to avoid collisions with a delivery platform's existing CSS.
2.4 Accessibility of QTI 3
QTI 3 has several methods for achieving accessibility, primarily through the use of W3C web accessibility standards (including selected HTML5 elements, WAI-ARIA 1.0, SSML 1.1, and PLS 1.0), and the use of a QTI 3 feature called "catalog" referencing.
Valid QTI 3 content many contain web accessibility markup, including Accessible Rich Internet Applications [wai-aria] 1.0 and Speech Synthesis Mark-up Language [speech-synthesis11] 1.1 in the text-based HTML content. QTI also allows for some additional HTML5 tags in the HTML markup, to aid in the structural intent of the content to aid Assistive Technology test takers. Content instances may also reference Pronunciation Lexicon Standard [pronunciation-lexicon] files to instruct Text-to-Speech Synthesis engines on pronunciation, emphasis, and timing.
In addition to promoting the use of international internet accessibility markup, QTI 3 has additional supports that may assist candidates in accessing assessment content, or receiving special assessment accommodations. The specific needs of candidates can be provided to delivery systems using the data provided in a candidate's Personal Needs & Preferences (PNP) file (see Section 5). Alternate or additional content can be authored and exchanged in QTI 3 files which is intended to be provided to candidates who specifically request this alternate or additional content (see Section 5).
2.4.1 Use of W3C Standards in QTI
Assessment delivery systems that use web delivery platforms can be made accessible to Assistive Technology audiences by using standardized accessible web markup. QTI v3 supports and encourages the use of W3C standards, including HTML5, WCAG 2.0, WAI-ARIA 1.0, SSML 1.1, MathML 3, CML, CSS3 (except CSS3 Speech), and PLS. The proper use of these standards will greatly increase the accessibility of the assessment content exchanged in a QTI 3 content package. For guidance around the proper use of the W3C standards for accessibility, use the extensive online W3C documentation .
While W3C recommended techniques are continuously being modified, the exchange of QTI 3 content may have more restricted markup, using fixed released versions and accepted best practices for content transfer. However, delivery systems may choose to adopt newer techniques for the candidate-facing code during presentation (a live assessment session). The methods that are most likely to give candidates access to content, and the ability to respond to interactions, are encouraged to be implemented as soon as they are available and robust enough to be practically implemented.
2.4.2 Candidate Profiles
QTI 3 is capable of using candidate profiles to offer assessment presentation modifications for specific candidates. QTI 3 uses the Access for All® (AfA®) 3.0 standard [AFA-30] for the exchange of candidate profiles, also known as Personal Needs & Preferences (PNP) profiles. The vocabulary used in AfA 3.0 is closely aligned with the predefined supports that can be provided in QTI 3 content.
Through the use of a candidate PNP, a delivery system can provide additional assessment tools for candidates, modify the assessment session parameters (e.g., time limits), or inform test proctors of any special needs of the candidate. Additionally, the assessment content can contain content alternatives or supplemental content that can be activated based on the specific support needs of the candidate.
A description of all the QTI 3 predefined supports can be found in Section 5 of this guide.
2.4.3 Using Catalogs to Store Support-Specific Content
QTI 3 uses a feature called "catalogs" to provide additional content for specific supports which can be activated for specific users, either based on their candidate PNP information or through other test administrative controls. Within an item, any element within the qti-item-body (including the qti-item-body element itself) can point to a referenced container called a "catalog" that contains one or more snippets of content that support the referencing content.
A general description of how to reference and use catalogs can be found in Section 3.7.10, and examples for each of the QTI 3 profile of the AfA 3.0 supports can be found in Section 5.
2.5 Use of Portable Custom Interactions (PCI)
QTI defines a rich set of interaction types but it is not possible for QTI to fully define all interaction types which may be required by educational organizations, particularly with growth in the use of technology enhanced items.
QTI 2 offered an extension mechanism, customInteraction, which allowed interaction content not defined in the QTI Assessment Test, Section and Item specifications to be included in a QTI assessment item, but such items are not in general inter-operable.
To address this interoperability gap, a best practice, known as the Portable Custom Interaction (PCI), was established for QTI 2, which standardizes the contents of a custom interaction element so that it can be utilized by any assessment engine which implements the Portable Content Interaction Best Practice.
In QTI 3 this has been superseded by the introduction of a new interaction type, qti-portable-custom-interaction which makes an enhanced version of this best practice part of the QTI specification. For more information see Section 3.2.22b and Section 3.7.12.
2.6 Results and Metrics: Caliper Assessment Metric Profile
In addition to using the Response Processing Templates in Section 3.4 to score items, there is now a QTI 3.0 Assessment Profile for Caliper Analytics® in development. Adopting this profile allows use of the 1EdTech learning Sensor API™to define basic learning events and to standardize and simplify the gathering of learning metrics across learning environments. Using Caliper to capture student activity during an assessment will allow for metrics that are unavailable from a simple score on each item. For more details on Caliper Analytics [CALIPER-11] please review the latest specification.
Review the Results Reporting Specification [QTI-RR-30] for more information.
2.7 Internationalization
2.7.1 BI-directional Text and Content
Item authors might want to specify the base directionality of their item contents. This is done by the 'dir' attribute, enabling text and content bi-directionality (BIDI). Although the [UNICODE] specification supports directionality of characters, the 'dir' attribute enables item authors to specify the direction of texts but also other kinds of contents, such as tables or interactions. The Content Model described by QTI 3.0 Information Model obey to bidirectional algorithm, inheritance of text direction information, and direction of embedded text specified by the [html40] and [html5] specifications.
Composition of Water (Hebrew)
packaging/items/choice_multiple_rtl.xml
The following example is an Hebrew version of the Composition of Water item. An enclosing div' has a 'dir' attribute with a value of "rtl" (Right to Left). As a result, the 'rtl' directionality is in effect (by inheritance) for all nested block elements. The ChoiceInteraction and its content must be then displayed from right to left as well.
Grand Prix of Bahrain (Hebrew)
The following example describes the use of the bdo class to turn off the bidirectional algorithm for given text portions ("F1", "Rubens Barrichello", "Jenson Button", "Michael Schumacher").
2.7.2 Ruby Markup
QTI 3.0 includes Ruby Markup support. Its intent is to provide a way to render small annotations rendered alongside base text. As explained in depth by the W3C Ruby Markup and Styling article, "Ruby is used in East Asian countries to describe characters that readers might not be familiar with, or describe the meaning of ideographic characters". [ruby] Markup in QTI 3.0 adheres to the description of W3C in [html5].
Hometown (Japanese)
packaging/items/choice_ruby.xml
The item example below makes use of the ruby, rb and rt classes to annotate base text in paragraphs and choices.
3. Item Structure
Items are the essential building blocks of an assessment and make up the bulk of the test material. Items contain the assessment stimuli and prompts (the questions), and also the response areas (the interactions) and scoring instructions.
In order for organizations to exchange the assessment items, the item files may also need to contain a variety of data elements that support the item content. These data elements are briefly explained in this subsection, and with greater details throughout Section 3 of this implementation guide. An assessment item encompasses the information that is presented to a candidate and information about how to score the item. Scoring takes place when candidate responses are transformed into outcomes by response processing rules.
3.1 The qti-assessment-item Element
The qti-assessment-item element contains all the other QTI 3 item structures, and the opening qti-assessment-item element contains the following attributes (* denotes the attribute is required):
- All namespace declarations, including schema locations*
- identifier*
- label
- language (xml:lang)
- tool name (tool-name)
- tool version (tool-version)
- title
- adaptive item indicator (adaptive)
- time dependent (time-dependent) item indicator*
The qti-assessment-item node must contain an "identifier" attribute with a non-null string to identify the item. It is used to identify the item as a unique entity within the context of the exchange of assessment content, so organizations may wish to add organizational prefixes to their identifier information to ensure uniqueness among multiple vendors.
You can optionally add a "label" as an attribute, in whatever way is meaningful as an organizational label for the item(s).
The "xml:lang" attribute is optional, though it should be included as a best practice, as the language is a primary accessibility support for web-based documents.
Both the "tool-name" and "tool-version" are optional elements, which usually indicate the tool name and version that generated the item.
The "title" is an additional optional attribute, which generally contains a more human readable string of text that describes the item.
The "adaptive" attribute is also optional, and the default value is false, where only boolean values (true/false) are permitted. By not including the adaptive attribute, the item will NOT be considered adaptive (changing to the responses of the candidate). The adaptive attribute is not related to adaptive assessments, where the sequence of the item within the context of an assessment is non-linear. See Section 3.7.2 for more information on item adaptivity.
The "time-dependent" attribute is a required attribute, where boolean values (true/false) are permitted. A time dependent item (time-dependent="true") is one in which time; i.e., the amount of time a candidate is provided by a delivery system to enter a response, is important for the psychometric properties - the calibration - of the item. Along with response evaluation, this attribute can also be used in conjunction with other Test attributes by delivery systems to enforce candidate attempt duration limits.
3.1.1 Structures within the qti-assessment-item Node
The QTI-specific XML structures are described in the QTI 3Item XSD. The QTI 3 Item XSD can be found at https://purl.imsglobal.org/spec/qti/v3p0/schema/xsd/imsqti_itemv3p0_v1p0.xsd , which is a subset of the full QTI 3 XSD found at https://purl.imsglobal.org/spec/qti/v3p0/schema/xsd/imsqti_asiv3p0_v1p0.xsd. The namespace is http://www.imsglobal.org/xsd/imsqtiasi_v3p0
An item typically includes the following information:
- Scoring data
- The item content presented to the candidate, which itself contains:
- Any directions/instructions
- Any stimuli or references to stimuli
- The prompt(s)
- The interaction(s)
- Feedback for the candidate
- Supplemental content or references to supplemental content
- Content displayed, voiced, or printed, contingent on the candidate's Access for All (AFA) Personal Needs and Preferences (PNP)
The above information is stored in specific QTI 3structures, and must be supplied in the sequence listed below :
- qti-context-declaration
- qti-response-declaration
- qti-outcome-declaration
- qti-template-declaration
- qti-template-processing
- qti-assessment-stimulus-ref
- qti-companion-materials-info
- qti-response-processing
- qti-modal-feedback
The inclusion or exclusion of the above structures depends on the complexity of the item, and on the needs of the assessment program using the assessment content.
Scoring an item can be quite complex, and the information used to provide the response information and the score(s)received (the outcome(s)) are possible using a combination of the following structures:
- qit-context-declaration
- qti-response-declaration
- qti-outcome-declaration
- qti-response-processing
Content (and content presentation data) to be presented to the candidate is supplied or referenced in a combination of these structures:
- qti-assessment-stimulus-ref
- qti-companion-materials-info
- qti-stylesheet
- qti-item-body
Content presented to candidates using variables use these structures:
- qti-template-declaration
- qti-template-processing
- qti-catalog-info
- qti-modal-feedback
A brief introduction to the AssessmentItem structures is provided below.
3.1.1.1 Context Declaration
The qti-context-declaration nodes are used to make "contextual" variable declarations that are global in scope to an item. When evaluating TemplateProcessing and ResponseProcessing instructions in an AssessmentItem, having contextual information available in the information model can improve the effectiveness, efficiency, and personalization of TemplateProcessing and ResponseProcessing instructions. Contextual information can include candidate information, test information, and system (or environmental) information. Context declarations are also permitted in tests. See Section 3.7.11 for a longer description of context declarations.
3.1.1.2 Response Declaration
Response variables are declared using qti-response-declaration nodes. Interactions in the itemBody must be bound to one of these declared variables . The response declaration supplies the values for the scoring of the item. It may indicate what the correct response is, or the partially correct response(s). The base-type and cardinality defined for a response variable must match the types and cardinality required by the interactions bound to that response variable.
3.1.1.3 Outcome Declaration
Outcome variables are declared using qti-outcome-declaration nodes. The outcome variables represent the score that the candidate can receive for responding to, or not responding to, the item. The outcomes variables values are set either from a default given in the outcome declaration itself or by a ResponseRule during ResponseProcessing. See Section 3.5 for a longer description of outcome declarations.
3.1.1.4 Template Declaration
Use qti-template-declaration nodes to declare item variables that are to be used specifically for the purposes of cloning items. Template variables can have their value set only during TemplateProcessing. Template declarations are referred to within the qti-item-body in order to individualize the clone and possibly also within the ResponseProcessing rules if the cloning process affects the way the item is scored. See Section 3.7.4 for a longer description of using templates in items.
3.1.1.5 Template Processing
Use the qti-template-processing node for template processing. Template processing consists of one or more TemplateRules that are followed by a cloning engine or delivery system in order to assign values to the template variables. Template processing is identical in form to ResponseProcessing except that the purpose is to assign values to template variables, not outcome variables. See Section 3.7.4 for a description on using template processing in items.
Reference to a Shared Stimulus
The qti-assessment-stimulus-ref element can be used to associate one or more external; i.e., external to the qti-assessment-item XML, stimulus blocks with a particular item. A common use case is to author and package a stimulus such as a passage, which can then be shared among multiple items. See Section 3.7.7 for more specifics on how to link items to a shared stimulus.
3.1.1.6 Companion Materials
The qti-companion-materials-info node is used to indicate if the item should be presented to candidates with other kinds of (built-in) assessment tools or materials (companion materials), including: calculators, protractors, rulers, digital materials, or physical materials. See Section 3.7.8 for a longer description of including companion materials in items.
3.1.1.7 Stylesheets
The qti-stylesheet nodes are used to associate external stylesheets for the item. QTI 3 supports CSS 2.1 and CSS 3.0 stylesheets (excluding speech). Any number of stylesheets can be included in an item. See Section 3.6 for examples of how to include stylesheets in items.
For conformance purposes, the use of stylesheets may be ignored by delivery systems, where support for stylesheets is not required for QTI systems.
For interoperability and implementation purposes, QTI shared CSS vocabulary classes take precedence over CSS stylesheets. See Section 3.6.1 for details about QTI 3 shared vocabulary CSS classes.
3.1.1.8 The Item Body
The qti-item-body node contains the text, graphics, media objects and interactions that describe the item's content and information about how it is structured. Only one qti-item-body node is allowed within an item. The qti-item-body is presented to candidates by combining the qti-item-body content with stylesheet information, either explicitly or implicitly using the default style rules of the delivery or authoring system. The ItemBody contains formatted, structured HTML content (see @@@ Section 2.3), as well as any prompt content (optionally contained within the qti-prompt nodes) and any interactions.
Composite items are items that contain more than one interaction within the ItemBody. Composite items may contain multiple instances of the same type of interaction or have a mixture of interaction types within the ItemBody. See Section 3.2 for documentation for specific QTI interactions, and Section 3.3 for the use of composite items. Note that while the qti-item-body node may contain multiple interactions, any interaction MUST NOT be nested or contained within other interactions. Items with nested interactions are not considered compliant to the QTI standard regardless of whether they pass validation or not.
Because ItemBody content is expected to be presented to candidates with a wide variance of perceptual, cognitive processing, physical capabilities, etc.; assessment content should be made as accessible as possible to the widest range of candidates. Guidance on how to provide accessible content is sprinkled throughout this implementation guide, but is certainly not the definitive nor complete documentation on providing accessible content to people. Implementers should stay current in methods and approaches that help increase access to assessment content for all users.
The ItemBody content must be presented to the candidate during an active assessment session. In the assessment session, the candidate must be able to interact with each of the presented interactions and therefore set or update the values of the associated response variables.
The ItemBody may be presented to the candidate when the item session is in the closed or review state. In these states, although the candidate's responses should be presented, the interactions must be disabled so as to prevent the candidate from setting or updating the values of the associated response variables.
The ItemBody may be presented to the candidate in the solution state, in which case the correct values of the response variables must be presented and the associated interactions disabled.
Adaptive items are a feature that allows an item to be scored adaptively over a sequence of attempts. This allows the candidate to alter their answer following feedback or to be posed additional questions based on their current answer.
The ItemBody may also contain rubric blocks (qti-rubric-block), which is content that may be presented to one of the possible audiences for the content, including the author, candidate, proctor, scorer, testConstructor, or tutor. This content would only be shown to the specified audience when the role of that audience is specifically known the system presenting the item. See Section 3.7.5 for more information on using rubric blocks in an assessmentItem.
3.1.1.9 Catalog Resources
The qti-catalog-info node holds one or more catalogs. The ItemBody content references specific catalogs within the qti-catalog-info node. Catalogs hold and reference item content that is presented to candidates based on their candidate profile (PNP) requirements. See Section 5 for a longer description of using catalogs to store support-specific content. In addition to Section 5, there is an annotated item in Section 3.8.1 that includes the use of catalogs for encoding Glossaries and Keyword Translations.
3.1.1.10 Response Processing
Use the qti-response-processing node for response processing – the process by which a delivery engine assigns outcomes (the scores) based on the candidate's responses. Response processing can be achieved using either a response processing template (a reference to a common processing pattern), or by using customized response processing. See Section 3.4.2 for information on using response processing templates, and Section 3.7.1 for information on customized response processing.
3.1.1.11 Modal and Test Feedback
The qti-modal-feedback node is used to provide item-level feedback, which is presented to the candidate directly following response processing. See Section 3.7.3 for more information on providing feedback to candidates. Similarly, qti-test-feedback provides a method to display feedback at the Assessment Test or Test Part level and can be presented either during the test or test part after each instance of outcome processing, or at the conclusion of the test or test part.
3.2 Interaction Types
All QTI v2.2 interaction types are included in QTI 3. However, the interaction elements have been renamed to reflect a web component-friendly syntax which will enable QTI processors to render ItemBody interaction content - should they choose to do so – with web components, and without having to apply further interaction transformations.
The QTI 3 interaction web components-friendly vocabulary introduces the "qti-" prefix on every QTI element. Furthermore, camelcase elements and attributes are replaced with all-lowercase elements/attributes with hyphen separators. See the example below of a choice interaction with the QTI 3 web components-friendly vocabulary.
Example: qti-choice-interaction
|
In another example (a hotspot interaction), note how the object element is considered an HTML element - and therefore not prefixed by "qti-" - even though it is a sub-element of an interaction.
Example: qti-hotspot-interaction
|
QTI 3 includes the following standardized interactions:
- Choice (qti-choice-interaction): presents a set of choices to the candidate. The candidate's task is to select one or more of the choices, up to a maximum number of choices allowed. (See Section 3.2.2 )
- Text Entry (qti-text-entry-interaction): an inline interaction that accepts text from the candidate. (See Section 3.2.3 )
- Extended Text(qti-extended-text-interaction): a block interaction that allows the candidate to enter an extended amount of text.
- Gap Match (qti-gap-match-interaction): a block interaction that contains a number of gaps that the candidate can fill from an associated set of choices.
- Hot Spot(qti-hotspot-interaction): a graphical interaction with a corresponding set of choices that are defined as areas of the graphic image. The candidate's task is to select one or more of the areas (hotspots).
- Hot Text (qti-hot-text-interaction): presents a set of choices to the candidate represented as selectable runs of text embedded within a surrounding context, such as a passage of text.
- Inline Choice (qti-inline-choice-interaction): an inline interaction that presents the user with a set of choices, each of which is an answer option (usually text). The candidate's task is to select one of the choices.
- Match (qti-match-interaction): a block interaction that presents candidates with two sets of choices and allows them to create associations between pairs of choices in the two sets, but not between pairs of choices in the same set.
- Order (qti-order-interaction): the candidate's task is to reorder the choices, the order in which the choices are displayed initially is significant.
- Graphic Order(qti-graphic-order-interaction): A graphic order interaction is a graphic interaction with a corresponding set of hotspot choices that are defined as areas of the graphic image. The candidate's task is to impose an ordering on the areas (hotspots).
- Associate (qti-associate-interaction): a block interaction that presents candidates with a number of choices and allows them to create associations between them.
- Graphic Associate (qti-graphic-associate-interaction): a graphic interaction with a corresponding set of choices that are defined as areas of the graphic image. The candidate's task is to associate the areas (hotspots) with each other.
- Graphic Gap Match (qti-graphic-gap-match-interaction): a graphical interaction with a set of gaps that are defined as areas (hotspots) of the graphic image and an additional set of gap choices that are defined outside the image. The candidate must associate the gap choices with the gaps in the image and be able to review the image with the gaps filled in context, as indicated by their choices.
- Media (qti-media-interaction): allows more control over the way the candidate interacts with a time-based media object and allows the number of times the media object was experienced to be reported in the value of the associated response variable.
- Position Object (qti-position-object-interaction): consists of a single image which must be positioned on another graphic image (the stage) by the candidate.
- Select Point (qti-select-point-interaction): a graphic interaction in which the candidate's task is to select one or more points.
- Slider (qti-slider-interaction): presents the candidate with a control for selecting a numerical value between a lower and upper bound.
- Upload(qti-upload-interaction): allows the candidate to upload a pre-prepared file representing their response.
- Drawing(qti-drawing-interaction): allows the candidate to use drawing tools provided by the delivery system to modify a given graphical image (the canvas). The result is a file in the same format as the original image.
- Custom(qti-custom-interaction) and Portable Custom (qti-portable-custom-interaction): allow the item author to present an interaction with a custom user interface and behavior, supported by, respectively, delivery engine-specific or author-provided code. Portable Custom Interactions (PCIs) allow the Javascript code implementing the interaction to be made available to delivery systems, with a standard Javascript interface, offering the potential for making PCIs more interoperable and portable between conforming delivery engines.
- End Attempt (qti-end-attempt-interaction): is a special interaction which immediately ends the current attempt on an assessment item. It may be used, for example, to allow the candidate to request a hint or model solution, or in an adaptive item to let the candidate display feedback or to move to the next in a series of interactions in the item.
Each of the interactions described in the following sections can contain sub-elements and attributes. For full descriptions of these features, see the QTI 3 Information Model document.
3.2.2 Choice Interaction
The ChoiceInteraction.Type (qti-choice-interaction) interaction presents a collection of choices to the candidate. The candidate's task is to select one or more of the choices, up to a maximum of max-choices. The interaction is always initialized with no choices selected.
The ChoiceInteraction.Type must be bound to a response variable with a base-type of identifier and single or multiple cardinality.
ChoiceInteraction Attributes (element: qti-choice-interaction)
| Name | Usage | Value(s) | Default |
|---|---|---|---|
| max-choices | optional | Non-negative integer | 1 |
| min-choices | optional | Non-negative integer | 0 (unlimited) |
| orientation | optional | Vocabulary:• horizontal• vertical | |
| shuffle | optional | boolean | false |
The choice interaction is made up of choices, which use the qti-simple-choice element (SimpleChoice.Type) to present an ordered list of choices to the candidate.
As noted in the table above, the "shuffle" attribute is optional and defaults to false. However, if the shuffle attribute is set to "true", and the delivery engine supports the discretionary "shuffle" feature, the presentation system must randomize the order in which the choices are originally listed in the Assessment Item XML, subject to the value of the fixed attribute of each choice. If fixed is "true" for a choice then the position of this choice within the interaction must not be changed by the presentation system even if the immediately enclosing interaction supports the shuffling of choices. If no value is specified then the choice is free to be shuffled.
SimpleChoice (element: qti-simple-choice) Attributes
| Name | Usage | Value(s) | Default |
|---|---|---|---|
| identifier | required | Identifier | |
| template-identifier | optional | Identifier | |
| show-hide | optional | Vocabulary:• show• hide | show |
| fixed | optional | boolean | false |
Below is an example of a choice interaction that allows the candidate to select multiple answer options to respond to the prompt.
Example: qti-choice-interaction (multiple cardinality)
|
|
|
|
The qti-choice-interaction has a considerable amount of its shared vocabulary dedicated to the presentation/layout of the interaction's associated qti-simple-choices. Each qti-simple-choice consists of a collection of elements, displayed from left to right, defined as follows:
- A "control"; e.g., either a radio button or checkbox control, and
- A "label"; e.g., often an alphanumeric character such as, "A", "B", "1", "2", etc.
- A "label suffix"; e.g., a "." or ")" character after the label, and
- A "description"; e.g., the HTML content contained by a qti-simple-choice element
By default, in the absence of any shared vocabulary, the presentation of each choice control, label, label suffix, and description, is left to the implementer, with the only requirement that the choices are displayed in a single column, vertically oriented.
3.2.2.1 Choice Label
For explicit choice labeling, use the class attribute as follows:
| Values | ||
|---|---|---|
| qti-labels-none | No labels displayed. | |
| qti-labels-decimal | Display numeric characters 1, 2, 3, … | |
| qti-labels-lower-alpha | Display lowercase characters a, b, c, … | |
| qti-labels-upper-alpha | Display uppercase characters A, B, C, … | |
In the absence of choice labeling, delivery systems should render platform defaults.
Example: Demonstrates class="qti-labels-none"
|
|
|
|
Example: Demonstrates class="qti-labels-decimal"
|
|
|
|
Example: Demonstrates class="qti-labels-lower-alpha"
|
|
|
|
Example: Demonstrates class="qti-labels-upper-alpha"
|
|
|
|
3.2.2.2 Choice Label Suffix
For explicit choice suffix labeling, use the class attribute as follows:
| Values | ||
|---|---|---|
| qti-labels-suffix-none | No character is displayed after the choice label. | |
| qti-labels-suffix-period | A period "." character is displayed after the choice label. | |
| qti-labels-suffix-parenthesis | A right parenthesis ")" character is displayed after the choice label. | |
In the absence of choice suffix labeling, delivery systems should render platform defaults.
Example: Demonstrates class="qti-labels-suffix-none"
|
|
|
|
|
Example: Demonstrates class="qti-labels-suffix-period"
|
|
|
|
Example: Demonstrates class="qti-labels-suffix-parenthesis"
|
|
|
|
3.2.2.3 Combining Choice Label and Choice Label Suffix
It is possible to combine choice label and choice label suffix classes in order to make explicit the desired presentation of the label. In the absence of choice labeling and choice suffix labeling, delivery systems should render platform defaults.
Example: Demonstrates class="qti-labels-lower-alpha qti-labels-suffix-parenthesis"
|
|
|
|
Example: Demonstrates class="qti-labels-decimal qti-labels-suffix-period"
|
|
|
|
3.2.2.4 Choice Orientation
For explicit choice visual orientation, use the class attribute as follows:
| Values | ||
|---|---|---|
| qti-orientation-vertical | Choices are displayed from top to bottom, vertically. | |
| qti-orientation-horizontal | Choices are displayed from left to right, horizontally. | |
When displaying horizontally-oriented lists of choices, delivery systems are not expected to display more than five choices in any row.
Example: Demonstrates class="qti-orientation-vertical"
|
|
|
|
Example: Demonstrates class="qti-orientation-horizontal"
|
|
|
|
3.2.2.5 Choice Stacking
For explicit choice stacking, use the class attribute as follows:
| Values | ||
|---|---|---|
| qti-choices-stacking-1 | Choices are stacked in 1 column. | |
| qti-choices-stacking-2 | Choices are stacked in 2 columns. | |
| qti-choices-stacking-3 | Choices are stacked in 3 columns. | |
| qti-choices-stacking-4 | Choices are stacked in 4 columns. | |
| qti-choices-stacking-5 | Choices are stacked in 5 columns. | |
By default, with vertical orientation, default stacking = 1. With horizontal orientation, default stacking equals the number of choices; e.g., if there are 4 choices then default stacking is 4 when orientation is horizontal. Furthermore, when orientation is horizontal, no delivery system is expected to stack more than 5 choices in a single row. In the absence of an orientation class (horizontal or vertical), stacking is implicitly horizontal.
Example: Demonstrates class="qti-choices-stacking-1"
|
|
|
|
Example: Demonstrates class="qti-choices-stacking-2"
|
|
|
|
Example: Demonstrates class="qti-choices-stacking-3"
|
|
|
|
Example: Demonstrates class="qti-choices-stacking-4"
|
|
|
|
Example: Demonstrates class="qti-choices-stacking-5"
|
|
|
|
3.2.2.6 Combining Orientation and Choice Stacking
Combining an orientation class with a stacking class is used to explicitly set the visual order of the choices. Horizontal stacking must result in a "Z" order of the choices, while vertical stacking must result in a so-called, "Reverse N" visual order of the choices.
Please see the examples below.
Example: Demonstrates class="qti-choices-stacking-3 qti-orientation-horizontal"
|
|
|
|
|
Example: Demonstrates class="qti-choices-stacking-3 qti-orientation-vertical"
|
|
|
|
Example: Demonstrates class="qti-choices-stacking-2 qti-orientation-vertical"
|
|
|
|
Example: Demonstrates class="qti-choices-stacking-2 qti-orientation-horizontal"
|
|
|
|
3.2.2.7 Choice with No Input Control
To specify choice rendering with no input control (radio/checkbox), use the class attribute as follows:
| Values | ||
|---|---|---|
| qti-input-control-hidden | Hide the input controls of the choices. | |
When input controls are hidden, delivery systems should ensure that choice presentation follows WCAG 2.0 AA (or better) guidelines for text and images. Hidden in the context of input controls is intended to mean that the controls are only visually hidden – the controls MUST be available programmatically (available for assistive technology).
Example: Demonstrates class="qti-input-control-hidden"
|
|
Note: The above two examples include choice labels (A., B., etc.). This is not a part of the expected rendering when qti-input-control-hidden is specified. Delivery platforms may choose a different labeling style except in the case where shared labeling vocabulary is specified. |
|
Example: Demonstrates class="qti-input-control-hidden qti-labels-none"
|
|
|
|
3.2.2.8 Choice Interaction Custom max|min-choices Messages
To specify custom max-choices or min-choices messages, use a data- attribute as follows:
| Values | ||
| data-max-selections-message | Custom message to be rendered by the delivery platform upon violation of the max-choices constraint. | |
| data-min-selections-message | Custom message to be rendered by the delivery platform upon violation of the min-choices constraint. | |
In the absence of such custom message overrides, delivery systems should render platform defaults.
3.2.3 Text Entry Interaction
A Text Entry Interaction is an inline interaction that obtains a simple piece of text from the candidate. Like qti-inline-choice-interaction, the delivery engine must allow the candidate to review their choice within the context of the surrounding text.
The TextEntryInteraction.Type (qti-text-entry-interaction) must be bound to a response variable with single or record cardinality only. If the response variable has single cardinality the base-type must be one of string, integer or float; if it has record cardinality the permitted fields are 'stringValue', 'floatValue', etc.
TextEntryInteraction Attributes (element: qti-text-entry-interaction)
| Name | Usage | Value(s) | Default |
|---|---|---|---|
| response-identifier | required | Identifier | |
| base | optional | xs:int | Default is 10. |
| string-identifier | optional | Identifier of a qti-response-declaration with base-type=string | |
| expected-length | optional | Non-negative integer | |
| pattern-mask | optional | string | |
| placeholder-text | optional | string | |
| format | optional | Normalized string |
The bulk of the shared vocabulary for this interaction adds further definition to the presentation width of the input element by utilizing the class attribute.
3.2.3.1 Input Width
For input element width definition, use the class attribute as follows:
| Values | ||
| qti-input-width-1 | Input element width at least 1 character. | |
| qti-input-width-2 | Input element width at least 2 characters. | |
| qti-input-width-3 | Input element width at least 3 characters. | |
| qti-input-width-4 | Input element width at least 4 characters. | |
| qti-input-width-6 | Input element width at least 6 characters. | |
| qti-input-width-10 | Input element width at least 10 characters. | |
| qti-input-width-15 | Input element width at least 15 characters. | |
| qti-input-width-20 | Input element width at least 20 characters. | |
| qti-input-width-72 | Input element width at least 72 characters. (Intended to be interpreted as the full width of a tablet.) | |
The input element widths are intended to provide a general visual impression, and are not expected to exactly match the width of the designated characters. By default, in the absence of any shared vocabulary, the presentation width of the input element is left to the implementer.
Example: Demonstrates various "qti-input-width-1 | 2 | 3 | 4 | 6 | 10 | 15 | 20 | 72" classes
|
|
|
|
3.2.3.2 Custom Pattern Mask Message
To specify a custom pattern mask message, use a data- attribute as follows:
| Values | ||
| data-patternmask-message | Custom message to be rendered by the delivery platform upon violation of the pattern mask constraints. | |
Example: Demonstrates data-patternmask-message
|
|
|
|
3.2.4 Extended Text Interaction
If an extended written response is required from the candidate then the Extended Text Interaction (qti-extended-text-interaction) is appropriate. An extended text interaction is a block Interaction that allows the candidate to enter an extended amount of text.
ExtendedTextInteraction Attributes (element: qti-extended-text-interaction)
| Name | Usage | Value(s) | Default |
|---|---|---|---|
| base | optional | xs:int | 10 |
| string-identifier | optional | Identifier of a response variable with base-type=string | |
| expected-length | optional | Non-negative integer | |
| pattern-mask | optional | xs:string | |
| placeholder-text | optional | xs:string | |
| max-strings | optional | Non-negative integer | |
| min-strings | optional | Non-negative integer | 0 (unlimited) |
| expected-lines | optional | Non-negative integer | |
| format | optional | Vocabulary: • plain • preformatted • xhtml |
plain |
The qti-extended-text-interaction must be bound to a response variable of single, multiple, ordered or record cardinality. If the response variable has record cardinality the fields in the record must be 'stringValue', 'floatValue', etc. Otherwise it must have a base-type of string, integer or float. When bound to response variable with single cardinality a single string of text is required from the candidate. When bound to a response variable with multiple or ordered cardinality several separate text strings may be required.
The shared vocabulary for the extended text interaction is intended to provide more precision when describing:
- Interaction height
- Character counter behavior
- Plain or Rich Text options
- A custom pattern-mask message
- Placeholder text
Responsive design implies that delivery systems should display an input area (typically, this will be a <textarea> or <div> html element) that has a width equal to 100% of the interaction's encapsulating container. Consequently, there is no shared vocabulary for overriding the width of this interaction.
3.2.4.1 Interaction Height
For input area height definition, use the class attribute as follows:
| Values | ||
| qti-height-lines-3 | Input area is approximately 3 lines tall. | |
| qti-height-lines-6 | Input area is approximately 6 lines tall. | |
| qti-height-lines-15 | Input area is approximately 15 lines tall. | |
The input element heights are intended to provide a general visual impression, and are not expected to exactly match the height of the designated lines. By default, in the absence of any shared vocabulary, the presentation height of the input element is left to the implementer.
Example: Demonstrates format="plain" and class="qti-height-lines-3"
| <qti-extended-text-interaction class="qti-height-lines-3" format="plain" response-identifier="RESPONSE" /> | |
|
|
Example: Demonstrates format="xhtml" and class="qti-height-lines-3"
| <qti-extended-text-interaction class="qti-height-lines-3" format="xhtml" expected-length="200" response-identifier="RESPONSE" /> | |
|
|
Example: Demonstrates format="plain" and class="qti-height-lines-6"
| <qti-extended-text-interaction class="qti-height-lines-6" format="plain" response-identifier="RESPONSE" /> | |
|
|
Example: Demonstrates format="xhtml" and class="qti-height-lines-6"
| <qti-extended-text-interaction class="qti-height-lines-6" format="xhtml" expected-length="200" response-identifier="RESPONSE" /> | |
|
|
Example: Demonstrates format="plain" and class="qti-height-lines-15"
| <qti-extended-text-interaction class="qti-height-lines-15" format="plain" response-identifier="RESPONSE" /> | |
|
|
Example: Demonstrates format="xhtml" and class="qti-height-lines-15"
| <qti-extended-text-interaction class="qti-height-lines-15" format="xhtml" expected-length="200" response-identifier="RESPONSE" /> | |
|
|
3.2.4.2 Character Counter Behavior
By default, a character counter is not displayed. For specifying character (not word) counter display and behavior, use the class attribute as follows:
| Values | ||
| qti-counter-down | Display a character counter, starting at the value of the expected-length attribute and counting down to 0. | |
| qti-counter-up | Display a character counter, starting at 0 and increasing to the value of the expected-length attribute. | |
In the case where the format of the interaction is "xhtml", the delivery system is expected to count only the text of the markup elements. Example: <span>Hello</span> has 5 characters.
Example: Demonstrates qti-counter-down
| <qti-extended-text-interaction class="qti-height-lines-3 qti-counter-down" format="plain" expected-length="200" response-identifier="RESPONSE" /> | |
|
|
Example: Demonstrates qti-counter-up
| <qti-extended-text-interaction class="qti-height-lines-3 qti-counter-up" format="plain" expected-length="200" response-identifier="RESPONSE" /> | |
|
|
Example: Demonstrates qti-counter-up with format="xhtml"
| <qti-extended-text-interaction class="qti-height-lines-3 qti-counter-up" format="xhtml" expected-length="200" response-identifier="RESPONSE" /> | |
|
|
3.2.4.3 Custom Pattern Mask Message
To specify a custom pattern mask message, use a data- attribute as follows:
| Values | ||
| data-patternmask-message | Custom message to be rendered by the delivery platform upon violation of the pattern mask constraints. | |
Example: Demonstrates data-patternmask-message
|
|
|
|
3.2.5 Gap Match Interaction
A gap match interaction is a block Interaction that contains a number of gaps that the candidate can fill from an associated set of choices. The candidate must be able to review the content with the gaps filled in context, as indicated by their choices.
The GapMatchInteraction.Type (qti-gap-match-interaction) is similar to Match Interaction (qti-match-interaction) except that the choices in the second set are gaps (qti-gap) in a given passage of text and the task involves selecting choices from the first set and using them to fill the gaps. The same attributes are involved in controlling which, and how many, pairings are allowed, though there is no match-max attribute for the gaps because they can only ever have one associated choice. The scoring is again done with a mapping.
GapMatchInteration Attributes (element: qti-gap-match-interaction)
| Name | Usage | Value(s) | Default |
|---|---|---|---|
| max-associations | optional | Non-negative number | 1 |
| min-associations | optional | Non-negative number | |
| shuffle | optional | boolean | false |
Sub-elements include qti-gap-text (GapText.Type) and qti-gap-img (GapImg.Type).
GapText Attributes (element: qti-gap-text)
| Name | Usage | Value(s) | Default |
|---|---|---|---|
| identifier | required | Identifier | |
| template-identifier | optional | Identifier of a template variable used to control the visibility of the qti-gap-text | |
| show-hide | optional | Vocabulary:• show• hide | show |
| match-group | optional | IdentifierList | |
| match-max | required | Non-negative integer | |
| match-min | optional | Non-negative integer | 0 (unlimited) |
The qti-gap-img contains a single HTML object element.
GapImg Attributes (element: qti-gap-img)
| Name | Usage | Value(s) | Default |
|---|---|---|---|
| identifier | required | Identifier | |
| template-identifier | optional | Identifier of a template variable used to control the visibility of the qti-gap-img | |
| show-hide | optional | Vocabulary:• show• hide | show |
| match-group | optional | IdentifierList | |
| match-max | required | Non-negative integer, 0 means unlimited | |
| match-min | optional | Non-negative integer <= match-max | 0 |
| object-label | optional | string | |
| top | optional | empty | |
| left | optional | empty |
Additional formatting may be applied within the qti-gap-text element allowing for a greater variation.' Allowed formats include:
'br', 'img', 'xi:include', 'm:math', 'object', 'qti-printed-variable', 'a', 'abbr', 'acronym', 'b', 'big', 'cite', 'code', 'dfn', 'em', 'qti-feedback-inline', 'i', 'kbd', 'q', 'samp', 'small', 'span', 'strong', 'sub', 'sup', 'tt', 'var', 'qti-template-inline', 'bdi', 'bdo', 'label', 'ruby', 'ssml11:*'.
The qti-gap-match-interaction must be bound to a response variable with base-type directedPair and either single or multiple cardinality, depending on the number of gaps. The choices represent the source of the pairing and gaps the targets. Each gap can have at most one choice associated with it. The maximum occurrence of the choices is controlled by the match-max attribute of qti-gap-text or qti-gap-img.
The shared vocabulary for the Gap Match Interaction is intended to provide more precision when describing:
- Positioning of the Gap Choices container with respect to the passage of text containing the Gaps.
- Gap Choices container width.
- Gap element widths.
- Custom max|min-associations message overrides.
3.2.5.1 Gap Choices Container | Gap Positioning
For explicit gap choices container positioning with respect to the passage text containing the gaps, use the class attribute as follows:
| Values | ||
| qti-choices-top | The gap choices container is displayed above the passage text. | |
| qti-choices-bottom | The gap choices container is displayed below the passage text. | |
| qti-choices-left | The gap choices container is displayed to the left of the passage text. | |
| qti-choices-right | The gap choices container is displayed to the right of the passage text. | |
The following examples demonstrate shared vocabulary describing the visual orientation of the gap match choices container with respect to the passage text containing the gaps.
Example: Demonstrates class="qti-choices-top"
|
|
|
|
Example: Demonstrates class="qti-choices-bottom"
|
|
|
|
Example: Demonstrates class="qti-choices-left"
|
|
|
|
Example: Demonstrates class="qti-choices-right"
|
|
|
|
3.2.5.2 Gap Choices Container Width
A common implementation of the gap match interaction is to place the gap choices in a so-called "gap choices container". If the gap choices are implemented with responsive design, then one can achieve a visual equivalent of gap choices stacking by manipulating the gap choices container width.
For specifying explicit gap choices container width, use a data- attribute as follows:
| Values | ||
| data-choices-container-width | The gap choices container width in pixels. Example: data-choices-container-width="100" | |
The assumption is that the container sizes would scale when content is magnified. There is likely to be a significant decrease in the ability for low-vision users to respond to the item who may magnify the content large enough to have portions of the container displayed off-screen.
Example: Demonstrates qti-choices-top and data-choices-container-width="200"
|
|
|
|
Example: Demonstrates qti-choices-left and data-choices-container-width="100"
|
|
|
|
3.2.5.3 Gap Element Input Width
For gap element width definition, use the class attribute as follows:
| Values | ||
| qti-input-width-1 | Gap element width at least 1 character. | |
| qti-input-width-2 | Gap element width at least 2 characters. | |
| qti-input-width-3 | Gap element width at least 3 characters. | |
| qti-input-width-4 | Gap element width at least 4 characters. | |
| qti-input-width-6 | Gap element width at least 6 characters. | |
| qti-input-width-10 | Gap element width at least 10 characters. | |
| qti-input-width-15 | Gap element width at least 15 characters. | |
| qti-input-width-20 | Gap element width at least 20 characters. | |
| qti-input-width-72 | Gap element width at least 72 characters. (Intended to be interpreted as the full width of a tablet.) |
|
The gap element widths are intended to provide a general visual impression. By default, in the absence of any shared vocabulary, the presentation width of a gap element is left to the implementer.
Note that the assumption is that input sizes scale with increased magnification of the content, though the input areas should never wrap to another line of text. Limits on scaling could be problematic for low-vision candidates, particularly at higher levels of magnification.
Example: Demonstrates all gap element "qti-input-widths-1 | 2 | 3 | 4 | 6 | 10 | 15 | 20 | 72" classes.
|
|
|
|
3.2.5.4 Gap Match Custom max|min-associations Messages
To specify custom max-associations or min-associations messages, use a data- attribute as follows:
| Values | ||
| data-max-selections-message | Custom message to be rendered by the delivery platform upon violation of the max-associations constraint. | |
| data-min-selections-message | Custom message to be rendered by the delivery platform upon violation of the min-associations constraint. | |
In the absence of such custom message overrides, delivery systems should render platform defaults.
3.2.6 Hotspot
A HotspotInteraction.Type (qti-hotspot-interaction) is a graphical interaction with a corresponding set of choices that are defined as areas of the graphic image. The candidate's task is to select one or more of the areas (hotspots).
The hotspot interaction should only be used when the spatial relationship of the choices with respect to each other (as represented by the graphic image) is important to the needs of the item. Otherwise, Choice Interaction should be used instead with separate material for each option.
The delivery engine must clearly indicate selected hotspots when such hotspots are selected. If the Shared Vocabulary class qti-unselected-hidden is present, the delivery engine must hide the hotspots in their unselected and unfocused state. If the qti-unselected-hidden is not present, indicating hotspots in their unselected and unfocused state is left to the delivery engine.
HotspotInteraction Attributes (element: qti-hotspot-interaction)
| Name | Usage | Value(s) | Default |
|---|---|---|---|
| max-choices | optional | Non-negative number | 1 |
| min-choices | optional | Non-negative number | 0 (unlimited) |
The sub-element sequence for the qti-hotspot-interaction:
- either img, picture, or object (must have only 1, note that the use of object is deprecated in QTI 3)
- qti-hotspot-choice (at least 1)
HotspotChoice Attributes (element: qti-hotspot-choice)
| Name | Usage | Value(s) | Default |
|---|---|---|---|
| identifier | required | Identifier | |
| template-identifier | optional | Identifier of a template variable used to control the visibility of the qti-hotspot-choice | |
| show-hide | optional | Vocabulary:• show• hide | show |
| shape | required | Vocabulary:• circle• default• ellipse• poly• rect | |
| coords | required | Coords.Type | |
| hotspot-label | optional | string |
The hotspot interaction must be bound to a response variable with a base-type of identifier and single or multiple cardinality.
The shared vocabulary for the Hotspot Interaction is intended to provide more precision when describing:
- Hotspot Selections theming.
- Custom max|min-choices message overrides.
3.2.6.1 Hotspot Selections Theming
For explicit hotspot selection theming, use the class attribute as follows:
| Values | ||
|---|---|---|
| qti-selections-light | Delivery platform must implement hotspot selections in a color that the platform believes to be of suitable color contrast and opacity against a "dark" background image. | |
| qti-selections-dark | Delivery platform must implement hotspot selections in a color that the platform believes to be of suitable color contrast and opacity against a "light" background image. | |
| qti-unselected-hidden | Hotspot selections are visually hidden until focused or selected. | |
When using qti-selections-dark and qti-selections-light classes, the intent is to increase the contrast between the selections and the background, to ensure candidates can clearly identify the selections. In the absence of such hotspot selection theming overrides, delivery systems should render platform defaults.
For qti-unselected-hidden, note that there is an obvious visual bias for these types of questions. In addition, the selection should only be visually-hidden. Selections should always be programmatically available (usable by keyboards and assistive technology) to candidates.
Example: Demonstrates Hotspot selections with class="qti-selections-light" and class="qti-selections-dark"
|
|
| Expected Rendering: Hotspot selections are rendered with colors and opacities of the delivery platform's choosing. In the two hotspot interactions below, two of the four hotspots are selected, and two are unselected. All hotspots are visible, even in their unselected state, though this is left to the delivery platform. 
|
|
Example: Demonstrates Hotspot selections with class= " qti-selections-light " and class= " qti-selections-dark " , and " qti-unselected-hidden " in both.
|
|
| Expected Rendering: Hotspots are rendered invisible in their unselected and unfocused state, with visible colors and opacities of the platform's choosing in their selected state. In the two hotspot interactions below, two of the four hotspots are selected (visible), and two are unselected and unfocused (invisible). 
|
|
3.2.6.2 Hotspot Interaction Custom max|min-choices Messages
To specify custom max-choices or min-choices messages, use a data- attribute as follows:
| Values | ||
| data-max-selections-message | Custom message to be rendered by the delivery platform upon violation of the max-choices constraint. | |
| data-min-selections-message | Custom message to be rendered by the delivery platform upon violation of the min-choices constraint. | |
In the absence of such custom message overrides, delivery systems should render platform defaults.
3.2.7 Hot Text
The HotTextInteraction.Type (qti-hottext-interaction) presents a set of choices to the candidate represented as selectable runs of text embedded within a surrounding context, such as a simple passage of text. Like Choice Interaction, the candidate's task is to select one or more of the choices, up to a maximum of max-choices.
The interaction is initialized from the qti-default-value of the associated response variable, a NULL value indicating that no choices are selected (the usual case).
HotTextInteraction Attributes (element: qti-hottext-interaction)
| Name | Usage | Value(s) | Default |
|---|---|---|---|
| min-choices | optional | Non-negative integer | 0 (unlimited) |
| max-choices | optional | Non-negative integer | 1 |
The qti-hottext-interaction must be bound to a response variable with a base-type of identifier and single or multiple cardinality.
The shared vocabulary for the Hot Text Interaction is intended to provide more precision when describing:
- Hiding the input control of the Hot Text choices.
- Custom max|min-choices message overrides.
3.2.7.1 Hot Text Choices with No Input Controls
To specify Hot Text choice rendering with no input control (radio/checkbox), use the class attribute as follows:
| Values | ||
|---|---|---|
| qti-input-control-hidden | Hide the input controls of the Hot Text choices. | |
When input controls are hidden, delivery systems should ensure that choice presentation follows WCAG 2.0 AA (or better) guidelines for text and images. By default, in the absence of any shared vocabulary, the presentation of input controls on the Hot Text elements is left to the delivery system.
Example: Demonstrates class="qti-input-control-hidden"
|
|
|
|
3.2.7.2 Hot Text Interaction Custom max|min-choices Messages
To specify custom max-choices or min-choices messages, use a data- attribute as follows:
| Values | ||
| data-max-selections-message | Custom message to be rendered by the delivery platform upon violation of the max-choices constraint. | |
| data-min-selections-message | Custom message to be rendered by the delivery platform upon violation of the min-choices constraint. | |
In the absence of such custom message overrides, delivery systems should render platform defaults.
3.2.8 Inline Choice
The InlineChoiceInteraction.Type (qti-inline-choice-interaction) is an inline interaction to display a set of simple text choices in context in a surrounding text, which may be subject to variable value substitution with qti-printed-variable.
InlineChoiceInteraction Attributes (element: qti-inline-choice-interaction)
| Name | Usage | Value(s) | Default |
|---|---|---|---|
| identifier | required | Identifier | |
| required | optional | boolean | false If true then a choice must be selected by the candidate in order to form a valid response to the interaction. |
| shuffle | optional | boolean | false |
The sub-element seCoolquence of qti-inline-choice-interaction is:
- qti-label (maximum of 1)
- qti-inline-choice (at least 1)
InlineChoice Attributes (element: qti-inline-choice)
| Name | Usage | Value(s) | Default |
|---|---|---|---|
| identifier | required | Identifier | |
| template-identifier | optional | Identifier of a template variable used to control the visibility of the choice | |
| show-hide | optional | Vocabulary:• show• hide | show |
| fixed | optional | boolean | false |
When rendering an inline choice interaction, the common implementation is an embodiment of a <select> html form element or a combo box form control.
Below is an example of an inline choice interaction that allows the candidate to select one answer option to respond to the prompt.
Example: qti-inline-choice-interaction
|
|
|
|
The bulk of the shared vocabulary for this interaction adds further definition to the presentation width of the selection element by utilizing the class attribute.
3.2.8.1 Input Width
For selection element width definition, use the class attribute as follows:
| Values | ||
| qti-input-width-1 | Selection element width at least 1 character. | |
| qti-input-width-2 | Selection element width at least 2 characters. | |
| qti-input-width-3 | Selection element width at least 3 characters. | |
| qti-input-width-4 | Selection element width at least 4 characters. | |
| qti-input-width-6 | Selection element width at least 6 characters. | |
| qti-input-width-10 | Selection element width at least 10 characters. | |
| qti-input-width-15 | Selection element width at least 15 characters. | |
| qti-input-width-20 | Selection element width at least 20 characters. | |
| qti-input-width-72 | Selection element width at least 72 characters.(Intended to be interpreted as the full width of a tablet.) | |
The selection element widths are intended to provide a general visual impression, and are not expected to exactly match the width of the designated characters. By default, in the absence of any shared vocabulary, the presentation width of the selection element is left to the implementer.
Example: Demonstrates various "qti-input-width-1 | 2 | 3 | 4 | 6 | 10 | 15 | 20 | 72" classes
|
|
|
|
3.2.8.2 Custom Prompt Messages
Delivery systems may display a word or a phrase - a so-called, "prompt" - inside the boundaries of the selection element when the element is in an unselected state. To specify custom text, use a data- attribute as follows:
| Values | ||
| data-prompt | Custom text to be rendered by the delivery platform when the selection element is in an unselected state. | |
In the absence of custom prompt overrides, delivery systems should render platform defaults.
Example: Demonstrates data-prompt
|
|
|
|
3.2.9 Match
A MatchInteraction.Type (qti-match-interaction) is a blockInteraction that presents candidates with two sets of choices and allows them to create associations between pairs of choices in the two sets, but not between pairs of choices in the same set. Further restrictions can still be placed on the allowable associations using the match-max characteristic of the choices.
The sub-element within qti-match-interaction is qti-simple-match-set. MatchInteration Attributes (element: qti-match-interaction)
| Name | Usage | Value(s) | Default |
|---|---|---|---|
| max-associations | optional | Non-negative number | 1 |
| min-associations | optional | Non-negative number | |
| shuffle | optional | boolean | false |
The sub-element of qti-match-interaction is qti-simple-match-set (SimpleMatchSet.Type). The qti-simple-match-set has an optional "id" attribute which contains a UniqueIdentifier.Type. The qti-simple-match-set contains an ordered set of choices using qti-simple-associable-choice (SimpleAssociableChoice.Type) elements.
SimpleAssociableChoice Attributes (element: qti-simple-associable-choice)
| Name | Usage | Value(s) | Default |
|---|---|---|---|
| identifier | required | Identifier | |
| template-identifier | optional | Identifier | |
| show-hide | optional | Vocabulary:• show• hide | show |
| match-group | optional | IdentifierList | |
| match-max | required | Non-negative integer | |
| match-min | optional | Non-negative integer | 0 (unlimited) |
| fixed | optional | boolean | false |
The match interaction must be bound to a response variable with base-type directedPair and either single or multiple cardinality.
The shared vocabulary for the Match Interaction is intended to provide more precision when describing:
- Non-tabular Match Interaction positioning of the first Simple Match Set choices with respect to the second Simple Match Set choices.
- Tabular Match Interaction styling.
- Custom max|min-associations message overrides.
3.2.9.1 Non-Tabular Match Interaction Choice | Target Positioning
For explicit choice | target positioning, use the class attribute as follows:
| Values | ||
| qti-choices-top | The first Simple Match Set choices are displayed above the second Simple Match Set choices. | |
| qti-choices-bottom | The first Simple Match Set choices are displayed below the second Simple Match Set choices. | |
| qti-choices-left | The first Simple Match Set choices are displayed to the left of the second Simple Match Set choices. | |
| qti-choices-right | The first Simple Match Set choices are displayed to the right of the second Simple Match Set choices. | |
Note about accessibility when using targeting position classes: there may be issues related to the order that choices and targets are presented to assistive technology candidates. If the candidate is known to be using assistive technology (screen readers), by default the choices should be presented first, followed by the targets second.
The following examples demonstrate shared vocabulary describing the visual orientation of the list of match choices; i.e., the choices of the first Simple Match Set, with respect to the list of match targets; i.e., the choices of the second Simple Match Set.
Example: Demonstrates class="qti-choices-top"
|
|
|
|
Example: Demonstrates class="qti-choices-bottom"
|
|
|
|
Example: Demonstrates class="qti-choices-left"
|
|
|
|
Example: Demonstrates class="qti-choices-right"
|
|
|
|
3.2.9.2 Tabular Match Interactions
Delivery systems may implement Match Interaction's in a visual Tabular fashion. When they do so, the shared vocabulary is intended to provide visual styles and content to improve interoperability and visual consistency.
For explicit Tabular embodiments of Match Interactions, use the class attribute:
| Values | ||
| qti-match-tabular | Render a visual table with the choices of the first Simple Match Set as the table row headers, and the choices of the second Simple Match Set as the table column headers. | |
| qti-header-hidden | For certain presentations, it can be advantageous to hide the column headers. This class enables this presentation. Do not display the top row of the table where the column headers are displayed. | |
Class qti-header-hidden, and data- attribute data-first-column-header (see below) are only relevant when qti-match-tabular is specified.
To specify the text of the top-left header cell of the table, use a data- attribute as follows:
| Values | ||
| data-first-column-header | Custom text to be rendered in the top-left header cell of the table (headings must be visible). | |
A note about accessibility when using qti-match-tabular: there are known issues for assistive technology users (screen readers in particular) when putting content into tables. There are sometimes differences between screen readers in the order that content is read out loud. Because the cells contain interactive controls, assistive technology needs to be able to provide navigation within the table (between the cells) as well as coordinating the match interaction. If any possible candidates may be using screen readers to respond to match interactions, using HTML tables may not be the best choice for presentation.
In addition, there is a likely negative impact to assistive technology candidates when using the qti-header-hidden, as the headers are used to orient assistive technology users.
The following examples show expected rendering when class is qti-match-tabular.
Example: Demonstrates class="qti-match-tabular"
|
|
|
|
Example: Demonstrates class="qti-match-tabular qti-header-hidden"
|
|
|
|
Example: Demonstrates class="qti-match-tabular" data-first-column-header="Characters"
|
|
|
|
3.2.9.3 Match Custom max|min-associations Messages
To specify custom max-associations or min-associations messages, use a data- attribute as follows:
| Values | ||
| data-max-selections-message | Custom message to be rendered by the delivery platform upon violation of the max-associations constraint. | |
| data-min-selections-message | Custom message to be rendered by the delivery platform upon violation of the min-associations constraint. | |
In the absence of such custom message overrides, delivery systems should render platform defaults.
3.2.10 Order
In an OrderInteraction.Type (qti-order-interaction) the candidate's task is to reorder the choices, the order in which the choices are displayed initially is significant. By default the candidate's task is to order all of the choices but a subset of the choices can be requested using the max-choices and min-choices attributes. When specified the candidate must first select a (sub)set of the choices and then impose an ordering on them.
OrderInteraction Attributes (element: qti-order-interaction)
| Name | Usage | Value(s) | Default |
|---|---|---|---|
| min-choices | optional | Non-negative number | |
| max-choices | optional | Non-negative number | |
| orientation | optional | Vocabulary:• horizontal• vertical | |
| shuffle | optional | false |
The sub-element of qti-order-interaction is qti-simple-choice (SimpleChoice.Type) where there must be at least one qti-simple-choice in the interaction to be valid, and at least 2 choices to be useful as an order interaction.
SimpleChoice (element: qti-simple-choice) Attributes
| Name | Usage | Value(s) | Default |
|---|---|---|---|
| identifier | required | Identifier | |
| template-identifier | optional | Identifier | |
| show-hide | optional | Vocabulary:• show• hide | show |
| fixed | optional | boolean | false |
3.2.10.1 Order Target Labels
In certain rendering embodiments where the ordering choices are separated from an ordering target area (see 3.2.10.3 Ordering Choices | Ordering Target Container Positioning ), it may be desirable to specify labels for the order target elements. For explicit labeling of order target elements, use the same classes as for choice interaction; i.e., use the class attribute as follows:
| Values | ||
|---|---|---|
| qti-labels-none | No labels displayed (default) | |
| qti-labels-decimal | Display numeric characters 1, 2, 3, … | |
| qti-labels-lower-alpha | Display lowercase characters a, b, c, … | |
| qti-labels-upper-alpha | Display uppercase characters A, B, C, … | |
In the absence of order target labeling, delivery systems should render platform defaults.
Example: Demonstrates qti-choices-top and qti-labels-none
|
|
|
|
Example: Demonstrates qti-choices-top and qti-labels-decimal
|
|
|
|
Example: Demonstrates qti-choices-top and qti-labels-lower-alpha
|
|
|
|
Example: Demonstrates qti-choices-top and qti-labels-upper-alpha
|
|
|
|
3.2.10.2 Order Target Label Suffixes
For explicit suffix labeling of order target elements, use the same classes as for choice interaction; i.e., use the class attribute as follows:
| Values | ||
|---|---|---|
| qti-labels-suffix-none | No character is displayed after the order target label. | |
| qti-labels-suffix-period | A period "." character is displayed after the order target label. | |
| qti-labels-suffix-parenthesis | A right parenthesis ")" character is displayed after the order target label. | |
In the absence of order target suffix labeling, delivery systems should render platform defaults.
Example: Demonstrates qti-choices-left and qti-labels-decimal and qti-labels-suffix-none
|
|
|
|
Example: Demonstrates qti-choices-left and qti-labels-decimal and qti-labels-suffix-period
|
|
|
|
Example: Demonstrates qti-choices-left and qti-labels-decimal and qti-labels-suffix-parenthesis
|
|
|
|
3.2.10.3 Ordering Choices | Order Target Container Positioning
For explicit ordering choice | order target container positioning, use the class attribute as follows:
| Values | ||
| qti-choices-top | The choices container is displayed above the order target container | |
| qti-choices-bottom | The choices container is displayed below the order target container | |
| qti-choices-left | The choices container is displayed to the left of the order target container | |
| qti-choices-right | The choices container is displayed to the right of the order target container | |
In the absence of choices | order target container positioning, delivery systems should render platform defaults.
Example: Demonstrates class="qti-choices-top"
|
|
|
|
Example: Demonstrates class="qti-choices-bottom"
|
|
|
|
Example: Demonstrates class="qti-choices-left"
|
|
|
|
Example: Demonstrates class="qti-choices-right"
|
|
|
|
3.2.10.4 Ordering Choices Container Width
For specifying explicit ordering choices container width, use a data- attribute as follows:
| Values | ||
| data-choices-container-width | The ordering choices container width in pixels. Example: data-choices-container-width="100" | |
3.2.10.5 Ordering Custom max|min-selections Messages
To specify custom max-choices or min-choices messages, use a data- attribute as follows:
| Values | ||
| data-max-selections-message | Custom message to be rendered by the delivery platform upon violation of the max-choices constraint. | |
| data-min-selections-message | Custom message to be rendered by the delivery platform upon violation of the min-choices constraint. | |
3.2.11 Graphic Order
A GraphicOrderInteraction.Type (qti-associate-interaction) is a graphic interaction with a corresponding set of choices that are defined as areas of the graphic image. The candidate's task is to impose an ordering on the areas (hotspots). The order hotspot interaction should only be used when the spatial relationship of the choices with respect to each other (as represented by the graphic image) is important to the needs of the item.
Otherwise, Order interaction should be used instead with separate material for each option. The delivery engine must clearly indicate all defined area(s) of the image.
Graphic Order Interaction Attributes (element: qti-graphic-order-interaction)
| Name | Usage | Value(s) | Default |
|---|---|---|---|
| max-choices | optional | Non-negative number | If unspecified, all of the choices may be ordered. |
| min-choices | optional | Non-negative number | If unspecified, all of the choices must be ordered and max-choices is ignored. |
The sub-element sequence for the qti-graphic-order-interaction:
- either img, picture, or object (must have only 1, object is deprecated)
- qti-hotspot-choice (at least 1)
HotspotChoice Attributes (element: qti-hotspot-choice)
| Name | Usage | Value(s) | Default |
|---|---|---|---|
| identifier | required | Identifier | |
| template-identifier | optional | Identifier of a template variable used to control the visibility of the qti-hotspot-choice | |
| show-hide | optional | Vocabulary:• show• hide | show |
| shape | required | Vocabulary:• circle• default• ellipse• poly• rect | |
| coords | required | Coords.Type | |
| hotspot-label | optional | string |
The graphic order interaction must be bound to a response variable with a base-type of identifier and ordered cardinality.
Example: Demonstrates qti-graphic-order-interaction
|
|
|
|
3.2.12 Associate
An AssociateInteraction.Type (qti-associate-interaction) is a block interaction that presents candidates with a number of choices and allows them to create associations between them.
AssociateInteraction Attributes (element: qti-associate-interaction)
| Name | Usage | Value(s) | Default |
|---|---|---|---|
| max-associations | optional | Non-negative number | 1 |
| min-associations | optional | Non-negative number | 0 (unlimited) |
| shuffle | optional | boolean | false |
The sub-element of qti-associate-interaction is qti-simple-associable-choice, where there must be at least one qti-simple-associable-choice.
SimpleAssociableChoice Attributes (element: qti-simple-associable-choice)
| Name | Usage | Value(s) | Default |
|---|---|---|---|
| identifier | required | Identifier | |
| template-identifier | optional | Identifier | |
| show-hide | optional | Vocabulary:• show• hide | show |
| match-max | required | Non-negative integer | |
| match-min | optional | Non-negative integer | 0 (unlimited) |
| fixed | optional | boolean |
The qti-associate-interaction must be bound to a response variable with base-type pair and either single or multiple cardinality.
Example: Demonstrates qti-associate-interaction max-associations="3"
|
|
|
|
3.2.13 Graphic Associate
A GraphicAssociateInteraction.Type (qti-graphic-associate-interaction) is a graphic interaction with a corresponding set of choices that are defined as areas of the graphic image. The candidate's task is to associate the areas (hotspots) with each other. The graphic associate interaction should only be used when the graphical relationship of the choices with respect to each other (as represented by the graphic image) is important to the needs of the item. Otherwise, an Associate Interaction should be used instead with separate material for each option. The delivery engine must clearly indicate all defined area(s) of the image.
AssociateInteraction Attributes (element: qti-associate-interaction)
| Name | Usage | Value(s) | Default |
|---|---|---|---|
| max-associations | optional | Non-negative number | 1 |
| min-associations | optional | Non-negative number |
The sub-element sequence:
- img, picture, or object (limited to a single occurrence, object is deprecated)
- qti-associable-hotspot (at least 1)
AssociableHotspot Attributes (element: qti-associable-hotspot)
| Name | Usage | Value(s) | Default |
|---|---|---|---|
| identifier | required | Identifier | |
| template-identifier | optional | Identifier | |
| show-hide | optional | Vocabulary:• show• hide | show |
| match-group | optional | IdentifierList | |
| shape | required | Vocabulary:• circle• default• ellipse• poly• rect | |
| coords | required | Coords.Type | |
| hotspot-label | optional | string | |
| match-max | required | Non-negative integer | |
| match-min | optional | Non-negative integer | 0 (unlimited) |
The qti-graphic-associate-interaction must be bound to a response variable with base-type pair and either single or multiple cardinality.
Example: Demonstrates qti-graphic-associate-interaction
|
|
|
|
Alternatively, you may wish to use the picture element to reference the source for the more highly compressed WebP version and with a PNG alternative within the img element for browsers that do not support WebP.
Example: Demonstrates qti-graphic-associate-interaction with picture
|
|
|
|
|
3.2.14 Graphic Gap Match
A GraphicGapMatchInteraction.Type (qti-graphic-gap-match-interaction) is a graphical interaction with a set of gaps that are defined as areas (hotspots) of the graphic image and an additional set of gap choices that are defined outside the image. The candidate must associate the gap choices with the gaps in the image and be able to review the image with the gaps filled in context, as indicated by their choices.
Care should be taken when designing these interactions to ensure that the gaps in the image are a suitable size to receive the required gap choices. It must be clear to the candidate which hotspot each choice has been associated with. When associated, choices must appear wholly inside the gaps if at all possible and, where overlaps are required, should not hide each other completely. If the candidate indicates the association by positioning the choice over the gap (e.g. drag and drop) the system should 'snap' it to the nearest position that satisfies these requirements.
GraphicGapMatchInteraction Attributes (element: qti-graphic-gap-match-interaction)
| Name | Usage | Value(s) | Default |
|---|---|---|---|
| max-associations | optional | Non-negative number | 1 |
| min-associations | optional | Non-negative number |
The sequence of elements within the qti-graphic-gap-match-interaction is:
- qti-prompt
- either img, picture, or object (deprecated)
- qti-gap-text
- qti-gap-img
- qti-associable-hotspot
GapText Attributes (element: qti-gap-text)
| Name | Usage | Value(s) | Default |
|---|---|---|---|
| identifier | required | Identifier | |
| template-identifier | optional | Identifier | |
| show-hide | optional | Vocabulary:• show• hide | show |
| match-group | optional | IdentifierList | |
| match-max | required | Non-negative integer | |
| match-min | optional | Non-negative integer | 0 (unlimited) |
GapImg Attributes (element: qti-gap-img)
| Name | Usage | Value(s) | Default |
|---|---|---|---|
| identifier | required | Identifier | |
| template-identifier | optional | Identifier | |
| show-hide | optional | Vocabulary:• show• hide | show |
| match-group | optional | IdentifierList | |
| match-max | required | Non-negative integer | |
| match-min | optional | Non-negative integer | 0 (unlimited) |
| object-label | optional | string | |
| top | optional | empty | |
| left | optional | empty |
AssociableHotspot Attributes (element: qti-associable-hotspot)
| Name | Usage | Value(s) | Default |
|---|---|---|---|
| identifier | required | Identifier | |
| template-identifier | optional | Identifier | |
| show-hide | optional | Vocabulary:• show• hide | show |
| match-group | optional | IdentifierList | |
| shape | required | Vocabulary:• circle• default• ellipse• poly• rect | |
| coords | required | Coords.Type | |
| hotspot-label | optional | string | |
| match-max | required | Non-negative integer | |
| match-min | optional | Non-negative integer | 0 (unlimited) |
The graphic-gap-match-interaction must be bound to a response variable with base-type directedPair and multiple cardinality. The choices represent the source of the pairing and the gaps in the image (the hotspots) the targets. Unlike the simple GapMatchInteraction, each gap can have several choices associated with it if desired, furthermore, the same choice may be associated with an qti-associable-hotspot multiple times, in which case the corresponding directed pair appears multiple times in the value of the response variable.
The shared vocabulary for the Graphic Gap Match Interaction is intended to provide more precision when describing:
- Positioning of the Gap Choices container with respect to the image containing the hotspots.
- Gap Choices container width.
- Associable Hotspot Selections theming.
- Custom max|min-associations message overrides.
3.2.14.1 Gap Choices Container | Image Positioning
For explicit gap choices container positioning with respect to the passage text containing the gaps, use the class attribute as follows:
| Values | ||
| qti-choices-top | The gap choices container is displayed above the image. | |
| qti-choices-bottom | The gap choices container is displayed below the image. | |
| qti-choices-left | The gap choices container is displayed to the left of the image. | |
| qti-choices-right | The gap choices container is displayed to the right of the image. | |
The following examples demonstrate shared vocabulary describing the visual orientation of the gap choices container with respect to the image containing the hotspots.
Example: Demonstrates class="qti-choices-top"
|
|
|
|
Example: Demonstrates class="qti-choices-bottom"
|
|
|
|
Example: Demonstrates class="qti-choices-left"
|
|
|
|
Example: Demonstrates class="qti-choices-right"
|
|
|
|
3.2.14.2 Choices Container Width
A common implementation of the graphic gap match interaction is to place the gap choices in a so-called, "gap choices container". One can achieve a visual equivalent of gap choices stacking by manipulating the gap choices container width.
For specifying explicit gap choices container width, use a data- attribute as follows:
| Values | ||
| data-choices-container-width | The gap choices container width in pixels. Example: data-choices-container-width="100" | |
Example: Demonstrates qti-choices-top and data-choices-container-width="188"
|
|
|
|
Example: Demonstrates qti-choices-left and data-choices-container-width="100"
|
|
|
|
3.2.14.3 Graphic Gap Match Hotspot Selections Theming
For explicit associable hotspot selection theming, use the class attribute as follows:
| Values | ||
|---|---|---|
| qti-selections-light | Delivery platform must implement associable hotspot selections in a color that the platform believes to be of suitable color contrast and opacity against a "dark" background image. | |
| qti-selections-dark | Delivery platform must implement associable hotspot selections in a color that the platform believes to be of suitable color contrast and opacity against a "light" background image. | |
| qti-unselected-hidden | Delivery platform must implement associable hotspot selections that are visually hidden (no visual border and no fill) unless a candidate is actively attempting to match gap choices with the selections. | |
In the absence of such selections theming overrides, delivery systems should render platform defaults. When using qti-selections-dark and qti-selections-light classes, the intent is to increase the contrast between the selections and the background, to ensure candidates can clearly identify the selections.Use qti-selections-light to indicate that the selection lines and fills should be lighter than usual to accommodate for the background image. Use qti-selections-dark to indicate that the selection lines and fills should be darker than usual to accommodate for the background image.
For qti-unselected-hidden, note that there is an obvious visual bias for these types of questions. In addition, the selection should only be visually-hidden. If a candidate is known to have low-vision indications in their PNP, the class should be ignored, and the selection should NOT be visually hidden. Selections should always be programmatically available (usable by keyboards and assistive technology).
Example: Demonstrates Associable Hotspot selections with class="qti-selections-light"
|
|
|
|
Example: Demonstrates Associable Hotspot selections with class="qti-selections-dark"
|
|
|
|
3.2.14.4 Graphic Gap Match Custom max|min-associations Messages
To specify custom max-associations or min-associations messages, use a data- attribute as follows:
| Values | ||
| data-max-selections-message | Custom message to be rendered by the delivery platform upon violation of the max-associations constraint. | |
| data-min-selections-message | Custom message to be rendered by the delivery platform upon violation of the min-associations constraint. | |
In the absence of such custom message overrides, delivery systems should render platform defaults.
3.2.15 Media
The MediaInteraction.Type (qti-media-interaction) enables measurement of the number of times the media object was experienced. This quantity is reported in the value of the interaction's response variable.
MediaInteraction Attributes (element: qti-media-interaction)
| Name | Usage | Value(s) | Default |
|---|---|---|---|
| autostart | required | boolean | Note: Accessibility guidelines suggest that candidates should initiate any media instead of automatically playing the media, therefore the value should be "false". |
| min-plays | optional | Non-negative integer | 0 (unlimited) |
| max-plays | optional | Non-negative integer | 0 (unlimited) |
| loop | optional | boolean | false |
| coords | optional | Coords.Type |
The sub-elements include:
- audio
- video
- object (deprecated)
The qti-media-interaction must be bound to a response variable of base-type integer and single cardinality.
Example: Demonstrates qti-media-interaction
|
|
|
|
3.2.16 Position Object
The PositionObjectInteraction.Type (qti-position-object-interaction) consists of a single image which must be positioned on another graphic image (the stage) by the candidate. Like Select Point Interaction, the associated response may have a qti-area-mapping that scores the response on the basis of comparing it against predefined areas but the delivery engine must not indicate these areas of the stage. Only the actual position(s) selected by the candidate shall be indicated.
PositionObjectInteraction Attributes (element: qti-position-object-interaction)
| Name | Usage | Value(s) | Default |
|---|---|---|---|
| center-point | optional | IntegerList | |
| min-choices | optional | Non-negative number | |
| max-choices | optional | Non-negative number | 1 |
The sub-element for the qti-position-object-interaction is either the HTML "img" or "picture" element. The object element is deprecated in QTI 3.
The qti-position-object-interaction must be bound to a response variable with a base-type of point and single or multiple cardinality. The point records the coordinates, with respect to the stage, of the centre point of the image being positioned.
Position Object Interaction, has a required parent, the qti-position-object-stage, which is a graphic image (represented as an "object"), on top of which the Position Object Interaction image is to be positioned. A single qti-position-object-stage may have several Position Object Interactions as child elements, representing several objects to be positioned on the same "stage".
Example: Demonstrates qti-position-object-interaction
|
|
|
|
3.2.17 Select Point
The SelectPointInteraction.Type (qti-select-point-interaction) is a graphic interaction. The candidate's task is to select one or more points. The associated response may have an qti-area-mapping that scores the response on the basis of comparing it against predefined areas but the delivery engine must not indicate these areas of the image. Only the actual point(s) selected by the candidate shall be indicated.
SelectPointInteraction Attributes (element: qti-select-point-interaction)
| Name | Usage | Value(s) | Default |
|---|---|---|---|
| min-choices | optional | Non-negative number | 0 |
| max-choices | optional | Non-negative number | 0 (unlimited) |
The sub-element for the qti-select-point-interaction is either the HTML "img" or "picture" element. The object element is deprecated in QTI 3.
The select point interaction must be bound to a response variable with a base-type of point and single or multiple cardinality.
3.2.18 Slider
The SliderInteraction.Type (qti-slider-interaction) presents the candidate with a control for selecting a numerical value between a lower and upper bound. It must be bound to a response variable with single cardinality with a base-type of either integer or float.
Note that a slider interaction does not have a default or initial position except where specified by a default value for the associated response variable. The currently selected value, if any, must be clearly indicated to the candidate.
Because a slider interaction does not have a default or initial position, except where specified by a default value for the associated response variable, it is difficult to distinguish between an intentional response that corresponds to the slider's initial position and a NULL response. As a workaround, slider interaction items have to either a) not count NULL responses (i.e. count all responses as intentional) or b) include a 'skip' button and count its activation combined with a response variable that is equal to the slider's initial position as a NULL response.
There are six attributes for the qti-slider-interaction where the lower-bound and upper-bound are required attributes:
Slider Interaction Attributes (element: qti-slider-interaction)
| Name | Usage | Value(s) | Default |
|---|---|---|---|
| lower-bound | required | NonNegativeDouble | |
| upper-bound | required | NonNegativeDouble | |
| step | optional | NonNegativeDouble | 1.0 |
| step-label | optional | boolean | false |
| orientation | optional | Vocabulary;
|
|
| reverse | optional |
Example: Demonstrates qti-slider-interaction
|
|
|
|
3.2.19 Upload
The UploadInteraction.Type (qti-upload-interaction) allows the candidate to upload a pre-prepared file representing their response.
The qti-upload-interaction must be bound to a response variable with base-type file and single cardinality.
UploadInteraction Attributes (element: qti-upload-interaction)
| Name | Usage | Value(s) | Default |
|---|---|---|---|
| class | optional | xs:string | |
| response-identifier | mandatory | identifier |
Example: Demonstrates qti-upload-interaction
| 0001 | <qti-upload-interaction response-identifier="RESPONSE" /> | |
|
||
3.2.20 Drawing Interaction
The DrawingInteraction.Type (qti-drawing-interaction) allows the candidate to use a set of drawing tools to modify a given graphical image (the canvas). It must be bound to a response variable with base type file and single cardinality.
DrawingInteraction Attributes (element: qti-drawing-interaction)
| Name | Usage | Value(s) | Default |
|---|---|---|---|
| class | optional | xs:string | |
| response-identifier | mandatory | identifier |
The sub-element of the qti-drawing-interaction are the HTML elements img, picture, or object. The image specified within one of the aforementioned elements acts as the canvas on which the drawing takes place. It is best practice to use the img or picture elements for this interaction. If using the deprecated object element it MUST be of an image type, as specified by the type attribute.
Example: Demonstrates qti-drawing-interaction
|
|
|
|
3.2.21 End Attempt
End Attempt Interaction is a special interaction which immediately ends the current attempt on an assessment item. It may be used, for example, to allow the candidate to request a hint or model solution, or in an adaptive item to let the candidate display feedback or to move to the next in a series of interactions in the item.
EndAttemptInteraction Attributes (element: qti-end-attempt-interaction)
| Name | Usage | Value(s) | Default |
|---|---|---|---|
| title | mandatory | xs:string | |
| count-attempt | optional | xs:boolean |
Example: Demonstrates qti-end-attempt-interaction with a Hint
|
|
|
|
3.2.22 Custom Interaction
The CustomInteraction.Type (qti-custom-interaction) provides an opportunity for delivery platform-specific extensibility of this specification to include support for interactions not currently built into the QTI specification. This can be used, for example, to develop technology-enhanced items.
As the user interface and behavior of a qti-custom-interaction are custom, there is no predefined shared vocabulary for qti-custom-interaction. However if a qti-custom-interaction implements a feature or behavior in a way which is consistent with how that has been defined for the pre-defined interaction types then it may use qti- prefixed class names to indicate it supports a behaviour consistent with the use of that shared vocabulary elsewhere in this specification; e.g., a qti-custom-interaction which supports text entry by the candidate may support the qti-input-width set of classes to control the visible width allocated to display of the candidate's input.
CustomInteraction Attributes (element: qti-custom-interaction)
| Name | Usage | Value(s) | Default |
|---|---|---|---|
| class | optional | xs:string | |
| response-identifier | mandatory | identifier |
Example: Demonstrates qti-custom-interaction
|
|
|
|
3.2.23 Portable Custom Interaction (PCI)
The PortableCustomInteraction.Type (qti-portable-custom-interaction) allows an item author with the support of a PCI module developer the ability to render an interaction with a custom user interface and behaviors by providing custom Javascript code supporting the interaction. This can be used, for example, to develop technology-enhanced items.
The Javascript code which implements a PCI may be included with the item in the content package or may reside elsewhere on the network. It will be loaded dynamically by the delivery engine when the item containing the PCI is presented. These Javascript modules must be AMD (Asynchronous Module Definition) modules, and must conform to the PCI API, detailed later in this document. The markup of a PCI may include any HTML5, MathML, and SSML elements supported elsewhere in QTI. In addition, a PCI may contain feedback, template, and printed variable elements. Finally, a special templateelement may be included. This may be used only in a PCI and is a container for any valid XML markup.
As the user interface and behavior of a PCI are custom, there is no predefined shared vocabulary for PCIs. However if a PCI implements a feature or behavior in a way which is consistent with how that has been defined for the pre-defined interaction types then it MAY use qti- prefixed CSS class names to indicate it supports a behaviour consistent with the use of that shared vocabulary elsewhere in this specification; e.g. a PCI which supports text entry by the candidate may support the qti-input-width set of classes to control the visible width allocated to display of the candidate's input.
There is a detailed example of a PCI in Section 3.7.12 . Consequently, example definitions and expected renderings are not provided here.
3.3 Composite Items
Composite items are items that contain more than one interaction. Composite items may contain multiple instances of the same type of interaction or have a mixture of interaction types.
While a QTI item may contain multiple interactions, an interaction MUST NOT be nested or contained within any other interaction. Items with nested interactions are not considered compliant to the QTI standard regardless of whether they pass validation or not.
Example: Demonstrates composite item with two Inline Choice interactions and oneText Entry interaction, Response Processing with partial scoring
|
|
|
|
3.4 Response Processing
Item response processing occurs after the candidate has completed an attempt on an item. The purpose of response processing is to compute the value of the item's outcome variables. The most common application is to compute the candidate's score on the item, but in more advanced items, response processing may be used to show or hide feedback or interaction choices, and for other purposes.
3.4.1 Response Processing Rules
Response processing consists of a sequence of rules that are carried out, in order, by the response processor. A ResponseCondition rule is a special type of rule which contains sub-sequences of rules divided into responseIf , responseElseIf and responseElse sections. The response processor evaluates the expressions in the responseIf and responseElseIf elements to determine which sub-sequence to follow. In this example, the responseIf section is followed only if the variable with identifier RESPONSE matches the correct response declared for it. The responseElseIf section is followed if RESPONSE matches the response explicitly given (which places the correct driver 1st but confuses the other two). Finally, the responseElse section is followed if neither of the previous two apply. The responseElse section has no corresponding expression of course. The qti-set-outcome-value element is just a ResponseRule that tells the processor to set the value of the specified outcome variable to the value of the expression it contains.
The qti-variable , qti-correct and qti-base-value elements are examples of simple expressions. In other words, expressions that are indivisible. In contrast, the qti-match and qti-ordered elements are examples of operators. Operators are expressions that combine other expressions to form new values. For example, match is used to form a boolean depending on whether or not two expressions have matching values.
3.4.2 Fixed and General Response Processing
There are two forms of response processing:
- Fixed Template Response Processing
- General Response Processing.
In "fixed template" response processing, the processing to be done is identified by a "template name". There are three standard template names, and a delivery engine may define additional template names. For simple scenarios, the "match_correct" and "map_response" standard templates may be used because this maximizes interoperability. All conformant delivery systems are required to provide response processing as defined by these two templates, while there is no assurance that a template other than these two will be supported, or that general response processing will be supported.
The three standard "fixed" response processing templates are:
| Template Name | Description | Location |
| match_correct | https://purl.imsglobal.org/spec/qti/v3p0/rptemplates/match_correct.xml | |
| map_response | https://purl.imsglobal.org/spec/qti/v3p0/rptemplates/map_response.xml | |
| map_response_point | https://purl.imsglobal.org/spec/qti/v3p0/rptemplates/map_response_point.xml |
For "general" response processing, QTI defines an XML-based Domain Specific Language (DSL) with a large number of commands and operators for computing and setting template and outcome variables. General response processing is necessary for more complex items, such as items generated from templates, adaptive items involving feedback, and composite items.
The same Domain Specific Language is also used for Outcome Processing, Template Defaults, Constraints, and Processing, and for evaluating Preconditions and Branch Rules.
3.4.3 Partial Scoring
Please see section 3.3 Composite Items for an example of response processing that implements partial scoring.
3.4.4 Conformance
It is possible to define the effect of the standard templates using the "general" response processing DSL, but it is not required that a QTI 3 Entry-level delivery system implement the standard templates through support of the DSL. A "built-in" implementation of the standard templates is sufficient for conformance in a QTI 3 Entry-level delivery system.
At the QTI 3 Core-level of conformance, a delivery system is required to support enough of the response processing DSL to be able to load and execute at least the "match_correct" and "map_response" standard templates, as well as other templates or inline response processing blocks using the same subset of the Domain Specific Language as these two standard templates. For convenience and performance, a QTI 3 Core-level delivery system may still also use the "built-in" approach for some of the templates which it supports, in addition to supporting the response processing language.
3.4.5 External Scoring
In some cases, response processing is undertaken by external systems or human scorers. This is typically the case for items asking candidates to write an essay. However, it might be important for external systems or human scorers to know which outcome value has to be set to derive an appropriate score.
External Scoring Example
|
This example describes an item with a single qti-extended-text-interactionasking the candidate to write an essay. As the item does not contain qti-response-processing, the SCORE qti-outcome-declaration has its external-scored attribute value set to "human". This makes QTI compliant systems aware that the final value of SCORE has to be set by a human scorer after the Item Session has closed.
3.5 Outcomes
Outcome variables are declared by outcome declarations. Their value is set either from a default given in the declaration itself or by a responseRule during responseProcessing.
Items that declare a numeric outcome variable representing the candidate's overall performance on the item should use the "SCORE" built-in outcome variable. SCORE must have a base-type of float.
Items that declare a maximum score (in multiple response choice interactions, for example) should do so by declaring the built-in variable named "MAXSCORE". MAXSCORE must have a base-type of float.
Items or tests that want to make the fact that the candidate scored above a predefined threshold available as a variable should use the built-in "PASSED' outcome variable. PASSED must have a base-type of boolean.
At runtime, outcome variables are instantiated as part of an item session. Their values may be initialized with a default value and/or set during response processing. If no default value is given in the declaration then the outcome variable is initialized to NULL unless the outcome is of a numeric type (integer or float) in which case it is initialized to 0.
For non-adaptive Items; i.e., items that do not use template processing to compute default values, the values of the outcome variables are reset to their default values prior to each invocation of response processing. For adaptive Items, the outcome variables retain the values that were assigned to them during the previous invocation of response processing. For more information, see section 3.4.2 Fixed and General Response Processing .
There is one built-in outcome variable, "completionStatus", that is declared implicitly and must not appear in an outcomeDeclaration. Delivery Engines must maintain the value of the built-in outcome variable completionStatus, a single identifier. It starts with the reserved value "not_attempted". At the start of the first attempt it changes to the reserved value "unknown". It remains with this value for the duration of the item session unless set to a different value by a setOutcomeValue rule in responseProcessing. There are four permitted values:
- 'completed' - the candidate has experienced enough of the item to consider it completed;
- 'incomplete' - the candidate has not experienced enough of the item to consider it completed;
- 'not_attempted' - the candidate is considered to have not used the item in any significant way;
- 'unknown' - no assertion on the state of completion can be made.
Any one of these values may be set during response processing. If an Adaptive Item sets completionStatus to completed then the session must be placed into the closed state, however an item session is not required to wait for the completed signal before terminating, it may terminate in response to a direct request from the candidate, through running out of time or through some other exceptional circumstance. Adaptive Items must maintain a suitable value and should set completionStatus to "completed" to indicate when the cycle of interaction, response processing and feedback must stop. Non-adaptive Items are not required to set a value for completionStatus, but they may do so. Delivery Engines are encouraged to use the value of completionStatus when communicating externally.
OutcomeDeclaration Attributes (element: qti-outcome-declaration)
| Name | Usage | Value(s) | Default |
|---|---|---|---|
| identifier | required | Identifier | |
| base-type | required | Normalized string
|
|
| cardinality | required | Normalized string
|
|
| view | optional | Normalized string
|
The intended audience for an outcome variable can be set with the view attribute. If no view is specified the outcome is treated as relevant to all views. Complex items, such as adaptive items or complex templates, may declare outcomes that are of no interest to the candidate at all, but are merely used to hold intermediate values or other information useful during the item or test session. Such variables should be declared with a view of author (for item outcomes) or testConstructor (for test outcomes). Systems may exclude outcomes from result reports on the basis of their declared view if appropriate. Where more than one class of user should be able to view an outcome variable the view attribute should contain a comma delimited list. |
| interpretation | optional | string | A human interpretation of the variable's value. |
| long-interpretation | optional | uri | An optional link to an extended interpretation of the outcome variable's value. Declared outcomes with numeric types should indicate their range of possible values using normal-maximum and normal-minimum, especially if this range differs from [0,1]. Declared outcomes with numeric types should indicate their range of possible values using normal-maximum and normal-minimum, especially if this range differs from [0,1]. |
| normal-maximum | optional | float | The normal-maximum attribute optionally defines the maximum magnitude of numeric outcome variables, it must be a positive value. If given, the outcome's value can be divided by normal-maximum and then truncated (if necessary) to obtain a normalized score in the range [-1.0,1.0]. normal-maximum has no effect on response processing or the values that the outcome variable itself can take. |
| normal-minimum | optional | float | The normal-minimum attribute optionally defines the minimum value of numeric outcome variables, it may be negative. |
| mastery-value | optional | float | The mastery-value attribute optionally defines a value for numeric outcome variables above which the aspect being measured is considered to have been mastered by the candidate. |
3.6 Stylesheets
QTI 3 introduces an extensive shared vocabulary for improving item interaction rendering interoperability (see Section 3.2.1 ). To further improve item rendering interoperability, QTI 3 also introduces a limited number of shared CSS style names and conventions for use by authoring and delivery systems.
By implementing these shared styles and conventions, QTI 3 authoring and delivery platforms can safely import/export – or render – items while preserving certain presentation characteristics without using custom stylesheet injection. Note that all of the shared styles are prefaced by the "qti-" string so as to avoid collisions with a delivery platform's existing CSS.
The following two sections provide an overview of the semantics of the shared CSS classes. Reference implementations of each CSS class – and further examples – can be found in the 1EdTech GitHub QTI 3 repository. Over time, it is expected that additional shared CSS style names and definitions will be added to this repository. Section 3.6.3 provides a description of how to use custom stylesheets in the event that the QTI shared CSS styles are insufficient.
3.6.1 General-Purpose Shared CSS Classes - Definitions and Examples
3.6.1.1 qti-underline
| Semantics | Example CSS Definition | ||
|---|---|---|---|
| Underline an element |
|
||
<p>Look at the <span class="qti-underline" >text</span> in the picture.</p> |
|||
| Look at the text in the picture | |||
3.6.1.2 qti-italic
| Semantics | Example CSS Definition | ||
|---|---|---|---|
| Italicize an element |
|
||
<p>Look at the <span class="qti-italic" >text</span> in the picture.</p> |
|||
| Look at the text in the picture | |||
3.6.1.3 qti-align-left | -center | -right
| Semantics | Example CSS Definition | ||
|---|---|---|---|
| Horizontal alignment, left, center, and right. |
|
||
|
|||
|
|||
3.6.1.4 qti-valign-top | -middle | -baseline | -bottom
| Semantics | Example CSS Definition | ||
|---|---|---|---|
| Vertical alignment, top, middle, baseline, and bottom. |
|
||
|
|||
|
|||
3.6.1.5 qti-fullwidth
| Semantics | Example CSS Definition | ||
|---|---|---|---|
| Set the width of the element to 100% of the width of the element's container. |
|
||
|
|||
| Note: Table border added for effect. Table expands to 100% width of its container. | |||
3.6.1.8 qti-bordered
3.6.1.9 qti-well
| Semantics | Example CSS Definition | ||
|---|---|---|---|
| qti-bordered adds a visual border to an element. qti-well adds a "well" to an element. A "well" is a UI convention of adding visual importance to an element. Increased visual importance is usually achieved by adding both a border and background + foreground colors to the element. The background color should be chosen by the delivery platform so as not violate WCAG AA guidelines for foreground color textual contrast. |
|
||
|
|||
|
|||
3.6.2 Shared CSS Classes for Item Body Layout - Definitions and Examples
A common assessment presentation requirement is to arrange item stimuli, stems, and interactions into standard layouts which minimize scrolling and cognitive load while also supporting common user interface patterns about how content is displayed. Historically, this requirement has led authoring and delivery systems to implement such presentation layouts in ways that may impede interoperability. To address this common requirement, QTI 3 introduces shared "layout" CSS class names and definitions. By implementing these layout CSS class names and definitions, delivery and authoring platforms can achieve a wide range of flexible, responsive, standardized, interoperable item presentation user interfaces.
The QTI 3 shared Layout CSS class design and styles emulate well-known modern CSS presentation frameworks which define responsive layout grids in terms of "rows", each of which contains twelve "columns", each of which can be defined individually or grouped together to equal twelve total columns in each row.
The first row above is divided into twelve individual columns. The second row contains twelve columns grouped into three four-column groupings. The third row contains twelve columns grouped into one four-column grouping, and one eight-column grouping. The fourth row contains twelve columns grouped into two six-column groupings. The fifth row contains one twelve-column grouping which encapsulates all of the columns in a single row.
Furthermore, rows and columns may be nested inside column groupings so long as the total number of nested columns equals the number of columns in the parent container column grouping.
Rows and column groupings are specified on <div> elements in the qti-item-body and are defined with the following class names:
3.6.2.1 qti-layout-row
3.6.2.2 qti-layout-col1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
Example: Item Body with one layout row, and two six-column (qti-layout-col6) groupings
|
||
|
Example: Item Body with two layout rows, each row with different column groupings
|
||
| The first row contains column groupings of 8 and 4. A stimulus is placed into the eight-column grouping on the left. A hotspot interaction is placed into the four-column grouping to the right of the stimulus. The second row contains one twelve-column grouping spanning the entire width of the second row. A match interaction and stem are placed into the second row's twelve-column grouping. 
|
3.6.2.3 qti-layout-offset1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11
Column groupings within a row can be "offset" (from left to right) from the beginning of a row, or from a column grouping to the left. One row should never contain column groupings plus offsets that exceed twelve; i.e., the maximum number of columns in a row.
Column offset definitions can be visualized in the following diagram which contains three rows, each having twelve total columns. The first row contains a three-column grouping offset by two columns from a four-column grouping. The second row contains a three-column grouping offset by one column, plus a second three-column grouping offset by two columns.
Example: Item Body with one layout row, and two three-column (qti-layout-col3) groupings, the first of which is offset by three columns
|
||
| The item's stimulus is placed in the leftmost three-column grouping which is offset by three columns, while the interaction is placed in an adjacent three-column grouping. This creates the visual impression of a six-column grouping that is horizontally centered in a row. 
|
3.6.3 Custom Styles
For QTI 3, the best practice is to avoid using custom styles, and instead use the Shared CSS Vocabulary as described in the aforementioned Sections 3.6.1 and 3.6.2. By using the Shared CSS style names, Test Delivery Systems can optimize the rendering experience for accessibility and for design responsiveness.
However, as a last resort, custom stylesheets may be injected into an item and other QTI content, such as tests, stimuli, and feedback, rubric, and template blocks, using the qti-stylesheet element:
|
<qti-stylesheet href="samples/assessmentitem.css" />
As in earlier versions of QTI, it is not required for conformance for delivery systems to support the qti-stylesheet element -- a further reason why stylesheet injection is likely not to be interoperable. Notwithstanding these issues, if your implementation will be using stylesheets, QTI 3 recommends the use of CSS 3 stylesheets. For more information on CSS 3 stylesheets, see the W3C documentation at https://www.w3schools.com/css/default.asp .
The best practice convention in QTI 3 is that stylesheets referenced within an AssssmentItem file apply to the item itself, and are not assumed to apply to associated content such as stimulus ( qti-assessment-stimulus) or rubric blocks ( qti-rubric-block), both of which can have their own associated stylesheets. An item's stylesheets are assumed to apply to content within qti-item-body, qti-catalog-info, as well as to any content generated from the use of feedback or templates. Any included content using XInclude that is placed within the qti-item-body, qti-catalog-info, and qti-modal-feedback, or qti-template-block generated content is also assumed to be covered by the stylesheet reference made within an item.
It is the responsibility of an item author to limit the scope of an injected stylesheet to the content with which it is associated. Because of the way CSS scoping is defined, this is admittedly difficult. The following describes some approaches to limiting CSS scope:
- Use class naming conventions. Use a naming convention for CSS classes which includes a prefix with an item vendor-specific code, and which is likely to make custom class names globally unique.
- Avoid bare element or attribute selectors. Avoid CSS style rules which apply broadly, such as those using "bare" element or attribute selectors. Such rules are very likely to have a wider impact than intended. Do not write rules like "div {color: red}". There are bound to be many other div'sin the document, not all of which should be red. Instead, write ".vendorprefix-red { color: red }", and add the "vendorprefix-red" class to elements in the content which should be red. Further note: at all costs, avoid specifying any colors in custom style definitions as these are practically guaranteed to result in an accessibility problem for the delivery platform.
- Do not assume defaults are in effect. Do not assume that CSS properties will have their default values. If it is important for an element to have the default CSS property values, you should set the properties explicitly to the default values.
- Use id attributes and descendent selectors. QTI 3 allows the use of the id attribute on HTML5 elements. It may be helpful to assign an id to a higher level element within the HTML content you are styling, such as a div,and write style rules against that id, possibly combined with descendant selectors. Choose ids that are likely to be globally unique so that other stylesheets in the environment don't affect your content, and vice-versa.
- Do not assume order.Do not assume an injected stylesheet will be first or last, or in any particular position relative to other stylesheets in the delivery environment. That is, if item 1 injects stylesheet A, and the next item, item 2, injects stylesheet B, a delivery engine is free to insert the two stylesheets in any order, and an author cannot rely on stylesheet B being after stylesheet A. Even worse, stylesheet C, from somewhere else entirely, may land in between the two. In short, it is not really possible to rely on the CSS cascade between stylesheets, because the ultimate ordering of the stylesheets is not defined.
- Be aware of delivery system artifacts. You may observe that the HTML generated by the delivery system for QTI content includes HTML elements which were not in the original content. This is because delivery engines commonly transform QTI content such as interactions, interaction components (e.g. qti-prompt, or qti-simple-choice), the qti-item-body, catalog cards, rubrics, feedback blocks, etc, into standard HTML elements, and these will end up as the parents, children, or siblings of the HTML elements placed in the item directly. It is unwise to style these system-generated elements or to rely on the generated structure in CSS style rules, because another delivery system, or even another version of the same delivery system, will generate a different structure. Be aware when writing style rules that delivery system artifacts may appear "out of nowhere" and "get in the way" of sibling selectors, child selectors, adjacency selectors, first- and last-child pseudo-selectors, and the like.
- Do not depend on the stylesheet. To be interoperable, QTI content should fall back to a functional and accessible presentation even if the stylesheet is not injected. When injecting a stylesheet, authors should still rely on the CSS Shared Vocabulary for most of the styling and reserve the additional rules in the stylesheet for styling which cannot be achieved through Shared Vocabulary. An author should ensure that the content is acceptable with just Shared Vocabulary and be prepared for a stylesheet not to be injected at all.
Here is an example item, generated by a fictional vendor Quizzco, with some of these best practices applied:
Item with External Stylesheet Example
|
External Stylesheet Example
|
3.7 Advanced Item Structures
3.7.1 Customized Response Processing
The qti-custom-operator extension mechanism allows the inclusion of custom, non-QTI response evaluation rules. In general, such APIs are likely to be particular to a specific software library or programming language. For that reason, it is difficult to predict what form such custom operators will take, and, by extension, how to generalise functions or syntax between different custom operators.
By way of illustration, the following fragment illustrates the use of the Maxima engine as a response processing library via the qti-custom-operator element.
|
In this case, a qti-custom-operator is used as a very slim container for what is effectively a complete script in Maxima's language. A QTI processor designed to work with this qti-custom-operator could pass the script verbatim to Maxima, and use its response to set the 'oDummy' outcome value.
3.7.2 Adaptive Items
Adaptive items are a feature that allows an item to be scored adaptively over a sequence of attempts. This allows the candidate to alter their answer following feedback or to be posed additional questions based on their current answer. Response processing works differently for adaptive items. Normally (for non-adaptive items) each attempt is independent and the outcome variables are set to their default values each time response processing is carried out. For adaptive items, the outcome variables retain their values across multiple attempts and are only updated by subsequent response processing. This difference is indicated by the value of the adaptive attribute of the Assessment Item. Adaptive items must of course provide feedback to the candidate in order to allow them to adjust their response(s).
Using qti-feedback-block to show a solution
items/Example03-feedbackBlock-solution.xml
In this example, the feedback is used to contain a solution which is displayed when the user clicks the "Show Solution" button.
|
A randomized version of the item above is also available here:
items/Example03-feedbackBlock-solution-random.xml .
The randomization does not affect the display of the solution in this example.
Using qti-template-block and qti-template-inline inside qti-feedback-block to adjust content:
items/Example04-feedbackBlock-templateBlock.xml
The qti-feedback-block element can contain subsidiary feedback elements, "template" elements and interactions alongside any of the HTML elements. In this question, the values of template variables are calculated within the templateProcessing element, and the solution is different depending on the value of the variable iA; if iA=90, the right angle in the triangle makes the question easier.
The method for displaying the solution is as in the previous example; here we concentrate on the template elements within the SOLUTION feedbackBlock.
Using qti-feedback-block to change the appearance of a question
items/Example05-feedbackBlock-adaptive.xml
In this example, the "feedback" forms part of the question. In adaptive questions, feedbackBlock and feedbackInline elements can contain interactions:
Monty Hall (Take 1)
Section 3.8.3 - Annotated Item Examples - Monty Hall (Take 1)
This example takes a famous mathematical problem and presents it to the user as a game. The qti-feedback-block element, in association with a number of outcome variables is used to control the flow of the story, from the opening gambit through to whether or not you have won a prize. When the story concludes you are asked about the strategy you adopted. Notice that the scoring for the question is based on the actual strategy you took (one mark) and your answer to the final question (two marks). If you choose a bad strategy initially you are always punished by losing the game. If you feel that this is cheating take a look at a more realistic version of the same question which combines adaptivity with the powerful feature of item templates: Monty Hall (Take 2).
Mexican President with hints
In this example, Mexican President is extended to provide both feedback and the option of requesting a hint. The qti-end-attempt-interaction controls the value of the response variable HINTREQUEST - which is true if the attempt ended with a request for a hint and false otherwise.
3.7.3 Feedback
Feedback consists of material presented to the candidate conditionally, based on the values of outcome variables, allowing an item to be reconfigured as a result of Response Processing . In other words, feedback is controlled by the values of outcome variables. There are several types of feedback material:
- Feedback blocks ( qti-feedback-block) are shown to the candidate based on the value of an outcome variable. Each feedback block is associated with an outcome variable and an identifier. If the outcome variable has that identifier as its value, then the feedback block is shown or hidden, as determined by the value of the show-hide attribute. Feedback blocks may contain almost any valid qti-item-body content, including interactions and other feedback blocks. Feedback blocks may be used inside many interaction components, such as choices, and within HTML5 elements, such as div. After each attempt, following a round of response and outcome processing, the delivery engine re-computes the visibility of feedback blocks based on possibly new values of the controlling outcome variables. By default, the changed state of feedback content is only shown during subsequent attempts on, or review of, an item.
- Inline feedback ( qti-feedback-inline) is similar to block feedback, but may only be used in "inline" contexts. Inline feedback elements may only contain inline HTML5 content, such as span, and inline QTI interactions, such as qti-inline-choice-interaction, or qti-text-entry-interaction.
- Modal feedback ( qti-modal-feedback) is item content which is shown to (or hidden from) the candidate based on the value of outcome variables, and whose display can be changed by response processing. Those display changes become visible before any subsequent attempt or review of the item. As with feedback blocks, the value of a controlling outcome variable is used in conjunction with the show-hide and identifier attributes to determine whether or not the feedback is presented. Unlike feedback blocks and inline feedback, the modal feedback element cannot contain any interactions, and may not be used inside an item body. Because modal feedback is not part of the item body, it may be displayed "modally" -- for example, as a pop-up "dialog box" which appears after response and outcome processing and which must be dismissed by the candidate after it is read. However, how modal feedback is displayed is left to the delivery platform, and an implementation may simply display modal feedback in-line in the item, similar to other forms of feedback.
- Test feedback ( qti-test-feedback) is allowed within qti-assessment-test and qti-test-part, and is otherwise very similar to modal feedback. Test feedback may be configured to be shown during the test or test part ( access="during"), or only when the candidate reaches the end of the test or test part ( access="atEnd").
Using qti-modal-feedback
items/Example01-modalFeedback.xml
In this example, a straightforward multi-choice question declares an additional outcome variable called FEEDBACK which is used to control the visibility of just qti-modal-feedback .
Using qti-feedback-inline
items/Example02-feedbackInline.xml
In this example, the feedback appears within the question, right beside the text of the selected option. The content of qti-feedback-inline is restricted to material which can be displayed "inline", i.e. without moving to a new block or paragraph, so it behaves like the HTML "span" element.
3.7.4 Item Templates
Item Templates are items which function as templates that can be used for generating large numbers of related items. The generated items are often called "cloned items". Item templates can be used by special-purpose software, a so-called "cloning engine" to produce many clones of the template.
Where Delivery Engines support Template Processing, an Item Template can also be included directly in an assessment. At delivery time, the delivery engine will run the Template Processing in the item, giving the item's template variables values, and possibly computing new correct responses based upon the template variable values, effectively creating a single clone of the item template dynamically. In combination with the QTI selection element with the attribute with-replacement="true", a single Item Template in an assessment may be instantiated multiple times, and appear to the candidate as a different item each time, as a result of the Template Processing in the Item being run in each separate instance.
Each item cloned from an Item Template is identical except for the value, qti-default-value, and qti-correct-responsevalue of the template, response, and outcome variables of the item, as assigned by the Template Processing.
An Assessment Item is therefore an Item Template if it contains a set of Template Processing rules for assigning values to the item variables. An Item Template will typically also have Template Declarations for template variables, although this is not mandatory. The state of the template, outcome, and response variables post-Template Processing is what distinguishes one clone of an item from another.
A cloning engine that creates cloned items must assign a different identifier to each clone and record the values of the template variables used to create it. A report of an item session with such a clone can then be transformed into an equivalent report for the original item template by substituting the item template'sidentifier for the cloned item's identifier and adding the values of the template variables to the report.
Item templating features may be used in combination with QTI adaptive and feedback features to provide items with varying paths through multiple interactions.
The main QTI features which support Item Templates include:
- Template Variables. Similar to response, outcome, and context variables, template variables are defined by the qti-template-declarationelement. The default values of template variables can be set in the declaration or by qti-template-defaultelements. The values may subsequently be changed via Template Processing.
- Template Variable Defaults ( qti-template-default). While the default value of a template variable can be set using the qti-default-valueelement within the qti-template-declaration, in the same manner as with response and outcome declarations, the qti-template-default element may also be used to set the default value within an Assessment Item Reference at the Assessment Section level. This allows the default values of template variables, as specified within the item, to be overridden when an item is incorporated by reference into a particular assessment. The template default value can be given as an expression in the Template Processing domain-specific language.
- Template Content( qti-template-block and qti-template-inline). Conceptually similar to feedback blocks and inline feedback, template blocks and inline templates represent content which is shown to, or hidden from, the candidate based on the identifier and show-hide attributes of the template blocks and inline templates. Many of the interaction types also have subcomponents, such as hotspots or choices, which can be conditionally displayed (or hidden), using the same show-hide mechanism as template blocks and inline templates. This makes it possible, for example, to turn the choices in a Choice Interaction on or off via template variables.
- Template Variable Expansion. Printed variables ( qti-printed-variable) may be used to display template variable values, just as they may be used with outcome and context variables. In addition, if a template variable has the math-variable="true" attribute, MathML mi and mo variables will be replaced with the value of the corresponding template variable. Similarly, if a template variable has the param-variable="true" attribute, param element values will be replaced with the corresponding template variables.
- Template Processing( qti-template-processing). Similar to response and outcome processing, template processing may be defined within an item to compute and set the values of template, response, and outcome variables. The delivery system will run the template processing rules immediately before the first attempt on an item, just prior to its initial presentation to the candidate. Following template processing and still before the initial presentation of the item, the delivery system will then determine the visibility of template blocks and inline templates, and do variable expansion on printed variables, MathML and param elements based on template variables.
- Template Constraints( qti-template-constraint). A template constraint is a processing rule available only in Template Processing. It terminates Template Processing and re-runs it from the beginning if the condition specified in the template constraint is not satisfied. This can be used, for example, to iterate the Template Processing with different randomly-generated values until a predetermined condition is satisfied.
The following examples demonstrate a variety of templating features.
Digging a Hole
This example contains a simpleqti-text-entry-interaction(TextEntryInteraction.Type) but the question (and the correct answer) varies for each item session . In addition to the usual RESPONSE and SCORE variables a number of template variables are declared. Their values are set by a set of TemplateProcessing rules. Template processing is very similar to response processing. The same condition model and expression language are used. The difference is that TemplateRules set the values of template variables and not outcome variables. Notice that the declaration of RESPONSE does not declare a value for the CorrectResponse because the answer varies depending on which values are chosen for A and B. Instead, a special rule is used, qti-set-correct-response in the template processing section.
The display of aqti-text-entry-interaction response can be formatted through the use of a format attribute using # for optional digits. For example, comma separators and a leading 0 for decimal entries can be displayed if format="#,##0.#". A response 12345678 would display as 12,345,678, but would be captured as entered - "12345678". A response .12345 would be captured as entered, but would display as 0.12345. A response 1.2345 would display and be captured as entered, 1.2345. See https://code.google.com/p/javascript-number-formatter/ for the basis of this feature.
The qti-random-integer element represents a simple expression that selects a random integer from a specified range. The qti-random element represents an operator that selects a random value from a container.
The qti-item-body displays the values of the template variables using the qti-printed-variable element.
Mick's Travels
Sometimes it is desirable to vary some aspect of an item that cannot be represented directly by the value of a template variable. For example, in "Mick's Travels", the qti-item-body contains an illustration that needs to be varied according to the value chosen for a template variable. To achieve this, three qti-template-inline elements are used, each one enclosing a different img element. This element (along with the similar qti-template-block ) has attributes for controlling its visibility with template variables in the same way as outcome variables are used to control the visibility of feedback.
Item templates can be combined with adaptive items too.
Monty Hall (Take 2)
In Monty Hall (Take 1) we cheated by fixing the game so that the wrong strategy always lost the candidate the prize (and the first mark). In this version we present a more realistic version of the game using an item template. The same outcome variables are defined to control the story and the feedback given but this time a qti-template-declaration is used to declare the variable PRIZEDOOR. The qti-template-processing rules are then used to preselect the winning door at random making the game more realistic. The qti-response-processing rules are a little more complicated as the value of PRIZEDOOR must be checked (a) to ensure that Monty doesn't open the prize winning door after the candidate's first choice and (b) to see if the candidate has actually won the "fantastic prize".
In this example, using the correct strategy will still lose the candidate the prize 1/3 of the time (though they always get the mark). Do you think that the outcome of the game will affect the response to the final strategy question?
The number divisors
This example makes extensive use of templates to test knowledge of calculus. It has modal feedback and includes some mathML.
Test of statistics functions
An example that uses templates extensively, and uses many common numeric operators in the response processing. It has modal feedback and includes some mathML.
Product of a fraction by a number
This is another numeric example that makes use of templates, but is notable for its use of templateConstraint to determine variables at runtime.
3.7.5 Rubric Blocks
The qti-rubric-block element is the container for the rubric block content, which can be placed anywhere within the qti-item-body node of an AssessmentItem. A rubric block identifies part of the content that represents instructions to one or more of the actors that view the item.
Although rubric blocks are defined as simple blocks they must not contain interactions. The visibility of nested qti-rubric-blocks is determined by the outermost element. In other words, if an element is determined to be hidden then all of its content is hidden including conditionally visible elements for which the conditions are satisfied and that therefore would otherwise be visible.
If you use a stylesheet within a rubric block, the stylesheet is scoped only to that specific rubric block, and should not be used for other content within an AssessmentItem or any other rubric block. The stylesheet within the rubric block would also apply to any catalog content, if it were placed in that same rubric block. The assumption is that the rubric block also inherits from the AssessmentItem, and the rubric block stylesheet is intended to add styles or override AssessmentItem styles.
The qti-rubric-block element has two attributes, "use" and "view".
Rubric Block Attributes (element: qti-rubric-block)
| Name | Usage | Value(s) | Default |
|---|---|---|---|
| use | required | Vocabulary:
|
No default |
| view | required | Vocabulary:
|
No default |
The content within the qti-rubric-block should only be presented to the specified actors when the role of the actor is known. For example, in a testing session, a candidate would not have any content in the qti-rubric-block where the view="scorer" as the content is intended for the scorer, not the candidate.
In addition to the use and view attributes, QTI 3 introduces a limited set of shared classes which are used to clarify the presentation expectations for the rubric block. The classes include:
- qti-rubric-discretionary-placement : to indicate that the delivery/presentation system should provide the content to the intended view actors, but they are not necessarily placed inline with the content. The rubric block content can be displayed somewhere within the delivery platform's interface.
- qti-rubric-inline : to indicate that the delivery/presentation system should provide content to the intended view actors in the order they appear within the AssessmentItem file. For example, if a rubric block showing scoring information for scorer is placed after an interaction, the scoring information should be visually placed after the interaction is presented for any scorer.
The content of the rubric block is stored within the qti-content-body node, and contain the QTI 3 limited HTML set. It cannot contain any QTI interactions.
Rubric blocks can also optionally include a qti-catalog-info node to store catalogs that support the rubric block content.
An example of using multiple rubric blocks for different views and uses is shown below. Note that the use of the shared classes is optional, but included in the example to demonstrate good practice.
Rubric Block in an AssessmentItem
|
3.7.6 Printed Variable, MathML Variable, and Param Expansion.
Printed variable (qti-printed-variable) elements may be used to insert the values of template or outcome variables into test- and item-level content, such as within feedback, template, and rubric blocks, within most HTML5 elements, and within such interaction components as prompts and choices. This is useful in generating item content from templates, for customizing feedback and messages, and for similar use cases.
The formatattribute of the qti-printed-variable element can be used to control the formatting of the printed variable. Appendix A of Section 2 of this document gives a list of possible formatting options.
A delivery system which supports printed variables updates them in all content currently displayed to users immediately after response processing and outcome processing are completed. Similar to printed variables, the values of template variables with math-variable="true" are substituted into < mi> and < ci> elements within MathML blocks, and template variables with param-variable="true" are substituted into object param elements
3.7.8 Companion Materials
Companion materials are described within the <qti-companion-materials-info> node, and include assessment materials that are required to be available to test takers while answering a specific item. Materials may include interactive tools, like calculators or rulers. The specific materials tags, and their best practice usage are described below.
3.7.8.1 Calculators
All calculators would have access to all number digits, decimal key, equals button, and Clear button. Spoken (read aloud) capability should be something that is configurable to either allow, or not allow, during testing. Additionally, some programs allow for reading the numbers or functions as you use them, but do not allow reading the number as a whole. This is usually for Math-related content. The four possible calculators that can be specified are Basic, Standard, Scientific, and Graphing. Descriptions of each are included below.
Basic Calculator:In the <qti-calculator-type> tag, use the "Basic" vocabulary. The best practice assumed functions: Add, Subtract, Multiply, Divide.
Example usage:
|
Standard Calculator:In the <qti-calculator-type> tag, use the "Standard" vocabulary. The best practice assumed functions: all basic calculator functions, Square root (√), Percentage (%) , Plus/Minus (a.k.a. Sign Change), Memory Functions.
Scientific Calculator:In the <qti-calculator-type> tag, use the "Scientific" vocabulary. The functions may include, but are not limited to: ALL standard calculator functions, a p key, square ( x2) , cube (x3), x to the y (xy), cube root , xth root , logarithm keys, log, ln, base 10, base e,Trigonometry function keys with an INVERSE key for the inverse functions, sin, cos, tan, hsin (hyperbolic sin), hcos, (hyperbolic cos), htan (hyperbolic tan), DEG, RAD, GRAD conversion, a capacity to work in both degree and radian mode, a reciprocal key (1/ x) – calculate the inverse of the displayed value, permutation and/or combination keys ( nP r , nC r), parentheses keys, metric conversion, permutation and combination keys, nPr, cPr, x!
Graphing Calculator:In the <qti-calculator-type> tag, use the "Graphing" vocabulary. A Graphing calculator includes many of the same functions of a scientific calculator, plus the ability to display equations graphically.
3.7.8.2 Rule
Allows for the presentation of a measuring device for use on the computer with the supplied content. Use the qti-description tag for text description, as a human readable description of the functionality/capability of the rule. Provide the system of measurement using the rule system (which provides for choosing between metric (SI) and US measurement systems), then set the minimum length of the rule, the minor increment of the rule, and the major increment of the rule using the unit type (related to the rule measurement system).
Example usage:
|
3.7.8.3 Protractor
The test taker will be supplied with an on-screen protractor while responding to the item. A human readable description can be included in the description tag. Provide the measurement system using the increment tag, which lets you provide a value for either the metric (radians) or US (degrees) systems of angular measurement.
Example usage:
|
3.7.8.4 Digital Materials
These are content or reference materials that relate to the item content. The materials can include some level of interactivity, but no QTI interactions. Examples could be a map, a table of information, a sheet of math formulas, an interactive periodic table of elements, or even graphic creation tools. Use the <qti-digital-material> tag and provide a link to the material by use of the qti-file-href tag.
An optional label and icon representing the digital material's resource may be provided which the delivery system may use if it wants to provide a link to the resource, or a button to launch the resource.
A MIME type may also be provided (via the attribute mime-type) which may allow the delivery engine to optimize the delivery of the resource.
Example usage:
|
Digital Materials are intended to be presented to candidates during an assessment session. However, these materials are meant to assist, remind, guide, or in the case of a formative assessment, may even instruct the candidate. The candidate's interaction with these materials is not a requirement to responding to any assessment items, and no there are no scoring implications for the use of the materials by candidates.
The reference to the materials from within the item is often done to indicate that the particular reference materials are associated with the item, and that the candidate should have access to the materials while the assessment item is presented to the candidate. Because there is no indication as to how the materials are to be presented to candidates, the delivery system has discretion over the manner of presentation. Assessment programs often provide direction as to their expectations around the presentation of reference materials for candidates.
If candidates are required to access the materials to answer questions (like a reading passage), use the assessment stimulus structures (see Section 3.7.7 ) instead of digital materials. 3.7.8.5 Physical Materials
These are external materials needed to work with, or respond with, when the test taker responds to the item. Use the <qti-physical-material> tag, then describe the materials using text.
Example usage:
|
3.7.9 HTML5 Accessibility Structures
Within an QTI 3 item, content presented to candidates is largely authored using HTML in the itemBody, qti-catalog-info, and qti-modal-feedback nodes. Any prompts or interactions within the itemBody use QTI 3 specific elements, which are commonly converted to HTML elements at the time of delivery to the candidate. While authoring QTI 3 content, and transforming any markup code to delivery code, it is important to ensure that the content is presentable to as wide an audience as possible. In addition to making content more accessible to all candidates, using accepted web-delivery standards provides access to candidates using assistive technology (AT).
Many of the recommendations around the techniques that provide accessibility to candidates come from the World Wide Web Consortium's (W3C) Web Content Accessibility Guidelines (WCAG) 2.1. Implementers are encouraged to use WCAG to provide guidance on making their assessments accessible. The practices recommended below and throughout this document are certainly not definitive, exhaustive, or complete. However, using the native HTML structures will reduce the amount of special accessibility markup required for assessment delivery.
Using semantically-rich markup aids AT because the content structure and meaning can be programmatically determined. The WCAG 2.1 documentation defines "programmatically determined" as:
determined by software from author-supplied data provided in a way that different user agents, including assistive technologies, can extract and present this information to users in different modalities.
There are several HTML elements that are also useful for accessibility that can be used within an item, or an assessment interface. The elements: h1, h2, h3, h4, h5, h6, figure, main, nav, aside, ul (unordered list), ol (ordered list), table, footer, audio, video, p (paragraph) – all provide semantic meaning to the content within the element, and that meaning is used by assistive technology to be conveyed to the user, as well as providing navigational assistance. Implementers are encouraged to take advantage of native HTML elements to aid in providing meaningful, understandable content to candidates.
3.7.9.1 Use of Headings and Labels
By using descriptive headings and labels in assessment items (and assessment interfaces), the assessment experience for all candidates, including Assistive Technology (AT) users, is substantially improved. WCAG success criteria cover many of the aspects of using headings and labels in web content. The success criteria for headings and labels include:
- 2.4.6 Headings and Labels
- 2.4.10 Section Headings
- 3.2.4 Consistent Identification
- 3.3.2 Labels and Instructions
- 4.1.2 Name, Role, Value
In addition to headings providing useful descriptions of the content that follows, they can provide structure to the content and allow AT users to navigate through and around the content using keyboard shortcuts. This allows the AT users to skim, read, and focus their attention on the specific portions of the content that are important to them, without the need of rereading unimportant information, and freeing them from a content-linear user experience.
Heading levels should maintain their hierarchical order, as computer programs would assume that heading levels with lower numbers are not within heading sections with higher numbers.
Having labels for interactive components allows assistive technology users (particularly screen reader users) to understand the purpose of the interactive component, as well as identifying the current object why the computer device has in focus. The use of WAI-ARIA to provide state information (or for labelling custom created web components) is also extremely helpful for AT users, and is discussed in more detail in Section 2.4.1, as well as within many of the item examples (particularly the transformation to delivery examples).
3.7.9.2 Alt Text and Long Descriptions
Images (pictures, illustrations, graphs, charts, icons, etc.) intended to provide meaningful content (non-decorative images) should include a short description of the image. The length of the description can vary from a few words to a couple of sentences. If the description needs to exceed two or three sentences, or the description would benefit from text formatting (use of lists, data tables, mathematical notation, etc.), consider making a shorter description that identifies the image, then add a long description for the image.
For assessments, the amount of information, and the specific information provided, is particularly important. In some cases, over describing the image can be a hindrance to understanding the image, or may add unintended distractions for the candidate, so authors should include only the amount of information that is important to the task, and for which a sighted candidate might need to consider when responding to the item.
Decorative images should include the empty alt text string (alt=""), as this coding convention is used by AT to skip even mentioning the image in any way. In some cases, assessments (particularly for younger candidates) include images to increase the engagement of the assessment, though the image is not critical to answer the question. Authors will need to judge whether adding simple descriptions like "Picture of a duck" is useful for the candidate. In many cases, treating these engagement images as "decorative" may be appropriate.
If the image has a caption which is intended for all candidates (regardless of accessibility requirements), consider using the HTML5 <figure> element which allows for a caption by using the <figcaption> element. The <figure> element can also be useful when displaying a series of images together. When providing multiple images within a figure, the <figcaption> can be used to describe the grouping of images collectively. If you use a caption for an image, you should also include at least a short identifying description in the alt text for any images within the figure.
For more complicated images, the simple description provided in the alt text string may be inadequate to describe all the information within the image, and writing a long string of text describing the image can be difficult to navigate for AT users. In these cases, it is recommended that a long description of the image be provided for candidates who could benefit from them.
See Section 5.2.1.1 for additional information on alternative text, and Section 5.2.1.2 for examples of long descriptions.
3.7.9.3 Audio and Video Tracks
The QTI 3 standard allows the use of the HTML5 elements audio and video. These are useful not only because they provide semantic meaning for the media object, but because they allow the use of tracks, which are used to include alternative representations of the auditory and visual aspects of the media.
To provide captions for a video object, use the "captions" vocabulary in the "kind" attribute in the track element, as shown in the code snippet below:
|
The above example refers to a WebVTT file for the captions. Most browsers have media players that automatically display a Closed Caption (CC) icon in the controls bar if you supply a captions track, but check your particular delivery implementation to ensure that candidates can access the track. The media players then synchronize the captions information supplied in the WebVTT file with the video playback.
Some video files include the captions in the video file itself.
While you can provide multiple languages as subtitles for videos, this is typically not done for assessment content, as the captions provided are expected to be in the language of the assessment content, and if the content is also provided in a different language, that content is provided in a completely different Assessment Item (QTI 3 refers to these as item "variants").
There is a notable exception, where some assessments provide "stacked" translations, where the content switches back and forth between two languages by providing a chunk of content in one language (like a paragraph of text), then following that chunk with the second language translation. For stacked translated content, it would make sense to include multiple languages, as well as providing the language in the "srclang" attribute using ISO 639 notation, as well as using the "label" attribute of the track (label="English") to identify the captions for the different language versions. Typically, those language labels appear in a list when the user selects the Closed Caption (CC) icon.
QTI 3 allows for the Media Fragments URI 1.0 notation (l ink to W3C documentation ) as recommended by the W3C as of 25 September, 2012. For example, if you wanted to play only the first 20 seconds of a video file, you add the media fragment notation to the end of the src URI, as shown in the example below:
|
3.7.10 PNP Activated Content and the Use of Catalogs for Resource Storage
Within an QTI 3 Item, you can provide support-specific content through the use of catalog resources. Catalog content in a QTI 3 Item is considered "dormant" because it is only presented to candidates if their PNP information or their program's business rules indicate that the delivery system should provide them with the support-specific content within the catalog.
It should be noted that general accessibility information should NOT be supplied within catalogs, but rather should be included as content readily available to all users using accepted web-based accessibility markup practices. General accessibility information would include things like alt text for images, captions for videos with audio, roles for sections of content, headings, labels, and text descriptions for non-text content.
An item can contain none, one, or many catalogs, all contained within the qti-catalog-info node within an AssessmentItem file, inserted after the qti-item-body content.
A single catalog can contain one or many supports, which are enumerated using "cards" within the qti-catalog node. The "support" attribute of the card describes which support is contained within the card. Each catalog must only contain one of any of the particular supports. For example, you cannot have a catalog with 2 cards with a support="additional-directions". If the support is intended to match the predefined supports (see Section 3.8.10.1) of the AfA 3.0 PNP, the support name in the support attribute will exactly match the support name of the PNP. If the support is not intended to match the predefined supports, then the support name is considered "custom" and should follow the custom support conventions (see Section 3.8.10.3).
If you need to further differentiate between candidates based on their PNP needs and preferences, cards can contain one or more qti-card-entry nodes, where the specific differentiated metadata is provided as an attribute for each qti-card-entry. A common differentiating characteristic is the language of the content for each qti-card-entry.
A qti-card or qti-card-entry may contain a single qti-html-content node, or any number of qti-file-href nodes, which reference files outside the item instance. A qti-card or qti-card-entry must contain at least some content: either qti-html-content or a qti-file-href reference.
The qti-html-content node can contain any of the QTI 3 permitted HTML elements, or plain text. The qti-html-content node cannot contain any QTI 3-specific elements, including any interactions.
The qti-file-href nodes reference one or more external files that are intended to be delivered for the specific support as listed in the support attribute for the card or card-entry. When referencing multiple files intended to provide the same support, use the mime-type attribute to differentiate between the file types, where the delivery system determines which file type is most appropriate to deliver in any specific context. The multiplicity of files is not intended to provide files for different user-based needs or preferences (as derived from the candidate's PNP). If different content is needed for user-based needs, the differences should be expressed in the attributes of a multiplicity of card-entry instances for that support.
However the content with the qti-card or qti-card-entry is provided, the delivery expectation is that the content for any specific support should only be provided when requested. A request can come from either a candidate's needs and preferences (their PNP), or from an administrative request for all or some portion of the candidate pool; e.g., a testing program could decide that ALL candidates should receive the glossary-on-screen support, regardless of any specific requests from a candidate's PNP. If no request for any particular support-specific content is made, that content should remain dormant; i.e., not presented to the candidate.
3.7.10.1 The Predefined AfA 3.0 Supports Permitted in QTI 3 Item Content
The QTI 3 profile of AfA 3.0 is a subset of the full set of supports that are defined in AfA 3.0. Additionally, only certain supports of the QTI 3 profile are allowed in the support attribute of cards, hereafter referred to as the predefined supports. For many of the supports it is not necessary to provide additional or alternative content in order to provide a candidate with the support. Examples include supports like breaks for candidates during testing, or providing a computer linereader tool. The presentation/delivery system can provide these supports without the need of authored information within the item. These supports are therefore not needed in the context of authored content.
The predefined supports can be named in the support attribute without the use of custom support extension. The 1EdTech QTI 3 validator will check and allow the use of the predefined supports.
The full list of predefined supports that can be authored in assessment content includes:
- additional-directions
- audio-description
- braille
- glossary-on-screen
- high-contrast
- keyboard-directions
- keyword-translation
- linguistic-guidance
- long-description
- sign-language
- simplified-language-portions
- simplified-graphics
- spoken
- tactile
- transcript
3.7.10.2 How to Reference Catalog Content
Catalogs can be referenced from the qti-item-body element, from any element within the qti-item-body node, and within any element within a qti qti-catalog → qti-card → qti-html-content node.
A reference is made to the catalog using the attribute "data-catalog-idref" from within an element in the qti-item-body - or on the qti-item-body element itself - where the value of the attribute is the id of the catalog you are referencing. A catalog MUST contain a unique id in the qti-catalog element's start tag. In the simple item example below, notice the reference (data-catalog-idref="catalog1") to the qti-catalog on line 0005, where the data-catalog-idref value matches the id in the qti-catalog element found on line 0009.
Note that the catalog is placed within the qti-catalog-info node (starting on line 0009), and the qti-card supports the "linguistic-guidance" feature (line 0010), as described within the support attribute of the qti-card.
Example: Referencing Catalog Content
|
A catalog can be referenced from more than one originating source. For example, if there is additional content in the above example that also used the word "accurate", you would point to the same catalog from all the instances of the word accurate within the text.
Catalogs can contain more than one support, as shown in the slightly more complex example below, where the catalog has support for both keyword-translation and linguistic guidance.
The example also shows how a support with other user-based needs (as provided in the candidate's PNP) uses multiple qti-card-entry nodes where the attributes differentiate between which content is to be presented to the candidate. In this example, the keyword-translations are provided in multiple languages (the languages are specified as ISO 639-1 language codes), and the expectation is only the language requested by the candidate in their PNP will be presented to them.
Example: Catalog with Multiple Supports
|
While an item may not contain any catalogs, it might also contain multiple catalogs that support any number of pieces of content within the item. In the example below, the sign-language support uses two different catalogs to allow the stem and the response options to have their own associations to portions of the sign language video file.
Example: Multiple Catalogs within a Single Item
|
In addition to the primary qti-catalog-info node of an assessment item, catalog content can be placed within the various structures that go inside assessment items (i.e., rubric blocks, feedback structures, template structures).
As a best practice, the scope of the catalog should be limited to the container that holds (or could hold) a qti-catalog-info node. For example, a rubric block within an assessment item's qti-item-body node should reference catalogs within that rubric block. It should not jump out of the rubric block and reference catalogs from the item's primary qti-catalog-info node or other rubric blocks. Conversely, item content outside the rubric block should never access catalogs inside the rubric block's qti-catalog-info node. An example of the proper referencing is shown below.
Example: Catalogs across content nodes
|
For interoperability purposes, catalog ids within assessment content files (items, sections, stimulus, parts/tests) MUST be unique. Be aware that there may be referenced/included/nested content (like a shared stimulus or rubric blocks) that may also include catalogs and could be on the same delivery presentation screen for candidates. It is the expectation that Authoring systems ensure there are no catalog naming conflicts across structures when exported.
3.7.10.3 Custom Supports
Cards within a catalog can also contain custom content – content for supports other than the predefined supports allowed in QTI 3 (see Section 3.7.10.1 for the list).
To include your custom content, use the prefix "ext:" in the name of the support attribute on the card. As a best practice, your custom name should include the name of the organization implementing the custom support, in order to avoid namespace collisions with other organizations that may create similar custom supports. In the example below, the fictional organization "KXZ Testing" will include "kxztesting" in the custom support name (line 0012), which follows the lowercase & hyphen naming convention used throughout QTI 3 and AfA 3.0. The 1EdTech QTI 3 validator will allow any alphabetical characters (a-z, A-Z, 0-9) (plus dash and underscore) following the extension prefix. It will not check for any spelling consistencies for custom-created support names.
Example: Labelling Custom Support Content
|
If the custom support is intended to be delivered for specific candidates based on their PNP information, the PNP should also use the AfA 3.0 extension mechanism, using the same name of the custom support used in the content. (See Section 5.4)
3.7.11 Context Declarations
When evaluating Template Processing and Response Processing instructions in an Assessment Item, having contextual information available in the information model can improve the effectiveness and efficiency of such Template Processing and Response Processing instructions. For example, Template Processing and Response Processing instructions with easy access to a candidate's PNP "context" can yield richer, more effective, presentation and outcomes. In another example, enabling an evaluation system to pass system or environmental "context" into an Assessment Item – or an Assessment Test – using common information model conventions can add richness to item evaluation and improve interoperability.
The built-in QTI_CONTEXT record variable can be visualized with the following qti-field-identifier structure when declared in a QTI3 Assessment Item:
The key elements to qti-context-declaration are:
- A variable declaration which declares a variable with global scope. Such a globally scoped variable can be accessed within <qti-template-processing>, <qti-response-processing>, and <qti-outcome-processing> instructions. This approach uses the element qti-context-declaration.
A <qti-context-declaration> has all of the typical attributes; e.g., cardinality, identifier, and base-type.
- A built-in <qti-context-declaration> for a variable named "QTI_CONTEXT", with cardinality of record. The following is an explicit (though unnecessary) <qti-context-declaration> of QTI_CONTEXT:
<qti-context-declaration cardinality="record" identifier="QTI_CONTEXT" />
"QTI_CONTEXT" is the name used in order to avoid collisions with other variables that might already be declared in existing items.
- Systems that support context declarations are required to support three field definitions within the QTI_CONTEXT record:
- candidateIdentifier: a string used to map to a candidate object. A practical application of this would be to encode a user or session ID which could then be used as the key to additional user/candidate information
- testIdentifier: a string used to map to a test object. A practical application of this would be to encode an <qti-assessment-test> identifier which could then be used as the key to additional "test" contextual information.
- environmentIdentifier: a string used to map to an environment runtime in which template processing or response processing is being evaluated. A practical application of this would be to encode a "program" identifier which could then be used as the key to additional system-level properties.
|
A system supporting context declarations must implement the candidateIdentifier, testIdentifier, and environmentIdentifier fields of the QTI_CONTEXT record.
Note: A common expected usage of QTI_CONTEXT is to enable more interoperable methods of retrieving a candidate's PNP information. For example, PNP information can be located by using the candidateIdentifier field as a key, alone, or in conjunction with the testIdentifier field.
In the next example, different programs use one item to capture and evaluate essays. However, each program has chosen to implement different partial scoring ratios. An environmentIdentifier is passed into an item using the QTI_CONTEXT environmentIdentifier field (lines 39–41). This value (either "1" or "2" in this example) is then used with a <qti-match-table> (lines 12–15) to find the partial scaling factor for a program.
|
3.7.12 Portable Custom Interactions (PCIs)
As discussed in Section 3.2.22b , PCIs can be used to build interoperable interactions with custom user interface and behaviour.
The functionality of a PCI is implemented by an AMD module written in Javascript, which may load any other AMD modules upon which it depends.
PCIs are introduced into an item by the use of a qti-portable-custom-interaction element. As with the predefined interaction types, PCIs are bound to a response variable via the response-identifier attribute.
As two different qti-portable-custom-interaction elements could represent two very different custom interaction types, a PCI MUST have an attribute (custom-interaction-type-identifier) to identify the actual interaction type represented by this PCI. To prevent name collisions between the values used by different implementers it is RECOMMENDED that a Federated Content URN [rfc4198] be used for the value of the custom-interaction-type-identifier attribute.
Any custom attributes provided by the item author through the use of data- attributes on the qti-portable-custom-interaction element MUST be passed as properties by the delivery engine to the PCI module on initialization.
The item author MAY pass the values of template variables defined in the item to the PCI module via qti-template-variable child elements.
The item author MAY pass HTML markup to the PCI module to customize the user interface of the PCI via a qti-interaction-markup child element. It is the responsibility of the PCI module to decide what use (if any) it will make of this markup. The markup allowed would be similar to that allowed by a qti-rubric-block, so it could for example include qti-printed-variable or inline feedback elements. One difference with qti-rubric-block is that the qti-interaction-markup element MAY contain a templateelement which in turn may contain any HTML5 markup.
3.7.13 PCI AMD Default Module Resolution
As the delivery engine must dynamically load the AMD module which implements the PCI module and any AMD module that it depends on, it needs to know how to resolve references to AMD module names to loadable Javascript files.
PCI supports loading AMD modules from global URLs (e.g. CDN (content delivery network) hosted Javascript files) and also from QTI content package relative files. As a QTI content package may be deployed in more than one context (e.g. it may be used in a normal web browser with access to external CDN hosted files or it may be used in a high stakes secure browser context where access is permitted only to files included in the QTI content package) PCI allows both a primary location (typically used to reference CDN hosted files) and a fallback location (typically referencing content package provided files) to be used when specifying AMD module locations.
The first mechanism supported for AMD module resolution is to provide a module resolution configuration file called "module_resolution.js" in the QTI content package which defines the item in a directory called "modules".
This file defines the primary location of each named AMD module.
This MUST be supported by delivery engines. While it is expected that this will be the most common way to resolve the AMD modules used by PCIs its use by content authors and QTI content packages is RECOMMENDED, but not mandatory.
3.7.14 PCI AMD Module Resolution File Format
This config file is a JSON document like the following example:
{
"waitSeconds": 15, "paths": {
"module1": "https://example.com/js/modules/graph1.01/graph",
"module2": "https://foobar.com/foo/bar1.2/foo" }}
The "waitSeconds" property defines how long the delivery engine should wait for each Javascript file to load before timing out. A setting of 0 indicates that no timeout should be used (however this may prevent a fallback configuration from being used). If "waitSeconds" is not specified then a default of 7 seconds should be assumed.
The paths object provides a collection of AMD module name to URL mappings. The path supplied should not contain a file extension.
If the location starts with a protocol (e.g. https://) then the module should be fetched from that location. Otherwise it should be assumed to be a QTI content package relative path.
A delivery engine MAY ignore any package relative locations which are not defined in the manifest of the QTI content package.
A delivery engine MAY apply security rules to the URLs from which it will load Javascript files.
In the example above if an AMD require call was made for "module1" the delivery engine would first read the module resolution configuration from "<content package base href>/modules/module_resolution.js" and then load the Javascript for the module from https://example.com/js/modules/graph1.01/graph.js
3.7.15 PCI AMD Default Fallback Module Resolution
The second module resolution mechanism is to provide a module resolution configuration file called "fallback_module_resolution.js" in the QTI content package which defines the item in a directory called "modules".
This MUST be supported by delivery engines, but its use in QTI content packages is optional. For any modules where the primary location is not a package relative path it is RECOMMENDED that a fallback location is configured which uses a package relative path.
The file format and processing rules are the same as defined in section 3.7.12.2 above, but the locations provided are those to be used if a timeout or a fatal error (such as a 403 error) is encountered when attempting to load the module from the primary location.
3.7.16 Associating a PCI module to the interaction
To associate a PCI module with a qti-portable-custom-interaction (PCI), either the "module" attribute or a qti-interaction-modules element MUST be present. The value of the "module" attribute (or the qti-interaction-modules element) MUST be the name of an AMD module defined in the module resolution configuration.
If we take the example of a simple PCI which implements a custom Likert Scale interaction where the QTI content package included a module resolution configuration in "modules/module_resolution.js" with the contents: {
"paths": {
"exampleLikertScale": "modules/likert",
"handlebars": "modules/lib/handlebars.min" }}
Then the item author can use:
|
When this item is rendered by the delivery engine it will read the "module" attribute's value ("exampleLikertScale") and after looking this module name up in "modules/module_resolution.js" will attempt to dynamically load "modules/likert.js" from the QTI content package. If the AMD module in likert.js required a module called "handlebars", then the location for that will be resolved in the same way and the delivery engine will attempt to dynamically load "modules/lib/handlebars.min.js" from the QTI content package.
The item author MAY also override the default location for the primary resolution config files by adding a qti-interaction-modules child element with a "primary-configuration" attribute to set the location for the primary module resolution configuration and MAY set the fallback module resolution configuration location by setting a "fallback-configuration" attribute. This MUST be supported by the delivery engine, however the delivery engine MAY refuse to load relative paths which are not defined in the content package's manifest, and MAY apply security rules to the URLs it will load Javascript from.
The item author MAY further customize the module loading for an interaction by specifying the primary and fallback locations to use for an individual module by adding one or more qti-interaction-module child elements to the qti-interaction-modules element. This MUST be supported by the delivery engine.
For example, there may be no default module resolution configuration files in the content package, but there may be a module resolution file called e.g. modules/maths_config.js with the contents: { "waitSeconds": 10, "paths": { "exampleLikertScale": "modules/likert", "exampleGraphing": "modules/graphing", "handlebars": "modules/lib/handlebarsv101.min" }}
Assuming that both PCI modules require a module called "handlebars" but require different versions of the handlebars module, the item author may wish to override the module version in the item definition, e.g.
|
3.7.17 Example PCI lifecycle
Depending on the item definition, on the set of features implemented by the delivery engine, and on the portable custom interaction, there are many possible PCI lifecycles.
The first example flow is of a non-adaptive, non-composite item containing a portable custom interaction. Here the candidate navigates away from the item while it is unsubmitted, and then later returns to complete the item and submit it. The delivery engine stores the state of the item it retrieves from the PCI object in the item session and when the candidate returns to the item it passes that stored state back to the custom interaction instance.
In this second example a more complex flow is shown where a candidate may interact with an adaptive composite item which may contain more than one portable custom interaction and a qti-end-attempt-interaction across multiple attempts where the candidate uses the endAttemptInteraction to end each attempt and a button in the delivery engine to ‘submit' the item, the item response processing then closes the item.
3.7.18 PCI API
Any Javascript loaded as part of or to support a PCI MUST be written to run inside a strict Javascript execution context (e.g. it must expect that the delivery engine has called "use strict" before any of its modules are loaded) [STRICT]. It is recommended that all PCI modules also call "use strict".
3.7.19 PCI Communication Bridge Methods
The delivery engine supports portable custom interactions by injecting a Javascript object which supports the PCI Communication Bridge contract into the loaded PCI module via AMD. This object allows PCIs to register themselves and exchange state and configuration settings with the delivery engine. The delivery engine will provide this via a standard AMD definition of 'qtiCustomInteractionContext' which the portable custom interaction can require in its AMD module.As an alternate method of discovering the qtiCustomInteractionContext object, the delivery engine MUST also assign it to the global window object before the PCI is loaded.
When a delivery engine is rendering an item which contains one or more portable custom interaction instances, it needs a way to obtain the factory interface needed to create new PCI objects to implement the portable custom interaction instances in the item. The key which links the two is that each qti-portable-custom-interaction element has a custom-interaction-type-identifier attribute which is a string that uniquely identifies the factory that will be used to create PCI objects of the type needed by that qti-portable-custom-interaction instance. That instance also identifies the module(s) which are required to be loaded for that PCI.
As these modules are loaded they must ensure that one will call the registermethod of the bridge object to register the factory for that PCI with the Communication Bridge under a key which is the typeIdentifier of the PCI module.
The delivery engine can then later call the getInstance method of the Communication bridge to cause it to render itself to the DOM element passed in the call. The delivery engine will also pass the value of the custom-interaction-type-identifier attribute of the qti-portable-custom-interaction it is rendering as the first parameter of the call, and the Communication Bridge will then look up the factory the PCI registered with that typeIdentifier and then call getInstance on that factory, proxying on the other parameters provided. The getInstance call returns a reference to the object thus created.
The qti-interaction-markup element of the PCI may contain HTML which in turn may contain QTI elements such as qti-variable etc. It is the responsibility of the delivery engine to resolve those elements. As this HTML is passed to the PCI when getInstance is called, the PCI can then choose to modify that HTML as it sees fit. Consequently, the delivery engine should resolve these elements before generating the HTML in the DOM element passed to the PCI, and whenever the rendering of that HTML might change; e.g., after response or outcome processing where response and outcome variables used in that HTML might change, the delivery engine should update the HTML and call getInstance on the PCI again to pass it the updated HTML.
The register method will be called once per PCI type, in each AMD loading context where the PCI module is loaded. How an implementation defines AMD loading contexts is beyond the scope of this document. For example, there may be only one loading context for an entire assessment, or loading contexts for each item, or for each portable custom interaction instance, depending on the implementation.
If a delivery engine supports composite interactions the qtiCustomInteractionContext getInstance method may be called multiple times to construct more than one PCI in the Assessment Item.
Before unloading a PCI, if the PCI object provides an oncompleted callback function the delivery engine MUST call it to allow the PCI to release any global resources it allocated (e.g. global event listeners).
| PCI Communication Bridge (qtiCustomInteractionContext) Required Methods | |||
|---|---|---|---|
| register(customInteraction) After the PCI module loads it uses this method to register its customInteraction factory object which provides a factory method used to create PCI instances |
|||
| getInstance(typeIdentifier, dom, configuration, state) | The typeIdentifier argument should be the value of the typeIdentifier property of the customInteraction factory object passed in a previous call to the registermethod. It should also match the value of the custom-interaction-type-identifieron the qti-portable-custom-interaction element.The other arguments of this call are the same as the arguments of the getInstancemethod of the registered custom interaction for the PCI and are documented in the next section.Returns the object created. | ||
3.7.19.1 PCI API - PCI Module Factory
| PCI Communication Bridge - PCI Factory | |||
|---|---|---|---|
| getInstance(dom, configuration, state) This is the registered PCI module factory method for constructing a new instance of the custom interaction with the supplied configuration and state. The domparameter is required. It is a reference to the DOM element where the delivery engine has transformed and injected the qti-interaction-markup child of the qti-portable-custom-interaction into the HTML DOM. The state parameter is optional. It can be passed to recreate a previous interaction state of the item. The value of state, if provided, should have been previously returned by the same interaction type. It returns the object created. The object passed as the required configurationparameter should contain the following properties: |
|||
| properties | An object containing all of the key/value pairs from the data- attributes set on the qti-portable-custom-interaction.The naming rules applied by HTML5 for element.dataset should be followed here. For example, the data- is removed and hyphenated names have the hyphens stripped and are camelCased. Also, data-max-choices-message="Too Many" would become properties: { maxChoicesMessage: "Too Many" } | ||
| templateVariables | An object containing all of the template variables referenced (via qti-template-variable elements) in the qti-portable-custom-interaction and their current values.The values of variables MUST follow the structure defined in Appendix C. | ||
| contextVariables | An object containing all of the context variables referenced (via qti-context-variable elements) in the qti-portable-custom-interaction and their current values. The values of variables MUST follow the structure defined in Appendix C. | ||
| boundTo | The value of the response variable of this qti-portable-custom-interaction.The values of variables MUST follow the structure defined in Appendix C | ||
| responseIdentifier | The interaction's response identifier; e.g., "RESPONSE". Useful for logging and events. This should not be relied on to be unique for the web-page the interaction is rendered on ( e.g. multiple items may be rendered on the same web page). | ||
| onready | Callback method for the PCI instance to call when it is fully constructed and ready for interaction.The signature of this callback function is documented in the next Section. | ||
| ondone | OPTIONAL. Callback method which MAY be called by the PCI module if the candidate indicates that they have finished interacting with the item; e.g., by clicking on a button rendered by the PCI. The custom interaction can identify that the item state should change; e.g. the attempt should be ended, or that a model solution be shown to the candidate.The signature of this callback function is documented in the next Section. | ||
| status | OPTIONAL. Specify the item status (as per Section 4.1 of the QTI 3 Information Model). If not specified it should default to "interacting". The values of status which may be passed to a PCI are:
|
||
3.7.19.2 PCI Communication Bridge API - Delivery Engine Callbacks
When the delivery calls getInstance, the configurationobject contains one required and one optional callback, onreadyand ondone, respectively. The PCI instance is responsible for calling these callback functions on the events described below.
These two callbacks are defined below:
| onready | ||
|---|---|---|
| This callback MUST be called by the custom interaction instance once it has finished initialization and is ready for the candidate to interact with. When onready is called, the following two parameters below MUST be provided. |
||
| interaction | The custom interaction instance (as created by a call to getInstance) | |
| state | The current internal state of the custom interaction instance. This should be treated as an opaque string by the delivery engine. It can be passed back by the delivery engine in a getInstance call to recreate the PCI in the same state. | |
| ondone | ||
|---|---|---|
| This callback MAY be called by the custom interaction instance if the candidate indicates that they have finished interacting with the item (e.g. by clicking on a button rendered by the PCI). For example, it might be used to request that the item be closed, or that the item transition to "solution" state. When ondone is called, the first three parameters below MUST be provided. |
||
| interaction | The custom interaction instance (as created by a call to getInstance) | |
| response | The response variable to which this qti-portable-custom-interaction is bound and its value. The values of variables MUST follow the structure defined in Appendix C. | |
| state | The current internal state of the custom interaction instance. This should be treated as an opaque string by the delivery engine. It can be passed back by the delivery engine to the PCI module in a getInstance call to recreate the PCI in the same state. |
|
| status | OPTIONAL. Requests that the delivery engine transition the item to the specified state. If not specified, it should default to "interacting". For example, if a value of "closed" is provided that would indicate that the item state should be set as closed, which would also end the attempt. The delivery engine is not required to transition the item state as requested. The values of status that a delivery engine should expect a PCI to send are:
|
|
3.7.19.3 PCI API - PCI Object
The PCI module getInstancefactory method returns an instance of the portable custom interaction. Each instance will correspond to one occurrence of qti-portable-custom-interaction in an assessment item. PCI objects have the following properties and methods.
| PCI Instance | |
|---|---|
| getResponse() This method may be called zero or more times. The type of the response data must correspond with the base-type and cardinality defined in the QTI response declaration of the response variable the qti-portable-custom-interaction is bound to (via the response-identifier attribute). The value returned must follow the format defined in Appendix C. If the user has not yet interacted with the interaction, or if the response is not valid for any reason, then getResponse should return undefined. |
|
| getState() This method can be used to retrieve the current state of the custom interaction instance. This can be later used to re-initialize the PCI to that state. This may, for example, be used by delivery engines when a student navigates away from the current item to another item and later returns to resume their interaction with the item. This should be treated as an opaque string by the delivery engine. |
|
| oncompletedOPTIONAL. The custom object instance MAY implement an oncompleted callback function. If a function has been assigned to the oncompleted property of the PCI object, then this callback function MUST be called by the delivery engine before unloading the PCI module, or before removing markup associated with the PCI from the DOM. | |
| typeIdentifier This should have the same value as the custom-interaction-type-identifier attribute in the qti-portable-custom-interaction element. |
|
| checkValidity() OPTIONAL. Check whether the candidate's interaction with the PCI satisfies any validity constraints defined for this PCI instance; i.e., is the interaction's response valid? If the validity constraints are not met, the PCI MUST fire a cancelable invalid event at elements containing invalid input, and then return false. If the validity constraints are met, the PCI MUST return true. If this PCI has no validity constraints, or the PCI can not yet validate the candidate's input, the PCI MUST return undefined. |
|
| reportValidity() OPTIONAL. Behave exactly as checkValidity(), except if false is returned the PCI SHOULD also report validation problems identified to the candidate. |
|
| setCustomValidity() OPTIONAL. Set the custom validity message for the PCI to the specified message. Use the empty string to indicate that the element does not have a custom validity error. |
|
| getCustomValidity() OPTIONAL. Return the custom validity message for the PCI. Use the empty string to indicate that the element does not have a custom validity error. |
The custom interaction instance is responsible for calling the callback functions set by the delivery engine in the getInstance call via the onready and/or ondone properties of the configuration. See Section 3.7.12.9 for the expected signature of these functions, and for information on when in the interaction life cycle the custom interaction instance should call these callback functions.
3.7.19.4 PCI Communication Bridge API - PCI callback
The custom interaction instance returned by the PCI module MAY implement an "oncompleted" callback which MUST be called by the delivery engine before unloading the PCI module or removing markup associated with the PCI from the DOM.
| oncompleted() | |
|---|---|
| oncompletedhas no parameters. If provided, this callback MUST be called by the delivery engine before unloading the PCI module or removing markup associated with the PCI from the DOM. This is to allow the custom interaction instance to release any allocated resources; e.g., unbind global event listeners etc., or remove markup, which might not be deallocated or removed automatically by removing the DOM element associated with the PCI. Typically, the delivery engine will call getResponseand getStatebefore calling oncompleted. |
3.7.19.5 Notifying Changes to the Delivery Engine
When the value of a PCI changes (e.g. the value which would be returned by getResponse() changes) a PCI MUST send a qti-interaction-changed event by firing a custom event to the DOM element passed to getInstance. The PCI can determine when it considers the response value to have changed. For example, a PCI does not have to send a qti-interaction-changed event on every keypress or mouse click - unless of course the designer of the PCI explicitly , it does not have to e.g. send an event on every keypress. When sent, the custom event MUST be set to bubble and be cancellable. The custom event MUST be initialized with the following data ( which will appear as a 'detail' object on the event ).
| qti-interaction-changed | |||
|---|---|---|---|
| interaction | The PCI object MUST provide itself. It is recommended that the bridge/delivery engine always use this value to resolve which qti-portable-custom-interaction the change relates to. | ||
| responseIdentifier | The PCI MUST provide the value of responseIdentifier provided in the getInstance call. This value should not be relied on to be a unique identifier on the web page. | ||
| valid | The PCI SHOULD provide a boolean which provides the value that a call to checkValidity() would return; i.e., whether or not the PCI's response meets the PCI's validity constraints. | ||
| value | The PCI SHOULD provide the value that a call to getResponse() would return. | ||
3.7.19.6 Configuration of a PCI
Configuration of portable custom interactions may utilize data- attributes of the qti-portable-custom-interaction. The configuration data is passed to the PCI module via a call to getInstance.
QTI template variables may also be utilized to provide configuration data to custom interactions by template variable binding. The delivery system must read the mapping and provide configuration data before interaction initialization. QTI template variables are transcribed into JSON data by the delivery system using the JSON binding defined in Appendix C.
PCI module developers should consider that a PCI module may be used in a composite item when deciding how to bind template variables to a PCI as template variables are defined at the level of the item. For template variables which the PCI module expects to be given a unique value for each interaction in the item the PCI module author should consider approaches to providing the item author flexibility over how the template variables can be named so that they can be unique to the instance but still recognized by the PCI module.
Some techniques which the PCI module author might consider applying are
- Allowing a suffix to be applied to the template variable name; e.g., where a template variable is used to provide a range on a number line and which will be mapped to an internal variable called rangethen any template variable starting with ‘range'which the item author has bound to the PCI instance via a qti-template-variable element would be mapped to the internal variable ‘range',so the item author could use any of the following template variable names, range, rangeOne, rangeTwo, rangeline1.
- Allow a suffix to be applied as above but require the item author to provide the value of the suffix as a documented data attribute on the qti-portable-custom-interaction element; e.g.,using data-instance-id=" One" might then cause the PCI module to expect the template variable to be named " rangeOne". This suffix might apply to multiple template variables used by the PCI module.
- Allow the item author to override a default expectation for the template variable name via a data attribute on the qti-portable-custom-interaction element; e.g., data-range-variable-name=" rangeOne" would cause the PCI Module to map a template variable called " rangeOne" rather than defaulting to mapping a template variable called " range" to an internal variable " range".
Where the values of the template variables are not expected to be unique to an instance, PCI module authors should consider selecting template variables which are not likely to be the same as the names required by other PCI modules which might be used in the same item, e.g. by using a vendor prefix.
The JSON data is passed into the custom interaction object on creation via the getInstance method. The example item in Section 3.8.2 below binds two template variables (X and Y) to this interaction, so that the value of these two variables will be passed by the delivery engine into the configuration in the templateVariables property when the custom interaction object is created.
3.8 Annotated Item Examples
3.8.1 Example 1 - Implementing Shared Vocabulary, ARIA, and Catalogs with Glossary and Keyword Translation
This example demonstrates a variety of techniques involving QTI3 shared CSS vocabulary, shared interaction vocabulary, use of aria for users of assistive technology, and Catalogs for encoding glossaries, keyword translations, and computer read aloud.
|
|
|
|
3.8.1.3 Use of WAI-ARIA
The item's author also endeavored to make this item a fairer geometry measurement for both sighted candidates and for candidates with visual impairments who use certain forms of assistive technology (AT) such as screen readers. This was accomplished by adorning various parts of the item's content with aria.
On lines 18 and 19, the image uses an "alt" attribute to tell AT that the image is indeed the "survey map" to be examined, but goes further by linking the detailed description of the image with an "aria-describedby" attribute. By using so-called "down-arrow" navigation, a candidate can easily manipulate the screen reader to scan the content linked by the id of the element specified by the value of the describedby - in this case "imgdesc1"on line 21.
Furthermore, as is common with mathematics, aria is used in several places of the describedby element to get the AT to properly voice the mathematical symbols (lines 22, 24-25, 28-31).
In order to properly voice the math on lines 42-44, the author also specifies an "alttext" attribute on the MathML. Delivery systems MUST convert MathML alttext attributes to aria-label attributes. Otherwise, most AT will not properly voice the math.
3.8.1.4 Use of Catalogs (Glossary, Keyword Translation, and Computer-Read-Aloud)
In this item, the author uses catalogs for three different purposes: Glossary, Keyword Translations, and Computer-Read-Aloud.On line 16, the word "Examine" is wrapped in a span element with data-catalog-idref="cat01", which links the contents of the span ("Examine") with the qti-catalog id="cat01" on line 58.
On lines 59-63, there is a qti-card element with support="glossary-on-screen", and containing a glossary definition for the word "Examine".On line 65, there is a qti-card element with support="keyword-translation", which typically contains a list of qti-card-entry's, each of which contains an ISO 639 language reference. In this item's case, the author only encodes a translation for Spanish (ISO 639-1 "es") on lines 65-69.
As mentioned previously, there exists a qti-visually-hidden detailed description of the survey diagram on lines 21-33. To prevent the delivery system's computer-read-aloud technology (which is primarily used as a literacy support) from voicing the description of the diagram that is provided to AT users, a catalog (data-catalog-idref="cat02") is linked on line 21. Then, on lines 73-78, there is a catalog override for what the delivery system's computer-read-aloud technology should voice, which, in this case, should be nothing because we don't want to create a literacy aid to content that we can't see! Consequently, there exists what amounts to empty white space for this qti-card-entry (lines 74-77). This effectively "hides" the visually-hidden content from the delivery system's computer-read-aloud technology while still retaining content visibility for assistive technology.
3.8.2 Example 2 - Implementing a PCI
In formative assessment, it can be useful to provide rapid feedback to the student when they are testing their own comprehension of a topic. A useful interaction type to support this is a Tap To Reveal/Click to Reveal interaction, where a prompt is displayed with one or more images displayed which are initially masked and revealed when the student clicks on them. There is no built-in interaction in QTI for this. And while this result could be achieved in QTI using an adaptive item with custom response processing and feedback blocks, this approach is quite cumbersome to author.
However, this is quite easy to implement as a portable custom interaction.