Why standards exist
Online learning depends on software: browsers, learning platforms, video players, documents. When that software is built without thought for how different people use it, whole groups are shut out. Accessibility standards exist so that designers, developers and authors share a common description of what “usable by more people” requires, and so there is something concrete to test against.
The best-known set is the Web Content Accessibility Guidelines, usually shortened to WCAG, published by the World Wide Web Consortium. It has gone through several versions, including 2.1 and 2.2, and later versions add to earlier ones. Many laws and institutional policies refer to WCAG, often naming a version and a level. This article explains its main ideas in plain terms; it is not a full reading of the standard.
The four principles
WCAG organizes its requirements under four principles, often remembered as POUR.
- Perceivable: information must be presentable in ways users can perceive. Someone who cannot see needs text or audio; someone who cannot hear needs captions.
- Operable: users must be able to operate controls and navigate, including without a mouse.
- Understandable: content and the interface must be clear and predictable.
- Robust: content must work with a range of browsers and assistive tools, now and as they change.
Each principle contains numbered guidelines and testable success criteria, graded at three levels: A, AA and AAA. Level AA is the one most commonly cited in policies, while AAA is regarded as not achievable for all content.
Captions and text alternatives
Pre-recorded video with speech needs captions, and pre-recorded audio needs a transcript or equivalent. Live captioning is also expected in some contexts. Captions should be accurate, synchronized and complete. Automatically generated captions are a convenient starting point but must be checked.
Images that carry meaning need a text alternative. A good description conveys what the image contributes to the lesson, not just what it depicts. Decorative images should be marked so assistive tools can skip them. For a complex chart, give a short description and make the underlying data available in a table.
Screen reader support
A screen reader builds its picture of a page from the underlying code, not from how the page looks. That means the following matter:
- Headings must be marked as headings and used in order.
- Lists, tables and landmarks (such as main content and navigation) must use proper structure.
- Links and buttons need names that describe what they do.
- Form fields need labels linked to them.
- Dynamic changes, such as a quiz result appearing, should be announced.
- Any custom interactive widget should expose its name, role and state to assistive tools.
Authors working in a platform’s editor usually control headings, descriptions and link text, but not the platform’s underlying code. If the platform itself is inaccessible, authors can only do so much, and reporting the issue to the provider is appropriate.
Color and contrast
WCAG sets minimum contrast between text and its background. At level AA, ordinary text should have a contrast ratio of at least 4.5 to 1, while large text needs at least 3 to 1. User interface components and meaningful graphics also have a minimum, 3 to 1. Information must not rely on color alone: if errors are shown only in red, a color-blind learner may miss them, so add text or an icon.
Free contrast-checking tools take two colors and report the ratio. Remember to check text over images and in dark mode as well.
Keyboard access
Everything that can be done with a mouse should be possible from the keyboard. Specific points include a visible indication of where focus currently is, a logical tab order, no keyboard traps that stop you leaving a component, and a way to skip repeated navigation. This matters for people with motor impairments, for screen reader users and for those who simply prefer it. Learning a few keyboard shortcuts is helpful for testing as well.
Layout, text and time
Further requirements often relevant to courses include:
- Text can be enlarged substantially without losing content or function.
- Content reflows on a narrow screen without sideways scrolling.
- Users can adjust or extend time limits on timed activities.
- Moving or flashing content is limited, since flashing can be dangerous for some people.
- Error messages explain what went wrong and how to correct it.
Documents and downloads
Course documents are in scope too. Tagged PDFs with headings, descriptions and reading order are far more useful than scans. If you prepare slides or handouts, use heading styles and built-in lists, and run the accessibility checker many editors provide. Having to change formats later is simpler with an editable original, and many PDF tools include options for checking structure.
Testing
A layered approach is practical.
- Run an automated checker to catch obvious faults. These tools find only a portion of problems.
- Test with the keyboard.
- Try a screen reader on key pages.
- Review captions and transcripts by hand.
- Ask learners who use assistive tools to try the course.
Document what you find and what you fixed.
Keeping it in proportion
Standards are a baseline, not a guarantee that every learner will find a course easy. They do not cover every cognitive or learning need, and conformance can be claimed while a course remains hard to use. Yet they give authors and platform providers a shared language and a way to hold each other to account. For open courses, which anyone may meet, building to the standard from the beginning is a courteous and practical choice.