Accessibilité… sur le backend ?

Você pode ler esse artigo em português aqui.

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 ou des concepteurs frontaux. Bien qu'une grande partie du travail porte effectivement sur ces domaines, les développeurs backend ne sont pas écartés du sujet.

Mais moi, en tant que backend, je ne développe aucune mise en page d'écran, j'écris à peine quelques lignes de HTML de temps en temps, comment dans ce scénario pourrais-je aider avec quoi que ce soit ?

Eh bien, il y a toujours un moyen. Dans cet article, j'apporte quelques idées de choses que les backend peuvent faire dans le domaine de l'accessibilité.

Performance

Nous entendons depuis longtemps qu'il est extrêmement important d'optimiser les performances de nos applications, et cela a généralement deux raisons principales :

• Les performances peuvent être un facteur clé pour que l'utilisateur finalise un achat , et le manque de performances sur un site Web peut entraîner la perte de clients potentiels ;
• Google a le score de performance comme facteur de classement dans son moteur de recherche .

Il faut en moyenne 3 secondes à l'utilisateur pour renoncer à accéder à une page car elle ne s'est pas encore chargée . Mais imaginons un scénario où l'utilisateur est persistant et veut passer "tout ce temps" à attendre : dès le début du flux, il aura déjà une mauvaise impression, et cette lenteur peut provoquer une anxiété ou une colère qui peut (et probablement ) influencent l'ensemble de l'expérience utilisateur.

Internationalisation

L'internationalisation a tout à voir avec l'accessibilité. En pratique, les deux techniques ont un objectif commun : rendre le contenu à l'écran compréhensible pour l'utilisateur .

C'est un travail qui varie d'un système à l'autre pour être considéré comme un « travail backend » ou un « travail frontend » (ou les deux), mais c'est un fait : quand quelque chose qui est conçu pour être multilingue est en cours de développement, un travail d'internationalisation cohérent doit être fait. Vous êtes-vous déjà inscrit sur un site Web « traduit » en anglais, mais avez remarqué plusieurs textes dans une autre langue ? Oui, ne suivez pas cet exemple.

Oh! Cela peut sembler si simple qu'il n'est même pas nécessaire de le mentionner, mais il est parfois assez facile d'oublier : utilisez l' langattribut dans votre HTML, cet attribut est généralement utilisé dans l'élément racine de la page ( htmlbalise) mais peut également être utilisé lorsqu'une partie spécifique de la page est dans une langue différente du reste du site Web. Cet attribut est très important pour que le navigateur identifie la langue utilisée par la page et propose des traductions automatiques en fonction de la langue de l'utilisateur.

Apprenez les bases

Même si cela ne fait pas forcément partie de votre travail quotidien, il est recommandé de savoir ce qu'est l'accessibilité et comment cela fonctionne dans un contexte d'application Web/Mobile. Souvent, les utilisateurs du backend écrivent quelques lignes de HTML, et lorsque cela se produit, les pages générées peuvent ne pas être structurées de la manière la plus accessible possible.

Parlez à des gens d'autres régions

Si votre équipe a déjà une certaine maturité en matière d'accessibilité dans des domaines tels que le frontend et le design, parlez aux personnes de ces domaines pour savoir comment ce travail est effectué et comment vous pouvez les aider. Il s'agit peut-être simplement d'ajouter un champ de description d'image à utiliser sur une image alt ou des informations supplémentaires dans les détails de votre produit, et oui, ces détails peuvent sembler si petits qu'ils peuvent sembler insignifiants, mais avec d'autres améliorations, ils finissent par faire un gros différence.

Limiter le temps 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 que plusieurs limitations techniques peuvent nous empêcher de fournir cela, mais il est toujours bon d'éviter ce genre de problème qui ne fera que frustrer 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é, par exemple dans une vente aux enchères en ligne.
• Activités où le temps est essentiel : le temps est un facteur essentiel, et augmenter le temps limite rendrait l'action invalide, par exemple dans une offre disponible pour un temps limité dans une boutique en ligne.
• Limite de 20 heures : bien qu'il soit peu probable qu'une tâche prenne plus de 20 heures d'affilée pour être accomplie, 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 mettre à disposition un moyen d'afficher la signification d'une abréviation lorsqu'elle est utilisée sur une page, pour aider les utilisateurs qui :

• avoir de la difficulté à interpréter ce que signifie un acronyme;
• dépend des lecteurs d'écran ;
• avoir une mémoire limitée;
• ont de la difficulté à utiliser le contexte où ils se trouvent pour comprendre le sens de l'acronyme.

Réauthentification

Imaginez le scénario suivant :

Mon groupe préféré de tous les temps va être proche de chez moi et j'ai la rare chance de réaliser ce rêve de les voir. Sachant que la compétition pour obtenir des places sera grande, je crée mon compte sur le site et j'attends juste que les places soient disponibles. Quand enfin ce moment arrive, je reçois mon ticket, je tape le numéro de carte de crédit et tout, mais… juste au moment où je clique pour terminer l'achat, je me déconnecte. À ce moment, je suis désespéré : j'essaie rapidement de me reconnecter, et lorsque j'essaie de procéder à l'achat, je vois le triste message… les billets sont épuisés.

Pas cool, non ? Ouais.

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

En effet, ce n'est pas un problème uniquement d'accessibilité, mais si cette situation frustre les utilisateurs qui n'ont aucune limitation, pouvez-vous imaginer ce qu'il en est pour ceux qui ne savent utiliser que la souris ou dépendent d'un lecteur d'écran pour naviguer ?

C'est pourquoi nous devons être prudents lorsque nous implémentons des flux nécessitant une authentification, l'utilisateur doit pouvoir continuer l'activité sans perdre de données en cas d'expiration de la session. Dans ce scénario de ticket, il existe des solutions qui atténuent le problème :

• Prolonger périodiquement la durée de la 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 tape, au cas où il ne pourrait pas finir de remplir pour une raison quelconque et voudrait 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 cas où il est possible de faire des recherches par texte pour trouver du contenu, il est intéressant d'avoir un mécanisme qui suggère des contenus avec des noms similaires, au cas où le système soupçonne que l'utilisateur a mal orthographié un mot dans la recherche. De cette façon, nous évitons à l'utilisateur d'avoir à effectuer une deuxième recherche, en corrigeant l'erreur et en trouvant ensuite ce qu'il veut.

Comme pour beaucoup de choses en matière d'accessibilité, la vérification orthographique aide tous les types d'utilisateurs, mais en particulier les personnes ayant un faible niveau d'éducation et les personnes souffrant de troubles cognitifs tels que la dyslexie.

Emballer

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

Eh bien, puisque le domaine de la technologie devient de plus en plus populaire et inclusif, et que l'entrée de nouvelles personnes (y compris les personnes handicapées) augmente également, une connaissance de base du sujet peut aider non seulement les personnes backend, mais tout le monde dans une équipe, de cette façon 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 également de noter que l'accessibilité n'est pas uniquement la responsabilité des personnes qui travaillent avec le frontend, le backend, la conception et l'assurance qualité, mais toute personne qui passe par n'importe quelle étape de la conception du 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)