Assessments, SCORM and HTML5 packages, embeds, third-party tools, and custom code can introduce accessibility considerations that are different from standard course content.
These experiences may include interactive controls, external interfaces, custom behavior, or content created outside LearnWorlds. Their accessibility can depend on how the activity is configured, how the external content was created, and how the interaction behaves for keyboard and assistive technology use.
Use this guide to review these experiences before making them available to learners.
Review assessments and interactive activities
Assessments should make the question, available options, required action, and resulting feedback clear.
When creating or reviewing an assessment, check that:
- Questions and answer options are clear and concise
- Instructions appear before learners need to take an action
- Similar question types behave consistently
- Important information does not rely only on color, position, shape, or other visual cues
- Images, video, and audio provide appropriate alternatives where needed
- Errors explain what needs to be corrected
- Feedback is clearly associated with the relevant question or action
- Timing settings are appropriate for the learning objective
- Important controls can be reached and operated using a keyboard
Write clear questions and instructions
Instructions should describe the action learners need to take without relying only on visual appearance.
For example:
- Instead of, Select the items shown in green, use: Select all items marked as Approved. Approved items are also shown in green.
Avoid instructions such as Select the option on the right, Click the red answer, or Press the icon below, when the same instruction can refer to the name or purpose of the control.
If an activity uses an unfamiliar interaction, explain how it works before the learner begins.
Make assessment media accessible
Images, video, and audio used in an assessment may contain information needed to answer a question.
Check that meaningful images include an appropriate text alternative where supported. Video should provide captions or subtitles where appropriate, while audio should provide a transcript or equivalent text alternative when needed.
Important visual information in a video should also be communicated through speech or another accessible format.
For more guidance, see this guide..
Make feedback and errors clear
Learners should be able to understand the result of an action and what to do next.
Do not communicate correct and incorrect answers using color or icons alone. Pair visual indicators with clear text.
For example, instead of showing only a red border around an unanswered field, provide a message such as, Select an answer before continuing.
Feedback and validation messages should appear in a clear location and remain available long enough to be understood. When reviewing an assessment with a screen reader, check that important errors, feedback, and status changes are communicated when they occur.
Review timing settings
Time limits can affect accessibility, especially when speed is not part of the learning objective.
Before adding a time limit, consider whether it is necessary for what the assessment is intended to measure. Where LearnWorlds settings provide flexibility, consider options such as additional time, additional attempts, or an untimed configuration when appropriate.
Explain any time restrictions before the assessment begins so learners know what to expect.
Review keyboard interaction
Interactive activities should support keyboard use without requiring a mouse.
During a keyboard check, use the following controls where applicable:
- Tab to move forward through interactive elements
- Shift + Tab to move backward
- Enter to activate relevant links and controls
- Space to activate buttons and selectable controls where appropriate
- Arrow keys to move within components that support them
Check that:
- Important controls can be reached
- Keyboard focus is visible
- Focus moves in a logical order
- Controls can be operated successfully
- Focus can move into and out of the activity
- Focus does not become trapped
- Hidden or inactive elements do not receive focus unexpectedly
- The activity can be completed without requiring a mouse
Interaction types such as drag-and-drop may require particular attention because a mouse-based action may need another method of operation.
For a more detailed testing workflow, see Testing your LearnWorlds learning experience for accessibility.
Review SCORM and HTML5 learning activities
SCORM and HTML5 packages are created outside LearnWorlds and then uploaded to the platform. LearnWorlds can deliver these packages, but it cannot change the internal structure or behavior of the package after it has been created.
Before publishing a SCORM or HTML5 activity, review whether it:
- Can be operated using a keyboard
- Uses a logical navigation and focus order
- Avoids keyboard traps
- Keeps focus indicators visible
- Provides meaningful names and labels for buttons, links, and controls
- Works with relevant screen readers where required
- Provides captions, transcripts, or other alternatives for media where appropriate
- Includes appropriate alternative text for meaningful images
- Uses sufficient color contrast
- Communicates important information using more than color alone
- Provides clear errors and feedback
- Remains usable when text is enlarged or the viewport changes
If you did not create the package, ask the provider about its accessibility support before making the activity part of a required learning experience.
What to ask a SCORM or content provider
When purchasing, licensing, or selecting externally authored content, ask the provider how accessibility has been considered and tested.
Useful questions include:
- Which accessibility standards does the content aim to support?
- Has the content been evaluated against WCAG?
- Which WCAG version and conformance level were used?
- Which browsers and screen readers have been tested?
- Can all required activities be completed using a keyboard?
- Are captions, transcripts, and other media alternatives provided where needed?
- Are meaningful images supplied with appropriate text alternatives?
- Are there known accessibility limitations?
- Is an accessibility statement available?
- Is a Voluntary Product Accessibility Template (VPAT), Accessibility Conformance Report (ACR), or equivalent accessibility document available?
Accessibility documentation can provide useful information about how a provider has evaluated its content. It does not guarantee that every learner will experience the content without barriers, so important learner experiences should still be reviewed in your own context.
Review embedded and third-party content
LearnWorlds schools can include content and tools from external providers, such as embedded websites, forms, scheduling tools, surveys, widgets, external applications, and learning resources.
Once a learner enters an external interface, its accessibility depends largely on how that provider has built and maintained the experience.
Before making a third-party tool part of a required activity, review whether:
- Keyboard interaction is supported
- Focus moves into and out of the embedded experience predictably
- Important controls have clear names and labels
- Forms provide understandable labels and instructions
- Errors explain what needs to be corrected
- The experience works with relevant screen readers
- Media provides appropriate alternatives
- Text and controls use sufficient contrast
- Important information does not rely only on color or visual position
If the provider publishes an accessibility statement, VPAT, ACR, or other accessibility documentation, review it before making the tool part of an important learner experience.
External video and media should also be reviewed separately. For detailed guidance, see Making video, audio, images, and other media accessible.
Review custom HTML, CSS, and JavaScript
Custom code can change how the learner experience behaves and may also change accessibility behavior provided by the underlying platform.
Where possible, use native HTML controls and LearnWorlds components for standard interaction patterns instead of recreating them with custom code.
When reviewing custom content, check for:
- Clickable elements that are not implemented as appropriate buttons or links
- Interactions that require a mouse
- Missing form labels or accessible names
- Controls that do not communicate states such as selected, expanded, checked, or disabled
- Focus indicators removed by custom CSS
- Focus moving in an unexpected order
- Pop-ups, menus, or dialogs that create keyboard traps
- Visual content order that does not match the underlying reading or focus order
- Low text or component contrast
- Moving or updating content that cannot be paused or controlled
- Content that is visible but unavailable to assistive technologies, or content that is hidden visually but still announced
Review custom interactive components
Custom pop-ups, dialogs, dropdown menus, and similar components should be tested separately when they are created or modified with custom code.
Check that these components can be opened, used, and closed with a keyboard. When a dialog or menu opens, keyboard focus should move to the active component so learners can interact with it. When it closes, focus should return to a logical place, such as the button or link that opened it.
Also check that all controls inside the component can be reached and that their purpose and state are communicated to assistive technologies. For example, a dialog should have a clear name, and a menu should communicate whether it is open or closed where relevant.
LearnWorlds cannot verify the accessibility of code added by customers, so custom interactions should be reviewed and tested before they are used in an important learner experience.
Provide an accessible alternative when needed
Some third-party or externally authored content may not be sufficiently accessible and may not be something a school owner can modify directly.
If the activity is required for completing the course, consider providing another way to access the same information or achieve the same learning objective.
Depending on the activity, an alternative could include:
- A text version of the information
- An accessible document
- A transcript
- An alternative video
- A LearnWorlds-native learning activity covering the same information
- A different assessment format
- Another method for submitting an answer or completing the activity
The alternative should support the same intended learning outcome. Make it easy to find and explain clearly when it should be used.
Understand what LearnWorlds and external providers can control
The accessibility of an activity can depend on more than one part of the experience. LearnWorlds can improve the accessibility of the platform and the components we build, while school owners and external providers influence the content and tools added to that experience.
LearnWorlds can directly improve the accessibility of LearnWorlds-built interfaces, including Course Player structure, platform controls, and platform-level keyboard and screen reader behavior.
School owners, admins, and course creators influence accessibility through choices such as assessment settings, uploaded SCORM and HTML5 packages, embedded tools, custom code, third-party providers, and any alternative formats they make available.
External providers control the accessibility of their own applications and content, including keyboard interaction, screen reader support, media controls, semantic structure, and their own accessibility testing.
Knowing which part of the experience is causing an issue can help you determine whether it needs to be addressed in LearnWorlds, in your own content or configuration, or by the external provider.