Questions answered by this guide
- Does my course stay accessible after it is translated?
- What accessibility problems does localization introduce?
- Do I need to set the language again for a translated course?
- Why are my screen-reader labels still in English after translating?
- Does A11yCheck check accessibility when it compares a localized course to the source?
What you'll learn
- The source-language accessibility sign-off does not carry over to a translated version
- Run a full, separate Accessibility review on each language version's URL
- The clearest regression is the course language setting: screen readers use it to choose pronunciation rules
- Accessible names, alt text, and instructional text can be left in the source language even when the visible content is translated
- Expanded translated text can reflow a layout and change reading or focus order
What's inside
Instructional designers and accessibility reviewers releasing a course in more than one language
- 01Why accessibility does not carry over
- 02Language metadata
- 03Untranslated accessible text
- 04Right-to-left languages
- 05Font fallback
- 06Reflow and focus order
- 07What to re-check
Why it matters
Accessibility conformance is specific to what a learner actually experiences. A translated course is a different experience: different text length, sometimes a different reading direction, sometimes a different script, and often different metadata. WCAG 3.1.1 (Language of Page) exists so a screen reader can apply the right pronunciation and speech rules; if the translated version does not declare its language, the screen reader may read French or Japanese content with English pronunciation. Accessible names and alt text that were not part of the translated content export stay in the source language, so a screen-reader user hears a mix. Expanded text can push a layout out of shape and change the order things are read in. None of this is visible in the source-language review.
When you'll encounter this
- A course that passed accessibility review is being released in additional languages.
- A screen-reader user reports that the translated version announces some elements in the wrong language.
- A right-to-left version (Arabic, Hebrew) has been produced from a left-to-right source.
- The translated version uses a script the course's brand font does not cover.
Examples
Language metadata
✕ Incorrect
The Spanish version of the course does not declare its language. A screen reader keeps its English voice and pronunciation, so "seguridad" is read with English phonetics.
WCAG 3.1.1 requires the page's human language to be programmatically set. Without it, assistive technology falls back to its own default, usually the user's OS language, which is wrong for this content.
✓ Correct
The Spanish version declares Spanish as its language, so the screen reader switches to a Spanish voice and pronunciation for the whole course.
With the language set, the screen reader reads the content the way a Spanish speaker expects, and any per-part language markup (WCAG 3.1.2) handles the exceptions.
Untranslated accessible name
✕ Incorrect
A button's visible label reads "Weiter" but its accessible name is still "Next." A screen-reader user hears "Next, button" on a German course.
The accessible name was set as a separate field (an alt text, a Storyline accessible-name entry, an ARIA label) that was not included in the translated content and was never updated.
✓ Correct
The accessible name is updated to "Weiter" so it matches the visible label and the rest of the course's language.
The accessible name should match the visible label (WCAG 2.5.3, Label in Name) and be in the same language as the content the learner is reading.
Best practices
- After every localization, run a full A11yCheck Accessibility review on that language version's published URL. Do not assume the source-language result applies.
- Confirm the course language is set for each version. In Storyline this is the project's language setting; in Rise it follows the course's language. Screen readers depend on it.
- Check accessible names, alt text, and instructional or hint text specifically, these are separate fields that are easy to leave in the source language.
- For right-to-left languages, verify the layout mirrors and that Tab order follows the visual reading order, not the original left-to-right order.
- Confirm the font used for the target script is embedded and readable, a fallback system font can be lower contrast, differently sized, or missing characters.
- Re-check reading order and focus order on any screen where translated text expanded enough to reflow the layout.
Common mistakes
- Treating the source-language accessibility pass as covering every translated version.
- Leaving the course language set to the source language, or unset, on translated versions.
- Translating visible text but not the accessible names, alt text, and instructional text stored in separate fields.
- Producing a right-to-left version without checking that focus order was mirrored too.
- Assuming A11yCheck's Localization comparison also re-runs accessibility checks, it does not.
Practical checklist
- A full Accessibility review has been run on this language version's URL.
- The course language is set correctly for this version.
- Accessible names match the visible (translated) labels.
- Alt text and instructional text are in the target language.
- For RTL languages, layout mirrors and Tab order follows the visual order.
- The target-script font is embedded, and text is readable at the intended size and contrast.
- Reading and focus order still make sense on any screen where text expanded.
How A11yCheck reviews this
A11yCheck's Accessibility review, run on a translated course's URL, checks that course the same way it checks any course, including whether the course language is identified (it flags a missing course language as a Medium issue), accessible names, alt text, heading and reading structure, keyboard operability, and contrast. Run it separately on each language version. A11yCheck's Localization review is a different thing: it compares the source and target rendered courses on 10 mechanical checks (text overflow, missing slides, untranslated text, and so on) and does not re-run any Accessibility, Course Quality, or Course Engagement check. A11yCheck does not run a screen reader, so whether a translated accessible name sounds right in the target language, and whether a mirrored RTL layout reads naturally, still need a manual check with assistive technology.
Frequently asked questions
If my English course is accessible, is the translated version automatically accessible too?
No. Accessibility depends on what the learner actually experiences, and a translated version has different text, sometimes a different script or reading direction, and often different metadata. Re-run a full Accessibility review on each language version.
Why does my translated course announce elements in the wrong language?
Two common causes. The course's language setting is missing or still set to the source language, so the screen reader does not switch voices (WCAG 3.1.1). Or an accessible name, alt text, or ARIA label was set as a separate field that the translation did not touch, so it is still in the source language.
Does A11yCheck check accessibility when it compares my localized course to the source?
No. The Localization comparison is only the 10 mechanical source-vs-target checks. Accessibility is a separate A11yCheck review. Run it on each language version's URL.
What is different about right-to-left languages?
The layout has to mirror, and the focus order has to mirror with it. A common regression is a course that looks correctly mirrored but still Tabs through elements in the original left-to-right order, so keyboard and visual order disagree. This needs a manual keyboard pass.
Related Guides
Localization QA for eLearning: What to Check in a Translated Course→
Localization QA is checking that the translated version of a course still works the way the source does, structurally, visually, and for assistive technology, not judging whether the wording is good. Here is what to review source-vs-target, and which of those checks A11yCheck runs automatically.
Localization QA Checklist: Reviewing a Translated Course Before You Publish→
A pre-publish pass for a course that has been translated, run per language version. It is split into the mechanical checks A11yCheck compares automatically between source and target, and the checks that still need a human.
Accessible Names Guide→
What an accessible name is, why "Click here" fails, and how to write clear names for buttons and controls in Storyline and Rise.
Focus Order Guide→
Focus order is the order Tab moves through a slide's interactive elements. It should match the order things appear on screen, and it's checked by pressing Tab and watching where focus lands each time.
WCAG for eLearning: A Practical Introduction→
What WCAG actually is, and what it means for a Storyline or Rise course. No legal jargon.
How to Test eLearning with a Screen Reader→
A practical, no-fear guide to testing your own course with a screen reader, from your first NVDA install to knowing exactly what you're listening for.
Summary
Localization can introduce accessibility problems that did not exist in the source: a missing or wrong course language setting, accessible names and alt text left in the source language, un-mirrored focus order in right-to-left versions, silent font fallback, and reading-order changes from reflowed text. Run a full, separate A11yCheck Accessibility review on each language version, the Localization comparison does not cover accessibility.
Review your course before you publish it.
A11yCheck reviews Storyline and Rise courses for:
- Accessibility
- Course Quality
- Course Engagement
www.a11ycheck-dev.com