Mise en conformité a11y de l'application

[Volubyl]

Description du besoin

⚠️ cette issue sera régulièrement mise à jour en fonction des avancées

Une des étapes importante de la phase du projet catalogage, débutée en octobre 22, est la mise en conformité en terme d'accessibilité de l'application.

Cette EPIC a pour vocation de proposer "un plan d'action" pour atteindre cet objectif.

Ce plan sera découpé en plusieurs autres epic où chaque étape y sera plus détaillée

Etapes

• 1. ETQ dev je ne souhaite plus avoir de warning de la part de svelte concernant l'a11y #520
• 2. ETQ visiteur, je souhaiterais avoir accès la déclaration de conformité concernant l'a11y #523
• 3. ETQ dev, je voudrais pouvoir identifier les problèmes d'a11y de l'application #518

Étape 1 : Ne plus avoir de warning concernant l'accessibilité relevés par svelte ✔️

Actuellement, lors du build de l'application Svelte soulèvent quelques warnings marqués comme "svelte-a11y".

Jusqu'à présent, nous les avions ignorés sans trop les comprendre. Ce n'était certainement pas une bonne idée 😁

👉 issue liée #520

Étape 2 : ajouter une déclaration de mise en conformité ✔️

Comme proposé en réunion, l'on pourrait doit commencer par ajouter une déclaration de conformité au site web où y serait fait mention que pour le moment le site n'est pas conforme.

👉 issue liée #523

Etape 3 : identifier les problèmes potentiels de l'application

Avant toute chose, l'on pourrait commencer par identifier les problèmes potentiels en terme d'accessibilité.

Ici l'idée serait de réaliser un audit par nos soins du site web afin d'identifier les problèmes.

À l'issue de cette audit, une série d'autres issues par problème (par page ?) pourront être écrite. Cela permettra de p-e priorisé et/ou classer par ordre de difficulté de résolution.

Il est possible que certains problèmes nécessite des adaptations en terme UI ou code.

Dans ce cas, il faudra certainement réfléchir à stratégie de remédiation au cas par cas.

Issue liée :

👉 #518

Étape 4 : résoudre les problèmes identifiés

Une fois que cet audit sera réalisé, il faudra remédier aux problèmes soulevés

Étape 5 (optionnelle ?) : faire un audit externe

Cette étape consisterait à faire effectuer un audit par une entreprise externe (type: Access 42) pour avoir un regard extérieur sur l'application.

❓ question/réflexions ?

Est-ce que cette étape est obligatoire pour établir une déclaration d'accessibilité définitive ?

Non mais

faire un audit maison pour vérifier que tout est bon : oui ; mais pour se fixer son score soi même, non, trop de risque de passer à côté de quelque chose

Étape 6 : mettre à jour la déclaration de mise en conformité

Avoir une déclaration de mise en conformité stipulant notre conformité sera signe que l'on a touché au but.

--

Etat d'avancement au 9/05/23

Toutes les pages ont été auditées automatiquement avec AxeCore. Il y a eu aussi un audit manuel effectué en utilisant le plugin Firefox wave.

Ces deux actions me semblent avoir permis de mettre en lumière certains problèmes d'accessibilité qui ont été corrigé.

A l'heure actuelle, je pense que l'application est prête à être auditée par une société externe.

Pour rappel, seul ce type d'audit permettra de confirmer que Catalogage est bien accessible.