Web Almanac 2019: disponibilité



L'accessibilité sur le Web est essentielle pour une société juste et équitable. Plus notre sphère de vie sociale et professionnelle se met en ligne, plus il est important pour les personnes handicapées de pouvoir participer à toutes les interactions en ligne sans barrières supplémentaires. Tout comme les architectes en bâtiment peuvent prendre en charge ou négliger les technologies d'accessibilité telles que les rampes pour fauteuils roulants, les développeurs Web peuvent aider ou gêner les utilisateurs qui utilisent des moyens supplémentaires d'accéder à Internet.



En ce qui concerne les utilisateurs handicapés, nous devons nous rappeler que, souvent, ils utilisent les services de la même manière, simplement en utilisant d'autres outils. Parmi ces outils, les plus populaires sont: les lecteurs d'écran, les boucles d'écran, la mise à l'échelle du navigateur, l'augmentation de la taille du texte ou le contrôle vocal. Mais la liste ne se limite pas à eux.

Souvent, l'amélioration de l'accessibilité du site profite à tous. Bien que nous considérions généralement les personnes handicapées comme des personnes qui se trouvent dans cet état tout le temps, en fait, n'importe qui peut constater une perte temporaire de fonctionnalité. Par exemple, quelqu'un est aveugle, quelqu'un a une infection oculaire temporaire et quelqu'un est juste dans la rue sous le soleil brillant et aveuglant. Tout cela peut être la raison pour laquelle l'utilisateur n'est actuellement pas en mesure de voir ce qui s'affiche à l'écran. N'importe qui peut, pour une raison quelconque, devenir limité dans le temps, et donc l'amélioration de l'accessibilité de vos sites Web améliorera la commodité de tous les utilisateurs, quelle que soit leur condition.

Les directives d'accessibilité du contenu Web (WCAG) fournissent des recommandations sur la façon de rendre votre site accessible. Ces recommandations ont servi de base à notre analyse. Cependant, il existe souvent des situations dans lesquelles il est très difficile d'analyser par programme la disponibilité d'un site Web. Par exemple, une plate-forme Web offre plusieurs façons d'obtenir des résultats fonctionnels similaires, mais le code sous-jacent peut être radicalement différent. Par conséquent, notre analyse n'est qu'une estimation approximative de la disponibilité globale des sites Web.

Nous avons identifié quatre catégories principales: lisibilité, éléments multimédias sur le Web, facilité de navigation dans les pages et accessibilité à l'aide des technologies d'assistance.

Pendant les tests, nous n'avons pas trouvé de différence significative dans l'accessibilité entre les versions de bureau et mobile. En conséquence, tous les résultats que nous présentons concernent les versions de bureau, sauf indication contraire.

Lisibilité


Le but principal d'une page Web est de fournir du contenu avec lequel les utilisateurs souhaitent interagir. Ce contenu peut être une vidéo ou un ensemble d'images, mais le plus souvent, il s'agit de texte brut. C'est pourquoi il est extrêmement important que ce contenu textuel soit lisible. Si les visiteurs ne peuvent pas lire le contenu de la page Web, ils ne peuvent pas interagir avec elle, ce qui entraînera le fait qu'ils quittent simplement le site. Dans cette section, nous considérerons trois paramètres selon lesquels les sites ont été notés.

Contraste des couleurs


Il existe de nombreux exemples où les visiteurs ne peuvent pas voir clairement le contenu d'un site. Ils peuvent être daltoniens, incapables de distinguer la couleur du texte et du fond de la page (1 homme sur 12 et 1 femme sur 200 d'origine européenne). Peut-être que l'utilisateur lit simplement le texte en plein soleil, créant beaucoup d'éblouissement sur l'écran, ce qui nuit considérablement à la visibilité. Ou peut-être que c'est juste une personne âgée ayant une déficience visuelle, incapable de distinguer les couleurs aussi bien qu'avant.

Par conséquent, pour être sûr que votre site est lisible dans ces conditions, il est important que la couleur du texte soit suffisamment contrastée par rapport à l'arrière-plan.


