You don’t need to be an accessibility expert to start identifying barriers in the digital content you create. There are some simple checks you can incorporate into your development process to help make your eLearning courses more accessible.
I hear from learning designers often who aren’t really sure where to start with accessibility. There’s a misconception that it just means people know where to find your content and everything has alternative text and captions. I know learning designers who assume that because when they checked their content for accuracy and function, everything worked. But does it work for everyone?
Don’t feel bad if this is a misconception you had. If you were never taught about accessibility, you might not know. I didn’t know everything I know now until I knew, ya know? And I’m always learning more.
Using a course I made in Claude Code, I demonstrate how to complete these simple checks, along with some intentionally broken examples to show what happens when things don’t work as they should.
Watch the 5 Simple Checks video on YouTube, or read below to start incorporating these simple checks into your workflow.
1. Check Keyboard Accessibility
Put your mouse aside and try navigating your course using only your keyboard.
- Tab will move through focusable elements.
- Shift + Tab will move backward through focusable elements.
- Enter or Space will activate buttons.
- Arrow keys to move between options in a radio button group.
Can you reach and operate every interactive element? Can you open menus, select answers, submit responses, and close dialogs? Is there a visible focus indicator so you can tell where you are? Do you ever get completely stuck and need to use the mouse to get unstuck?
Don’t just test the first interaction. Try every button, link, question, and other interactive component throughout your course.
2. Check Focus Order
Being able to reach everything with a keyboard isn’t enough. The order in which keyboard focus moves also matters.
As you Tab through your course, pay attention to where focus goes next. Does it follow a logical sequence that makes sense with the content? Or does it jump unpredictably around the screen?
Pay particular attention to dialogs and popups. When one opens, focus should move somewhere appropriate within it. For modal dialogs (a pop-up or overlay that forces interaction before returning to the page’s main content), keyboard focus should remain within the dialog until it’s closed, then return to the control that opened it.
3. Check Color Contrast
Text needs sufficient contrast against its background to be readable. You can check this using a color contrast checker, such as WebAIM’s Contrast Checker.
For WCAG AA, normal-sized text needs a contrast ratio of at least 4.5:1, while large text needs at least 3:1. Important non-text elements, such as form control boundaries and focus indicators, generally need at least 3:1 against adjacent colors.
Don’t forget to check text placed over photographs or gradients. Contrast may be sufficient in one area of the image but not another. That’s where the contrast checker’s color picker comes in handy.
Keep in mind that meeting the minimum contrast requirements is a starting point, not a guarantee that your content will be comfortable for everyone to read.
4. Don’t Rely on Color or Other Sensory Characteristics Alone
Imagine a question that indicates correct answers with a green outline and incorrect answers with a red outline, but provides no other feedback. Someone who can’t distinguish those colors may not know whether their answer was correct.
The same principle applies to instructions. Directions like “select the round button on the right” rely on shape and position rather than identifying the control by its purpose.
Use clear labels and instructions that don’t depend on someone being able to see a particular color, shape, size, or location. For example, “Choose one answer, then select Submit” tells learners exactly what to do without relying on visual characteristics.
5. Check Zoom & Resizing
People may need to enlarge content to access your course comfortably. Others may be using a smaller browser window, or be on a tablet or mobile device with a smaller screen.
Try increasing your browser zoom and resizing the window. Can you still access all of the content? Does text overlap or get cut off? Can you scroll to reach everything, including the contents of popups and dialogs?
Try zooming in to 200%, and then all the way to 400%. Does the content adjust so you can still read and interact with everything? You should be able to scroll up and down without having to scroll back and forth horizontally just to read the text. Nothing should overlap, get cut off, or become impossible to use.
Make sure to test interactions at these sizes, too. A button that works at normal size isn’t much help if it disappears offscreen when someone zooms in.
Accessibility in Claude Code
I’ve seen more and more projects completed with Claude Design and Claude Code recently, and I completely understand why. This was my first project with Claude Code, and I was pretty impressed with how responsive it was to accessibility-related prompts.
I know enough code to detect a lot of accessibility issues, but I am by no means a coder. That is not my expertise. Claude Code makes it possible for me to troubleshoot issues and test them with my keyboard and screen reader and other tools until I find what works. Claude Code can’t replace accessibility testing, but it can help to fix issues if you know how to identify the barriers. I’m excited to experiment more with this and find a workflow that prevents more barriers from being built.
A Starting Point, Not a Complete Accessibility Evaluation
These five checks can help you identify many common accessibility barriers, but they aren’t a substitute for more thorough testing. Programmatic structure, accessible names, screen reader behavior, and other accessibility requirements still need to be evaluated.
Stay tuned for a follow-up post and video where I’ll demonstrate how to use ANDI (Accessible Name and Description Inspector) to inspect some of the accessibility information that isn’t apparent from looking at the screen.
The more we incorporate accessibility checks throughout development, the more opportunities we have to find and fix barriers before learners encounter them.
Follow accessibility professionals on LinkedIn or Substack. More importantly, follow people with disabilities who share their experiences with digital content, including the barriers they encounter and what makes content more accessible.
If we only design based on our own personal life experiences, we’re really only designing for ourselves. You’ve put a lot of work into creating a great learning experience. Don’t let accessibility barriers keep people from experiencing it.
Leave a Reply