Déclaration d’accessibilité

• HTML sémantique. De vrais titres, des repères et des listes. Exactement un h1 par page, vérifié automatiquement sur chaque page aux deux largeurs.
• Un lien d’évitement vers le contenu principal, premier élément focalisable de chaque page.
• Des alternatives textuelles. Chaque image porte un attribut alt ; la suite de tests fait échouer la construction si l’une n’en a pas. Les dessins décoratifs sont marqués comme décoratifs, de sorte qu’un lecteur d’écran passe outre.
• Le mouvement réduit est respecté. Toute animation de ce site — le soleil qui se lève, les compteurs, les illustrations qui se tracent, les coups de surligneur, les enregistrements du produit — est désactivée sous prefers-reduced-motion, et la suite de tests vérifie que rien n’a bougé et qu’aucune vidéo ne joue ni ne porte encore un attribut d’autoplay.
• Rien ne dépend de JavaScript. Scripts bloqués, les dessins sont déjà tracés et les chiffres sont déjà à leur valeur finale. Il n’existe aucun état où un lecteur se retrouve devant une boîte vide.
• Pas de défilement horizontal à aucune largeur jusqu’à 390 px, vérifié sur chaque page. Le texte se reflue ; les tableaux larges défilent dans leur propre boîte plutôt que de déplacer la page.
• Focus visible. Un anneau de focus clavier dans le teal du site, sur tout ce qui est focalisable, jamais retiré.
• Contraste. Le texte courant est presque noir sur blanc. Là où le registre demandait un gris plus clair, il a été refusé pour le texte et gardé pour les filets et les marques qui ne portent aucun sens.
• La langue est déclarée sur chaque page, et chaque traduction déclare la sienne ; le sélecteur de langue marque la langue courante.
• Aucun son en lecture automatique. Les enregistrements du produit sont muets, ne démarrent pas avant d’être délibérément à l’écran, et ne démarrent pas du tout sous mouvement réduit.

• Des grilles qui se mènent d’abord au clavier. Les grilles pivot et les grilles de liste se conduisent au clavier — flèches, Entrée, Tab, copier, coller, recopier vers le bas — parce que c’est ainsi que travaillent les planificateurs, et cela se trouve être aussi ce dont les technologies d’assistance ont besoin.
• Les refus s’énoncent, ils ne se colorent pas. Quand une écriture est refusée, la raison est une phrase qui nomme la cellule et la règle. La couleur est un second signal, jamais le seul.
• Le linting d’accessibilité dans la construction. Le linter de l’application inclut les règles d’accessibilité JSX, et la construction échoue sur une erreur de lint.
• Les constructeurs prennent le cadre, jamais une modale, ce qui veut dire que le focus se trouve là où un utilisateur au clavier est allé plutôt que là où on l’a jeté.

Lacunes connues dans le produit. Une grande grille virtualisée est difficile à rendre lisible dans un lecteur d’écran, et nous n’avons pas résolu cela. Les graphiques n’ont pas encore d’équivalent en table de données. L’application n’a pas été testée de bout en bout avec un lecteur d’écran, et il n’existe pas de VPAT. Si vous utilisez une technologie d’assistance et voulez planifier avec Superiora, écrivez-nous — c’est une conversation que nous voulons, et elle changera la feuille de route.