Accessibilité… sur le backend ?

Vous pouvez lire cet article en anglais ici.

Lorsqu'on parle d'accessibilité numérique, la plupart des gens pensent que les pratiques de ce sujet ne sont effectuées que par des développeurs et des concepteurs frontaux. S'il est vrai que la plupart du travail se situe dans ces domaines, ceux qui travaillent avec le backend ne sont pas complètement exclus de ce sujet.

Mais moi, le développeur backend, je ne fais pas de mise en page d'écran, j'écris une demi-douzaine de lignes de HTML une fois dans ma vie, comment pourrais-je aider dans ce scénario ?

Eh bien, il y a toujours un moyen. Ci-dessous, j'apporte quelques idées d'action de personnes backend dans le domaine de l'accessibilité.

Performance

Ce n'est pas nouveau que nous entendons dire qu'il est extrêmement important d'effectuer des optimisations de performances dans les applications, et cela a généralement deux raisons principales :

• La performance peut être un facteur décisif pour que l'utilisateur finalise un achat , et le manque de performance sur un site peut entraîner la perte de clients potentiels ;
• Google considère le score de performance du site comme un critère de classement de recherche .

Il faut en moyenne 3 secondes à l'utilisateur pour renoncer à accéder à une page car elle n'est pas encore chargée . Mais imaginons un scénario dans lequel l'utilisateur est persistant et est prêt à passer "tout ce temps" à attendre : dès l'entrée du site, il aura déjà une mauvaise impression, éventuellement la lenteur provoquera une anxiété ou une irritation qui peut ( et probablement) influenceront le reste de l'expérience du site.

Internationalisation

L'internationalisation est une question d'accessibilité. En pratique, les deux techniques ont un objectif commun : faire en sorte que le contenu à l'écran soit compris par l'utilisateur .

Il s'agit d'un travail qui dépend beaucoup de l'application en cours de développement pour être considéré comme un « travail en arrière » ou un « travail en avant » (ou les deux), mais une chose est un fait : lorsque vous développez quelque chose conçu pour être multilingue, le travail doit être fait d'une internationalisation cohérente. Qui n'est jamais entré dans un site « traduit » en portugais, mais a remarqué plusieurs textes en anglais ? Oui, ne suivez pas cet exemple.

Oh! Cela semble être trop simple pour être même mentionné, mais il est très courant d'oublier dans la vie de tous les jours : utilisez l'attribut langen HTML, il est généralement utilisé dans l'élément racine de la page ( tag html) mais peut également être utilisé lorsqu'une partie spécifique de la page, il est dans une langue différente du reste du site. Cet attribut est très important pour que le navigateur identifie la langue utilisée sur la page et propose des traductions automatiques en fonction de la langue du navigateur de l'utilisateur.

apprendre les bases

Même si cela ne fait pas forcément partie de votre quotidien, il convient de savoir ce qu'est l'accessibilité et comment elle fonctionne dans le cadre d'une application Web/Mobile. Souvent, les développeurs backend génèrent des pages HTML, et lorsqu'ils le font, ces pages peuvent ne pas être structurées de la manière la plus conviviale possible.

Parlez à des collègues d'autres domaines

Si votre équipe a déjà une certaine maturité par rapport à l'accessibilité dans des domaines tels que le frontend et le design, discutez avec des personnes de ces domaines pour savoir comment ce travail est fait et comment vous pouvez les aider. Peut-être manque-t-il simplement un champ de description pour les alts d'image ou des informations supplémentaires dans les détails du produit, et oui, ces détails semblent si petits qu'ils sont insignifiants, mais avec d'autres améliorations, ils finissent par faire une grande différence.

Délai pour terminer les actions

Le temps ne doit pas être une limite qui empêche l'utilisateur de terminer une activité, c'est-à-dire si l'utilisateur a besoin de 5 minutes ou d'une heure pour soumettre un formulaire, qu'il en soit ainsi, l'application doit être préparée pour les deux scénarios.

Bien sûr, nous ne pouvons pas ignorer le fait qu'il existe plusieurs limitations techniques qui peuvent nous empêcher de fournir cela, mais il est toujours bon d'éviter ce type de problème qui ne générera que de la frustration pour l'utilisateur. De plus, comme l'explique le W3C , il existe quelques exceptions à cette règle :

