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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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/
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
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
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
kloh
nrslib
os1ma
azukiazusa1
koic
prof18
zakky21
marcustung
takamin55
seike460
palkan
ivargrimstad
.jpg){kind=avatar}
yumnumm
robhawkes
lara
panda_program
addyosmani
jmmastey
aki_iinuma
smashingmag
sachag
lauravandoore
danielanewman
mraible