Build it in, do not bolt it on
Fixing accessibility after a resource is finished is slow and often incomplete. Building it in while you write costs little extra, and it tends to make the material clearer for everyone, including people reading on a phone, in a noisy room or in a second language. The checklist below is ordered roughly as you would work: structure first, then text, images, media, color and finally a quick test.
This is a practical overview, not a full standard. For formal requirements in your own situation, consult the official guidance that applies to your institution or country.
Start with structure
Screen reader users often navigate by jumping between headings, so real structure matters more than appearance.
- Use your authoring tool’s actual heading styles (Heading 1, 2, 3) rather than making ordinary text big and bold.
- Keep heading levels in order. Do not jump from a level 2 to a level 4 because you like the look.
- Give each page or section a meaningful title.
- Use real lists for lists and real tables for data. Avoid tables for layout.
- Give table columns header cells, and keep tables simple, without merged cells where possible.
Most word processors and web editors can do all of this, and the same structure carries across if the file is later converted to another format.
Write plainly
Clear writing is an accessibility feature. Short sentences, familiar words, and one main idea per paragraph help learners with reading difficulties, those working in a second language, and anyone short on time. Explain abbreviations the first time they appear. Make link text meaningful: “download the exercise sheet” tells a screen reader user far more than “click here”. If you use a standard dyslexia-friendly approach such as left-aligned text with generous spacing, that will help many readers, though there is no single layout that suits everyone.
Images and diagrams
Every image that carries meaning needs a text alternative, usually called alt text. A few guidelines:
- Describe what the image is for, not just what it looks like. For a chart, state the main point and where the data can be found.
- Keep it short for simple images. Put longer descriptions in the surrounding text.
- Mark purely decorative images as decorative so they are skipped.
- Avoid putting important text inside an image. If you must, repeat it in the text.
For complex diagrams, a written explanation or a data table next to the figure is usually better than trying to cram everything into alt text. Pairing a diagram with a clear verbal explanation also follows the idea of dual coding, where words and pictures support each other.
Audio and video
Recorded media should come with captions, and ideally a transcript. Captions help deaf and hard-of-hearing learners, but also people watching without sound or in a noisy place. Automatic captions are a useful starting point, but they contain errors, especially with names and technical terms, so review and correct them before publishing. For video where important things appear only on screen, describe them aloud in the narration, or provide an alternative description. Avoid autoplay, and give users controls to pause and adjust volume.
Color, contrast and layout
- Do not use color as the only way to convey meaning. “Answers in red” fails for color-blind readers; add a label or symbol too.
- Aim for strong contrast between text and background. The widely used web guidelines set a ratio of 4.5 to 1 for normal-size text at their common target level; many free checkers will measure this for you.
- Use readable fonts at a sensible size and avoid long blocks of capitals.
- Allow the layout to reflow, so that text can be enlarged or viewed on a small screen without losing content or needing sideways scrolling.
File formats matter
Choose formats that can be made accessible and that people can adapt. Web pages and well-structured word-processor files are generally easy to work with. PDFs can be accessible, but only when properly tagged, and scanned images of pages are usually not readable by assistive tools at all. If you publish a PDF, consider publishing an editable or web version alongside it. This kind of flexibility is one reason open licenses are so useful: they let others produce alternative formats that suit their own learners.
Interactive items and quizzes
If your resource includes forms, quizzes or interactive widgets, make sure they can be used with a keyboard alone, that every control has a clear label, and that error messages explain what to fix. Avoid time limits that cannot be extended, or at least mention how a learner can request more time. Where you reuse a third-party tool, check its accessibility statement and have a fallback, such as a printable text version.
Test before you publish
A quick check catches most obvious problems:
- Navigate your resource using only the keyboard.
- Run it through an accessibility checker built into your editing tool, remembering these catch only some issues.
- Listen to a section with a screen reader, even for five minutes.
- Zoom the text to 200 percent and see whether anything breaks.
- Print or view it in grayscale to see whether meaning survives without color.
If possible, ask someone who uses assistive technology to try it. Their feedback is more reliable than any tool.
Say what you know
No resource is perfect. Consider adding a short accessibility note stating what you checked, what you did not, and how to report a problem. This is honest, helpful, and invites improvements. Because your resource is openly licensed, others can also fix problems and share the improved version, so make the editable source files available where you can.