Concevoir des structures filaires en tenant compte des directives d'accessibilité

Question

Je ne sais pas s'il y a une réponse définitive à cela, mais j'ai pensé que je vais la jeter ...

Je travaille sur la refonte d'un site pour une organisation fédérale qui exige également que son site soit accessible selon directives de la section 508 . L'une des recommandations que j'ai reçues était que je devais examiner l'intégration des directives d'accessibilité lors de la conception des structures filaires elles-mêmes afin de ne pas rencontrer de problèmes plus tard.

Ce que j'aime savoir, c'est s'il existe des lignes directrices recommandées sur la façon d'incorporer les principes d'accessibilité dans les wireframes (j'ai lu autant que possible sur la façon de intégrer l'accessibilité pendant la phase de conception visuelle et html), mais j'ai dessiné un blanc en ce qui concerne ce qui devrait être fait pour la conception filaire et quels devraient être les points de contrôle.

J'ai trouvé cet article intéressant qui parle de quelques lignes directrices mais elles sont assez génériques. Pour citer l'article:

Hiérarchie intuitive : Une page Web avec plus de 150 liens prendra très longtemps à parcourir, si un utilisateur écoute des noms de liens ou les lit visuellement . Cela rend la hiérarchie intuitive d'autant plus importante. Une bonne structure hiérarchique signifie que moins de liens sont présentés sur chaque page du site et que seuls les liens pertinents sont présentés sur la page au niveau suivant. Tant que les liens sont significatifs et pertinents, la hiérarchie ou la structure signifie que globalement, un utilisateur a moins de touches de tabulation à effectuer, car moins de liens pertinents sont disponibles.

Aides à la navigation: Les utilisateurs malvoyants sont souvent considérablement aidés par un index de A à Z ou un plan du site. Ces aides à la navigation présentent le contenu dans une longue liste qui peut être visualisée facilement avec un grossissement d'écran ou une grande taille de texte.

Utilisez des liens significatifs : en incorporant des liens dans la copie de présentation, les planificateurs de contenu peuvent soutenir le parcours des utilisateurs vers des informations clés. Les liens intégrés sont excellents car ils permettent aux lecteurs de mieux comprendre une page qu'un lien de navigation isolé dans un menu. Les liens intégrés peuvent donner aux utilisateurs un accès direct au contenu enfoui, à un niveau plus profond de la hiérarchie logique.

Je me demandais si quelqu'un était tombé sur des lignes directrices spécifiques en recherche ou à partir de sa propre expérience.

Henny Swan · Answer

J'ai travaillé avec des équipes UX pour aider à établir de bonnes pratiques en ce qui concerne l'inclusion de l'accessibilité dès le début ainsi que la documentation de certains problèmes dans les structures filaires et les conceptions.

Matt Obee a couvert les problèmes clés ci-dessus. À sa liste, j'ajouterais également:

Structure: comprendre comment fonctionne la structure des en-têtes sur la page, où se trouvent les listes, les repères WAI ARIA et les tableaux de données. La simple indication de l'en-tête principal, des sous-titres, etc. garantira que la conception prend en charge une structure d'en-tête logique au début du codage.
Couleur et sens: utiliser la couleur pour renforcer le sens est bon, assurez-vous simplement qu'il existe un autre moyen de définir la couleur pour les utilisateurs qui ne peuvent pas percevoir la couleur. C'est le même principe avec la forme et la taille.
Contraste des couleurs: il doit correspondre au minimum au contraste des couleurs des WCAG et des couleurs de premier plan et d'arrière-plan définies dans les guides de style.
États de mise au point: les états de survol et de mise au point doivent être définis pour tous les éléments pouvant être mis au point (le même style fonctionne bien et est préférable aux paramètres par défaut du navigateur). Assurez-vous également que les états sélectionnés sont uniques aux états de survol/focus.
Contenu/ordre de mise au point: si ce n'est pas immédiatement évident, il est nécessaire d'indiquer l'ordre du contenu dans les fils afin que les groupes d'informations connexes ne soient pas divisés. Ceci est essentiel pour les utilisateurs de lecteurs d'écran.

Tout ce qui précède peut être annoté en filaires et guides de style. En regardant la situation dans son ensemble, je dirais également que le rôle de l'UX est de réfléchir aux principes de conception UX accessibles suivants:

Choix: offrir deux façons de réaliser des interactions complexes ou non standard
Contrôle: ne pas supprimer les paramètres d'accessibilité du système ou forcer le contenu sur l'utilisateur lorsqu'il n'est pas demandé. Par exemple, supprimer le zoom pincé ou forcer la lecture automatique pour le multimédia.
Familiarité: utiliser des modèles de conception standard, un étiquetage cohérent et des alternatives sur tous les appareils - à la fois visuellement et dans un texte alternatif.
Valeur: lors de la hiérarchisation des fonctionnalités à inclure, demandez quels sont les avantages pour les utilisateurs handicapés. Ce qui pourrait être un Nice pour tous les utilisateurs pourrait être très avantageux pour les utilisateurs handicapés. Par exemple, en ajoutant un mécanisme de tri à une page de listes afin que les utilisateurs puissent trier par les plus récents, les plus populaires, etc.

