Detected country: US
logo
Back to creating
‌
‌
‌
logo

Powered by

  • Home
  • Partners
  • Accessibility guide

Accessibility guide

8min read

Share

How do I support accessibility as an Embed partner?

Which accessibility claims Coassemble can make, what your implementation is responsible for, and the practices to pass on to your course creators.

Accessibility is central to creating meaningful and inclusive learning experiences. As an Embed partner, you play an essential role in how accessibility principles are put into practice, both in the way you implement Coassemble's course creation tools within your platform and in how you guide your customers to use them.

What Coassemble can claim

The Classic learner experience has been independently verified as conforming to WCAG 2.2 Level AA by digital accessibility specialists Modality Co, who awarded Coassemble a Statement of Conformance.

The course builder's rebuilt learner view has not yet been independently verified. Coassemble's own accessibility testing shows that the course builder learner experience meets WCAG 2.2 Level AA. When you're responding to a customer requirement that depends on independent third-party verification, the Statement of Conformance applies to the Classic learner experience only.

Accessibility is a shared responsibility. Coassemble provides an accessible foundation for the learner experience, but accessible outcomes also depend on partner implementation decisions and course creators following best practices.

Shared responsibility: Coassemble, you, and your users

  • Coassemble: Provides the underlying course creation tools, designed with WCAG principles in mind.
  • You (Embed partner): Your implementation decisions (e.g. navigation, shell UI, theme overrides) directly impact accessibility outcomes.
  • Your users (course creators): They must apply accessibility best practices when building courses (e.g. adding alt text, maintaining contrast, structuring screens carefully).

A note on Screen Player. Where you use Screen Player to render a single Coassemble screen inside your own application, the page around that screen is yours. Coassemble's accessibility work covers the screen itself, while the heading structure, navigation and keyboard focus of the surrounding page sit with your implementation, so test the two together rather than assuming the screen carries the whole page.

Key accessibility practices for course creators

1) Add alternative text (alt text) for images

Images can bring content to life, but for learners who use screen readers those visuals need to be described in text form. Alt text provides a written description of an image so learners who cannot see it can still understand its purpose and meaning. Without alt text, a screen reader may skip the image or read out the file name, creating a poor learning experience.

Best practices:

  • Be clear and concise: Keep alt text under 125 characters so it can be quickly read by screen readers.
  • Describe the purpose, not just the appearance: Instead of saying "a chart," write "bar chart showing sales growth over three years."
  • Avoid unnecessary phrases: Don't start with "image of" or "picture of". Screen readers already announce that it's an image.
  • Include essential text: If the image contains text that isn't repeated elsewhere, include it in the alt text.
  • Leave decorative images blank: Don't add alt text for purely decorative images so screen readers can skip them.
  • Test for context: Ask, "If this image were removed, would learners still get the same information?" If not, the missing context belongs in the alt text.

2) Ensure high contrast and legible text

Colour and contrast play a critical role in making digital content readable for everyone. Learners with low vision or colour blindness may struggle to read text if it doesn't stand out clearly against its background.

Best practices:

  • Start with defaults: Coassemble themes are built with sufficient contrast, so encourage customers to use presets wherever possible.
  • Check custom colours: If they override default theme colours, they must manually check the contrast between text and background to ensure it follows WCAG guidance.
  • Check custom fonts: In the course builder, a creator can set a font on an individual heading or paragraph, outside the theme set. A font chosen this way carries the same readability risk as an overridden theme colour, so check the text is still easy to read at the size it appears, and use the reset to theme font option where it isn't.
  • Use reliable tools: Free resources like WebAIM's Contrast Checker help confirm compliance quickly.

3) Give every screen real structure

Assistive technology relies on the underlying structure of a screen, not its visual arrangement.

  • Use a heading block for the screen title. A heading gives assistive technology what it needs to navigate. A screen carrying real body text with no heading is harder to navigate and is something the course review flags.
  • Use list-shaped blocks for list content. Checklists, accordions, and process blocks carry real structure. Bullets typed into a paragraph only look like a list.
  • Use the table block for tabular data, which gives the table a proper header row.
  • Set the reading order. In the course builder, creators can set the order blocks are read in by screen readers, narration, and keyboard navigation. This matters whenever the visual arrangement doesn't match the order things should be read, for example when two blocks sit side by side.
  • Check what the mobile layout hides. In the course builder, creators can reorder blocks for mobile, or hide a block from mobile entirely. A block hidden from mobile isn't there at all for anyone learning on a phone, so keep anything a learner needs visible, or make sure the same information is carried by a block that stays.

