Civic tech et prestations numériques — comment les portails d’allocations chômage échouent les demandeurs handicapés

Les portails d’assurance chômage des États, les sites de demande de SNAP, les outils d’éligibilité Medicaid et la propre interface de la SSA pour le SSDI constituent les services essentiels accessibles au public du filet de sécurité sociale américain. Ce sont aussi certaines des surfaces web publiques les plus mauvaises en matière d’accessibilité. Nous avons audité les principaux portails de prestations opérés par les dix États américains les plus peuplés — Californie, Texas, Floride, New York, Pennsylvanie, Illinois, Ohio, Géorgie, Caroline du Nord et Michigan — ainsi que la couche d’authentification fédérale (Login.gov) et les systèmes accessibles aux demandeurs sur SSA.gov, par rapport au WCAG 2.1 Niveau AA et à la règle finale DOJ Titre II du 24 avril 2024 qui lie légalement les gouvernements étatiques et locaux au même standard. Sur les douze surfaces auditées, nous avons enregistré environ 217 défaillances distinctes WCAG 2.1 AA, soit en moyenne environ 18 par portail, avec un seul des douze ayant satisfait à nos quatre critères de passage. Ce dossier nomme les portails, les classe et conclut sur ce que la règle DOJ signifie pour les moins bien classés.

01. Méthodologie et critères de passage

L’audit s’est déroulé du 7 mars au 12 mai 2026. Deux auditeurs ont parcouru le parcours canonique du demandeur sur chacun des douze portails depuis une session froide — sans cookies préalables, sans extensions d’aide installées, sans saisie automatique. Le parcours était : arriver à la page d’accueil, créer un nouveau compte, s’authentifier, déposer une demande initiale d’allocations chômage (ou, pour les surfaces SSA et SNAP-Medicaid, le flux de première demande équivalent), atteindre le point de soumission, puis certifier une semaine ultérieure ou téléverser un document justificatif.

Chaque surface a été évaluée par rapport aux critères de succès WCAG 2.1 Niveau AA en utilisant axe-DevTools Pro 4.10 et un parcours manuel avec NVDA 2024.4 sur Windows 11 et VoiceOver sur macOS 14.7. Les flux mobiles ont été re-testés sur iOS 18.2 avec VoiceOver et sur Android 15 avec TalkBack. Tout PDF servi dans le parcours a été extrait et analysé séparément avec PAC 2024 et le contrôle d’accessibilité d’Acrobat Pro DC.

Nous avons ensuite appliqué quatre critères de « passage » binaires — plus grossiers que l’échelle WCAG complète, mais les critères qui importent réellement à un demandeur handicapé : opérable au clavier (un utilisateur ne se servant que du clavier peut-il atteindre une demande soumise ?), récupération d’erreur par lecteur d’écran (lorsque quelque chose échoue, le lecteur d’écran annonce-t-il quoi et où ?), extension du délai de session (le mécanisme d’avertissement et d’extension est-il accessible et opérable par technologie d’assistance ?), et téléversement de fichier accessible (le succès ou l’échec du téléversement est-il annoncé par programme ?). Une surface réussit l’audit uniquement si elle passe les quatre critères.

02. Le classement portail par portail

Le classement des douze surfaces selon leur score d’accessibilité normalisé — la part des pages du parcours ayant passé axe au WCAG 2.1 AA, pondérée par la satisfaction des quatre critères — a produit le tableau ci-dessous. Login.gov se trouve en tête parce qu’il a été conçu comme une primitive d’authentification privilégiant l’accessibilité dès le départ et que l’équipe re-teste à chaque version. Les surfaces accessibles aux demandeurs sur SSA.gov se trouvent en deuxième position parce que le Bureau des systèmes accessibles et de la technologie de la SSA opère un programme de surveillance continue. À partir de la troisième place, l’écart avec le bas est abrupt.

Login.gov montre la forme d’un portail de prestations accessible. Floride CONNECT montre la forme d’un portail qui ne peut pas être rempli sans aide visuelle.

03. Les pièges CAPTCHA

Le critère CAPTCHA est la surface de défaillance la plus visible parce qu’elle se situe tôt dans le flux — généralement sur le formulaire d’inscription ou de connexion, parfois à nouveau sur la soumission de la demande initiale comme mesure anti-fraude. Huit des douze portails audités servent un reCAPTCHA v2 uniquement image dont le fallback audio est soit défaillant (se charge en silence, aucun fichier audio lisible) soit redirige le demandeur vers une page 404 générique. Deux des huit placent l’intégralité du flux de demande initiale derrière le CAPTCHA : le portail UI de la Texas Workforce Commission et Floride CONNECT. Un demandeur aveugle dans ces deux États, travaillant sans aide visuelle, ne peut pas déposer de demande depuis ces interfaces. Il doit téléphoner à l’État, où la file d’attente s’étend sur plusieurs heures.