Figure 1. Un exemple de texte insuffisamment contrasté. Gracieuseté de LookZook

Seuls 22,04% des sites rendent la couleur de tout le texte assez contrastée. Autrement dit, 4 sites sur 5 contiennent du texte qui se confond avec l'arrière-plan, ce qui complique sa lecture.

Veuillez noter que nous n'avons pas la possibilité d'analyser le texte à l'intérieur des images, donc la valeur que nous avons appelée est la limite supérieure du pourcentage de sites qui ont réussi le test

Zoom et zoom de page


L'utilisation d' une taille de police lisible et d'une zone de clic suffisante permet aux utilisateurs de lire du texte et d'interagir avec le site. Mais même les sites qui suivent exactement les recommandations mentionnées ne peuvent pas répondre pleinement aux besoins individuels spécifiques de chaque visiteur. C'est pourquoi les fonctionnalités spéciales de l'appareil telles que le zoom par pincement et le zoom sont importantes: elles permettent aux utilisateurs de personnaliser votre page en fonction de leurs besoins. Ou dans une situation de sites extrêmement inaccessibles utilisant de petites polices et boutons, cela donne toujours aux utilisateurs la possibilité d'interagir avec les éléments de la page.

Il existe de rares exemples où la désactivation de la mise à l'échelle est acceptable. Par exemple, lorsque la page en question est un jeu Web utilisant le contrôle tactile. Si vous laissez la possibilité d'évoluer dans cette situation, les appareils des joueurs effectueront un zoom avant et arrière à chaque fois que le joueur double-cliquera sur l'écran, ironiquement, rendant cette approche indisponible.

Par conséquent, les développeurs prennent en compte la possibilité de désactiver cette fonction en définissant l'une des deux propriétés suivantes dans la balise META de la fenêtre d'affichage :

  1. mise à l' échelle de l'utilisateur définie sur 0 ou non
  2. échelle maximale définie sur 1, 1,0

Malheureusement, les développeurs ont trop souvent abusé de cela, que presque chaque troisième site de la version mobile a cette fonctionnalité désactivée, et Apple (à partir d'iOS 10) ne permet plus aux développeurs de désactiver la fonction de zoom. Le navigateur mobile Safari ignore cette balise . Tous les sites, peu importe lesquels, peuvent être mis à l'échelle en utilisant le zoom sur les nouveaux appareils iOS.


Figure 2. Pourcentage de sites par type d'appareil sur lesquels la mise à l'échelle est désactivée

Définition du langage


Le Web regorge de contenu incroyable. Cependant, il y a un hic: dans le monde, il existe plus de 1000 langues différentes et le contenu que vous recherchez peut ne pas être disponible dans la langue que vous parlez. Ces dernières années, nous avons fait des progrès importants dans les technologies de traduction, et vous avez probablement utilisé l'une d'entre elles (par exemple, Google Translate).

Afin de faciliter cette opportunité, les technologies de traduction doivent savoir dans quelle langue le texte de vos pages est écrit. Cela se fait à l' aide de l'attribut lang . Sans cela, les ordinateurs sont obligés de le deviner. Comme vous l'avez peut-être deviné, cela entraîne de nombreuses erreurs, en particulier lorsque les pages sont multilingues (par exemple, naviguer sur votre page en anglais et le contenu de l'article en japonais).

Dans une plus grande mesure encore, ce problème est perceptible lors de l'utilisation de technologies de synthétiseur vocal, telles que les lecteurs d'écran, qui tentent de lire le texte dans une langue définie par défaut par l'utilisateur, sauf si une langue différente est spécifiée sur le site.

De notre analyse, il s'ensuit que 26,13% des pages ne spécifient pas la langue en utilisant l'attribut " lang ". Cela rend ce quart de toutes les pages potentiellement sujettes aux problèmes décrits ci-dessus. La bonne nouvelle est que parmi les sites utilisant l'attribut " lang ", 99,68% indiquent la valeur de langue de page correcte

Contenu distrayant


