Questions diverses

Simplicité d'accès, facilité d'utilisation et de mise en œuvre du RGAA

Le RGAA est accessible à l'adresse : http://references.modernisation.gouv.fr/rgaa-accessibilite/, des ressources http://references.modernisation.gouv.fr/ressources permettent de faciliter sa mise en œuvre et de vérifier la conformité avec le référentiel.

Ce sujet est destiné à recueillir toutes propositions d'évolution concernant la facilité d'utilisation du RGAA et de ses ressources appuyées sur vos retours d'expérience. Des suppressions ou fusions de ressources peuvent aussi être proposées.

Ajouter ma proposition
  • Proposition de ARMONY DE KOENA | 22/03/2019 - 10:57

    Ajouter des notes avec des exemples comme sur WCAG

    Lors d'une possible difficulté de compréhension d'un critère WCAG, il est ajouté une ou plusieurs note à l'intérieur même du critère de succès avec des exemples concrets pour faciliter la compréhension.

    Nous proposons que RGAA intègre l'intégralité des notes WCAG a minima.

    Il ne s'agit pas d'en faire un manuel d'utilisation, mais bien d'en faire une transposition exacte et complète.

    Si le RGAA est un outil de vérification de la conformité aux WCAG, avec une volonté d'en faciliter la mise en œuvre, il semble pertinent de conserver les outils pédagogiques inhérents aux WCAG.

  • Proposition de ARMONY DE KOENA | 22/03/2019 - 10:13

    Plateforme de contribution

    L'utilisation de la plateforme de contribution gagnerait à proposer la possibilité d'afficher la liste des critères au choix selon les dernières modifications (ce qui est fait par défaut actuellement) ou selon l'ordre initial (en respectant la logique RGAA).

    Les erreurs dans les liens de navigation (précédent/suivant) sont sans doute liés à ce tri par dernière mise à jour.

    Je sais que c'est un peu hors sujet de cette rubrique, mais je ne vois pas où déposer ce commentaire.

  • Proposition de ARMONY DE KOENA | 21/03/2019 - 16:06

    Bugs sur la version actuelle du RGAA

    Nous avons constaté des erreurs sur les principes WCAG associés aux thématiques du RGAA, il faudrait veiller à les corriger dans la future version.

    Par ailleurs, le niveau des critères RGAA est indiqué visuellement avec un aria-hidden="true", ce qui rend le niveau non restitué par le lecteur d'écran. L'alternative a été pensée pour être plus compréhensible avec le lecteur d'écran, mais elle est donnée via un aria-label sur une balise span, qui n'est malheureusement pas plus restituée au lecteur d'écran (ni vocalement, ni en braille). Les auditeurs et auditrices aveugles ne peuvent donc pas connaître le niveau du critère audité.

  • Proposition de JULIEMOYNAT | 27/02/2019 - 16:26

    Critère 13.14 et définition de premier cycle de l'enseignement secondaire

    Bonjour,

    Dans le critère 13.14 [AAA] "Dans chaque page web, chaque texte qui nécessite un niveau de lecture plus avancé que le premier cycle de l'enseignement secondaire a-t-il une version alternative ?", l'expression "premier cycle de l'enseignement secondaire" n'est pas définie et est difficile à comprendre. Dans la traduction de WCAG, elle est défini comme suit :

    « les deux ou trois années de scolarité qui commencent après six ans environ d'enseignement primaire et qui se terminent après neuf ans environ de scolarisation depuis le début de l'enseignement primaire
    Note : cette définition se fonde sur la norme de Classification internationale type de l'éducation de l'[UNESCO]. »
    https://www.w3.org/Translations/WCAG20-fr/#lowseceddef

    Cela reste malgré tout ambigu et, s'agissant du RGAA, je pense que nous pourrions préciser, qu'en France, il s'agit du collège (de la 6e à la 3e). Cela faciliterait grandement la compréhension.

  • Proposition de LCAREVIC | 18/02/2019 - 23:32

    Format de la nouvelle version du RGAA (partie technique) proposée en relecture

    Bonsoir,

    Avez-vous déjà une idée quant au format de la nouvelle version du RGAA qui sera proposée pour relecture globale ? Est-ce que le format actuel sera conservé (URLs et ancres notamment) ? Si ce n'est pas possible ou souhaité, serons-nous consulter sur le format qui sera proposé ?

    Ma proposition serait de garder le format actuel si possible car de nombreuses ressources reposent dessus.

    Pour faciliter la prise en main et les comparaisons, est-il prévu de fournir une note de révision (changelog) avec la liste des changements et nouveautés introduits dans la version 4 du RGAA sur ce modèle : https://references.modernisation.gouv.fr/rgaa-accessibilite/changelog.html

    Par ailleurs quid des retours postérieurs à la publication du RGAA 4. Se feront-ils sur cette plateforme ? Ou sur GitHub (qui personnellement me semble plus efficace et bien plus facile d'utilisation) ?

    Merci d'avance pour les éléments de réponse que vous pourrez m'apporter.

  • Proposition de COUSQUER | 06/02/2019 - 17:00

    Pourquoi ne pas s'appuyer, traduire et MAINTENIR DANS LE TEMPS certaines ressources du w3c directement ?

    On collera un peu plus avec l'évolution de la plateforme et des standards. Dans un contexte de développement soutenu par des Fondation open-sources et de consortium français.
    Le dialogue s'apparente à des jongleries d’acronymes nationaux et de mapping entre différents critères classés différemment selon les pays et à du brassage de bras. amusant et décredibilisant
    au final: vous connaissez les stats nationales d'accès compliqué ou impossible des projets qui sont lancer
    vous me direz heuristiques nationales d'implémentation, certes - mais elles sont là :
    Le site de l’initiative d'accessibilité Web du W3C - WAI
    Les priorité de traduction des ressources de la WAI
    [La page du wiki du W3C qui détaille un peu les choses](https://www.w3.org/wiki/WAI_Translations#Translation_Priorities

    cousquer

    avec les fautes d'orthographe en moins - c'est mieux. Désolé clic par inadvertance...
    On collera un peu plus avec l'évolution de la plateforme et des standards. Dans un contexte de développement soutenu par des Fondations open-sources et de consortiums français.
    Le dialogue s'apparente à des jongleries d’acronymes nationaux et de mapping entre différents critères classés différemment selon les pays et à du brassage de bras. Amusant et décrédibilisant
    au final : vous connaissez les statistiques nationales d'accès compliqué ou impossible des projets qui sont lancer
    vous me direz heuristiques nationales d'implémentation, certes - mais elles sont là :

    • Pas d'accord 0 Pas d'accord

    cousquer

    Bon il reste des fautes d'orthographe... Ceci pour mettre en perspective de façon constructive (cet engagement)[https://twitter.com/mounir/status/1059533080157917184] et (ce constat)[https://twitter.com/_DINSIC/status/1067071631003172869]

    • Pas d'accord 0 Pas d'accord

  • Proposition de ANNECAV | 04/02/2019 - 10:49

    Toutes les WCAG que les WCAG ou plus si affinités ?

    Je ne sais pas si c'est le bon endroit/vecteur pour évoquer cette question mais je pense qu'elle mériterait d'être traitée.

    Cette nouvelle version du RGAA souhaite rester au plus près des WCAG ; cependant lors de la dernière réunion (janvier) il a été évoqué que des critères plus exigeants pourraient être ajoutés s'il y avait consensus sur leur nécessité.

    Cela soulève à mes yeux quelques questions :

    • y a-t-il une "doctrine" d'éligibilité de critères supplémentaires ou cela repose-t-il seulement sur le consensus ?
    • ne risque-t-on pas de créer des situations où un site européen pourrait être conforme aux WCAG mais pas au RGAA ? L'obligation ne s'appliquerait-elle que pour sa version en langue française ? ou seulement si son siège est en France ? ou ?

    En tout état de cause si des exigences supplémentaires devaient être créées il faudrait à tout le moins les regrouper dans un document / une page web accompagnés de leur justification dans les annexes au RGAA.

    roullierb

    Bonjour, la vocation du RGAA est d'être un outil d'évaluation de la conformité avec les exigences légales. La directive européenne applicable depuis le 23 septembre 2018 fixe le niveau d'exigence aux critères A et AA des WCAG 2.1. Le RGAA fournit une méthode de test technique aux auditeurs de sites web. La Dinsic ne souhaite pas que le RGAA soit plus exigeant dans ses tests de conformité que les recommandations et autres documents techniques accompagnant les WCAG. C'est un des objectifs de cette mise à jour.

    • Pas d'accord 0 Pas d'accord

    lcarevic

    « Ne risque-t-on pas de créer des situations où un site européen pourrait être conforme aux WCAG mais pas au RGAA ? »

    Ça ne semble pas devoir se poser dans le cadre du RGAA, mais je pose la question néanmoins, est-ce un problème ? Je considère pour ma part que non. D'autant plus si ces exigences apportent un réel gain aux personnes handicapées.

    On pourrait très bien envisager que certains États européens décident d'aller au-delà de l'exigence définie dans la directive européenne (cas théorique, il y a zéro chance pour que ça arrive je pense).

    Donc un site français serait conforme WCAG/RGAA, mais pas conforme au référentiel de cet autre État membre plus exigeant.

    C'est quelque chose qui arrive fréquemment sur d'autres pans de la législation (heureusement d'ailleurs !) et les entreprises européennes/multinationales s'adaptent simplement à la législation en vigueur dans le pays où elles veulent exercer.

    • Pas d'accord 0 Pas d'accord

  • Proposition de ESTELLE RENAUD | 01/02/2019 - 17:12

    A qui s’adressent les documents composant le RGAA ? Comment faciliter la compréhension du RGAA par l'administration ?

    Rappel des documents composant le RGAA v3

    Extrait de [https://references.modernisation.gouv.fr/rgaa-accessibilite/guide-accomp...
    Le RGAA (version 3) représente un ensemble cohérent de documents dont le respect est imposé par décret. Il est composé de trois documents :
    * Le document « Introduction au RGAA », qui définit la problématique et les enjeux de l'accessibilité numérique ;
    * Le « Guide d'accompagnement » ;
    * Le « Référentiel technique », lui-même composé de 6 sections :
    ** Liste des critères et des tests ;
    ** Glossaire ;
    ** Cas particuliers ;
    ** Notes techniques ;
    ** Base de référence ;
    ** Références.

    Questions en vrac

    Quelles sont les compétences requises pour comprendre les documents composants le RGAA ? Quelle est la cible de ces documents ? Des experts en accessibilité numérique ? Des agents des administrations non experts ? Comment un contributeur (webmaster), un graphiste, un chef de projet, un développeur etc. peut-il s’assurer de la conformité avec le RGAA ? En étant formé puis en consultant les documents du RGAA ou en consultant d’autres ressources ? etc.

    Exemple de cas concret : Comment un graphiste au sein d’une administration peut-il s’assurer que ses productions graphiques sont conformes avec le RGAA ?

    A priori pas en lisant les critères et les tests trop complexes, mais plutôt en s’appuyant sur des outils et ressources complémentaires aux vertus pédagogiques. Quelques idées d’évolutions sur le site [http://references.modernisation.gouv.fr/rgaa-accessibilite/] :
    * Prévoir un filtre profil. Ex : « graphiste » sur le RGAA (idem checklist pidila) [https://pidila.gitlab.io/checklist-pidila/?Profil=Graphisme]
    * Prévoir sous chaque critère deux liens :
    ** Tests (idem existant) – Cible : les experts
    ** Notice – Cible : les non experts. Notice dans laquelle on pourrait retrouver des exemples, illustrations, cas concrets, outils, liens, fils de discussion etc. exactement ce que fait atalan [https://www.accede-web.com/notices/graphique/3-couleurs/3-1-contraste-te... et pourquoi pas associer Atalan, pour faire évoluer leurs notices avec cette nouvelle version du RGAA (puisque les ressources existent…)
    * Autre idée d’évolution du site : il serait pratique de pouvoir récupérer l’url d’un critère du RGAA, actuellement on peut récupérer des urls par thématique seulement (ex [https://references.modernisation.gouv.fr/rgaa-accessibilite/criteres.htm...)

    Autre exemple : Comment un chef de projet web en charge de la refonte d’un site peut-il s’assurer de la conformité avec le RGAA ?

    Ce qui se passe fréquemment : les CP positionnent le RGAA comme étant une exigence du CCTP, les prestataires de développement s’engagent à respecter le RGAA dans leurs offres mais pas dans la pratique, les CP recettent les sites d’un point de vue fonctionnel mais pas d’un point de vue RGAA. Pour éviter cela, la solution pour l’administration est de prendre un prestataire en accessibilité pour former le CP, assister le CP lors de la recette (audits), assister le CP pour le suivi du prestataire de dev... Pour gagner en autonomie, des ressources pédagogiques autour du RGAA sont ensuite indispensables.

    lcarevic

    « Autre idée d’évolution du site : il serait pratique de pouvoir récupérer l’url d’un critère du RGAA, actuellement on peut récupérer des urls par thématique seulement. »

    La fonctionnalité n'est sans doute pas évidente pour les personnes non techniques, mais il existe déjà des ancres pour les critères et les tests.

    Exemples : https://references.modernisation.gouv.fr/rgaa-accessibilite/criteres.htm... ou https://references.modernisation.gouv.fr/rgaa-accessibilite/criteres.htm...

    • Pas d'accord 0 Pas d'accord

    lcarevic

    La plateforme tronquant les liens :
    * modèle d'ancre pour les critères : #crit-1-1
    * modèle d'ancre pour les tests : #test-1-1-1

    • Pas d'accord 0 Pas d'accord

    Olivier Nourry

    Bonjour Estelle,

    Mon avis sur la question des profils: pour moi c'est une fausse bonne idée.

    C'est peut-être intéressant dans une méthodologie projet, mais AMHA ce n'est pas le rôle d'une norme technique que de fournir des éléments de gestion de projet de ce genre. En revanche il y a des ressources annexes qui peuvent aider à faire cela, et surtout à l'adapter au projet (car il n'y a pas 2 projets sur lesquels on pourrait caler une méthodo toute faite, avec 0 adaptation, même au sein d'une organisation donnée).

    De plus le RGAA sortirait de sa fonction de méthodologie d'application des WCAG, qui en aucun manière ne fait de préco de ce type.

    Mais supposons qu'on le fasse quand même... Et rapidement on verra plusieurs écueils apparaître.

    D'abord il faudra se mettre d'accord sur ce que l'on met derrière chaque profil. Pour certains un graphiste ne touche pas au code, pour d'autre il conçoit les CSS voire monte le HTML... on peut débattre à l'infini sans jamais avoir raison, puisque définir la réalité des métiers du Web est une gageure en soi, tant cette réalité est complexe et variable au cas par cas.
    Répète pour chaque typologie de profil, et tu vois déjà la première difficulté.

    Admettons qu'on arrive à se mettre d'accord sur les profils... encore faudra-t-il que les utilisateurs du RGAA le soient aussi! Or, il y a des projets où les contributeurs font un peu de graphisme, d'autres qui injectent du code, d'autres où le CP est aussi développeur mais uniquement JS... et je ne te parle même pas du webmaster dév full stack pizzaïolo. Donc là où on aura fixé des choses pour des profils normés, les équipes ne se reconnaîtront pas, ce qui donnera forcément lieu à des problèmes pour atteindre la conformité. On risque de rajouter une couche de complexité au lieu de simplifier. Et il sera facile de reprocher au RGAA l'échec d'une mise en accessibilité, par inadaptation au réel.

    Ensuite il est risqué de limiter tel critère à tel métier. Si on dit par exemple que le 3.3 est un critère de graphiste, on oublie que les contributeurs et les développeurs peuvent aussi introduire des couleurs via leur production. On risque alors de voir des projets où les responsabilités n'ont pas été assumées par les profils que le RGAA n'aura pas explicitement désignés comme concernés par tel ou tel critère. Rapidement on va finir par dire que tous les critères concernent tous les profils (ou quasiment), car on trouvera toujours une situation où sera la réalité... donc bénéfice nul.

    Donc pour moi: ce n'est pas à faire au niveau du RGAA, mais, si on y tient vraiment, plutôt au niveau des projets, ou à la rigueur des méthodos de projet. Ce que des ressources annexes peuvent aider à faire, au besoin.

    • Pas d'accord 0 Pas d'accord

    sdeschamps

    Ensuite il est risqué de limiter tel critère à tel métier. Si on dit par exemple que le 3.3 est un critère de graphiste, on oublie que les contributeurs et les développeurs peuvent aussi introduire des couleurs via leur production. On risque alors de voir des projets où les responsabilités n'ont pas été assumées par les profils que le RGAA n'aura pas explicitement désignés comme concernés par tel ou tel critère. Rapidement on va finir par dire que tous les critères concernent tous les profils (ou quasiment), car on trouvera toujours une situation où sera la réalité... donc bénéfice nul.

    Merci Olivier pour toutes ces réflexions. Il peut être intéressant de voir le travail (en cours) sur ARRM (Accessibility Roles and Responsibilities Mapping) sur le wiki du W3C https://www.w3.org/WAI/EO/wiki/RA11y_Matrix - ce projet essaie justement d'aider à la prise de décision/prise de responsabilité, en tâchant de définir une "responsabilité principale" pour chaque critère. Attention, ce n'est pas encore sec du tout (le chemin est encore long) et il faudra bien garder en tête à la fin que ce sera un outil d'aide à la décision, mais une limitation de tel critère à tel métier.

    En tout cas à terme, ça vaudra le coup effectivement de fournir une ressource annexe d'aide à la décision sur le qui-fait-quoi.

    • Pas d'accord 0 Pas d'accord

    sdeschamps

    Zut le style de citation a disparu de mon commentaire, je croyais qu'il y avait du Markdown.
    Bref, le premier paragraphe est une citation du commentaire d'Olivier, je n'ai pas moyen de corriger mon commentaire pour le rendre explicitement - Bénédicte et Aurélien, SVP, on peut y faire quelque chose ?

    • Pas d'accord 0 Pas d'accord

    lcarevic

    Concernant les profils

    Comme Olivier, je pense que les profils constituent une fausse bonne idée et s'éloigne de l'objectif premier du RGAA.

    Le travail de répartition et de définition des responsabilités me semble à faire en fonction de chaque projet par la personne en charge du projet.

    Je n'ai personnellement jamais vu de clients avoir des difficultés particulières pour répartir les responsabilités lorsqu'un audit leur est remis. La réunion de restitution des résultats d'audit permet justement de revoir le périmètre de chacun.

    Sur ce point : « Comment un contributeur (webmaster), un graphiste, un chef de projet, un développeur etc. peut-il s’assurer de la conformité avec le RGAA ? »

    La réponse me semble évidente : en étant formé et/ou accompagné.

    « Les CP recettent les sites d’un point de vue fonctionnel mais pas d’un point de vue RGAA. Pour éviter cela, la solution pour l’administration est de prendre un prestataire en accessibilité pour former le CP, assister le CP lors de la recette (audits), assister le CP pour le suivi du prestataire de dev... Pour gagner en autonomie, des ressources pédagogiques autour du RGAA sont ensuite indispensables. »

    Effectivement, on peut déplorer que l'administration ne soit pas autonome sur l'accessibilité numérique, mais dans ce cas, le constat est applicable sur bien d'autres domaines où l'administration ne semble pas hésiter à recourir à des prestataires. Le problème ne me semble pas être lié au RGAA.

    Il est illusoire de croire que des personnes sans formation puissent rendre leur site conforme en toute autonomie de manière efficace et respectant les contraintes planning des projets qui ne sont même pas forcément tenables pour des experts et expertes expérimentées ayant plusieurs années d'audits derrière eux.

    • Pas d'accord 0 Pas d'accord

  • Proposition de SKEY | 01/02/2019 - 15:47

    Cas particulier du elearning

    Comment prendre en compte les capsules de elearning et ses spécificités de conception, de suivi et d'implémentation. Voilà ce que j'ai pu identifier

    J'ai lu les documents traitant de l'accessibilité numérique suivants : le Web Content Accessibility Guidelines WCAG, le Référentiel Général d'Accessibilité pour les Administrations RGAA, le Facile A Lire et à Comprendre FACL

    Je propose cette check liste à affiner en fonction du public cible.

    Cette check liste permet de valider la prise en charge du besoin d'accessibilité au niveau de la note de cadrage et est formulée de manière à être directement applicable lors des tests.

    Les contenus textuels sont dans un langage simple, utilisent des phrases courtes, des mots simples, des sigles explicités ;

    Les contenus sont illustrés avec des exemples concrets, des visuels explicites en rapport avec le sujet ;
    Mise en page :

    Les pages et le texte sont structurés dans un ordre logique et chronologique ;

    La lisibilité et la clarté du texte est privilégiées par rapport aux effets graphiques ;

    Le contenu est simple sur la forme et sur le fond.

    Il y a une idée par phrase.

    Il y a un texte alternatif pour les éléments visuels pris en compte par un lecteur d’écran.

    L’ordre d’affichage d’une navigation clavier des objets est défini.

    Les pages comportent un titre qui décrit le sujet ou le but

    La mise en page est claire et aérée faisant ressortir l'information essentielle.
    Navigation :

    Une localisation dans le module est disponible.

    La navigation est prévisible et cohérente.

    Toutes les fonctionnalités sont accessibles au clavier.

    Les liens et les boutons d’actions sont homogènes et clairement identifiables de la même manière.
    Affichage du texte :

    La police utilisée est Arial ou Tahoma

    La police n’est pas en italique, ni soulignée

    La taille minimale de l’écriture est 14

    Il y a un seul type d’écriture

    L’écriture est de couleur noire

    La largeur des textes est inférieur à 80c

    Les textes ne sont pas justifiés

    L’espacement entre les lignes est d’au moins 1,5

    Une nouvelle phrase commence sur une nouvelle ligne

    Le texte n’est pas écrit dans des colonnes

    Le texte est agrandit à au moins 200 % par une technologie d’assistance

    Il n’y a pas de texte sous forme d’image (sauf décoratif)
    Délais :

    Le délai de visualisation est suffisant

    Il n'y a pas de délai d’exécution imposé
    Audio

    Les sous-titres apparaissent synchronisés à la bande audio

    Les sous-titres sont affichés sur une bande foncée

    Il est possible de masquer les sous-titres

    La traduction en langue des signes est disponible

    Il est possible d’arrêter une bande audio, de la mettre en pause, de la ralentir

    Quand il y a un son dans une activité les autres sons sont mis en pause.

    Il n'y a pas de contenu sonore en arrière plan ou alors < 20db

    Qu'en pensez vous ?

  • Proposition de LENA | 31/01/2019 - 11:07

    Lister les différences par rapport aux WCAG

    Dans le guide d'accompagnement est écrit "Il est important de comprendre que si le RGAA est entièrement compatible avec les WCAG 2.0, l'inverse n'est pas forcément vrai."

    Il serait utile de lister les points de divergences.

    Annecav

    Discussion à rapprocher de celle que j'ai ouverte ce matin ici https://evolution-rgaa.numerique.gouv.fr/participer/questions-diverses/s... avant de voir la présente proposition...

    • Pas d'accord 0 Pas d'accord

Retour en haut