Notifications

La principale différence entre un site web et une application web est… sujette à débat. Dans l’ensemble, je dirais que plus il y a de liens, plus c’est un site ; et que plus il y a de boutons, plus c’est une application. Si cela n’inclut qu’une seule page avec un formulaire, c’est probablement une sorte de site. S’il s’agit principalement de formulaires, vous pouvez parler d’application. Dans tous les cas, votre « produit » web n’est en réalité que du contenu interactif, consommé et transmis par une application que nous appelons un « navigateur ».

Une chose est certaine : une page web ressemble plus à une application de bureau à sa façon de se comporter. Les pages web qui subissent des changements au fur et à mesure que vous les utilisez sont quelque chose de tout à fait différent des pages web qui ne font que se recharger lorsque vous cliquez sur les hyperliens.

Parfois, c’est l’utilisateur ou l’utilisatrice qui sera à l’origine d’un changement d’état. D’autres fois, ce sera un autre usager ou une autre usagère qui affectera l’application à distance, et en temps réel. Plus occasionnellement, l’application pourra être sujette à des événements extérieurs et temporels, indépendants de toute action humaine. Dans tout les cas, il est important que les utilisateurs et utilisatrices soient tenus au courant des changements d’état, et la problématique est donc de les avertir.

Dans cet article, j’examinerai les possibles moyens de notification et j’expliquerais pourquoi elles peuvent rassurer les usagers et les usagères d’applications web ; tout ça de manière inclusive.

Attirer l’attention

L’un des plus grands défis dans la création d’interfaces agréables à utiliser est de savoir quand attirer l’attention sur quelque chose. Une remontée d’informations excessive sera sans doute considérée comme une nuisance, mais une remontée d’informations insuffisante pourra donner à vos utilisateurs et utilisatrices l’impression qu’ils leur manque des points essentiels. C’est parfois très perturbant : même quand il n’y a vraiment aucune information à remonter, il y a ce besoin de le « savoir ».

Et puis il y a le comment. D’une manière générale, il y a deux types de messages qui nécessitent deux approches différentes pour être accessibles :

1. les messages qui demandent aux utilisateurs et utilisatrices d’interagir ;
2. les simples messages informatifs.

Typiquement, un message demandant de faire quelque chose constituera le contenu d’une fenêtre de dialogue (ou l’apparition d’un élément au sein du contenu). Cette fenêtre doit alors être accompagnée d’un certains nombre de boutons d’action. Et puisque l’utilisateur ou l’utilisatrice devra interagir avec ces boutons, le focus doit être déplacé dans cette boîte de dialogue.

Pour les besoins de cet article, ce que j’entendrais par « notification » sera pour les messages qui vous permettent simplement de savoir ce qui se passe. Cela peut être pour que vous puissiez choisir d’agir plus tard, ou pour vous assurer qu’un événement a eu lieu.

En termes d’accessibilité pour un lecteur d’écran et au clavier, il est important que le focus ne soit pas fait vers de tels messages. S’il n’y a aucune action à faire, vous ne mettez d’outil dans la main de personne. Malgré cela, le déplacement de focus s’est imposé comme une « bonne pratique ». Pourquoi ? Parce que la focalisation sur un élément était, historiquement, le moyen le plus fiable d’obtenir que cet élément et son contenu soient annoncés dans des lecteurs d’écran. Donner le focus à une notification, déclenchait donc une annonce dans le lecteur d’écran.

Heureusement, nous avons de nos jours des live regions afin de parer à cette mauvaise habitude.

Introduction aux live regions

Nous avons déjà utilisé des live regions sur ce blog, mais je vais prendre le temps de vous redonner un aperçu général ici.

Une live region n’est qu’un conteneur qui fixe un périmètre autour d’un contenu live : un contenu qui sera donc annoncé – par un logiciel de lecture d'écran – sans interaction de l’utilisateur ou de l’utilisatrice et sous certaines conditions. Par défaut, une live region annoncera tout ce qui est ajouté ou modifié à l’intérieur de son conteneur.

C’est troublant, mais il existe deux A.P.I. équivalentes pour les live regions : l’attribut aria-live et les rôles ARIA des live regions. Dans la plupart des cas, vous voudrez utiliser soit un role="status", soit un aria-live="polite". L’utilisation simultanée des deux augmente la compatibilité avec différents couples de navigateurs et de technologies d’assistance :

<div role="status" aria-live="polite">  
</div>  