Certains utilisateurs, comme ceux qui ont des troubles cognitifs, ont du mal à se concentrer sur une tâche pendant longtemps. Ces utilisateurs ne veulent pas traiter de sites contenant un grand nombre d'éléments dynamiques et animés, surtout lorsque ces effets ne sont présents que pour la beauté et ne sont pas liés à la tâche en cours. Au minimum, ces utilisateurs doivent pouvoir désactiver toutes les animations distrayantes.

Malheureusement, nos données indiquent que les éléments dont l'animation se répète à l'infini sont assez courants sur Internet: 21,04% des pages l'utilisent avec les propriétés CSS de l'animation sans fin ou à l'aide des éléments <marquee> et <blink> .

Cependant, il convient de noter que la raison de la plupart de ces phénomènes est quelques bibliothèques CSS tierces populaires, qui sont définies par défaut pour une lecture d'animation en boucle sans fin.

Éléments multimédias Web


Texte alternatif pour les images


Les images sont une partie importante du Web moderne. Ils peuvent raconter des histoires intéressantes, attirer l'attention et susciter des émotions. Mais tout le monde ne peut pas voir ces images. Heureusement, en 1995, HTML version 2.0 a fourni une solution à ce problème - l'attribut «alt» . Il offre aux développeurs Web la possibilité d'ajouter une description textuelle des images que nous utilisons, donc lorsque quelqu'un ne peut pas voir cette image (ou que l'image ne s'est pas chargée), il reste la possibilité de lire un autre texte de description.

Malgré le fait que l'attribut alt ait été introduit il y a 25 ans, il n'est toujours pas utilisé pour certaines images par 49,91%, et il ne se produit pas du tout sur 8,68% des pages.

Légendes audio et vidéo


Comme les images sont bonnes pour la narration, le contenu audio et vidéo est également bon pour attirer l'attention et exprimer des idées. Lorsque l'audio et la vidéo ne sont pas signés, les utilisateurs qui, pour une raison quelconque, ne peuvent pas l'écouter actuellement, perdent une partie considérable de l'essence du matériel. C'est au sujet de la nécessité d'inclure des signatures audio et vidéo que nous entendons le plus souvent des plaintes de personnes sourdes ou malentendantes.

