C'est une période passionnante pour travailler dans le domaine de l'accessibilité numérique ! Il y a encore quelques années à peine, il pouvait s'avérer difficile de trouver un poste vacant de spécialiste de l'accessibilité, surtout si l'on ciblait les entreprises du secteur privé. Dans certains cas, il y avait certes des postes à pourvoir, mais il s'agissait soit de missions à temps partiel rattachées à un poste technique « classique », soit de fonctions rattachées au service UX. Aujourd’hui, je constate qu’il existe beaucoup plus d’opportunités autonomes dans le domaine de l’accessibilité numérique au sein d’entreprises du classement Fortune 500 telles que Microsoft, Google, Target, JPMorgan Chase, Prudential et bien d’autres encore.
Je pense que cette évolution des efforts en matière d’accessibilité est due en partie à la prise de conscience et en partie à l’éducation. Bien sûr, je ne suis pas naïf au point de croire que les poursuites judiciaires n’ont joué aucun rôle dans ce domaine – selon Usable Net, on recense plus de 40 nouvelles poursuites par semaine en matière d’accessibilité, avec un total de plus de 2 200 actions en justice intentées en 2018 –, mais j’aimerais espérer que cela ne représente qu’une petite partie de l’équation. Si les poursuites judiciaires peuvent dans un premier temps ouvrir la voie à l’accessibilité numérique, on peut espérer qu’une fois que davantage de professionnels et d’entreprises du secteur technologique auront pris conscience de l’intérêt d’intégrer l’inclusivité dans leurs produits, cette voie restera ouverte et accessible à tous – et pas seulement sous la contrainte d’une procédure judiciaire.
Mais quelle que soit la raison pour laquelle l’accessibilité numérique semble se développer si rapidement, une chose est sûre : à mesure que le nombre d’emplois dans ce domaine augmente, le besoin de former ces futurs professionnels de l’accessibilité s’accroît également. Dans le cadre de mon travail chez Deque, j’ai eu la chance de faire partie du programme de formation dispensée par un formateur (ILT). Ce programme est assuré par une équipe d’experts en accessibilité qui forment des professionnels techniques aux différents aspects de l’accessibilité numérique. Nous abordons un large éventail de sujets, notamment l’accessibilité sur mobile, la conception et l’accessibilité pour les développeurs.
DequeL’équipe ILT de [nom de l’entreprise] a été très occupée à animer des sessions de formation, tant en présentiel qu’en ligne, aux quatre coins du monde. Au cours des derniers mois, j’ai, à moi seul, parcouru plus de 8 000 miles et animé au total 25 jours de formation (et d’autres sont à venir)… et je suis loin d’être le membre le plus occupé de notre équipe ! Au cours de mes récents déplacements, j’ai rassemblé une liste de questions posées par les concepteurs et les développeurs sur le terrain. Quelle que soit la taille de l’entreprise ou le secteur d’activité, vous serez peut-être surpris d’apprendre que bon nombre de leurs questions se recoupent. Vous trouverez ci-dessous les cinq questions qui reviennent le plus souvent, ainsi que quelques éléments de contexte et ressources pour en savoir un peu plus sur chacune d’entre elles.
À quelles règles d'accessibilité dois-je prêter attention ?
Pour lancer chaque session de formation, nous aimons poser la question suivante au public : « Quelle est la première chose qui vous vient à l’esprit lorsque vous entendez le mot « accessibilité » ? » Nous posons cette question pour établir un lien avec le public et susciter son intérêt dès le début, mais aussi pour évaluer son niveau de connaissance en matière d’accessibilité. Bien sûr, les réponses sont très variées, mais celle que j’entends le plus souvent est : « Je ne sais pas trop quelles directives suivre. » Il existe une grande confusion quant aux réglementations en matière d’accessibilité que les entreprises sont tenues de respecter en général, mais plus particulièrement en ce qui concerne les WCAG. Avec la publication des WCAG 2.1 l’année dernière, la situation est encore plus déroutante pour les débutants.
Tout d'abord, prenons un peu de recul…qu'est-ce que les WCAG au juste? WCAG est l'acronyme de « Web Content Accessibility Guidelines » (Directives pour l'accessibilité des contenus Web) et version 1.0 a été publiée en 1999 par le World Wide Web Consortium (W3C). À l’origine, ces directives ne concernaient que le langage HTML et avaient pour objectif d’uniformiser les normes d’accessibilité sur le Web naissant. Fin 2008, la version 2.0 des WCAG a été mise à disposition du grand public. Cette version n’était pas liée à une technologie spécifique et couvrait de nombreux autres aspects du handicap, notamment la cécité et la malvoyance, la surdité et la perte auditive, les troubles d’apprentissage, les limitations cognitives, la mobilité réduite, les troubles de la parole, la photosensibilité, et bien d’autres encore.
Les WCAG 2.0 ont marqué une étape majeure dans l’évolution des normes d’accessibilité. En effet, en octobre 2012, l’Organisation internationale de normalisation (ISO) a établi les WCAG 2.0 comme norme numérique en matière d’accessibilité, et celles-ci sont devenues la « référence absolue » pour de nombreux pays et organisations à travers le monde. Bien sûr, il existe également des réglementations spécifiques à certains pays et à certains secteurs (par exemple, la section 508 aux États-Unis) qui ont donné lieu à des référentiels distincts en matière d'accessibilité . La liste complète des réglementations est variée et en constante évolution ; elle peut varier d’un client à l’autre. C’est pourquoi nous avons tendance à nous concentrer sur les règles de base des WCAG lors de nos formations.
Faisons un bond en avant de quelques années jusqu’en 2018, où l’on assiste à une nouvelle évolution des WCAG avec la la version 2.1. En raison des avancées technologiques et d’une meilleure compréhension des besoins des utilisateurs, les modifications apportées aux WCAG 2.1 se sont concentrées sur l’accessibilité aux appareils mobiles et aux tablettes, ainsi que sur les utilisateurs malvoyants et ceux présentant des troubles cognitifs. Les WCAG 2.1 sont considérées comme une extension des WCAG 2.0, et non comme un remplacement. Notre collègue Glenda Sims a rédigé une excellente série d’articles sur les WCAG 2.1 que je recommande vivement aux personnes et aux organisations souhaitant approfondir le sujet.
Comme nous le savons tous, les directives WCAG peuvent très vite devenir extrêmement complexes… C’est pourquoi, pour les débutants, j’essaie de me concentrer sur les aspects concrets de ces directives, à savoir les concepts P.O.U.R.: Perceptible, Utilisable, Compréhensible et Robuste.
La première catégorie du modèle P.O.U.R. est « Perceptible ». Cela signifie que les utilisateurs doivent être capables de percevoir les informations présentées ; celles-ci ne doivent pas être invisibles à l'un de leurs sens.
- Questions : Y a-t-il des éléments sur notre site web ou notre application qu’une personne en situation de handicap ne serait pas en mesure de percevoir ? Notre site est-il compatible avec différents types d’appareils d’assistance technique ? Veillez à prendre en compte tous les types de handicaps : déficiences visuelles, motrices, auditives, cognitives et de la parole, troubles vestibulaires et épileptiques, et bien d’autres encore.
- Exemples : ajouter des descriptions textuelles aux images non décoratives, ajouter des légendes et des transcriptions aux vidéos, veiller à ce que la couleur ne soit pas le seul moyen de transmettre du sens.
La deuxième catégorie est celle « Utilisable ». Les utilisateurs doivent pouvoir utiliser l’interface ; celle-ci ne doit pas exiger d’interaction qu’un utilisateur ne serait pas en mesure d’effectuer.
- Questions : Les utilisateurs peuvent-ils interagir avec les éléments interactifs de notre site web/application ? Notre site web comporte-t-il des pièges ?
- Exemples : permettre la navigation uniquement au clavier, s'assurer que toutes les commandes des diaporamas sont visibles, veiller à ce que les utilisateurs disposent de suffisamment de temps pour remplir un formulaire.
La troisième catégorie est Compréhensible. Les utilisateurs doivent être capables de comprendre les informations ainsi que le fonctionnement de l’interface utilisateur ; le contenu ou le fonctionnement ne doit pas dépasser leur niveau de compréhension.
- Questions : Le contenu est-il rédigé de manière claire ? Toutes les interactions sont-elles faciles à comprendre ? La structure de la page est-elle logique ?
- Exemples : rédigez du contenu adapté à un niveau de lecture de 3e – n'utilisez pas un mot compliqué quand un mot simple suffit, veillez à ce que votre site web soit intuitif, et assurez-vous que les messages d'erreur affichés sur votre site soient clairs et faciles à résoudre.
La dernière catégorie est « Robuste ». Cela signifie que les utilisateurs doivent pouvoir accéder au contenu à mesure que les technologies progressent : même si les technologies et les agents utilisateurs évoluent, le contenu doit rester accessible.
- Questions : Notre site web est-il compatible uniquement avec les navigateurs ou les systèmes d'exploitation les plus récents ? Notre site web a-t-il été développé conformément aux meilleures pratiques ? Fonctionne-t-il aussi bien en mode paysage qu'en mode portrait ?
- Il n'y a pas d'exemples concrets à ce sujet… Testez simplement votre site web ou votre application ! Veillez à utiliser tous les types d'outils : tests automatiques, manuels, tests avec des technologies d'assistance et tests utilisateurs. Après vos premiers tests d'accessibilité, effectuez d'autres tests à chaque fois que de nouvelles fonctionnalités sont ajoutées.
L'esprit qui anime P.O.U.R. ne consiste pas à respecter à la lettre des règles strictes et immuables, mais plutôt à comprendre et à répondre aux besoins variés de vos utilisateurs. Une fois que vous avez intégré cette idée, le respect des directives WCAG devient davantage une feuille de route qu'une liste de tâches à accomplir.
Qu'est-ce qu'ARIA et en ai-je vraiment besoin ?
Après les WCAG, la question qui revient le plus souvent concerne toujours ARIA. En fonction du niveau de connaissance du public en matière d’accessibilité et/ou de développement, on me pose des questions allant de : « Qu’est-ce que c’est ? En ai-je vraiment besoin ? Pourquoi ne puis-je pas simplement utiliser du HTML ? » À vrai dire, lorsque j’ai entendu le terme « ARIA » pour la première fois, j’ai supposé qu’il s’agissait simplement d’un autre langage de programmation autonome. Avec toutes les variantes de JavaScript et de CSS qui existent, il est logique qu’ARIA suive le mouvement. Mais ARIA est un peu différent.
Tout d'abord, ARIA est l'acronyme de « Accessible Rich Internet Applications » (applications Internet riches et accessibles) et son nom officiel est WAI-ARIA (mais beaucoup l’appellent par son nom abrégé). Il a été développé pour la première fois en 2008 par la Web Accessibility Initiative (WAI) , un sous-groupe du World Wide Web Consortium (W3C) qui régit et encadre l’accessibilité du Web.
ARIA se définit comme un ensemble d'attributs destinés à corriger les balisages incorrects et à combler les lacunes du langage HTML afin d'offrir une expérience plus accessible aux utilisateurs de technologies d'assistance (TA). L'intégration correcte d'ARIA dans votre code garantit que les utilisateurs de technologies d'assistance disposeront de toutes les informations nécessaires pour utiliser votre site web ou votre application. En d'autres termes, ARIA est un code d'aide qui comble le fossé entre le site web ou l'application et l'utilisateur de technologies d'assistance.
Le modèle ARIA peut être décomposé comme suit :
- Rôles — définissent ce qu’est un élément ou ce qu’il fait.
- Propriétés — expriment les caractéristiques ou les relations d’un objet.
- États et valeurs — définissent les conditions actuelles ou les valeurs associées à l'élément.
Avez-vous besoin d'ARIA ? Eh bien, comme pour beaucoup de questions d'accessibilité numérique « Ça dépend »™. ARIA était autrefois le meilleur choix pour rendre le code entièrement accessible, mais les éléments HTML ont pris un peu le relais. Pour simplifier les choses aux débutants, lors des sessions de formation « Deque », nous rappelons la première règle d’ARIA établie par le W3C :
« Si vous pouvez utiliser un élément ou un attribut HTML natif intégrant déjà la sémantique et le comportement dont vous avez besoin, plutôt que de détourner un élément de sa fonction d'origine et d'y ajouter un rôle, un état ou une propriété ARIA pour le rendre accessible, alors faites-le. »
Ou, comme j'aime à le reformuler (en m'efforçant de prendre la voix de Brad Pitt dans le film Fight Club de 1999) : « La première règle d'ARIA est : n'utilisez pas ARIA. »
En cas de doute, utilisez des éléments HTML *pris en charge*, puis recourez à ARIA. Pour vérifier la compatibilité des navigateurs, je consulte souvent des sites web tels que HTML5 Accessibility, Can I Useou la liste des « ARIA dans les attributs HTML » avant de décider si je peux utiliser des éléments HTML ou ARIA pour un modèle particulier. Pour en savoir plus sur ARIA et voir quelques exemples, consultez Much Ado About ARIA et pratiquement n’importe quel article que Scott O’Hara écrit ou code.
Quelle est la meilleure façon d'ajouter un contenu alternatif aux images ?
La troisième question la plus fréquente porte généralement sur le texte alternatif. Je suis ravie que le message soit passé : les images ont besoin de descriptions ! Mais bien sûr, ce n’est pas aussi simple que ça. Selon le type d’image, vous devrez peut-être adapter votre approche pour ajouter du contenu alternatif. La première étape consiste à réfléchir à l’objectif de votre image. S’agit-il d’informer un utilisateur ? De créer une « ambiance » sur le site web ? Joue-t-elle un rôle fonctionnel ? Déterminer la « catégorie » de votre image n’est pas toujours une tâche facile, mais l’utilisation des arbres de décision pour les balises alt peut vous aider.
If an image is decorative, you need to hide it from assistive technology devices (ATs). You can use different methods like CSS background images or web fonts. You can also use the <img> tag, but then the decorative image needs to have an empty/null alternative text attribute. This sends a signal to the AT to ignore this image as it is not necessary for understanding the content or action on the page. An empty/null alternative text attribute is not the same as a missing alternative text attribute. If the alternative text is just missing, the AT might read out the file name or surrounding content in an attempt to give the user more information about the image.
En revanche, si vous estimez qu'une image est informative, veillez à inclure des informations alternatives concernant cette image. Il existe de nombreux modèles d’accessibilité différents pour les images que vous pouvez utiliser pour atteindre cet objectif ; choisissez celle(s) qui s’intègre(nt) le mieux à votre framework ou à votre CMS. Quel que soit le modèle choisi, veillez à ce que votre texte alternatif soit pertinent et descriptif, et qu’il ne soit pas répétitif. De plus, n’utilisez pas d’expressions telles que « image de » ou « graphique de » pour décrire une image. Un lecteur d’écran fournit déjà cette information à l’utilisateur.
Lorsque j’aborde la question de la rédaction d’un bon contenu alternatif, j’utilise souvent l’analogie du téléphone. Si vous appeliez un ami et que vous lui disiez simplement « Chien marron » avant de raccrocher, votre ami risquerait d’être perplexe. Si vous appeliez un ami et que vous lui disiez « Le chien marron est assis sur la plage », cela permettrait de brosser un tableau plus vivant sans pour autant ajouter trop de complexité ni de travail. Bien sûr, un utilisateur de lecteur d'écran devra écouter votre contenu alternatif, alors n'en faites pas trop. C'est pourquoi nous vous recommandons de ne pas dépasser 250 caractères pour votre contenu alternatif. Si vous avez besoin d'ajouter davantage de contexte à l'image (par exemple, un graphique complexe), il existe d'autres modèles ou méthodes plus descriptifs que vous pouvez utiliser pour fournir plus de détails.
Another kind of informative image is an “actionable” image – which is a tricky one for a lot of people. This is where an image acts as a link or performs a functionality. If your image is actionable you need to provide information about the function of the image instead of describing the image. For example, if you use a magnifying glass as your “submit” button on a search form, that is completely fine. But the alternative text should *not* read <img alt=“magnifying glass”> but something about the action that will happen when you click or press on it <img alt=“Search this website”>.
Pourquoi l'utilisation d'un outil d'accessibilité automatisé ne suffit-elle pas ?
Les professionnels du secteur des technologies adorent les outils. C'est tout à fait logique. Nous sommes nombreux à nous souvenir de la première fois où nous avons utilisé un ordinateur (un petit clin d'œil à mon Commodore 64) et repensons avec nostalgie à l’époque des téléphones à clapet. Je n’aime pas porter de bijoux, je n’ai donc jamais acheté d’Apple Watch… mais je me souviens de son lancement et des files d’attente interminables qui s’étaient formées pour en obtenir une.
Je ne suis donc pas surpris lorsque, lors de formations ou de conférences, on m’interroge sur les outils d’accessibilité. Les gens veulent appuyer sur quelques boutons et *pouf !* faire apparaître des créatures magiques capables de se charger de repérer et de résoudre tous leurs problèmes. Bien sûr, ils n’apprécient pas ma réponse : quel que soit l’outil utilisé, les tests automatiques ne peuvent détecter de manière fiable que 30 à 40 % de tous les problèmes d’accessibilité. De plus, certains outils sont plus efficaces pour détecter certains problèmes d’accessibilité, tandis que d’autres sont mieux adaptés pour repérer d’autres erreurs ; il est donc indispensable d’utiliser une suite d’outils. Par-dessus tout, parmi les problèmes détectés par les outils de test automatisés, beaucoup nécessitent encore l’intervention d’un humain pour interpréter les résultats et hiérarchiser les problèmes. Par exemple, un outil de test automatisé peut vous signaler qu’il manque un texte alternatif à votre image, mais il ne peut pas vous indiquer quel texte alternatif rédiger. Ouf… rien que d’y penser, c’est épuisant !
Mais tout n’est pas noir ! La bonne nouvelle, c’est que les outils de tests automatisés sont vraiment incroyables et deviennent de plus en plus « intelligents » à chaque nouvelle version. Il se peut que, d’ici peu, ces outils soient capables de détecter de manière fiable près de 100 % des problèmes, voire de les corriger pour vous. Mais d’ici là, vous pouvez ajouter des tests UX/UI, des tests manuels au clavier, des tests tactiles sur mobile, des tests avec des lecteurs d’écran (et d’autres technologies d’assistance), des tests de lisibilité du contenu et (ce qui est, à mon avis, le plus important) des tests utilisateurs à votre workflow afin de combler les lacunes laissées par les tests automatisés. N’oubliez pas non plus d’ajouter une déclaration d’accessibilité et de mettre à la disposition des utilisateurs un moyen accessible de vous contacter pour tout problème qu’ils pourraient rencontrer avec votre site web ou votre application ; cela contribue grandement à l’expérience utilisateur globale et à la satisfaction des utilisateurs.
Pour vous aider à démarrer, voici quelques outils de tests automatisés utiles que nous vous recommandons :
Qu'en est-il de l'accessibilité sur mobile ?
Le mobile peut être une source de grande confusion pour les personnes qui découvrent l’accessibilité, et c’est un sujet qui revient souvent lors de nos sessions de formation. Certaines personnes sont surprises d’apprendre que les personnes malvoyantes utilisent des appareils mobiles pour, par exemple, naviguer sur Internet ou consulter leurs e-mails. Beaucoup ignoraient que ces appareils sont équipés de lecteurs d’écran, dont bon nombre sont intégrés d’origine. À vrai dire, je faisais moi-même partie de ces personnes il n’y a pas si longtemps.
Je me souviens encore de la première fois où j’ai vu quelqu’un utiliser un lecteur d’écran mobile en personne. Je me rendais au déjeuner avec Rachel Olivero lors d’une conférence sur les technologies lorsque j’ai remarqué qu’elle avait un écouteur dans l’oreille gauche et son téléphone à la main. Elle tapotait frénétiquement sur un écran noir. Sachant que Rachel était aveugle, je me suis arrêtée et lui ai demandé si elle avait besoin d’aide pour allumer son téléphone. Elle a ri et m’a répondu que son téléphone fonctionnait parfaitement et qu’elle venait simplement d’activer le « rideau d’écran » sur son appareil iOS, ce qui lui offrait davantage d’intimité face aux regards indiscrets.
Selon la dernière enquête de WebAIM sur les lecteurs d'écran, 88 % des personnes ayant répondu utilisent des lecteurs d’écran mobiles sur leurs appareils mobiles, et ce chiffre a considérablement augmenté au cours des dernières années. Parmi les personnes interrogées, 75,6 % préféraient les appareils iOS (par exemple, l’iPad ou l’iPhone) équipés du lecteur d’écran VoiceOver, suivis par les appareils Android (22,0 %) utilisant le lecteur d’écran TalkBack. Non seulement le nombre d’utilisateurs mobiles augmente, mais 54 % des personnes interrogées ont indiqué qu’elles utilisaient autant les lecteurs d’écran mobiles que ceux pour ordinateurs de bureau, ce qui fait du mobile non seulement une nouveauté, mais un élément essentiel de la vie quotidienne. Outre cette augmentation du nombre d’utilisateurs, bon nombre des nouvelles directives WCAG 2.1 se concentrent sur les ; le mobile est donc un domaine crucial à maîtriser en matière d’accessibilité.
Mais par où commencer en matière d'accessibilité mobile ? Eh bien, le plus simple est de prendre votre smartphone et d'activer le lecteur d'écran ! Contrairement à la plupart des lecteurs d'écran pour ordinateurs de bureau, ceux destinés aux appareils mobiles sont généralement préinstallés sur votre appareil et s'utilisent de manière assez intuitive une fois que vous avez pris le coup de main avec quelques gestes de balayage et de tapotement.
Utilisation de VoiceOver sur iOS
Activer VoiceOver
- Pour activer VoiceOver, rendez-vous dans « Réglages » > « Général » > « Accessibilité », puis activez l'option « VoiceOver ».
- Vous pouvez également activer le lecteur d'écran à l'aide de Siri. Accédez à « Réglages » > « Siri et recherche » > Activez l'option « Écouter “Hey Siri” ». Dites ensuite : « Hey, Siri. Active VoiceOver. »
Brève démonstration avec VoiceOver
- Appuyez avec un doigt sur l'écran de votre iPhone pour sélectionner l'écran d'accueil, puis faites glisser votre doigt de gauche à droite. VoiceOver annoncera le nom de l'application sélectionnée.
- Une fois que vous êtes sur l'application que vous souhaitez ouvrir, appuyez deux fois avec un doigt n'importe où sur l'écran pour la lancer.
Désactiver VoiceOver
- Vous pouvez désactiver VoiceOver en vous rendant dans « Réglages » > « Général » > « Accessibilité », puis en désactivant l'option « VoiceOver ».
- Vous pouvez également désactiver le lecteur d'écran à l'aide de Siri. Il suffit de dire : « Hey, Siri. Désactive VoiceOver. »
Ressources VoiceOver pour iOS
- Guides sur les raccourcis clavier et les gestes de VoiceOver – https://dequeuniversity.com/screenreaders/voiceover-ios-shortcuts
- Liste complète des commandes – http://tinyurl.com/commands-voiceover-ios
Utilisation de TalkBack sur Android
Activer TalkBack
- Pour activer TalkBack, rendez-vous dans « Paramètres » > « Accessibilité » > « TalkBack », puis basculez le commutateur sur ON. Remarque : sur certains appareils Android, vous devez d'abord installer l'application TalkBack.
Brève démonstration avec TalkBack
- Accédez à un site web accessible, tel que le site principal du W3C à l'aide du navigateur Chrome ou Firefox.
- Faites glisser un doigt de haut en bas pour parcourir les éléments que vous souhaitez explorer dans TalkBack. Dans cette démonstration, choisissez « Titres ».
- Avec un seul doigt, faites glisser votre doigt de gauche à droite pour écouter les titres de la page dans l'ordre, du haut vers le bas. Vous remarquerez peut-être que la hauteur du son augmente à mesure que vous descendez dans la page. Cela permet à l'utilisateur d'une technologie d'assistance d'avoir une idée de la longueur de la page.
- Double-cliquez sur n'importe quel titre cliquable pour accéder à une nouvelle page.
Désactiver TalkBack
- Vous pouvez désactiver TalkBack en vous rendant dans « Paramètres » > « Accessibilité » > « TalkBack »
- Appuyez une fois sur « TalkBack » pour le sélectionner, puis appuyez deux fois dessus pour basculer le commutateur sur « OFF ».
Ressources TalkBack
- Guide des raccourcis et des gestes de TalkBack – https://dequeuniversity.com/screenreaders/talkback-shortcuts
- Liste complète des commandes – http://tinyurl.com/commands-talkback
Une fois que vous serez plus à l’aise avec l’utilisation des lecteurs d’écran sur mobile, parcourez quelques-uns de vos sites web ou applications préférés : vous remarquerez rapidement la différence entre ceux qui sont accessibles et ceux qui ne le sont pas. Une fois que vous maîtriserez cela, vous pourrez passer aux tests de lecture d’écran sur mobile. Le site Deque propose également quelques outils qui peuvent vous aider dans cette démarche (mentionnés plus haut) ! Bien sûr, utiliser occasionnellement votre lecteur d’écran mobile ne fera pas de vous un expert. Mais nous espérons que le fait de tester certaines de ces démos et de réaliser ces tests vous aidera à développer davantage d’empathie et à comprendre que l’accessibilité numérique n’est pas simplement un plus, ni quelque chose que l’on met en place si l’on en a le temps ou le budget, mais qu’il s’agit d’un élément essentiel pour bon nombre de vos utilisateurs.
Récapitulatif
Comme vous pouvez le constater à travers ces cinq questions-réponses sur l’ILT, il y a beaucoup à savoir en matière d’accessibilité numérique… et ce n’est que la partie émergée de l’iceberg ! J’espère sincèrement que cet article vous a aidé à répondre à certaines questions fondamentales que vous vous posiez peut-être sur l’accessibilité numérique et qu’il vous a donné envie d’en savoir plus. Je vous encourage à laisser un commentaire ci-dessous ou sur Twitter si vous avez des questions. Bien sûr, je ne connais pas moi-même toutes les réponses, mais la communauté de l’accessibilité regorge de personnes formidables et je suis sûr que nous pourrons trouver une réponse (voire deux ou trois) à n’importe quelle question posée.
Pour finir, je voudrais simplement vous adresser quelques mots d'encouragement. Je comprends que l'accessibilité numérique puisse parfois sembler insurmontable, mais il est important de ne pas perdre espoir et de continuer à poser des questions.
« Seuls, nous ne pouvons pas faire grand-chose ; ensemble, nous pouvons faire tant de choses. » – Helen Keller
