Déclaration d’accessibilité
Alcometer.org s’engage à rendre son calculateur d’alcoolémie, ses pages sur la gueule de bois, la chronologie de récupération et l’hydratation accessibles au plus grand nombre, y compris aux personnes présentant des différences visuelles, motrices, auditives, cognitives ou neurologiques.
Objectif de conformité
Notre objectif est de respecter les Web Content Accessibility Guidelines (WCAG) version 2.2 au niveau AA, publiées par le W3C. Cet objectif s’inscrit dans le cadre de la norme EN 301 549 et de l’European Accessibility Act (EAA), avec WCAG 2.1 AA comme socle minimal de compatibilité.
Le dépôt exécute une base de tests axe-core avec Puppeteer sur les principales pages Alcometer. Les corrections d’accessibilité sont suivies de manière à éviter toute régression avant le passage en gate bloquant.
Les limites connues sont documentées ci-dessous et font l’objet d’une remédiation progressive.
Couverture actuelle des tests automatisés
Le dépôt exécute npm run test:alcometer:a11y : le site est construit, Astro preview est lancé, axe-core est injecté via @axe-core/puppeteer et les règles wcag2aa / wcag22aa sont contrôlées.
Le rapport le plus récent est écrit dans reports/a11y-run.json et la base de référence se trouve dans test/a11y-baseline.json.
Les outils automatisés servent à détecter les régressions ; ils ne remplacent pas une revue humaine complète de l’expérience.
Conséquences pratiques
• Les contrôles interactifs doivent utiliser des éléments HTML natifs lorsque c’est possible, avec un focus visible et une utilisation au clavier.
• Les graphiques SVG ou assimilés doivent proposer une alternative textuelle ou tabulaire lorsque l’information dépend du visuel.
• Les dialogues doivent conserver un ordre de focus cohérent et fournir une sortie explicite.
• La langue du document est déclarée sur chaque page générée avec l’attribut <html lang>.
Limites connues
Certaines visualisations de données incluent déjà des tableaux réservés aux lecteurs d’écran, mais les libellés de graphiques et la parité entre langues restent soumis à une revue manuelle.
Les langues de droite à gauche ne disposent pas encore d’une mise en page RTL dédiée ; elles utilisent l’enveloppe LTR disponible lorsque c’est applicable.
Les tests automatisés peuvent détecter des problèmes de contraste ou de sémantique, mais pas toute la charge cognitive d’une page.
Méthode de test
• Automatisé : axe-core via @axe-core/puppeteer sur Astro preview, limité aux règles wcag2aa et wcag22aa.
• Rapport de régression : reports/a11y-run.json.
• Base figée : test/a11y-baseline.json.
• Une revue manuelle reste nécessaire pour le clavier, les lecteurs d’écran, la clarté cognitive, le zoom et les régressions visuelles.
Les outils automatisés ne couvrent qu’une partie de la conformité WCAG. Une revue humaine est nécessaire avant lancement, en particulier pour le calculateur, la barrière de conformité et les pages avec graphiques.
Retour et contact
Si vous rencontrez une barrière d’accessibilité — texte alternatif manquant, piège clavier, contraste insuffisant, ordre de focus peu clair ou tout autre problème — veuillez nous contacter.
E-mail : alcometer@wp.pl
Adresse postale : Piotr Zieminski, Kalonka 71a, Pologne
Merci d’indiquer : (1) l’URL concernée, (2) une brève description de la barrière, (3) votre configuration d’assistance technique si elle est pertinente.
Voie de recours
Si notre réponse ne vous satisfait pas, vous pouvez saisir l’autorité nationale compétente au titre de l’European Accessibility Act. En Pologne, il s’agit de l’Urząd Komunikacji Elektronicznej (UKE, https://www.uke.gov.pl/).
Préparation de cette déclaration
Cette déclaration a été mise à jour le 25 avril 2026 après l’ajout de la base axe-core et du job CI d’accessibilité non bloquant.
Prochaine revue prévue : 25 avril 2027, ou plus tôt en cas de changement substantiel des modèles de page, de l’interface du calculateur ou des outils d’accessibilité.