J'ai écrit à ce sujet dans Smashing Mag dans une étude de cas sur la façon dont nous accessibilité intégrée dans UX sur BBC iPlayer .

DA01 · Answer

En termes de création de documents d'accessibilité filaires, ce n'est pas à ça que servent les filaires!

D'autres choses que les wireframes ne sont pas conçues pour être:

référentiels de contenu
spécification de conception d'interaction
spécifications de conception visuelle
un dossier permanent
etc.

:)

Mon point étant simplement qu'il est important pour les équipes UX de repousser le désir que les wireframes soient le document d'enregistrement . Les wireframes sont un moyen d'esquisser visuellement des idées. C'est leur intention. Leur demander de faire plus que cela, bien que courant, est également lourd d'inefficacités.

Quant à l'accessibilité en particulier, elles sont déjà documentées. Comme vous l'avez souligné, les directives 508 ou WCAG en sont des exemples.

La clé de l'accessibilité est que tout le monde doit le comprendre et en être conscient. L'équipe UX doit en avoir connaissance afin de ne pas concevoir délibérément des solutions difficiles à rendre accessibles. Les développeurs doivent le comprendre pour que le balisage de couche de présentation et le javascript qu'ils utilisent soient accessibles pour commencer.

Demander à un filaire de communiquer les exigences d'accessibilité revient à demander à un filaire de communiquer les meilleures pratiques HTML. C'est juste un ensemble de compétences que les constructeurs du site devraient posséder. S'ils ne possèdent pas cette compétence, alors c'est un problème de formation/éducation - pas un problème UX Wireframe.

Donc, sur la base de tout cela, en termes de réponse à votre question spécifique:

comment intégrer les principes d'accessibilité dans les wireframes

Cela revient aux concepteurs UX travaillant sur les wireframes qui doivent avoir une connaissance des meilleures pratiques d'accessibilité. Il n'y a pas de liste principale de choses à surveiller, car cela sera toujours très axé sur le contexte. Et il y a toujours aussi place pour le débat. Je suggère donc que la meilleure solution soit de vous assurer que votre équipe UX a une certaine formation en accessibilité. Idéalement, faites appel à un membre du personnel UX qui est un expert des questions d'accessibilité.

Matt Obee · Answer

Je ne suis pas au courant que quiconque ait compilé une liste de directives 508 ou WCAG qui méritent spécifiquement d'être étudiées pendant la phase filaire. Certains aspects visuels tels que le contraste des couleurs et la taille du texte, et les détails techniques de la mise en œuvre tels que le balisage HTML sont presque certainement hors de portée au stade du wireframing. Cela dit, il y a certainement encore beaucoup de choses à considérer. Les décisions que vous prenez dans les wireframes en ce qui concerne la fonctionnalité et la structure auront presque certainement des implications d'accessibilité.

En plus des trois domaines cités dans la question (hiérarchie intuitive, aides à la navigation et liens significatifs), le printemps suivant vient à l'esprit:

Pensez à l'accessibilité au clavier (et au toucher) lorsque vous filmez des commandes complexes ou des interfaces inhabituelles. Ne présumez pas que vous pouvez compter sur la souris.
Comment les utilisateurs sauront-ils où ils se trouvent? Devez-vous inclure, par exemple, un fil d'Ariane?
Pour déplacer et mettre à jour automatiquement le contenu, réfléchissez à la manière dont l'utilisateur pourra suspendre/arrêter;
Pour le contenu audio et vidéo, réfléchissez à la manière dont votre interface donnera accès à une transcription textuelle;
Ne vous fiez pas à la forme, à la taille ou à l'emplacement visuel pour fournir des instructions ou fournir des informations importantes;
Prévoyez une longueur de ligne appropriée (ni trop courte, ni trop longue);
Validation du formulaire - Comment indiquerez-vous les champs obligatoires et comment présenterez-vous les messages d'erreur?
Comment l'interface répondra-t-elle aux différentes entrées utilisateur? Par exemple, taper un champ changera-t-il automatiquement la page? Comment communiquerez-vous ces modifications à vos utilisateurs?

Il convient de noter que ces considérations varient en fonction de la personne qui produit et consomme les wireframes, et dans quel but. Si vous produisez des wireframes afin de donner une orientation aux concepteurs et aux développeurs, vous devriez probablement réfléchir davantage aux détails de l'accessibilité, plus que s'ils étaient utilisés pour donner une vue d'ensemble de haut niveau (pour un client, peut-être).