Making H5P content accessible is not a separate compliance exercise to address at the end of a project, it is a design decision that should be considered from the outset, with each content type evaluated individually throughout the development process.

For course creators and instructional designers, accessibility in H5P presents unique challenges that go beyond those associated with static text or video. Interactive elements such as timed activities, drag-and-drop interactions, branching scenarios and custom user interface components can introduce barriers for learners who rely on keyboard navigation or assistive technologies, such as screen readers.

This guide:

• explores what accessibility means specifically within the context of H5P,
• provides practical recommendations for improving accessibility across different content types,
• includes a pre-publication accessibility checklist and
• outlines effective methods for testing and validating your content.

Why H5P Accessibility Matters Beyond Compliance

There is also a legal dimension to H5P accessibility. In the EU, the European Accessibility Act (EAA) has been applied since June 2025 and most public-facing digital products and services, including e-learning platforms are expected to meet accessibility requirements aligned with WCAG 2.2 AA and EN 301 549. In addition, many organisations like universities, government bodies and public training providers are already subject to separate accessibility obligations under national legislation, regardless of whether the EAA directly applies.

However, the most effective way to think about H5P accessibility is not as a compliance checkbox, but as a marker of quality and inclusivity. Accessibility improvements rarely benefit only one group of users. Captions support not only d/Deaf and hard-of-hearing learners, but also users in noisy environments and those learning in a second language. Clear focus indicators make keyboard navigation easier for screen reader users, while also helping anyone move efficiently through a course. Plain language improves comprehension for people with cognitive disabilities and for learners who are quickly scanning content on a mobile device.

When you design for edge cases, the experience often improves for everyone. This principle commonly known as the “curb-cut effect” is one of the strongest arguments for building accessibility into H5P content from the start.

The Four Principles Behind Accessible H5P Content

WCAG 2.2 organises accessibility requirements around four core principles, commonly known by the acronym POUR. These principles provide a useful framework for evaluating H5P content because every accessibility issue ultimately falls into one or more of these categories.

1. Perceivable: Information and user interface components must be presented in ways that users can perceive, regardless of the senses they rely on. This includes providing alternative text for images, captions for video and audio content and sufficient colour contrast between text and backgrounds. For example, if an H5P Interactive Video contains spoken instructions, captions ensure that learners who are d/Deaf, hard of hearing or studying in a noisy environment can still access the information.
2. Operable: Users must be able to navigate and interact with content using a variety of input methods, including a keyboard alone. Controls should be accessible without requiring a mouse and any time limits should be adjustable or removable where possible. For example, a learner using only a keyboard should be able to move through an H5P Quiz, select answers and submit responses without becoming trapped in an interactive element.
3. Understandable: Content and interface behaviour should be clear, consistent and predictable. Instructions should be easy to follow, terminology should be familiar and users should understand what is expected of them. For example, in an H5P Drag and Drop activity, learners should receive clear instructions about what needs to be matched and meaningful feedback if they make a mistake.
4. Robust: Content must work reliably across different browsers, devices and assistive technologies, including screen readers, voice control software and switch devices. For example, an H5P Multiple Choice activity should expose questions, answer options and feedback in a way that a screen reader can accurately interpret and announce to the learner.

Consider a simple H5P Interactive Video. Providing captions makes the content Perceivable; ensuring all interactive hotspots can be reached by keyboard makes it Operable; using clear instructions and consistent navigation makes it Understandable; and ensuring the player and interactions work correctly with screen readers makes it Robust.

Every H5P accessibility improvement discussed in this guide maps back to one or more of these four WCAG 2.2 principles, making POUR a useful lens for evaluating and improving the accessibility of your interactive learning content. 

H5P Accessibility Best Practices by Content Type

Here are some examples of commonly used H5P activities and how to improve accessibility

