Accessibility testing helps you identify issues that may not be obvious through visual review alone. You can perform useful checks with a keyboard, a screen reader, and automated tools before deciding whether a deeper accessibility audit is needed.
Start with the parts of the learner experience that matter most, such as signing in, opening a course, moving through the Course Player, completing an assessment, and accessing important files or embedded content.
This guide explains what to test, what to look for, and what these checks can and cannot tell you.
Start with important learner experiences
You do not need to test every page at once. Begin with common learner tasks and the content types used most often in your school.
For example:
- Sign in as a learner
- Open a course
- Move through the Course Player
- Open the main learning activity types used in the course
- Complete an assessment
- Move to the next activity
- Access important files, SCORM packages, or embedded content
Include customized learner-facing pages in your review where they form part of an important task.
Test using only a keyboard
Keyboard testing is one of the quickest ways to identify interaction barriers. Open your school as a learner and complete an important task without using a mouse.
During the test, use Tab to move forward through interactive elements and Shift + Tab to move backward. Use Enter for relevant links and controls, and Space for buttons and selectable controls where appropriate. Some components also use Arrow keys, while Escape may close menus, dialogs, or overlays.
As you move through the experience, make sure every important interactive element can be reached and that the current focus position is easy to identify. Focus should follow a logical order, and buttons, links, menus, forms, and assessment controls should respond to the expected keyboard commands.
Pay particular attention to embedded content and dialogs. Focus should be able to enter and leave embedded content predictably, hidden or inactive elements should stay out of the focus order, and no interaction should trap focus. After a dialog closes, focus should return to a logical place. The full learner task should be completable with the keyboard.
If you cannot reach a control, lose track of the current focus position, or cannot move away from an element using the keyboard, review that interaction more closely.
Check visible focus
Keyboard focus should remain visible so the current interactive element can be identified while moving through the page.
Review focus on buttons, links, navigation items, form fields, menus, assessment answers, and other interactive controls. If your school uses custom colors or CSS, check that styling has not hidden or reduced the visibility of focus indicators.
For more detailed guidance on custom interactions, see Accessibility considerations for assessments, embeds, SCORM, and custom content.
Test with a screen reader
A screen reader test lets you review the structure, names, states, and other information exposed to assistive technologies.
You do not need to become an expert screen reader user before performing a basic spot check. Start with a small number of important learner tasks and focus on whether the content and controls make sense when announced.
Common starting combinations include macOS + Safari + VoiceOver, Windows + Chrome or Firefox + NVDA, iOS + Safari + VoiceOver, and Android + Chrome + TalkBack.
Browser and screen reader combinations can behave differently. For a basic review, choose combinations that reflect the environments most relevant to your learners rather than trying to test every possible setup.
Use the screen reader's built-in tutorial or documentation to learn its basic navigation commands before starting.
What to check with a screen reader
Do not focus only on whether the screen reader announces content. Check whether the information it provides is meaningful and supports the task.
Start with structure and controls. Headings should communicate the page or activity structure, and course sections should be announced in a meaningful order. Links, buttons, and icon-only controls need accessible names that explain their purpose. Form fields and assessment questions should have clear labels, and required information should be available through the screen reader.
Then review feedback and media. Error messages should explain what needs to be corrected, and feedback should stay associated with the relevant action. Meaningful images need useful text alternatives where supported, while decorative images should avoid unnecessary announcements. Relevant states such as selected, expanded, collapsed, completed, locked, or unavailable should be communicated where applicable. Important changes, such as an error appearing or new feedback becoming available, should also be announced when needed.
For example, a control may visually display Next lesson while a screen reader announces only Button. Without an accessible name, the purpose of the control may not be clear.
A screen reader spot check can identify potential accessibility barriers, but it does not replace a formal accessibility audit.
Test the Course Player and learning activities
The Course Player is a useful place to begin because it contains the main course structure and the learning activities learners use.
LearnWorlds is investing in making learning content more accessible one learning activity at a time. This is a long-term effort. We have significantly improved the Course Player structure and navigation and are now working on the first learning activity types, Interactive Video and PDFs. Assessments are next, followed by ebooks.
Review whether you can understand the course structure, identify sections and activities, move between activities, identify the current activity, and use Previous and Next navigation. Check that the main learning content can be reached without becoming trapped in sidebars, menus, or other controls.
Then test the main activity types used in the course.
- Video
Check that video controls can be identified and operated with a keyboard. Review whether captions or subtitles are available where appropriate and whether a transcript is available when needed.
For more guidance, see Making video, audio, images, and other media accessible.
- PDF and downloadable resources
Review whether the surrounding learning activity is understandable and whether the file itself has been prepared for accessibility. Check that an accessible alternative is available where needed.
For more guidance, see Preparing accessible course content and downloadable resources.
- Assessments
Check that questions and answer options are announced clearly, controls can be operated with a keyboard, and errors and feedback are understandable.
- SCORM and embedded content
Check that focus can move into and out of the external content and that the activity itself supports keyboard and screen reader use.
For more guidance, see Accessibility considerations for assessments, embeds, SCORM, and custom content.
Review your school website and learner-facing pages
If you have customized your LearnWorlds website, include important learner-facing pages in your review.
These may include the home page, course catalog, course landing pages, sign-in or registration pages, learner profile areas, and custom pages used in important learner tasks.
Review heading structure, link and button names, keyboard operation, visible focus, image descriptions, color contrast, form labels and errors, custom menus or pop-ups, and embedded third-party content.
Custom styling and content can affect accessibility, so review heavily customized pages separately from the standard course experience.
Test third-party and customer-created content separately
Files and experiences created outside LearnWorlds should be tested separately because their internal accessibility depends on how they were created.
This includes PDFs, Word documents, presentations, SCORM and HTML5 packages, embedded applications, external websites, third-party video players, and custom HTML, CSS, or JavaScript.
Where practical, test important external content using both a keyboard and a screen reader. For third-party products, review accessibility documentation provided by the vendor, such as an accessibility statement, Voluntary Product Accessibility Template (VPAT), or Accessibility Conformance Report (ACR).
Use automated accessibility tools
Automated tools can identify some technical accessibility issues quickly. Depending on the page and tool, they may detect missing labels, missing alternative text, low color contrast, certain ARIA issues, HTML structure problems, or duplicate IDs.
Common tools include Lighthouse accessibility checks, WAVE, axe or axe DevTools, and browser accessibility inspection tools.
Automated results need manual review. A tool may detect that an image has alternative text, for example, but it cannot reliably determine whether that text communicates the image's purpose in the course.
Combine manual and automated testing
No single testing method identifies every accessibility barrier. Use different methods for different parts of the experience.
- Keyboard testing helps you review operability, focus order, and keyboard traps.
- Screen reader testing helps you review structure, labels, roles, states, and announcements.
- Visual review helps you check contrast, focus visibility, readability, and whether meaning relies only on visual cues.
- Content review helps you check captions, transcripts, alternative text, instructions, documents, and course structure.
- Automated checks can surface detectable technical issues that need further review.
Understand what a spot check can tell you
Keyboard, screen reader, visual, content, and automated checks can uncover real barriers and help you improve important learner experiences.
They can show whether controls are reachable, navigation makes sense, content has useful structure, images are described appropriately, and important feedback is communicated.
A successful spot check does not mean that a course, website, or platform fully conforms to WCAG or another accessibility standard. Accessibility conformance requires a broader evaluation against the applicable criteria and across the relevant scope.
Use these checks as a practical review, not as formal certification.
When to consider a deeper accessibility audit
A broader review may be appropriate when accessibility is a contractual or regulatory requirement, forms part of procurement or certification, or when you need formal documentation of accessibility conformance.
A professional audit may include WCAG conformance testing, multiple browser and assistive technology combinations, detailed code inspection, document review, testing of custom and third-party content, and a formal issue report with recommended fixes.
The level of testing you need depends on your organization, the content you provide, and the requirements that apply to your use case.