Comment décrire les conceptions complexes pour les utilisateurs handicapés

Vous êtes un développeur qui vient de recevoir une spécification de conception complexe. Vous savez que les conceptions prennent en charge l'accessibilité car votre équipe UX a lu un article de Medium sur la conception accessible il y a quelques mois. C’est maintenant à vous de créer une expérience accessible, mais par où commencer?

Il y a le WCAG 2.0, qui est largement respecté comme «la vérité» en ce qu'il concerne les normes d'accessibilité internationales. Il existe également la spécification WAI-ARIA, qui est une partie importante de toute boîte à outils de développement axée sur l'accessibilité. En remontant dans le temps, il existe la norme du gouvernement fédéral américain, l’article 508 de la loi sur la réhabilitation.

Bien qu'elles ne soient pas connues pour leur pertinence durable, les normes d'accessibilité techniques de la section 508 contiennent une suggestion très sage. Il déclare que

“… Les technologies d'assistance doivent disposer d'informations suffisantes sur un élément d'interface utilisateur, y compris l'identité, le fonctionnement et l'état de l'élément.”

Écrit à l'origine pour un logiciel, ces mots sont encore plus pertinents aujourd'hui compte tenu de la prévalence des applications Web. Ils décrivent le type d'informations dont les utilisateurs handicapés ont besoin pour mener à bien une tâche. Il peut s'agir d'un utilisateur aveugle avec un lecteur d'écran, d'un utilisateur à entrée vocale ayant une déficience physique ou de plusieurs autres types d'utilisateurs dotés de diverses technologies d'assistance.

Les principes de base pour rendre toute interaction accessible à la fois au clavier et aux utilisateurs de lecteurs d'écran se résument à la fourniture de trois informations de base: identité, fonctionnement et état.

Les utilisateurs qui interagissent avec un élément aussi élémentaire qu'une case à cocher ou aussi complexe que l'expérience du glisser-déposer doivent prendre en compte ces trois questions:

  1. Identité: Avec quoi est-ce que j'interagis?
  2. Opération: Comment utiliser cette chose?
  3. Etat: Quel est l'état actuel de cette chose?

Un regard plus attentif sur les cases à cocher

Un utilisateur voyant reçoit de nombreux indices visuels liés à l'identité, au fonctionnement et à l'état. Jetons un coup d’œil à une simple case à cocher à titre d’exemple.

Case à cocher avec étiquette «J'accepte les conditions d'utilisation»

Lorsque je vois un carré à côté des mots «J'accepte les présentes conditions», j'ai coché une case.

Même case à cocher avec une souris prête à cliquer.

Je sais comment utiliser la case à cocher en cliquant sur la case. Cela permettra de passer de coché à coché.

Une case à cocher avec une étiquette,

Si je vois une coche à l'intérieur de cette case, je sais que son statut est «coché».

Comment un utilisateur aveugle obtiendrait-il cette information?

«Je suis d'accord avec ces termes et conditions. Case à cocher, non cochée. Appuyez sur la barre d'espace pour vérifier.

Si un lecteur d'écran le lit à un utilisateur aveugle, il reçoit trois informations importantes.

  1. L'identité de l'objet: une case à cocher pour déclarer si je suis d'accord ou non
  2. L'état: non vérifié
  3. L'opération: appuyer sur la barre d'espace fera basculer l'état

Dans cet esprit, considérons trois méthodes, du plus préférable au moins préférable, pour fournir l’identité, le fonctionnement et l’état à la technologie d’assistance: utiliser des contrôles natifs, utiliser ARIA et, en dernier recours, utiliser intelligemment des textes masqués et des régions actives.

Contrôles Natifs

Les contrôles natifs tels que les contrôles de formulaire et les boutons seront toujours la meilleure option. Dans l'exemple ci-dessus, une vraie case à cocher est idéale car elle fait tout le travail à votre place. Il n’est pas nécessaire de créer l’opération en utilisant JavaScript, la case à cocher s’identifie déjà et indique son état. De plus, les utilisateurs savent comment les utiliser.

Pour des interactions plus complexes, telles que le glisser-déposer, déterminez si un élément natif peut être utilisé en arrière-plan. Pensez à redimensionner la largeur des colonnes dans un tableau:

Glisser-déposer pour redimensionner la largeur de la colonne

Un curseur ou une entrée de plage est l'équivalent natif parfait de ce comportement et fournit sa propre identité, opération et état.

