Un guide complet des composants frontaux accessibles

Liens et boutons d'icônes accessibles

Il n'est pas rare d'avoir un lien ou bouton qui n'a visuellement pas de texte mais se compose uniquement d'une icône – une barre de navigation compacte, par exemple, ou des icônes sociales. Mais comment vous assurer que ces types de liens d'icônes sont entièrement accessibles? En fait, ce n’est pas aussi simple que l’on pourrait le penser.

Pour montrer comment nous pouvons faire mieux, Kitty Giraudel a consacré un article « Accessible Icon Links » au numéro. Ils utilisent un lien icône constitué d'un SVG avec l'emblématique oiseau Twitter pour illustrer le point, et montrent pas à pas comment le rendre accessible: avec un texte descriptif visuellement masqué, puis en supprimant le balisage SVG de l'arborescence d'accessibilité avec aria-hidden et, enfin, corriger le fait que les éléments svg peuvent être focalisés sur Internet Explorer en ajoutant l'attribut focusable . À la fin de l'article, Kitty montre également comment transformer tout cela en un petit composant React .

Un petit détail qui fera une énorme différence pour de nombreux utilisateurs.

Dans Création de boutons d'icônes accessibles et Inclusively Hidden Sara Soueidan et Scott O'Hara vont dans toutes les subtilités et détails de l'icône boutons, en explorant un certain nombre de techniques pour le faire fonctionner. Sara et Scott explorent un certain nombre de techniques, suggérant d'utiliser une technique appropriée pour un texte visuellement masqué accessible – le texte qui sera visuellement masqué mais accessible aux lecteurs d'écran. Cela pourrait être fait avec une classe d'utilité .sr-only ou hidden et aria-labelledby ou aria-label seul. Sara ne recommanderait pas d'utiliser l'icône SVG elle-même pour fournir une étiquette pour le bouton lorsque je peux en fournir une directement sur le bouton lui-même.

En général cependant, il y a encore un peu de confusion quant à l'élément à utiliser pour l'utilisateur interaction: quand utilisons-nous des liens et quand utilisons-nous des boutons? Marcy Sutton a écrit un article détaillé sur Liens vs boutons dans les applications modernes . Avec un lien, le visiteur accède à une nouvelle ressource, l'éloignant du contexte actuel. Mais un bouton provoque un changement dans l'interface.

Marcy décrit les cas d'utilisation des liens et des boutons dans les applications d'une seule page, montrant qu'un bouton est un élément parfait pour ouvrir une fenêtre modale, déclencher une fenêtre contextuelle, basculer un interface ou lecture de contenu multimédia. Vous pouvez également consulter l’article de Vadim Makeev sur « Quand un bouton n’est-il pas un bouton? ».

Info-bulles et info-bulles accessibles

Un composant étroitement lié aux boutons d’icône est une info-bulle. Littéralement «trucs pour les outils», ce sont de petits éléments d'information qui expliquent le but d'un contrôle, ou d'un visuel, qui autrement pourraient être mal compris. Chaque fois que nous voulons expliquer pourquoi nous avons besoin d'une information personnelle particulière dans une caisse, c'est là que nous utiliserons probablement une bonne vieille info-bulle. Alors, comment pouvons-nous les corriger?

Les info-bulles inclusives de Heydon Pickering fournissent un aperçu très complet de pratiquement tout ce qui est nécessaire pour créer une info-bulle accessible. Cela signifie décider si le contenu de l'info-bulle doit être fourni en tant qu'étiquette ou description et choisir les propriétés ARIA en conséquence, ne pas se fier aux attributs title et éviter de mettre du contenu interactif tel que fermer et confirmer des boutons ou des liens dans les info-bulles. [19659080] Notes de bas de page et notes de bas de page accessibles

Dans leur essence, les notes de bas de page ne sont pas beaucoup plus que des liens de saut – des liens vers la description d'une source, soit placés au bas du document, soit dans la barre latérale, soit apparaissant en ligne, un petit accordéon . Cependant, comme les notes de bas de page sont des liens de saut, nous devons nous assurer que les utilisateurs de lecteurs d'écran comprennent quand les liens sont des références à des notes de bas de page – et nous pouvons le faire avec l'attribut aria-describedby . Le compteur pour chaque lien serait implémenté via un compteur CSS. Avec : target nous mettons ensuite en surbrillance la ligne à laquelle le lecteur a sauté et nous fournissons un lien retour vers l'emplacement réel de la note de bas de page dans le contenu.

