Catégories
Start-up et applications

Utilisez des indicateurs de fonctionnalité pour rendre votre site Web plus accessible

Être apte est une condition temporaire.

Certains d'entre nous sont nés avec un handicap et certains d'entre nous les développent. À un moment de votre vie, vous deviendrez assez vieux pour avoir besoin de lunettes de lecture, ou vous vous casserez le bras ou vous développerez des problèmes d'audition. Lisez-vous cette page à travers des lunettes? Utilisez-vous une attelle de poignet ou une souris ergonomique? Votre système d'exploitation est-il réglé sur le mode sombre? Ce sont toutes des modifications d'accessibilité.

Le Web est né accessible
L’une des choses que j’aime et apprécie à propos de l’organe directeur du World Wide Web, W3C, c'est qu'ils s'efforcent constamment de rendre et de maintenir le Web ouvert et accessible. Les normes utilisées par les navigateurs et autres logiciels sont issues des recommandations du W3C. Votre navigateur actuel peut servir des pages à partir de 1998 et elles sont parfaitement lisibles, voire jolies, si les images ont été capturées.

Le W3C a un groupe dédié à l'accessibilité, et leur nouvel ensemble de normes, WCAG 2.2, entrera en vigueur en novembre 2020. En décembre, l'accessibilité d'un site Web sera évaluée en fonction des nouvelles normes.

> WCAG 2.0 et WCAG 2.1 sont des normes techniques stables et référençables. Ils ont 12-13 lignes directrices qui sont organisées sous 4 principes: perceptible, exploitable, compréhensible et robuste. Pour chaque directive, il existe des critères de succès, qui sont à trois niveaux: A, AA et AAA.

Il existe de nombreux correctifs d'accessibilité simples pour les pages Web, tels que l'utilisation d'en-têtes sémantiques au lieu de la mise en forme du texte, et l'utilisation de boutons HTML au lieu de DIV, et souvent, même le niveau le plus bas, A, est absent des pages Web d'une organisation. Mais comme tout dans le logiciel, l'amélioration progressive et le retour rapide sont plus utiles qu'un grand projet de transformation qui nécessite un engagement massif.

Certaines accessibilités Web nécessitent un conflit
Parfois, l'accessibilité nécessite un conflit. Par exemple, dans le exemples d'utilisateurs dans la documentation WCAG, certains utilisateurs ont besoin que leur texte soit redistribué autour de boutons de plus grande taille, et certains utilisateurs ont besoin que les boutons restent dans un emplacement stable pour la recherche. Si vous avez déjà été frustré lorsqu'une mise à jour de téléphone réorganise toutes vos applications, vous pouvez identifier à quel point cela peut être difficile lorsqu'une interface quotidienne change sans autorisation.

Les utilisateurs malvoyants sont souvent aidés par un texte à contraste élevé, noir sur blanc ou blanc sur noir. Cependant, les utilisateurs souffrant de dyslexie et d'autres problèmes de traitement de texte peuvent trouver le contraste trop discordant et ont besoin d'un contraste plus faible pour les aider à lire confortablement – quelque chose comme le gris foncé sur blanc cassé. Il est difficile pour un site ou une application de répondre à ces besoins contradictoires. Les utilisateurs disposent donc souvent d'extensions ou de paramètres de navigateur qui les aident à gérer leur expérience Web.

Les développeurs de sites et d'applications doivent être conscients que tout le monde n'utilise pas leur site ou leur application exactement comme le développeur le voit. Les utilisateurs peuvent avoir des écrans plus petits, être sur un appareil mobile ou avoir installé des extensions de navigateur dont le développeur n'a jamais entendu parler ou imaginé. Ce système fonctionne tant que nous nous développons selon les normes d'accessibilité qui maintiennent le web sémantique. Il semble contradictoire que rendre le Web accessible aux machines aide les humains, mais c'est le cas, parce que les humains utilisent les concepts de l'ordinateur pour traduire les informations d'une manière qui fonctionne pour eux.

