Définit le comportement inclusif, les exigences sémantiques, les attentes en matière de technologies d'assistance et les cas d'échec courants pour les tables accessibles. Il fixe les limites d'adoption et les preuves d'échec observables tout en maintenant les limites spécifiques à l'environnement configurables.
Statut du package : contexte de référence prêt pour revue humaine. Le contrat et les scénarios de test sont complets, mais aucune affirmation n'est faite qu'une implémentation adoptante les ait validés.
Décision
Pour les tables accessibles, adopter d'abord la sémantique native, avec un contrat documenté pour le clavier et le focus. Spécifier le comportement sémantique, clavier, focus, annonce, visuel, mouvement et erreur comme partie du contrat fonctionnel du composant. Ce package est un contrat de référence : l'équipe adoptante doit choisir les limites numériques, fournisseurs, juridictions et propriétaires opérationnels à partir des preuves dans son propre environnement.
Portée
- Les acteurs, entrées, sorties, états, versions de politique ou de schéma, et résultats visibles de l'extérieur décrits par ce bloc d'accessibilité pour les tables accessibles.
- Interfaces principales et alternatives, travaux en arrière-plan, caches, intégrations, chemins de support et preuves pouvant exercer la même limite.
- Configuration spécifique à l'adoption, déploiement, récupération et responsabilités de vérification nécessaires pour appliquer la référence en toute sécurité.
Hors de ce bloc
- Choisir un fournisseur universel, un framework, une juridiction, un seuil numérique, une période de rétention ou un objectif de niveau de service pour chaque adoptant.
- Affirmer que les scénarios packagés ont été exécutés contre une implémentation en aval ou que cette référence accorde une certification légale, de sécurité ou d'accessibilité.
Contrat
- Exposer un nom programmatique, un rôle, une valeur, un état et une relation partout où l'interface visuelle les communique.
- Chaque action est opérable au clavier sans piège, et l'ordre de focus suit l'ordre de lecture et d'interaction.
- Annoncer les statuts asynchrones ou erreurs sans déplacer le focus de manière inattendue, et associer les conseils de récupération au contrôle affecté.
- Préserver le contenu et le fonctionnement sous zoom, espacement du texte, réagencement, couleurs forcées, réduction du mouvement et mise à l'échelle du texte de la plateforme lorsque applicable.
- Préférer les éléments natifs ; lorsqu'un widget personnalisé est nécessaire, implémenter son modèle d'interaction complet attendu plutôt que d'ajouter uniquement un rôle.
- Tester avec plusieurs modes d'entrée et au moins une combinaison représentative lecteur d'écran/navigateur définie par l'équipe adoptante.
- Fournir une légende ou un nom accessible et des relations programmatiques d'en-têtes de ligne et de colonne qui restent correctes après tri, filtrage, pagination ou transformation responsive.
- Exposer la sélection, l'état de tri, la position, les totaux et les actions sur les lignes au clavier et aux technologies d'assistance, et maintenir le contenu virtualisé dans un ordre de lecture et de focus cohérent.
Conseils d'implémentation
- Rédiger la séquence clavier et focus avant l'implémentation et revoir les copies avec étiquettes visibles et noms programmatiques côte à côte.
- Modéliser les entrées, sorties, acteurs, états, invariants, effets secondaires et preuves des tables accessibles avant de sélectionner les détails du framework ou du fournisseur.
- Stocker la version applicable du contrat ou de la politique des tables accessibles avec l'état matériel afin que les migrations, rejouages et décisions de support restent attribuables.
- Introduire le chemin derrière un déploiement contrôlé, comparer les résultats attendus et observés, et conserver une voie de récupération testée jusqu'à ce que les preuves d'adoption soient complètes.
Gestion des échecs et protections
- Si la sémantique ou le focus ne peuvent être préservés, l'interaction ne se déploie pas derrière un comportement visuel uniquement ; le défaut reste bloquant pour la sortie.
- L'état invalide ou contradictoire des tables accessibles est rejeté ou mis en quarantaine ; l'implémentation ne devine jamais une valeur qui élargit l'autorité ou duplique un effet.
- Les tentatives sont limitées et utilisent une identité durable ; après épuisement, le travail atteint un état terminal inspectable avec un propriétaire responsable.
Vérification et opérations
- Vérifier les règles automatisées, le fonctionnement au clavier uniquement, la visibilité du focus, les annonces, le contraste, le zoom et l'achèvement manuel des tâches.
- Surveiller le succès, le refus, l'échec de validation, l'échec de dépendance, l'épuisement des tentatives et la récupération des tables accessibles par version de contrat sans dimensions de charge utile sensibles.
- Relancer les fixtures positives et négatives appariées après des changements de politique, schéma, dépendance, migration ou limite et conserver les preuves résultantes.
Hypothèses d'adoption
- Les noms et valeurs dans l'exemple sont une fixture concrète, pas des valeurs par défaut universelles ; les adoptants les remplacent par des preuves et une propriété documentées.
- Le système adoptant peut fournir une identité authentifiée, des versions durables d'opérations ou d'enregistrements, une télémétrie limitée et un chemin contrôlé pour le changement.
Les exemples à l'apparence exécutable dans ce package sont des fixtures et des contrats d'acceptation. Exécutez le validateur de collection pour vérifier la structure et les métadonnées, puis traduisez et exécutez les scénarios dans le dépôt cible avant d'enregistrer les preuves d'implémentation.