Accessibilité web – Meetup CDI

Dans le cadre des meetups internes que j’organise chez CDI, j’ai présenté une introduction à l’accessibilité web.

Transcript

1. Accessibilité web - Luc Poupard CDI meetup #11 / 10 décembre 2020 1
2. Qu’est-ce que l’accessibilité web ? 2
3. Une petite histoire (de l’accessibilité) du web 3 • 1989 – Invention du World Wide Web par Tim Berners-Lee et Robert Cailliau • 1994 – Création du W3C (World Wide Web Consortium) • 1995 – Lancement d’Amazon : l’ère e-commerce • 1996 – Création de la WAI (Web Accessibility Initative) • 1997 – Lancement de Google : l’ère des machines • 1999 – Publication des WCAG (Web Content Accessibility Guidelines) • 2000 – Flash intégré dans les navigateurs : l’ère multimédia • 2001 – Sortie d’Internet Explorer 6 • 2004 – Sortie de Firefox • 2005 – Première vidéo sur YouTube : l’ère vidéo • 2006 – Facebook est ouvert au grand public : l’ère sociale • 2007 – Sortie de l’iPhone : l’ère mobile • 2012 – Sortie des Google Glass : l’ère des objets connectés
4. Définition de l’accessibilité web « Mettre le Web et ses services à la disposition de tous les individus, quel que soit leur matériel ou logiciel, leur infrastructure réseau, leur langue maternelle, leur culture, leur localisation géographique, ou leurs aptitudes physiques ou mentales. » — Tim Berners-Lee, inventeur du World Wide Web 4
5. Numéronyme « a11y » accessibility a11y 5 1 2 3 4 5 6 7 8 9 10 11
6. Qu’est-ce que le(s) handicap(s) ? 6
7. Définition du handicap « Constitue un handicap […] toute limitation d'activité ou restriction de participation à la vie en société subie dans son environnement par une personne en raison d'une altération substantielle, durable ou définitive d'une ou plusieurs fonctions physiques, sensorielles, mentales, cognitives ou psychiques, d'un polyhandicap ou d'un trouble de santé invalidant. » — Loi n°2005-102 pour l'égalité des droits et des chances, la participation et la citoyenneté des personnes handicapées, article 114 - 11 février 2005 7
8. Statistiques en Suisse • 1,7 millions de personnes (20% de la population) en situation de handicap1 • Environ 250 000 personnes avec une limitation fonctionnelle importante ou totale1 • 377 000 personnes aveugles ou malvoyantes2 • 15 % de la population de plus de 15 ans souffre d’au moins une limitation fonctionnelle, surtout les plus de 65 ans1 • 1 français sur 3 aura plus de 60 ans en 2035 (contre 1 sur 5 en 2005) 8 1. https://www.bfs.admin.ch/bfs/fr/home/statistiques/sante/etat-sante/handicaps.html 2. https://www.ucba.ch/footer/service/actualites/detail/?tx_news_pi1[news]=225&cHash=4dc737d9b02ae1a3535dd78dd0efb53b
9. Types de handicaps • Moteurs • Sensoriels • Ouïe • Vue • Cognitifs et mentaux • Troubles DYS • Autisme • Du quotidien • Illectronisme / inhabilité numérique 9
10. Simulations de handicaps 10
11. Outils pour naviguer sur le web 11
12. Exemple : Switch Control iOS 12 https://support.apple.com/fr-fr/HT201370
13. Exemple : iPhone utilisé par un aveugle 13
14. Exemple : accessibilité by design 14 https://www.apple.com/accessibility/
15. Handicap ≠ déficience Ce n'est pas la personne qui est handicapée, c'est son environnement qui la met en situation de handicap. Sur le web, c’est le site qui handicape l’internaute, pas une éventuelle déficience. 15
16. Normes et réglementations 16
17. Standards et travaux du W3C • 1997 – Création de la WAI (Web Accessibility Initiative) • 1999 – Publication des WCAG 1.0 (Web Content Accessibility Guidelines) • 2000 – Publication des ATAG 1.0 (Authoring Tool Accessibility Guidelines) • 2002 – Publication des UAAG 1.0 (User Agent Accessibility Guidelines) • 2008 – WCAG 2.0 • 2014 – Publication des WAI-ARIA 1.0 (Web Accessibility Initiative - Accessible Rich Internet Applications) • 2015 – ATAG 2.0 et UAAG 2.0 • 2017 – WAI-ARIA 1.1 • 2018 – WCAG 2.1 • À venir – WCAG 2.2 en 2021 ; WCAG 3.0 en préparation 17
18. Norme ISO En 2012, les WCAG 2.0 sont reconnues comme un standard ISO avec la norme ISO/IEC 40500:2012 18
19. En France et dans l’Union Européenne • 1997 – Création de l’association Braillenet • 2003 – Braillenet publie le référentiel Accessiweb 1.0, basé sur WCAG 1.0 • 2005 – Loi n°2005-102 du 11 février 2005 pour l’égalité des droits et des chances, la participation et la citoyenneté des personnes handicapées • 2009 – Publication du RGAA (Référentiel Général d’Accessibilité des Administrations), basé sur WCAG 2.0 • 2016 – Directive (UE) 2016/2102 relative à l'accessibilité des sites internet et des applications mobiles des organismes du secteur public • 2018 – Le standard européen EN 301 549 « Accessibility requirements for ICT products and services » définit WCAG 2.1 comme référence pour l'accessibilité des contenus web, des documents électroniques et des applications numériques • 2019 – RGAA 4 (Référentiel Général d’Amélioration de l’Accessibilité), basé sur WCAG 2.1 19
20. En Suisse • 2000 – Création de l’association Access for all • 2004 – Loi fédérale sur l’égalité pour les handicapés (LHand) • 2005 – Norme fédérale « P028 – Directives de la Confédération pour l’aménagement de sites Internet facilement accessibles » basée sur WCAG 1.0 • 2007 – Norme d’accessibilité eCH-0059 v.01.0, s’appuyant sur la norme P028 • 2010 – Accessibility Checklist 2.0 basée sur WCAG 2.0 • 2016 – P028 2.03 basée sur WCAG 2.0 • 2020 – Adaptations WCAG 2.1 • eCH-0059 v.03.0 • Nouvelle checklist (site pas encore public, actuellement en beta) 20
21. L’accessibilité en pratique : plongée dans les WCAG 21
22. Introduction aux WCAG • 4 principes (POUR) • Perceptible • Utilisable • Compréhensible • Robuste • 13 règles • 78 critères (sur 3 niveaux : A, AA, AAA) • 312 tests 22
23. Perceptible L’information et les composants de l’interface utilisateur doivent être présentés à l'utilisateur de façon à ce qu’il puisse les percevoir. 23
24. 1.1 – Proposer des alternatives textuelles à tout contenu non textuel • Toutes les images ont une alternative • Toutes les images décoratives ont une alternative vide • Les informations des images complexes (par exemple graphiques) sont disponibles dans un format textuel • Les boutons de formulaires ont un intitulé explicite • Les champs de formulaire sont associés à des étiquettes • Les contenus multimédias et cadres (iframes) sont identifiés par un titre 24
25. 1.2 – Fournir des sous-titres et autres alternatives pour le multimédia Les médias audio et/ou vidéo, doivent être accompagnés d’au moins une des alternatives suivantes : • Retranscription textuelle (exemple) ou audiodescription • Sous-titres synchronisés • Langue des signes [AAA] Qu’il s’agisse d’un média pré- enregistré ou en direct [AA]. 25
26. 1.3 – Créer des contenus qui peuvent être présentés de différentes manières, y compris par les technologies d’assistance, sans perdre la signification • Les balises sémantiques sont correctement utilisées pour indiquer les titres, régions, listes, tableaux de données… • L’ordre de lecture et de navigation dans le code source est logique • Les instructions ne se basent pas seulement sur la forme, la taille ou la position, ni ne sont transmises uniquement par le son • L’orientation du contenu n’est pas limitée [AA] • Le type de contenu attendu dans les champs de formulaires est identifié [AA] 26
27. 1.4 – Faciliter la perception visuelle et auditive du contenu par l’utilisateur • L’information n’est pas transmise uniquement par la couleur • Tout son de plus de 3 secondes doit pouvoir être contrôlé par l’utilisateur • Le rapport de contraste entre un élément et son fond [AA] : • Est d’au moins 4.5:1 pour le texte ; • Est d’au moins 3:1 pour les éléments graphiques (icônes par exemple) • La page est lisible et fonctionnelle avec un zoom à 200% [AA] • Il n’y a pas de perte de contenu ou de fonctionnalité sur une largeur d’affichage de 320 pixels [AA] 27
28. Utilisable Les composants de l’interface utilisateur et de navigation doivent être utilisables. 28
29. 2.1 – Rendre toutes les fonctionnalités accessibles au clavier • Toutes les fonctionnalités sont utilisables à l’aide du clavier, sauf si elle ne peut pas être accomplie d’une autre manière (par exemple dessin à main levée) • Il n’y a pas de piège au clavier dans la page • Si un raccourci clavier utilise un caractère imprimable (lettres, chiffres…) seul, il peut être désactivé ou reprogrammé 29
30. 2.2 – Laisser à l’utilisateur suffisamment de temps pour lire et utiliser le contenu • Si une page ou une application a une limite de temps, l’utilisateur peut supprimer, ajuster ou allonger cette limite • Tout contenu animé pendant plus de 5 secondes peut être contrôlé par l’utilisateur 30 2.3 – Ne pas concevoir de contenus susceptibles de provoquer des crises ou des réactions physiques • Aucun contenu de la page ne flashe plus de 3 fois par seconde, sauf si petit, avec un contraste faible et contient peu de rouges
31. 2.4 – Aider l’utilisateur à naviguer et trouver le contenu • Un lien d’évitement permet d’aller directement au contenu • La page web a un titre informatif et descriptif • Le contenu est structuré avec des titres correctement hiérarchisés • L’ordre de tabulation est logique et intuitif • La fonction de chaque lien et bouton est explicite • Il existe plusieurs moyens d’accéder à une page [AA] • Le focus est visible [AA] 31
32. 2.5 – Faciliter l’utilisation d’outils de saisie autres que le clavier • Les mouvements multipoints ou basés sur un chemin (balayage de l’écran) peuvent être effectué avec une activation en un point • Les actions en un point ne doivent pas être déclenchées à l’action de pression (mousedown, touchstart) mais au relâchement (mouseup, touchend) et doivent pouvoir être annulées • Les fonctionnalités activées par le mouvement (de l’appareil ou de l’utilisateur) peuvent être désactivées • Les zones cliquables doivent mesurer au minimum 44 sur 44 pixels [AAA] 32
33. Compréhensible Les informations et l’utilisation de l’interface utilisateur doivent être compréhensibles. 33
34. 3.1 – Rendre le texte lisible et compréhensible • La langue de la page est indiquée • Les changements de langue dans la page sont indiqués [AA] • Les termes rares, ambigus, inconnus ou spécifiques sont définis dans un texte adjacent ou un glossaire [AAA] • Le sens des abréviations est founi [AAA] • Une alternative plus compréhensive est fournie pour tous les contenus dont le niveau de lecture est trop avancé (universitaire) [AAA] 34
35. 3.2 – Faire en sorte que les contenus apparaissent et fonctionnent de manière prévisible • Le déplacement du focus ou la saisie d’information par l’utilisateur ne déclenchent pas un changement de contexte (ouverture de nouvelle fenêtre, validation de formulaire…) • Les liens de navigation qui se répètent sur plusieurs pages se présentent dans le même ordre et au même emplacement sur toutes les pages [AA] • Les éléments avec la même fonctionnalité se présentent de manière cohérente sur chaque page [AA] 35
36. 3.3 – Aider l’utilisateur à éviter et corriger les erreurs • Les erreurs de formulaire doivent être fournies dans les étiquettes des champs correspondants • Les étiquettes et instructions des champs de formulaire sont correctement positionnées et balisées • En cas d’erreur, une suggestion explicite permet de comprendre l’erreur et de la corriger [AA] • Si l’utilisateur peut modifier ou supprimer des données légales, financières ou de tests, ces actions peuvent être annulées, vérifiées ou confirmées [AA] 36
37. Robuste Le contenu doit être suffisamment robuste pour être interprété de manière fiable par une large variété d’agents utilisateurs, y compris les technologies d’assistance. 37
38. 4.1 – Optimiser la compatibilité avec les outils des utilisateurs actuels et futurs • Le code HTML/XHTML doit être valide • Le balisage des composants web respecte les spécifications HTML/XHTML afin de les rendre accessibles ; au besoin ARIA doit être utilisé si le code HTML de base ne suffit pas • Si un message d’état ou d’alerte est affiché et que le focus n’est pas placé dessus, ce message doit être annoncés programmatiquement (avec ARIA) [AA] 38
39. Comment améliorer l’accessibilité de nos sites et applications ? 39
40. Premier pas : certification Opquast • Bonnes pratiques Opquast1 • 41 bonnes pratiques liées à l’accessibilité (sur 240) • Check-list « Premier pas vers WCAG »2 • 81 bonnes pratiques de base pour l’accessibilité 40 1. https://checklists.opquast.com/fr/qualiteweb/ 2. https://checklists.opquast.com/fr/accessibility-first-step/
41. AcceDe Web par Atalan 41 https://accede.info/ • Notices pratiques et opérationnelles par métier • Conception fonctionnelle et graphique • Intégration HTML et CSS • Interfaces riches • Contenu éditorial
42. Outils de développement des navigateurs 42
43. Attention aux tests automatiques ! • Ne couvrent qu’une faible partie des critères • Environ 25 % des critères dans le meilleur des cas • Une bonne note sur les outils de tests automatiques ne garantit pas du tout un bon niveau d’accessibilité Contre-exemple créé par Manuel Matuzović : https://cdpn.io/matuzo/debug/LYGxLLJ Score Lighthouse de 100 alors qu’inutilisable pour la plupart des internautes. Explications complémentaires sur son blog : https://www.matuzo.at/blog/accessible-to-some 43
44. Extensions 44 1. headingsMap sur Firefox ou sur Chrome 1 2 2. https://ffoodd.github.io/a11y.css/
45. Livres 45 1. https://www.eyrolles.com/Informatique/Livre/accessibilite-web-2e-edition-9782212674620/ 2. https://www.eyrolles.com/Informatique/Livre/accessibilite-web-9782212128895/ 3. https://abookapart.com/products/accessibility-for-everyone 4. https://inclusive-components.design/ 2 3 4 1
46. Quelques ressources supplémentaires • Introduction à l'accessibilité du web par la WAI • Apprendre le développement web / Accessibilité sur MDN • Checklist WCAG 2.1 de WebAIM par AnySurfer • The A11Y Project • Accessibility Developer Guide • Principes de Conception Inclusive • Colloque national en ligne E-Accessibilité 2020 • a11y-resources par Atalan • #100daysofa11y par Loriane Buffet 46
47. Merci pour votre écoute 47