On continue à coder et tester une navigation accessible sur ce blog.

Ce que j’ai fait :

• emprunter un Iphone pour réaliser ses tests avec VoiceOver
• refactoriser le header pour avoir un code plus maintenable et lisible
• transformer le mixin “mobile” en mixin “desktop” pour coder mobile first
• ajouter un lien d’accès rapide au contenu
• tester le rendu du fil d’ariane, du menu et du lien d’accès rapide sur Talkback et Voiceover

Aperçu du code

Lien d’accès rapide au contenu

Voici un aperçu du code ajouté pour afficher un lien d’accès rapide au contenu.

<header role="banner" class="header">
  <div class="header__info">
    <a class="skip-link" href="#content">Aller au contenu</a>
    </div>

    <nav class="header__nav" role="navigation">...</nav>
  </header>

Ainsi que l’ancre vers laquelle ce lien renvoie :

<main id="main" role="main" class="container">
  <a id="content" tabindex="-1"></a>
</main>

J’ai ensuite stylisé le lien de manière à ne le rendre visible qu’à la prise de focus, par défaut il est masqué.

.skip-link {
  background: #fff;
  color: $blue;
  display: inline-block;
  font-size: 12px;
  left: -99999px;
  position: absolute;
  top: 5px;
  z-index: 100;

  &:focus {
    left: 50%;
    transform: translateX(-50%);

    @include desktop {
      left: 0;
      transform: none;
    }
  }
}

Je me suis basée sur la notice d’AcceDe Web, Mettre en place des liens d’évitement(lien externe), pour créer le code.

Modification du fil d’Ariane

J’ai modifié le symbole > avec le code HTML correspondant > et ajouté l’attribut aria-current="page" pour indiquer à l’utilisateur.rice la page courante.

Tests

Avec Voiceover

Test effectué sur un Iphone 5c, version IOS 10.3.3 avec Safari 10

• le lien d’accès rapide est bien détecté et vocalisé pour accéder directement au contenu principal. Il apparait visuellement lorsqu’on navigue en balayant à droite.

• les items du menu de navigation principal sont bien détectés comme des liens et le title indiquant la page active est vocalisé

• dans le fil d’ariane, le symbole > est vocalisé avec “supérieur à” et la page active indiquée normalement par l’attribut aria-current n’est pas détectée

Avec Talkback

Test effectué sur un téléphone Androïd, version Androïd 8.1.0 avec Firefox 68.2.1

• le lien d’accès rapide est bien détecté et vocalisé pour accéder directement au contenu principal mais contrairement à Voiceover il n’apparaît pas visuellement. Il semble également que ce lien ne soit détecté qu’une fois au chargement de la page, il est impossible de retomber dessus en naviguant dans la page. L’ancre implémentée dans la balise <main> est vocalisée par “Lien”, ce qui n’est pas le cas dans Voiceover.

• les items du menu de navigation principal ne sont pas signalés comme des liens et le title indiquant la page active n’est pas vocalisé

• dans le fil d’ariane, le symbole > est vocalisé avec “chevron droit” et la page active indiquée normalement par l’attribut aria-current n’est pas détectée.

Ce que j’ai appris

C’était la première fois que je testais véritablement l’accessibilité de mon code avec des lecteurs d’écran. En tant qu’intégratrice, j’ai l’habitude de vérifier mon code sur différents navigateurs et terminaux afin d’assurer une compatibilité la plus optimale possible et compte tenu de la diversité actuelle des appareils, ce n’est pas une tâche facile.

Les tests avec lecteur d’écran sont similaires et doivent tenir compte du lecteur utilisé, du navigateur et du système d’exploitation. Contrairement aux tests de navigateurs et terminaux, il n’existe pas d’émulateurs ou d’outils intégrés directement dans le navigateur pour simuler le rendu sur des appareils spécifiques. Il serait donc intéressant de voir comment d’autres développeurs.euses procèdent pour intégrer ces tests dans leur processus de travail.

Dans cet exemple d’implémentation de navigation, Voiceover semble mieux détecter et vocaliser de manière plus juste les différents éléments.

Il faut garder à l’esprit qu’un test avec un lecteur d’écran ne sera jamais suffisant. L’accessibilité ne se limite pas aux utilisateurs.rices de lecteurs d’écran et l’usage que j’en ai ne sera jamais identique à celui d’une personne non-voyante (j’utilise après tout ma vue pendant les tests).