Sur la liste complète des sites utilisant les balises <audio> ou <video>, seulement 0,54% ajoutent des signatures (le critère de mesure était la présence de l'élément <track>).

Navigation de page pratique


Lorsque vous ouvrez le menu dans un restaurant, la première chose que vous faites probablement est de lire les titres des sections: collations, salades, plats principaux, desserts. Cela vous permet d'examiner rapidement le menu pour les options possibles, puis de passer immédiatement aux plats qui vous intéressent. De même, lorsqu'un visiteur ouvre une page Web, son objectif est de trouver les informations qui l'intéressent le plus - la principale raison pour laquelle il est venu sur la page. Afin d'aider les utilisateurs à trouver le contenu qui les intéresse le plus rapidement possible (et les éviter de cliquer sur le bouton "retour"), nous essayons de diviser le contenu de nos pages en plusieurs sections visuellement distinctes. Par exemple, la rubrique du site pour la navigation, les différentes rubriques de l'article, afin que les utilisateurs puissent rapidement passer par dessus leurs yeux, pied de page pour des informations complémentaires.

Bien que cela soit extrêmement important, nous devons prendre soin de la mise en page des pages afin que les appareils des visiteurs puissent reconnaître correctement ces sections individuelles. Pourquoi? Bien que la plupart des lecteurs utilisent la souris pour naviguer dans les pages, une grande proportion d'utilisateurs se fient aux claviers et aux lecteurs à l'écran. Le bon fonctionnement de ces appareils dépend davantage de la façon dont il reconnaît la mise en page.

Rubriques


Les titres sont utiles non seulement d'un point de vue visuel, mais aussi particulièrement importants pour les lecteurs à l'écran. Ils permettent aux lecteurs d'écran de passer rapidement d'une section à l'autre et indiquent où se termine une section et où commence la suivante.

Pour éviter de dérouter les utilisateurs de lecteurs d'écran, veillez à ne pas ignorer les niveaux d'en-tête. Par exemple, ne sautez pas de H1 directement à H3, en sautant H2. Pourquoi est-ce important? Parce que ce changement inattendu peut amener les utilisateurs de lecteurs d'écran à penser qu'ils ont manqué une partie du contenu. Cela peut les amener à commencer à rechercher une partie du contenu qu'ils auraient pu ignorer, même si ce n'est pas le cas. En plus de cela, vous n'aiderez les lecteurs que si vous adhérez à un seul style.

Cela dit, nous avons obtenu les résultats suivants:

  1. 89,36% des pages utilisent les titres d'une manière ou d'une autre. Génial
  2. 38,6% des pages ignorent les niveaux d'en-tête
  3. Étrange, mais les en-têtes H2 sont plus courants que H1 (note du traducteur: nous parlons très probablement du fait d'utiliser des en-têtes d'un certain niveau, et non de leur nombre sur la page)


Figure 3. La prévalence des niveaux d'en-tête

Index du contenu "principal"


Un index du contenu «principal» aide les lecteurs à l'écran à déterminer où commence le contenu principal d'une page Web, afin que les utilisateurs puissent y accéder directement. Sans cela, les utilisateurs de lecteurs d'écran sont obligés à chaque fois de parcourir manuellement toutes les sections de la navigation lorsqu'ils passent à la page suivante du site. Évidemment, c'est très fatigant.

Nous avons déterminé qu'une seule des quatre pages (26,03%) contient cet index. Et étonnamment, 8,06% des pages contenaient par erreur plus d'un index principal, forçant ses utilisateurs à deviner lequel des index reflète vraiment le contenu principal.


Figure 4. Le pourcentage de pages par le nombre d'index principaux

Éléments HTML en coupe


Depuis que HTML5 a été introduit en 2008 et est devenu la norme officielle en 2014, de nombreux éléments HTML sont apparus pour aider les ordinateurs et les lecteurs d'écran à comprendre la mise en page et la structure d'une page Web.

Des éléments tels que <header> , <footer> , <nav> et <main> indiquent dans quelle partie se trouve un type de contenu particulier et permet aux utilisateurs de naviguer rapidement sur la page. Ils sont largement utilisés en développement, la plupart d'entre eux étant utilisés sur plus de 50% des pages (la balise <main> est une exception).

D'autres balises, telles que <article> , <hr> et <aside>, aident les utilisateurs à comprendre le contenu principal de la page. Par exemple, il indique où se termine un article et où commence un autre. Ces éléments ne sont pas utilisés aussi souvent. Chacun a un taux de 20%. Ils ne font pas partie intégrante de la page, ce n'est donc pas nécessairement une alarme.

Tous ces éléments sont conçus principalement pour améliorer l'accessibilité et ne se distinguent pas visuellement, ce qui signifie que vous pouvez les remplacer par les éléments actuellement utilisés sans crainte de conséquences imprévues.


Figure 5. Utilisation de différents éléments HTML sémantiques

Autres éléments HTML de navigation


De nombreux lecteurs d'écran populaires permettent aux utilisateurs de parcourir rapidement les liens, les listes, les éléments de liste, les cadres et les champs de formulaire tels que les boutons, les boutons radio et les cases à cocher sur la page. La figure 6 montre la fréquence à laquelle nous avons rencontré des pages utilisant ces éléments.

Figure 6. Autres éléments HTML de navigation

Ignorer les liens


Les liens de saut sont des liens situés en haut de la page et permettent aux lecteurs d'écran ou aux utilisateurs utilisant uniquement le clavier d'accéder directement au contenu principal. Ils vous permettent de sauter tous les liens et menus de navigation en haut de la page. Les liens de saut sont particulièrement utiles pour les utilisateurs de clavier qui n'utilisent pas de lecteurs à l'écran, car ces utilisateurs n'ont généralement pas accès à d'autres modes de navigation rapide (par exemple, les en-têtes). Il a été constaté que 14,19% dans notre étude ont de tels liens.

Si vous êtes intéressé de voir comment fonctionne un tel lien, recherchez simplement sur Google et cliquez sur «onglet» sur la page de résultats. Un lien caché avant cela apparaîtra, comme dans la figure ci-dessous


Figure 7. Exemple de lien de saut sur Google

Lors de l'analyse du code de la page, il est assez difficile de déterminer le lien de saut. Dans cette étude, si nous avons trouvé un lien avec une ancre ( href = # header1 ) parmi les trois premiers liens d'une page, nous l'avons défini comme une page avec cet élément. Ainsi, 14,19% est la limite supérieure du partage de pages utilisant de tels liens.

Raccourcis clavier


Les raccourcis clavier définis via les raccourcis aria-keys ou les attributs accesskey peuvent être utilisés de deux manières:

  1. Activer un élément sur une page comme un lien ou un bouton
  2. Concentrez-vous sur un élément de page spécifique. Par exemple, déplacer le focus vers un champ de saisie spécifique sur une page permet à l'utilisateur de commencer à taper juste après.

À la suite de nos recherches, nous pouvons conclure que l' attribut aria-keyshortcuts n'est pratiquement pas utilisé, car il n'a été trouvé que sur 159 sites sur plus de 4 millions. L'attribut accesskey est utilisé plus souvent - à 2,47% des pages (1,74% sur les versions mobiles des sites). Nous sommes enclins à croire que son utilisation plus fréquente sur les versions de bureau des sites est due au fait que les développeurs pensent que les utilisateurs n'accèdent aux versions mobiles des sites qu'à partir d'appareils dotés d'écrans tactiles et n'utilisent pas de clavier.

Le fait que 15,56% des sites mobiles et 13,03% des sites de bureau qui utilisent des raccourcis clavier attribuent les mêmes combinaisons pour différents éléments est particulièrement inattendu. Cela signifie que le navigateur est obligé de deviner à quelle combinaison de touches particulière doit appartenir.

Des tables


Les tableaux sont l'un des principaux moyens d'organiser et de présenter de grandes quantités de données.De nombreuses technologies d'assistance, telles que les lecteurs d'écran et les commutateurs (qui peuvent être utiles aux utilisateurs dont la motricité est affaiblie), peuvent avoir des fonctions spéciales qui leur permettent de naviguer plus efficacement dans les données tabulaires.

Rubriques


En fonction de la structure particulière d'une table particulière, l'utilisation des en-têtes de table facilite la lecture des colonnes et des lignes sans perdre le contexte des données auxquelles cette colonne ou ligne particulière fait référence. Pour les utilisateurs de lecteurs d'écran, se déplacer dans un tableau sans en-têtes de ligne et de colonne n'est pas une tâche facile. En effet, il est difficile pour un lecteur d'écran de garder une trace de leur emplacement actuel dans un tableau sans en-têtes, en particulier lorsque le tableau est suffisamment grand.

Pour marquer les en- têtes de table, il suffit d' utiliser la balise <th> ( au lieu de <td> ), ou le rôle de Ar- columnheader ou RowHeader. Seulement 24,5% des pages du tableau ont été balisées en utilisant l'une des méthodes indiquées. Par conséquent, sur les trois quarts restants des pages, les développeurs ont présenté les tableaux sans en-têtes, créant des difficultés supplémentaires pour les utilisateurs de lecteurs d'écran.

L'utilisation des balises <th> et <td> était une méthode plus courante pour baliser les en-têtes de table. Rôles columnheader et RowHeader pratiquement pas utilisés: depuis rencontré que 677 sites (0,058%).

Légendes


Les légendes de table utilisant l'élément <caption> sont utiles pour fournir un contexte descriptif plus large aux lecteurs de tous types. La signature peut préparer le lecteur à la perception des informations contenues dans le tableau, ce qui peut être particulièrement utile pour les personnes qui peuvent facilement être distraites ou interrompues. Ils sont également utiles pour les personnes qui pourraient se perdre dans une grande table, telles que les utilisateurs de lecteurs d'écran ou les personnes ayant des troubles d'apprentissage ou de l'intelligence. Plus il est facile pour les lecteurs de comprendre quelles données leur sont présentées, mieux c'est.

Malgré cela, seulement 4,32% des pages du tableau ont une signature.

Compatibilité des technologies d'assistance


Utiliser ARIA


L'une des spécifications d'accessibilité Web les plus populaires et les plus utilisées est la norme ARIA ( Accessible Rich Internet Applications ). Cette norme offre de nombreux attributs HTML supplémentaires pour indiquer le rôle d'un élément, malgré sa représentation visuelle (c'est-à-dire leur signification sémantique) et les types d'actions pour lesquels ils sont conçus.

