ETQ dev, je voudrais pouvoir identifier les problèmes d'a11y de l'application

[Volubyl]

rel : #517

Avant de débuter :

Pour commencer, il va falloir déterminer quel est l'échantillons de page à auditer

Message reçu de la part d'Anne-Sophie Tranchet sur le mattermost de beta.gouv

[... le premier travail dans un audit est de définir ton échantillon de pages à auditer. Dans cet échantillon, on y trouve certaines pages obligatoires (accueil, contact, login, mention légales...) ainsi que toutes les pages pertinentes (les différentes étapes d'un parcours, les différents gabarits...).

L'échantillon de page retenu est le suivant :

• page recherche (//fiches/search)
• page déclaration d'accessibilité (/declaration-daccessibilite)
• page de contribution/modification d'un jeu de donnée (/contribuer) Note: le formulaire est commun aux deux pages)
• page d'accueil en mode connecté (/)
• page d'accueil en mode non connecté
• page mention légales

Approche automatique

Il existe des outils qui permettent d'auditer une application de manière automatique, qu'ils soient utilisables en CLI (axe core, ...), sous forme d'extension navigateur (wave) ou autre.

Ces outils peuvent déjà aider à comprendre certains problèmes d'a11y mais ceux-ci ne suffiront pas à évaluer la conformité de l'application.

Etant donné le tooling utilisé actuellement par l'app Axe Core Playwright pourra faire la taf'

Cependant, ceux-ci peuvent permettre d'aider à maintenir la conformité du site web dans le temps.

Check list

• page recherche (//fiches/search)
• page déclaration d'accessibilité (/declaration-daccessibilite)
• page de contribution/modification d'un jeu de donnée (/contribuer) Note: le formulaire est commun aux deux pages)
• page d'accueil en mode connecté (/)
• page d'accueil en mode non connecté
• page mention légales

Approche "manuelle"

Débuter un audit par vérifier des points essentiels

• est-ce que l'application est construite sur une base de web sémantique et véfier que le site soit compréhensible même sans CSS
• vérifier si le site est utilisable au clavier

Check list orientées "dev"

Ces check list me semblent un peu "légère" car elles ne reprennent pas beaucoup de critères indiqués dans le RGAA. Elles peuvent cependant être un bon début ...

Exemple de check list:

• https://design.numerique.gouv.fr/outils/checklist-dev
• https://doc.incubateur.net/design/ressources-design/kit-accessibilite/accessibilite/10-choses-faciles-a-verifier-pour-un-site-plus-accessible

Tests du RGAA

Le RGAA propose une série de tests auxquels nous pouvons soumettre l'application pour mettre en lumière des choses à améliorer.

Sur le site du RGAA, il existe un kit d'audit avec un modèle de Grille d'audit.

En téléchargement ici : ici

L'idée serait de réaliser un audit se basant sur ce référentiel.

Livrable attendu

• pour chaque page de catalogage avoir une liste de choses à corriger et éventuellement une issue s'y référant

❓ questions et réflexions

• est-ce que partir directement dans un audit basé sur la grille d'évaluation du RGAA est réalisable dans la mesure de nos moyens (connaissance, temps, ... ?)