AccessiWeb HTML5/ARIA

50
AccessiWeb HTML5/ARIA Séminaire AccessiWeb Juin 2013

description

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. - PowerPoint PPT Presentation

Transcript of AccessiWeb HTML5/ARIA

Page 1: AccessiWeb HTML5/ARIA

AccessiWeb HTML5/ARIAAccessiWeb HTML5/ARIA

Séminaire AccessiWeb Juin 2013

Page 2: AccessiWeb HTML5/ARIA

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 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

Juin 2012Préparation

Novembre 2012

PropositionAdaptation

Décembre2012

PréparationRéférentielMars

2013PublicationAdaptation

Juin 2013Référentiel

HTML5 / ARIA

Page 3: AccessiWeb HTML5/ARIA

Séminaire AccessiWeb Juin 2013

Généralités

AW HTML5/ARIA

Page 4: AccessiWeb HTML5/ARIA

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érentielAW HTML5

Glossaire NotesTechniques

Glossaire NotesTechniques

Base deréférence

Page 5: AccessiWeb HTML5/ARIA

Séminaire AccessiWeb Juin 2013

Quelques exemples…

AW HTML5/ARIA

Page 6: AccessiWeb HTML5/ARIA

Séminaire AccessiWeb Juin 2013

Images

AW HTML5/ARIA

Page 7: AccessiWeb HTML5/ARIA

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 <desc>

Page 8: AccessiWeb HTML5/ARIA

Séminaire AccessiWeb Juin 2013

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 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 <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é.

AW HTML5/ARIA

Page 9: AccessiWeb HTML5/ARIA

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 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

oTest 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 ?

AW HTML5/ARIA

Page 10: AccessiWeb HTML5/ARIA

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 <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

AW HTML5/ARIA

• 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 ?

Page 11: AccessiWeb HTML5/ARIA

Séminaire AccessiWeb Juin 2013

AW HTML5/ARIA

<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>

Spécification HTML5 Fallback 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 <figure> et <figcaption>

Page 12: AccessiWeb HTML5/ARIA

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 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.

Page 13: AccessiWeb HTML5/ARIA

Séminaire AccessiWeb Juin 2013

CadresCouleurs

AW HTML5/ARIA

Pas de changement

Page 14: AccessiWeb HTML5/ARIA

Séminaire AccessiWeb Juin 2013

Multimédia

AW HTML5/ARIA

Page 15: AccessiWeb HTML5/ARIA

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 <track>, l'élément <track> 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 <track> chaque fois que nécessaire

Page 16: AccessiWeb HTML5/ARIA

Séminaire AccessiWeb Juin 2013

Tableaux

AW HTML5/ARIA

Page 17: AccessiWeb HTML5/ARIA

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

Page 18: AccessiWeb HTML5/ARIA

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 5.1.1 : Pour chaque tableau de données complexe (balise table) un résumé est-il disponible dans la balise <caption> ?

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.

Page 19: AccessiWeb HTML5/ARIA

Séminaire AccessiWeb Juin 2013

AW HTML5/ARIACritè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."

Page 20: AccessiWeb HTML5/ARIA

Séminaire AccessiWeb Juin 2013

Liens

AW HTML5/ARIA

Page 21: AccessiWeb HTML5/ARIA

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

Page 22: AccessiWeb HTML5/ARIA

Séminaire AccessiWeb Juin 2013

Scripts

AW HTML5/ARIA

Page 23: AccessiWeb HTML5/ARIA

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 <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)

Page 24: AccessiWeb HTML5/ARIA

Séminaire AccessiWeb Juin 2013

AW HTML5/ARIACritè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.

Page 25: AccessiWeb HTML5/ARIA

Séminaire AccessiWeb Juin 2013

AW HTML5/ARIACritè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.

Page 26: AccessiWeb HTML5/ARIA

Séminaire AccessiWeb Juin 2013

Eléments Obligatoires

AW HTML5/ARIA

Pas de changement

Page 27: AccessiWeb HTML5/ARIA

Séminaire AccessiWeb Juin 2013

Structuration de l'information

AW HTML5/ARIA

Page 28: AccessiWeb HTML5/ARIA

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

Page 29: AccessiWeb HTML5/ARIA

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 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 ?

Page 30: AccessiWeb HTML5/ARIA

Séminaire AccessiWeb Juin 2013

AW HTML5/ARIA

Test de cohérence de l'outline

<body>

<nav> <article> <aside>

<section>

<H2>

<H2>

<H3>

Page 31: AccessiWeb HTML5/ARIA

Séminaire AccessiWeb Juin 2013

AW HTML5/ARIACritè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 ?

Page 32: AccessiWeb HTML5/ARIA

Séminaire AccessiWeb Juin 2013

Présentation de l'information

AW HTML5/ARIA

Page 33: AccessiWeb HTML5/ARIA

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 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

Page 34: AccessiWeb HTML5/ARIA

Séminaire AccessiWeb Juin 2013

Formulaire

AW HTML5/ARIA

Page 35: AccessiWeb HTML5/ARIA

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

Page 36: AccessiWeb HTML5/ARIA

Séminaire AccessiWeb Juin 2013

AW HTML5/ARIACritè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

Page 37: AccessiWeb HTML5/ARIA

Séminaire AccessiWeb Juin 2013

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 ?

Page 38: AccessiWeb HTML5/ARIA

Séminaire AccessiWeb Juin 2013

Navigation

AW HTML5/ARIA

Page 39: AccessiWeb HTML5/ARIA

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 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.

Page 40: AccessiWeb HTML5/ARIA

Séminaire AccessiWeb Juin 2013

Consultation

AW HTML5/ARIA

Pas de changement

Page 41: AccessiWeb HTML5/ARIA

Séminaire AccessiWeb Juin 2013

Base de référence

AW HTML5/ARIA

Page 42: AccessiWeb HTML5/ARIA

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 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.

Page 43: AccessiWeb HTML5/ARIA

Séminaire AccessiWeb Juin 2013

AW HTML5/ARIA

Base de référence

Technologies d'assistance d'usage habituel

Source : Enquête WEBAIM 2012

Page 44: AccessiWeb HTML5/ARIA

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.

Page 45: AccessiWeb HTML5/ARIA

Séminaire AccessiWeb Juin 2013

AW HTML5/ARIA

Base de référence

Les différentes combinaisons possibles qui peuvent être considérées

Page 46: AccessiWeb HTML5/ARIA

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

Page 47: AccessiWeb HTML5/ARIA

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.

Page 48: AccessiWeb HTML5/ARIA

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.

Page 49: AccessiWeb HTML5/ARIA

Séminaire AccessiWeb Juin 2013

Roadmap

AW HTML5/ARIA

Juillet 2013publication d'une version "expérimentale" publique sur le site AccessiWeb

Octobre 2013publication de la version définitive

Page 50: AccessiWeb HTML5/ARIA

Merci de votre attention

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