Une bonne utilisation d'ARIA peut être difficile. Par exemple, nous avons trouvé 12,31% des pages utilisant des valeurs non valides pour les attributs ARIA. Il s'agit d'un problème urgent, car les erreurs lors de l'utilisation des attributs ARIA ne sont pas visibles visuellement. Certaines de ces erreurs peuvent être détectées à l'aide d'outils de validation automatique, mais généralement, elles nécessitent toujours une vérification manuelle à l'aide de dispositifs d'assistance (tels que des lecteurs d'écran). Cette section définit comment ARIA est utilisé sur le Web et en particulier quelle partie de la norme est la plus courante


Figure 8. La popularité des attributs ARIA parmi les pages utilisatrices

Attribut de rôle


L'attribut role est le plus important dans toute la spécification ARIA. Il est utilisé pour informer le navigateur sur le but de cet élément HTML (c'est-à-dire sur la signification sémantique). Par exemple, un élément stylisé via CSS en tant que bouton doit recevoir le rôle " bouton " du rôle ARIA .

Actuellement, 46,91% des pages utilisent au moins l'attribut ARIA " rôle ". Dans la figure 9 ci-dessous, nous avons compilé une liste des dix valeurs les plus couramment utilisées des rôles ARIA.


Figure 9. 10 principaux rôles aria

