Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
Rough notes from #CRAW2013

Conférence Romande sur l'Accessibilité du Web 2013

About

Rough notes from CRAW2013

I posted these notes immediately after each talk. Expect typos, formatting glitches, incomplete thoughts, and ...

And yeah, it was in french.

Hashtag

#CRAW2013

Lieu de la conférence

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é numérique : définition et enjeux pour les utilisateurs

Orateurs : Florian Egger & Laetitia Giannettini, Telono

La législation suisse impose le critère AA pour les administration publique.

Présentation de JAWS (Job Access With Speech)

Pour aller plus loin


Présentation

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

Référence : http://www.w3.org/WAI/

Règles pour l’accessibilité des contenus Web

  • La WAI publie -entre autres guides -les WCAG («Web Content Accessibility Guidelines»)
    • Règles pour l’accessibilité des contenus Web
    • Aujourd’hui dans leur version 2.0
    • 4 principes, 12 règles avec critères de succès évaluables qui indiquent l’objectif opérationnel à atteindre
    • 3 niveaux de conformité : A, AA et AAA

Référence : http://www.w3.org/TR/WCAG/

Pour voir la liste de l’ensemble des guides édités par la WAI :http://www.w3.org/WAI/guid-tech.html

Exemple de recommandations:Structuration de l’information“

  • "Utiliser des titres, des listes, des abréviations et des citations pour structurer l’information”

Référence : référentiel AccessiWeb 2.2 http://www.accessiweb.org

Structuration de l’information:explication

  • 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

Référence : référentiel Accessiweb 2.2 (www.accessiweb.org) , “Accessibilité web”aux éditions Eyrolles, Armony Altinier

Exemple:Navigation avec le lecteur d’écran JAWS

  • Logiciel JAWS signifie : “Job Access WithSpeech”
  • 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
  • Pas d’usage de balises html de titres
    • Le contenu de lapage n’est pas accessible

Pour aller plus loin

  • Les WCAG 2.0:http://www.w3.org/TR/WCAG/
  • 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

Merci de votre attention. 16 avril 2013.
Laetitia Giannettini (giannettini@telono.com),Florian Egger (egger@telono.com), Telono.

Annotation collaborative pour l'Accessibilité des Vidéos sur le Web : le projet ACAV

Orateur: Benoît Encelle, Université de Lyon 1

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

Accessibilité web : démonstration de techniques d'évaluation rapide

Orateur: Jean-Pierre Villain, Quelios

Avant-propos

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

  1. CSS -> désactiver CSS
  2. Entourer -> personnalisé -> IMG
  3. Entourer -> personnalisé -> A
  4. 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

  1. CSS -> désactiver CSS
  2. Entourer -> personnalisé -> IFRAME
  3. Info-> afficher les attributs TITLE

Rechercher

  • Les IFRAMES sans attribut TITLE

Evaluer

  • Les titres données aux IFRAMES

3. Tableau

Paramètres

  1. CSS -> désactiver CSS
  2. Entourer -> tableaux -> TABLEAUX
  3. Entourer -> tableaux -> CAPTION
  4. Entourer -> tableaux -> CELLULES
  5. 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

  1. CSS -> désactiver CSS
  2. Entourer -> personnalisé -> A
  3. Entourer -> personnalisé-> IMG
  4. Images -> Afficher les attributs ALT

Rechercher

  • Les liens vides
  • Les liens-images vides

Paramètres

  1. CSS -> désactiver CSS
  2. Entourer -> personnalisé -> A
  3. Info -> Afficher les attributs TITLE

Rechercher

  • Les TITLE inutiles
  • Evaluer
  • La pertinence des TITLES

Paramètres

  1. CSS -> désactiver CSS
  2. Entourer -> indiquer les balises
  3. Entourer -> personnalisé -> A
  4. Entourer -> personnalisé-> IMG
  5. Images -> Afficher les attributs ALT
  6. 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

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

  1. CSS -> désactiver CSS
  2. 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

  1. CSS -> désactiver CSS
  2. Entourer -> personnalisé -> FORM
  3. Entourer-> personnalisé -> LABEL
  4. 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.

7. Navigation

Paramètres

  1. CSS -> désactiver CSS

Vérifier

  • La présence de liens d'accès rapides
  • Le fonctionnement des liens d'accès rapides

Démonstration d’usages mobiles

Orateur: Daniele Corciulo, Fondation Suisse Accès pour tous

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

Évaluation de l'accessibilité des téléphones tactiles à l'aide du test utilisateur : cas de iPhone et Android

