What is the difference between accessible and inclusive learning? We explore how accessibility provides the foundation and inclusive design considers the wider learner experience.
When I wrote the first edition of Designing Accessible Learning Content, I was very aware that I still had a lot to learn. Since eLaHub was founded in 2019, our training, consultancy, and auditing work with more than 150 organisations across the private, public and voluntary sectors has given us the opportunity to see first-hand the accessibility challenges learning teams face.
It has also challenged and developed our own thinking.
One area that we still find creates confusion is the difference between accessible and inclusive learning. The two are closely connected and there is considerable overlap between them, but we have found it useful to distinguish between the two.
For us at eLaHub, accessibility provides the essential foundation. Inclusive learning takes us further by considering the wider learner experience.
What do we mean by accessible learning?
W3C describes web accessibility as enabling people with disabilities to perceive, understand, navigate and interact with digital content and contribute without barriers. The Web Content Accessibility Guidelines (WCAG), provides the internationally recognised technical standard used to help achieve this.
Consider your learners access needs
For learning practitioners, this means thinking about whether someone with a disability or access need can actually access and use the learning.
- Can someone using a screen reader access and follow the content?
- Can someone who cannot use a mouse complete the interactions?
- Can someone who is deaf access the information in a video?
- Can someone with low vision read the text and identify the controls?
WCAG 2.2 is the latest version of the Web Content Accessibility Guidelines and contains 86 success criteria across three levels: A, AA and AAA. Level AA is the level most commonly used as the benchmark for accessibility legislation and best practice internationally. To conform at Level AA, content must meet all Level A and Level AA success criteria, which means 55 requirements in total. Not every one of these will apply to every piece of learning content, but practitioners still need to understand which requirements are relevant and how to apply them.
Get started with WCAG
Through our training,and consultancy work, we know that the number and technical nature of the requirements can initially feel overwhelming. One way we help practitioners make sense of them is by connecting individual requirements with the access needs they support.
We also created our 20 eLearning accessibility tips for more accessible learning content leaflet as a practical starting point. It brings together straightforward actions covering vision, hearing, motor and cognitive access needs, helping practitioners begin applying accessibility without having to tackle every WCAG requirement at once.
At this stage, the focus is specifically on accessibility, which means understanding and meeting the relevant standards. The following four examples are ones we often use to show practitioners what meeting WCAG can look like in practice. We have chosen one relating to each of the four main access needs so that the standards feel more connected to the people they are designed to support. They are also among the issues we find most consistently across the hundreds of hours we have spent auditing learning content for organisations across different sectors.
Supporting vision access needs
WCAG 2.2 Success Criterion 1.4.3 Contrast (Minimum) requires sufficient contrast between text and its background. Normal-sized text generally needs a contrast ratio of at least 4.5:1, while large text needs at least 3:1. Success Criterion 1.4.11 Non-text Contrast also requires sufficient contrast for meaningful visual information such as controls, states and important parts of graphics.
These requirements can make a significant difference to people with low vision, colour vision differences and reduced contrast sensitivity. They are also examples of accessibility requirements that often improve readability and usability much more widely.
Supporting hearing access needs
WCAG 2.2 Success Criterion 1.2.2 Captions (Prerecorded) requires captions for prerecorded synchronised media containing audio.
Effective captions include more than the spoken words. Where needed to understand the content, they should identify speakers and communicate meaningful sound information as well. W3C specifically includes non-speech information such as meaningful sound effects within its guidance.
This is something we regularly cover in our eLaHub training because automatically generated captions can provide a useful starting point, but they still need to be checked for accuracy, timing and the information they communicate.
Supporting motor access needs
WCAG 2.2 Success Criterion 2.1.1 Keyboard requires functionality to be operable through a keyboard interface, with limited exceptions.
This is particularly relevant to digital learning because interactions are a common source of accessibility barriers. Learners may be using a keyboard directly or assistive technologies that generate keyboard input. An interaction designed only for a mouse on a desktop or fingers on a mobile device can therefore prevent someone from completing the learning.
WCAG 2.2 also introduced Success Criterion 2.5.7 Dragging Movements, which requires an alternative way to perform functionality that relies on dragging, unless dragging itself is essential. This is particularly relevant to the drag-and-drop activities we regularly review in learning content.
Supporting cognitive access needs
WCAG 2.2 Success Criterion 2.2.2 Pause, Stop, Hide gives people control over moving, blinking, scrolling or automatically updating content.
Movement can be particularly distracting for some people with cognitive disabilities and attention-related access needs. WCAG therefore requires controls in specific circumstances where movement starts automatically, lasts for more than five seconds and appears alongside other content.
As with many WCAG requirements, we often recommend going further than the minimum technical test. If movement is distracting learners or making information harder to process, giving people greater control can improve the experience even where the precise WCAG conditions do not apply.
WCAG gives us the foundation
These examples demonstrate the practical role accessibility standards can play in learning design. They give practitioners testable requirements and a shared benchmark for identifying barriers.
They also have limits.
W3C itself acknowledges that WCAG cannot address every need of every person with a disability. It also distinguishes accessibility from the wider concepts of usability and inclusion. Accessibility focuses specifically on people with disabilities, while inclusion considers diversity and involvement more broadly.
We see that distinction very clearly in our own auditing work. Our technical testing checks learning against WCAG and identifies accessibility failures, but we also include lived-experience testing and recommendations that consider what the content is actually like to use.
A piece of learning can meet a technical requirement and still provide a frustrating, confusing or less positive experience for some learners. That is where our thinking about inclusive learning comes in.
What do we mean by inclusive learning?
At eLaHub, we describe inclusive learning in terms of the experience we are trying to create.
Inclusive learning is learning where people feel welcomed and considered, and where no one has a lesser experience because of a disability or access need.
Accessibility is central to this, but inclusion takes us beyond technical conformance. It encourages us to consider the language we use, the people represented in our content, the choices learners are given, how easy information is to understand and whether people feel that their access needs have genuinely been considered.
Good instructional design is also part of our definition of inclusive learning. Clear instructions, plain language, a logical structure and content broken into manageable chunks can all contribute to a better learning experience. Interaction should also have a clear purpose rather than simply being added to make learning feel more engaging.
The following four examples are not WCAG requirements, but they can make a significant difference to how inclusive the learning feels for disabled people and people with access needs. As with the accessibility examples above, we have chosen them because they are issues we see frequently across our auditing work and because they give practitioners a practical sense of what inclusive learning can look like beyond meeting technical standards.
Note: Inclusive learning can, of course, be considered much more broadly and include many other aspects of diversity such as age, race and ethnicity, gender, sexual orientation and socio-economic circumstances. eLaHub’s particular focus is disability and access needs.
Give people clear accessibility information and support
Learners should know what accessibility features are available, where any known barriers exist and how to ask for help.
For some organisations, particularly public sector bodies, publishing an accessibility statement is also a legal requirement for websites and mobile applications. Even where a particular learning resource is not subject to that requirement, providing clear accessibility information and an obvious contact route sends an important message that access needs have been considered and that support is available.
Working on accessibility statements for individual learning resources, as well as wider organisational accessibility statements, is one of the areas organisations most frequently ask us to support through our consultancy work. It often forms part of a broader discussion about governance, responsibilities, support routes and how an organisation communicates its commitment to accessibility.
Use language that includes different ways of interacting
Instructions can unintentionally assume that everyone uses content in the same way.
Writing select the answer rather than click the answer, or enter your response rather than type your response, avoids assuming that somebody is using a mouse, touchscreen or physical keyboard.
These may seem like very small changes, but they help create learning that acknowledges different ways of interacting with technology. This is one of the reasons we use this language consistently within our Designing Accessible Learning Content Programme and encourage practitioners to adopt it in their own content.
Make information comfortable to read
Not every good inclusive design decision appears as an individual WCAG failure.
Long sections of text in CAPITAL LETTERS are a good example. Using sentence case rather than blocks of capital letters makes text easier to read and scan. GOV.UK guidance recommends avoiding large amounts of text in block capitals because they are harder to read, while the British Dyslexia Association specifically advises against whole phrases in capitals because losing the familiar shape of lower-case words can make them harder to decipher.
This is a good example of how inclusive design can improve the learning experience for everyone, because a change that supports dyslexic learners also makes information easier for all learners to read and process.
Make representation genuinely inclusive
Imagery can technically meet WCAG because it has an appropriate text alternative, But it can still leave some learners feeling that they have been overlooked.
In our audits we still see learning where disability representation consists almost entirely of a single stock image of a wheelchair user. Inclusive imagery should reflect the much broader diversity of disability and access needs, including people whose disabilities are non-visible.
Representation should also feel natural within the learning rather than appearing only when disability or accessibility is the subject being discussed. Disabled people work, lead teams, attend meetings, use technology, study and take part in everyday life. Learning imagery can reflect that reality and in turn change peoples’ perceptions and shift mindsets.
Why we need both
The distinction between accessible and inclusive learning has become increasingly useful in our work with organisations.
Accessibility gives us standards that can be tested. We can check colour contrast, keyboard access, captions, headings, alternative text and many other requirements against WCAG.
Inclusive learning asks us to look at what sits around those requirements. How straightforward is the learning to use? Does the language make assumptions about people? Can learners find the information they need? Are different people represented naturally? Does somebody using assistive technology have an equally good experience rather than simply being able to complete the course?
Our recent Insight post, Design accessible eLearning interactions for better learning about unnecessary interaction provides a good example. A series of buttons may technically work with a screen reader and pass the relevant accessibility checks. Feedback from our screen reader tester showed that repeatedly opening controls simply to reveal information could still create a frustrating experience. When we considered the interaction more widely, we realised the unnecessary effort could affect every learner.
That is why technical accessibility and inclusive learning need to work together.
Accessible learning leads towards better learning
One of the most valuable things we have learned through our extensive training and auditing support is that accessibility often makes us question design decisions we might otherwise have accepted without thinking about them.
- Why is this information hidden behind an interaction?
- Why are learners being given a time limit?
- Why does this instruction assume they are using a mouse?
- Why does this video contain important on screen information that isn’t conveyed through narration or audio description?
Answering those questions first helps us remove barriers for people with disabilities and access needs. Very often, it also leads us towards learning that is clearer, more flexible and easier for everyone to use.
Our Accessible and inclusive eLearning – eLaHub ultimate guide explores how these principles can be applied throughout the design and development process.
The distinction we now use at eLaHub is simple. Accessibility gives people access to the learning. Inclusion asks us to consider the experience they have once they are there.
We need both if we want people to have a fair opportunity to participate, learn and demonstrate what they can do, while also creating the kind of excellent learning experience we should be aiming to provide for everyone.
About this article
Written by: Susi Miller and the eLaHub team
Published: August 2026
Explore more with the eLaHub newsletter
For longer thought-leadership articles, in-depth practical guidance and strategic perspectives on accessible and inclusive learning, subscribe to our LinkedIn newsletter, The eLaHub Accessibility Briefing.
Each edition explores an important topic in greater depth, drawing on research, client experience and lived experience. You will find clear guidance, practical reflections and useful ideas to help you move accessibility forward across your organisation.
Subscribe to The eLaHub Accessibility Briefing [Add link]
Links and resources
- W3C Web Content Accessibility Guidelines (WCAG) 2.2
- W3C WCAG 2.2 Success Criterion 1.4.3 Contrast (Minimum)
- W3C WCAG 2.2 Success Criterion 1.4.11 Non-text Contrast
- W3C WCAG 2.2 Success Criterion 1.2.2 Captions (Prerecorded)
- W3C WCAG 2.2 Success Criterion 1.2.5 Audio Description (Prerecorded)
- W3C WCAG 2.2 Success Criterion 2.1.1 Keyboard
- W3C WCAG 2.2 Success Criterion 2.5.7 Dragging Movements
- W3C WCAG 2.2 Success Criterion 2.2.2 Pause, Stop, Hide
- GOV.UK A to Z style guide – capitalisation
- British Dyslexia Association guidance on avoiding whole phrases in capital letters
- Accessible and inclusive eLearning – eLaHub ultimate guide
- Designing Accessible Learning Content Programme