Ajouter « Faites une petite pause ! » dans cette live region (comme illustré plus loin) s’activera immédiatement après l’insertion du nœud texte. Et cela ne fonctionne pas qu’avec les nœuds textes ; cela peut être du code.

<div role="status" aria-live="polite">  
  Faites une petite pause !
</div>  

L’arrivée du message « Faites une petite pause ! » dans l’interface peut maintenant être vue et entendue simultanément, créant une correspondance entre l’expérience visuelle et l’expérience auditive (assistée par lecteur d’écran). Ce n’est pas la même expérience, mais c’est une expérience comparable : elle sert le même but.

Et tout le monde devrait régulièrement s’éloigner de son écran.

Les live regions invisibles

Parfois, pour créer une expérience globale similaire, un peu d’information sonore supplémentaire peut être nécessaire. Par exemple, lorsqu’un usager ou une usagère clique sur un bouton « ajouter au panier », l’interface peut répondre animant un produit se déplaçant dans le panier. Une traduction directe de ceci peut être un bruit de glissement suivi d’un bruit métallique, mais je pense qu’ici une live region visuellement cachée indiquant « produit ajouté avec succès » (ou quelque chose de similaire) serait beaucoup plus clair.

Ajouter une live region à une page contenant déjà le contenu que vous souhaitez annoncer n’est pas fiable. Il faut au moins un certain temps entre l’ajout d’une live region au DOM et l’ajout de contenu dans la live region.

Pour faire dire des choses aux lecteurs d’écran simplement pendant que vous gérez les événements dans vos scripts, j’ai créé un petit module. En voici un exemple d’utilisation, avec les paramètres par défaut :

const liveRegion = new OnDemandLiveRegion()

liveRegion.say('Faites une petite pause !')

Le script créé des live regions ARIA cachées et les peuple à la volée, il rend donc la communication avec les lecteurs d’écran triviale du point de vue de la procédure. Cependant, dans la plupart des cas – et dans le cas des messages d’état en particulier – nous voulons communiquer avec les utilisateurs et les utilisatrices. Pas uniquement ceux et celles qui possèdent des lecteurs d’écran ou au contraire ceux et celles n’en utilisant pas ; mais tout le monde. Les live regions facilitent les communications visuelle et auditive simultanées.

Une messagerie instantanée

Dans les applications de messageries instantanées (des outils comme Slack, où tout se passe en temps réel), il y a de nombreuses choses à remonter. Par exemple :

• des utilisateurs ou utilisatrices qui se connectent ;
• des utilisateurs ou utilisatrices qui s’abonnent aux canaux ;
• des utilisateurs ou utilisatrices qui répondent à vos messages ;
• des utilisateurs ou utilisatrices qui « réagissent » à vos messages…

Tous ces types de messages arrivant en permanence vont rapidement devenir perturbant et irritants, surtout s’ils sont remontés vocalement. Vous pouvez détourner les yeux, mais pas les oreilles.

Nous devons faire deux ou trois choses pour rendre l’expérience plus digeste :

• restreindre les messages à ceux appropriés en fonction du contexte et de la situation ;
• donner aux internautes le contrôle sur la verbosité des messages.

Restreindre les messages en fonction du contexte

J’ai remarqué récemment alors que j’utilisais un lecteur d'écran pour consulter un onglet de mon navigateur que je pouvais entendre les mises à jour provenant d’un autre onglet ouvert, même si je ne l’affichais pas. La seule solution à été de fermer l’onglet caché. Ce qui n’était pas idéal, car j’aurais souhaité passer d’un onglet à l’autre.

Pour un internaute voyant, l’invisible est inconnu. Peu lui importe que les messages continuent de s’afficher. Mais, pour les utilisateurs ou utilisatrices de lecteurs d'écran (aveugles ou non), nous devons rendre muettes les remontées des onglets cachés. Nous pouvons le faire en interrogeant document.hidden après un événement visibilitychange issu de l’A.P.I. de visibilité des pages, puis en passant la live region d’active à inactive. Les live regions inactivent se voient alors attribuées d’un role="none" et/ou d’un aria-live="off".

Voici comment ça fonctionne :

const notifications = document.getElementById('notifications');

document.addEventListener('visibilitychange', () => {  
  let setting = document.hidden ? ['none', 'off'] : ['status', 'polite'];

  notification.setAttribute('role', setting[0]);
  notification.setAttribute('aria-live', setting[1]);
});