En examinant les résultats de la figure 9, deux points intéressants peuvent être mis en évidence:

  • la mise à jour d'un cadre d'interface utilisateur peut avoir un impact majeur sur l'accessibilité du Web
  • un nombre impressionnant de sites essaient de mettre à disposition des fenêtres modales

La mise à jour des cadres d'interface utilisateur peut être un moyen d'augmenter l'accessibilité sur le Web


Les 5 premiers rôles, tous apparaissent sur 11% ou plus de pages et sont des rôles historiques. Ils sont utilisés pour faciliter la navigation et non pour décrire la fonctionnalité d'éléments tels qu'une liste déroulante. Il s'agit d'un résultat inattendu, car le principal motif d'ARIA était de donner aux développeurs la possibilité de décrire la fonctionnalité des éléments fabriqués à partir d'éléments HTML courants (par exemple, <div>).

Nous pensons que certains des cadres d'interface utilisateur les plus populaires ont inclus des rôles de navigation dans leurs modèles. Cela expliquerait l'utilisation généralisée d'attributs historiques. Si cette théorie est vraie, la mise à jour des cadres d'interface utilisateur populaires avec une meilleure prise en charge de l'accessibilité peut avoir un impact énorme sur l'accessibilité du Web.

Un autre résultat menant à cette conclusion est le fait que les attributs ARIA plus «avancés» mais tout aussi importants ne semblent pas du tout être utilisés. Ces attributs ne peuvent pas simplement être implémentés via des frameworks d'interface utilisateur, car ils peuvent avoir besoin d'être configurés en fonction de la structure et de l'apparence d'un site particulier. Par exemple, nous avons constaté que les attributs posinset et setsize n'étaient utilisés que sur 0,01% des pages. Ces attributs indiquent à l'utilisateur du lecteur d'écran combien d'éléments se trouvent dans la liste des menus et lequel est actuellement sélectionné. Ainsi, si un utilisateur malvoyant essaie de naviguer dans le menu, il doit entendre une annonce, par exemple: "Accueil, 1 sur 5", "Produits, 2 sur 5", "Téléchargements, 3 sur 5", etc.

De nombreux sites essaient de rendre les fenêtres modales disponibles.


