Le fonctionnel, l’ergonomie et l’accessibilité

Quand arrive la recette d’un projet avec des exigences d’accessibilité, on entend bien souvent qu’il y a trop de correctifs à apporter à cause de celles-ci. Pourtant, si on trie les anomalies pour déterminer si elles relèvent du fonctionnel, de l’ergo ou de l’accessibilité, on se rend compte que tout ne vient pas de l’exigence d’accessibilité !

Il faut en général préparer le terrain pour travailler sur la qualité. Déterminer la nature d’un bug front-end est donc essentiel pour le chef de projet car cette distinction va lui permettre de prioriser et alerter suffisamment tôt ses équipes dans la période de recette et reléguer à plus tard certains bugs purement cosmétiques.
Avec au moins 3 exemples, on va s’efforcer de différencier ces types de bugs front-end.

Le bug fonctionnel

Sur un site web, il peut être d’au moins 3 natures statiques : HTML, CSS ou JavaScript.
Plus indirectement, le bug peut également provenir du serveur, de sa configuration ou de scripts côté serveur mais ici on va parler de phénomènes qui se jouent dans le navigateur et qui relèvent de l’intégrateur.

J’ai choisi ce cas très simple d’une popin qui a un bug JavaScript. Vous ouvrez la popin, pas de souci, puis vous essayez de la refermer un cliquant sur le bouton fermer, il ne se passe rien. C’est clair, c’est un bug fonctionnel. Est-ce un bug d’accessibilité ? Non, on ne peut même pas s’y intéresser vu que la fonctionnalité n’est pas opérationnelle. Ce genre de bug fonctionnel entrave donc la phase de correction de l’accessibilité.

Le bug ergonomique

Là aussi j’ai délibérément choisi un exemple très simple. Vous connaissez sans doute la loi de Fitts ? Dans les interfaces en responsive web design (RWD), cette règle est bien souvent oubliée. Si vous êtes chef de projet, combien de fois avez-vous demandé à votre DA ou votre intégrateur d’agrandir ces boutons de menu ou de validation ?

Dans le cas présenté, c’est simple, les liens de bas de page sont tellement petits et tellement proches du bas de l’écran du smartphone qu’ils sont presque systématiquement confondus avec les boutons contextuels du navigateur.
Alors oui, avec un stylet, ou en pinçant l’écran pour zoomer (ici cette fonctionnalité est bloquée…), vous pourrez y arriver sans vous y prendre à 3 fois, donc ce n’est pas un bug fonctionnel mais bien un bug ergonomique.
Et l’accessibilité ? Bien que le confort ne soit pas vraiment au rendez-vous, l’accessibilité n’est pas impactée ici. L’expert accessibilité relèvera le défaut, pour que le site soit plus facile à utiliser, mais ce n’est pas un correctif de mise en accessibilité.

Le bug accessibilité

Ici, j’ai choisi un bug d’accessibilité vraiment bloquant et pourtant assez fréquent. Il s’agit de la page d’accueil d’une startup très connue de location saisonnière avec un formulaire permettant d’effectuer une recherche d’offres pour la destination et les dates de séjour prévues.

Sur Firefox, vous parcourez le formulaire au clavier, la destination reçoit bien le focus, on peut saisir puis sortir du champ, ensuite vient la date d’arrivée qui reçoit bien le focus également mais si vous saisissez une date ou rien, le gros problème c’est que vous ne pouvez plus du tout sortir de ce champ (les touches Echap, Tab ou Maj tab ne vous y aideront pas).
C’est ce qu’on appelle communément un piège au clavier. Bug qui stoppe l’utilisateur du clavier, il est présenté dans un critère de niveau simple A (ou bronze).
A mon sens, ce critère est déterminant pour fournir un début d’accessibilité !

Un autre pour la route

Un bug beaucoup plus visuel qu’on pourra mettre en évidence sur beaucoup de sites peu flexibles qu’ils soient en RWD ou classiques : le zoom texte qui rend le contenu illisible.

Ici c’est un critère de niveau double A qui est invalidé.
Optimiste de nature, je croyais que le responsive web design allait rendre les sites plus résistant au zoom texte, c’était sans compter la mode des sites en structure « une seule page qui se scrolle pour tout le contenu » avec des sous-pages justifiées en hauteur et en largeur (un peu comme des slides Powerpoint) ce qui ne donne généralement aucun espoir aux débordements de textes et au zoom texte jusqu’à 200%. De plus le hack du scroll proposé par des scripts comme fullPage.js n’est jamais fiable à 100% et encore moins dans des situations où le texte a besoin d’être agrandi.

Et puis il y a les problèmes d’affichage

Les bugs qui échappent parfois aux tests du développeur parce-qu’il n’a pas testé telle ou telle combinaison de configuration matérielle, logicielle ou connexion. Comme j’en parlais dans les ratés du RWD à ses débuts, bien souvent, un site trop lourd avec des JavaScript chargés en fin de fichier HTML, le tout consulté sur un smartphone en connexion de 2G ou 3G c’est parfois complètement dégradé ou inutilisable à l’écran.

Plus facile à reproduire, il s’agit du bug de la résolution d’écran oubliée. Certains éléments, placés en position absolue, viennent cacher du texte partiellement mais parfois suffisamment pour créer des problèmes d’ergonomie et d’accessibilité. C’est le même problème que celui observé avec le zoom texte en accessibilité sauf que là, le bug apparaît avec les réglages par défaut de l’interface : taille de texte à 100% et options d’usine.

Exemple d’un bouton qui cache partiellement 2 liens en bas de page sur un smartphone de 3.5 pouces.

Exemple d’un bouton qui cache quelques mots sur une tablette 7 pouces.

Dans les 2 cas, ces bugs posent des problèmes d’ergo et d’accessibilité mais on est bien d’accord que dans le cadre d’une recette sans contrainte d’accessibilité on demanderait une correction de ces bugs d’affichage.

On n’a pas parlé des bugs esthétiques, ceux qui feront sursauter le client avant tout le reste mais qui n’ont pas d’impact ni sur le fonctionnel  ni sur l’accès ou l’utilisation d’un service en ligne.

Mon conseil

Testez un maximum de configurations matérielles et logicielles et traitez les bugs dans le bon ordre pour ne rien négliger :

  1. Commencez par corriger les bugs fonctionnels et ergonomiques qui ont un impact sur des critères d’accessibilité.
  2. Continuez avec les correctifs pour l’accessibilité.
  3. Terminez par les bugs cosmétiques, ainsi, à la résolution de ces correctifs, le client peu familier à l’accessibilité, pourra mesurer  visuellement si son site est prêt pour la production !

Pour conclure, tant mieux si les référentiels d’accessibilité web vous permettent de corriger des bugs fonctionnels et ergonomiques. Pensez à demander du temps supplémentaire dans la recette si vous voulez aller au delà de ce que le client et vos collègues testent.

Vous  n’avez plus d’excuses pour vous arrêter en si bon chemin et ainsi poursuivre sur les correctifs pour améliorer l’accessibilité !

Laisser un commentaire

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