The eLearning Accessibility Checklist for Course Authors

Accessibility is often treated as a compliance checkbox. Something to worry about after the course is built, if there is time. But accessible courses are not just legally safer. They are better courses. They load faster, work on more devices, and reach learners who would otherwise be shut out.

The WCAG 2.1 AA standard is the benchmark most organizations follow. It can feel dense if you are reading it for the first time. This is not a comprehensive audit. It is a starting point: ten practical items that address the most common accessibility gaps we see in eLearning courses. Getting these right will not make your course perfectly accessible, but it will make it meaningfully better for a wide range of learners.

1. Write meaningful alt text for every image

Alt text is what screen readers announce when a learner encounters an image. It is also what displays when an image fails to load. Good alt text describes what the image communicates, not what it looks like.

For example, a chart showing completion rates should not have alt text that says "bar chart." It should say something like "Bar chart showing 85% completion rate for Module 1 and 62% for Module 2." If an image is purely decorative, like a divider or background pattern, it should have empty alt text so screen readers skip it entirely.

The key question: if a learner cannot see this image, what do they need to know?

2. Follow a logical heading hierarchy

Headings are not just visual formatting. Screen reader users navigate courses by jumping between headings, the same way sighted users scan a page. If you skip from an H2 to an H4, it creates a confusing gap in the document structure.

A clean hierarchy looks like this: H2 for major sections, H3 for subsections within them, H4 for details within subsections. Never choose a heading level for its font size. Use the level that reflects the content's place in the structure.

Slate enforces heading hierarchy automatically. The editor will not let you skip levels, so this one is handled for you if you are building in Slate.

3. Don't use color alone to convey meaning

Roughly 8% of men and 0.5% of women have some form of color vision deficiency. If your course uses red to mean "incorrect" and green to mean "correct" with no other indicator, some learners will not be able to tell the difference.

Pair color with another visual cue: an icon, a label, a pattern, or a border style. "Correct" answers can be green and include a checkmark. Error messages can be red and start with the word "Error." This redundancy helps everyone, including learners viewing your course on a low-contrast screen in bright sunlight.

4. Check your color contrast

WCAG requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18px bold or 24px regular). Low contrast makes text harder to read for everyone, but especially for learners with low vision.

The WebAIM Contrast Checker is a free tool that lets you test any color combination in seconds. Paste in your text and background colors and it will tell you whether you pass AA or AAA levels. If you are using a custom theme, test your heading colors, body text, and any accent colors against their backgrounds.

5. Add captions or transcripts to media

Video content needs captions. Audio content needs transcripts. These give learners an alternative way to access the same content, whether they are deaf, hard of hearing, in a noisy environment, or simply prefer reading.

For video, use SRT or VTT caption files. Most video hosting platforms (YouTube, Vimeo) can auto-generate captions that you then review and correct. For audio narration, a written transcript below the audio block gives learners an alternative way to access the same content.

Auto-generated captions are a starting point, not a finished product. Always review them for accuracy, especially for technical terms and proper nouns.

6. Write descriptive link text

Screen readers can pull up a list of all links on a page. When every link says "click here" or "read more," that list is useless. Descriptive link text tells learners where the link goes without needing surrounding context.

Instead of "To learn more about SCORM exports, click here," write "Learn more about SCORM export formats and options." The link text itself should make sense in isolation.

This also applies to buttons and calls to action. "Submit quiz" is better than "Submit." "Download the PDF guide" is better than "Download."

7. Make knowledge checks keyboard-accessible

Not every learner uses a mouse. Some use keyboards, switch devices, or voice input. Every interactive element in your course, especially quizzes and knowledge checks, should be fully operable with a keyboard alone. That means learners can tab to each answer, select it with Enter or Space, submit, and read the feedback.

If you are using Slate's built-in knowledge check blocks, keyboard accessibility is handled for you. If you are building custom interactions with the Code block, test them by unplugging your mouse and navigating with Tab, Enter, Space, and arrow keys. If you get stuck anywhere, a keyboard-only learner will too.

8. Keep language clear and concise

Cognitive accessibility is part of WCAG, and it benefits every learner. Short sentences, plain language, and clear instructions reduce cognitive load and make content easier to process.

A few practical guidelines: define acronyms the first time you use them. Break long paragraphs into shorter ones. Use bullet points for lists of three or more items. Avoid jargon unless your audience expects it, and even then, consider a brief definition. Write instructions that are specific: "Select the correct answer and click Submit" is better than "Complete the activity below."

9. Test your course on mobile

A significant percentage of learners access training on phones and tablets. If your course has not been tested on a smaller screen, you may have text that is too small to read, tap targets that are too close together, or layouts that break at narrow widths.

Open your course preview on your phone. Can you read every text block without zooming? Can you tap buttons and quiz answers without accidentally hitting the wrong one? Do images scale down or overflow? Responsive design is an accessibility issue: if a course is unusable on mobile, it is inaccessible to learners who depend on mobile devices.

10. Review your course with a screen reader

This is the single most eye-opening test you can run. Even a five-minute pass through your course with a screen reader will reveal issues you cannot catch visually: missing alt text, confusing reading order, unlabeled buttons, or headings that do not make sense out of context.

You do not need special software. Every major operating system includes a screen reader:

• VoiceOver on Mac (built-in, activate with Cmd+F5)
• NVDA on Windows (free, open-source)
• Narrator on Windows (built-in, activate with Win+Ctrl+Enter)

You do not need to become an expert. Just turn it on, close your eyes, and try to take your own course. You will hear what your learners hear.

Accessibility is a practice, not a destination

Accessibility is not something you finish. Standards evolve, tools improve, and our understanding of how people experience content keeps growing. What matters is treating it as an ongoing part of how you work, not a one-time checklist to clear. The more you build with these considerations in mind, the more natural they become.

Slate handles many technical accessibility requirements automatically: heading hierarchy enforcement, keyboard navigation for all interactive blocks, ARIA landmarks, skip navigation, focus management, and semantic HTML output. But the authoring decisions, like writing good alt text, choosing clear language, and adding captions, are yours. The tool provides the structure. You provide the care.

For a full list of Slate's built-in accessibility features, visit our accessibility page. If you have suggestions for how we can do better, let us know on our feedback page.