E-learning Componants

Getting Started 

We have organized the information by component :

Each component includes

• Best practices for using the component in Articulate Storyline. 
• Accessibility guidelines. 
• Keyboard interactions (tab order, navigation, and activation). 

Project settings, to be fixed before any production work

• An explicit course title: it becomes the title of the published output and the first thing announced when the module opens. 
• Project language and player labels consistent with the language of the content. A French-language module published with an English-language player is non-compliant, and Storyline provides no way to flag a language change on a portion of text: plan for a case-by-case treatment (see the Quotations tab). 
• A unique, explicit title for every slide: it feeds the player menu and serves as a landmark for screen reader output (see the Headings tab). 

Templates and reading order

• Focus order explicitly defined on every slide and every layer ("Focus Order" panel, Home ribbon), including for reused templates. 
• Decorative elements (backgrounds, frames, rules, ambience icons) systematically removed from both the on-screen output and the focus order. 
• A structural point of caution: focus order is static. It is designed slide by slide and cannot be changed at runtime by a trigger; nor is there any action that moves focus to a given object. The expected behavior when a layer opens and closes must therefore be tested, not assumed. 
• Controlled motion: no uncontrollable looping animation, no flashing, short and understated transitions. 

Publishing and the LMS environment

• Published in web format, with the modern player: the module is delivered through the Articulate player, and learners access it from a web page in their browser. Accessibility checks must therefore always be carried out on this published page, never on the source file. 
• Tested in a real LMS environment and in the browser learners actually use: session resume, score reporting, and external resources opening in a new window so the session is not interrupted. 
• Re-checked after every authoring-tool version upgrade and after republishing an older project: the player and the semantic structure of the published page can change from one version to the next, with no guarantee of equivalence. 

Accessibility Note — Scope of the Score 

The accessibility score reported for a module built from this design system is provided strictly for guidance. It measures how well the recommendations in this document have been applied, not compliance with a regulatory standard. It is neither an audit result nor a sufficient basis for publishing an accessibility statement. 

Why the score is indicative

• An e-learning module is not a website. Only the subset of RGAA criteria that can be transposed to a module published as a web page is assessed: text alternatives for images, colors and contrast, time-based media, structuring and presentation of information, links, input controls, keyboard navigation. 
• Criteria that apply only to a website are excluded: they concern mechanisms the module does not have (navigation between a site's pages, sitemap, search engine, template consistency across pages, mandatory elements of the page produced by the player, frames). Excluding them is a scoping decision, not compliance already achieved. 
• Part of the published output is beyond the designer's control: it is produced by the Storyline player. Some requirements therefore cannot be fixed at module level and should be flagged as tool limitations, not production defects.
• The score calculation is comparable only from one module to another within this same scope. It cannot be compared to a website's RGAA compliance rate, nor cited as evidence to a third party. 

Standard used

• Today, no official standard specifically addresses the accessibility of e-learning modules. We have therefore built our own test grid, drawing on three recognized standards. 
• RGAA, in France, serves as our foundation: it is the source of our test method and of how we phrase our criteria. 
• RAWeb, in Luxembourg, applies to modules distributed in that country. Since it follows the same structure as RGAA, we move between the two standards without changing our test method. 
• WCAG underpins both of the standards above. We refer to it whenever a situation is not covered by them, particularly for interactive components specific to e-learning. 
• We have kept only the criteria that make sense for a module published with Articulate Storyline or with Rise when Rise supplies the course player. This grid remains a working tool, and it is not set in stone: it does not replace an official standard, it does not allow a compliance claim to be made, and it evolves along with tools, usage, and standards. Whether you are a designer, a trainer, a learner, or an accessibility specialist, your comments, corrections, and feedback are valuable to us: write to us at [email protected].

What the score does not cover

• The host LMS platform, its SCORM player (Sharable Content Object Reference Model: the exchange standard that lets the module communicate with the platform, in particular progress and scores), its catalog, and its learning paths: these fall under a separate audit scope. 
• Documents and downloadable resources associated with the module (PDFs, handouts, job aids): these are assessed separately. 
• Embedded third-party content (web objects, hosted videos, iframes) and the quality of external resources linked to. 
• Determining the legal framework that applies to the program. Depending on the country of deployment and the nature of the organization, this framework differs, and so do the documentation obligations that come with it: this point must be clarified with the accessibility team before any public communication of a result, and compliance of a digital service is then demonstrated by an accessibility statement backed by an audit report, not by a score. 

Questions? 

Contact us at [email protected].