Pour pallier ces erreurs, les claviers logiciels existants proposent trois mécanismes de correction.
1.2.1 Correction manuelle
Cette première correction est classique ; elle nécessite l’utilisation d’un curseur pour se positionner à l’endroit de l’erreur. Lorsque l’utilisateur souhaite corriger sa saisie, il peut appuyer sur l’endroit précis de son erreur, et corriger ses erreurs en insé-rant ou supprimant des caractères. Cette méthode est extrêmement difficile à utiliser pour un utilisateur en situation de déficience visuelle. En effet, les non-voyants n’uti-lisent pas de système de pointage. Par conséquent, ils ne vont pas pouvoir positionner directement le curseur à l’endroit de la correction à effectuer. Pour y parvenir, ils doivent utiliser les touches du clavier comme la touche retour arrière ou les touches directionnelles pour déplacer avec précision le curseur jusqu’à l’erreur. L’utilisation de ces touches peut s’avérer très coûteuse en temps si la correction à effectuer est située loin du curseur actuel. De plus, une fois la correction effectuée, il faudra repo-sitionner le curseur au bon endroit pour pouvoir continuer la saisie.
1.2.2 Correction automatique
Une autre méthode possible est la correction automatique une fois le mot fini. Pour cela, le système analyse la saisie de l’utilisateur et la corrige si nécessaire en remplaçant le mot tapé par le mot le plus proche dans le dictionnaire de correction. Ce mot est brièvement affiché à l’utilisateur lors de sa saisie (voir figure 12).
Cette méthode est jugée difficile, et souvent source d’erreurs de saisie par de nom-breux utilisateurs voyants [Madison, 2012]. La correction automatique est utilisable, mais elle pose souvent des difficultés car la correction est effectuée de manière im-plicite, sans demander de confirmation à l’utilisateur. Si la correction effectuée ne convient pas à l’utilisateur, il doit alors lui-même revenir dessus pour la corriger et perd à nouveau du temps.
Figure 12 – Utilisation de la correction automatique
Une autre solution consiste à proposer à l’utilisateur le mot, ou une liste de mots, par lequel il souhaiterait remplacer sa saisie. Cette phase de validation peut soit être proposée automatiquement à l’utilisateur en fin de mot et donc celui-ci est obligé de la prendre en compte ; soit être proposée sur un composant à côté du clavier et l’utilisateur peut consulter les propositions s’il le souhaite. Dans tous les cas, cela demande une interaction et un retour vocal supplémentaires pour valider ou non la correction proposée, l’utilisateur est alors freiné dans sa saisie pour chaque mot jugé incorrect par le système.
Cette solution permet ainsi de réduire les erreurs en proposant à l’utilisateur de les corriger à chaque fin de mot. En revanche, cette étape supplémentaire vient encore réduire la vitesse de saisie de texte ; car elle oblige l’utilisateur à effectuer des actions supplémentaires, alors qu’il s’était déjà appliqué à saisir chaque caractère de son mot.
1.2.3 Système de prédiction
Pour permettre à l’utilisateur d’anticiper la saisie complète de son mot, les claviers logiciels sur mobile présentent généralement une liste de prédiction à l’utilisateur. Cette liste est souvent affichée juste au-dessus du clavier (voir figure 13). L’utilisateur peut alors sélectionner le mot désiré, dès que celui-ci apparaît dans la liste, et ainsi éviter de saisir l’ensemble de la chaîne de caractères. Les systèmes de prédiction ont
aussi l’avantage de proposer des mots correctement orthographiés : c’est-à-dire que même si l’utilisateur a réalisé une faute de frappe, le système de prédiction peut lui proposer des mots fréquents proches de ce qu’il a saisi. L’utilisateur peut donc être un peu moins précis dans sa saisie et la corriger rapidement grâce à cette liste de mots.
Figure 13 – Utilisation de listes de prédiction
Cependant, cette liste représente un focus d’attention supplémentaire, et détourne le regard de l’utilisateur de sa saisie. Sa vitesse de saisie peut alors s’en retrouver diminuée si celui-ci ne trouve pas le mot qu’il recherche dans la liste. Pour des utilisateurs voyants, l’affichage de la liste de mots n’est pas trop pénalisante car ils peuvent y jeter un regard en continuant de saisir leur mot sans trop ralentir leur vitesse de saisie.
Dans le cas des utilisateurs non-voyants, le problème est différent : pour que l’uti-lisateur prenne connaissance des mots qui lui sont proposés, il faut que ces derniers soient oralisés. Or, la liste de mots change après chaque caractère saisi. Par consé-quent, oraliser chaque mot de la liste serait beaucoup trop perturbant au cours de la saisie de l’utilisateur. Le système annonce déjà par synthèse vocale les caractères survolés par l’utilisateur au moment de sa recherche d’un caractère sur le clavier. Les deux retours auditifs ne pourraient donc pas être faits en parallèle : il n’est donc pas possible de présenter la liste de mots pendant la saisie d’un mot.
il le souhaite. Cela nécessiterait que l’utilisateur interrompe sa saisie pour parcourir la liste avec le doigt et prenne connaissance des mots qui s’y trouvent. Si le mot recherché ne se trouve pas dans la liste, l’utilisateur retournera alors continuer sa saisie sur le clavier. Faire plusieurs allers/retours entre la liste et le clavier pendant la saisie d’un mot hacherait trop sa saisie et la vitesse de saisie en serait grandement réduite.
Cette solution à base de liste de mots au cours de la saisie n’est donc pas envisa-geable dans le cas d’un clavier optimisé pour des déficients visuels.
En résumé, bien que la correction soit souvent nécessaire pour corriger les fautes de frappes de l’utilisateur, cette phase de correction ou prédiction est coûteuse en temps pour les utilisateurs, et plus particulièrement pour les utilisateurs non-voyants.