Curseur de gamme

Cela peut être caché visuellement à l'aide de CSS, tout en restant disponible pour les utilisateurs de lecteurs d'écran. Synchronisez sa valeur avec la largeur de la colonne et un utilisateur aveugle interagira avec un contrôle de formulaire familier. Un utilisateur voyant continuera à glisser-déposer comme prévu.

WAI-ARIA

Dans les endroits où l'utilisation d'un contrôle natif n'est pas possible, suivez les meilleures pratiques ARIA (Accessible Rich Internet Applications) pour les modèles de conception courants tels que les menus, les boîtes de dialogue et les commandes à complétude automatique.

Ces consignes sont rédigées de manière à ce que les modèles d’interface utilisateur qui ne sont pas disponibles nativement en HTML s’identifient toujours correctement aux utilisateurs de technologies d’assistance.

Prenons par exemple un élément de sélection standard:

Élément de base de sélection.

C'est un élément accessible nativement. Il est parfait pour utiliser des formulaires, pour choisir une option dans une liste. Ils peuvent même servir de menus. Malheureusement, ils sont «laids» aux yeux de nombreuses équipes de conception et il est très difficile de les styler et de rester cohérents d’un navigateur à l’autre. Pour cette raison, leur utilisation est largement rejetée dans les applications Web modernes. Au lieu de cela, les gens créent leurs propres menus déroulants.

Menu construit avec ARIA

Si vous construisez votre propre interface utilisateur interactive à partir de rien, il est très important d’utiliser le balisage approprié, de fournir les comportements de clavier appropriés et d’inclure ainsi que de mettre à jour les attributs ARIA. C'est le seul moyen de fournir une identité, un fonctionnement et un état correct aux utilisateurs de technologies d'assistance.

Régions en direct et texte masqué

S'il n'y a pas d'élément natif équivalent à ce que vous construisez et qu'il n'existe pas de directive ARIA, vous devez délibérément fournir des informations en utilisant une combinaison de techniques.

  • caché visuellement à l'aide de CSS, mais toujours lisible par les utilisateurs de lecteurs d'écran
  • Une région "aria-live"
  • Une méthode JavaScript pour mettre à jour le contenu textuel de cette région

Lorsque du texte est ajouté à une région active, il est placé directement dans la file d’attente d’un lecteur d’écran et communiqué à ses utilisateurs. En masquant visuellement cette région, nous créons une méthode pour communiquer directement avec les utilisateurs de lecteurs d'écran.

Si vous construisez une interface utilisateur complexe, telle qu'une liste triable utilisant le glisser-déposer, ces méthodes sont indispensables.

Faites glisser et déposez pour réorganiser une liste.

Pour identifier le glisser-déposer, utilisez aria-décritby pour associer du texte masqué à chaque élément de la liste indiquant «Appuyez sur la barre d'espace pour saisir cet élément». Cela fournira une identité. Lorsque les utilisateurs saisissent l'élément, indiquez l'opération et l'état en plaçant du texte dans la région dynamique:

“{Nom de l'élément} saisi, utilisez les touches de direction pour réorganiser, barre d'espace pour déposer. Échapper à annuler. Position actuelle dans la liste, 1 sur 7 ”.

Vous pouvez également fournir le statut final après la suppression d'un élément:

“{Nom de l'élément} supprimé. Position finale en liste, 4 sur 7 ”.

Pour rappel, cette méthode ne devrait être utilisée qu'une fois les éléments natifs éliminés et les composants spécifiés par ARIA inexistants ou ne fonctionnant pas. Comme vous fournissez votre identité, votre fonctionnement et votre statut, des tests utilisateur seront nécessaires pour déterminer le meilleur moyen de communiquer ces informations à vos utilisateurs.

Maintenant, allez prendre ces conceptions accessibles et créez une expérience qui peut être appréciée de tous les utilisateurs, y compris les handicapés. Grâce à ces méthodes, vous serez en mesure de fournir des informations d’identité, de fonctionnement et d’état à tous vos utilisateurs, qu’il s’agisse d’une interaction simple ou complexe.

Jesse est le spécialiste principal de l'accessibilité chez Salesforce. Envoyez-lui un tweet @jessehausler, son téléphone est solitaire.

Suivez-nous sur @SalesforceUX.
Voulez-vous travailler avec nous? Contactez uxcareers@salesforce.com
Découvrez le système de conception Salesforce Lightning