Table des matières
Comment rendre les modaux utilisables et accessibles?
Une boîte de dialogue modale ou modale est une fenêtre de superposition qui s’ouvre au-dessus du contenu ou de l’écran principal actuel. Il se concentre sur lui-même, rendant généralement l’arrière-plan inactif («inerte») – c’est-à-dire visuellement grisé ou grisé.
Il peut être ignoré en appuyant sur une sorte de bouton de fermeture ou X, en tapant loin de la zone de mise au point ou en appuyant sur un CTA «d’annulation» approprié.
Dans la conception et le développement Web, trois facteurs influent sur le succès des modaux:
ArticlesA lire
- Existe-t-il un cas d’utilisation approprié?
- Est-il conçu conformément à heuristique d’utilisation et Directives du W3C?
- Est-il construit conformément au W3C et maximise les pratiques ARIA?
Chacun de ces éléments peut entraîner des problèmes de convivialité et d’accessibilité pour les utilisateurs.
Dans cet article, je vais voir comment les ensembles de compétences de conception UX et de développement frontal peuvent travailler ensemble pour obtenir des résultats positifs.
Remarque: Ce sont des enseignements tirés de projets en direct et d’études personnelles, donc comme toujours – corrigez-moi dans les commentaires. Nous sommes tous un travail en cours.
Il existe deux principaux cas d’utilisation acceptés pour les modaux:
1. Entrée de données – Pour permettre aux utilisateurs d’effectuer une petite tâche supplémentaire dans le cadre d’un flux principal sans ouvrir une nouvelle fenêtre ou commencer un nouveau voyage.
Cela permet à l’utilisateur de fournir les données requises par le système, sans quitter le contexte et le flux de la tâche dans laquelle il est actuellement engagé. Par exemple, il peut s’agir d’un sélecteur de date ou de certaines autorisations critiques. Dans les pratiques ARIA, ceci est couvert par un boîte de dialogue modale.
2. Une alerte – Introduire les frictions nécessaires.
Chaque tâche, voyage ou expérience ne doit pas être sans friction. Parfois, nous introduisons délibérément des frictions pour éviter les erreurs de l’utilisateur. Par exemple, la suppression de fichiers ou de contenu peut avoir un impact significatif sur le flux de travail, donc cela devrait être une action à friction élevée. Dans les pratiques ARIA, cela s’appelle un boîte de dialogue d’alerte.
La façon dont les modaux sont utilisés et conçus peut poser des problèmes d’utilisation et d’expérience utilisateur. Cependant, l’accessibilité visuelle la plus parfaite peut toujours tomber en matière d’accessibilité Web, si le modal n’est pas construit correctement.
Échec de l’utilisabilité
L’utilisation de modaux qui introduisent des frictions lorsqu’elles ne sont pas nécessaires, ou lorsqu’une tâche peut être exécutée en ligne ou dans le cadre de l’écran principal, peut être une interruption massive de l’expérience utilisateur.
Les occurrences courantes de ceci sont:
- Couvrir des voyages interrompus
Quelqu’un a décidé d’insérer quelque chose dans un parcours existant et plutôt que de repenser plusieurs écrans, ou de penser à travers l’IA, un modal a été considéré comme une solution opportune.
Dans ce scénario, en tant que concepteurs, nous devons vraiment remettre en question notre propre motivation et / ou celles de l’OP ou des parties prenantes qui le suggèrent. Est-ce de la paresse? Ou cela augmente-t-il vraiment la convivialité du produit et la facilité de réalisation des tâches? Dans l’exemple ci-dessus, j’ai mentionné un sélecteur de date – la question est donc de savoir s’il doit s’agir d’un mode de superposition? Cela ne peut-il pas être complété en ligne?
- Inscription par e-mail et astuce marketing générale
De nombreux sites Web l’utilisent délibérément – vous lisez un article ou du contenu et des messages contextuels « veuillez vous inscrire
Dans tous les cas et scénarios, car il s’agit d’une interruption soudaine du voyage, nous devons être extrêmement clairs sur l’objectif du modal – à la fois en interne et pour nos utilisateurs.
Si nous allons bombarder l’utilisateur avec des changements soudains dans l’interface utilisateur, nous devons être conscients de l’impact sur leur flux et reconnaître que des changements soudains peut déclencher une réponse au stress et comme nous le savons, même des réactions de stress légères peuvent conduire à des erreurs ou à l’abandon de tâches.
Une fois que vous avez cloué le design visuel, surmonté et l’épopée habituelle échoue du contraste des couleurs qui affligent Internet, vous pouvez toujours venir un cropper.
Ce qui ressemble à un modal fonctionnel peut se révéler illisible par les lecteurs d’écran et les technologies d’assistance – de sorte qu’ils ne peuvent même pas détecter et communiquer que le modal est affiché. Cela laisse l’utilisateur en tabulant le contenu d’arrière-plan, ignorant que le système nécessite une action supplémentaire de sa part.
L’utilisateur peut également rester bloqué, car le focus du clavier reste sur l’élément qui a déclenché le modal – l’action se produit ailleurs et ne peut pas être vue.
Non seulement les modaux doivent être détectés par la technologie d’assistance, mais ils doivent contenir des séquences d’onglets, des états de mise au point et des fonctions de fermeture / fermeture corrects. Il est donc essentiel de travailler avec nos amis dans le développement frontal – ces pratiques ARIA doivent être sur le point.
Nous avons donc décidé d’utiliser un modal car vous pensez vraiment que ce modèle répond aux besoins des utilisateurs et des entreprises – comment pouvons-nous les rendre utilisables et accessibles?
Il existe un certain nombre de pratiques de conception visuelle et d’ARIA que nous pouvons utiliser. Beaucoup d’entre eux heuristique d’utilisation de base et Directives du W3C.
Et bien sûr, le W3C fournit des conseils exhaustifs comme toujours sur les modes de dialogue, il ne s’agit donc que d’un résumé mettant l’accent sur l’expérience globale.
1. Remplissage d’écran et changement de focus
- Tous les modaux sur les sites Web rendus par mobile doivent remplir 100% de l’écran. Cela empêche le défilement en arrière-plan et garantit la lisibilité
- Sur les écrans non mobiles ou d’autres scénarios qui pourraient apparaître à l’avenir où nous ne remplissons pas 100%, nous devons nous assurer que l’arrière-plan est grisé ou grisé pour prendre en charge la concentration visuelle sur le modal.
Pour cette raison, un modal ne peut pas obliger l’utilisateur à avoir accès aux informations affichées sur l’écran derrière. Si l’utilisateur a besoin d’accéder aux informations sur l’écran principal pour terminer votre tâche, c’est un indice massif que vous utilisez le mauvais modèle de conception.
- Lorsque le modal est déclenché, changez l’arrière-plan en
aria-hidden='true'et avec le devenir modalaria-hidden='false'et{display:none;}devenir{display:block;}. - N’autorisez pas le défilement à l’intérieur du modal lui-même. Cela deviendra trop difficile à manipuler pour les utilisateurs, et vous risquez également de devenir un dépotoir de contenu à moins que vous ne mettiez en place des directives et des restrictions strictes.
2. Contrôle et licenciement
Les utilisateurs devraient pouvoir rejeter le modal en utilisant un CTA (close / X) ou en tapant loin du modal. L’exception à cela est lorsque le modal est un formulaire de capture de données, auquel cas être en mesure de puiser loin pourrait perdre à la perte de données déjà entrées. Dans ce scénario, un bouton «annuler» serait plus approprié. Encore une fois, l’introduction de friction là où il y a un risque d’erreur.
Quoi qu’il en soit, il devrait être parfaitement clair qu’il peut être rejeté et comment y parvenir.
• Le modal doit être facile à ignorer – tous les CTA doivent être clairs en termes de langage et de conception. Et bien sûr, vous êtes en utilisant des contrastes de couleurs appropriés tout au long.
• À la fin, l’expérience devrait revenir à l’état de mise au point sur l’écran sous-jacent – emplacement visuel pour l’utilisateur ou état de mise au point sur le terrain pour la technologie d’assistance. Dans la mesure du possible, le focus du lecteur d’écran revient à l’élément qui a déclenché le modal (sauf s’il n’est plus présent).
Comme pour les autres écrans, les modaux contiennent leurs propres séquences d’onglets, donc l’utilisation de Tab et Shift + Tab doit naviguer dans le modal uniquement, sans fermer jusqu’à ce que l’utilisateur sélectionne Fermer CTA ou ESC.
3. Message et objectif clairs
• Le modal a besoin d’un en-tête, qui indique clairement à quoi sert le modal et / ou ce que l’utilisateur peut désormais faire. Qu’il s’agisse d’une alerte (dialogue d’alerte) ou d’un mode d’interaction (dialogue modal), il doit être clair à 100%.
• Quand créer une boîte de dialogue d’alerte, utilisation alertdialog plutôt que dialogboîte de dialogue pour s’assurer que les lecteurs d’écran savent que le modal peut recevoir des commentaires de l’utilisateur (c’est-à-dire l’obligation pour l’utilisateur de confirmer qu’il a compris un message d’erreur)
• Lors de l’étiquetage de l’utilisation modale aria-labelledby de sorte que le titre visible soit associé au role=dialog récipient.
• Assurez-vous que l’action qui a déclenché le modal et la langue utilisée se reflètent dans le modal – c’est-à-dire en appuyant sur un bouton «sélectionner la date», ouvre un modal avec l’en-tête «sélectionner la date» – ou un équivalent presque identique.
• Ne placez pas de mots ou de boutons supplémentaires aléatoires dans le modal. Gardez-le aussi simple et minimal que possible (heuristique # 8)
4. Mise au point correcte tout au long
• Créez une concentration visuelle sur le modal et sur la tâche principale ou l’interaction du modal. Surtout s’il y a plus d’une étape dans un modal.
• Maintenez cette clarté de l’objectif à travers tous les écrans suivants dans le modal.
• Pour les lecteurs d’écran, nous devons nous assurer placement approprié de la concentration sur chaque étape du voyage, en utilisant aria-describedby pour mettre en évidence le contenu, les champs et les CTA.
• Si la tâche propose des décisions complexes ou à fort impact, nous devons alors nous concentrer sur l’élément le moins destructeur (c.-à-d. Annuler plutôt que « Supprimer tout »).
Il existe absolument des tonnes de ressources en ligne pour les développeurs frontaux travaillant avec ARIA, mais pour les concepteurs UX travaillant avec des modaux, voici mes meilleurs conseils:
• Soyez clair sur le cas d’utilisation de votre modal, assurez-vous qu’il prend en charge les utilisateurs et pas seulement la destruction de voyages professionnels. Soit dit en passant, si vous avez effectué votre travail d’analyse approfondie et l’aviez signé, cela devrait réduire le nombre d’insertions aléatoires de parcours des parties prenantes. Avec de la chance.
• Concevez tout en fonction de votre heuristique de base. Ils ont résisté à l’épreuve du temps pour une raison.
• Montrez vos wireframes et prototypes aux développeurs tôt – faites-leur valider que ce que vous avez construit (et testé avec les utilisateurs) peut être construit, et peut être construit en maximisant les pratiques ARIA.
• Testez vos prototypes avec de vrais utilisateurs. Ça coule de source. Mais il est inutile de construire quelque chose que les utilisateurs ne peuvent pas utiliser. Si l’entreprise fait pression pour une solution rapide (mais mauvaise), la vidéo met en évidence les rouleaux d’utilisateurs en difficulté peut vraiment aider à arrêter le non-sens.
• Testez votre site de mise en scène ou en direct avec la technologie de lecteur d’écran – il y a beaucoup de technologie d’assistance et outils de simulation disponibles.
• Vérifiez auprès de l’équipe de développement et soutenez-la généralement dans les tests bêta de votre expérience dans différents navigateurs – parce que les navigateurs peuvent prendre en charge quelles pratiques ARIA change avec chaque version.
En matière d’accessibilité, il s’agit vraiment de la conception (et de la recherche) 50-50 UX et du développement frontal. Comme toujours, suivez les directives, parlez-vous les uns aux autres et continuez à tester.
