Keyboard Layout API, préférences régionales et confidentialité
Utiliser la disposition du clavier pour des libellés accessibles sans en faire un signal de frappe ou d’identité.
BotBrowser Team
Vous voulez la documentation structurée pour Empreinte ?
Cet article fait partie de la bibliothèque éditoriale. Pour les étapes de configuration, la référence et les mises à jour continues, passez directement à la section docs.
La spécification WICG Keyboard Map et les règles de contexte sécurisé du navigateur définissent la limite des informations de disposition exposées. BotBrowser permet de vérifier cette interface dans un profil contrôlé, mais ne capture pas les frappes et ne garantit pas une carte sur chaque hôte. Cette limite sépare un libellé utile d’un signal d’identité.
Résumé
Keyboard Layout API peut afficher les raccourcis selon la disposition active. C’est une aide de présentation, pas un enregistreur de frappes ni une preuve d’identité. Demandez la carte seulement pour une tâche claire et gardez un repli utilisable.
Sommaire
- Le rôle de la carte
- Permissions, politique et confidentialité
- Libellés accessibles et repli
- Règle de décision testable
- Conclusion
Le rôle de la carte
navigator.keyboard.getLayoutMap() associe des codes physiques aux caractères de la disposition active. Une aide peut ainsi montrer le raccourci visible par la personne. La carte ne contient pas l’historique des touches et sa lecture ne donne pas accès au texte saisi.
Gardez ce signal dans la présentation. Une personne peut changer de disposition, partager un appareil ou choisir une autre langue temporairement. La carte ne doit pas devenir un attribut de profil.
Permissions, politique et confidentialité
Le support dépend du navigateur, du contexte sécurisé et des permissions ou politiques. Un refus indique que cette présentation n’est pas disponible, pas que l’appareil est suspect. Utilisez la carte localement lorsque c’est possible et ne transmettez pas un inventaire inutile au serveur.
La carte ne remplace pas une règle responsable pour les événements clavier. N’enregistrez pas le texte et proposez aussi une action à la souris ou au toucher. Les diagnostics doivent rester minimaux et expliqués.
Libellés accessibles et repli
Conservez le nom de la commande et une alternative sans clavier. Ajoutez le libellé localisé lorsque la carte est disponible; le texte destiné aux lecteurs d’écran doit nommer la commande et les modificateurs. Sinon, utilisez un libellé documenté ou un réglage modifiable.
Vérifiez les textes longs, les langues de droite à gauche et un changement de disposition pendant la tâche. L’interface doit rester utilisable pendant une demande de permission.
Règle de décision testable
- Affichez d’abord le nom stable de la commande et une alternative.
- Dans un contexte sécurisé, demandez la carte à l’ouverture de l’aide.
- Si elle est résolue, affichez le libellé sans la stocker comme identité.
- En cas d’échec, gardez le repli et notez seulement le résultat utile au produit.
Le test attendu est simple: la personne trouve et déclenche « Annuler » avec ou sans carte; aucun test ne capture des frappes ni n’infère une nationalité.
Conclusion
La carte rend les commandes plus claires entre langues et claviers, mais reste une donnée de présentation limitée. BotBrowser peut vérifier une interface dans un profil contrôlé sur des systèmes compatibles; il ne capture pas les frappes et ne garantit pas une carte sur chaque hôte.
Consultez la spécification Keyboard Map, MDN Keyboard API, le guide des profils multiplateformes, le guide de formatage locale et le guide fuseau, région et langue.
Sources publiques
Articles Connexes
Faites passer BotBrowser de la recherche à la production
Utilisez ces guides pour comprendre le modèle, puis passez à la validation multi-plateforme, aux contextes isolés et au déploiement navigateur prêt pour l'échelle.