Comme vous le savez déjà certainement, le RGAA va connaître des évolutions.
Déjà il va changer de nom : il s’appellera désormais le Référentiel Général d’Amélioration de l’Accessibilité.
Les critères vont également évoluer, notamment afin de prendre en compte la version WCAG 2.1, les feedbacks des experts, etc.
Vous pouvez contribuer sur le site dédié (il reste qq jours) : https://evolution-rgaa.numerique.gouv.fr/
Normalement en septembre 2019, la version 4 du RGAA sera publiée.
Comment anticiper (liste de tâches à effectuer) et contribuer afin de mettre à jour Asqatasun ?
Merci pour le lien. Je mentionne @koj et @fabrice. Globalement l’arrivée d’une nouvelle version du RGAA revient faire un “diff” avec la/les versions précédentes. De là on implémente les changements.
En parallèle, Asqatasun v4.1 (actuellement en rc.4) sera sortie avant le RGAA.
Pour savoir comment anticiper, je dirais faire du bruit et accueillir de nouveaux contrbuteurs pour avancer plus vite
Merci pour cette info sur la nouvelle version d’Asqatasun.
Concernant les contributions, c’était aussi l’objet de mon message :
Quelles sont les tâches sur lesquelles des contributeurs pourraient agir ?
Malheureusement je ne suis moi même pas développeur mais si je peux contribuer d’une manière ou d’une autre, ca me plairait bien d’apporter ma pierre à l’édifice.
Pour info, pour faciliter sa réutilisation, le RGAA 4 va être rendu disponible au format JSON. Si vous souhaitez donner un avis sur le format de données envisagé, la Dinsic organise une réunion le jeudi 26 septembre à de 15h à 16h30 (possibilité de suivi à distance). Est ce que ça vous intéresse ?
Merci @Yann pour l’information. Pas sûre d’être disponible. Si une version est consultable avant cette rencontre, nous pouvons peut-être faire des retours par mail. Autrement, nous nous débrouillerons en utilisant le Json ou en scrapant du html.
Ressources complémentaires pour le futur fichier Json du RGAA :
Je suis aussi très intéressé par le RGAA v4, je n’ai pas trouvé d’information sur l’avancement de cette intégration dans Asqatasun.
Toutefois, j’ai trouvé depuis un moteur de recherche la page “DÉCLARATION DE CONFORMITÉ - RGAA 4.0”, “Un audit du site est en cours de réalisation par asqatasun.” sur https://www.thionville.fr/fr/d-claration-de-conformit-rgaa-40
Commençons pas un brin de re-contextualisation : d’un point de vue Asqatasun / automatisation les différences entre RGAA 3 et 4 ne sont pas significatives (voilà pourquoi nous avons choisi de sortir la version 4.1 avant).
Ceci étant, nous prévoyons de travailler sur le RGAA 4 cet été (moyennant les évolutions de ce cher corona évidemment, et en espérant pouvoir aller bat’ un carré d’ici là ).
Fournir des résultats fiables est la marque de fabrique d’Asqatasun, aussi l’ajout du RGAA 4 n’est pas une tâche anodine, et nous souhaitons procéder avec rigueur et méthode. Enfin les contributions sont toujours chaleureusement accueillies !
Tout d’abord merci pour cette suite qui apporte un plus pour un pauvre développeur comme moi.
Toutefois avez-vous une plus grande visibilité sur la mise à disposition d’une version compatible avec le RGAA 4 ?
En effet dans les tests menés, une image sans “alt” mais avec un “title” remonte en anomalie avec le RGAA 3 alors qu’il devrait être accepté au regard du critère 1.1.1 du RGAA4. J’ai donc beaucoup de faux négatif dans mes tests.
De plus comment allez-vous prendre en compte la subtilité du “image porteuse d’information” ? En effet à moins d’insérer un paramètre de “classe signalant les images porteuses d’information” cela me semble compliqué à automatiser.
Nous travaillons présentement à l’intégration de ce nouveau référentiel. Nous ne sommes pas encore mesure de donner une date de livraison pour le moment.
Pour ce qui est de la subtilité dont tu parles, nous avons mis en place le principe de marqueur. Effectivement, il n’est pas possible de définir de maniere fiable qu’une image est porteuse d’information (nous avions imaginé à l’époque essayer de detecter la présence de caractères dans l’image mais la mise en oeuvre etait complexe, et prenait beaucoup de temps). Pour autant, le principe de marqueur nous semble repondre à cette problématique, si les dev respectent une certaine convention de codage.
A ce moment la, étant sur de la nature de l’image, le test peut etre deroulé et le resultat pour etre donné de maniere sure.
).