Accessible elearning is about completing the whole experience
Accessibility is sometimes treated as a characteristic of a single product. A course is reviewed. An accessibility checklist is completed. The module is published. The project team records that the accessibility work has been done.
That approach is understandable, particularly when responsibility for the course sits with one supplier or development team. It is also incomplete.
In April 2025, the Australian Human Rights Commission released updated guidelines on equal access to digital goods and services. The guidelines are intended to help organisations meet their obligations under the Disability Discrimination Act 1992. They are not legally binding in themselves, but the Commission states that they can help organisations act consistently with the Act.
The Commission also recommends that organisations conform with WCAG 2.2 at a minimum of Level AA.
Importantly, the Commission frames accessibility around a person’s ability to complete the full task or use a complete digital service, not simply their ability to access one screen or one piece of content.
The Web Content Accessibility Guidelines take a similar view. The WCAG requirements relating to a complete process recognise that, when a sequence of pages is required to complete an activity, accessibility cannot be established by examining only one part of that sequence.
For an online retailer, the complete process might extend from selecting a product through to payment and receiving confirmation.
For workplace learning, the process might begin when a person receives a training notification and end only when their completion has been recorded successfully.
That distinction matters. A learner does not experience the course, the LMS, the login system and the supporting documents as separate organisational products. They experience one learning task.
Start by mapping the real learner journey
Before testing begins, map what the learner is actually expected to do.
This sounds obvious, but digital learning projects are commonly divided across several teams. The elearning developer builds and tests the module. An LMS administrator configures enrolment and reporting. IT manages authentication. A communications team sends the invitation. A policy owner provides supporting documents. A service desk responds when something goes wrong.
Each group may complete its own part of the work successfully while no one evaluates the journey as a whole.
A typical workplace learning journey may require the learner to:
- Receive and understand a training invitation.
- Activate an account or confirm their identity.
- Sign in and complete multi-factor authentication.
- Locate the required course in the LMS.
- Understand why the training is required and when it is due.
- Launch and navigate the course.
- Complete activities and assessments.
- Open supporting policies, procedures or resources.
- Receive a clear completion result or training record.
- Find help if any part of the process does not work.
Behind those ten steps there may be an email platform, an HR system, an identity provider, an LMS, a SCORM player, a video service, downloadable documents and a separate helpdesk system.
One inaccessible handover can prevent completion of the entire task.
Accessibility barriers can appear before the course begins
When people think about accessible elearning, their attention naturally moves to the module itself. However, some of the most significant barriers appear in the communications, registration and authentication steps that sit before it.
If the learner cannot understand the invitation, activate their account or sign into the platform, the accessibility of the course becomes largely irrelevant.
Invitation, registration and enrolment
A course invitation should make the required action clear without depending on an image, colour or visual layout to communicate essential information.
The message should explain what the training is, why the person is receiving it, when it is due, how long it is expected to take and where help is available. Important information should appear in the body of the message rather than only inside an attachment.
Link wording also matters. A link labelled Complete your Respectful Workplaces training gives the learner a clear destination. A link labelled Click here does not.
That difference becomes particularly important for people who navigate by scanning links, using a screen reader or moving through a page without a mouse. Our article on creating accessible hyperlinks provides further guidance on making links meaningful and easy to understand.
Registration and enrolment forms should use properly associated labels, logical keyboard navigation and clear instructions. When the learner makes an error, the message should identify what has gone wrong and explain how to correct it. An error indicated only by a red outline may be missed by someone who cannot perceive the colour or by assistive technology that has not been notified of the change.
These are small design decisions, but they shape whether the learner can begin the task independently.
Login, single sign-on and multi-factor authentication
Authentication is one of the most common places for accessibility to become someone else’s problem.
The learning team may not own the login page. It may sit within Microsoft, Google, an internal identity provider or another third-party system. However, from the learner’s perspective, it is still the entrance to the learning experience.
WCAG 2.2 includes an Accessible Authentication criterion at Level AA. Its purpose is to reduce unnecessary cognitive effort during authentication and avoid making memory, transcription or problem-solving the only way to sign in.
This does not mean weakening security. It means implementing security controls in ways that can be used by people with different access needs.
Password managers should be supported. Learners should generally be able to paste passwords and verification codes. Login fields should have clear labels, error messages should be specific, and visual puzzles should not be the only available verification method.
Time limits also require thought. A learner using screen magnification, voice control or another assistive technology may take longer to complete a process. If re-authentication is required, the system should preserve work wherever possible rather than forcing the learner to begin again.
Multi-factor authentication is a security process, but it is also part of the learner journey. It needs to be tested with the same care as the LMS and course.
Finding the course can be harder than completing it
Signing in successfully does not mean the learner can find what they need.
LMS dashboards often grow over time. What begins as a simple list of assigned courses can become a combination of banners, catalogues, carousels, search fields, filters, alerts, due dates, reports and promotional content.
That information may look well organised visually while becoming repetitive or confusing when read by a screen reader. Keyboard users may need to move through dozens of navigation items before reaching their assigned learning. Status information may be communicated by colour alone. A course card may have several links with identical labels such as View or Launch.
Accessibility testing should therefore include the actual pathways learners use. This might include assigned learning, course catalogues, search, filters, course cards, due dates, completion history, certificates and mobile views.
A vendor accessibility statement or conformance report is useful evidence, but it does not replace testing the organisation’s configured environment.
Custom branding, themes, plugins, integrations, dashboard changes and third-party widgets can all alter the experience. A platform that performs well in its standard configuration may behave differently once it has been adapted to the organisation.
Launching the course is another important handover
The move from the LMS into the course player creates another point of risk.
Does the course open in a new tab or window? If it does, is that change communicated to the learner? Does keyboard focus move to a sensible location? Can the learner return to the LMS? Does the player create a keyboard trap? Are the course controls still visible when the page is enlarged? Does the course resize appropriately on a smaller screen?
These questions cannot be answered fully in an authoring-tool preview.
Review links and external testing environments are valuable during development, but final testing should occur in the organisation’s real LMS using the intended player settings, authentication, permissions, browser configurations and branding.
A SCORM package may behave perfectly in one environment and encounter focus, sizing, tracking or resume issues in another.
The course itself still needs to get the fundamentals right
Looking at the complete journey does not reduce the importance of course-level accessibility. It places it in context.
The module still needs to be designed and developed so that people can perceive the information, operate the interface, understand the content and use it reliably with assistive technologies.
Depending on the course, this usually includes attention to:
- Structure and navigation: meaningful headings, logical reading order, descriptive labels, consistent navigation and visible keyboard focus.
- Images and multimedia: appropriate text alternatives, accurate captions, transcripts and equivalent access to important visual information.
- Interactions: full keyboard operation and alternatives to activities that rely on dragging, hovering, rapid movement or precise pointer control.
- Visual presentation: sufficient colour contrast, readable text, sensible spacing and information that does not depend on colour or position alone.
- Timing and movement: suitable controls for animation, audio, video and time-limited activities.
- Feedback and status: results, errors and changes that are communicated both visually and through assistive technology.
These are not settings to switch on immediately before publication. They need to influence the learning structure, visual design, writing and interaction model from the beginning.
An authoring tool may provide accessibility features, but the presence of a feature does not guarantee that it has been used well. Alt text can still be vague. Focus order can still be illogical. Captions can still be inaccurate. A keyboard-accessible interaction can still be unnecessarily difficult to understand.
Accessibility is a design discipline, not simply a software function.
Assessment is where accessibility can unravel
Assessments often introduce more complex behaviour and less tolerance for error than the learning content that precedes them.
A learner may need to interpret instructions, select response options, move between questions, identify unanswered items, submit responses, interpret feedback and retry incorrect questions. If any of those steps is inaccessible, the assessment may fail to measure the person’s knowledge accurately.
For example, a learner may understand the subject but be unable to complete a drag-and-drop question using a keyboard. Correct and incorrect feedback may be shown only through green and red styling. A result panel may appear visually but not be announced by a screen reader. A timed assessment may expire before someone using assistive technology can complete it.
The issue is not simply whether the questions can be reached. It is whether the learner can understand what is required, provide an answer, recognise what happened and move to the next appropriate action.
Progress should be saved where practical. Unanswered questions should be easy to identify. Feedback should be available without relying on colour alone. Changes in status should be communicated to assistive technology. Retry behaviour should be predictable and should not trap the learner in a repetitive loop.
The same expectations apply when an assessment sits outside the course. An LMS quiz, external form or third-party assessment platform remains part of the learning process.
Resources can undo good accessibility work
Supporting resources are often treated as content attachments rather than parts of the learner experience.
A carefully designed course might link to a policy, procedure, workbook, form or reference guide that has not been reviewed for accessibility. A scanned PDF may contain no usable text. A long document may have no heading structure or bookmarks. A table may make sense visually but have no meaningful structure when read by assistive technology.
This creates a frustrating situation in which the course introduces the topic accessibly and then directs the learner to an inaccessible source of truth.
Linked documents should be checked for real text, logical reading order, meaningful headings, descriptive links, structured lists and tables, appropriate alternative text, usable form fields and sufficient colour contrast. Longer documents should be easy to navigate, and an accessible source format or alternative should be available where needed.
The learning team does not necessarily need to own every document. It does, however, need to identify when a required resource creates a barrier and work with the relevant owner to address it.
Completion records are part of the experience too
A learner should be able to tell when they have completed the course successfully.
That sounds straightforward, but completion can become unclear when the course closes abruptly, the LMS does not refresh, a score is recorded without explanation or the learner is returned to a dashboard that still shows the course as incomplete.
The final status should be understandable visually and through assistive technology. When a certificate or completion statement is provided, that document should also be accessible rather than simply being an image containing text.
Learners may need to use their training record later to demonstrate compliance, confirm professional development or provide evidence to a manager. Accessibility should not stop at the final question.
Support is not an accessibility strategy, but it is part of an accessible service
When something goes wrong, learners need a clear and consistent way to get help.
Support may be provided through accessible help content, email, chat, telephone assistance, an LMS administrator or the learner’s manager. The right model will depend on the organisation, but the pathway should be easy to find and suitable for different communication needs.
Support should not be used as a substitute for fixing standard accessibility barriers. Requiring a person to disclose a disability and request individual intervention every time they encounter a routine process is not a sustainable model.
At the same time, even a well-designed system can encounter account, device or configuration issues. A visible and consistent support pathway gives learners a way forward rather than leaving them stranded partway through mandatory training.
Accessibility testing needs more than one method
There is no single test that can establish the quality of an accessible learning experience.
A strong evaluation combines automated checks, informed manual testing and input from people with disability. Each method reveals different information.
Automated accessibility checks
Automated tools can identify common technical issues such as missing labels, coding errors, contrast failures and some structural problems. They are efficient and valuable throughout design and development.
They are not a complete answer.
W3C guidance on selecting accessibility evaluation tools makes it clear that tools cannot check every aspect of accessibility automatically. Human judgement remains necessary, and automated results can sometimes be incomplete or misleading.
An automated scan cannot determine whether a course invitation makes sense, whether the LMS journey is predictable or whether an assessment feedback loop is understandable.
Manual accessibility testing
Manual testing examines the parts of the experience that require human judgement.
This includes keyboard navigation, focus behaviour, screen-reader output, zoom and reflow, authentication, error handling, media controls, assessment feedback and course-player behaviour.
Manual testing should cover the final configured environment rather than stopping at the course package. It should also include the browsers, devices and assistive technologies the organisation intends to support.
Evaluation with people with disability
People with disability can identify practical barriers and usability issues that are difficult to understand through technical review alone.
W3C recommends involving users with disability in accessibility evaluation throughout development—not only at the end. It also cautions against assuming that the experience of one person represents every person with the same disability.
User involvement is extremely valuable, but it does not replace a standards-based accessibility evaluation. The strongest approach combines both.
A new evaluation methodology broadens the view beyond websites
In July 2026, W3C published WCAG Evaluation Methodology 2, known as WCAG-EM 2.
The earlier methodology focused specifically on websites and web pages. WCAG-EM 2 can be applied more broadly to digital products, including websites, mobile applications and kiosks. That broader scope is useful for learning environments, where the experience may move between several platforms and content types.
The methodology guides evaluators through five broad stages: defining the scope, exploring the product, selecting a representative sample, evaluating that sample and reporting the findings.
For learning teams, the most important point may be the first one: define what is actually being evaluated.
If the scope is described only as “the elearning course”, the invitation, authentication, LMS navigation, supporting documents and completion process may all be excluded before testing begins.
A more useful scope would describe the complete learner journey and identify the systems, views, functions and content required to finish it.
A practical end-to-end accessibility test
A useful way to test the experience is to begin with a representative learner account and complete the same task expected of the target audience.
Use the same permissions, enrolment rules, authentication process, LMS configuration and course package that will be used in production. Avoid relying only on administrator accounts, as they may present different navigation and fewer access barriers.
Test whether the learner can:
- Receive and understand the training invitation.
- Activate an account and sign in.
- Complete multi-factor authentication.
- Find the assigned course.
- Understand its purpose, duration and due date.
- Launch the course and move into the learning content.
- Navigate representative pages and interactions.
- Pause, replay and understand multimedia.
- Exit and resume without losing progress.
- Complete the assessment and interpret the feedback.
- Open and use the supporting resources.
- Confirm completion and access a training record or certificate.
- Locate and use the available support process.
Complete the journey using keyboard-only navigation and relevant assistive technologies. Repeat it across the supported browsers, devices and screen sizes.
Record each issue against the stage of the journey where it occurs. Note its impact, the system involved, the person or team responsible for addressing it and whether the remediation has been retested.
A passing automated scan is one useful form of evidence. A learner successfully completing the full journey is another.
Test the difficult pathways, not only the happy path
Many learning journeys work when everything goes to plan. Accessibility and usability issues often become visible when the process is interrupted.
What happens when the learner closes the browser and returns the next day? What happens when the internet connection drops? What happens when the session times out? What happens when the learner fails an assessment, changes devices or needs to reset a password?
These are realistic events, not edge cases.
A learner who takes longer to read or navigate may encounter timeouts more frequently. Someone using a mobile device in a remote workplace may have an unstable connection. A person relying on magnification may not notice that a session warning has appeared outside the visible area of the screen.
Testing should therefore include interruptions, failed attempts, resume behaviour and recovery pathways. An experience is not robust if it is accessible only when every step works perfectly the first time.
The ownership problem
Many accessibility gaps sit between teams.
The elearning developer may not control authentication. The LMS administrator may not own the linked documents. IT may not understand the required learning sequence. The communications team may not know how the invitation behaves with assistive technology. The policy owner may not know that the PDF has become a barrier.
Without end-to-end ownership, every component can be treated as someone else’s responsibility.
Organisations can reduce this risk by assigning someone responsibility for the complete learner experience. That person does not need to personally fix every issue. Their role is to understand the whole pathway, coordinate the relevant owners and make sure accessibility does not disappear at the handovers.
Accessibility should also appear in project acceptance criteria, LMS implementation plans, supplier requirements and ongoing content governance. Known limitations should be documented, remediation actions should have owners, and accessible interim pathways should be available when a barrier cannot be corrected immediately.
Testing should not be a one-off event. LMS upgrades, theme changes, new integrations, refreshed authentication processes and course updates can all introduce new issues. Important journeys should be retested when the surrounding environment changes.
Ask better accessibility questions during LMS procurement
Accessibility is easier to influence before a platform is selected than after it has been implemented.
A generic statement that an LMS or digital platform is “accessible” does not provide enough information. Organisations need to understand what was evaluated, which version was tested, what was excluded and how their own configuration could affect the result.
Useful questions for an LMS or technology supplier include:
- Which accessibility standard and version has the product been evaluated against?
- Which learner journeys, functions and product areas were included in the evaluation?
- Which browsers, devices and assistive technologies were used?
- What known accessibility issues remain, and when are they expected to be addressed?
- How can custom themes, branding, plugins and integrations affect accessibility?
- How are accessibility defects reported, prioritised and communicated to customers?
- Can the organisation test a representative learner journey before purchase or implementation?
- How frequently is accessibility retested following product updates?
A conformance report can be valuable, but it should begin a more detailed conversation rather than end one.
Organisations reviewing their broader digital learning environment and learning platforms should consider accessibility alongside security, reporting, integration, usability and support.
What a good accessible learning experience looks like
A good accessible learning experience does not require every learner to use the same device, navigation method or way of processing information.
It provides reliable ways for people to complete the same core task.
Learners can understand what is required. They can access the system, locate the learning, navigate the content, complete the assessment, use the supporting resources, confirm their completion and seek help without encountering unnecessary barriers.
They are not required to understand how the organisation has divided responsibility between HR, IT, learning, communications and external suppliers. Those internal boundaries should be invisible to the person completing the training.
Accessibility is therefore not only an elearning development requirement. It is part of communication, service design, procurement, implementation, assessment, learner support and governance.
The course is not the finish line
Consider the full experience.
Can someone complete the full learning task, from the first invitation through to assessment, completion evidence and support?
Map the journey. Test the handovers. Use automated tools appropriately, apply informed manual testing and involve people with disability. Assign responsibility for the complete experience rather than leaving accessibility to individual project components.
At Lucid, we build accessibility into our custom elearning design and development and help organisations consider how course content, learning platforms, supporting resources and the complete learner journey work together.
To discuss accessible elearning, your learner experience or a review of your current digital learning environment, contact the team at Lucid.
The content on this page was last updated on 18 August 2026.
