New · source-linked answers
Accessibility knowledge library
Explore twelve common decisions, worked examples and linked sources. Find guidance for images, media, content, interactions, testing and documents.
Explore the knowledge libraryDIGITAL ACCESSIBILITY / LEARN · BUILD · TEST
A useful service lets people find information, understand a choice and complete a task. Practise the details here, then use the testing worksheet to review your own pages.
Fifteen connected resources · source-linked learning and practical tools · no account needed
CHOOSE A TASK
15 resources available.
No matching resources. Try a shorter search or choose Everything.
New · source-linked answers
Explore twelve common decisions, worked examples and linked sources. Find guidance for images, media, content, interactions, testing and documents.
Explore the knowledge libraryNew · learn and plan
Compare captions, transcripts and description. Build a media plan for the content type and target WCAG level, with production and player checks.
Plan accessible mediaNew · inclusive content
Make instructions and journeys easier to understand. Plan the message, draft a rewrite and review it with a human checklist.
Work on content clarityNew · source to publication
Review Word documents, PDFs and presentations. Record structure, reading order, image alternatives and export findings for the selected format.
Review a documentNew · guided observations
Work through 16 manual checks. Record the page, task, environment, evidence and next action; save a draft on this device or download a report.
Start a reviewExpanded · content decisions
Preview a local reference image, choose its purpose and context, and draft an equivalent alternative. Save your writing on this device or transfer a portable draft.
Work on an alternativeNew · editorial review
Paste HTML to inventory image alternatives. Compare missing and empty attributes, record proposed changes and review decisions, then export the whole image list.
Review image markupNew · structured equivalents
Combine a short alternative with a visible full description. Prepare chart values in a semantic table, or explain diagram stages and relationships.
Build a full descriptionNew · working examples
Try validation errors, a modal dialog and keyboard tabs. Follow the focus, inspect the patterns, and test the recovery path as well as success.
Try the interactionsCalculate · compare
Compare foreground and background colours, understand text and interface thresholds, and check that colour is supported by another cue.
Check a colour pairHTML · CSS · JavaScript
Study semantic markup, names, forms, focus and live regions. Pair the code examples with the working interaction lab.
Explore code patternsEditorial workflow
Find the image-description workflow for your publishing platform, then review the final post with its surrounding context.
Open the publishing guideMedia production
Plan speech, meaningful sounds and essential visual information. Review timing and accuracy before publishing.
Plan accessible mediaFind the requirement
Look up a criterion’s level, purpose and practical examples. Keep the full requirement and its exceptions alongside your finding.
Browse the referenceLearn the method
Build a repeatable review using keyboard, screen-reader and visual checks, then turn the result into work a team can reproduce.
Read the testing courseFROM KNOWING TO DOING
Start with what the reader needs to do. Use meaningful headings, short instructions and links that describe their destination. Explain unfamiliar terms at the point of use.
Design the empty, loading, invalid and successful states alongside the main screen. Show where focus should go when something opens, closes or fails. Give information enough space to survive larger text.
Use links for navigation and buttons for actions. Give fields persistent labels and connect help and error messages to their controls. A custom appearance still needs a usable name, role, state and keyboard behavior.
Choose a real task, such as finding a course and registering. Include validation, confirmation and recovery. Record the browser and assistive technology so another person can reproduce the finding.
WCAG 2.2 / PRACTICAL CHECKPOINTS
These are selected criteria added in WCAG 2.2. They extend the fundamentals; they are not a complete conformance checklist. Open each source for the full requirement, definitions and exceptions.
2.4.11 · AA
A keyboard-focused component must not be entirely hidden by author-created content. Check sticky headers and fixed toolbars. User-opened content has an allowance when the control can be revealed without advancing focus; movable content is assessed in its initial position. Aim to keep the whole control visible.
2.5.7 · AA
When an action needs dragging, provide a single-pointer alternative without a drag, unless an exception applies. A reorder list can offer Move up and Move down buttons. Keyboard support alone does not establish this pointer alternative.
2.5.8 · AA
The minimum target size is 24 × 24 CSS pixels, subject to spacing and other exceptions. Tiny neighbouring icons need particular care. Larger targets can be easier to use; 44 × 44 belongs to the enhanced AAA criterion, not this AA minimum.
3.2.6 · A
When a help mechanism repeats across a set of pages, keep its order relative to other content consistent unless the user changes it. Check contact links and self-help options across the same layout variation. This criterion does not require adding a help mechanism to every page.
3.3.7 · A
When a process asks again for information already entered or provided, populate it or make it selectable, subject to the criterion’s exceptions. For example, offer to reuse the delivery address for billing. Browser autocomplete alone is not the same as the site reusing that information.
3.3.8 · AA
Avoid making a cognitive-function test the only way to authenticate. Support tools such as password managers and pasting codes, or an alternative that meets the criterion. Its named exceptions matter; inspect the whole login and recovery journey rather than one field.
CONTENT IS PART OF THE PRODUCT
An event poster needs its essential event information in text. A chart may need a short alternative plus a nearby explanation or data table. Keep names, units, relationships and the important conclusion available without relying on the image.
Provide the information where people need it, and use the alternative to identify the image’s role. Avoid repeating a full caption when it already provides the same meaning.
Plan captions for speech and meaningful sounds. Identify essential visual information that the audio does not convey, and plan description where needed. A transcript makes content easier to search and review; it does not automatically replace synchronized captions or required audio description.
Review automatic output for names, timing and meaning. Check the player with a keyboard, including captions and playback controls.
LEAVE A USEFUL HANDOFF
Record evidence and uncertainty. “No issue found” means that this check, on this task and environment, did not reveal an issue. A short worksheet or automated scan cannot establish that a whole website conforms.
Guidance reviewed on 15 September 2026. These original learning tools use WCAG 2.2, W3C WAI tutorials and ARIA Authoring Practices. Individual tools link to the relevant material. Apply the full requirements to your project and test with people who use assistive technology.
CONTENT / TOOLS / INTERFACES / EVALUATION
Explore WCAG for content, ATAG for authoring tools, UAAG for browsers and players, WAI-ARIA for interface semantics, ACT for test rules, and EARL for reporting results. Search the references, try practical learning activities, and follow the original sources.