Comment les indicateurs de fonctionnalité peuvent aider
J'ai réfléchi à la manière dont les indicateurs de fonctionnalités pourraient faciliter la conception d'accessibilité, en particulier en ce qui concerne le problème consistant à essayer de servir des populations ayant des besoins différents.

Quand il est possible de servir tout le monde, cela devrait être le code par défaut et le code de la page principale. Tout le monde est servi par des normes telles que les en-têtes sémantiques, le texte alternatif d'image et le texte qui n'est pas une image. Certaines personnes ont besoin d'accommodements supplémentaires, tels que la réduction des mouvements, la navigation par onglets ou de gros boutons. Ces besoins pourraient être des variantes de drapeau.

Un indicateur peut être configuré avec des variantes d'affichage de texte:

  • Standard (aucune modification du comportement CSS)
  • Basse vision (texte à contraste élevé, permettre le redimensionnement)
  • Dyslexie (utilisez la police OpenDyslexia en CSS)
  • Contraste réduit (réduit le contraste entre le texte et l'arrière-plan)

Cette variante d'indicateur peut être liée à un paramètre configurable par l'utilisateur, de sorte qu'à chaque fois qu'ils se connectent au site, ils obtiennent le texte comme ils en ont besoin, même s'ils se trouvent sur un navigateur ou un appareil différent.

C’est un exemple simple, bien sûr. Idéalement, les développeurs et les défenseurs de l'accessibilité travailleraient ensemble pour déterminer quelle partie du site ou de l'application devrait être modifiée, et comment cela fonctionnerait en combinaison avec d'autres modifications.

Le manque de planification est une dette technique
Même si votre équipe ne dispose pas en permanence d'experts en recherche d'utilisateurs ou en accessibilité, vous pouvez coder de manière proactive pour leur faire de la place. Les indicateurs d'accessibilité seraient permanents. Vous ne voudriez pas les supprimer comme vous le feriez pour un indicateur de déploiement. Comme ils sont permanents, il n'y a aucun mal à les utiliser comme espace réservé, ils n'ajouteront pas plus de demande de test à vide qu'ils ne satisferont.

Au début d'un projet, la plupart des équipes n'ont pas les ressources pour faire tout ce qu'elles veulent, même si elles savent que cela devra être fait à terme. Nous ne faisons pas de localisation pour les applications de preuve de concept, nous n'écrivons pas de documentation API pour des outils strictement internes. Mais si un produit réussit, alors nous devons ajouter ces éléments et ils deviennent une dette technique que nous devons rembourser sans ajouter de nouvelle valeur au produit.

L'un des moyens de réduire le coût de cette dette consiste à ajouter des espaces réservés pour les modifications futures. Tenter de refactoriser une application avec des éléments d'interface codés en dur pour accepter la localisation revient à essayer d'ajouter des pépites de chocolat à des cookies déjà cuits – c'est beaucoup moins efficace. L'utilisation d'indicateurs définis pour ne renvoyer qu'une valeur par défaut (pour le moment) est un moyen de planifier les modifications futures de votre code, sans investir pleinement.

L'avenir est ici
Les normes WCAG ne sont pas arbitraires ou imposées sans signification. Ils existent pour aider chacun à accéder aux informations, aux services et aux capacités dont il a besoin. Lorsque nous créons des sites qui ne répondent pas à ces normes, nous perdons des clients, des clients et des utilisateurs, et pas en petit nombre.

L'utilisation d'indicateurs de fonctionnalités pour rendre votre site accessible est une intervention plus petite et moins chère que la création de sites entièrement séparés. Les indicateurs de fonctionnalité aident également à créer le cadre pour fournir d'autres éléments de votre site à la demande, vous permettant de répondre aux besoins des utilisateurs avec précision et efficacité.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *