Les technologies d’accessibilité de HTML5 permettent aux outils comme les narrateurs ou les loupes d’accéder aux contenus des pages web correctement.
L’accessibilité du web signifie que les sites web, les outils et les technologies sont conçus et développés de façon à ce que les personnes handicapées puissent les utiliser. Plus précisément, les personnes peuvent :
- percevoir, comprendre, naviguer et interagir avec le web ;
- contribuer sur le web.
L’accessibilité du web comprend tous les handicaps affectant l’accès au web, en particulier le handicap :
- auditif ;
- cognitif ;
- neurologique ;
- physique ;
- de la parole ;
- visuel.
L’accessibilité du web bénéficie également aux personnes sans handicap, par exemple :
- les personnes utilisant un téléphone mobile, une montre connectée, une télévision connectée, et autres périphériques ayant des petits écrans, différents modes de saisie, etc. ;
- les personnes âgées dont les capacités changent avec l’âge ;
- les personnes ayant un « handicap temporaire » tel qu’un bras cassé ou perdu leurs lunettes ;
- les personnes ayant « une limitation situationnelle » comme être en plein soleil ou dans un environnement où elles ne peuvent pas écouter l’audio ;
- les personnes utilisant une connexion internet lente ou ayant une bande passante limitée ou onéreuse.
Pour qu'une fonctionnalité de HTML (ou de toute autre technologie Web) soit considérée comme accessible, trois choses doivent se produire :
- Le navigateur doit prendre en charge la fonctionnalité
Cela signifie que le navigateur reconnaît la fonctionnalité et fournit le rendu visuel et/ou le comportement attendu. Lorsque le W3C publie une nouvelle version de HTML, il s'assure que chaque élément, attribut et API est pris en charge dans au moins deux navigateurs. Cela donne aux développeurs un degré raisonnable de confiance que les fonctionnalités du HTML W3C fonctionneront à l'état brut. - Le navigateur doit exposer la fonctionnalité à l'API d'accessibilité de la plateforme
C'est ce que l'on entend par « prise en charge de l'accessibilité du navigateur ». En plus de prendre en charge une fonctionnalité comme décrit ci-dessus, le navigateur doit également exposer des informations sur le rôle, le nom, les propriétés et les états de la fonctionnalité à l'API d'accessibilité de la plateforme.
Le niveau de prise en charge de l'accessibilité HTML5 dans les navigateurs populaires est suivi sur html5accessibility.com. Il s'agit de tests et de résultats accessibles au public qui sont mis à jour à mesure que de nouvelles versions de navigateur sont publiées. - La technologie d'assistance doit obtenir et utiliser des informations sur la fonctionnalité à l'aide de l'API d'accessibilité de la plateforme
Ces informations sont utilisées par les technologies d'assistance de différentes manières - par un lecteur d'écran pour indiquer à quelqu'un le type de fonctionnalité qu'il utilise, ou par un outil de reconnaissance vocale pour permettre à quelqu'un de cibler un objet particulier par exemple.
En d'autres termes, le navigateur est responsable de la prise en charge d'une fonctionnalité et de son exposition à l'API d'accessibilité de la plateforme, et la technologie d'assistance est responsable de l'utilisation de ces informations pour aider les utilisateurs à accéder au contenu du navigateur. Si le navigateur ou la technologie d'assistance ne remplissent pas leurs responsabilités, la prise en charge de l'accessibilité n'est pas complète.
Le classement des navigateurs
Dans la pratique, cela signifie que différentes combinaisons de navigateurs et de technologies d'assistance offrent différents niveaux de prise en charge de l'accessibilité. Par exemple, Edge prend désormais en charge à 100 % l'accessibilité pour HTML5, et Narrator (le lecteur d'écran Windows intégré) en profite pleinement - ce qui signifie qu'Edge est extrêmement utilisable avec le lecteur d'écran Narrator. En revanche, d'autres lecteurs d'écran n'ont pas encore profité des informations d'accessibilité exposées par Edge, et donc pour l'instant ce navigateur reste largement inutilisable avec ces produits.
Microsoft Edge a donc répondu à tous critères testés, que ce soit au niveau de sections et regroupement (article, section, nav, header, footer) que des graphiques et des médias (canvas, audio, video, track) sans oublier les contrôles et les propriétés.
Il est suivi de près par Safari qui s’offre un score de 98 %, puis de Chrome avec 92 % et Firefox avec 89 %. Internet Explorer est très loin derrière avec ses 56 %.
Comment sont effectués les tests ?
Chaque fonctionnalité a sa propre page de test, y compris les critères de réussite et les références de spécification pour le mappage requis de la fonctionnalité HTML à la couche d'accessibilité de la plateforme.
La prise en charge par le navigateur d'une fonctionnalité est automatiquement détectée. Cela permet de vérifier si le navigateur peut prétendre à la prise en charge de la fonctionnalité via la détection d'objet, mais pas que la fonctionnalité est prise en charge correctement. Si une fonctionnalité n'est pas prise en charge, elle est exclue de la notation.
Si une fonctionnalité est prise en charge, l'étape suivante consiste à tester si elle est correctement mappée à la couche d'accessibilité de la plateforme. Cela doit être testé manuellement. Cela peut être fait avec l'un des outils répertoriés par HTML5accessibility.
Pour être pris en charge de manière accessible, les éléments qui représentent des commandes interactives doivent être entièrement accessibles au clavier. Les actions qui doivent pouvoir être effectuées sont répertoriées dans le fichier de test, mais les raccourcis peuvent être différents entre les navigateurs et les plateformes.
En célébrant cette note, l’équipe Microsoft Edge a indiqué sur Twitter qu’elle a travaillé dur pour améliorer la prise en charge de l'accessibilité, avec des fonctionnalités telles que UI Automation et des contrôles plus accessibles.
Mais en y regardant de plus près, nous pouvons noter que même si Edge 80 a été testé, Chrome 62 est loin d'être un navigateur récent, ce qui en fait une comparaison plutôt injuste. Mais pour rappel c'est l'équipe HTML5 Accessibility qui est responsable de la mise à jour des versions de navigateur qu'ils vérifient. Néanmoins, ce que nous pouvons retenir est l'amélioration d'Edge en matière d'accessibilité, qui avait pris du retard sur le sujet après la transition vers Chromium (l’ancienne version de Microsoft Edge avait déjà atteint ce score, mais le passage à la base Chromium avait marqué un recul de la part du navigateur).
Source : HTML5 Accessibility, Microsoft Edge
Et vous ?
Vous servez-vous souvent des fonctionnalités d'accessibilité ?
Lesquelles et sur quel navigateur ?
Cette étude est elle bonne ? pertinente ? mal faite ? ou mensongère selon vous ?