Bonjour, Il n'est pas requis par le RGAA d'utiliser un design pattern ARIA pour coder un composant. On peut par exemple coder un système d'onglets "à l'ancienne", à base de listes de liens pour les onglets, de contenus intercalés ou listés à la suite pour les panneaux, et gérer l'affichage/masquage par manipulation du DOM via CSS et JS. Tout cela peut être accessible et consultable avec un lecteur d'écran, tant que l'on gère correctement l'affichage et le focus.
Par contre, ce qui est requis, c'est que si l'on utilise ARIA (par exemple, role="tab" sur les onglets), il faut aller au bout de la logique, et appliquer entièrement le design pattern proposé par le doc 'authoring practices" accompagnant la spec ARIA. Ce design pattern est une tentative de normalisation de composants d'interface qui dans les faits ne sont que des assemblages de HTML, CSS et JS résultant en un simulacre visuel de composants d'interface riches. Cela permet de se mettre tous d'accord (développeurs Web, éditeurs de navigateurs, éditeurs de lecteurs d'écran) sur les conventions d'écriture qui feront que le lecteur d'écran reconnaitra tel assemblage comme étant un système d'onglets, et le restituera correctement, en étant capable de fournir des indications du type nombre d'onglets, onglet actif, etc. Par ailleurs il faut respecter le schéma d'interaction clavier proposé pour le design pattern; pour le RGAA on ne vérifiera que le support des touches Entrée, Flèches, Espace, Tab et Echap. J'ai écrit "tentative de normalisation" car ce doc n'est pas normatif, et c'est un document de travail en évolution permanente. Le choix du RGAA est de s'appuyer dessus malgré tout, faute de mieux j'allais dire... De fait, si les design patterns sont plutôt bien supportés pour certains composants et pour certaines configurations de consultation, ça peut ne pas être toujours le cas. D'où l'exigence complémentaire de tester a minima sur la base de référence définie pour le projet. Donc en résumé: si on met de l'ARIA, il faut le faire entièrement, et tester que ça restitue bien. Sinon, on n'en met pas. Pour le fait que l'on s'adresse à l'auditeur uniquement: en fait le RGAA est juste une méthode de vérification de conformité. Sa cible est donc l'auditeur, et il ne serait ni opportun ni pertinent qu'il s'adresse à un autre type d'intervenant. Même si, bien entendu, sur cette base il est possible de décliner des méthodes de conception, des précos de développement, des specs, etc. J'espère avoir répondu à ta question! [image: --] Olivier Nourry [image: http://]about.me/oliviernourry <http://about.me/oliviernourry> Le 6 octobre 2016 à 12:15, Julie Moynat <juliemoy...@gmail.com> a écrit : > Merci Aurélien pour ta réponse. C'est vrai que le lien de ce glossaire > explicite mieux tout ça. > > Alex, il semble donc, d'après ce glossaire, qu'on peut aussi définir > l'état dynamiquement dans le nom (hors HTML5 et hors ARIA) via JavaScript. > Ce qui nous offre finalement pas mal de possibilités. > > La citation : "Note : *un état peut également être transmis **via** le > nom*, lorsque l’intitulé est changé dynamiquement pour correspondre à > l’état de la zone contrôlée notamment." > > > Bonne journée ! > > Julie > > > Le 6 octobre 2016 à 12:04, Alex Bernier <alex.bern...@braillenet.org> a > écrit : > >> Bonjour, >> >> Un script peut être accessible aux technologies d'assistance sans pour >> autant qu'il utilise ARIA (i.e. quand les rôle, l'état, la propriété... >> utilisés existent "nativement" en HTML5). >> >> Alex >> >> >> On Thu, Oct 06, 2016 at 10:45:04AM +0200, Julie Moynat wrote: >> > Bonjour, >> > Quand je lis le critère "7.1 [A] Chaque script est-il, si nécessaire, >> > compatible avec les technologies d’assistance ?" et le test 7.1.1 >> dans >> > le référentiel (cf. >> > [1]http://references.modernisation.gouv.fr/rgaa/criteres. >> html#scripts), >> > je comprends qu'on est obligé d'utiliser ARIA pour qu'un script soit >> > accessible à moins qu'il ait une alternative. >> > Lors de ma formation AccessiWeb, on avait bien vu que ARIA était >> > obligatoire à moins d'avoir une alternative accessible utilisant ARIA >> > ou d'avoir une alternative sans JavaScript. >> > Mais, quand je lis le test 7.1.1 dans la méthodologie (cf. >> > [2]http://disic.github.io/rgaa_methodologie/#script), je comprends >> > qu'ARIA n'est pas obligatoire. >> > Il doit y avoir, quelque part, un problème de formulation. >> > Bref, je suis perdue. >> > Mon script n'a pas d'alternative et n'utilise pas ARIA et la question >> > est de savoir si je dois préconiser l'utilisation d'ARIA à chaque >> fois >> > ou si remplir les conditions du test de la méthodologie est >> suffisant. >> > Quelqu'un saurait-il éclairer ma lanterne ? >> > En vous remerciant, >> > Julie Moynat >> > >> > Références >> > >> > 1. http://references.modernisation.gouv.fr/rgaa/criteres.html# >> scripts >> > 2. http://disic.github.io/rgaa_methodologie/#script >> >> > _______________________________________________ >> > liste_gta mailing list >> > liste_gta@list.accessiweb.org >> > http://list.accessiweb.org/mailman/listinfo/liste_gta_list. >> accessiweb.org >> >> >> _______________________________________________ >> liste_gta mailing list >> liste_gta@list.accessiweb.org >> http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org >> > > > _______________________________________________ > liste_gta mailing list > liste_gta@list.accessiweb.org > http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org > >
_______________________________________________ liste_gta mailing list liste_gta@list.accessiweb.org http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