Kitty Giraudel entre dans les détails expliquant comment créer des notes de bas de page accessibles, et vous pouvez également
Vérifiez comment créer des notes de bas de page accessibles avec React et utilisez react-a11y-footnotes pour les construire dans React with Eleventy (merci à Kitty Giraudel pour le conseil!)

SVG accessibles

Parler des SVG: ce que nous pouvons faire avec les SVG aujourd'hui va bien au-delà des formes de base d'antan. Non seulement nous pouvons décrire les icônes SVG, mais aussi les styliser et les animer. Si la véritable inclusion se situe au-delà des modèles – quels autres facteurs devrions-nous prendre en compte lors de la conception et du développement de SVG accessibles?

C'est exactement la question à laquelle Carie Fisher répond dans son article sur SVG accessibles: l'inclusivité au-delà Modèles . Dans l'article, Carie examine de plus près la couleur et le contraste SVG, les modes clair et sombre, l'animation SVG, la réduction des mouvements et de nombreux outils axés sur l'accessibilité. Vous trouverez également des démos et des exemples de code dans les articles, ainsi que des explications détaillées et des pointeurs pour une lecture plus approfondie.

Et si vous souhaitez approfondir le sujet monde complexe de composants accessibles – non seulement liés aux SVG – nous avons juste publié l'article de Carie sur modèles de code accessibles .

Better : focus Styles [19659005] Chaque navigateur a des styles de focus par défaut, mais prêts à l'emploi, ils ne sont pas très accessibles . Le but de : focus est de donner à l'utilisateur des indications sur l'endroit exact où il se trouve dans le document et l'aider à s'y retrouver. Pour y parvenir, nous devons éviter une focalisation trop subtile ou pas du tout visible. En fait, supprimer le contour est une mauvaise idée car cela supprime toute indication visible de mise au point pour les utilisateurs de clavier. Plus la mise au point est évidente, mieux c'est.

Il existe des moyens de mieux concevoir : focus styles. Dans son article Conseils pour les styles de mise au point Nic Chan met en évidence quelques conseils utiles sur la façon d'améliorer les styles de mise au point avec une meilleure accessibilité et un peu de remplissage, de décalage et de contours appropriés. Besoin de plus de plaisir avec les styles : focus ? Lari Maza vous soutient également .

Nous pouvons également utiliser : focus-within pour styliser l'élément parent d'un élément focalisé et : mise au point visible à ne pas afficher les styles de mise au point lors de l'interaction avec une souris / un pointeur si cela pose des problèmes dans votre conception.

Il est important de considérer les problèmes d'accessibilité vers : mise au point visible : comme Hidde de Vries l'a noté ce ne sont pas toutes les personnes qui se fient aux styles de mise au point qui utilisent un clavier et la création de styles de mise au point au clavier ne leur enlève pas les moyens. les utilisateurs de souris aussi, car le focus indique également que quelque chose est interactif (merci à Jason Webb pour le conseil!) .

Enfin, il convient de noter que plus récemment, Chrome, Edge et d'autres navigateurs basés sur Chromium a cessé d'afficher un indicateur de mise au point ( bague de mise au point ) lorsque l'utilisateur clique ou appuie sur un bouton n (merci à Kim Johannesen pour l'astuce!) .

Styles de formulaires multi-navigateurs accessibles

Avez-vous déjà eu du mal à cacher et à styliser des cases à cocher et des boutons radio personnalisés? Qu'en est-il des styles de sélection personnalisés? Ou peut-être un menu de navigation déroulant accessible? Nous avons tendance à construire et à reconstruire les mêmes composants tout le temps, alors faisons-les bien une fois pour toutes.

Sarah Higley's « your poison » est une plongée complète en deux parties dans tous les défis et les subtilités du style de l'élément avec des variantes modifiables et à sélection multiple, leur utilisabilité comparative (avec des données!) Et des recommandations pratiques sur la façon de l'obtenir

Stephanie Eckles Modern CSS Solutions for Old CSS Problems met en évidence de nombreuses techniques modernes utiles pour résoudre de nombreux défis, mais certains articles de sa série sont dédiés aux formulaires: Cases à cocher CSS personnalisées des boutons radio stylisés, sélectionnez des styles, des entrées et des zones de texte.

