Pourquoi la conformité à la Section 508 n'est en fait qu'une meilleure ingénierie
La plupart des équipes considèrent la Section 508 comme un obstacle juridique de dernière minute, mais la mise en place d'une politique d'accessibilité vous oblige à écrire un code plus propre et une meilleure expérience utilisateur pour tous.
J'ai passé beaucoup de temps à regarder des arbres DOM qui donnent l'impression que quelqu'un a jeté une poignée de
Mais nous voyons les choses différemment.
Si votre site n'est pas conforme à la norme 508, il est pratiquement défectueux. Vous ne proposeriez pas un site sur lequel le bouton « Soumettre » ne fonctionne pas pour les utilisateurs de Chrome, n'est-ce pas ? Alors pourquoi peut-on envoyer un site qui ne fonctionne pas pour une personne utilisant un clavier ou un écran braille ? La section 508 n'est pas une couche supplémentaire de fonctionnalités qu'il est agréable d'avoir. Il s'agit de la référence pour les logiciels fonctionnels. Chez Sweent LLC, nous avons développé de nombreux systèmes destinés aux entreprises, qu'il s'agisse d'outils de mise à jour de dispositifs médicaux pour Kaiser Permanente ou de sites marketing pour Deloitte, et la leçon est toujours la même : un code accessible est un meilleur code.
De quoi parle-t-on réellement ?
L'article 508 fait partie de la loi de 1973 sur la réhabilitation. Il indique que les agences fédérales doivent rendre leurs technologies électroniques et informatiques accessibles aux personnes handicapées. Dans le monde du Web, cela implique généralement de suivre les directives pour l'accessibilité des contenus Web (WCAG).
Pour une entreprise comme la nôtre, c'est notre pain et notre beurre. Nous sommes une petite entreprise appartenant à des anciens combattants handicapés (SDVOSB) et nous détenons un contrat GSA MAS (47QRAA25D0024). Lorsque nous construisons pour le gouvernement, la conformité à la norme 508 n'est pas une suggestion. C'est la loi. Mais même si vous n'êtes pas à la recherche de contrats fédéraux, les principes qui sous-tendent 508 améliorent votre logiciel pour tous.
Pensez-y. Avez-vous déjà essayé d'utiliser votre téléphone en plein soleil et vous ne pouviez pas voir le texte à faible contraste ? C'est un problème d'accessibilité. Avez-vous déjà subi une blessure temporaire et dû naviguer sur un site d'une seule main ? Problème d'accessibilité. Un meilleur contraste et des raccourcis clavier sont utiles à tout le monde, et pas seulement aux personnes présentant un handicap permanent. Il s'agit de la version numérique d'une bordure coupée sur un trottoir. Il a été conçu pour les fauteuils roulants, mais il facilite également la vie des personnes avec des poussettes, des planches à roulettes et des bagages lourds.
La colline HTML sémantique sur laquelle je vais mourir
L'une des plus grandes faveurs que vous puissiez faire à votre futur moi est d'utiliser le HTML sémantique. C'est le moyen le plus simple d'atteindre 70 % du chemin vers la conformité sans même essayer. C'est ce que nous voyons tout le temps : un développeur souhaite qu'un bouton ait une certaine apparence. Il lui donne donc le style «
``html
```Pour un utilisateur voyant avec une souris, cela ressemble à un bouton. Mais un lecteur d'écran voit un conteneur générique. Il ne sait pas que c'est interactif. Il n'apparaîtra pas dans une liste de boutons. Vous devrez ajouter manuellement tabindex="0", role="button", et gérer les événements clés « Entrée » et « Espace » juste pour que cela se comporte comme... un bouton.
Ou, vous pouvez simplement utiliser la balise ``.
``html
Soumettre
Le navigateur sait déjà comment manipuler un bouton. Il est accessible au clavier par défaut. Il intègre les bons rôles. C'est ce que je veux dire quand je dis que la conformité à la norme 508 n'est qu'une bonne ingénierie. Vous utilisez les outils comme ils ont été conçus pour être utilisés. Lorsque nous soutenions l'équipe marketing d'entreprise de Deloitte, traduire les designs haute fidélité de Figma en code impliquait de nous assurer que chaque « bouton » était en fait un bouton, et non une section stylisée qui échouerait à un audit.
Et cela va plus loin que de simples boutons. L'utilisation de <nav>`` pour vos menus, de <main>`` pour votre contenu principal et de `<header>` pour votre image de marque donne au navigateur une carte. Lorsque vous les utilisez correctement, vous n'aidez pas simplement les lecteurs d'écran ; vous facilitez la lecture de votre code pour les autres développeurs. Je peux regarder un fichier HTML bien structuré et savoir exactement ce qui se passe sans jamais ouvrir de navigateur. Cela permet d'économiser du temps et de l'argent lors de la maintenance.
## Le test sans souris
Voici une expérience rapide. Accédez à votre projet en cours, placez votre souris sur le sol et essayez de terminer un flux utilisateur principal en utilisant uniquement vos touches « Tab » et « Entrée ».
Pouvez-vous voir où se concentre l'attention ? Si vous avez caché la bague de mise au point parce que votre designer la trouvait « moche », vous avez déjà échoué. Si le focus passe de l'en-tête au pied de page, puis revient à une barre latérale, votre ordre DOM est perturbé.
Nous l'avons rencontré alors que nous travaillions sur un projet pour Kaiser Permanente. Nous étions en train de créer un outil pour gérer l'application de correctifs à des milliers d'appareils médicaux à l'aide d'IBM BigFix. Dans un environnement de soins de santé, vous ne pouvez pas vous permettre d'avoir une interface utilisateur confuse ou difficile à naviguer. Si un technicien est pressé et ne trouve pas le bouton « Confirmer » parce que l'état de mise au point est invisible, c'est un réel problème. Nous avons passé beaucoup de temps à nous assurer que chaque action pouvait être déclenchée via le clavier avec des indicateurs de mise au point clairs et à contraste élevé. Il ne s'agissait pas seulement de conformité ; c'était aussi une question de sécurité.
Mais la gestion de la concentration devient délicate dans les applications React modernes. Lorsque vous modifiez des « pages » dans une application à page unique (SPA), le navigateur ne se recharge pas réellement. Pour un utilisateur de lecteur d'écran, rien ne s'est passé. Ils sont toujours assis sur le lien sur lequel ils viennent de cliquer, mais le contenu qui les entoure a changé. Vous devez déplacer manuellement le focus sur le nouveau contenu ou utiliser une région `aria-live` pour annoncer le changement de page. Si vous ne le faites pas, votre application « moderne » n'est qu'une brique pour un utilisateur aveugle.
## ARIA n'est pas une baguette magique
Les attributs ARIA (Accessible Rich Internet Applications) sont puissants, mais ils sont souvent mal utilisés. La première règle d'ARIA est la suivante : si vous pouvez utiliser un élément HTML natif à la place, faites-le.
J'ai vu des développeurs saupoudrer « aria-label » et « aria-live » sur tout, comme s'ils assaisonnaient un steak. Cela finit par créer une expérience bruyante et confuse pour les utilisateurs de lecteurs d'écran. ARIA doit être utilisé pour combler les lacunes que le HTML natif ne peut pas gérer, comme les panneaux d'onglets complexes ou les mises à jour de statut en temps réel dans un tableau de bord.
Si vous créez une visualisation de données personnalisée, ce que nous avons beaucoup fait pour les suites d'analyse des réseaux sociaux, vous pourriez avoir besoin d'ARIA pour expliquer ce qui se passe dans un graphique. Mais pour un formulaire standard ? Faites en sorte que ce soit simple. Les étiquettes et les entrées sont vos amis.
Et pour l'amour de tout ce qui est sacré, veuillez utiliser <label>correctement la balise ``. Ne vous contentez pas de placer du texte à côté d'une entrée. Utilisez l'attribut for pour les lier. Il donne à l'utilisateur une cible de clics plus grande et indique au lecteur d'écran exactement à quoi sert cette saisie. C'est un petit détail qui fait toute la différence dans le niveau de professionnalisme de votre site.
## Le mythe du site accessible « laid »
Il existe cette idée étrange selon laquelle un site accessible doit ressembler à un document en texte brut datant de 1994. Ce n'est tout simplement pas vrai. Vous pouvez avoir une belle interface utilisateur qui est également entièrement conforme. Cela demande juste une certaine intentionnalité.
Cela implique de choisir des palettes de couleurs qui respectent le rapport de contraste de 4,5 : 1 pour un texte normal. Cela signifie ne pas utiliser la couleur comme seul moyen de transmettre des informations. Si un message d'erreur n'est qu'une bordure rouge autour d'une case, un utilisateur daltonien risque de le manquer. Ajoutez une icône ou une étiquette de texte telle que « Erreur : » pour le rendre plus clair.
Notre équipe de conception, dirigée par Rita Gonzalez, se concentre sur ce point dès le premier jour. Lorsque nous sommes dans Figma, nous vérifions le contraste et la taille des polices avant d'écrire une seule ligne de code. Il est beaucoup moins coûteux de corriger un défaut de conception dans une maquette que de refactoriser un composant React trois semaines avant son lancement. Notre travail avec l'université de Caroline du Sud et la NMSU a porté ses fruits : les designs épurés et accessibles semblent en fait plus professionnels et plus fiables. Un bon design est un design inclusif.
## Outils que nous utilisons réellement
Les tests automatisés, c'est bien, mais ce n'est qu'un début. Des outils tels que WAVE, Axe et Lighthouse sont parfaits pour détecter les problèmes les plus faciles : texte alternatif manquant, mauvais contraste ou identifiants dupliqués. Nous les intégrons dans nos pipelines CI/CD à l'aide de GitHub Actions afin de détecter les régressions à un stade précoce. Nous utilisons même jest-axe pour effectuer des contrôles d'accessibilité lors de nos tests unitaires.
Mais les outils automatisés ne détectent qu'environ 30 % à 40 % des problèmes d'accessibilité. Ils peuvent vous dire si une image contient un texte alternatif, mais ils ne peuvent pas vous dire si ce texte est réellement utile.
``html
<!-- Bad: Not helpful -->
<img src="chart.png" alt="image">
<!-- Good: Descriptive -->
<img src="chart.png" alt="Bar chart showing a 20% increase in social media engagement over Q3.">
C'est pourquoi les tests manuels ne sont pas négociables. Nous utilisons des lecteurs d'écran tels que NVDA sur Windows et VoiceOver sur Mac. Nous effectuons également des tests « sans souris » et des tests de zoom. Avez-vous déjà essayé d'utiliser votre site avec un zoom de 400 % ? Les WCAG 2.1 exigent que votre site reste fonctionnel sans défilement horizontal à ce niveau. Cela vous oblige à écrire un CSS plus réactif. Ce n'est pas seulement pour les personnes malvoyantes ; c'est pour tous ceux qui utilisent un petit appareil ou une taille de fenêtre de navigateur étrange. Si votre site tombe en panne avec un zoom de 400 %, votre logique de mise en page est probablement trop fragile de toute façon.
L'analyse de rentabilisation (au-delà de la loi)
Si les arguments moraux et juridiques ne vous convainquent pas, parlons d'argent. Lorsque vous créez un site accessible, vous élargissez votre marché. Rien qu'aux États-Unis, des millions de personnes souffrent d'une forme ou d'une autre de handicap. Si votre site est inutilisable pour eux, vous refusez littéralement des clients. Pourquoi voudriez-vous réduire votre audience potentielle ?
Les moteurs de recherche aiment aussi les sites accessibles. Les robots d'exploration de Google agissent un peu comme des lecteurs d'écran. Ils recherchent des en-têtes, du texte alternatif et une structure sémantique pour comprendre le sujet de votre page. Si vous avez optimisé la conformité à la norme 508, vous avez essentiellement effectué un énorme travail de référencement gratuitement. Vous obtenez un meilleur classement parce que vous avez créé un meilleur site.
Et puis il y a l'aspect maintenance. Un code sémantique bien structuré est plus facile à lire et à déboguer. Lorsqu'un nouveau développeur rejoint l'équipe et voit un <nav>, un
et un `, il comprend immédiatement la mise en page. S'ils voient « div-1 », « div-2 » et « div-3 », ils doivent passer une heure à déterminer où se termine la navigation et où commence le contenu. L'accessibilité est une forme de documentation qui n'est jamais obsolète.
Pourquoi nous nous soucions de Sweent
Nous sommes allés dans les tranchées avec ce genre de choses. Qu'il s'agisse d'intégrer Adobe Analytics pour Deloitte ou de créer des tableaux de bord complexes pour la NMSU, nous avons constaté l'impact de l'accessibilité sur les résultats.
Dans le cadre du projet de modernisation des applications informatiques de la NMSU, nous migrons les anciennes applications Rails vers une pile React et Node.js moderne. L'un de nos principaux objectifs est de remédier à la sécurité et à la conformité. Les anciennes applications ont été créées à une époque où l'accessibilité n'était qu'une question secondaire. En intégrant les normes 508 aux nouveaux composants de React dès le départ, nous veillons à ce que l'université n'ait pas à faire face aux mêmes maux de tête dans cinq ans. Nous réparons la dette technique du passé en construisant un avenir plus inclusif.
C'est une question de fierté à l'égard de l'artisanat. En tant qu'entreprise appartenant à des vétérans, nous n'aimons pas faire des économies. Nous ne voulons pas construire des choses qui ne fonctionnent que pour certaines personnes. Nous voulons créer des solutions qui fonctionnent pour tout le monde. Julian Tejera, notre fondateur, a passé du temps dans le Corps des Marines où le succès de la mission dépend de l'exactitude de chaque détail. Nous appliquons cette même discipline à notre code.
Comment démarrer
Si vous consultez un site obsolète et que vous vous sentez dépassé, n'essayez pas de tout réparer en même temps. Commencez par vos éléments généraux : l'en-tête, le pied de page et la navigation principale. S'ils ne sont pas accessibles, le reste du site n'a même pas d'importance car les utilisateurs ne peuvent pas passer la porte d'entrée.
Ensuite, examinez vos formulaires. Est-ce que quelqu'un peut s'inscrire ? Peuvent-ils acheter quelque chose ? Peuvent-ils vous contacter ? Corrigez d'abord les chemins à valeur élevée.
Est-ce que c'est difficile ? Parfois. Existe-t-il une réponse parfaite pour chaque composant complexe de l'interface utilisateur ? Pas toujours. Mais l'effort en vaut la peine. Quelle est la dernière fois que vous avez essayé de naviguer sur votre propre site à l'aide d'un lecteur d'écran ? Si vous ne l'avez pas fait récemment, essayez-le aujourd'hui. C'est une expérience révélatrice qui changera probablement pour toujours votre façon d'écrire du code. Vous constaterez peut-être que les « bugs » que vous recherchez n'étaient en fait que les symptômes d'une fondation cassée.
Questions fréquemment posées
L'article 508 fait partie de la loi de 1973 sur la réadaptation qui exige que l'électronique et l'informatique fédérales soient accessibles aux personnes handicapées, conformément aux directives des WCAG. Au-delà de la loi, l'accessibilité impose un HTML sémantique plus propre, une meilleure prise en charge du clavier, un meilleur contraste et des mises en page réactives plus résilientes, autant de qualités qui facilitent la maintenance des logiciels, accélèrent l'intégration de nouveaux développeurs et sont plus conviviaux pour les moteurs de recherche. C'est un indicateur de la qualité technique de base.
Atteignez toujours l'élément natif en premier. A gère l'activation du clavier, la mise au point et la sémantique correcte des technologies d'assistance dès le départ. Recréer ces comportements sur un
Des outils automatisés tels que Axe, WAVE, Lighthouse et jest-axe détectent 30 à 40 % des problèmes (texte alternatif, contraste, doublons d'identifiants). Exécutez-les dans CI. Pour le reste, utilisez NVDA sur Windows ou VoiceOver sur macOS, naviguez avec le clavier uniquement et vérifiez le zoom du navigateur à 400 %. Pour les changements d'itinéraire SPA en particulier, déplacez manuellement le focus sur le titre de la nouvelle page ou utilisez une zone aria-live pour annoncer le changement. Sinon, les utilisateurs de lecteurs d'écran n'auront aucun signal indiquant que quelque chose s'est passé.
Les éléments globaux d'abord : en-tête, pied de page et navigation principale. Si un utilisateur ne parvient pas à franchir la porte d'entrée, rien d'autre sur la page n'a d'importance. Ensuite, corrigez les formulaires à forte valeur ajoutée (inscription, paiement, contact) car ce sont les chemins qui convertissent directement. Un code HTML sémantique, adapté à chaque entrée, une bague de mise au point visible et un rapport de contraste de 4, 5:1. vous permettront de faire avancer les choses plus loin que n'importe quel exercice avec Aria-Sprinkling.
Non. Une conception accessible ne limite que trois choses : les rapports de contraste, le fait de ne pas utiliser uniquement la couleur pour transmettre l'état et la prise en charge du clavier et du zoom. Des bibliothèques d'interface utilisateur bien conçues et des systèmes de conception intentionnels, à commencer par Figma avec des contrôles de contraste et de taille de police avant l'écriture du code, produisent des interfaces modernes et soignées qui passent également avec succès les audits. Corriger ces décisions dans la maquette est nettement moins cher que de refactoriser les composants React avant le lancement.