Le rôle de la boîte de dialogue est relativement populaire, car rendre les fenêtres modales accessibles aux lecteurs d'écran est très difficile. C'est pourquoi il est très impressionnant que 8% des pages analysées l'ont fait tout de même. Encore une fois, nous soupçonnons que cette métrique aurait pu être atteinte grâce à l'utilisation de certains cadres d'interface utilisateur spécifiques.

Étiquettes de texte pour les éléments interactifs


La façon la plus courante pour un utilisateur d'interagir avec un site consiste à utiliser ses contrôles, tels que des liens ou des boutons. Cependant, les lecteurs d'écran ne savent souvent pas quelle action entreprendra l'élément lorsqu'il sera activé. Cette confusion se produit souvent en raison de l'absence d'étiquettes de texte sur les éléments. Par exemple, un bouton contenant une icône de flèche gauche indiquant qu'il s'agit d'un bouton Retour, mais ne contenant pas de description textuelle de celui-ci.

Environ un quart seulement (24,39%) des pages utilisent des boutons ou des liens qui incluent des étiquettes de texte. Si l'élément ne contient pas une telle étiquette de texte, l'utilisateur du lecteur d'écran peut lire quelque chose en commun, par exemple, le mot «bouton» au lieu de la «recherche» plus spécifique.

Les boutons et les liens peuvent presque toujours être sélectionnés à l'aide du bouton Tab et ont donc une apparence proéminente. La navigation sur un site à l'aide du bouton Tab est l'un des principaux moyens par lesquels les utilisateurs utilisant uniquement le clavier peuvent parcourir votre site. Ainsi, l'utilisateur rencontrera certainement des boutons et des liens qui ne sont pas marqués de texte s'il navigue sur le site à l'aide du bouton Tab.

Disponibilité des éléments de formulaire


Remplir des formulaires est une tâche que beaucoup d'entre nous accomplissons tous les jours. Que nous effectuions des achats, achetions un billet ou envoyions un CV, les formulaires sont le principal moyen de transmettre des informations à un site Web. Pour cette raison, rendre les formulaires accessibles est extrêmement important. La manière la plus simple d'y parvenir est de spécifier un nom pour chaque champ de saisie via la balise <label> ou les attributs aria-label ou aria-labelledby . Malheureusement, seulement 22,33% des pages ont des noms pour tous les champs de saisie de formulaire, ce qui signifie que 4 pages sur 5 ont des formulaires difficiles à remplir

Pointeurs de champ obligatoires et mal remplis


Lorsque nous rencontrons un champ avec un gros astérisque rouge, nous savons que cela est obligatoire. Ou lorsque nous cliquons sur «Soumettre» et que nous recevons un message indiquant que des données incorrectes ont été saisies, tous les champs mis en évidence dans une couleur différente doivent être corrigés et le formulaire sera renvoyé. Cependant, les personnes malvoyantes ou aveugles ne peuvent pas se fier à ces indices visuels, c'est pourquoi l'attribut HTML « requis » ou les attributs ARIA aria-required et aria-invalid sont si importants . Ils offrent aux lecteurs d'écran une alternative à la mise en évidence de l'étoile rouge et du champ. Sous la forme d'un joli bonus, lorsque vous indiquez au navigateur les champs obligatoires, eux-mêmes , sans recourir à JavaScript, vérifieront l'exactitude des champs remplis.

De toutes les pages sur lesquelles les formulaires sont présents, 21,73% utilisent les attributs requis ou aria-requis lors du marquage des champs obligatoires. Seul un site sur cinq l'utilise. Il s'agit d'une étape facile pour rendre votre site accessible et déverrouiller des fonctionnalités de navigateur utiles pour tous les utilisateurs.

Nous avons également trouvé 3,52% des sites avec des formulaires balisés à l'aide de l'attribut aria-invalid . Cependant, comme leur effet ne se produit qu'après l'envoi d'un formulaire avec des champs incorrectement remplis, nous n'avons pas pu déterminer le pourcentage exact de sites qui les utilisent dans le balisage.

ID de duplication


Les ID peuvent être utiles en HTML pour lier deux éléments. Par exemple, l'élément <label> fonctionne de cette façon . Vous spécifiez l'ID du champ de saisie décrit par cette étiquette et le navigateur les associe. Quel est le résultat? Les utilisateurs peuvent maintenant cliquer sur cette étiquette pour se concentrer sur le champ de saisie, et les lecteurs d'écran l'utiliseront comme description.

Malheureusement, la duplication des ID se produit sur 34,62% ​​des sites, ce qui signifie que sur de nombreux sites, l'ID spécifié par l'utilisateur peut faire référence à plusieurs champs de saisie différents. Ainsi, lorsque l'utilisateur clique sur l'étiquette pour mettre en surbrillance le champ de saisie, il peut finalement se concentrer sur le mauvais élément auquel il s'attendait. Comme vous pouvez l'imaginer, cela peut entraîner des conséquences particulièrement désastreuses, par exemple, sur la page de paiement de la boutique en ligne.

Ce problème est encore plus prononcé pour les lecteurs d'écran, car leurs utilisateurs peuvent ne pas être en mesure de vérifier visuellement ce qui est exactement sélectionné. De plus, de nombreux attributs ARIA, tels que aria-descriptionsby et aria-labelledby , fonctionnent de manière similaire à l'élément <label>décrit ci-dessus. Ainsi, pour rendre votre site accessible, la suppression de tous les identifiants en double est une bonne première étape.

Conclusion


Non seulement les personnes handicapées ont besoin d'accessibilité. Par exemple, toute personne qui se blesse temporairement un poignet peut avoir du mal à faire passer la souris sur une petite zone de pression. La vision s'aggrave souvent avec l'âge, ce qui rend difficile la lecture de petits textes. La dextérité des doigts chez les personnes d'âges différents est également différente, ce qui rend difficile pour la plupart des utilisateurs de cliquer sur des éléments interactifs ou de glisser sur des versions mobiles de sites.

De même, les logiciels auxiliaires sont conçus non seulement pour les personnes handicapées, mais également pour augmenter la commodité du travail quotidien:

  • , , , . ,
  • , , , . ,
  • , ,

Après la création d'un site, il est souvent difficile de mettre en œuvre l'accessibilité pour une structure de site existante et ses éléments. La disponibilité n'est pas quelque chose qui peut ensuite être ajoutée au produit fini, elle devrait faire partie du processus de conception et de mise en œuvre. Malheureusement, en raison du manque d'outils pointant sur ce point, de nombreux développeurs ne connaissent pas les besoins de tous les autres utilisateurs et les exigences des appareils qu'ils utilisent.

Bien que les résultats de nos recherches ne soient pas définitifs, ils indiquent que l'utilisation de normes telles que l'ARIA et les meilleures pratiques d'accessibilité (par exemple, l'utilisation de texte alternatif) se trouve sur une partie considérable mais non essentielle d'Internet. À première vue, les indicateurs sont assez encourageants, mais nous soupçonnons un mérite considérable dans ce cadre d'assurance-chômage. D'une part, c'est une nouvelle décevante, car les développeurs ne peuvent pas simplement compter sur des frameworks pour rendre leurs sites accessibles. D'un autre côté, il est agréable de voir dans quelle mesure les frameworks peuvent affecter l'accessibilité à Internet.

Le prochain objectif, à notre avis, est de rendre les éléments fournis avec les cadres plus accessibles. Étant donné que de nombreux widgets complexes utilisés dans les produits (par exemple, un widget de calendrier) sont des bibliothèques prêtes à l'emploi, ce serait formidable s'ils étaient initialement conçus dans un souci d'accessibilité. Nous espérons que lorsque nous effectuerons l'analyse suivante, l'utilisation de rôles ARIA complexes plus correctement mis en œuvre augmentera, ce qui signifie que des éléments plus complexes deviendront également plus accessibles. En outre, nous voulons exprimer notre espoir de voir des éléments multimédias plus accessibles, tels que des images et des vidéos, afin que tous les utilisateurs puissent profiter de la richesse du Web.

Source: https://habr.com/ru/post/fr476208/


All Articles