Glisser-déposer : contrat d’accessibilité
Spécifie la sémantique, le comportement au clavier, la gestion du focus, les annonces et les règles d’interaction inclusives pour le glisser-déposer. Il fixe les limites d’adoption et les preuves observables d’échec tout en gardant 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 le glisser-déposer, adopter un contrat d’état et d’interaction réutilisable utilisant la sémantique native lorsque disponible. Spécifier le comportement sémantique, clavier, focus, annonces, visuel, mouvement et erreurs comme partie du contrat fonctionnel du composant. Ce bloc d’accessibilité se concentre spécifiquement sur le contrat d’accessibilité. Ce package est un contrat de référence : l’équipe adoptante doit choisir les limites numériques, fournisseurs, juridictions et responsables opérationnels à partir des preuves dans son propre environnement.
Portée
- Les acteurs, entrées, sorties, états, versions de politique ou schéma, et résultats visibles externes du glisser-déposer requis pour le focus du contrat d’accessibilité de ce bloc d’accessibilité.
- 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
- Définir les états déclencheur, ouvert ou actif, chargement, succès, vide, invalide, erreur, désactivé et rejet que le modèle peut atteindre.
- Spécifier ensemble les entrées clavier, l’entrée et le retour du focus, le nom accessible, les annonces, le comportement du pointeur et la cible tactile.
- Rendre explicites les effets destructeurs, irréversibles ou externes et empêcher les activations en double tant que le travail est en cours.
- Garder la hiérarchie du contenu et les actions utilisables à des largeurs étroites, fort zoom, expansion de texte, couleurs forcées et mouvement réduit.
- 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 seulement 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 un chemin clavier et tactile équivalent avec source nommée, cibles valides, état saisi, position, contraintes, annulation et complétion annoncés programmatiquement.
- Valider un déplacement ou une copie de manière atomique contre la version courante de la collection, préserver le focus après réorganisation et récupérer sans perdre l’intention lorsqu’une cible disparaît ou que le serveur rejette le changement.
- Pour la variante du contrat d’accessibilité, appliquer cette limite déclarée : spécifie la sémantique, le comportement clavier, la gestion du focus, les annonces et les règles d’interaction inclusives pour le glisser-déposer.
Conseils d’implémentation
- Écrire la séquence clavier et focus avant l’implémentation et revoir la copie avec étiquettes visibles et noms programmatiques côte à côte.
- Modéliser les entrées, sorties, acteurs, états, invariants, effets secondaires et preuves du glisser-déposer avant de sélectionner les détails du framework ou du fournisseur.
- Stocker la version applicable du contrat ou de la politique de glisser-déposer avec l’état matériel pour 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 garder une route de récupération testée jusqu’à ce que les preuves d’adoption soient complètes.
Gestion des échecs et protections
- En cas d’action échouée, préserver l’entrée et le focus pertinents, annoncer le résultat et ramener le composant à un état avec un chemin de récupération sûr.
- L’état invalide ou contradictoire du glisser-déposer 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 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 du glisser-déposer par version de contrat sans dimensions sensibles de charge utile.
- Relancer les fixtures positives et négatives appariées après 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 documentées et une propriété.
- 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 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.