Publications

Réflexions et retours d'expérience.

Acces­si­bi­lité et compor­te­ments utili­sa­teurs.

4min de lecture

Il y a au moins autant de compor­te­ments que de contextes diffé­rents d’une inté­rac­tion. Ces usages sont liées à des carac­té­ris­tiques propres aux utili­sa­teurs et de leur envi­ron­ne­ment. C’est d’ailleurs cette notion qui nous permet de déter­mi­ner socia­le­ment les carac­té­ris­tiques distinc­tives des commu­nau­tés. Mais au delà de ça, ce sont ces carac­té­ris­tiques propres à des typo­lo­gies d’uti­li­sa­teurs que nous devons la diffé­rence de compor­te­ments d’un indi­vidu à l’autre.


Le « contexte », est mot phare et fourre-tout auquel nous devons la grande majo­rité de nos expli­ca­tions (c’est le prin­cipe de vulga­ri­sa­tion). Inté­res­sons nous donc plutôt à deux notions plus précises que sont « l’en­vi­ron­ne­ment » et "les carac­té­ris­tiques person­nelles". L’uti­li­sa­teur réalise des tâches en fonc­tion de chacune de ces deux notions, et le compor­te­ment en dépend forte­ment.

Prenons un exemple : Une personne assis­tée par un lecteur d’écran aura une inté­rac­tion diffé­rente qu’une personne voyante (c’est une carac­té­ris­tique physique); Et une autre personne navi­guant sur un dispo­si­tif à taille réduite inté­rar­gira diffé­re­ment d’une personne sur un grand écran (c’est l’en­vi­ron­ne­ment). De même les inter­faces homme-machine apportent leurs lots de diffé­rences (ex: le clavier et la souris, les écrans tactiles, etc) entrai­nant des compor­te­ments diffé­rents.

Détaillons quelques peu notre compa­rai­son entre les utili­sa­teurs atteints de cécité et les autres. Inté­res­sons-nous par exemple à la gestion des erreurs d’un formu­laire sur une inter­face quel­conque.

Le modèle acces­sible

Il est bien évidem­ment possible de conce­voir des inter­faces faci­li­tant le proces­sus de compré­hen­sion des erreurs à desti­na­tion des assis­tants de lecture. Par exemple en propo­sant au lecteur une liste des erreurs engen­drées en amont du formu­laire.

Formulaire incluant uniquement une liste d'erreurs au début du formulaire.

Cette infor­ma­tion permet notam­ment à l’uti­li­sa­teur d’iden­ti­fier les champs néces­si­tant une correc­tion. Il est par ailleurs possible de lui propo­ser des méca­nismes d’ac­cès rapide à chacun des champs ayant généré une erreur.

Problème réglé ?!

Pas tout à fait …

Là où un utili­sa­teur atteint de cécité dispo­sera effec­ti­ve­ment d’une assis­tance dans la réali­sa­tion de sa tâche, l’uti­li­sa­teur voyant se verra affecté par ces allers-retours visuels entre la liste des erreurs et les champs à modi­fier. Le taux d’er­reurs d’iden­ti­fi­ca­tion des champs affec­tés sera pour lui d’au­tant plus impor­tant qu’il y aura de champs.

On pour­rait égale­ment analy­ser cette situa­tion à un utili­sa­teur voyant sur un dispo­si­tif à taille réduite (coucou l’en­vi­ron­ne­ment!). Au délà du problème énnoncé ci-dessus, l’ac­cès à la réfé­rence des erreurs néces­si­tera de nouvelles inté­rac­tions, augmen­tant le taux d’er­reurs et la frus­tra­tion pouvant être engen­drée.

Conclu­sion : Ce modèle génère un compor­te­ment peu accep­table pour des groupes d’uti­li­sa­teurs.

Le modèle visuel

Disons ce qui est, la propor­tion d’uti­li­sa­teurs voyants est bien plus impor­tante que celle d’uti­li­sa­teurs non voyants. Par consé­quent, la consi­dé­ra­tion de certains utili­sa­teurs passe à la trappe. À qui la faute ? Je vous le demande !

