Develop accessible content with imc Express

We want imc Express to be available to all learners worldwide, including people with disabilities. To achieve this, the issue of accessibility was very important to us when developing imc Express.

Every edition of your learning content is published with a second, accessible rendering alongside the visual one. That rendering is built to meet WCAG 2.2 Level AA. It carries the same information and the same functionality as the visual version, and it is reachable directly from it.

Some requirements, however, are decided by what you write, not by the player. The following guidelines cover exactly those points. If they are not followed, no setting in imc Express can repair the result afterwards.

Guidelines for authors

Say out loud what your videos show

This is the most important one, and the most expensive to get wrong.

Accessibility guidelines ask for an audio description for video – a separate narration of what is visible on screen. That separate track is not needed when the video's own soundtrack already conveys everything the picture shows, because then there is nothing left to describe. This is the route imc Express takes: the platform does not deliver a separate audio description track.

So write the description into your script:

• Instead of "as you can see here", say "the chart shows the share rising from 20 to 60 percent".
• Instead of "click the button shown", say "click the red Continue button at the bottom right".
• When text appears on screen, read it aloud or summarise it.
• When a process is demonstrated without commentary, narrate each step as it happens.

A quick test before a video goes live: play it with the screen switched off. Someone who has not seen it should still be able to follow what happened. If something is missing, it belongs in the script.

Add subtitles to every video with speech

Where your video carries subtitles, the accessible version loads them and offers a labelled control to switch them on and off. Where your content has none, none can be shown – the player cannot invent them.

Subtitles pay off twice: when no separate transcript is written, the accessible version builds the video's text transcript from the subtitle timings. Adding subtitles therefore covers both the caption requirement and the transcript requirement in one step.

Give every meaningful image a caption

The accessible version takes an image's text alternative from its caption. If there is none, it falls back to the title stored with the asset, and if that is empty too, the image is announced as decorative.

That is the correct behaviour for decorative images. But an image that carries information and has neither a caption nor an asset title reaches a screen reader user as nothing at all. If an image says something, give it a caption.

Where an image has labelled hotspots, their descriptions appear as a numbered list below the picture and the markers on the picture itself are hidden from assistive technology. Write those descriptions so that they stand on their own, without the picture.

Start every section with a heading

Headings do more than structure the page. The accessible version takes the document title from the first heading in your content; only when there is none does it fall back to the title of the published edition. Content that opens without a heading therefore reaches the learner with a less specific page title, and a section without one is announced as "Section 2" instead of by its subject.

Keep the heading levels in order, and do not skip from a level 1 to a level 3 just to make something look smaller.

Make link text work on its own

Screen reader users commonly pull up a list of all links on a page, stripped of the sentences around them. "Click here", "more" and "read on" are useless in such a list. Name the destination instead: "Download the safety instructions (PDF)".

Put spoken narration into the text as well

In the accessible version, automatic narration is switched off on purpose – the learner's screen reader provides the voice, and two voices at once help nobody.

The consequence is that anything said only in a voiceover, and written nowhere, is lost in that version. If your narration adds something to the visible text, put it in the transcript field for that element. The accessible version renders a transcript whenever it differs from the visible text, so the addition reaches the learner.

Structure and language

Organise your content carefully and use clear, precise language. This makes the content easier to understand and easier to navigate – for every learner, not only those using assistive technology.

Using accessible content

When using a screen reader, users can navigate to the accessible version of the content using the [Tab] key.

Alternatively, the accessible content can also be accessed as follows:
On the content's start screen, press the [Tab] key and then [Enter].

What the accessible version provides

The accessible rendering is built from semantic HTML rather than from a canvas, which is what makes it available to assistive technology in the first place. In particular it provides:

• a heading structure and page landmarks, so that assistive technology can skip repeated content and jump between sections;
• a text alternative for every image, and a text transcript alongside every video;
• subtitles with a labelled control wherever the content provides them;
• video controls that are fully operable by keyboard, including seeking and volume;
• a name for every control, so that nothing is announced as just "button";
• spoken announcements for things that change on their own, such as quiz feedback or a section becoming available;
• a visible focus indicator throughout, and a reading position that follows the learner's actions instead of jumping back to the top of the page.

What does ARIA mean?

ARIA stands for Accessible Rich Internet Applications. It is a set of HTML attributes developed to improve the accessibility of interactive web content and applications. These attributes provide additional information to assistive technologies such as screen readers to enable a better user experience for people with disabilities.

We use ARIA where standard HTML elements are not sufficient on their own – for example to announce a change that happens without the learner doing anything. Where a standard element already carries the right meaning, we use that element rather than describing it with ARIA, because native elements behave correctly in more situations.

Conformance with WCAG 2.2 AA

The Web Content Accessibility Guidelines define how digital content has to be designed so that it is accessible to all users. We evaluate the accessible rendering of our learning content against WCAG 2.2 Level AA, which covers 56 individual success criteria grouped under four principles.

Perceivable

Content is designed to be recognisable: sufficient colour contrast, text alternatives for non-text content, captions and transcripts for media, and a structure that can be read with a screen reader or another assistive technology.

Operable

Every function can be reached and used without a mouse. Controls are standard, keyboard-operable elements, the focus order follows the content, and the focus indicator is visible at all times.

Understandable

The page declares its language, so that a screen reader pronounces it correctly. Controls behave consistently, feedback is given in words rather than by colour alone, and where the content makes an element available only after a delay, that is explained rather than left to guesswork.

Robust

The accessible rendering is built from valid, semantic HTML with unique identifiers and correct names, roles and values, so that it works across browsers, devices and assistive technologies rather than with one specific combination.

How we verify conformance

Automated testing alone cannot establish accessibility. Depending on the study, automated tools detect between a third and a half of all accessibility barriers – they can find a missing alternative text, but not whether the text is meaningful. We therefore combine four methods:

1. Automated testing of the published output with axe-core, covering the WCAG 2.0, 2.1 and 2.2 rule sets.
2. Manual code review of the renderer and the shared interface components.
3. Manual inspection of the rendered result: how names are computed, how headings are structured, where the focus goes.
4. Screen reader testing by an external tester, whose findings are recorded and remediated.

The last two are the decisive ones. In our own audit, automated testing reported almost no violations on content that nevertheless contained a Level A failure: a set of quiz options whose labels pointed at elements that did not exist, leaving them without any name for a screen reader. Only a manual check found it.

Conformance report

Our Accessibility Conformance Report (VPAT® 2.5) documents the result for each of the 56 success criteria of WCAG 2.2 Level A and AA, together with the evaluation methods and the remediations carried out. It covers the accessible rendering of the learner-facing content.

Accessibility Conformance Report – WCAG 2.2 AA (PDF)