L’ironie de la civic tech est que reCAPTCHA v3 — invisible, basé sur le comportement, sans défi pour la grande majorité des utilisateurs — existe, est gratuit aux volumes qu’un portail étatique voit, et résoudrait le problème au coût d’une demi-journée de travail d’intégration. L’inertie dans les marchés publics, et non la difficulté technique, maintient le défi v2 en place.

04. Les délais de session qui ne s’étendent pas

Onze des douze portails audités — chaque surface d’allocations chômage étatique et iClaim de la SSA — imposent un délai de session compris entre 10 et 20 minutes d’inactivité. Le WCAG 2.2.1 (Réglage du délai) exige que toute limite de temps puisse être désactivée, ajustée ou prolongée par l’utilisateur avant son expiration, avec au moins 20 secondes d’avertissement et une simple interaction « prolonger ». Parmi les onze, trois ne donnent aucun avertissement du tout ; la session expire simplement en cours de formulaire et le demandeur est renvoyé à la connexion avec toutes les données saisies perdues.

Cinq autres affichent un modal visuel de compte à rebours mais n’annoncent jamais le modal via aria-live, si bien qu’un utilisateur de lecteur d’écran en train de lire le formulaire en dessous n’a aucune idée que l’avertissement est apparu. Les trois restants annoncent le modal mais trappent le focus de telle façon que le bouton « Prolonger la session » est inaccessible par la touche Tab — appuyer sur Tab dans le formulaire sous-jacent ne déplace pas le focus vers le modal. L’utilisateur sait que l’avertissement est là. L’utilisateur ne peut pas agir dessus.

05. Les formulaires PDF obligatoires au sein d’un parcours HTML

Neuf des dix portails d’allocations chômage étatiques dirigent le demandeur, à un moment ou un autre du parcours, vers un PDF. Les cas les plus fréquents sont le formulaire d’appel, la certification de semaine partielle, le journal de recherche d’emploi et l’attestation d’allocation pour personnes à charge. Parmi les PDF servis, moins de la moitié portent un arbre de structure PDF balisé. Les autres sont des images scannées de formulaires papier — parfois le modèle dactylographié original des années 1990, photocopié et re-photocopié — sans couche de texte du tout.

Un PDF uniquement image servi comme formulaire obligatoire n’est pas un défaut d’accessibilité à la marge. C’est une exclusion catégorielle. Le lecteur d’écran signale un document vide. Les assistants OCR échouent parce que le formulaire comporte des champs que la couche OCR ne peut pas reconstruire. Le demandeur a deux options : imprimer, remplir à la main, scanner, et envoyer par email ; ou téléphoner à l’organisme. Les deux options supposent une imprimante-scanner et une aide visuelle. De nombreux demandeurs handicapés ne disposent ni de l’une ni de l’autre.

06. Les téléversements de fichiers sans retour pour le lecteur d’écran

Dix des douze portails exigent, quelque part dans le parcours, un téléversement de fichier — une notification de séparation, un document d’identité, une certification médicale, un document d’éligibilité SNAP-Medicaid. Le schéma qui fait échouer l’audit, de manière constante, est le suivant : l’élément input de fichier est un input HTML natif enveloppé dans un bouton « Choisir un fichier » au style personnalisé qui absorbe l’événement clavier et n’annonce jamais le nom de fichier sélectionné, n’annonce jamais la progression du téléversement, n’annonce jamais le succès, et (le pire) n’annonce jamais l’échec. L’utilisateur sélectionne un fichier. Quelque chose se passe. Rien n’est annoncé. L’utilisateur avance, sans savoir si le téléversement a réussi — et découvre, trois jours plus tard, que sa demande a été rejetée pour documentation manquante.

La correction la moins coûteuse de tout le dossier se trouve ici. Une seule région en direct visuellement masquée à côté de l’input de fichier, polie, mise à jour à la sélection et à la complétion avec le nom de fichier et un statut en un mot, coûte une heure de travail front-end et résout l’ensemble du schéma de défaillance. Nous l’avons vu correctement implémenté sur exactement une des douze surfaces.

07. Les messages d’erreur sans aria-live

