Sujet : accessibility
-
Signaux de jeu accessibles aux daltoniens : ne pas transmettre l'état par la seule teinte
Associez la couleur à des symboles, des motifs et des libellés stables, puis testez le signal complet à l'échelle réelle du jeu au lieu de vous fier uniquement à un préréglage de palette.
-
Interfaces sensibles aux paramètres régionaux : règles de pluriel Intl, dates et mise en page droite-à-gauche
Formater les nombres, dates et heures relatives avec les objets Intl du navigateur plutôt que par arithmétique de chaînes, choisir les formes de pluriel par les catégories d'Intl.PluralRules plutôt que par n == 1, mettre en page avec des propriétés CSS logiques pour qu'un document dir=rtl se reflète lui-même, et laisser de la place pour un texte qui s'allonge à la traduction.
-
Texte courant lisible : longueur de ligne, interligne et contraste
Trois propriétés décident si un texte long se lit confortablement : la longueur de ligne (le critère AAA des WCAG la plafonne à 80 caractères), l'interligne (au moins 1,5 fois la taille de la police doit être possible sans que la mise en page se casse) et le contraste (4,5:1 pour le texte normal, 3:1 pour le texte grand). Utiliser des unités relatives pour que les personnes puissent agrandir le texte et le respacer.
-
Icônes SVG : balisage en ligne, sprite avec use, ou élément img
Le SVG en ligne peut être stylé avec currentColor et le CSS, mais répète les octets à chaque occurrence ; un sprite de même origine référencé avec use n'est mis en cache qu'une fois et suit tout de même la couleur du texte ; un img est mis en cache mais opaque au CSS. Choisir selon le rôle de l'icône, garder les icônes décoratives masquées aux technologies d'assistance, et dimensionner chaque icône pour que rien ne se déplace pendant le chargement du sprite.
-
Texte de corps lisible : mesure, hauteur de ligne et contraste
Trois propriétés déterminent si un long texte peut être lu confortablement : la longueur de ligne (le critère AAA des WCAG la plafonne à 80 caractères), l'interlignage (un espacement d'au moins 1,5 fois la taille de police doit rester possible sans casser la mise en page) et le contraste (4,5:1 pour le texte normal, 3:1 pour le grand texte). Les définir en unités relatives permet aux personnes qui utilisent le site de redimensionner et de réespacer le texte.
-
Le mode sombre avec prefers-color-scheme, color-scheme et light-dark()
Le mode sombre comporte trois volets : la media query prefers-color-scheme pour détecter le choix de l'utilisateur, la propriété color-scheme (et la balise meta correspondante) pour indiquer au navigateur quels schémas la page prend en charge afin que les contrôles de formulaire, les barres de défilement et le canevas suivent, et light-dark() ou des propriétés personnalisées pour permuter les valeurs de palette sans dupliquer les règles.
-
Sélecteurs stables et attente automatique dans les tests de bout en bout en navigateur
Deux causes dominent l'instabilité des tests en navigateur : des sélecteurs qui se cassent ou correspondent au mauvais élément, et des pauses temporisées qui présument d'un minutage. Localiser les éléments par rôle, libellé ou identifiant de test, faire en sorte que chaque localisateur corresponde à exactement un élément, et synchroniser sur des assertions qui réessaient et des vérifications d'actionnabilité plutôt que sur le temps.
-
Formulaires accessibles : libellés, messages d'erreur et autocomplete
Donner à chaque contrôle un libellé associé via for et id, marquer les champs obligatoires dans le texte et avec l'attribut, utiliser les jetons autocomplete pour que navigateurs et technologies d'assistance connaissent la finalité d'un champ, et signaler les erreurs dans un résumé accompagné de messages par champ reliés via aria-describedby.
-
dialog contre popover : comportement modal, la couche supérieure et la fermeture légère
dialog avec showModal() est modal : couche supérieure, page rendue inerte, ::backdrop, touche Échap, closedby et form method=dialog ; l'attribut popover fait de n'importe quel élément une superposition non modale de la couche supérieure, qu'un bouton peut basculer sans script, avec fermeture légère en état auto. Utiliser dialog pour les invites bloquantes et les formulaires, popover pour les menus, infobulles et notifications toast.
-
Sous-titres et sous-titres descriptifs dans les jeux : préserver le sens, le minutage et la lisibilité
Représenter les dialogues et les événements sonores significatifs par des cues minutés, gérer délibérément les chevauchements et proposer une présentation lisible avant la première scène parlée.
-
Que s'attendent à voir supprimé les personnes qui activent la réduction des animations : toute animation, les grands mouvements, ou seulement la lecture automatique ?
Question ouverte : le réglage de réduction des animations dit « réduire », pas « supprimer entièrement », et les recommandations suggèrent de conserver de petites transitions porteuses de sens tout en supprimant les effets de parallaxe, les zooms et la lecture automatique ; existe-t-il des données sur ce que veulent réellement les personnes qui activent ce réglage, et leurs attentes diffèrent-elles selon la raison (trouble vestibulaire, distraction, batterie, préférence) ?
-
Rôles ARIA : pourquoi un élément HTML natif l'emporte sur un div doté d'un rôle
La première règle d'utilisation d'ARIA du W3C est de préférer un élément ou un attribut HTML natif qui possède déjà la sémantique et le comportement requis ; ARIA ne change que ce qui est communiqué aux technologies d'assistance, jamais ce que fait l'élément. Un div doté de role=button a encore besoin que la focalisabilité, la gestion du clavier et les états soient ajoutés à la main, et chaque erreur reste invisible lors d'un test visuel.
-
Navigation au clavier dans les widgets composites : tabindex flottant, flèches et Échap
Tab et Maj+Tab déplacent le focus entre les composants ; les touches fléchées le déplacent à l'intérieur d'un composant, tel qu'une liste d'onglets, une barre d'outils, un menu ou un groupe de boutons radio. Mettre cela en œuvre avec un tabindex flottant (un seul élément à tabindex=0, les autres à -1) ou avec aria-activedescendant, fermer les surfaces transitoires avec Échap, et ne jamais piéger le focus sans offrir une sortie annoncée.
-
Gestion du focus dans les interactions de page unique : boîtes de dialogue, changements de route et éléments supprimés
Lorsqu'une page change sans chargement complet, le focus clavier doit être déplacé délibérément : dans une boîte de dialogue à son ouverture et de retour vers son déclencheur à sa fermeture, vers le titre de la nouvelle vue après un changement de route côté client, et vers un voisin pertinent quand l'élément focalisé est supprimé. Sinon, le focus retombe sur le corps du document et les personnes utilisant un lecteur d'écran sont renvoyées en haut de page.
-
prefers-reduced-motion : quelles animations réduire, et comment
La fonctionnalité média prefers-reduced-motion indique si l'utilisateur a demandé moins de mouvement au système d'exploitation ; ses valeurs sont no-preference et reduce. La respecter consiste à remplacer les grands mouvements (parallaxe, zooms, glissements, animations en lecture automatique) par des fondus ou des changements instantanés, tout en conservant les petites transitions d'état porteuses de sens, et à appliquer la même règle aux animations pilotées par script.
-
Action maps d'Unity Input System : contextes, control schemes et remappage persistant
Organisez des actions sémantiques par contexte de jeu, distinguez les control schemes (périphériques) de l'activation des maps et donnez au remappage un cycle de vie complet.
-
Accessibilité : les quatre principes WCAG appliqués concrètement
Les WCAG 2.2 classent tous les critères de succès selon quatre principes : perceptible, utilisable, compréhensible, robuste. Connaître par principe les manquements les plus fréquents (alternatives textuelles absentes, pièges au clavier, contraste insuffisant, champs non étiquetés, cibles trop petites) permet de repérer de nombreux obstacles sans outil spécialisé ; le niveau AA est l'objectif habituel.
-
Quelle part des défauts d'accessibilité trouvés en audit manuel ou signalés par des utilisateurs avait passé les contrôles automatisés en CI, et quels types de défauts leur ont échappé ?
Question ouverte : les recommandations du W3C WAI sur les outils d'évaluation indiquent que certains contrôles d'accessibilité ne peuvent pas être automatisés et nécessitent une intervention manuelle ; pour des sites qui font tourner un vérificateur automatisé à chaque build, quelle part des défauts trouvés ensuite lors d'un audit manuel ou signalés par des utilisateurs avait passé ce vérificateur, et quels types de défauts expliquent cet écart ?
-
Cibles tactiles et types de pointeur : dimensionner les contrôles pour les doigts et les souris
Le WCAG 2.2 exige des cibles de pointeur d'au moins 24 sur 24 pixels CSS au niveau AA, avec des exceptions pour l'espacement, les liens en ligne et les contrôles équivalents, et 44 sur 44 au niveau AAA. Les media features pointer et hover indiquent si l'entrée principale est grossière (coarse) ou fine et si elle peut survoler, ce qui permet à une conception d'agrandir les contrôles et d'abandonner les interactions au survol seul là où le pointeur est un doigt.
-
Fondamentaux de l'accessibilité : perceptible, utilisable, compréhensible, robuste
Le WCAG organise ses exigences autour de quatre principes ; les défaillances les plus courantes sur les sites de contenu sont l'absence d'alternatives textuelles, une signalisation reposant uniquement sur la couleur, les pièges au clavier, un contraste faible et des contrôles sans étiquette.
Lisible par machine : JSON