Appel à l'action, ce qu'ils sont et quelle est leur importance.

Les appels à l'action sont des invitations à passer à l'action. En conception Web et surtout, dans le domaine de l'utilisabilité, les Call to Actions sont des éléments précisément distinguables qui sollicitent l'internaute à effectuer une action. De toute évidence, ces éléments, dans les interfaces Web, rien qu'en pensant au concept d'utilisabilité, deviennent d'une importance énorme et doivent être considérés avec une extrême précision.

Normalement, les Call To Actions, dans les interfaces web, prennent l'apparence de boutons actifs, qui, une fois cliqués, renvoient l'internaute pour conclure une action bien définie (un paiement, la saisie de données dans un formulaire, une procédure d'achat, etc... )

Compte tenu de la délicatesse de la question, il existe des règles précises pour que les Call To Actions soient réussis et optimaux. Quelques suggestions très intéressantes sont données par le site MAGAZINE ÉCRASANT, qui donne une illustration assez large et détaillée avec des exemples réels.

Par conséquent, pour tous les concepteurs de sites Web, qu'ils soient experts ou non, il est très important d'évaluer les aspects qui peuvent influencer positivement ou négativement une Cll To Action. Et donc, finissons de parler à nouveau d'accessibilité et de convivialité. Termes qui tombent dans l'oubli ces derniers temps et je ne comprends pas pourquoi.

Le (bon) copywriting pour sites web et réseaux sociaux

Le Call To Action ne s'arrête cependant pas qu'à l'aspect graphique :

étant un élément important du marketing persuasif, il est clair qu'il devra également être évalué en termes de contenu. C'est-à-dire ce qu'il y a derrière un Call to Action et pourquoi le navigateur doit cliquer là et pas ailleurs.

Le Call To Action est un véritable appel à l'action, cette action que vous devez induire ou que vous souhaitez qu'elle soit réalisée et qui s'inscrit dans le cadre de communication persuasive car une fois que l'utilisateur est arrivé sur notre site, il ne faut pas le laisser partir, au contraire, il faut même le convaincre de faire quelque chose qui peut devenir un avantage pour les deux, c'est-à-dire pour nous et pour l'utilisateur. Je suis d'avis, en effet, avouons-le, j'en suis sûr, que 10.000 99 visites quotidiennes avec un taux de rebond de 500% sont moins utiles que 10 avec un taux de rebond de 5% et un taux de conversion de 10 voire XNUMX% .

Nous sommes bien conscients que la performance d'un site en termes de nombre de visiteurs et de taux de rebond dépend aussi du type de site mais il est également vrai qu'un site web d'entreprise est fait pour "faire des affaires" et de ne pas peigner les poupées et donc il est indispensable que le visiteur reste "chez nous" ou plutôt sur le site plus de 30 secondes, réalisant des actions que nous avons tenté de lui faire réaliser. Sinon, de quoi parle-t-on ?

Par exemple, dans le cas des sites d'entreprise, il est très important créer un contact avec le visiteur, dans le cas des sites de commerce électronique, il est nécessaire vendez des produits, dans le cas des sites d'information il faut catalyser l'attention éventuellement demander un commentaire final ; il y a aussi l'éventualité de ne vouloir que faire des marques, et cela peut prendre beaucoup moins de temps, mais c'est une autre histoire.

La appel à l'action fait partie intégrante de rédaction persuasive: il faut balayer tous les doutes du client potentiel pour le pousser à l'action. Je ne dis pas pour le tromper, attention, mais pour pouvoir lui faire comprendre la vraie valeur du produit (ou service) que vous vendez et surtout le besoin réel, parfois inexprimé.

L'accessibilité des appels à l'action est étroitement liée à deux aspects : la sémantique des étiquettes utilisées pour identifier une action et la manière dont cette action est réalisée.

La sémantique des appels à l'action doit être explicite. Un bouton, un lien, doit avoir une étiquette qui identifie exactement l'action que l'utilisateur va effectuer. J'ai récemment vu les changements apportés par certains réseaux sociaux et CMS dans l'appel à l'action des téléchargements d'images : en gros, nous avons maintenant deux boutons qui indiquent "Sélectionner l'image". Incroyablement, il manque un bouton qui dit "Télécharger des photos". Cela crée une confusion pour les utilisateurs, sachant également que toute personne qui surfe avec un lecteur d'écran a une vision seriale de la page, c'est-à-dire qu'il lui manque le regard global typique des utilisateurs qui naviguent avec un navigateur visuel.

Les étiquettes vagues doivent être évitées, générique ou peu clair. Une étiquette à éviter est "Cliquez ici". Si vous naviguez sur une page qui comporte des appels à l'action avec un tel étiquetage avec un lecteur d'écran, vous entendrez une série interminable de "(lien) Cliquez ici" qui ne vous donneront aucune information utile sur la nature de l'action que vous allez effectuer Activer.

Une autre chose à éviter est l'abus d'attributs title quelques liens. Lorsqu'il est utilisé discrètement, cet attribut peut fournir des informations contextuelles précieuses sur l'action à effectuer, mais lorsqu'il est surutilisé, il transforme la navigation dans les pages en une épreuve. En effet, les lecteurs d'écran associent chaque lien à son propre titre et le lisent avant le contenu de l'élément.

D'un point de vue graphique, et en gardant à l'esprit les besoins des utilisateurs malvoyants, les éléments qui rappellent une action doivent être clairement visibles et en relief, avec des polices suffisamment grandes pour permettre une lecture facile. Plus important encore, certains ajustements au niveau CSS doivent être utilisés pour permettre à ces éléments de s'adapter aux changements de taille de police qu'un utilisateur malvoyant peut apporter à la page. Enfin et surtout, ils doivent avoir un contraste de couleur adéquat entre le texte et l'arrière-plan, afin d'éviter les problèmes avec les daltoniens.

nginx : un nouveau serveur web

JavaScript et son utilisation correcte

En ce qui concerne la manière dont ces actions sont déclenchées, nous devons penser à JavaScript.

Rappelons que JavaScript et accessibilité ne sont pas incompatibles, tant que vous respectez quelques bonnes pratiques simples. L'un d'eux concerne les liens et comment les garder accessibles même avec JavaScript désactivé ou non pris en charge. En ce sens, il faut distinguer les liens effectifs (qui conduisent l'utilisateur vers une nouvelle page ou qui en tout cas renvoient vers des ressources) et les liens déclencheurs, c'est-à-dire les liens sans contenu proprement dit mais qui servent à "déclencher" des actions JavaScript.

Une pratique à éviter est celui des liens sans valeur pour l'attribut hrefcomme <a href="" id="trigger" >...</a>. Dans les navigateurs sans prise en charge de JavaScript tels que Lynx, un tel lien entraînera le rechargement complet de la page. Bien sûr, nous pouvons entièrement générer le déclencheur avec JavaScript, mais le lien ne sera pas disponible si JavaScript n'est pas pris en charge ou désactivé. De nombreux sites statiques utilisent également cette technique pour générer des liens permanents, car le navigateur considérera la page actuelle comme la valeur d'attribut manquante href.

Il est donc nécessaire de donner une valeur à cet attribut, compte tenu également du fait que pour les spécifications XHTML l'attribut href Il ne peut pas être vide. Mais lequel? Beaucoup ont choisi d'utiliser le caractère dièse (#) comme remplissage. Cependant, même cette solution a des limites, car avec JavaScript désactivé ou non pris en charge, nous aurons pour effet de créer une référence à une ancre inexistante, ce qui peut désorienter ceux qui surfent sur le Web avec une technologie d'assistance non visuelle.

La solution, bien sûr, se situe quelque part entre les deux : nous pouvons en fait créer une ancre qui pointe vers le contenu réel de la page. Dans le cas d'un contenu généré via JavaScript, nous pouvons utiliser une approche comme celle-ci :

Aide L'e-mail doit être au format nom d'utilisateur@domaine.extension

Stylisons notre div, que nous cacherons avec JavaScript. Si JavaScript n'est pas supporté ou désactivé, notre div restera simplement visible. Pour le masquer, utilisons une classe CSS pour créer un lien lorsque le document est chargé :

.caché { position : absolu ; haut : -1000em ; }

jQuery et Prototype ont tous deux des méthodes pour masquer un élément, mais rappelez-vous qu'ils utilisent la déclaration display: none. Cette déclaration est malheureusement interprétée par les lecteurs d'écran, qui supportent partiellement JavaScript, les empêchant de lire le contenu d'un élément. À ce stade, si nous utilisons jQuery, nous pouvons écrire :

$('#trigger').click(function() { $('#email-help').removeClass('hidden'); });

J'ai délibérément évité d'insérer la déclaration return false; car certains lecteurs d'écran sont capables d'interpréter un événement click, ce qui l'assimile à un événement clavier dans certains cas. Si j'avais inséré une telle déclaration, de tels programmes n'auraient pas suivi la destination du lien et n'auraient donc pas pu lire le contenu de notre div. Le seul effet désagréable pour les navigateurs normaux est de voir l'ancre ajoutée à l'URL de la page en cours, mais cela n'affecte en rien son accessibilité et sa convivialité.

Moyennant les adaptations appropriées, les mêmes observations s'appliquent également aux boutons, compte tenu évidemment des différences dans la casuistique des événements JavaScript disponibles.

Le premier principe d'utilisabilité qui s'applique aux appels à l'action est leidentifiabilité. Un appel à l'action doit toujours être immédiatement reconnaissable par l'utilisateur et sa fonction facilement compréhensible. Deux aspects sont concernés :

• mise en page de l'appel à l'action
• étiquetage de l'appel à l'action

Chaque aspect est inextricablement lié à l'autre. La mise en page d'un appel à l'action ne doit jamais affecter sa reconnaissance. Un bouton sur un formulaire, même modifié à l'aide de CSS, doit toujours faire penser à l'utilisateur "Maintenant, je clique ici". En effet, selon Steve Krug, l'utilisateur doit cliquer sans réfléchir si ce qu'il voit est un bouton ou non. L'action doit être immédiate (dans les 300 millisecondes environ, exactement comme établi par des recherches récentes sur l'expérience utilisateur).

Le deuxième aspect est plutôt lié à la façon dont un appel à l'action est défini textuellement. Les étiquettes doivent être simples, claires et explicites. Un exemple est la traduction de l'élément "Enregistrer" dans le menu contextuel des applications Mac OS X : en italien, cet élément a été rendu par "Enregistrer", ce qui n'est certainement pas le meilleur en termes de clarté. Donc, si un bouton doit lancer un moteur de recherche, l'étiquette doit indiquer "Rechercher" et ainsi de suite. Dans ce cas, l'imagination doit céder la place au bon sens : les conventions dans ce cas sont très utiles.

Il est clair qu'il y aurait encore tant à écrire sur le sujet mais le but de ce long article est avant tout de faire réfléchir, de prendre conscience de ce qui se fait et surtout de comprendre qu'un simple bouton qui devrait inciter à vous contacter ou à envoyer un email ou une demande, ce n'est pas si anodin.

Design pour les entreprises, Sketchin : « Toujours partir du changement… »