4) Choose accessible content types

Different content types interact with assistive technologies differently.

  • Standard blocks and layouts: In the course builder, every screen starts from a layout, a pre-arranged set of blocks that can be swapped afterwards. The standard blocks and the layouts built from them are compatible with screen readers and can be used confidently.
  • Hotspots: Hotspots place interactive labels on images, which may not always be interpreted clearly by screen readers. If critical information sits in a hotspot, ensure it's also provided in text elsewhere. This applies both to the Hotspot block in the course builder and to Hotspot screens in Classic courses. The block supports reading order, so you can set the order pins are read out independently of where they sit on the image.
  • Embedded third-party content: The embed block allows third-party content such as videos and interactive tools. Accessibility varies widely across third-party providers, so customers must check each tool for compatibility with assistive technologies before embedding.
  • Provide alternatives: If a particular content type or embedded tool cannot be made accessible, offer the same information in an alternative format, such as a text summary or downloadable file.

5) Ensure video and audio content has captions

Video content is a powerful way to engage learners, but it also needs to be accessible. Learners may rely on captions to access video-based learning.

How to support captioning:

  • AI narration generates captions automatically. Where a creator generates narration from screen text, closed captions are produced with it and can be reviewed and edited before publishing. Captions play in sync with the narration during delivery.
  • Video uploaded directly to Coassemble is not captioned automatically, but it does take a caption file. In the course builder, a creator adds captions to an uploaded video by opening the Video menu, choosing Captions, picking the language the captions are in, and uploading an SRT or WebVTT file. Coassemble does not generate captions for uploaded video, so the caption file has to come from the customer.
  • Video hosted on YouTube or Vimeo can carry captions from those platforms, so use their built-in captioning tools and embed the captioned version.
  • Always enable captions for any instructional video.
  • Keep captions synchronised with the video, and make sure they convey spoken content accurately, including important sounds such as "[applause]" or "[music]".
  • Consider providing transcripts for video and audio content.

6) Avoid placing text inside images

Text embedded inside an image, for example screenshots of slides, infographics, or banners with text, typically isn't detectable by screen readers.

Best practices:

  • Avoid uploading images that contain large blocks of text.
  • Place text directly in the course content where assistive technology can read it.
  • If using an image with essential text, such as a chart or labelled diagram, provide that text in the alt text or as a supporting description alongside the image.

Using the course review as an accessibility check

The Review tab in the agent panel, which is the review known as Course Coach, checks a finished course and flags accessibility problems specifically, including images and slideshow slides with no alt text, link text that doesn't say where it goes (such as "click here" or a bare URL), and screens carrying real body text with no heading.

Two things make it useful as a check rather than a suggestion box:

  • Accessibility findings are objective checks, so they're the ones the review can state with certainty. When it marks something as needing correction, it can be fixed without second-guessing.
  • Most findings come with a one-click fix, and objective checks are re-run afterwards so a finding is only marked resolved once the problem has actually gone.

The review doesn't check whether a video has captions on it, so that stays a manual step for the creator, and it doesn't replace testing with assistive technology. It's available on all current plans, but not on the legacy Flow and Hub plans.

Answering customer accessibility questions

Keep the two claims separate, because the difference matters in a procurement response.

  • For the Classic learner experience, cite the Statement of Conformance, independently verified by Modality Co and available via the Coassemble Trust Centre at https://trust.coassemble.com/.
  • For courses built in the course builder, describe Coassemble's own accessibility testing rather than citing the Statement of Conformance, because the independent assessment didn't cover the rebuilt learner view.

If you're unsure how to word a response to a specific customer requirement, email vip@coassemble.com before you send it.

How Embed partners can support customers

  • Educate customers on accessibility best practices.
  • Highlight how implementation decisions (UI, colour schemes, navigation) impact accessibility.
  • Provide resources such as WCAG guidance and accessibility testing tools.
  • Encourage testing with assistive technologies before course launch.

Summary

The Classic learner experience has been independently verified for WCAG 2.2 Level AA conformance. The course builder learner experience meets WCAG 2.2 Level AA in Coassemble's own testing and has not yet been independently verified. Accessible outcomes depend on shared responsibility across Coassemble, Embed partners, and course creators. By following the practices above (alt text, contrast, real screen structure and reading order, accessible content choices, captions, and avoiding text-in-images) you can help deliver inclusive learning experiences for all learners.

Share