1 / 50

AccessiWeb HTML5/ARIA

AccessiWeb HTML5/ARIA. Séminaire AccessiWeb Juin 2013. AW HTML5/ARIA. Juin 2012. AW 2.2 n'est pas adapté à HTML 5. Préparation. Les différences de fond et les évolutions sont trop nombreuses pour porter AW 2.2 vers HTML 5. Novembre 2012. Décembre 2012.

kalei
Download Presentation

AccessiWeb HTML5/ARIA

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. AccessiWebHTML5/ARIA Séminaire AccessiWeb Juin 2013

  2. AW HTML5/ARIA Juin 2012 AW 2.2 n'est pas adapté à HTML 5 Préparation • Les différences de fond et les évolutions sont trop nombreuses pour porter AW 2.2 vers HTML 5 Novembre 2012 Décembre2012 • HTML5 supprime ou modifie des éléments requis par AW 2.2 • Par exemple summary pour les tableaux, longdesc pour les images • Outline pour le titrage… • La notion d’alternative et de compatibilité pour Javascript telle que définie par AW 2.2 n’est pas adaptée à HTML 5 • AW 2. ne prend pas en charge l’API ARIA Proposition Adaptation Préparation Référentiel Mars2013 Publication Adaptation Juin 2013 Référentiel HTML5 / ARIA Séminaire AccessiWeb Juin 2013

  3. AW HTML5/ARIA Généralités Séminaire AccessiWeb Juin 2013

  4. AW HTML5/ARIA • Modification de la nomenclature (niveaux : A, AA, AAA !) • Très peut de nouveaux critères (on reste à 133 critères) • Les nouveaux éléments sont implémentés au niveau des tests • Pris en charge d'ARIA chaque fois que nécessaire : • Présence/pertinence des rôles ARIA nécessaires • Test de la restitution AT chaque fois que nécessaire • Création de "notes techniques" chaque fois que nécessaire liées aux critères sur le même modèle que le glossaire • Création d'une "base de référence" pour la compatibilité avec l'accessibilité RéférentielAW HTML5 Notes Techniques Notes Techniques Base de référence Glossaire Glossaire Séminaire AccessiWeb Juin 2013

  5. AW HTML5/ARIA Quelques exemples… Séminaire AccessiWeb Juin 2013

  6. AW HTML5/ARIA Images Séminaire AccessiWeb Juin 2013

  7. AW HTML5/ARIA Images • Prise en charge de SVG et CANVAS • Prise en charge ARIA • propriété aria-label pour labelliser une image SVG • Role "présentation" pour une image de décoration (interdiction) • Création d'un critère spécifique sur les images légendées • Figure • Figcaption • Role "group" • Prise en charge de title sur l'élément IMG • Obligatoirement identique au alt • Test de restitution des alternatives implémentée dans SVG via aria-label ou <desc> Séminaire AccessiWeb Juin 2013

  8. AW HTML5/ARIA Images Critère  1.1 [A] Chaque image a-t-elle une alternative textuelle ? • Test 1.1.4 : Chaque image vectorielle (balise <svg>)  vérifie-telle une de ces conditions ?    o La balise svg possède un attribut aria-label    o Un élément <desc> est présent Note techniqueA l'exception de svg, l'utilisation des attributs aria-label et aria-labelledby permettant de créer une alternative ou de lier l'image à un passage de texte faisant office d'alternative ne peuvent pas être utilisés par manque de support des technologies d'assistance.La spécification SVG préconise d'utiliser un élément <title> pour la description "courte" et un élément <desc> pour la description longue. Actuellement seul l'élément <desc> est correctement restitué par les technologies d'assistance. L'usage de l'élément <title> est donc considéré comme incompatible avec l'accessibilité. Séminaire AccessiWeb Juin 2013

  9. AW HTML5/ARIA • Critère 1.3 [A] Pour chaque image porteuse d'information ayant une alternative textuelle, cette alternative est-elle pertinente (hors cas particuliers) ? • Test 1.3.1 : Chaque image porteuse d'information (balise img) ayant un attribut alt vérifie-t-elle ces conditions (hors cas particuliers) :    o Le contenu de l'attribut alt est pertinent    o S'il est présent le contenu de l'attribut title est identique au contenu de l'attribut alt • Test 1.3.6: Chaque image vectorielle porteuse d'information (balise svg) et possédant une alternative vérifie-t-elle une de  ces conditions  (hors cas particuliers)?    o La balise svg possède un attribut aria-label dont le contenu est pertinent et identique à l'attribut title s'il est présent    o La balise svg possède un élément <desc> dont le contenu est pertinent et identique à l'attribut title de la balise svg s'il est présent    o Un lien adjacent permet d'accéder à une alternative dont le contenu est pertinent et identique à l'attribut title de la balise svg s'il est présent • • Test 1.3.7: Pour chaque image vectorielle porteuse d'information (balise svg) et possédant une alternative, cette alternative est-elle correctement restituée par les technologies d'assistance ? Séminaire AccessiWeb Juin 2013

  10. AW HTML5/ARIA • Critère 1.6 [A] Chaque image porteuse d'information a-t-elle, si nécessaire, une description détaillée ? • Test 1.6.5: Chaque image vectorielle (balise <svg>)  qui nécessite une description détaillée vérifie-t-elle une de ces conditions ?    o Il existe un attribut aria-label contenant une référence à une description détaillée adjacente à l'image vectorielle    o Il existe un élément <desc> contenant une référence à une description détaillée adjacente à l'image vectorielle    o Il existe un élément <desc> contenant la description détaillée    o Il existe un lien adjacent (via une url ou une ancre) permettant d'accéder au contenu de la description détaillée • Test 1.6.6: Pour chaque image vectorielle (balise <svg>)  qui implémente une référence à une description détaillée adjacente via un attribut aria-label ou un élément <desc>, cette référence  est-elle correctement restituée par les technologies d'assistance ? Séminaire AccessiWeb Juin 2013

  11. AW HTML5/ARIA Prise en charge de <figure> et <figcaption> Spécification HTML5 Fallback note WCAG <figure> <img src="pic.jpg"> <figcaption> Légende de l'image </figcaption> </figure> <figure role="group" > <img src="pic.jpg" alt="photo 1" > <figcaption> Légende de l'image (photo 1)</figcaption> </figure> • L'atrribut ARIA role="group" permet de créer une relation explicite entre l'image et sa légende • La présence d'un "label" (nom de l'image) dans l'alternative permet de créer une relation implicite entre l'image et sa légende Séminaire AccessiWeb Juin 2013

  12. AW HTML5/ARIA Critère 1.10 [A] Chaque légende d'image est-elle, si nécessaire, correctement reliée à l'image correspondante ? • Test 1.10.1 : Chaque image légendée (balise img ou input de type image associée à une légende adjacente) vérifie-telle, si nécessaire, ces conditions ?    o L'image (balise img) et sa légende sont contenues dans un élément figure    o L'élément figure possède un attribut role="group"    o Le contenu de l'attribut alt de l'image contient une référence à la légende adjacente    o L'attribut title de l'image s'il est  présent, est strictement identique au contenu de l'attribut alt Note technique (extrait)Bien que recommandé par HTML5, la note WCAG stipule que le title ne peut pas être utilisé pour "labelliser" l'image.Les attributs aria-label, aria-labelledby et aria-describedby ne peuvent pas être utilisés actuellement par manque de support par les technologies d'assistance. Séminaire AccessiWeb Juin 2013

  13. AW HTML5/ARIA Cadres Couleurs Pas de changement Séminaire AccessiWeb Juin 2013

  14. AW HTML5/ARIA Multimédia Séminaire AccessiWeb Juin 2013

  15. AW HTML5/ARIA Multimédia • Peu de changements • Prise en charge de VIDEO et AUDIO par le glossaire • Prise en charge de <track> chaque fois que nécessaire Critère 4.3 [A] Chaque média temporel synchronisé pré-enregistré a-t-il, si nécessaire, des sous-titres synchronisés (hors cas particuliers) ? • Test 4.3.2: Pour chaque média temporel synchronisé pré-enregistré  possédant des sous-titres synchronisés diffusés via un élément <track>, l'élément <track>  possède-t-il un attribut kind="captions" Séminaire AccessiWeb Juin 2013

  16. AW HTML5/ARIA Tableaux Séminaire AccessiWeb Juin 2013

  17. AW HTML5/ARIA Tableaux • Abandon du support de SUMMARY • Nouvelle définition de glossaire "tableaux de données complexe" • Restriction de l'utilisation des techniques de summary HTML5 aux tableaux de données complexe • Support du rôle "présentation" pour déclarer un tableau de mise en forme Séminaire AccessiWeb Juin 2013

  18. AW HTML5/ARIA Critère 5.1 [A] Chaque tableau de données complexe a-t-il un résumé ?• Test 5.1.1 : Pour chaque tableau de données complexe (balise table) un résumé est-il disponible dans la balise <caption> ?Note techniqueLa spécification propose plusieurs méthodes pour lier un résumé à un tableau (tableau lié à un passage de texte avec aria-describedby, tableau groupé via figure avec le résumé en texte adjacent, tableau groupé avec figure avec le résumé dans un élément figcaption, résumé dans un élément details dans l'élément caption).Ces méthodes n'ont pas un support suffisant pour être utilisées actuellement. Séminaire AccessiWeb Juin 2013

  19. AW HTML5/ARIA Critère 5.3 [A] Pour chaque tableau de mise en forme, le contenu linéarisé reste-t-il compréhensible ?• Test 5.3.1 : Chaque tableau de mise en forme vérifie-t-il ces conditions ?    o le contenu linéarisé reste  compréhensible    o la balise <table> possède un attribut role="presentation" La spécification recommande de mapper un tableau de mise en forme avec le rôle "présentation"."If a table is to be used for layout it must be marked with the attribute role="presentation" for a user agent to properly represent the table to an assistive technology and to properly convey the intent of the author to tools that wish to extract tabular data from the document." Séminaire AccessiWeb Juin 2013

  20. AW HTML5/ARIA Liens Séminaire AccessiWeb Juin 2013

  21. AW HTML5/ARIA Liens Aucun changement Html 5 autorise l'utilisation d'éléments de type block dans un lien (A HREF). Ce type de lien est supporté par toutes les AT mais peut causer des problèmes de restitution. Cette utilisation est à éviter Problème potentiels • NVDA /JAWS : répétition de liens pour chaque élément de contenus sur certaines fonctionnalités • VOICE OVER : texte répétés plusieurs fois de suite • JAWS : disparition des titres via la liste des titres de la page Séminaire AccessiWeb Juin 2013

  22. AW HTML5/ARIA Scripts Séminaire AccessiWeb Juin 2013

  23. AW HTML5/ARIA Scripts • Abandon de l'obligation à des alternatives Javascript • Obligation de respecter les motifs de conception ARIA • Obligation de respecter les interactions clavier définit par les motifs de conception ARIA • Exigence réduite aux touches principales • Obligation de respecter les recommandations de la spécification et de la note technique "Using ARIA in HTML" sur : • Les surcharges de role (par exemple <NAV role="NAVIGATION"> • Les restrictions de modification du role natif HTML d'un élément (tableau de référence de la note sur ARIA) Séminaire AccessiWeb Juin 2013

  24. AW HTML5/ARIA Critère 7.1 [A] Chaque script est-il, si nécessaire, compatible avec les technologies d'assistance ? • Test 7.1.3 : Chaque script qui génère ou contrôle un composant d'interface via des rôles, des états ou des propriétés définis par l'API ARIA vérifie-t-il, si possible, une de ces conditions ?   o Le composant d'interface est conforme au motif de conception défini par l'API ARIA   o Un composant d'interface présent sur la page, permettant d'accéder aux mêmes fonctionnalités, est conforme au motif de conception défini par l'API ARIA   o Une alternative accessible permet d'accéder aux mêmes fonctionnalités. • Test 7.1.6: Pour chaque script qui génère ou contrôle un composant d'interface via des rôles, des états ou des propriétés définis par l'API ARIA respecte-t-il une de ces conditions :   o Le composant d'interface est correctement restitué par les technologies d'assistance   o Une alternative accessible permet d'accéder aux mêmes fonctionnalités. Séminaire AccessiWeb Juin 2013

  25. AW HTML5/ARIA Critère 7.3 [A] Chaque script est-il contrôlable par le clavier et la souris (hors cas particuliers) ? • Test 7.3.4 : Chaque composant d'interface implémenté via un rôle défini par l'API ARIA et correspondant à un motif de conception respecte-t-il, si possible, ces conditions ?   o Les interactions au clavier sont conformes au comportement défini par le motif de conception pour les touches Escape, Barre d'espace, Tabulation et Flèches de direction au moins   o Un composant d'interface présent sur la page, permettant de réaliser la même action, possède des interactions au clavier conformes au comportement défini par le motif de conception, pour les touches Escape, Barre d'espace, Tabulation et Flèches de direction au moins   o Une alternative  permettant d'accéder aux mêmes fonctionnalités est contrôlable par le clavier et à la souris. Séminaire AccessiWeb Juin 2013

  26. AW HTML5/ARIA Eléments Obligatoires Pas de changement Séminaire AccessiWeb Juin 2013

  27. AW HTML5/ARIA Structuration de l'information Séminaire AccessiWeb Juin 2013

  28. AW HTML5/ARIA Structuration de l'information • Prise en charge des nouveaux éléments • HEADER, NAV, MAIN, FOOTER rendus obligatoires pour structurer le document • Test de cohérence de l'OUTLINE (utilisation des éléments sectionnants) • Interdiction de l'utilisation exclusive de H1, obligation d'utiliser des titres Hx cohérent Séminaire AccessiWeb Juin 2013

  29. AW HTML5/ARIA • Critère 9.1 [A] Dans chaque page Web, l'information est-elle structurée par l'utilisation appropriée de titres ?• Test 9.1.1 : Dans chaque page Web, y a-t-il un titre de niveau 1 (balise h1 ou balise possédant un role ARIA "heading" associé à une propriété aria-level="1") ? • Test 9.1.2 : Dans chaque page Web, la hiérarchie entre les titres (balises h ou balise possédant un role ARIA "heading") est-elle pertinente ?• Test 9.1.3 : Dans chaque page Web, chaque titre (balises h ou balise possédant un role ARIA "heading") nécessaire à la structure de l'information est-il présent ?• Test 9.1.4 : Dans chaque page Web, chaque titre (balises h ou balise possédant un role ARIA "heading") est-il pertinent ? Séminaire AccessiWeb Juin 2013

  30. AW HTML5/ARIA Test de cohérence de l'outline <body> <article> <nav> <aside> <H2> <section> <H2> <H3> Séminaire AccessiWeb Juin 2013

  31. AW HTML5/ARIA Critère 9.2 [A] Dans chaque page Web, la structure du document est-elle cohérente ?• Test 9.2.1 : Dans chaque page Web, la structure du document vérifie-t-elle ces conditions ?   o La zone d'en-tête principale est structurée via une balise <header>   o Les zones de navigation principales et secondaires sont structurées via une balise <nav>   o La balise <nav> est réservée à la structuration des zones de navigations principales et secondaires   o La zone de contenu principal est structurée via une balise <main>   o La structure du document utilise une balise <main> unique   o La zone de pied-de-page est structurée via une balise <footer>• Test 9.2.2: dans chaque page web l'arborescence du document est-elle cohérente ? Séminaire AccessiWeb Juin 2013

  32. AW HTML5/ARIA Présentation de l'information Séminaire AccessiWeb Juin 2013

  33. AW HTML5/ARIA Présentation de l'information • Prise en charge de aria-hidden et de hidden • Test de cohérence de l'utilisation de aria-hidden pour interdire la vocalisation • Test de cohérence de l'utilisation de hidden en relation avec le statut visible ou caché des propriétés CSS display:none et visibility:visible Critère 10.13 [A] Pour chaque page Web, les textes cachés sont-ils correctement restitués par les technologies d'assistance ?• Test 10.13.2 : Dans chaque page Web, chaque texte caché qui utilise une propriété ARIA aria-hidden vérifie-t-il une de ces conditions ?    o Le texte n'a pas vocation à être restitué par les technologies d'assistance   o La valeur de la propriété ARIA aria-hidden est cohérente avec l'état visible ou caché du texte Séminaire AccessiWeb Juin 2013

  34. AW HTML5/ARIA Formulaire Séminaire AccessiWeb Juin 2013

  35. AW HTML5/ARIA Formulaire • Prise en charge des techniques de labellisation ARIA pour les champs et les boutons : • aria-label • aria-labelledby • Prise en charge des messages automatiques d'aide à la saisie ou de gestion des erreurs utilisés par les nouveaux types de champs de formulaire HTML5 • Prise en charge de aria-required et de required pour les saisies obligatoires • Prise en charge de aria-describedby pour lier un message d'aide à la saisie ou d'erreur Séminaire AccessiWeb Juin 2013

  36. AW HTML5/ARIA Critère 11.1 [A] Chaque champ de formulaire a-t-il une étiquette ?• Test 11.1.1 : Chaque champ de formulaire, vérifie-t-il une de ces conditions ?    o Le champ de formulaire possède un attribut title   o Une étiquette (balise label) est associée au champ de formulaire   o Le champ de formulaire possède une propriété aria-label   o Le champ de formulaire possède un attribut aria-labelledby référençant un passage de texte identifié Critère 11.10 [A] Dans chaque formulaire, le contrôle de saisie est-il utilisé de manière pertinente ? • Test 11.10.1 : Pour chaque formulaire, les champs obligatoires vérifient-ils une de ces conditions ?   o L'indication de champ obligatoire est indiquée dans l'étiquette (balise label, attribut title, propriété aria-label, texte lié via la propriété aria-labelledby)  du champ de formulaire   o L'indication de champ obligatoire est indiquée par un passage de texte avant le champ de formulaire   o L'indication de champ obligatoire est indiquée via un attribut required   o L'indication de champ obligatoire est indiquée via la propriété ARIA aria-required   o L'indication de champ obligatoire est indiquée par un passage de texte lié par la propriété ARIA aria-describedby Séminaire AccessiWeb Juin 2013

  37. AW HTML5/ARIA • Test 11.10.4 : Pour chaque formulaire, les erreurs de saisie vérifient-elle une de ces conditions ?   o L'erreur de saisie est indiquée dans l'étiquette (balise label, attribut title, propriété ARIA aria-label, texte lié via la propriété ARIA aria-labelledby)  du champ de formulaire   o L'erreur de saisie est indiquée par un passage de texte avant le champ de formulaire   o Le champ de formulaire possède un type qui produit de manière automatique un message d'erreur de saisie   o L'erreur de saisie est indiquée par un passage de texte lié par la propriété ARIA aria-describedby • Test 11.10.5 : Chaque erreur de saisie qui utilise la propriété ARIA aria-label doit être accompagnée d'un passage de texte avant le champ du formulaire, cette règle est-elle respectée ? Séminaire AccessiWeb Juin 2013

  38. AW HTML5/ARIA Navigation Séminaire AccessiWeb Juin 2013

  39. AW HTML5/ARIA Navigation • Prise en charge des role aria landmark, obligation d'utilisation de • banner, navigation, main, contentinfo, search Critère 12.10 [A] Dans chaque page Web, les groupes de liens importants (menu, barre de navigation...) et la zone de contenu sont-ils identifiés ? • Test 12.10.4 : Dans chaque page Web, la structure du document vérifie-t-elle ces conditions ?   o La zone d'en-tête de la page possède un rôle ARIA "banner"   o Le menu de navigation principal possède un rôle ARIA "navigation"   o La zone de contenu principal possède un rôle ARIA "main"   o La zone de pied-de-page possède un rôle ARIA "contentinfo"   o Le champ de saisie du moteur de recherche sur le site possède un rôle "search"   o Les rôles "banner","navigation","main","contentinfo" et "search" sont uniques dans la page. Séminaire AccessiWeb Juin 2013

  40. AW HTML5/ARIA Consultation Pas de changement Séminaire AccessiWeb Juin 2013

  41. AW HTML5/ARIA Base de référence Séminaire AccessiWeb Juin 2013

  42. AW HTML5/ARIA Base de référence L'établissement de la base de référence nécessaire pour établir qu'un dispositif HTML5/ARIA est "compatible avec l'accessibilité" est établie sur la base de la collecte des données disponibles sur les usages des Technologies d'Assistance impactées. 1. Quatre technologies d'assistances (NVDA, JAWS, WINDOW-EYES, VOICE OVER) représentent 84% des usages "habituels".2. Deux systèmes d'exploitation (WINDOWS XP+, IOS/OSX) couvrent plus de 95% des usages3. Trois navigateurs (INTERNET EXPLORER, FIREFOX, SAFARI) couvrent plus de 90% des usages par les utilisateurs de technologies d'assistance.4. INTERNET EXPLORER 8 ne présente pas de support suffisant et ne peut pas être considéré. Sur cette base il est apparu que l'on pouvait considérer (en attendant une généralisation du support de l'accessibilité par l'ensemble des technologies d'assistance, des systèmes d'exploitation et des navigateurs) que l'ensemble des éléments définis ci-dessus permettait de couvrir environ 80% des usages habituels des utilisateurs impactés. Séminaire AccessiWeb Juin 2013

  43. AW HTML5/ARIA Base de référence Technologies d'assistance d'usage habituel Source : Enquête WEBAIM 2012 Séminaire AccessiWeb Juin 2013

  44. AW HTML5/ARIA Base de référence • La base de référence est établie en tenant compte de plusieurs facteurs : • La proportion d'usage des technologies d'assistance :Quatre d'entre-elles (NVDA, JAWS, VO, Windows Eyes) couvrent 84% des usages (Webaimsurvey #4 – 2012) • La proportion d'usage des systèmes d'exploitation :Deux d'entre eux (Windows et OSX) couvrent plus de 95% des usages • L'usage de la plateforme Linux est confidentiel et distribué sur un grand nombre de versions. • La proportion d'usage des Navigateurs et de leurs versions • Trois d'entre eux sont gratuits et mis à jour automatiquement (Chrome, Firefox et Safari), Firefox est disponible pour toutes les versions de Windows (nécessite pour XP une mise à jour gratuite du service pack 3). • Internet Explorer 9 et 10 sont incompatibles avec windows XP (qui représente 41% de la base installée de windows), Internet Explorer 8 n'ayant aucun support HTML5/ARIA ne peut pas être pris en compte. Séminaire AccessiWeb Juin 2013

  45. AW HTML5/ARIA Base de référence Les différentes combinaisons possibles qui peuvent être considérées Séminaire AccessiWeb Juin 2013

  46. AW HTML5/ARIA Base de référence Pour qu'un dispositif HTML5/ARIA ou son alternative soit considéré comme compatible avec l'accessibilité il faut qu'il soit pleinement fonctionnel, en termes de restitution et de fonctionnalités, sur au moins une des combinaisons suivantes : Combinaison 1 : - NVDA + Firefox- JAWS + (Firefox ou IE9 +)- VOICE OVER + Safari Combinaison 2 : - JAWS + Firefox- NVDA + (Firefox ou IE9 +)- VOICE OVER + Safari Combinaison 3 : - JAWS + Firefox- WINDOW EYES + (Firefox ou IE9+)- VOICE OVER + Safari Combinaison 4 : - WINDOW EYES + Firefox- JAWS + (Firefox ou IE9 +)- VOICE OVER + Safari Séminaire AccessiWeb Juin 2013

  47. AW HTML5/ARIA Base de référence • Les règles suivantes doivent également être respectées • 1. L'ensemble des dispositifs HTL5/ARIA ou leurs alternatives doivent être pleinement fonctionnels, sur l'ensemble des pages du site, sans nécessiter de changement de technologie d'assistance en cours d'utilisation • 2. Lorsque des alternatives à des dispositifs HTML5/ARIA sont proposées elles ne doivent pas nécessiter la désactivation d'une technologie (par exemple Javascript ou le plugin flash) sauf s'il s'agit d'une fonctionnalité proposé par le site lui-même.Par exemple • le site met à disposition une version alternative conforme pleinement fonctionnelle sans le recours aux technologies dont l'usage est non-compatible avec l'accessibilité. • Le site met à disposition une fonctionnalité de remplacement des dispositifs HTML5/ARIA par des dispositifs alternatifs compatibles. Séminaire AccessiWeb Juin 2013

  48. AW HTML5/ARIA Base de référence 3. Un moyen est mis à disposition des utilisateurs de technologies d'assistance pour signaler les problèmes rencontrés et obtenir, via un dispositif de compensation, les informations qui seraient rendues indisponibles 4. Si une déclaration de conformité est établie elle doit comporter la liste des technologies d'assistance avec lesquelles les dispositifs HTML5/ARIA ont été testés et les résultats de ces tests (par exemple "supporté", "non supporté", "supporté partiellement") au moins. Séminaire AccessiWeb Juin 2013

  49. AW HTML5/ARIA Roadmap Juillet 2013publication d'une version "expérimentale" publique sur le site AccessiWeb Octobre 2013publication de la version définitive Séminaire AccessiWeb Juin 2013

  50. Merci de votre attention Merci à : Armony Altinier - Aurélien Levy – Frédéric Halna - Gilles Chagnon – Laurent Denis – Olivier Nourry - Marc-Etienne Vargenau – Patrice Bourlon - Philippe Vayssière - Romain Gervois - Sébastien Delorme - Sylvie Duchateau - Tanguy Lohéac - Victor Brito Séminaire AccessiWeb Juin 2013

More Related