Nous produisons de la documentation sur plusieurs applications du ministère, et un audit RGAA (Référentiel général d’amélioration de l’accessibilité https://accessibilite.numerique.gouv.fr/) a mis en avant des erreurs. J’aimerais savoir si dans les futures versions de DOKIEL il y a une volonté de se conformer au RGAA ?
Un exemple du retour d’audit sur le menu gauche d’une de nos documentations d’aide logicielle
Je n’ai pas eu d’autres documents, néanmoins voici certaines des erreurs remontées :
Sur le cadre de saisie de la recherche : Le système d’autocomplétion de la recherche n’est pas compatible avec les lecteurs d’écrans et les interactions clavier. Combobox Pattern | APG | WAI | W3C
Sur le menu : Le système d’arbre de navigation n’est pas compatible avec les les lecteurs d’écrans et les interactions clavier. Tree View Pattern | APG | WAI | W3C
Sur le menu : Des live régions sont mises en place à l’aide de aria-live de manière abusives et non justifiées.
Cela entraine une prise de parole intempestive du lecteur d’écran à chaque modification d’un élément ou d’un attribut sur l’ensemble du bloc (même comportement observé pour les autres blocs de contenus de la page).
Est-ce vous êtes au courant de ces points ? Est-ce qu’il y a une volonté pour que Scenari fournisse du contenu 100% accessible ?
Et l’image ? vous l’avez en plus grande taille, le text est souvent illisible.
De manière générale, oui, nous tentons de produire des contenus le plus accessibles possible.
Ce travail est complexe et long et, pour être le plus complet possible, nécessite un audit détaillé par des experts pour chaque publication de chaque modèle. De plus au fur et à mesure que les technologies assistives évolues, les contenus doivent aussi, un travail de fond perpétuel.
Un très gros travail a été fait en ce sens dans Opale 25 en partenariat avec Access42. Une partie de ces améliorations seront retrouvés dans Dokiel 25 mais à date ce ne sera pas exhaustif. Un projet à part devra être mené pour réellement garantir que la future version de Dokiel soit le plus accessible possible.
Par ailleurs aucun outil ne peut être 100% accessible « tout seul », l’auteur doit également l’utiliser correctement en fournissant systématiquement les informations d’accessibilité.
Merci pour votre réponse plus détaillée sur votre stratégie pour converger vers l’accessibilité. Je comprends que l’outil ne puisse pas garantir seul que le contenu soit accessible. Ma question était plutôt sur des choix structurels où on a pas la main côté édition.
cadre de saisie de la recherche : Je ne vois pas exactement ce qui est incompatible, à part peut-être le reset du champ de recherche sur Echap ?
le menu : Dans Dokiel 25 les boutons > et V sont maintenant compatible WAI. Par contre je ne suis pas sûr du bien-fondé de permettre de se mouvoir dans le menu avec les flèches. Ce n’est en tout cas pas ce qui a été préconisé dans Opale 25.
aria-live : Dans Dokiel 25 ces attributs ont été supprimés.
J’ai une question sur l’objet « image décrite », l’auditeur nous a remonté :
« Le contenu de l’image et les interactions associées ne peuvent pas être rendues accessibles pour les lecteurs d’écrans. Cette zone devrait être masquée pour éviter tout pollution de la restitution du lecteur d’écran. »
Est-ce que ce point sera corrigé en DOKIEL 25 ?
Est-ce qu’il y a une option pour que l’image décrite soit affichée par défaut en une liste de la succession des zones dans l’ordre ?
