Commitment

Accessibility

We aim for WCAG 2.2 Level AA. This page states what is verified, how, and what is not yet verified.

Last updated: September 15, 2026

This English translation is provided for convenience only. The French version prevails.

What is verified automatically, with every change

  • No serious or critical violation detected by axe-core. The scan covers every fixed-address page of both sites and every screen of the personal space; for pages generated from the database — article, chapter, learning path page — one instance of each template, as well as the error pages. A test reads the code and fails if a fixed-address page is not scanned: this part of the coverage cannot become outdated without our knowing it. Pages generated from the database, on the other hand, are covered template by template, and that list is maintained by hand. This is a blocking condition of our integration pipeline: a regression prevents deployment to production. The administration interface, which is not intended for the public, is excluded.
  • Contrast of the interface’s text/background pairs, recalculated from the design token file rather than copied by hand. A modified token that would fall below the threshold causes the build to fail.
  • A complete journey using the keyboard alone, from the home page to reading a training chapter.
  • Compliance with the “reduced motion” system preference.
  • Layout and functionality preserved at 200% zoom.

What automation does not detect

Automated tools detect about one third of real barriers. The rest requires human review: relevance of text alternatives, reading order, consistency of link labels heard out of context.

We go further than detecting violations: the accessibility tree — roles, announced names, heading levels in reading order, that is, the very source of what a screen reader conveys — is recorded and compared with every change, for the page shell (header, footer, sign-in form) and for the heading structure of a sample of pages. Within this scope, a lost name or a missing landmark blocks deployment to production. The body of the pages, by contrast, changes with every editorial publication: we do not record it, since a snapshot regenerated without being read would protect no one.

Screen reader listening tests have not yet been carried out.

What a machine cannot judge — the timing of an announcement, the clarity of a label heard out of context, whether the reading order makes sense — requires actual listening. The protocol is written and the session is scheduled before going live; it has not taken place to date, and we prefer to say so rather than suggest otherwise.

Nor do we claim to have had an accessibility audit carried out by a third-party organization: we have not.

Known limitations

  • Training chapters are text: the learning path currently contains no video or audio content. There are therefore no captions or transcripts to provide, and we do not claim otherwise.
  • The administration interface relies on a third-party component whose accessibility we do not fully control. It is not intended for the public.

Reporting a barrier to us

If a page prevents you from accessing information or a feature, write to contact@stratest.fr. Describe the barrier and, if you can, the tool you are using. We respond within five business days and tell you how long the fix will take.