Note technique pour les critères 1.1, 1.2 et 1.3 relative à la construction de l'échantillon de test

À l'image d'un audit d'un site web, la construction de l'échantillon pour l'audit RGAA d'un CMS doit se baser sur la nature essentielle des pages. À ce titre, il est recommandé pour ces tests, de choisir, si elles existent, au moins les types de pages suivantes :

• les pages de la documentation (si la documentation est intégrée à l'outil) ;
• l'index de la documentation (s'il est différencié de la page de la documentation) ;
• les pages de configurations globales du CMS (les paramètres généraux par exemple) ;
• les pages de configurations spécifiques (page de sélection d'un gabarit, page pour la configuration du menu, etc.) ;
• les pages qui présentent les contenus non textuels (la gestion d'une bibliothèque multimédia par exemple) ;
• les pages d'édition courantes (édition d'un article, édition d'une page…) ;
• toute autre page nécessaire à un auteur pour contribuer.

Note technique pour les critères 1.8, 1.9, 1.10

Les outils d'édition peuvent proposer des fonctionnalités de transcodage d'un format d'entrée vers un format de sortie. L'objectif des critères 1.8, 1.9 et 1.10 est de s'assurer que toutes les fonctionnalités d'accessibilité sont préservées, lorsqu'il existe des mécanismes équivalents dans le format de sortie. Dans le cas inverse, l'auteur doit être prévenu des pertes éventuelles d'accessibilité liées à l'absence ou aux limitations propres au format de sortie.

Ainsi, le format txt a un support limité de l'accessibilité, car il ne prend en charge qu'un nombre limité de structures via des conventions de formatage. Les titres peuvent notamment être indiqués par une ligne vide avant et après le titre et les listes par un marqueur visible, un tiret par exemple.

Il convient donc de vérifier deux choses :

• Si le format de sortie est limité, l'auteur est-il prévenu des pertes potentielles d'accessibilité ?
• Pour tous les mécanismes équivalents dans le format de sortie, les informations relatives à l'accessibilité sont-elles préservées ou adaptées (exemple : images remplacées par leurs alternatives au format txt) ?

Exemple d'application : cas des indications de langues dans le format txt.

On évalue une fonctionnalité d'exportation vers le format txt. On constate que pour tous les mécanismes propres au format txt (titre, liste, alternatives d'images…), les informations sont préservées. On constate par ailleurs que l'outil prévient que des informations d'accessibilité pourraient être perdues.

Le critère est conforme.

Dans le format d'entrée (par exemple HTML), il y a des indications de langue qui n'ont pas d'équivalent dans le format de sortie en txt. Pour ce problème, bien qu'il s'agisse d'une perte d'accessibilité, le critère reste conforme si l'auteur est prévenu. À lui de trouver une solution spécifique, par exemple en traduisant les termes ou en proposant une version accessible.

Note technique pour le critère 2.1

Les modifications de configuration de l'interface incluent également les mises à jour.

Si l'interface permet de réaliser les mises à jour de l'outil, dans ce cas précis, il est admis que la réversibilité de l'action ne soit pas possible. Dans ce cas, l'auteur doit être averti du caractère irréversible des modifications et doit confirmer la modification, par exemple la mise à jour vers une nouvelle version, avant son exécution.

Note technique pour le critère 4.1

Bien qu'il existe dans le RGAA 3 2016 de nombreux tests pour évaluer l'accessibilité des éléments non textuels (présence des attributs obligatoires pour les éléments img ou iframe par exemple), ce test est différent.

En effet, la zone d'édition peut utiliser un balisage d'édition différent du balisage de sortie. Ce balisage d'édition peut être un balisage indépendant d'une technologie web standard et peut ne pas trouver de correspondance dans les critères du RGAA 3 2016 basés sur HTML.

Les attributs ou propriétés ne peuvent pas être prévisibles dans ce cas. Il est donc utile pour ce test, de réaliser des tests de restitution avec les lecteurs d'écran de la base de référence, pour s'assurer que les alternatives des contenus non textuels sont effectivement restituées.