Orateur: Arnaud Béguin, Haute École du Paysage, de l'Ingénierie et d'Architecture de Genève - HEPIA

Questionnaire SUS

Résultat:

  • Androide : 32.8
  • iPhone : 73.5

L'iPhone est plus accessible.

##systèmes positifs des système

Android:

  • Clavier numérique
  • Suppression
  • Navigation circulaire

iPhone:

  • Retour d'info
  • Gestes
  • Validation
  • Arborescence
  • Repère physique
  • Utilisable tel quel (pas besoin d'installer des logiciels tiers)

Points négatifs

Android:

  • Prise en main
  • Sensibilité
  • Réactivité
  • Validation
  • Retour d'info
  • Geste de défilement
  • Bords de l'écran
  • Localiser les objet
  • Clavier virtuel
  • Reconnaissance vocale

iPhone:

  • Démarrage
  • Suppression
  • Confirmation
  • Clavier virtuel
  • Reconnaissance vocale

Gestion de projet : Intégrer l'accessibilité dans un projet web, méthodes et enjeux

Orateur: Armonie Altinier, ACS Horizons Présentation: SlideShare

Évaluation

  • L'évaluation est la première étape
    • Méthodologie d'évaluation
    • Les référentiels - WCAG 2.0 : "La" référence en thermes d'accessibilité - AccessiWeb : Une méthode francophone d'évaluation de la conformité à WCAG.

Processus WCAG-EM

  1. Objectif et périmètre
    Tous les critères du AAA ne sont pas applicables. Même le W3C le dit.
  2. Exploration du site
    Qu'est-ce qu'il y a comme contenu
  3. Échantillon
    Produire 10-15 pages d'échantillon
  4. Évaluation
    Par critère. On dit s’il est "fait", "pas fait", "non applicable".
  5. 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

  1. Synthèse décideurs
  2. 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.

Méthodologies

  • Le plus important d'abord MIPAW
  • Le plus facile d'abord Accessibiliy Steps
  • Répartition des critères par profil métier

Conclusion

Une question de contexte, la formation au centre

HTML5, ARIA et accessibilité web : où en est-on ?

Orateur: Jean-Pierre Villain, Quelios

HTML4, Le Web de grand-papa

  • Language extrêmement simple.
  • 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.

WCAG fait ce qu'il peut

Pour le Web

C'est le graal de l'iPad

Avant-propos

Quelques nouveautés

Eléments:

  • Structure (<article>, <aside>, etc.)
  • Groupe (<figure>, <main>, etc.)
  • Embed (video, etc.)
  • Interactif (<details>,<summary>, etc.)
  • Contenu (<mark>, <small>, etc.)
  • Formulaire (C'est principalement là-dessus qu'est accès HTML5)

Modifications

Un lien peut contenir des élément de type block

Eléments / Attributs obsolètes

  • <applet>
  • <acronym>
  • <hgroup>
  • etc.

ARIA, Le Web accessbile

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

  1. Définir les composants d'interface et de structure
  2. Informer de l'état et des propriétés des composants d'interface
  3. Informer et gérer les mises à jour de contenu dynamique
  4. 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=off aria-live=polite aria-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 ?

  1. Le navigateur Web traite les éléments de la page via une API d'accessibilité
  2. Les informations (role, state, properties) sont transmises à l'API accessibilité système
  3. Le lecteur d'écran traite les informations mises à dispositions via les API accessibilité
  4. 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

  1. Définir les composants d'interface et de structure
  2. Informer de l'état et des propriétés des composants d'interface
  3. Informer et gérer les mises à jour de contenus dynamiques
  4. 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

Recommandations note WCAG2 :

<figure role="group" > 
<img src="pic.jpg" alt="La tour eiffel " > 
  <figcaption> 
    Photo: Copyright : AFP 2013</figcaption> 
</figure> 

La note suggère d'utiliser figure et figcaption pour gérer ce genre d'information

A retenir

  • L'attribut title ne doit jamais être utilisé pour insérer une alternative.
  • Des informations complémentaires (des métadonnées, par exemple) (copyright, date, auteur…) ne doivent jamais être données dans l'alternative ALT.
  • Bien que suggerées par HTML 5, ces informations ne doivent jamais être données via un title.

Support partiel (accessibilité au clavier) pour : Firefox, IE10, Chrome, Safari, NVDA, Jaws

Images légendées FIGURE et FIGCAPTION, Absence d'attribut alt

Spécification HTML 5

<figure> 
<img src="pic.jpg"> 
  <figcaption> 
    Légende de l'image 
 </figcaption> 
</figure> 

Fallback HTML 5

<figure role="group"> 
<img src="pic.jpg" alt="photo 1"> 
  <figcaption> 
    Légende de l'image (photo 1)
 </figcaption> 
</figure> 
  • L'attribut alt doit toujours être présent !
  • 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

Utilisation de SVG

SVG inline

<svg height="100px" width="100px" role="img" aria-label="Titre et description">
 <title>Titre</title>
  <desc>Description</desc>
 <rect fill="green" height="100px" width="100px"/>
</svg>
  • role="img" et aria-label permettent aux AT de restituer le tracé comme une "image" dont le nom est le contenu de aria-label

Fallback

<svg height="100px" width="100px" >
<rect fill="green" height="100px" width="100px"/>
</svg>
<a href="description.htm">Description </a>

Support pour : Firefox, Chrome, NVDA, JAWS

Pas de support pour : Safari

Support inconnu pour IE10

Utilisation de CANVAS

Exemple de code

<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

Audio-description inexploitable

Exemple de code:

<video src="brave.webm"> 
<track kind=subtitles src=brave.en.vtt srclang=en label="English"> 
<track kind=captions src=brave.en.hoh.vtt srclang=en label="Sous-trage malentendants"> 
</video>

L'attribut KIND indique le type de sous-titrage :

  • Subtitles : sous-titrage de traduction
  • Caption : sous-titrage pour malentendants

Attention :

  • L'audio-description n'est pas supportée actuellement
  • Utiliser une vidéo alternative

Support(vidéo) pour : IE10

Support partiel : Firefox, NVDA, JAWS

Pas de support : Chrome, Safari

Support (track) pour : IE10

Support partiel : Firefox, Chrome, Safari, NVDA, Jaws

Stratégie d'implémentation si <video> est requis

Vidéo avec sous-titrage uniquement
Utilisation de <video> et <track> en désactivant les contrôles natifs par une surcouche de contrôle Javascript

Utiliser des framerworks :

Vidéo avec sous-titrage et audio-description

  1. Utilisation de
  2. 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)

