Bonjour à tous, Ce débat entre accessiweb et RGAA n'a à mon sens pas lieu d'être.
Les deux référentiels ont eu le mérite d'exister, et ils sont tous deux obsolètes car n'intègre pas les évolutions des usages, c'est à dire entre autres les applications mobiles. Le passé, est derrière nous! Construisons le présent et surtout le futur..; De mon coté, le plus important, est l'esprit d'un référentiel. En effet, en tant qu'utilisateur nous n'avons aucun besoin que toutes les règles soient respectées. Il importe par contre que les éléments de blocage soit levé. A trop vouloir en demander, nous n'obtenons rien. Je préfère un engagement sur une base minimum avec une volonté de progresser qu'un engagement sur un tout qui ne sera jamais respecté. Au plaisir de vous lire. Cordialement, Mathieu Froidure Directeur associé Urbilog Tél Urbilog : 03 28 55 21 30 - Tél Sourdline : 01 47 82 40 05 port : 06 744 944 59 Web : http://www.urbilog.fr http://www.sourdline.com -----Message d'origine----- De : liste_gta [mailto:[email protected]] De la part de ALTINIER Armony Envoyé : mardi 1 juillet 2014 08:43 À : [email protected] Objet : Re: [Liste GTA] Différences entre WCAG et AW HTML5-ARIA Bonjour à toutes et tous, Je m'immisce dans le débat une seconde pour vous annoncer que l'ouverture de la consultation au GTA débutera ce vendredi. Nous avons choisi de mettre en place un forum sur lequel vous aurez la possibilité de prendre position en écrivant un commentaire mais aussi en votant. La dernière expérience du genre que j'avais initiée sur la liste au sujet du nom du référentiel avait démontré que ce n'est pas parce que les membres de la liste ne donnent pas leur avis de façon rédigée qu'ils n'en ont pas. Avec ce système, on souhaite faciliter votre participation et vous encourager à prendre position. Ceci étant dit, il me semble que ce long débat est non seulement indigeste pour la plupart des gens qui auront bien du mal à participer (ne serait-ce que parce qu'il faut énormément de temps pour pouvoir le faire, à moins d'écrire de nuit comme le fait JP ), mais également biaisé. La plupart de tes remarques Aurélien semblent dire une chose : AccessiWeb n'est pas WCAG. Certes, évidemment, personne n'a prétendu le contraire. De même qu'AccessiWeb 2.2 n'était pas RGAA 2.2.1. D'ailleurs, si respecter AccessiWeb permet de respecter WCAG et même RGAA 2.2.1 selon la version, un site conforme WCAG 2 ou RGAA 2.2.1 n'est pas forcément conforme AccessiWeb 2.2 ou HTML5-ARIA. Ce qui est assumé depuis toujours. En même temps, je doute que quiconque ne soit surpris ici puisque tous les membres de la liste sont formés et donc au courant de ce qu'est une méthode d'évaluation. Et comme toute méthode d'évaluation, AccessiWeb prend partie sur certains sujets, comme l'a fait RGAA 2.2.1 en décidant que JS n'était pas compatible avec l'accessibilité à l'époque. Et comme le font tous les référentiels qui vérifient l'accessibilité en se basant sur WCAG. Du coup, je tiens à préciser une chose importante pour éviter toute confusion : le choix de la méthode AccessiWeb ne sera pas discuté. Ce choix a été fait par l'État lorsqu'il a choisi notre offre absolument sans ambiguïté : forker AccessiWeb pour en faire l'annexe technique du RGAA 3. Ce qui sera soumis à discussion, ce seront certains points techniques liés aux nouveautés de la version HTML5-ARIA, des définitions de glossaire, ainsi que la notion de base de référence, essentielle pour comprendre ce que fait le référentiel AccessiWeb : en un mot, il trie dans WCAG et dans la spécification HTML 5 elle-même les différentes techniques pour ne retenir que ce qui fonctionne réellement pour les utilisateurs. Bref, ce qui est « compatible avec l'accessibilité » (notion WCAG) dans la base de référence retenue. Chacun est libre bien entendu de continuer à discuter sur ce fil de discussion, mais si vous voulez bien faire preuve d'un tout petit peu de patience, le débat sera plus facile et permettra davantage à toutes et tous de s'exprimer à partir de vendredi (je ne sais pas à quelle heure précisément, c'est sans doute Denis qui vous donnera le lien et les modalités d'accès). Bonne journée ! Armony Le 30/06/2014 16:52, Aurélien Levy a écrit : Bonjour, merci Jean Pierre pour cette réponse. Je me permet donc de continuer ici la discussion. Désolé pour la longueur du mail qui de coup prend des allures de romans. JPV écrit : Ce billet relève 13 cas de différences entre WCAG et le référentiel AccessiWeb HTML5/ARIA. L'espace de discussion naturel du référentiel étant cette liste, j'ai préféré poster ici les réponses que je il y en a 14 pour être exacte, tu as oublié le fait que le référentiel prend position sur les éléments HTML5, point sur lequel les techniques sont muettes pour l'instant. 1. Sur le role "présentation" Aurélien écrit : "Les techniques WCAG interdisent lusage du role presentation sur des éléments ayant une valeur sémantique devant être restituée. Cest ce quindique léchec F92. À linverse ils lautorisent sur ceux dont la sémantique ne devrait pas être restituée (exemple sur un élément blockquote qui aurait été utilisé pour faire de la mise en forme) cf échec F43. Je nai pas trouvé de correspondance dans Accessiweb HTML5." JPV écrit : F92 est bien pris en charge. De manière plus générale, l'utilisation du rôle présentation est encadré de la manière suivante : 1. Si le rôle "presentation" est requis par un Design Pattern ARIA il est obligatoire (critère AW 7.1 - test 7.1.3 <http://www.accessiweb.org/index.php/accessiweb-html5aria-liste-deployee.htm l#script> ) 2. Si le rôle "presentation" est interdit par la table de recommandation de surcharge de rôles, <http://www.w3.org/TR/2013/WD-aria-in-html-20131003/#recommendations-table> c'est interdit (Critère AW 7.1 - test 7.1.4 <http://www.accessiweb.org/index.php/accessiweb-html5aria-liste-deployee.htm l#script> ) 3. Tout autre usage du rôle "présentation" comme de tout autre rôle ARIA est pris en charge par le critère 7.1 - Test 7.1.6 <http://www.accessiweb.org/index.php/accessiweb-html5aria-liste-deployee.htm l#script> qui demande d'en tester la restitution. Autrement dit une utilisation abusive du rôle "presentation" qui interdit la restitution de la valeur sémantique d'un élément (sauf cas prévu par un Design Pattern) sera bien sanctionné, conformément à la failure F92 <http://www.w3.org/TR/WCAG20-TECHS/failures.html#F92> . Pour ce qui concerne les correspondances : elles ne sont pas encore mises à jour. Nous avons jugé qu'il était plus sage de remettre cette mise à jour des correspondances des techniques à la fin du travail de relecture qui est actuellement en cours. Sur la forme, comme je l'ai indiqué dans mon article mon analyse portait sur la version disponible lors de mon analyse difficile donc de prendre en compte des correspondances qui n'y figurent pas. Il est vrai que souvent les auteurs principaux d'un référentiel sont souvent les mieux placés pour définir les dites correspondances. Sur le fond : - sur le point 1 rien n'as redire si ce n'est qu'un role n'est pas forcement généré via javascript ce présuppose le test 7.1.3 - sur le point 2 il faudrait également préciser l'inverse car sinon ça ne couvre pas mon cas de blockquote destiné à la mise en forme avec un role presentation. De plus la technique F43 ne parle nullement de la table de recommandation (document toujours en draft dont l'url à jour est http://w3c.github.io/aria-in-html/#recommendations-table ) il s'agit donc d'une position choisi par Accessiweb et non directement issu d'une technique. Par ailleurs, la table de recommandation étant en draft, elle est susceptible de contenir elle même quelques des incohérences. Par exemple, la version que tu pointais indique dans le tableau: "All elements Role: presentation, except focusable elements or those with the warning 'Not role=presentation' or those indicated: NONE" puis "Element is not natively focusable (li, span, div, etc.) Not role=presentation " ce qui revient en réalité à l'interdire partout, les autres éléments étant indiqués en NONE ou en not role=presentation. Ce point est corrigé sur la version sur github car j'ai fais remonter l'erreur à l'éditeur du document ce week end cf https://github.com/w3c/aria-in-html/commit/559d3913e9dc849482bb33264194bd3f3 9ba03ff - sur le point 3 là encore les rôles aria ne sont pas forcement généré via javascript et au regard du test 7.1.6 actuel ces cas seraient alors non applicable pour ce test. Prenons donc un cas cas simple : un <h1 role="presentation"> dont la valeur sémantique devrait être restituée est non conforme au regard de la technique F92. Pour Accessiweb, Cela ne correspond à aucun design pattern et dans le cas où ce code n'est pas généré par javascript les tests 7.1.3 et 7.1.6 sont non applicable. La table de recommandation de surcharges des rôles n'interdisant pas l'usage du role presentation sur l'élément h1 le test 7.1.4 est conforme alors qu'il y a bien une perte d'information sémantique pour l'utilisateur. Enfin la spécification HTML5 indique bien <http://www.w3.org/html/wg/drafts/html/master/dom.html#wai-aria> par rapport à la table de recommandation " Authors are encouraged [...]" et pas "Authors must follow". Idem juste après " Authors may use" the ARIA role <http://www.w3.org/html/wg/drafts/html/master/infrastructure.html#attr-aria- role> and aria-* attributes" et pas "Authors must use". Imposer le respect de ces documents est donc bien un choix propre à Accessiweb 2. Au sujet des méthodes d'implémentations d'alternative aux images Aurélien écrit : "Les techniques WCAG autorisent lusage des attributs title, aria-label ou aria-labelledby sous certaines conditions pour donner une alternative à une image (cf échec 65). Le critère AW/HTML5 1.1 prévoit lusage de lattribut alt comme seul moyen permettant de restituer une alternative à une image." JPV écrit : Les techniques ARIA en question (aria-label et aria-labelledby) ne peuvent pas être prises en charge du fait du manque de support sur la base de référence. <http://www.accessiweb.org/index.php/glossaire-du-referentiel-accessiweb-htm l5aria.html#baserefbase> Par ailleurs la note "HTML5: Techniques for providing useful text alternatives <http://w3c.github.io/alt-techniques/> " interdit l'utilisation d'un title pour labelliser une image. Ne reste d'exploitable que la condition 1 de la procédure de test de la failure F65 <http://www.w3.org/TR/WCAG20-TECHS/failures.html#F65> , c'est-à-dire l'utilisation d'un attribut ALT. Je ne comprends pas l'intérêt que nous aurions à prendre en charge des techniques qui ne fonctionnent pas de manière suffisamment satisfaisante. C'est tout l'intérêt de la base de référence. Pour information la note sur le support UA de aria-labelledby par exemple : (aria 10 : http://www.w3.org/WAI/WCAG20/Techniques/ua-notes/aria#ARIA10) précise : "The use of the alt attribute is best practice and strongly encouraged. Especially for elements where the alt attribute can be used to provide text alternatives, authors must confirm accessibility support for aria-labelledby before relying on this technique in place of H37: Using alt attributes on img elements." On ne saurait être plus clair : tant que le support sera insuffisant on ne peut pas prendre en charge ces techniques. Oui j'ai bien mentionné "sous certaines conditions". La notion de base de référence et sa constitution est par ailleurs un élément propre à Accessiweb sur lequel les WCAG laissent la liberté à chacun de définir sa propre base de référence (Par exemple, si je vais une web app compte tenu de la base de référence actuelle je suis plutôt mal barré, si mes utilisateurs sont sur linux aussi). Le document "HTML5: Techniques for providing useful text alternatives" (document toujours en draft par ailleurs) n'est nullement mentionné par les techniques ou les WCAG il s'agit donc également d'un choix d'Accessiweb de tenir compte de ce document. Par ailleurs, comme indiqué par l'éditeur de la spec HTML5 <http://blog.paciellogroup.com/2014/04/short-note-alt/> si HTML5 impose encore l'usage de l'attribut alt c'est car il est également utile à l'utilisabilité. C'est tout à fait louable, c'est bon pour l'utilisateur et pour la qualité du site mais ce n'est pas simplement lié au respect des WCAG Mon article n'avait pas vocation de dire ce qui doit ou pas à être prix en compte mais à faire la lumière sur ce qui est un choix Accessiweb et ce qui est explicitement indiqué et imposé par les techniques WCAG. La jugement sur la "qualité" de ces choix, la manière, les conditions dont ils sont opérés et la façon dont ils sont indiqués aux utilisateurs du référentiel sont d'autres questions sur laquelle j'aurai l'occasion de revenir ultérieurement. 3. Sur l'utilisation du role présentation pour une image de décoration Aurélien écrit "Les techniques WCAG autorisent lusage du rôle presentation au regard de léchec F38 pour masquer une image aux aides techniques. Le critère AW/HTML5 1.2 prévoit lusage dun attribut alt="" sur les images de décoration comme seul moyen pour masquer une image aux aides techniques." JPV écrit : 1. La failure F38 <http://www.w3.org/TR/WCAG20-TECHS/failures.html#F38> n'est pas claire car elle semble autoriser un usage interdit par la SPEC HTML5 (cf référence plus bas), par ailleurs cette "technique" n'est pas reprise par la note technique de gestion des alternatives d'images ni par la spec HTML5 elle-même : (ref SPEC HTML5 : 4.7.1.1.9 A purely decorative image that doesn't add any information <http://www.w3.org/html/wg/drafts/html/CR/embedded-content-0.html#a-purely-d ecorative-image-that-doesn%27t-add-any-information> ). 2. La SPEC HTML5 autorise le rôle "presentation" uniquement dans le cas où le alt est nul (alt="" cf plus bas la référence citée) mais la table de recommandation de la note "USING ARIA IN HTML" <http://www.w3.org/TR/2013/WD-aria-in-html-20131003/#recommendations-table> l'interdit. Référence pour la SPEC HTML5 : "Allowed ARIA role attribute values: presentation role only, for an img element whose alt attribute's value is empty (alt=""), otherwise any role value." La situation étant pour le moment très confuse, il semble surtout opportun de ne pas implémenter cette technique qui n'offre aucun intérêt réel par rapport à l'utilisation d'un alt nul dont on peut sans effort garantir la robustesse et l'efficacité. Idem, il s'agit d'un choix Accessiweb de donner plus de valeur à ces documents HTML5 qu'à la technique F38. Ce qui semble sans intérêt pour certains peut peut être en avoir pour d'autres (la diversité des situations et l'inventivité des intégrateurs web est sans fin). A défaut d'attendre que les incohérences se règlent d'elle même et de dire pour l'instant n'en tenant pas donc pas compte, il me semble préférable de contribuer à l'amélioration des specs en question. J'ai notamment ouvert un bug sur le problème que tu soulève : https://www.w3.org/Bugs/Public/show_bug.cgi?id=26229 4. Sur les tests de pertinences des moyens alternatifs aux informations données par la couleur Aurélien écrit : "Les techniques WCAG laissent librement le choix entre différentes techniques tel que G14 et G182 pour donner un moyen daccès à linformation autre que la couleur. Le critère AW/HTML5 3.2 juge de la pertinence de ce choix." JPV écrit : Je ne comprends pas la remarque. G14 comme G182 vérifient la pertinence. Technique G14 <http://www.w3.org/TR/WCAG20-TECHS/G14.html> , condition du test : "Check that the information conveyed is also available in text and that the text is not conditional content." La première partie du test ("Check that the information conveyed is also available in text") teste la présence d'un autre moyen (Critère AW 3.1 <http://www.accessiweb.org/index.php/accessiweb-html5aria-liste-deployee.htm l#couleurs> ) la seconde partie du test ("and that the text is not conditional content") teste la pertinence de cet autre moyen (critère AW 3.2). La technique G182 <http://www.w3.org/TR/WCAG20-TECHS/G182.html> , si l'on tient absolument à l'utiliser ici, possède la même mécanique : 1. Locate all instances where the color of text is used to convey information. 2. Check that any text where color is used to convey information is also styled or uses a font that makes it visually distinct from other text around it. donc, par exemple : Critère 3.1 (présence) : oui le texte est stylé de manière différente Critère 3.2 (pertinence) : oui le style différent utilisé permet bien de faire une distinction visuelle entre le texte et son environnement. Dans les deux techniques, on voit bien qu'il existe un critère de pertinence. C'est une garantie forte que l'objectif de ces techniques est effectivement atteint, et c'est l'idée qui est reprise dans le référentiel AccessiWeb. Non la technique G182 ne juge pas la pertinence de la technique employée, il vérifie juste que la technique utilisée permet d'être " visually distinct". Il est donc laissé libre choix à la personne d'apporter le complément graphique à la couleur qu'elle veut à partir du moment où cela permet de distinguer visuellement autrement que par la couleur (exemple une mise en gras via css qui ne serait donc pas restitué quand css est désactivé ou css utilisateur activé). Accessiweb impose la pertinence via le glossaire. Mais il est possible que je fasse erreur si tu me confirme qu'il est possible de faire une modification purement visuelle pour être conforme au critère 3.2 (dans ce cas je suis preneur de la définition de " accessible à tous" qui figure dans la définition de pertinence associée à ce critère dans le glossaire). 5. Sur le contrôle du volume sonore d'un son lancé automatiquement Aurélien écrit : "Les techniques WCAG demandent de pouvoir couper le son ou de pouvoir contrôler le volume si le concepteur choisit de permettre à lutilisateur de le régler cf G60 - G170 - G171 - F23). Les critères AW/HTML5 4.18 et 4.20 imposent dans tous les cas la capacité de pouvoir contrôler le volume sonore dun élément via le terme "fonctions de contrôle" du glossaire." JPV écrit : Ce qui nous est proposé ici consiste à dire "si le concepteur autorise l'utilisateur à contrôler le volume d'un son lancé automatiquement, alors il faut vérifier que l'utilisateur dispose d'un moyen de contrôler le son lancé automatiquement." Ce qui par effet d'escalier autoriserait le concepteur à interdire à l'utilisateur de contrôler le son lancé automatiquement ce qui est en contradiction flagrante avec la failure F23 <http://www.w3.org/TR/WCAG20-TECHS/failures.html#F23> : "Check that there is a way in a Web page to turn off any sound that plays automatically for more than three seconds." Par ailleurs, la définition du glossaire "fonctionalités de contrôle (media temporel) <http://www.accessiweb.org/index.php/glossaire-du-referentiel-accessiweb-htm l5aria.html#mFonctionControle> " n'a rien à voir avec le critère 4.18 (pas de lien à partir du critère vers cette définition) et concerne exclusivement le critère 4.20. Non pas du tout, ça veut juste dire que l'auteur peut choisir de ne pas permettre de régler de façon spécifique le niveau du volume. Cela n'as rien à voir avec le fait de permettre de couper le son qui est effectivement obligatoire. 6. Sur l'obligation d'un élément CAPTION pour titrer un tableau de donnée Aurélien écrit : "Les techniques WCAG imposent la présence dun élément caption si un titre de tableau est visuellement présent dans la page au regard de la technique h39. Le critère AW/HTML5 5.4 impose lusage dun élément caption dans tous les cas." JPV écrit La procédure de test de la technique H39 <http://www.w3.org/TR/WCAG20-TECHS/H39.html> est la suivante : Check for layout tables: determine whether the content has a relationship with other content in both its column and its row. If no," the table is a layout table. If yes," the table is a data table. If the table is a layout table, check that the table does not include a caption element. If the table is a data table and it includes a caption element, check that the caption identifies the table If both a summary attribute and a caption element are present for this data table, check that the summary does not duplicate the caption. Il n'est à aucun moment fait référence à un titre « visuellement présent ». Le document décrivant l'accessible name d'un tableau de données ("HTML to Platform Accessibility APIs implementation Guide <http://rawgit.com/w3c/html-api-map/master/index.html#table-element> " ) est particulièrement clair : 6.9.1 table element accessible name calculation (https://dvcs.w3.org/hg/html-api-map/raw-file/tip/Overview.html#table) Use aria-labelledby Otherwise use aria-label Otherwise use caption element Otherwise use the title attribute Otherwise use the summary attribute If none of the above yield a usable text string there is no accessible name aria-labelledby, aria-label et title n'ayant pas un support suffisant sur la base de référence, et summary étant obsolète non-conforme en HTML5, reste uniquement le caption pour titrer un tableau. Quant au titrage obligatoire d'un tableau de données cela réfère à l'utilisation du mode de navigation de tableau en tableau utilisé par les utilisateurs de lecteur d'écran. Dans ce mode navigation il est important que le tableau soit titré sinon il ne pourrait pas être clairement identifié. Il s'agit du même dispositif et du même but que le titrage des vidéos par exemple. Je ne vois pas la différence qu'il peut y avoir, en tout cas de problème, qui pourrait être relevé par rapport à WCAG. ---------------------------- Oui ce point peut être justifiable selon les critères retenu par Accessiweb mais encore une fois ce n'est pas la question soulevé par mon article. Le descriptif de la technique dit notamment " The objective of this technique is to programmatically associate captions for data tables where captions are provided in the presentation." Par ailleurs, l'étape 3 du test "If the table is a data table and it includes a caption element, check that the caption identifies the table" dit bien que si c'est un tableau de donnée et qu'il contient un caption, on doit vérifier sa pertinence, il ne dit pas si c'est un tableau de donné, vérifie qu'il y a un caption puis vérifie qu'il est pertinent. Je maintiens donc qu'il s'agit là encore d'un choix fait par Accessiweb. 7. Au sujet de la structuration des en-têtes d'un tableau de donnée Aurélien écrit "Les techniques WCAG autorisent lusage de simple td avec un attribut scope ou des role rowheader ou columnheader pour signaler des entêtes de lignes ou de colonnes au regard de la l'échec F91. Le critère AW/HTML5 5.6 impose lusage déléments th." JPV écrit : Les liaisons aria "columheader" et "rowheader" n'ont pas un support suffisant sur la base de référence (par exemple via NVDA). L'utilisation de "scope" sur des TD n'a pas non plus un support suffisant (par exemple via NVDA/IE) Il n'est donc pas possible d'utiliser actuellement ces techniques, à moins de pouvoir avoir des tests concluants. Je ne vais pas me répéter à propos de la base de référence ;) 8. Au sujet des propriété arai-label et aria-labelledby pour expliciter un lien Aurélien écrit: "Les techniques WCAG autorisent le recours à aria-label ou aria-describedby pour restituer des informations de contexte sur lintitulé dun lien via léchec F63. Le critère AW/HTML5 6.1 ne le prévoit pas." JPV écrit: Le support de ces deux techniques est très récent (NVDA échouait jusqu'à présent), il faudrait refaire l'ensemble des tests. Si les tests sont concluants, il faudra en effet compléter la définition du glossaire sur le "contexte de lien" idem puisque basé là encore sur la base de référence ---------------------------- 9. Au sujet des listes Aurélien écrit " Les techniques WCAG demandent à ce que les listes simulées visuellement soit balisées comme telles (via (ol / ul notamment) au regard de la procédure de test H48. Le critère AW/HTML5 9.3 impose lusage des éléments de listes sur tous les éléments de listes sans définition de ce quest une liste (est-ce quune suite dactualités (image + titre + intro + lien) balisée à laide de titres de hiérarchie est également une liste ?)." JPV écrit : Le critère AW implémente très exactement la procédure de test de la technique H48 <http://www.w3.org/TR/WCAG20-TECHS/H48.html> 1. Check that content that has the visual appearance of a list (with or without bullets) is marked as an unordered list. 2. Check that content that has the visual appearance of a numbered list is marked as an ordered list. 3. Check that content is marked as a definition list when terms and their definitions are presented in the form of a list. La restriction que faisait RGAA (auquel la remarque semble se référer en creux) au cas des listes associées à un "marqueur visuel" était une erreur d'interprétation de la technique H48 qui précise pour le cas des listes non-ordonnées : « with or without bullets ». La définition d'une liste est en cours de réflexion et sera prochainement proposée pour compléter le glossaire. Bonne nouvelle, pour la définition cela dit je reviens sur la technique H48. Sa description dit notamment : " Although the use of this markup can make lists more readable, not all lists need markup" et également " When markup is used that visually formats items as a list but does not indicate the list relationship" Il faudrait donc pour satisfaire ce critère une définition permettant de façon univoque d'identifier une liste qui visuellement peut ne pas ressembler à une liste mais qui nécessiterait quand même un balisage sous forme de liste. Hormis le cas bien particulier des menus de navigation cela me semble à titre personnel proche de l'impossible sans avoir un résultat hautement interprétable par chacun. 10. Au sujet des images en propriété de fond associée à un texte caché Aurélien écrit "Les techniques WCAG notamment la technique C30 demandent en complément dune image de fond porteuse dinformation et dun texte masqué via css davoir un bouton pour désactiver cette solution et avoir accès au texte. La procédure de test de léchec F3 indique quant à elle que linformation doit être disponible même quand limage css nest pas affichée " the information is provided to assistive technologies and is also available when the CSS image is not displayed." Le critère AW/HTML5 10.2 autorise par le biais du terme "contenu visible" du glossaire lusage de texte masqué seul pour rendre accessible une information rendue visible par le biais dune image de fond." JPV écrit Il s'agit d'une incompréhension de la définition de glossaire <http://www.accessiweb.org/index.php/glossaire-du-referentiel-accessiweb-htm l5aria.html#mContVisible> qui interdit, au contraire, l'utilisation d'une image en propriété de fond associée à un texte caché sauf lorsque ce dernier est "visible", CSS activé, lorsque les images sont désactivées. De ce point de vue la remarque est sans fondement. La technique C30 n'a rien à voir avec les images en propriété de fond mais avec l'utilisation d'image-texte (critère 1.8 qui implémente correctement la technique C30 <http://www.w3.org/TR/WCAG20-TECHS/css.html#C30> y compris en ce qui concerne le mécanisme de remplacement). La technique C30, bien qu'effectivement rattachée au critère WCAG sur l'utilisation d'image texte, traite bien tout de même de l'utilisation de CSS pour afficher visuellement une image de fond (contenant du texte) à la place d'un texte dans le html. Concernant ma possible incompréhension de la définition du glossaire, elle souligne peut être le manque de clarté de celle ci. Par ailleurs, elle ne visait pas le cas visible avec CSS activé et images désactivées mais le cas CSS activé et mode fort contraste activé (ou css utilisateur) ce qui est couramment le cas chez les utilisateurs mal voyant et me semble bien être couvert par l'échec F3. 11. Au sujet du pixel pour les tailles de caractères Aurélien écrit "Les techniques WCAG ninterdisent pas explicitement lusage du pixel pour dimensionner un texte. Léchec F80 vise explicitement les contrôles de formulaire. Léchec F69 vise le cas de perte dinformations quand on agrandit le texte (avec les pixels dans certains cas ils ne sagrandit pas donc le point ne peut s'appliquer) c'est le mix taille de bloc fixe / taille du texte qui s'agrandit qui est problématique. La technique G179 concerne également le cas quand on agrandit le texte par rapport aux tailles de blocs fixes. Enfin, les techniques C12, C13 et C14 s'appliquent uniquement quand on utilise également un dimensionnement relatif des blocs "Ensuring that text containers resize when the text resizes AND using measurements that are relative to other measurements in the content by using one or more of the following techniques" (le AND est en gras dans les sufficient techniques for 1.4.4). Par ailleurs, les solutions de recours au zoom du navigateur ou à des boutons dagrandissement ne sont pas prises en compte dans Accessiweb HTML5 (G142 et G178) bien que faisant explicitement partie de techniques suffisantes. Le critère AW/HTML5 10.4 interdit lusage du pixel pour dimensionner le texte." JPV écrit Oui, cette position qui, rappelons-le, n'est pas en contradiction avec WCAG, est assumée par le groupe d'expert référents depuis la version AccessiWeb 1.1. Elle est à nouveau soumise à validation pour le RGAA 3. Qu'est ce qui n'est pas contradictoire ? l'interdiction du pixel ? Si oui moi cela me semble bien contradictoire quand aucune technique n'interdit de s'en servir. Si il s'agit de la non présence des techniques G142 et G178 on est d'accord ce n'est pas contradictoire mais bien un choix d'Accessiweb (et partagé par RGAA V2) et non de l'implémentation littéral des techniques. 12. Au sujet de l'utilisation de title pour les input de type submit Aurélien écrit : "Aucune technique WCAG nautorise lutilisation de title ou d'ARIA sur les inputs submit. Le critère AW/HTML5 11.9 autorise leur utilisation." JPV écrit Pour ARIA il s'agit des techniques ARIA 16 <http://www.w3.org/TR/WCAG20-TECHS/aria.html#ARIA16> et ARIA 14 <http://www.w3.org/TR/WCAG20-TECHS/aria.html#ARIA14> : ARIA16: Using aria-labelledby to provide a name for user interface controls ARIA14: Using aria-label to provide an invisible label where a visible label cannot be used Pour le title il s'agit de la technique H65 <http://www.w3.org/TR/WCAG20-TECHS/html.html#H65> : H65: Using the title attribute to identify form controls when the label element cannot be used Ces trois techniques utilisent des attributs ou des propriétés ARIA universelles qui peuvent être utilisés sur tout les éléments, par ailleurs les dispositifs pris en charge (title et ARIA) sont fonctionnels. Merci pour ces références qui sont effectivement manquantes dans les correspondances établies de la version actuelle du référentiel AWHTML5. 13. Au sujet de la mention "erreur sur le formulaire" dans le titre de la page Aurélien écrit "Aucune technique WCAG nimpose la présence dans le titre des pages la mention derreurs de saisie dans un formulaire (cf H25, G88, F25). Le critère AW/HTML5 11.10 impose par le biais du terme "contrôle de saisie" dans le glossaire le fait davoir lindication dune erreur de saisie dans le title des pages en cas d'erreur." JPV écrit C'est exact, il n'existe pas de technique spécifique dans WCAG en dehors de celle demandant un titre de page pertinent qui pourrait suffire à vérifier ce point. Cette position a un objectif avant tout opérationnel, elle est assumée depuis AW 1.0 et résout un des principaux problèmes relevés par les utilisateurs lors de l'utilisation de formulaire. Je suis content de voir que nous partageons le même avis. Il s'agit bien d'un choix Accessiweb. Je rappelle que mon billet de blog s'appelle : "Respecter les techniques WCAG ou pas telle est la question ?" pas "Accessiweb à tort et fait n'importe quoi". A cette question est ce que le référentiel Accessiweb actuel respecte les techniques WCAG, pour moi au regard de tout ces éléments ma réponse ne peut être que non pas en totalité. Des choix ont été fait, c'est un fait ;)/ J'aimerai qu'il soit assumés et indiqués comme tel et que les conditions / raisons / critères entrant en jeu pour ces choix soient systématiquement précisés dans le référentiel. -- Aurélien Levy ---- Temesis _______________________________________________ liste_gta mailing list [email protected] http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org -- Armony ALTINIER Directrice ACS Horizons Consultante et formatrice en accessibilité numérique * Pro : acs-horizons.fr * Twitter : @armonyaltinier <https://twitter.com/armonyaltinier> * Livre : accessibiliteweb-lelivre.com _______________________________________________ liste_gta mailing list [email protected] http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