Conversations

Même quand votre onglet ouvert contient une application de messagerie instantanée, vous ne voulez pas être inondé par une multitude de notifications. Visuellement, cela pourrait devenir irritant ; vocalement, cela le sera à coup sûr.

Savoir quand informer votre utilisateur revient à se questionner sur son contexte d’utilisation. Ainsi, un utilisateur ne sera probablement pas intéressés par des notifications concernant les messages d’autres utilisateurs sans rapport à la conversation actuelle, ni par le signalement de l’arrivée en ligne d’autres utilisateurs avec lesquels il n’a aucun historique en commun.

D’un autre côté, si l'utilisateur est en train de rédiger une réponse dans un fil de discussion et qu’un nouveau message apparait entre-temps, il voudra probablement en être informé. Dans ce cas, le message ne se manifeste à vous que si vous êtes un utilisateur voyant. Pour un utilisateur aveugle utilisant un lecteur d’écran, vous devez lui faire remonter cette notification via une live region.

L’attribut aria-relevant permet de contrôler quels types de modifications dans une live region sont dignes d’être lus. Dans ce cas, seuls les messages nouvellement ajoutés sont vraiment intéressants, aussi nous l’avons défini avec aria-relevant="additions" en plaçant cet attribut sur l’élément qui gère le flux des messages.

Les messages supprimés ou édités ne devraient pas non plus être annoncés à nouveau, mais les messages édités devraient eux pouvoir être pris en compte. Par conséquent, le balisage des messages doit être bien formé et clair sémantiquement, en utilisant une structure de liste (<ul>) afin de les regrouper.

<h1>La messagerie instantanée du bien-être</h1>  
<div role="status" aria-live="polite" aria-relevant="additions">  
  <ul class="messages">
    <li>
      <h2>Heydon, <small>il y a 22 minutes</small> :</h2>
      <p>Faites une pause ! Ça fait 15 heures.</p>
    </li>
    <li>
      <h2>Heydon:</h2>
      <p>Oh, je suppose que c’est déjà fait.</p>
    </li>
  </ul>
<div>  
<form>  
   <label for="message">Votre message</label>
   <textarea id="message"></textarea>
   <button type="submit">Publier</button>
</form>  

Quand le dernier élément de la liste est ajouté, les utilisateurs de lecteurs d’écran entendent « Heydon : Oh, je suppose que c’est déjà fait ». On peut se demander alors s’il ne faut pas préfixer chaque message par le mot « Message » afin de permettre une différenciation entre eux et les autres notifications. Nous y reviendrons rapidement.

Si l’utilisateur du lecteur d’écran n’est pas au niveau du champ texte, une amélioration possible serait de lui faire entendre les nouveaux messages que s’il s'adressent directement à lui — ce qui utilisent le « @ », par exemple. Nous ne lésons pas ces utilisateurs ; nous évitons juste de pas les interrompre pendant une autre tâche, sauf quand le message est explicitement du type « hé, j'ai besoin de toi ».

Notifications rapides

Les notifications rapides – des bandeaux colorés contenant des messages qui apparaissent par dessus la page – sont souvent utilisés pour informer les utilisateurs des changements d’état. Une simple live region ARIA suffira pour ces notifications qui ne donnent lieu à aucune action.

Je vous en dirais plus sur la manière de les concevoir juste après, mais assurons nous avant tout qu’ils puisse être éteints. La première chose que je fais quand j’installe une application comme Skype est de désactiver les sons de notification, et j’ai de bonnes raisons à faire cela.

Le panneau de configuration

La conception d’une page regroupant les paramètres de l’application ne demande pas d’avoir fait de hautes études. Ce ne sont que des titres, des sous-titres et des contrôles de formulaires. Mais, si vous n’y faites pas attention, vous pouvez néanmoins abimer toute l’architecture et la terminologie de votre contenu.

Des noms de catégories comme « général » et « contenu » ne signifient pas grand chose par exemple. Et cacher ce que vous considérez subjectivement comme des paramètres avancés derrière un petit lien difficile à localiser, n’aide pas vraiment non plus.

Mieux vaux tout formuler tout de façon descriptive, et tout structurer logiquement. Utilisez les contrôles de formulaire standard tels que les cases à cocher, des boutons radio et des sliders. Le panneau de configuration permet aux utilisateurs de contrôler la façon dont ils utilisent leur application ; n’y pensez pas après coup.