Faire <h1><button>text</button></h1>

A consulter
Using WAI-ARIA in HTML : http://www.w3.org/TR/aria-in-html/

Consulter et suivre attentivement les recommandations d'utilisation des rôles ARIA indiqués sur la note Using Aria in HTML !

  • Restriction d'utilisation des rôles pour chaque élément

Préconisation de surcharge des rôles natifs pour certains

Tester et valider un widget ARIA

Exemple d'un processus de vérification

  1. ARIA Role, State, Properties
  2. . Comportement API accessibilité
  3. Compatibilité avec la baseline

Exemple de Baseline

  1. JAWS – IE – Windows ou JAWS – Firefox – Windows
  2. NVDA – IE – Windows ou NVDA – Firefox – Windows
  3. VoiceOver – Safari - IOS

Exemple simple avec le slider du fork JQuery

  1. Vérifier
    1. Role=slider
    2. Valuemin, value max
    3. Valuenow, valuetext
    4. Comportement clavier (flèche droite/bas et haut/gauche)
  2. Vérfier
    1. Avec Awiever :
      1. Name
      2. Role
      3. Value
    2. Ou avec inspect 32 :
      1. legacyAccessibleName
      2. legacyAccessibleRole
      3. legacyAccessibleValue
  3. Manipuler le slider et vérifier que
    1. Value (avec Awiever) ou legacyAccessiblevalue avec Inspect32 est correctement mise à jour

Tester avec la Baseline

Le logiciel libre comme outil d'accessibilité à l'information pour les personnes déficientes visuelles

Orateur: Jean-Philippe Mengual, Accelibreinfo

Présentation de ORCA un lecteur d'écran sur Linux. Démonstration de l'utilisation de l'utilisation de Linux pour les personne malvoyantes.

Utilisabilité des systèmes interactifs: méthodes et techniques d'évaluation

Orateurs : Florian Egger & Laetitia Giannettini, Telono

3 philosophies de conception

  1. 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
  2. Méthodologie "écologique": Analysée les besoins d’utilisateur en milieu réel
  3. 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

  1. Créer une carte pour chaque item de contenu (env. 50): titre et description
  2. Laisser les utilisateurs (20+) regrouper les cartes selon leur logique
  3. 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

  1. Entrer l'arbo dans un outil en ligne
  2. Créer des tâches en indiquant la ou les bonne réponses
  3. 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.
  • Outils en ligne d'avantage accessible
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment