You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hôpital ophtalmique Jules-Gonin
15 Avenue de France, CP 133
1000 Lausanne 7
Salle : auditorium
Programme
Partie 1 - Matinée "Accessibilité numérique : derniers standards et exemples de nouveaux usages"
8h45 : Ouverture des portes et accueil des participants
9h00-9h30 : Accessibilité numérique : définition et enjeux pour les utilisateurs
Florian Egger et Laetitia Giannettini, Telono
Que recouvre l’accessibilité numérique ? Quels sont les utilisateurs concernés ? Après avoir rappelé ce que recouvre l’accessibilité et ce que cela signifie pour tous utilisateurs ayant des limitations fonctionnelles au niveau moteur, visuel, auditif, et/ou cognitif, nous mettrons en perspective le programme de la journée.
9h30-10h15 : HTML5, ARIA et accessibilité web : où en est-on ?
Jean-Pierre Villain, Qelios
Html 5, Javascript et ARIA sont devenus les technologies dominantes du Web. Elles répondent à la mutation profonde et irréversible des usages, des publics et des plateformes. Pour l'accessibilité c'est un enjeu majeur et la promesse d'un web meilleur pour les utilisateurs. Néanmoins dans un paysage technologique en évolution rapide et des spécifications encore très instables, la prise en charge de ces nouvelles technologies se révèle particulièrement complexe. Bref tour d'horizon de l'état de l'art et des méthodes, notamment de test, nécessaire à la prise en charge de l'accessibilité des nouvelles technologies.
10h15-10h45 : Pause café
10h45- 11h15 : Démonstration d’usages mobiles
Daniele Corciulo, Fondation Suisse Accès pour tous
Les téléphones mobiles sont porteurs d’un très important potentiel pour les personnes non-voyantes, grâce au grand nombre de fonctionnalités qu’ils embarquent, comme le GPS, l’accès aux informations des transports publics via internet, des lecteurs de livre audio, etc. Notamment, les appareils Apple Iphone et sur ceux basés sur le système d’exploitation Android de Google, deux entreprises très présentes sur le marché de la téléphonie mobile offrent des fonctionnalités d’accessibilité pour les personnes en situation de handicap.
Daniele, consultant en accessibilité, nous montrera comment fonctionne un Iphone pour les utilisateurs mal-voyants et fera une démonstration d’applications qui lui ont permis d’acquérir plus d’autonomie dans la vie quotidienne.
11h15-12h00 : Evaluation de l'accessibilité des téléphones tactiles à l'aide du test utilisateur : cas de Iphone et Android
Arnaud Béguin, Haute École du Paysage, de l'Ingénierie et d'Architecture de Genève - HEPIA
Cette présentation fera le lien avec la précédente : à ce jour aucune étude comparative des principaux téléphones tactiles du marché n’existe quant à leur accessibilité pour les utilisateurs déficients visuels. Quelles sont les logiques d’interactions tactiles, de prise d’informations audio, de type de saisie qui favorisent la sécurité de manipulation et le sentiment de contrôle de ces appareils par ces utilisateurs ?
Pour combler cette absence de données, Arnaud a mené une étude itérative, dans le cadre de son Master à l'Université de Genève, impliquant 10 utilisateurs visant à évaluer et à comparer l’accessibilité et la facilité d’utilisation effective de l’Iphone 4S d’Apple et le Google Nexus (sous Android 4.0).
En se basant sur une première évaluation, Arnaud a proposé et implémenté des améliorations de la librairie Google Eyes-Free, dont le but est d’offrir des fonctionnalités d’accessibilité. Ces développements ont mené à une seconde évaluation, dont les retours sont prometteurs. Arnaud partagera avec nous les enseignements issus de son projet.
12h15-13h45 : Déjeuner
Partie 2 - Après-midi "Évaluer et mettre en œuvre de façon concrète l'accessibilité"
14h00-14h45 : Gestion de projet : Intégrer l'accessibilité dans un projet web, méthodes et enjeux
Armony Altinier, ACS Horizons
Ça y est, vous êtes convaincu/e, vous souhaitez rendre votre site accessible ! Vous commencez par faire (ou faire-faire) un état des lieux. Mais une fois les problèmes identifiés, par où commencer ? Faut-il commencer par ce qui est le plus facile ? Le plus bloquant pour l'accessibilité ? Peut-on répartir le travail selon le profil métier de chaque intervenant ? Existe-t-il une méthodologie propre à l'accessibilité web, avec des étapes clé à ne pas manquer ? Cela implique-t-il de revoir sa méthode de gestion de projets ?
Ces questions donnent lieu à différents travaux en cours.
Armony nous présentera l'état de la question et partagera son expérience de l'amélioration de l'accessibilité web dans le cadre de projets complexes.
14h45-15h30 : Utilisabilité des systèmes interactifs: méthodes et techniques d'évaluation
Florian Egger et Laetitia Giannettini, Telono
Cette présentation fera le lien avec la précédente en posant la question suivante : quelle expérience utilisateur offre un site ou application web qui respecte les critères d’accessibilité ? Comment évaluer cette expérience et l’utilisabilité effective de l’interface web ? A quelles étapes du projet ? Nous présenterons un panorama clair des différentes méthodes d’évaluation de l’utilisabilité les plus pertinentes à mettre en œuvre en fonction des étapes d’un projet de conception.
Nous illustrerons en particulier 2 méthodes et outils pratiques pour évaluer (et corriger) l’utilisabilité de l'architecture de l’information des sites et applications web.
15h30-16h00 : Pause café
16h00-16h45 : Accessibilité web : démonstration de techniques d'évaluation rapide
Jean-Pierre Villain, Qelios
La question de l'évaluation de l'accessibilité ne peut pas se résumer à une batterie de test, mais ces derniers en sont un maillon essentiel. Trop souvent, ils sont perçus comme trop lourds, trop nombreux ou trop techniques pour être intégrés de manière efficace dans la chaine de production des contenus. A ce titre plusieurs techniques d'évaluation rapide ont été développées par les professionnels permettant de rendre les tests plus digestes. Démonstration de quelques une de ces techniques, quelquefois enfantines, à la portée de tout intégrateur ou contributeur, qui permettent de tester l'accessibilité de manière rapide et efficace.
16h45-17h15 : Le logiciel libre comme outil d'accessibilité à l'information pour les personnes déficientes visuelles
Jean-Philippe Mengual, Accelibreinfo
Dans le domaine des aides techniques (synthèses vocales, agrandisseurs d'écrans...) permettant aux personnes non ou mal-voyantes d'accéder à l'information numérique, il existe face aux acteurs commerciaux tels que Jaws, Mac OS ou ZoomText, des solutions gratuites et libres.
Leur licence libre permet de replacer l'utilisateur au centre des préoccupations de l'informatique et de lui donner les moyens d'en faire ce qu'il veut.
Jean-Philippe présentera ces solutions et illustrera la façon dont une personne présentant une déficience visuelle perçoit et utilise l'ordinateur (lecture d'une page web, lecture et rédaction de mails...).
17h15 - 17h45 : Annotation collaborative pour l'Accessibilité des Vidéos sur le Web : le projet ACAV
Benoît Encelle, Université Lyon 1
L’objectif du projet ACAV (Annotation Collaborative pour l'Accessibilité des Vidéos) est d’améliorer l’accessibilité des vidéos situées sur le Web aux personnes malvoyantes/non-voyantes, malentendantes/non-entendantes. Les outils développés dans le cadre de ce projet visent à enrichir des vidéos avec des contenus additionnels, principalement sonores et/ou visuels, qui décrivent les informations visuelles et/ou sonores clefs des vidéos.Ces outils permettent de réaliser par exemple :
une audio-description pour les non-voyants,
un sous-titrage pour les malentendants.
Cependant, au delà de ces formes « classiques » d’enrichissement, il est également possible d’enrichir une vidéo davantage en utilisant des icônes sonores, voire du braille (via une plage tactile) pour transmettre certaines descriptions.
Benoît présentera les principaux enjeux, concepts développés et résultats de recherche issus de ce projet.
18h: Apéritif au Cavallo Bianco, Sponsorisé par UX Romandie
Adresse du Cavallo Bianco: Place Chauderon, 24 - 1003 Lausanneß
Accessibilité Web : définition et enjeux pour les utilisateurs, programme de la journée
16 avril 2013, Laetitia Giannettini (giannettini@telono.com) et Florian Egger (egger@telono.com)
Conférence Romande sur l’Accessibilité du Web. Hashtag sur twitter: #CRAW2013
Accessibilité web:définition
La WAI (Web Accessibility Initiative), groupe de travail du W3C (World Wide Web Consortium) définit l’accessibilité web comme un attribut grâce auquel :
les personnes qui ont des limitations fonctionnelles peuvent
utiliser le web, à savoir percevoir, comprendre, naviguer et interagir avec le web
contribuer sur le web
Comprend tous les handicaps qui impactent l’accès au web et inclut les handicaps visuels, auditifs, physiques, de parole, cognitifs et neurologiques
La conformité aux critères d’accessibilité bénéficie également aux personnes âgées dont les capacités peuvent être altérées avec l’âge
Il s’agit de structurer les pages web de façon cohérente afin de donner et de porter la signification de l’information :
pas uniquement sur la seule apparence visuelle (ex: titre principal écrit en plus gros, titres secondaires écrit en plus petit)
mais aussi avec des «méta-données» quipourront être exploitées par tout logiciel qui récupère et présente le contenu web aux utilisateurs
navigateurs web, lecteurs de médias, technologies d’assistance comme lecteur d’écran couplé à une synthèse vocale, agrandisseur d’écran, navigation clavier...
on parle parfois de balises HTML “sémantiques”
Exemple:restituer la structurelogique de la page avec un plande la page
Utiliser des titres pour structurer la page
dans le code HTML, usage de balises h1, h2, h3,... pour signifier les différents niveaux de titres et leur hiérarchie
objectif : composer une structure logique de titres représentant la composition de la page web
Implémentation dans le code html :exemple
<h3> 9h00-09h30 : Accessibilité numérique : définition et enjeux pour les utilisateurs </h3>
Exemple d’outil pour visualiser le plan du document
Extension «HeadingsMap»de Firefox
Plan de la page:avantages
Permet de restituer la vue d’ensemble de la page
Premiers bénéficiaires : les utilisateurs de lecteurs d’écran qui vont pouvoir se représenter le plan de la page grâce aux différents niveaux de titres
Les personnes avec handicap moteur en profitent également : permet de naviguer de titre en titre par exemple
Permet d'obtenir des listes de divers éléments présents sur la page Web,
tels que des liens, des cadres, des champs de formulaire ou encore des titres
Ces différentes fonctions s'implémentent par l'intermédiaire de combinaisons de touches du clavier de l’ordinateur
Ex: touches de navigation rapide utilisables avec Jaws Version 6+ française et Internet Explorer sur PC
Affichage des titres : touche Ctrl (verrouillage majuscule pour PC portable) + F6
Aller au titre suivant: touche t,
Aller au titre précédent : Maj + t
Aller au titre suivant de niveau n: touche 1 à 6 du pavé alphanumérique
Source : formation donnée par Julien Conti, testeur en accessibilité, Etat de Genève
Plan de la page : exemple de la page d’accueil du site de la ville de Lausanne
Structuration de l’information uniquement à l’aide d’éléments au format visuel
Le référentiel Accessiweb 2.2 : critères de succès répartis en 13 thématiques : http://www.accessiweb.org
Images
Cadres
Couleurs
Multimédia
Tableaux
Liens
Scripts
Eléments obligatoires
Structuration de l’information
Présentation de l’information
Formulaires
Navigation
Consultation
Programme de la journée
Partie 1 -Matinée «Accessibilité numérique : derniers standards et exemples de nouveaux usages»
9h30-10h15 : HTML5, ARIA et accessibilité web : où en est-on ? Jean-Pierre Villain, Qelios
10h15-10h45 : Pause café
10h45-11h15 : Démonstration d’usages mobiles Daniele Corciulo, Fondation Suisse Accès pour tous
11h15-12h00 : Evaluation de l'accessibilité des téléphones tactiles à l'aide du test utilisateur : cas de Iphone et AndroidArnaud Béguin, Haute École du Paysage, del'Ingénierie et d'Architecture de Genève –HEPIAV
12h15-13h45 : Déjeuner
Partie 2 -Après-midi «Évaluer et mettre en œuvre de façon concrète l'accessibilité»
14h00-14h45 : Gestion de projet : Intégrer l'accessibilité dans un projet web, méthodes et enjeux Armony Altinier, ACS Horizons
14h45-15h30 : Utilisabilité des systèmes interactifs: méthodes et techniques d'évaluation Florian Egger et Laetitia Giannettini, Telono
15h30-16h00 : Pause café
16h00-16h45 : Accessibilité web : démonstration de techniques d'évaluation rapide Jean-Pierre Villain, Qelios
16h45-17h15 : Le logiciel libre comme outil d'accessibilité à l'information pour les personnes déficientes visuelles Jean-Philippe Mengual, Accelibreinfo
17h15 -17h45 : Annotation collaborative pour l'Accessibilité des Vidéos sur le Web : le projet ACAVBenoît Encelle, Université Lyon 1
18h : Apéritif au Cavallo Bianco, Sponsorisé par UX Romandie Place Chauderon, 24 -1003 Lausanne
Le projet ACAV permet d'ajouter des informations pour les personnes non voyantes.
Les personnes documentent la vidéo via une interface qui permet de placer les informations dans le temps. Le texte ainsi saisi sera vocalisé sur la vidéo.
Une piste décrit les actions des personnages.
Un son informe que le lieu de l'action a changé.
etc.
Autre projet:
Natbraille: Un transcripteur universel de documents standards en texte braille
Les outils de tests automatiques ne peuvent rien nous dire sur l'accessibilité d'un contenu.
Démonstration de manipulation avec la Web développer toolba«r
Il est possible d'utiliser la "web développer toolbar" pour tester une bonne partie de l'accessibilité via le mode CSS désactivé.
ex.:
Désactiver les CSS
Entourer les balise <a>
Afficher le attribut title
Si on voit un cadre rouge sans attribut, c'est qu'il y a un problème d'accessibilité.
Un lien "Lire la suite" avec un title <a title="lire la suite"> est explicite si la l'élément précédent donne le titre de l'article.
Présentation
Accessibilité du Web Méthodes d'évaluation rapide
Conférence Romande sur l’Accessibilité du Web –Lausanne –Avril 2013
Avant-propos
Disposer de méthodes permettant d'évaluer rapidement l'accessibilité d'un site est important dans plusieurs situations :
En phase initiale, par exemple pour déterminer la meilleure stratégie pour aborder l'accessibilité
En phase d'accompagnement pour pouvoir interagir rapidement avec les développements en cours.
En phase de production pour évaluer ou valider rapidement les contenus produits en interne ou proposés par des tiers
En phase de qualification de contenus ou d'outils de production produits par des prestataires extérieurs
Les méthodes proposées ici s'appuient uniquement sur une évaluation humaine en utilisant :
La web developer toolbar pour firefox
Le mode CSS désactivé
Ces méthodes sont reproductibles en utilisant d'autres barres d'outils
Rappel
Les outils de test automatiques sont utiles mais limités :
Uniquement la présence
20 % des tests
Beaucoup de faux-positifs
Les outils de tests automatiques ne peuvent rien nous dire sur l'accessibilité d'un contenu.
Exemples De méthodes d'évaluation rapides
Le mode CSS désactivé offrent beaucoup d'avantages :
Accès direct au contenu et la structure
Affichage des contenus dynamiques masqués pas CSS
Ordre réel du contenu
Facilité d'évaluation
Rappel
Le mode CSS désactivé n'est pas un mode de consultation.
En revanche c'est un excellent mode pour tester l'accessibilité des contenus.
1. Images
Paramètres
CSS -> désactiver CSS
Entourer -> personnalisé -> IMG
Entourer -> personnalisé -> A
Images -> afficher les attributs ALT
Rechercher
Les images sans attribut ALT
Les liens-images avec des attributs ALT nul (alt="")
Les liens adjacents de description longue ou la présence d'une description longue adjacente
Evaluer
Les alternatives d'images porteuses d'information
Les images de décoration
2. Cadres
Paramètres
CSS -> désactiver CSS
Entourer -> personnalisé -> IFRAME
Info-> afficher les attributs TITLE
Rechercher
Les IFRAMES sans attribut TITLE
Evaluer
Les titres données aux IFRAMES
3. Tableau
Paramètres
CSS -> désactiver CSS
Entourer -> tableaux -> TABLEAUX
Entourer -> tableaux -> CAPTION
Entourer -> tableaux -> CELLULES
Entourer -> personnalisé-> TH
Rechercher
Les tableaux de données sans titre
Les tableaux de données sans cellule d'en-tête
L'absence de cellule d'en-tête ou d'élément CAPTION pour les tableaux de mise en forme
Evaluer
La pertinence des titres de tableaux
La linéarisation des tableaux de mise en forme
4. Liens
Paramètres
CSS -> désactiver CSS
Entourer -> personnalisé -> A
Entourer -> personnalisé-> IMG
Images -> Afficher les attributs ALT
Rechercher
Les liens vides
Les liens-images vides
Paramètres
CSS -> désactiver CSS
Entourer -> personnalisé -> A
Info -> Afficher les attributs TITLE
Rechercher
Les TITLE inutiles
Evaluer
La pertinence des TITLES
Paramètres
CSS -> désactiver CSS
Entourer -> indiquer les balises
Entourer -> personnalisé -> A
Entourer -> personnalisé-> IMG
Images -> Afficher les attributs ALT
Entourer -> personnalisé -> P
Evaluer
Le contexte des liens si les intitulés seuls ne sont pas suffisamment explicites. Si aucun contexte de lien n'est jugé suffisant :
1.Entourer -> entourer les titres H1-H6
2.évaluer la présence d'un TITLE pertinent en survolant avec la souris.
La présence de liens identiques
5. Structure
Paramètres
Info -> afficher le plan du document
Vérifier
La présence d'un titre H1 au moins
L'absence de titre manquant dans la hiérarchie des titres
Paramètres
CSS -> désactiver CSS
Entourer -> entourer les titres H1-H6
Evaluer
La présence des titres nécessaire à la structuration de l'information.
Note : ce test peut également être effectué CSS activé pour une meilleure évaluation
6. Formulaire
Paramètres
CSS -> désactiver CSS
Entourer -> personnalisé -> FORM
Entourer-> personnalisé -> LABEL
Images -> afficher les attributs ALT
Vérifier
La présence des labels pour les champs de formulairesEn cas d'absence de label vérifier la présence d'un title pertinent en survolant le champ avec la souris.
La présence d'un FIELDSET (cadre autour de champs regroupés) si nécessaire
La présence d'une légende (LEGEND), texte à cheval sur un fieldset
Evaluer
La pertinence des labels ou des titles
La pertinence des noms des boutons de soumission (ou du title associé) ou des alternatives des boutons de type image.
La cohérence des labels de champs de même nature répétés plusieurs fois dans la page.
Démonstration de l'usage d'un mobile dans la vie courante d'une personne aveugle.
Applications présentées :
BlindSquare : Foursquare accessible (direction, distance, etc.). Permets de trouver seul des bâtiments, gare, magasins, etc. Plus besoin de demander à quelqu'un dans la rue son chemin.
Mobile CFF : horaire de train. Permets de connaître
Ticketcorner : réservation de concert. L'application n'est pas du tout accessible. La liste des concerts n'est pas vocalisée.
Postfinance: Permet d'envoyer de l'argent aux gens en ayant juste leur numéro de téléphone. Il n'y a pas beaucoup de distributeurs de billets qui disposent de prise casque. L'application permet de les localiser ainsi que les boîtes aux lettres.
iOS : Démonstration des principales fonctionnalités d’iOS
Objectif et périmètre
Tous les critères du AAA ne sont pas applicables. Même le W3C le dit.
Exploration du site
Qu'est-ce qu'il y a comme contenu
Échantillon
Produire 10-15 pages d'échantillon
Évaluation
Par critère. On dit s’il est "fait", "pas fait", "non applicable".
Rapport
Rapport selon WCAG-EM
Rapport en profondeur: Rapport détaillé + Partie décideurs
Rapport détaillé: Rapport basiques + conformités et échecs page par page
Rapport basique: Conformités et échecs à l'échelle du site
Le rapport sera AccessiWeb
Synthèse décideurs
Annexe technique
Indicateurs quantitatifs
Mesure de la conformité
à l'échelle du site
page par page
Mesure de la quantité de travail
décompte par instance
Attention
Un site respectant 80% des critères n'est pas 80% accessible !
80% conforme != 80% accessible
ex.: Si sur un site qui nécessite un login, si le captcha ne fonctionne pas, le site est innaccessible.
On avait que les liens <a> et les formulaires <form> à disposition pour les actions.
JavaScript permettait d'ajouter du dynamisme.
Très lent
Très peu adapté au web (contenu et interaction)
Accessibilité
Très bien
Facile de rendre un site accessible
Il suffisait de suivre la norme
La norme était stabilisée
L'environnement était totalement prédictif
On imposait une alternative au JavaScript. Tout devait être utilisable sans JavaScript
HTML5, Le Web mutant
Il s'agit d'une mutation du Web
Le développement Web en HTML5
Le coeur du langage est entouré d'API et autres modules extrêmement riches (ex.: Calendar API, Web Socket, CSS 3.o, etc.)
Pour l'accessibilité
En développement. Tout ne fonctionne pas encore.
Instable. Comportement très différent selon les plateformes.
Imprévisible. On n’arrive pas à avoir des comportements prédictifs.
JS = JS. L'alternative à JavaScript ne sera mise en place que si on y est vraiment obligé. En plus, JavaScript va de plus en plus être le langage qui permet de rendre un contenu accessible.
ARIA est un API qui permet de rendre le javascript accessible.
Avant-propos
Le focus d'ARIA est de rendre accessible les lecteurs d'écran.
ARIA
Deux documents:
l'API
Role
State
Properties
Best practices
Design Pattern
Comportement
Gestion clavier
Pour l'HTML tout est défini dans les spécification
Le lecteur d'écran dispose de toutes les informations.
Avec Javascript
Propblème pour l'utilisateur :
Identifier
Utiliser
Comprendre
ex.: le slider.
<div><span>0%</span>
<div><a></a>
</div></div>
Il n'y a que des contenu HTML vide ce qui est inutilisable.
Objectifs de l'API ARIA
Définir les composants d'interface et de structure
Informer de l'état et des propriétés des composants d'interface
Informer et gérer les mises à jour de contenu dynamique
Rendre les composants utilisables au clavier.
Avantages
Implémentations de mieux en mieux supportée pas les navigateurs
Support en améliorantes
la prise en main par les bibliothèques JavaScript
Facile à implémenter
ARIA Exemple
Les boites de dialogue
role = alertdialog
Objectif: créer une boite d'alerte alternative au méthodes alert.
Mise à jour du contenu
Objectif: Informer des mises à jours dynamiques.
aria-live=offaria-live=politearia-live=assertive
Récupération d'information de contexte
labelledby
describedby
Permet de lier des contenu les uns les autres.
WCAG vs. HTML5/ARIA
Ce qui ne changera pas:
Les principes
Les règles
Les critères
La conformité
Ce qui va changer:
Les techniques
Les notes techniques
WCAG vs. HTML5/ARIA, Principales évolutions
Images
On peut enfin faire des légende aux images.
<figure>
<figcaption>
On peut utilise l'attribut title avec <img> mais il ne faut pas le faire car ce n'est pas accessible aus personnes qui n'utilise pas de souris.
Avec l'HTML5 on est plus obligé de mettre un attribut alt à partir du moment où il y a une description de l'image <figcaption>
On peut utiliser le SVG et les <canvas> mais il faudra quand même proposer une alternative en cas de problème.
Multimédia
Utilisation de <video> et <track>.
Ce n'est pas accessible avec tout les navigateur. On va utiliser les javascript pour les rendre accessible.
Les liens
Utilisation de <a href="…"> avec des contenus de type bloc.
Le JavaScript
L'utilisation de JS est prédominante dans HTML5.
Structure
<section>
<article>
<footer>
<address>
Utilisation de l'Outline. Permet de générer la structure du contenu (et non du document).
Formulaire et éléments interactifs
Support insuffisant
color
date
etc.
Navigation
Utilisation de <main> pour indiquer la zone de contenu principale.
<nav> permet de naviguer dans le site.
Les landmarks ARIA
Tester et valider un widget ARIA
AViewer
Inspect 32
Présentation
HTML 5 /ARIA et l'accessibilité du Web Où en est-on ?
Conférence Romande sur l’Accessibilité du Web – Lausanne – Avril 2013
HTML 4 le web de grand papa
Le développement Web en HTML 4
HTML : des contenus structurés
Liens
Textes
Images
Formulaire
Multimedia
Javascript : des effets dynamiques
Menu déroulants
De la neige en hiver
Contrôle de formulaire
HTML ne permet pas de créer des composants qui sont limités à des liens et des contrôles de formulaire
Le web fonctionne en mode client-serveur : une action = un rechargement de page
Pour l'accessibilité
Facile
Stable
Prédictif
JS = alternative
"WCAG est ton ami"
Pour le Web
Site perso : très facile
Site corporate : facile
Site marchand: difficile
Application : très difficile
HTML 5 le Web Mutant
Le développement Web en HTML 5
Autour du cœur de langage (HTML5) gravitent une multitude de modules et d'API :
Calendar
Geo location
CSS 3
Web Storage
Touch event
SVG
Web Workers
File API
Canvas
MAthML
AJAX
Drag and Drop
Micro Data
AUdio Video
Web GL
Web Socket
WAI ARIA
Pour l'accessibilité
En développement
Instable
Imprévisible
JS = JS
Pour le Web
C'est la possibilité d'exploiter pleinement les plateformes mobiles notamment
Quelques nouveautés en HTML 5
Structure
<article>
<section>
<nav>
<aside>
<hgroup>
<header>
<footer>
<address>
Regroupement
<figure>
<figcaption>
<main>
Embarqués
<video>
<audio>
<source>
<track>
<canvas>
Interactif
<details>
<summary>
<menu>
<menuitem>
<dialog>
Contenus
<mark>
<small>
<time>
<wbr>
Formulaire
Eléments
<datalist>
<keygen>
<output>
<progress>
<meter>
Types
search
tel
date
email
password
number
range
color
Attributs
required
multiple
pattern
min
max
step
placeholder
autofocus
autocomplete
Modifications
Un lien peut contenir des éléments de type block
Eléments ou attributs obsolètes
Non conformes
<applet>
<acronym>
<bgsound>
<tt>
Longdesc (réintroduit via une extension à la spécification)
target
summary
scrolling
Conforme (warning)
<doctype>
border
name
size
ARIA le WEB Accessible
Comment un lecteur d’écran sait de quoi il parle ?
Le navigateur Web traite les éléments de la page via une API d'accessibilité
Les informations (role, state, properties) sont transmises à l'API accessibilité système
Le lecteur d'écran traite les informations mises à dispositions via les API accessibilité
Le lecteur d'écran vocalise les caractéristiques des éléments
ARIA
Deux documents
L'API
Role
State
Properties
Best practices
Design Pattern
Comportement
Gestion clavier
Pour HTML tout est défini dans les spécifications
Le lecteur d’écran dispose de toutes les informations renvoyées par le navigateur et les adapte comme il le souhaite.
Avec Javascript
C'est beaucoup plus aléatoire car on peut créer n'importe quel composant en se basant sur des éléments neutres comme des divs, des spans....
Le problème pour l'utilisateur est de pouvoir identifier, utiliser et comprendre.
Exemple avec un slider uniquement structurés avec des divs, des spans et un lien vide.
Objectifs de l'API ARIA
Définir les composants d'interface et de structure
Informer de l'état et des propriétés des composants d'interface
Informer et gérer les mises à jour de contenus dynamiques
Rendre les composants utilisables au clavier
Avantages
Implémentation de mieux en mieux supportée par les navigateurs
Support en amélioration constante sur les AT
Prise en charge par les bibliothèques JavaScript
Facile à implémenter
Désavantages
Gestion de l'utilisation au clavier très complexe
Différence d'interprétation de certaines propriétés par les AT
Tests obligatoires
ARIA Exemples : les boites de dialogue "alertdialog"
Objectif : créer une boite d’alerte alternative aux méthodes alert, prompt, confirm de JS. Attention : l'implémentation peut être relativement complexe.
Alerte Javascript
Inconvénient
Pas stylable
N’accepte que du texte
Avantage
C’est une vraie fenêtre modale
Ne nécessite aucun traitement.
Alerte ARIA
Inconvénient
Ce n’est pas une vraie fenêtre modale
Avantage
Personnalisable à 100%
Elément HTML 5
<dialog>
ARIA Exemples : Les live region, la propriété aria-live
Objectif : informer des mises à jour dynamiques et gérer l’interaction entre la zone de mise à jour et les actions de l’utilisateur
Principe : on attribue des valeurs de gestion des signalements de mise à jour sur l'élément mis à jour
Propriété aria-live
Aria-live="off" : la zone n'est pas vocalisé mais son statut est mémorisé
Aria-live="polite" : la zone est vocalisée dés que l'utilisateur est disponible
Aria-live=assertive : la zone est vocalisée dés que possible
Propriété complémentaire
`atomic : true|false```
Toute la zone ou seulement la partie mise à jour est lue
relevant: addition|removal
Les ajouts et les suppressions de contenus (dom) sont signalés
relevant: text|all
Seuls les changements de texte ou tous les changements sont signalés
aria-busy: true|false
Signale que la zone est en train d’être mise à jour
ARIA Exemples : Récupération d'information de contexte avec labelledby et describedby
labelledby et describedby permettent de lier des contenus les uns aux autres.Ces deux attributs sont omniprésents dans les implémentations ARIA.
L’une des utilisations est de produire des messages lors de l’utilisation d’un composant ou d'affecter des "noms" aux éléments.
Exemple : vocaliser des aides à la saisie dans des formulaires.
Attention
labelledby et describedby ne fonctionnent pas avec tous les éléments :
fonctionnent lorsque le Design Pattern le requiert
Fonctionnent avec les éléments de formulaire
WCAG Vs HTML 5 / ARIA
Ce qui ne changera pas
Les principes
Les règles
Les critères
La conformité
Ces éléments font partie du bloc "normatif" de WCAG 2.0 ; ils sont indifférents aux technologies. En HTML 5, il faut adresser les mêmes problématiques avec les mêmes objectifs
Ce qui va changer
Les techniques
Les notes techniques
Un travail exploratoire est en cours pour les techniques.
Des notes techniques sont adossées
à la spécification pour certaines problématiques particulières
Techniques
10 techniques "HTML 5"
<section>
<article>
<aside>
<nav>
<track>
Tabindex
Required
Placeholder
30 techniques "ARIA"
heading
controls
landmarks
alert
range
label
labelledby
describedby
checked
expanded
Notes techniques
Alternative d'image
Utilisation d'Aria
WCAG Vs HTML5 / ARIA Principales évolutions
1. Images
Images légendées
Une image légendée doit avoir un attribut ALT renseigné contenant, au minimum un nom permettant d'associer l'image à sa légende
Utilisation de l'attribut title
Contrairement à la spécification HTML5, l'utilisation d'un title pour "labelliser" une image est proscrite
Présence de l'attribut ALT pour une image légendée
Html 5 autorise l'absence de l'attribut alt pour une image légendée. Cette possibilité est rejetée par la note technique associée aux alternatives d'image
Support : Firefox
Pas de support pour : IE10, Chrome, Safari, NVDA, Jaws
Images légendées FIGURE et FIGCAPTION, utilisation de l'attribut title
Spécification HTML 5 <img src="pic.jpg" alt="La tour eiffel Copyright : AFP 2013">
Mettre des informations destinées à tous les utilisateurs dans l'alternative est interdit.
<img src="pic.jpg" alt="la tour eiffel" title="Copyright : AFP 2013">
La specification HTML 5 suggère, dans ce cas là d'utiliser un attribute title
Lorsque les AT le supporteront, le motif défini par la spécification deviendra utilisable.
Exemple de comportement attendu via une API d'accessibilité
Avec Firefox, le parent de l'image (FIGURE) est labellisé avec FIGCAPTION.
Une AT pourrait utilisée cette valeur comme Alternative de l'image.
Pas de support pour : Firefox, IE10, CHROME, SAFARI, NVDA, JAWS
<canvas id="example" width="260" height="200">
<h2>Exemple de formes géométriques déssinées avec canvas</h2>
<p>Un rectangle avec une bordure noire contient trois formes : un <a href="http://en.wikipedia.org/wiki/Square" onfocus="drawSquare();" onblur="drawPicture();">carré</a>
vert et un <a href="http://en.wikipedia.org/wiki/Triangle"onfocus="drawTriangle();" onblur="drawPicture();">triangle</a> bleu recouvrent partiellement un <a href="http://en.wikipedia.org/wiki/Circle" onfocus="drawCircle();" onblur="drawPicture();">cercle</a> rose</p>
</canvas>
Firefox et IE implémentent correctement l'élément canvas, le contenu textuel est vocalisé et tabulable
Support pour : Firefox, IE10, NVDA, JAWS
Pas de support pour : Chrome, Safari
2 Multimedia
Utilisation de <VIDEO> et <TRACK>
Les éléments <VIDEO> et <TRACK> sont supportés par les navigateurs mais l'accessibilité est variable.
Problème :
Exposition partielle des contrôles (sauf pour IE 10)
Accessibilité des contrôles au clavier médiocre (sauf pour IE10
Utiliser une vidéo alternative où l'audio-description est intégrée en dur à la bande son principale.
Avantage : on peut remonter !
Dans tous les cas :
Proposer une alternative :
Vidéo sous-titrée en dur
Vidéo audio-décrite en dur
Lecteur FLASH accessible (Youtube ?)
3 Liens
Utilisation de A Href avec des contenus de type bloc
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
Stratégie d'implémentation si cette utilisation est requise
Placer l'information essentiel (qui rend le lien explicite) en début de contenus.
Utiliser un wrapper traité en JS (attention : testez !)
Attention : Ne pas utiliser de lien dans un lien
Support pour : Firefox, IE10, Chrome, Safari, NVDA, JAWS
4 Script
Utilisation de dispositifs JavaScript
L'utilisation de JavaScript est prédominante en HTML 5 :
Pilotage d'API (par exemple, canvas)
Mise à disposition de composants complexes
Mise à disposition de fallback, basés sur Javascript, pour des composants natifs HTML 5 non supportés (slider en fallback de range, par exemple)
Stratégie de gestion des dispositifs JavaScripts
Pas d'alternative obligatoire, si le dispositif est accessible et utilisable avec JS activé
Utilisation de ARIA pour rendre les dispositifs JS accessibles
Tester dans les AT l'accessibilité produite par les dispositifs Javascript
Pour accessiWeb
L'absence d'alternative à JavaScript est acceptée pour des contenus en HTML 5
Support partiel pour : Firefox, IE10, Chrome, Safari, NVDA, JAWS
5 Structure
Utilisation des nouveaux éléments de structure, exemple de structure HTML 5
Body
Header
Nav
Article
Header
Section
H1
Footer
Aside
Footer
Attention
SECTION
ARTICLE
FOOTER
ADDRESS
L'usage de ces éléments portent encore à débats.
Notamment l'utilisation des éléments SECTION et ARTICLE semblent poser beaucoup de problèmes aux producteurs de contenus.
Utilisation de l'outline
L'outline représente la structure du document basée sur les éléments sectionnants répartis en 3 catégories
Racine de section
Body
Section
Nav
Article
Section
Aside
Section implicite
Hx
Attention
L'OUTLINE est sujet à de nombreuses controverses.
On peut imaginer que, faute d'un usage suffisamment stable, il ne sera finalement pas utilisé pour l'accessibilité.
Utiliser le plan du document (H1 – H6) !
6 Formulaire et éléments interactifs
Support insuffisant des nouveaux types de formulaire
color
date (month week datetime)
email
number
time
url
required
placeholder
Support insuffisant des nouveaux éléments interactifs
<details>
<meter>
<output>
Utiliser des composants ou des méthodes alternatives en Javascript
Attention
A tester : le support évolue très vite sur ces éléments. !
placeholder ne peut pas remplacer un label !
Support partiel des nouveaux éléments de formulaire
<datalist>
<progress>
<range>
Support (datalist) : Firefox, IE10, Chrome, NVDA, JAWS
Support (datalist) inconnu pour : Safari
Support (progress) : Firefox, IE10, Chrome, NVDA, JAWS
Pas de support (progress) pour : Safari
Support (range) : IE10, Chrome, NVDA, JAWS
Support (range) partiel pour : Safari
Pas de Support (range) pour firefox
7 Navigation
<main>
<main> sera rendu obligatoire pour indiquer la zone de contenu principal
Attention
<main> devrait être unique dans la page
Il existe une différence d'interprétation entre HTML 5 et HTML LS !
Aucun support.
<nav>
<nav> sera rendu obligatoire pour indiquer les zones de navigation principales
Attention
doit être consacré aux éléments de navigation principaux
Les liens de pied de page se structurent avec plutôt qu'avec
Support pour : Firefox
Pas de support pour : IE10, Chrome, Safari, NVDA, JAWS
Utilisation des landmarks ARIA
Les rôles landmark ARIA permettent de positionner des "repères" sur la structure du document pour faciliter la navigation.
Mapping HTML 5
Landmark : HTML5
Banner : Header de la page
Main : Main
Navigation : Nav
Complementary : Aside
Contentinfo : Footer de la page
8 ARIA - Méthodes de conceptions et d'utilisation
Utiliser de préférence un élément ou un attribut HTML 5 équivalent, sauf si :
Le rendu visuel n'est pas satisfaisant
Les navigateurs ne supportent pas l'élément
Les navigateurs supportent l'élément mais les technologies d'assistance non
Ne pas changer le rôle natif d'un élément via ARIA sauf si c'est l'unique solution pour le rendre accessible
Ne pas faire <h1 role=button>text</h1> qui va renvoyer <button> text</button> (Le titre sera ignoré par les AT)
Conception pour tous ("design for all"): Prendre en compte les personnes âgées ou handicapées dès le début va également être utile aux autres utilisateurs
Méthodologie "écologique": Analysée les besoins d’utilisateur en milieu réel
Conception centrée sur l'utilisateur ("user-centered design")
Les utilisateurs : la population "normale".
C'est à dire, comprenant aussi des personnes handicapées ou très âgées.
Tri par carte
Marche à suivre
Créer une carte pour chaque item de contenu (env. 50): titre et description
Laisser les utilisateurs (20+) regrouper les cartes selon leur logique
Demander aux utilisateurs de nommer ces groupes
Variantes
Exporation = tri de cartes ouvert
Validation = tri de carte fermé
Objectifs
Se base non seulement sur les catégorisations, mais aussi sur les commentaires des participants lors/après l'exercice
le "dantrogram" permet de visualiser les lien entre les cartes/pages du site
Avantagees
Facile à mettre en place
En ligne, recueil et analyse aisés et rapides
Implication des utilisateurs finaux
Constructif: regroupement et taxonomie
Tree testing
Le "tree testing" a pour but de tester la pertinence dune arborescence de site web
Marche à suivre
Entrer l'arbo dans un outil en ligne
Créer des tâches en indiquant la ou les bonne réponses
Demander à des participant d'effectuer les taches en ligne.
L'outil : Optimal workshop
Avantages
Facile à mettre en place
En ligne, receuil et analyse des données aisée
Se base sur des taches utilisateurs
Permet de tester aussi bien la logique des catégorisation que la clarté des libellés (taxonomie)
Indique des chemins/emplacements alternatif, complémentaires ou plus davantage accessibleslisateur.