De plus, Stephanie montre comment créer une liste déroulante accessible (presque) CSS uniquement et sur son blog, Sara Soueidan va expliquant en détail comment se cacher et se cacher inclusivement les cases à cocher et boutons radio . Bonus: les exemples de code d'Adrian Roselli fournissent des informations supplémentaires sur les bascules mal conçues. Des ressources fantastiques à utiliser tout de suite et styliser les formulaires de manière accessible.

Cases à cocher et boutons radio accessibles

Le bon vieux problème: comment styliser les cases à cocher et les boutons radio pour s’assurer qu’ils sont, au moins similaires, en la plupart des navigateurs – tout en s'assurant qu'ils restent également accessibles? Dans son article Sara Soueidan couvre quelques techniques à garder à l'esprit pour obtenir le résultat souhaité.

Sara couvre les différentes techniques de masquage des éléments, comment chacune d'elles affecte l'accessibilité du contenu, et comment les masquer visuellement, afin qu'ils puissent être remplacés par une alternative plus stylée: le SVG.

Lors du masquage d'un élément interactif, nous devons nous assurer que nous choisissons une technique de masquage qui le rend accessible au lecteur d'écran, le positionnons au-dessus de tout ce qui le remplace visuellement, afin qu'un utilisateur naviguant au toucher puisse le trouver là où il attendez-vous à, puis rendez-le transparent. Sara fournit également des démos en direct que nous pouvons utiliser tout de suite, ainsi que des références utiles à des articles pour une lecture plus approfondie.

Carrousels accessibles et curseurs de contenu

Un carrousel accessible sonne un peu comme oxymore – bien qu'il existe de nombreux scripts qui fournissent la fonctionnalité, seuls quelques-uns d'entre eux sont accessibles. Maintenant, il y a, bien sûr, curseurs de plage accessibles mais les carrousels sont un composant légèrement différent. Comme le remarque Alison Walden dans son article sur «Si vous devez utiliser un carrousel, rendez-le accessible» la personne voyante n'est pas du tout obligée d'utiliser le carrousel, mais les utilisateurs de clavier sont obligés de naviguer dans le carrousel dans son intégralité. À tout le moins, un lien «sauter» masqué pourrait apparaître sur le focus du clavier. De plus, une fois que la personne a parcouru tous les ensembles de panneaux, le focus doit passer à l'élément interactif suivant qui suit le carrousel.

Grand aperçu )

Heydon Pickering suggère à d'utiliser le balisage de liste pour le groupe les diapositives ensemble, incluent les boutons précédent et suivant, les points d'accrochage et utilisent des éléments liés invisibles supprimés du focus. L'article fournit également un exemple de code qui utilise IntersectionObserver, vous pourriez donc avoir besoin d'un polyfill pour cela.

Est-ce toujours une bonne idée de concevoir des méga-listes déroulantes s'ouvrant sur flotter? Probablement pas . Les menus survolés présentent de nombreux problèmes d'utilisabilité et d'accessibilité, car ils sont incohérents, déroutants et nécessitent bien sûr une solution alternative pour les appareils mobiles. En fait, Mark Root-Wiley suggère qu'il est temps de supprimer les menus de survol au profit de menus cliquables sans ambiguïté et accessibles .

Dans son article, Mark entre dans les moindres détails sur la façon de créer un menu contextuel accessible, ainsi que des pointeurs et des références utiles issus de ses recherches. L'idée est de commencer à construire le menu comme un menu de survol CSS uniquement qui utilise li: hover> ul et li: focus-within> ul pour afficher les sous-menus. Ensuite, nous utilisons JavaScript pour créer les éléments définir les attributs aria et ajouter les gestionnaires d'événements. Le résultat final est disponible en tant qu'exemple de code sur CodePen et en tant que référentiel GitHub . Cela devrait également être un bon point de départ pour votre menu.

Liens «Ignorer» accessibles

Surtout sur les pages avec une grande quantité de navigation, se déplacer entre les sections ou autour de la page peut être frustrant et ennuyeux. C’est là que les liens «Ignorer» peuvent être très utiles. Malheureusement, il n'est pas rare de voir des liens «Ignorer» implémentés mais cachés avec l'affichage : aucun et en tant que tel, indisponible à quiconque (y compris les utilisateurs de lecteurs d'écran et les utilisateurs de clavier).

Dans Comment créer un lien «Ignorer le contenu» Paul Ryan propose un didacticiel pas à pas sur la façon d'implémenter un lien de saut de contenu accessible. Fondamentalement, nous utilisons la transformation CSS pour pousser le lien de saut hors de l'écran, mais le ramener à l'écran sur : focus . Dans les commentaires de l'article, Eric Bailey a également remarqué que nous pouvions fournir des liens de saut avant les sections de contenu qui contiennent de nombreux éléments interactifs, ou des éléments qui peuvent être difficiles à parcourir (comme la table des matières et iframe s).

Tableaux accessibles

Il existe de nombreux problèmes d'accessibilité liés aux tableaux, mais le plus grand défi est de transformer une représentation visuelle en une série linéaire qui sera lue à voix haute par un lecteur d'écran, sans omettre toute information importante. Heureusement, Adrian Roselli a passé beaucoup de temps à explorer les défis et les solutions des tables accessibles.

Dans son article sur accessible tables Adrian suggère d'encapsuler le tableau dans un

avec role = "region" aria-labelledby et tabindex = "0" pour s'assurer qu'un utilisateur à clavier seul peut accéder au conteneur, que le tableau reçoit le focus et

dans le tableau pour s'assurer qu'il est correctement annoncé aux lecteurs d'écran. Adrian also provides a code example for a responsive table, as well as tables with expandable rowssortable table and fixed table headers.

How Screen Readers Navigate Data Tables

Have you ever tried to navigate a table with a screen reader? If not, you should check out Leonie Watson’s article on how screen readers navigate data tables. It shares precious insights and shows what matters to create frustration-free tables that can be used by anyone.

In the post, Leonie uses NVDA to move to a table, navigate its content, and find specific information. The appropriate HTML elements (or ARIA roles) inform her about the characteristics of the table and give her access to keyboard commands specifically for navigating the table’s content.

An interesting takeaway: Keyboard focus and screen reader focus are not the same thing. Contrary to what you might have heard, you do not need to make each cell of a table focusable with a keyboard to aid navigation. If the content inside the cell is non-interactive, you’ll likely make keyboard users work much harder to navigate the table than you intended. You can also watch a Smashing TV video with Léonie on How A Screen Reader User Accesses The Web (73 mins).

Website Features That Annoy Screen Reader Users

A missing alt caption, an auto-playing video, unlabelled buttons, poor use of headings, inaccessible web forms — what might seem like a small issue for sighted users can make the difference between being able to use a website independently or not for blind and visually impaired people. Holly Tuke knows this from her own experience.

To raise awareness for common accessibility issues, Holly summarized five annoying website features she faces as a screen reader user every single day, and, of course, how to fix them. Chris Ashton also published a piece explaining common issues that screen reader users havewhich are often neglected in conversations focus on semantics and keyboard-accessibility alone. Little details that make a huge difference (thanks to Alex Chudesnov for the tip!).

Accessible Video/Audio Players

It’s not uncommon to see viewers frequently using captions when watching a short clip or a lengthy movie these days. We might be consuming the video in a noisy environment, or perhaps we can better understand written language, or perhaps we are currently busy with something else and need to look up something quickly without having to resort to headphones. Beyond that, how often do we use keyboard’s to prompt a pause, or key arrows to move back and forward? Still, many video players and custom solutions don’t provide this functionality out of the box.

Accessible HTML5 Media Players provides an overview of accessible audio and video players. There are plenty of great open-source options, e.g. AblePlayer seems to be one of the reliable ones. It includes a full set of player controls that are keyboard-accessible, properly labelled for screen reader usersand controllable by speech recognition users, features high contrast, supports closed captions and subtitles, chapters, text-based audio description, an interactive transcript feature and automatic text highlighting. It supports YouTube and Vimeo videos. Hower, it depends on jQuery.

Alternatively, you could look into Vime.js as well: fully open-source, lightweight, fully customizable and without third-party dependencies. Other great options like Plyr and Accessible HTML5 Video Player by PayPal are similar. The latter is fully accessible to keyboard-only users and screen reader users, written in vanilla JavaScript, is additionally provided as a React componentand falls back to browser’s native controls if JavaScript is unavailable (thanks for the tip, @jamsandwich!).

Accessible Cookie Consent Prompts

Overlays and pop-ups are always problematic. But especially for screen reader users, sometimes those prompts are incredibly difficult to deal with to set any settings or even confirm the usage of cookies on the site. In her 15-mins talk on “Screen readers and cookie consents”, Leonie Watson goes into detail explaining the poor experiences that compliance pop-ups have for accessibility. In some cases, users glide past consent prompts without being aware of them, in the others, the prompt are impossible to accept, resulting in an inability to use the site at all.

So how can we make them better? In Cookie banners and accessibilitySheri Byrne-Haber highlights common issues that cookie prompts usually have: from how they visually appear to focus traps, the appearance in the tab order, the type of acceptance and alternate formats of consent disclosure. Quentin Bellanger provides a basic code example of a cookie consent modal and a tutorial along with it. There are also free open-source solutions: Osano Cookie Consent and cookie-consent-boxbut they might require some accessibility work.

Accessible Close Buttons

“Close” buttons are everywhere — in modals, ads, confirmation messages, cookie prompts and any overlays that will appear in your interface. Unfortunately, the functionality is often limited to mouse users, leaving screen reader users and keyboard-users out. We can fix it.

In “Accessible Close Buttons” Manuel Matuzovic goes into deep details highlighting 11 examples and patterns of inaccessible close buttons as well as 5 examples of close buttons that work fairly well. The easiest way to solve the problem is to provide a button with visible text and only visually accessible icon and ensure that the description by screen readers isn’t polluted by the icon’s description. Manuel also provides code examples of 5 close buttons that you can apply to your work right away.

Accessible Inputs

In 2019, WebAIM analyzed the accessibility of the top one million websites, with a shocking conclusion: the percentage of error-free pages was estimated to be under one percent. To make our sites inclusive and usable for people who rely on assistive technology, we need to get the basics of semantic HTML right. With its credo of starting small, sharing, and working together, Oscar Braunert’s article on inclusive inputs is a great starting point to do so.

Starting off with the basics of WAI, ARIA, and WCAG, the article explores how to make inputs more accessible. The tips can be implemented without changing the user interface, and, as Oscar puts it: “If in doubt, just do it. Nobody will notice. Except some of your users. And they will thank you for it.”

Support User Preferences With prefers-reduced-*

Not every user is the same, and while some users love animations, others may have medical issues concerning motion. The prefers-reduced-motion media query lets you toggle animations on and off, but there are even more solutions to manage animations depending on a user’s preference. In his blog postElijah Manor addresses different techniques such as @media, matchMedia, and a custom React hook to address CSS, SVG SMIL, and JavaScript animations.

When it comes to making your content accessible to everyone, there’s another prefers-reduced-* media query that is worth knowing about — even though it isn’t supported by browsers yet (but you can emulate it in Polypane and Chromium browsers): prefers-reduced-data. It indicates when a user wants to use as little data as possible — if their connection is slow, for example, or if data is limited. The Polypane team summarized what you need to know about the media query to future-proof your site already today.

A Complete Guide To Dark Mode On The Web

Dark mode is quickly becoming a user preference with Apple, Windows, and Google having it implemented into their operating systems. But what about dark mode on the web? Adhuham wrote a comprehensive guide to dark mode that delves into different options and approaches to implementing a dark mode design on the web.

To start off, the guide looks at the technical considerations that implementing a dark mode entails, covering different approaches to toggling the themes and how to store a user’s preferences so that they will be applied consistently throughout the site and on subsequent visits. Tips for handling user agent styles with the color-scheme meta tag help avoid potential FOIT situations.

Design considerations are also tackled, of course, with valuable tips to get images, shadows, typography, icons, and colors ready for dark mode. While on it: to ensure we don’t unintentionally break the high contrast in mode, take a look at Styling for Windows High Contrast mode (thanks for the tip, Courtney Heitman!).

Accessible App-Wide Keyboard Navigation

A well-thought-out concept for keyboard navigation benefits everyone: It enables people who can’t comfortably use a mouse, assists screen reader users in interacting with an application, and it provides power users with more shortcuts to work as efficiently as possible. Usually, keyboard support is limited to specific shortcuts, but the team at Discord decided to go a step further with their application and expand keyboard support to, well, everything.

The case study “How Discord Implemented App-Wide Keyboard Navigation” shares valuable insights into how they tackled the task — and the challenges they faced along the way, of course. One turned out to be particularly difficult: How to consistently indicate where focus is on the page? As existing solutions for Focus Rings didn’t work out, the team had to build their own solution from scratch and made the code open source. If you’re facing a similar challenge, this one’s for you.

Accessible Comics

When we use slightly more complex shapes and layouts on the web, sometimes it appears to be so much easier to just save it as a foreground or background image and serve different images to small and large screens. This holds true for complicated charts and graphs as well as good old comics with speaking bubbles, but what if we could re-imagine the experience altogether?

Comica11y is an experiment by Paul Spencer that aims to achieve an all-inclusive online comic reading experience. What if we could have different reading modes for the comic, e.g. with closed captions, proper focus management to navigate between panels, high-contrast mode, SVG color blindness filters, programatic bubbles, selectable and translatable text, LTR and RTL support, and even adjustable font sizes? A wonderful initiative that shows just how far we can take UI challenges and use the web to enhance the experience greatly.

Inaccessible Disabled Buttons

It has become quite common for lengthy web forms to keep the “Continue” button disabled until the customer has provided all data correctly. This behavior acts as an indicator that something is wrong with the form, and it can’t be completed without reviewing the input. This works if the inline validation for every input field is working well, and it doesn’t work at all when it’s glitchy or buggy.

In “Disabled Buttons Suck”, Hampus Sethfors highlights the downsides of disabled buttons. With them in place, we do communicate that something is wrong, but we don’t really explain what is wrong, or how to fix it. So if the customer has overlooked an error message — be it in a lengthy form on desktop, or even in a short form on mobile, they’ll be lost. In many ways, keeping buttons active and communicating errors is more efficient.

And if it’s not possible, at least provide a way out with a button “I can’t complete the form, please help”, so customer support can get back to customers in case they get into trouble. If you need a more detailed refresher on web forms, “Form Design From One to Zero” will keep you busy.

But First, Accessibility Support

There are many different ways that assistive technologies interact with browsers and code. Since it’s still not possible to fully automate screen readers and voice control softwares, we are left with having to do manual tests. And that’s where a11ysupport.io comes into play.

Originally created by Michael Fairchild, this community-driven website aims to help inform developers about what is accessibility supported. It’s a project that is active and contributions are always welcome, so start testing away. Also, it’s always worth checking the WAI-ARIA authoring practices which describe essential semantics, roles, and ARIA necessary for common components and patterns (thanks to Stephanie Eckles for the tip!).

Accessibility Resources And Checklists

Accessibility is incredibly important, but, unfortunately, often overlooked. The community-driven A11Y Project attempts to make digital accessibility easier, providing designers and developers with the know-how they need to build beautiful, accessible, and inclusive experiences.

From the basic principles behind accessible design to conducting an accessibility audit, and cultivating community, The A11Y Project takes a 360 degree look at the topic. You’ll find articles just like quick tips, tips on books to read, newsletters to follow, as well as handy tools, groups committed to accessibility, and much more.

Repository Of Accessibility Tools

Do you ever get that itching feeling of forgetting something before shipping a project? Well, checklists are known to be the key to keeping an overview of things that need to be done and taken care of before the final showdown. When it comes to accessibility, there’s a growing list of tools and resources that are bound to help you keep an eye on things: A11y Resources.

Curated by Hannah Milanthis list was initially created to keep track of more than 200+ hand-curated accessibility plugins, tools, articles, case studies, design patterns, design resources, accessibility standards, and even checklists. Of course, you can always submit a tool if you see anything missing.

Wrapping Up

We probably have missed some important and valuable techniques and resources! So please leave a comment and refer to them — we’d love to update this post and keep it up-to-date for us all to be able to get back to it and build reliable, accessible components faster.

We sincerely hope that these tools and techniques will prove to be useful in your day-to-day work — and most importantly help you avoid some time-consuming, routine tasks.

Stay accessible!

Thank you! ❤️

A huge thanks to @jamsandwichCourtney HeitmanStephanie EcklesAdam SilverDaniela KubeschTanisha SabherwalManuel MatuzovićVadim MakeevKitty GiraudelIan JamesJuha LehtonenShivani GuptaSara SoueidanJason WebbAlex KallinikosSasha ChudesnovAdam LiptrotHolger BartelKim Johannesen and everybody else who has been passionately working all around accessibility for the contributions to this article. Community matters.

More On Accessibility

(il)

Le meilleur outil 2023 pour ta croissance Instagram !