La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

AccessiWeb HTML5/ARIA Séminaire AccessiWeb Juin 2013.

Présentations similaires


Présentation au sujet: "AccessiWeb HTML5/ARIA Séminaire AccessiWeb Juin 2013."— Transcription de la présentation:

1 AccessiWeb HTML5/ARIA Séminaire AccessiWeb Juin 2013

2 AW HTML5/ARIA Séminaire AccessiWeb Juin 2013 AW 2.2 n'est pas adapté à HTML 5 Les différences de fond et les évolutions sont trop nombreuses pour porter AW 2.2 vers HTML 5 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 dalternative et de compatibilité pour Javascript telle que définie par AW 2.2 nest pas adaptée à HTML 5 AW 2. ne prend pas en charge lAPI ARIA Juin 2012 Préparation Novembre 2012 Proposition Adaptation Décembre 2012 Préparation Référentiel Mars 2013 Publication Adaptation Juin 2013 Référentiel HTML5 / ARIA

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

4 Séminaire AccessiWeb Juin 2013 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érentiel AW HTML5 Glossaire Notes Techniques Glossaire Notes Techniques Base de référence

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

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

7 Séminaire AccessiWeb Juin 2013 Images AW HTML5/ARIA -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

8 Séminaire AccessiWeb Juin 2013 Images Critère 1.1 [A] Chaque image a-t-elle une alternative textuelle ? Test : Chaque image vectorielle (balise ) vérifie-telle une de ces conditions ? o La balise svg possède un attribut aria-label o Un élément est présent Note technique A 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 pour la description "courte" et un élément pour la description longue. Actuellement seul l'élément est correctement restitué par les technologies d'assistance. L'usage de l'élément est donc considéré comme incompatible avec l'accessibilité. AW HTML5/ARIA

9 Séminaire AccessiWeb Juin 2013 Critère 1.3 [A] Pour chaque image porteuse d'information ayant une alternative textuelle, cette alternative est-elle pertinente (hors cas particuliers) ? Test : 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 o 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 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 ? AW HTML5/ARIA

10 Séminaire AccessiWeb Juin 2013 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 ) 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 contenant une référence à une description détaillée adjacente à l'image vectorielle o Il existe un élément 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 AW HTML5/ARIA Test 1.6.6: Pour chaque image vectorielle (balise ) qui implémente une référence à une description détaillée adjacente via un attribut aria-label ou un élément, cette référence est-elle correctement restituée par les technologies d'assistance ?

11 Séminaire AccessiWeb Juin 2013 AW HTML5/ARIA Légende de l'image Légende de l'image (photo 1) Spécification HTML5Fallback note WCAG 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 Prise en charge de et

12 Séminaire AccessiWeb Juin 2013 Critère 1.10 [A] Chaque légende d'image est-elle, si nécessaire, correctement reliée à l'image correspondante ? AW HTML5/ARIA Test : 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.

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

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

15 Séminaire AccessiWeb Juin 2013 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) ? AW HTML5/ARIA 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, l'élément possède-t-il un attribut kind="captions" Multimédia -Peu de changements -Prise en charge de VIDEO et AUDIO par le glossaire -Prise en charge de chaque fois que nécessaire

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

17 Séminaire AccessiWeb Juin 2013 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

18 Séminaire AccessiWeb Juin 2013 AW HTML5/ARIA Critère 5.1 [A] Chaque tableau de données complexe a-t-il un résumé ? Test : Pour chaque tableau de données complexe (balise table) un résumé est-il disponible dans la balise ? Note technique La 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.

19 Séminaire AccessiWeb Juin 2013 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 : Chaque tableau de mise en forme vérifie-t-il ces conditions ? o le contenu linéarisé reste compréhensible o la balise 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."

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

21 Séminaire AccessiWeb Juin 2013 Liens AW HTML5/ARIA 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 Aucun changement

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

23 Séminaire AccessiWeb Juin 2013 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 -Les restrictions de modification du role natif HTML d'un élément (tableau de référence de la note sur ARIA)

24 Séminaire AccessiWeb Juin 2013 AW HTML5/ARIA Critère 7.1 [A] Chaque script est-il, si nécessaire, compatible avec les technologies d'assistance ? Test : 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.

25 Séminaire AccessiWeb Juin 2013 AW HTML5/ARIA Critère 7.3 [A] Chaque script est-il contrôlable par le clavier et la souris (hors cas particuliers) ? Test : 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.

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

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

28 Séminaire AccessiWeb Juin 2013 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

29 Séminaire AccessiWeb Juin 2013 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 : 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 : Dans chaque page Web, la hiérarchie entre les titres (balises h ou balise possédant un role ARIA "heading") est-elle pertinente ? Test : 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 : Dans chaque page Web, chaque titre (balises h ou balise possédant un role ARIA "heading") est-il pertinent ?

30 Séminaire AccessiWeb Juin 2013 AW HTML5/ARIA Test de cohérence de l'outline

31 Séminaire AccessiWeb Juin 2013 AW HTML5/ARIA Critère 9.2 [A] Dans chaque page Web, la structure du document est-elle cohérente ? Test : 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 o Les zones de navigation principales et secondaires sont structurées via une balise o La balise 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 o La structure du document utilise une balise unique o La zone de pied-de-page est structurée via une balise Test 9.2.2: dans chaque page web l'arborescence du document est-elle cohérente ?

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

33 Séminaire AccessiWeb Juin 2013 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 [A] Pour chaque page Web, les textes cachés sont-ils correctement restitués par les technologies d'assistance ? Test : 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

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

35 Séminaire AccessiWeb Juin 2013 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

36 Séminaire AccessiWeb Juin 2013 AW HTML5/ARIA Critère 11.1 [A] Chaque champ de formulaire a-t-il une étiquette ? Test : 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 [A] Dans chaque formulaire, le contrôle de saisie est-il utilisé de manière pertinente ? Test : 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

37 Séminaire AccessiWeb Juin 2013 AW HTML5/ARIA Test : 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 : 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 ?

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

39 Séminaire AccessiWeb Juin 2013 AW HTML5/ARIA Navigation -Prise en charge des role aria landmark, obligation d'utilisation de -banner, navigation, main, contentinfo, search Critère [A] Dans chaque page Web, les groupes de liens importants (menu, barre de navigation...) et la zone de contenu sont-ils identifiés ? Test : 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.

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

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

42 Séminaire AccessiWeb Juin 2013 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 usages 3. 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.

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

44 Séminaire AccessiWeb Juin 2013 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 (Webaim survey #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.

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

46 Séminaire AccessiWeb Juin 2013 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

47 Séminaire AccessiWeb Juin 2013 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.

48 Séminaire AccessiWeb Juin 2013 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.

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

50 Merci de votre attention Séminaire AccessiWeb Juin 2013 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


Télécharger ppt "AccessiWeb HTML5/ARIA Séminaire AccessiWeb Juin 2013."

Présentations similaires


Annonces Google