• Course Presentation: Use the built-in heading structure rather than just resizing text. Keep one idea per slide where possible and avoid relying on animation alone to convey meaning, if a sequence matters, state it in text too.
• Interactive Video: Always add captions and provide a transcript alongside the video, not just within it. If you’re layering interactive elements (questions, hotspots) on top of the video, make sure those elements are reachable and operable using keyboard navigation alone, not just mouse clicks.
• Quiz and Question Set: Write feedback that’s specific, not just “incorrect”, screen reader users especially benefit from feedback that explains why an answer was wrong, rather than relying on color or icon changes alone. Avoid auto-advancing through questions on a timer, unless the timer can be paused or extended.:
• Drag and Drop, Drag the Text, Fill in the Blanks: Drag and drop accessibility is one of the hardest problems to solve, because drag interactions don’t translate well to keyboard navigation or switch input. Where H5P offers a keyboard-accessible alternative interaction mode, enable it. Where it doesn’t, consider whether a different content type could test the same skill in a way that’s operable for everyone.
• Accordion and Branching Scenario: Make sure expand/collapse controls are announced correctly by screen readers (this is mostly built-in H5P behavior, but worth testing) and that branching logic doesn’t rely on visual-only cues like color-coded paths.
• Image Hotspots and Visual Content: Every hotspot needs a text label, not just a visual marker. If the image itself conveys information (a diagram, a map, a process flow), that information needs to exist in text form somewhere on the page too. Don’t make the image the only source of meaning.

The following resource, developed by H5P, provides examples of different content types and explains how they support specific accessibility criteria: Content Types Recommendations.

Universal H5P Accessibility Fixes That Apply Across Every Content Type

A handful of fixes apply almost everywhere, regardless of which H5P content type you’re using:

• Write meaningful alt text for every image,  describe its function or content, not just “image1.jpg”.
• Check color contrast, especially for text on coloured backgrounds and any custom theming. A 4.5:1 contrast ratio is the WCAG 2.2 AA minimum for normal text.
• Tab through every piece of content using only your keyboard before publishing. Keyboard navigation is the fastest way to surface H5P accessibility problems, if you can’t reach or operate something without a mouse, neither can a keyboard-only or switch-device user.
• Add captions and transcripts to anything with audio.
• Avoid instructions that depend on color alone (“click the green button”), pair color with text or shape.
• Give users control over timed elements: the ability to pause, extend or disable a timer.

Testing H5P Content for Accessibility

Automated tools, such as WAVE and Chrome’s Lighthouse Accessibility Audit provide a fast and efficient way to identify common accessibility issues. They can quickly detect problems, such as missing alternative text, insufficient colour contrast and unlabeled form controls. While these tools are an excellent starting point, they identify only a subset of accessibility barriers. For example, they cannot determine whether a branching scenario is logical and usable when navigated solely via a keyboard.

To achieve a more comprehensive accessibility evaluation, manual testing is essential:

1. Keyboard accessibility: Navigate the entire content using only the keyboard (Tab, Shift+Tab, Enter and arrow keys) to ensure that all functionality is accessible without a mouse.
2. Screen reader accessibility: Test the content with a screen reader, such as NVDA, Narrator or JAWS on Windows, VoiceOver on macOS/iOS or TalkBack on Android. Screen reader testing often reveals issues that automated accessibility tools cannot detect.
3. User testing with people who use assistive technologies: The most reliable way to validate accessibility is to involve individuals who regularly use assistive technologies. Their lived experience can uncover usability challenges and barriers that neither automated tools, nor simulated testing environments are able to identify.

Common H5P Accessibility Mistakes to Avoid

• Treating accessibility as a final QA step instead of a design constraint from the start.
• Relying on H5P’s defaults, without testing the specific combination of content types you’ve built - accessibility behaviour can vary depending on how content types are nested or combined.
• Adding captions but not transcripts, or vice versa - they serve different needs and both matter.
• Using placeholder or decorative alt text (“photo,” “icon”) that gives screen reader users no useful information.
• Designing branching scenarios or drag-and-drop activities with no keyboard-navigable alternative.

H5P Accessibility Checklist (Quick Pre-Publish Version)

• All images have meaningful alt text.
• Color contrast meets at least 4.5:1 for normal text (WCAG 2.2 AA).
• The entire activity is operable using keyboard navigation alone.
• Audio and video have captions and a transcript.
• No content relies on color alone to convey meaning.
• Timed elements can be paused, extended or disabled.
• Content has been tested for keyboard accessibility and with at least one screen reader.