Les éléments désactivés devraient-ils pouvoir être ciblés à des fins d'accessibilité?
Par exemple, si nous avons un assistant de configuration à 3 étapes et que l'utilisateur est à l'étape 1, si l'utilisateur peut se concentrer sur le contrôle pour passer à l'étape suivante, que ce contrôle soit désactivé ou non ? L'état du contrôle (activé ou désactivé) dépend du fait que l'utilisateur a satisfait aux exigences de l'étape en cours (dans ce cas, l'étape 1). Je pense que les éléments désactivés devraient être focalisables, juste pour rendre les choses moins compliquées et déroutantes.
Je travaille sur une webapp professionnelle pour les utilisateurs de lecteurs d'écran malvoyants.
Nous effectuons des tests utilisateur régulièrement, et cela a été soulevé à plusieurs reprises au cours des sessions de test utilisateur que les éléments désactivés qui sont nécessaires pour terminer une étape/un flux (ou sont généralement trop importants pour être manqués) devraient être ciblables avec la touche TAB.
Si les boutons désactivés ne sont pas focalisables avec TAB, notre utilisateur manquerait occasionnellement que le bouton existe jamais, et ils ne le trouveront jamais.
Ceci est un problème de blocage
En outre, comme l'a dit @Andrew Martin, si vous écrivez la raison du handicap dans l'info-bulle du bouton (ce qui n'est peut-être pas une bonne pratique, mais cela pourrait quand même arriver), il est possible que les lecteurs d'écran comme JAWS ne le lisent jamais. car les descriptions/info-bulles lisent uniquement la description sur le focus TAB.
Je dirais donc que dans votre cas d'utilisation, vous pouvez totalement y aller.
C'est un peu délicat.
Normalement, avec des éléments de formulaire réguliers, il serait préférable de supprimer complètement tout ce avec quoi vous ne pouvez pas interagir ou qui ne sert à rien.
Cependant, ce bouton particulier dont vous parlez (le bouton "étape suivante") peut également servir de guide pour le niveau d'achèvement - c'est-à-dire que vous ne pouvez pas passer à l'étape suivante tant que le formulaire ne contient pas suffisamment de données.
L'état désactivé, dans ce cas, indique à l'utilisateur qu'il n'a pas entré toutes les données requises.
En ce qui concerne le problème de la mise au point, il n'est généralement pas judicieux de permettre aux éléments désactivés visibles de se concentrer - la mise au point implique la possibilité d'interaction. En impliquant une interaction, vos utilisateurs sont susceptibles de penser que le bouton est défectueux plutôt que désactivé. La seule situation où vous pourriez vouloir ajouter le focus est si le bouton contenait un message indiquant pourquoi il a été désactivé - mais cela en soi est une mauvaise conception car cela le message devrait être traité ailleurs de manière plus visible et compréhensible.
CORRECTION
Merci à SteveD d'avoir signalé l'erreur ici:
Empêcher la concentration sur un élément désactivé qui est également utilisé comme indicateur de progression (comme dans le cas présenté par l'OP) empêche également sa lecture par le logiciel de lecture d'écran. Cependant, cela peut être corrigé dans le HTML:
Tant que le HTML utilise l'attribut désactivé, cela indiquera à l'agent utilisateur que le champ est désactivé, mais uniquement si le champ peut prendre le focus du clavier
Voir les commentaires ci-dessous pour plus de détails.
En tant que contrepoint marginal à @Leths, un lecteur d'écran vous permet d'accéder à chaque objet sur la page, qu'il soit désactivé ou non, à moins qu'il ne soit spécifiquement caché au lecteur d'écran à l'aide de aria-hidden=true. Je ne voulais pas ajouter ceci en tant que commentaire à la publication de @Leths, car il s'agit d'un point important lié à la question principale. Autrement dit, même si vous décidez pas pour permettre au focus d'aller aux objets désactivés, l'utilisateur du lecteur d'écran peut toujours accéder à ces objets. Avec JAWS (le lecteur d'écran le plus populaire pour le PC), vous pouvez utiliser le curseur du PC virtuel ou l'une des boîtes de dialogue d'accessoires JAWS (comme Ctrl + Ins + B pour obtenir une liste de boutons, les boutons désactivés ayant le texte `` indisponible ''). 'ajouté au nom du bouton).
Maintenant, cela étant dit, un utilisateur de lecteur d'écran parcourra souvent la page pour obtenir une image mentale de ce qui s'y trouve, et la tabulation ignorera les boutons désactivés par défaut. Si l'utilisateur était si enclin, il pouvait naviguer dans tout le DOM à l'aide du curseur du PC virtuel, ou faire apparaître des boîtes de dialogue de tous les boutons ou cases à cocher ou boutons radio ou autre, mais c'est un peu fastidieux juste pour construire votre modèle mental de la page. Idéalement, pour l'utilisateur du lecteur d'écran, il devrait pouvoir accéder aux objets désactivés. Ce n'est peut-être pas idéal pour les utilisateurs de clavier voyants, mais ce n'est pas non plus un terrible préjudice pour eux.
Edit: La logique est que ce n'est que si un élément répond aux événements qu'il peut être focalisé. Cependant, comme @Leths commente son expérience, cela peut être préjudiciable dans certains cas. Je suppose donc que la meilleure chose à faire est de suivre ce que vos utilisateurs attendent et ce que cela leur apporterait le plus.
Non, si l'utilisateur ne peut pas interagir avec l'élément, ne donnez pas l'indication (focus) que c'est possible.
La pseudo-classe: focus s'applique lorsqu'un élément a le focus (accepte les événements du clavier ou de la souris, ou d'autres formes d'entrée).
Source: W
Avec une souris, un changement de curseur indique que l'utilisateur peut interagir avec l'élément. Un pointeur, par exemple, indique à l'utilisateur que l'élément peut interagir.
Avec un clavier, la propriété focus indique que l'utilisateur peut interagir avec l'élément.
L'élément dans l'état que vous avez ne permet aucune interaction de la part de l'utilisateur, donc je ne donnerais pas l'indication qu'une interaction est disponible .
Voici un exemple de W3 d'une entrée désactivée qui ne peut pas être focalisée.
Voici un exemple du comportement que j'attendrais d'un assistant. Dans ce cas, il s'agit d'une boîte de dialogue de désinstallation (le premier programme que j'ai pu trouver pour l'essayer). C'est comme ça depuis aussi longtemps que je me souvienne. Fermer et afficher les détails sont les seules options disponibles, et les échanges d'onglets entre les deux.
Donc, pour répondre à la question, je suivrais la convention à laquelle je suis habitué et désactiverais complètement les boutons non interactifs de la même manière que Windows. Cependant, d'autres (et peut-être non utilisateurs de Windows) peuvent ne pas être d'accord.
Oui. Les boutons désactivés doivent pouvoir être mis au point. Non seulement parce que l'accessibilité, mais aussi d'expliquer dans les alertes pourquoi il est désactivé.
Ma règle d'or est la pertinence de la commande. Certains boutons que je cache lorsqu'ils sont déphasés ou hors contexte. Certains que je montre et explique pourquoi est désactivé lorsque vous cliquez dessus.
Par exemple: une vue détaillée du processus n'est activée que pour les managers. L'employé voit la commande désactivée. Lorsque vous cliquez sur l'alerte, expliquez ce qu'est la fonction et qu'il doit demander à son responsable si nécessaire. Cela évite à l'employé de remplir une suggestion "ce serait bien d'avoir la possibilité de voir les détails du processus" pour obtenir une réponse "demandez à votre manager".