<div role="status" aria-live="polite">  
  <div class="message award">
    <p>
      <strong>
        <svg viewBox="0 0 20 20" focusable="false">
          <use xlink:href="#star"></use>
        </svg>
        <span class="visually-hidden">Félicitations!</span>
      </strong>
      Vous avez gagné 6 bons points Internet
    </p>
  </div>
</div>  

Ignorer les notifications

En tant que consultant en design, je vois souvent des messages de notification avec des petits boutons "✖️" pour les rejeter.

Bien que je souhaite encourager tout ce qui permet aux utilisateurs d’avoir le contrôle sur l’interface, j’ai des doutes dans le cas présent. Je ne pense pas que la possibilité de rejeter manuellement des notifications soit assez importante pour les déranger ; ce n’est pas quelque chose qui vaut la peine d’être vu ou réfléchit. (Il y a aussi une problématique à gérer le focus lorsque le bouton de fermeture est retiré du DOM après avoir été pressé, comme nous l’avons vu dans la liste des tâches).

À la place, il vaut mieux que les messages disparaissent d’eux-mêmes – après un laps de temps approprié. Voici un petit script qui vous permet de créer des espaces de notifications classés par type (« erreur », « récompenses », ou « informations », par exemple) et d’injecter/supprimer des messages après un certain temps.

function Notifier(type, regionEl, duration) {  
  this.regionEl = regionEl;
  this.duration = duration || 10000;
  this.type = type || 'info';
}

Notifier.prototype.notify = function(message) {  
  let note = document.createElement('p');

  note.innerHTML = `
    <svg viewBox="0 0 20 20" focusable="false">
      <use xlink:href="#${this.type}"></use>
    </svg>
    <span class="visually-hidden">${this.type}:</span>
    ${message}
  `;

  this.regionEl.appendChild(note);

  window.setTimeout(() => {
    this.regionEl.removeChild(note)
  }, this.duration);
}

const infoNotifications = new Notifier(  
  'info',
  document.getElementById('notifications'), 
  5000
);

infoNotifications.notify('Heydon666 a rejoint ce groupe.');  

(Note : La chaîne de caractère « type » est utilisée à la fois pour l’ancre SVG et comme texte alternatif à l’icône.)

Mais que se passe-t-il si l’utilisateur manque des notifications ? Aucun problème. Les notifications ne doivent faire référence qu’à des choses qui peuvent être découvertes par ailleurs dans la mise à jour de l’interface.

Quelques exemples : si la notification fait référence à l’arrivée en ligne d’@Heydon666, vous pourrez découvrir qu’il est là parce qu’il figure dans la liste des utilisateurs actifs, ou que son statut est mis à jour. Pour l’exemple des « récompenses », l’interface devrait en garder une trace sur la page du profil de l’utilisateur. C’est tout à fait classique d’y trouver une chronologie des récompenses.

Conclusion

Grâce cette merveilleuse technique du « tu l’ajoutes, je le prononce » des live regions ARIA, la mise en œuvre d’une notification inclusive ne pourrait guère être plus facile. Il ne nous reste qu’à perfectionner la clarté et la forme de la communication.

La partie du travail la plus importante n’a finalement rien à voir avec la notification elle-même. Tout est dans la structuration et la présentation de la chronologie dans laquelle chaque message de notification viendra s’insérer. Et comme toujours, la structuration du contenu est primordiale, quand bien même nous sommes en présence d’interactions au sein d’une application web en temps réel.

Points de contrôle

• N’utilisez pas aria-atomic="true" [article en anglais] à moins que vous ne vouliez que tout le contenu d’une live region soit annoncé chaque fois qu’il y a le moindre changement.
• Utiliser les live region cachées avec précaution. La plupart des contenus doivent être vus et entendus.
• Faites la distinction dans votre interface entre les contenus (éventuellement mis en forme) et la pure mise en forme.
• N’annoncez pas tout ce qui bouge sur la page. Un plugin de carrousel très populaire que je ne nommerais pas annonce l’arrivée de chaque diapositive au fur et à mesure qu’elles sont visibles. Terriblement irritant, et comparable à l’expérience d’un internaute voyant si le carrousel était réglé pour suivre ses mouvements oculaires, tout en restant constamment dans son champ visuel.
• Méfiez-vous des notifications desktop pour votre site. Je n’ai jamais rencontré un site pour lequel je désirais autoriser ces messages indigents et obstructifs.