Accessibilité

Accessibilité

إمكانية الولوج

L'accessibilité n'est pas une option ajoutée en fin de projet : c'est une propriété du système, vérifiée à chaque composant. DSM vise la conformité WCAG 2.2 niveau AA, dans le cadre réglementaire national et des normes internationales applicables aux services publics numériques.

Engagement

WCAG 2.2 — Niveau AAAudit externe : à venirCadre réglementaire nationalNormes internationales

Les administrations qui construisent leurs services numériques avec DSM héritent d'un socle conçu pour les exigences WCAG 2.2 AA : jetons de contraste mesurés (≥ 4,5:1 pour tout texte sur son fond prévu), primitives accessibles, clavier et lecteurs d'écran pris en charge. Aucun audit externe du système n'a encore été réalisé, et cette base technique ne dispense pas chaque équipe de vérifier son propre contenu et ses propres parcours : voir « Ce que les équipes doivent encore faire ».

Ce que le système garantit

Des propriétés vérifiées une fois, au niveau des fondations et des composants, et qui s'appliquent à toute page construite avec DSM.

  • Contraste

    Tous les jetons de texte sur leur fond prévu atteignent AA (4,5:1 pour le texte courant, 3:1 pour le grand texte), en clair comme en sombre.

  • Focus visible

    Un anneau de focus global (:focus-visible) est appliqué à tout élément interactif ; aucun composant ne retire l'outline sans le remplacer.

  • Navigation clavier

    Menus, dialogues, onglets et accordéons sont pilotés par Base UI : flèches, Échap, Tab et piège de focus fonctionnent nativement.

  • Sémantique

    Les primitives interactives (dialogue, infobulle, onglets, accordéon, sélecteur, menu, interrupteur, case, bouton radio, message, popover) portent les rôles et états ARIA corrects par construction.

  • Mouvement réduit

    prefers-reduced-motion est respecté globalement : aucune configuration à faire par page ou par composant.

  • Liens d'évitement

    Trois liens d'évitement (contenu, menu, pied de page) sont générés par le composant d'en-tête et ciblent des ancres réelles.

  • Attributs de langue

    Chaque bloc multilingue porte lang et, si besoin, dir : lecteurs d'écran et correcteurs changent de langue automatiquement.

Ce que les équipes doivent encore faire

Le système ne peut pas deviner le contenu : ces points restent sous la responsabilité de chaque équipe produit.

  • Textes alternatifs

    Chaque image porteuse de sens reçoit un alt descriptif ; les images décoratives reçoivent alt="" et aria-hidden.

  • Ordre des titres

    Un seul h1 par page, puis une hiérarchie continue (h2, h3…) sans saut de niveau, y compris dans le contenu éditorial.

  • Étiquetage des formulaires

    Chaque champ a un label visible et associé (pas un simple placeholder), une aide avant le champ et une erreur après, reliée par aria-describedby.

  • Messages d'erreur

    Un message d'erreur nomme le champ concerné et la correction attendue ; il est annoncé (role="alert") et reste visible jusqu'à correction.

  • Tests avec lecteur d'écran

    Chaque parcours critique (démarche, formulaire, recherche) est testé au clavier et avec au moins un lecteur d'écran avant mise en production.

Grille de relecture d'une page

  • Un seul h1, hiérarchie de titres sans saut de niveau.
  • Tous les contrôles atteignables et utilisables au clavier, dans un ordre logique.
  • Chaque image porteuse de sens a un texte alternatif ; les décoratives sont masquées.
  • Chaque champ de formulaire a un label visible, une aide et, le cas échéant, une erreur reliés par aria-describedby.
  • Les couleurs ne sont jamais le seul vecteur d'information (icône ou texte en renfort).
  • Le focus reste visible sur tout élément interactif, y compris personnalisé.
  • La page reste utilisable et lisible en zoom 200 % et à 320px de large.
  • Le contenu et les composants fonctionnent en dir="rtl" sans régression visuelle.
  • Les messages de statut et d'erreur sont annoncés (role="status" ou "alert").
  • Testée avec au moins un lecteur d'écran (NVDA, VoiceOver ou TalkBack) sur le parcours principal.

Modèle de déclaration d'accessibilité

Un gabarit à adapter par chaque administration : remplacez les champs entre crochets par les informations réelles du service et de l'audit réalisé.

<h1>Déclaration d'accessibilité</h1>

<p>[Nom de l'organisme] s'engage à rendre [nom du site ou du service] accessible conformément
au référentiel [référentiel applicable, ex. RGAA / WCAG 2.2 AA].</p>

<h2>État de conformité</h2>
<p>[Nom du site] est en conformité [totale / partielle / non conforme] avec [référentiel applicable].</p>

<h2>Résultats des tests</h2>
<p>L'audit de conformité réalisé par [nom de l'auditeur ou de l'organisme] le [date] révèle que
[pourcentage] des critères du référentiel sont respectés.</p>

<h2>Contenus non accessibles</h2>
<ul>
  <li>[Description du contenu concerné] — [raison : dérogation pour charge disproportionnée, contenu tiers, etc.]</li>
</ul>

<h2>Établissement de cette déclaration</h2>
<p>Cette déclaration a été établie le [date]. Elle a été mise à jour le [date de mise à jour].</p>

<h2>Retour d'information et contact</h2>
<p>Si vous rencontrez un défaut d'accessibilité vous empêchant d'accéder à un contenu ou à une
fonctionnalité, contactez [nom du responsable ou du service] : [adresse e-mail], [numéro de téléphone].</p>

<h2>Voies de recours</h2>
<p>Si vous constatez un défaut d'accessibilité vous empêchant d'accéder à un contenu et que vous n'obtenez
pas de réponse satisfaisante, vous pouvez adresser une réclamation à [autorité ou instance compétente].</p>