La défaillance la plus fréquente sur les douze surfaces — présente dans environ trois états d’erreur sur quatre que nous avons déclenchés — était une erreur de validation en ligne rendue sous forme de span rouge stylisé à côté d’un champ input, sans région aria-live, sans pointeur aria-describedby de l’input vers le texte d’erreur, et sans déplacement programmatique du focus vers l’erreur. L’erreur est visible. L’erreur n’est pas annoncée. L’utilisateur de lecteur d’écran soumet, la page ne se recharge pas, l’utilisateur ne sait pas pourquoi rien ne se passe, et l’utilisateur soumet à nouveau.

Le schéma s’aggrave avec la défaillance du délai de session : un demandeur handicapé enchaîne des erreurs de validation non annoncées à la vitesse de la re-lecture humaine, atteint le délai de 15 minutes, perd le formulaire, et recommence. La correction est deux lignes par erreur — une région aria-live à proximité de chaque fieldset, polie, dans laquelle la routine de validation écrit lors de son déclenchement. Aucune des surfaces que nous avons auditées ne le fait de manière cohérente.

La partie la plus coûteuse de la correction de ces portails n’est pas l’ingénierie. C’est le contrat de marchés publics qui doit être rouvert.

08. Les implications pour l’application du DOJ Titre II

La règle finale DOJ Titre II du 24 avril 2024 — codifiée au 28 CFR Part 35, Sous-partie H — adopte le WCAG 2.1 Niveau AA comme norme fédérale d’accessibilité pour le contenu web et les applications mobiles des gouvernements étatiques et locaux. Les grandes entités publiques (populations de 50 000 personnes ou plus) avaient une date limite de conformité au 24 avril 2026 ; les entités plus petites ont jusqu’au 24 avril 2027. Chaque État de cet audit dessert une population bien au-dessus du seuil de 50 000. La date limite d’avril 2026 est passée.

La règle prévoit des exceptions — contenu archivé, documents individualisés, contenu non public protégé par mot de passe, contenu tiers non publié par l’entité — mais le parcours canonique de demande d’allocations chômage ne relève d’aucune d’entre elles. Un formulaire de demande initiale sur un portail UI étatique est actuel, accessible au public, fourni par l’entité et utilisé par le public. Il se trouve clairement dans la surface réglementée.

L’application au titre du Titre II passe par les enquêtes initiées par le DOJ (Section des droits des personnes handicapées de la Division des droits civils), les plaintes individuelles déposées sur civilrights.justice.gov, et les litiges privés au titre du même texte. Les remèdes envisagés par la règle comprennent des plans de conformité, des accords de surveillance, des dommages et intérêts compensatoires pour les plaignants identifiés, et — selon le modèle de décret de consentement que le Département utilise depuis l’accord H&R Block de 2014 — des calendriers de correction à l’échelle nationale avec des cibles de conformité WCAG nommées. Pour en savoir plus sur ce qui attire spécifiquement l’attention du DOJ, consultez notre article complémentaire sur la règle DOJ Titre II, deux ans après.

09. Le parcours du demandeur handicapé est l’expérience utilisateur civic tech la plus difficile — et la plus importante à corriger

Le chômage est par définition un moment de pression financière aiguë. Le demandeur n’a pas de revenus, des réserves limitées, et une fenêtre fixe pour déposer sa demande. Un non-demandeur abandonne un paiement en ligne défaillant et fait ses achats ailleurs. Un demandeur d’allocations chômage handicapé ne le peut pas. Le service est obligatoire, le calendrier est fixé, l’alternative est la déstitution.

C’est ce qui fait d’un portail de prestations la surface d’accessibilité à enjeu le plus élevé sur le web public. Les dix portails étatiques que nous avons audités sont, à deux ou trois exceptions près, actuellement hors de conformité avec la règle fédérale entrée en vigueur en avril 2026. Ils étaient également, avant que cette règle n’existe, les défaillances d’accessibilité les plus lourdes de conséquences de la civic tech américaine. La règle DOJ n’a pas rendu ces portails importants. Elle les a rendus juridiquement opposables.

Ce qui change ensuite, c’est l’application, pas la technologie. Les corrections — aria-live sur les erreurs en ligne, un contrôle d’extension de session focalisable, des PDF balisés, un état de téléversement annoncé, un fallback CAPTCHA fonctionnel — sont individuellement petites, bien documentées et dans le budget de maintenance ordinaire de chaque organisme de la liste. Ce qui manquait, c’était la pression réglementaire, l’attention politique et le libellé du contrat de marchés publics pour que la correction se produise. Le premier est désormais présent.