• Événements en temps réel : il doit y avoir une limite de temps pour l'activité, comme une vente aux enchères en ligne.
• Activités où le temps est compté : le temps est compté, et augmenter la limite rendrait l'action invalide, comme une offre à durée limitée sur un site de commerce électronique.
• Limite de 20 heures : bien qu'il soit peu probable qu'une tâche prenne plus de 20 heures d'affilée, cela a été choisi comme limite par le W3C, après quoi une limite de temps est autorisée.

Comme le recommande le W3C , nous devons fournir un moyen d'indiquer la signification d'une abréviation lorsqu'elle est utilisée sur la page, afin d'aider les utilisateurs qui :

• avoir de la difficulté à déchiffrer ce que signifie un acronyme;
• se fier aux lecteurs d'écran ;
• avoir une mémoire limitée;
• ont de la difficulté à utiliser le contexte dans lequel il se situe pour comprendre le sens de l'acronyme.

réauthentification

Imaginez le scénario suivant :

Mon groupe préféré de tous les temps joue un concert près de chez moi et j'ai la rare chance de réaliser ce rêve de les voir. Sachant déjà que la concurrence pour garantir les billets sera grande, je laisse toutes mes inscriptions prêtes sur le site, attendant juste que les billets soient mis en vente. Quand les billets sont enfin disponibles, je garantis le mien, je tape les détails de ma carte et tout, mais… quand je vais finaliser l'achat, ma session plante. À ce moment-là, le désespoir frappe, je m'authentifie rapidement à nouveau et lorsque j'essaie de procéder à l'achat, je vois le triste message… billets épuisés .

Une « sorte de » situation ennuyeuse, non ? Donc c'est.

OK, c'est un problème, mais qu'est-ce que cela a à voir avec l'accessibilité ?

En effet, il ne s'agit pas d'un problème d'accessibilité exclusif , mais si cette situation provoque déjà une grande irritation pour les utilisateurs qui n'ont aucune limitation, imaginez pour ceux qui ne savent utiliser que la souris, ou dépendent d'un lecteur d'écran pour naviguer ?

C'est pourquoi il faut faire attention lorsque l'on met en place des flux qui nécessitent une authentification, l'utilisateur doit pouvoir continuer son activité sans perdre aucune donnée si sa session expire. Dans ce scénario de ticket, il existe des solutions qui atténuent le problème :

• Prolonger périodiquement le temps de session pendant que l'utilisateur est actif sur le site ;
• Réservez le ticket et enregistrez les données du formulaire au fur et à mesure que l'utilisateur les saisit, au cas où il ne serait pas en mesure de terminer le remplissage pour une raison quelconque et souhaiterait continuer plus tard ;
• Fournir une option pour se réauthentifier sans quitter la page actuelle et continuer le flux après la réauthentification.

Dans les scénarios où vous pouvez effectuer une recherche par texte pour trouver du contenu, il est intéressant d'avoir un mécanisme qui suggère du contenu avec des noms similaires, au cas où le système soupçonne qu'il y a une erreur d'orthographe dans la recherche. De cette manière, nous évitons à l'utilisateur d'avoir à effectuer une deuxième recherche, en corrigeant son erreur et en trouvant ensuite ce qu'il veut.

Comme pour beaucoup de choses en matière d'accessibilité, la correction orthographique aide tous les types d'utilisateurs, mais en particulier les personnes peu scolarisées et les personnes souffrant de troubles cognitifs comme la dyslexie.

Final

D'accord, mais que se passe-t-il si aucun de ces conseils ne s'applique à mon backend quotidien ? Dois-je encore avoir des connaissances en accessibilité ?

Eh bien, puisque le domaine de la technologie est de plus en plus populaire et inclusif, et que l'entrée de nouvelles personnes (y compris les PCD) augmente, une connaissance de base du sujet peut aider non seulement les développeurs backend, mais tout le monde dans l'équipe , donc nous pouvons comprendre les besoins non seulement des utilisateurs pour lesquels nous développons les systèmes, mais aussi des collègues éventuels qui pourraient avoir de tels besoins.

Il convient même de mentionner que non seulement les personnes qui travaillent avec le frontend, le backend, la conception et l'assurance qualité sont responsables de l'accessibilité, mais que toute personne qui passe par n'importe quelle étape de la conception d'un logiciel peut y contribuer.

Les références

• Oui, l'accessibilité est également une préoccupation principale (Eric Bailey)
• Timing Adjustable — Limites de temps des comportements requis (W3C)
• Abréviations (W3C)