Tous nos articles en français sur l’utilisation de l’API WAI-ARIA (Accessible Rich Internet Application), qui permet d’améliorer l’accessibilité des composants riches sur le web, grâce à des motifs de conception qui fonctionnent de manière homogène et prédictive pour les personnes aveugles ou malvoyantes utilisant un lecteur d’écran.
Les chargements de données dynamiques sont monnaie courante, mais peuvent poser des problèmes aux personnes qui naviguent avec des technologies d’assistance. Voyons comment mettre en place une solution accessible et éviter les pertes d’information !
aria-live et ses analogues alert, log, status
Dans la spécification ARIA, les « live regions » (littéralement « régions en direct ») permettent d’informer en temps réel de mises à jour de contenus survenant dans la page. Mais, mal comprises ou mal utilisées, ces techniques peuvent détériorer l’accessibilité, plutôt que l’améliorer. Faisons le point.
Aujourd’hui, nous partageons avec joie la traduction en français de l’article « Building an accessible autocomplete control » écrit d’Adam Silver et publié le 2 février 2020. Nous remercions l’auteur pour son aimable autorisation.
L’une des problématiques les plus complexes lorsqu’on développe des dispositifs JavaScript concerne la reprise de focus, c’est-à-dire le parcours de l’utilisateur avant, pendant et après le déclenchement d’une fonctionnalité. Cet article a pour objectif d’expliquer les principes à appliquer, illustrés par quelques cas concrets.
Retraçons un peu l’histoire Au milieu des années 2000, on se demandait lequel de HTML 4.01 ou XHTML 1.x était le meilleur standard. Les deux langages avaient pour point commun leur absence totale de gestion des composants riches. Ceux-ci étaient de plus en plus convoités par les développeur·ses partout dans le monde. Malheureusement, les processus […]
Lorsque l’on a besoin de réduire des portions de contenus dans une page, notamment pour diminuer la charge informationnelle de contenus annexes, la solution la plus courante est d’utiliser une zone que l’utilisateur peut afficher ou masquer à volonté. Nous détaillons dans cet article trois méthodes pour gérer ce système de zones affichées/masquées de manière...
AOM est une nouvelle API en cours d’écriture. Son objectif est de fournir les moyens aux développeurs (propriétés et événements JavaScript) d’agir sur l’accessibility tree, notamment pour répondre aux besoins d’accessibilité des composants personnalisés.
Dans cette troisième partie, nous aborderons les particularités de l’utilisation des propriétés aria-labelledby, aria-describedby, et ses conséquences sur l’accessible name, ainsi que l’utilisation du rôle application. Avant de poursuivre votre lecture, ne manquez pas le début de cette série : Kit de survie ARIA, 1 sur 3 et Kit de survie ARIA, 2 sur 3.
La documentation « Notes on Using ARIA in HTML » devrait être entre les mains de tout développeur soucieux d’implémenter ARIA. Illustrée d’exemples, elle permet de comprendre les bases fondamentales d’une utilisation raisonnée de l’API. Cet article en trois parties détaille les cinq règles de base et l’utilisation spécifique de certaines propriétés ARIA en s’appuyant notamment sur...
La documentation « Notes on Using ARIA in HTML » devrait être entre les mains de tout développeur soucieux d’implémenter ARIA. Illustrée d’exemples, elle permet de comprendre les bases fondamentales d’une utilisation raisonnée de l’API. Cet article en trois parties détaille les cinq règles de base et l’utilisation spécifique de certaines propriétés en s’appuyant notamment sur leurs...