Il est par consé­quent bien plus perfor­mant d’as­so­cier chaque erreur à son champs, faci­li­tant ainsi le trai­te­ment de la percep­tion visuelle.

Formulaire inaccessible incluant uniquement les erreurs champs par champs.

Sur ce type de modèle, l’as­so­cia­tion de l’er­reur à sa source demande beau­coup moins d’ef­forts à l’uti­li­sa­teur. Sauf que, le compor­te­ment d’un lecteur d’écran (et par exten­sion son utili­sa­teur) est diffé­rent.

Là où le modèle précendent appor­tait un accès plus direct aux infor­ma­tions inté­res­sentes pour l’uti­li­sa­teur, il est ici contraint de consul­ter un nombre d’in­for­ma­tions volu­mi­neux avant d’at­teindre les infor­ma­tions qui lui sont inté­res­santes.

Détail de la lecture d'un champs : légende, champ (type, ect), puis erreur

D’autre part, là où un utili­sa­teur voyant traite des groupes d’in­for­ma­tions (champs-erreur), l’uti­li­sa­teur assisté par un logi­ciel se voit contraint de consul­ter l’en­semble des infor­ma­tions dans l’ordre d’ap­pa­ri­tion hiérar­chique.

En résumé, l’uti­li­sa­teur se retrouve à lire :

  1. le nom du champs,
  2. le champs lui-même et ses infor­ma­tions asso­ciées (type, valeur rensei­gnée, …),
  3. puis fina­le­ment l’er­reur (pour peu qu’il y en ait une)

Et le tout est multi­plié par le nombre de champs.

Conclu­sion : c’est un modèle « pain in the ass » (comme disent nos amis anglo­phones) pour un autre grou­pe­ment d’uti­li­sa­teurs.

Un modèle acces­sible et utili­sable

Heureu­se­ment, nous avons la chance de pouvoir appliquer les deux modèles précé­dem­ment énnon­cés sur une même inter­face. De plus, ces deux modèles sont complé­men­taires et aussi béné­fiques pour un grou­pe­ment d’uti­li­sa­teurs que pour l’autre.

Erreurs accessibles incluant la liste des erreurs dans un premier temps, puis les erreurs à chaque champs.

Quelques soient les carac­té­ris­tiques de l’uti­li­sa­teur, l’ac­cès à des raccour­cis vers des champs ou l’as­so­cia­tion renfor­cée de l’er­reur à son champs sont des assis­tants permet­tant de faci­li­ter l’ana­lyse et l’in­té­rac­tion avec l’écran en présence.

Morale de l’his­toire

Prendre en compte l’uti­li­sa­teur dans la concep­tion d’une inter­face, c’est prendre en compte ses carac­té­ris­tiques et son envi­ron­ne­ment. Par consé­quent, l’ac­ces­si­bi­lité est une notion détour­née de la prise en compte des carac­té­ris­tiques des utili­sa­teurs.

Cepen­dant, pour finir sur une note d’ac­ces­si­bi­lité, il faut recon­naître que l’at­ten­tion portée à ces compor­te­ments est moindre. Et pour cause, « seule » 1,7 million de personnes (en France) seraient atteintes d’un handi­cap visuel. Chiffre duquel on ne conserve que les utili­sa­teurs d’in­ter­faces virtuelles (envi­ron 1%). Et le tout sera par ailleurs noyée dans les statis­tiques géné­ra­listes.

Bref ! La prise en compte des carac­té­ris­tiques et de l’en­vi­ron­ne­ment des utili­sa­teurs n’en est qu’à ses débuts.

Mise à jour du 18/05/2016 : Theme­sis (l’édi­teur de la conven­tion Opquast) vient de publier une confir­ma­tion de néces­sité de prise en compte du contexte utili­sa­teur évoquée dans cet article.

Sébastien ALEXANDRE