L'accessibilité des iBooks

Pierre Jourdain le 04/09/2014

Les sites Web, mais également les documents numériques doivent être accessibles à tous. Les principes sont identiques pour tous les formats, mais les techniques à utiliser pour atteindre l'accessibilité varient selon le logiciel utilisé. Nos collègues de Blind d mobiel ont décrit ces techniques pour le logiciel iBooks Author, qui permet de créer des iBooks.

iBooks?

iBooks est l'interprétation d'Apple de la norme ePub pour les livres numériques. La première version de iBooks date d'avril 2010 et était pleinement conforme à la norme ePub. Lors du lancement de la deuxième version de iBooks en janvier 2012, Apple a ajouté quelques éléments au format des iBooks qui ne sont pas prévus par la norme ePub. Suite à cela, un iBook peut désormais contenir beaucoup plus d'éléments interactifs, mais ne répond plus à la norme ePub.

Pour ouvrir et lire un iBook, vous aurez besoin du logiciel "iBooks", qui est disponible pour:

  • iOS (iPhone, iPad, iPod touch) : l'application fonctionne très bien avec les logiciels de synthèse vocale et d'agrandissement typiques de ces dispositifs.
  • Mac OS X (pour Mac) : malheureusement, l'application n'est cette fois pas aussi accessible pour les utilisateurs de VoiceOver.

Comment créer un iBook accessible?

Logo de l'app iBooks Author

Le logiciel gratuit iBooks Author (disponible uniquement sur MAC) permet la création de livres électroniques iBooks. Via sa plate-forme de vente online, Apple vous permet de proposer vos livres électroniques à la vente. Il est également possible de les proposer sur votre propre site.

Durant le processus de création d'un livre iBooks, il faut tenir compte de certains points pour garantir que le résultat final sera accessible. Les techniques pour y parvenir sont décrites dans un document ADOD. (ADOD = Accessible Digital Office Documents). Les directives de AnySurfer s'appliquent aux sites web. Pour tous les autres documents électroniques, les manuels ADOD sont la référence. Le document (en anglais) Authoring Techniques for Accessible Office Documents: iBooks Author ver2 décrit les techniques a utiliser pour rendre un iBook accessible. Le document est également disponible en néerlandais (Technieken voor het produceren van Toegankelijke Office Documenten: iBooks Author v2).

Ce travail a été présenté lors du colloque Des livres numériques accessibles ! Une chance pour des bibliothèques accessibles à tous les publics qui s'est tenu à Paris les 22 et 23 août 2014. Les textes et les slides de la présentation sont disponibles sur le site de l’événement.

Réagissez

Un placeholder n'est pas un label

Pierre Jourdain le 12/08/2014

Nous observons de plus en plus souvent que l'attribut placeholder est utilisé à la place du label dans les formulaires.

Un placeholder n'est pas une alternative à part entière pour un label. Un label qui reste visible est indispensable.

Label, value et placeholder?

Quelles sont les différences entre label, value et placeholder?

Label

Le label est l'étiquette d'un champ et indique ce que doit contenir le champ (nom, prénom, ...).

Un lecteur d'écran vocalise le contenu du label lié au champ lorsque le curseur arrive dans celui-ci. S'il n'y a pas de label, le lecteur d'écran ne peut transmettre aucune information à l'utilisateur.

Avec la souris, quand l'utilisateur clique sur le label d'un champ, le curseur se place dans le champ relié. C'est surtout utile de pouvoir cliquer sur le label pour les champs de type bouton radio ou cases à cocher, car cela augmente fort la taille de la zone cliquable.

Voici un exemple de code qui relie le label à un champ de formulaire.

<label for="name">Nom:</label>
<input type="text" id="name"/>

Value

L'attribut value sert à attribuer une valeur initiale au champ. Avec un peu de javascript, cette valeur peut être effacée lorsque le champ reçoit le focus .

<label for="adresse">Adresse:</label>
<input type="text" id="adresse" value="Avenue des Arts, 24" onfocus="this.value=''"/>

Placeholder

L'attribut placeholder peut être ajouté à un champ, mais ne peut pas être considéré comme un substitut de l'élément label.

La spécification HTML5 dit littéralement:

The placeholder attribute should not be used as an alternative to a label.

Il communique à l'utilisateur un indice sur les données que l'utilisateur doit insérer. Par exemple, vous pouvez indiquer une adresse email factice dans l'attribut placeholder d'un champ de type mail.

Lorsque l'utilisateur commence à écrire dans le champ mail, le placeholder se vide.

Voici, un exemple de code.

<label for="e-mail">E-mail:</label>
<input type="text" id="e-mail" placeholder="info@anysurfer.be" />

Si vous ne voyez pas l'adresse email dans le champ sous le code, c'est que votre navigateur ne prend pas en charge l'attribut placeholder de HTML5.

Pourquoi un label visible est-il toujours requis?

Il est permis d'utiliser les attributs value et placeholder pour communiquer des informations complémentaires. Mais les labels restent obligatoires. Ils sont indispensables pour les lecteurs d'écrans, mais également utiles pour les personnes qui naviguent au clavier ainsi que pour les personnes souffrant de troubles déficitaires de l'attention:

  • Le texte du placeholder disparaît lorsque le curseur est dans le champ de saisie. Ceci vous oblige à lire le placeholder avant d'entrer dans le champ et à le mémoriser. Ce qui n'est pas évident pour tous les utilisateurs.

  • Les visiteurs qui utilisent la touche de tabulation pour naviguer entre les champs de saisie auront le même problème et devront faire shift-tab pour ressortir du champ afin de réafficher le placeholder. Ceci constitue une manœuvre complexe.

  • L'affichage standard du placeholder a un faible taux de contraste (4,5: 1), ce qui le rend difficilement lisible.

Alternatives

Le grand avantage de placeholder est qu'il occupe peu d'espace ce qui pour certains formulaires est fort utile. Si pour conserver le design de votre formulaire vous souhaitez continuer d'utiliser placeholder, voici deux alternatives qui simulent celui-ci mais qui utilisent de vrais labels visibles:

A lire aussi

Le Nielsen Norman grouve estime aussi que l'utilisation de placeholder est néfaste : Placeholders in Form Fields Are Harmful

Réagissez

jQuery UI Dialog

Pierre Jourdain le 04/08/2014

jQuery UI permet d'utiliser facilement des fenêtres de dialogue. Ce type de fenêtre peut contenir une notification avec ou sans boutons, un formulaire complet ou tout autre contenu.

Screenshot jQuery UI Dialog

Cette boite de dialogue est injectée dans le code source de la page et se superpose au reste de la page via CSS. Dans sa configuration par défaut, la fenêtre créée avec jQuery UI pose quelques problèmes d'accessibilité. Notamment pour les utilisateurs qui naviguent au clavier ou avec un lecteurs d'écran.

  • Lors de l'ouverture de la fenêtre, celle-ci ne reçoit pas le focus.
  • En tabulant, le focus est visible dans l'arrière-plan mais ne permet pas d'atteindre les éléments de la fenêtre.
  • Les utilisateurs de lecteur d'écran utilisent normalement les flèches vers le haut ou le bas pour déplacer le focus de lecture. Ils ne pourront pas le faire dans la fenêtre et ne pourront par conséquence, pas lire le contenu de celle-ci.

Néanmoins en configurant quelques options du module jQuery UI Dialog, il peut devenir accessible pour tous les utilisateurs.

Modal

Nous mettons la valeur de 'modal' à "true" pour que les autres éléments de la page cessent d'être accessibles au clavier. Vous créez ainsi une sorte de piège au clavier qui maintiendra le focus dans la boîte de dialogue. Il n'en sortira pas.

Gestion du focus

Il est très important que le focus se déplace vers la boîte de dialogue qui s'ouvre. Un utilisateur aveugle ou ayant une déficience visuelle peut penser que le lien qu'il a activé ne fonctionne pas parce qu'il y a l'air de ne rien se passer. Un utilisateur malvoyant qui travaille avec un logiciel d'agrandissement ne voit peut-être pas la fenêtre de dialogue car elle se trouve en dehors de son champ de vision. Heureusement le déplacement du focus fait bien partiue de jQUery UI.

Il faut idéalement que ce soit le premier élément de la lightbox qui reçoive le focus. En effet, on voit souvent que le premier champ de formulaire de la lightbox reçoit le focus. Or s'il y a du texte qui précède ce champ de formulaire, celui-ci ne sera pas lu par les lecteurs d'écran.

aria-hidden

On peut utiliser des propriétés ARIA pour communiquer des informations supplémentaires aux lecteurs d'écran. Dans ce contexte il peut être utile d'utiliser l'attribut aria-hidden.

L'attribut Aria-hidden est de type booléen. Aria-hidden="true" rend l'élément invisible pour un lecteur d'écran. Aria-hidden="false" le rend visible.

Nous mettons le contenu (dans ce cas un div avec id = "wrap") à aria-hidden="true". Le contenu devient alors invisible uniquement pour les lecteurs d'écrans. Pour la fenêtre de dialogue nous utilisons aria-hidden="false" pour qu'elle seule soit visible. Il ne faut pas perdre de vue que lors de la fermeture de la fenêtre, il faudra inverser les valeurs de ces deux 'aria-hidden' pour que la fenêtre soit cachée et que le contenu redevienne visible.

Exemple de code

Consultez un exemple en ligne.

Cet exemple a été teste avec les lecteurs d'écrans suivants: VoiceOver(mac) Jaws, NVDA et SuperNova (PC/Windows). Les résultats sont bons sauf en ce qui concerne SuperNova qui ne peut gérer le déplacement du focus dynamique. Les utilisateurs de SuperNova ne pourront pas consulter le contenu de la lightbox. Le focus reste bloqué sur le lien 'ouvrir la lightbox'.

Conclusion

Moyennant quelques adaptations du code, le plugin jQuery UI Dialog devient accessible et utilisable par pratiquement tout le monde.

3 réactions

OnClick? Préférez un lien ou un bouton!

Pierre Jourdain le 04/08/2014

De plus en plus souvent, nous rencontrons des éléments cliquables qui ne reçoivent pas le focus. Les personnes qui naviguent au clavier ainsi que les utilisateurs de lecteurs d'écran ne peuvent les utiliser.

Ces éléments cliquables ne pointent pas vers une nouvelle page, mais vers des éléments internes de la page. Ils provoquent souvent des rafraîchissements partiels du contenu de la page

Quelques exemples:

  • Un menu 'hamburger' pour la navigation dans un site responsive:
    <span onclick="...">Toggle navigation</span>
  • Les boutons 'fermer', 'suivant' et 'précédent' dans une lightbox:
    <div onclick="...">Fermer</div>
  • Les liens qui permettent de filtrer les résultats d'une recherche:
    <li onclick="...">Entre 1200W et 1500W</li>
  • Trier un tableau sur base du contenu du 'th':
    <th onclick="...">Date</th>
  • Le bouton corbeille qui permet d'éliminer un item de la liste de vos achats:
    <img onclick="..." alt="Enlever cet article" />

Les éléments <div>, <span>, <th>, … qui sont rendus interactifs via JavaScript (onclick) ne sont pas accessibles au clavier. Si vous souhaitez les rendre focusables et accessibles, vous devrez recourir à ARIA et ajouter du code JavaScript. Cette option est assez compliquée.

Il existe une solution bien plus simple: toujours utiliser un lien (a href) ou un bouton (button) qui sera couplé à du JavaScript. Un lien ou un bouton sont toujours inclus dans l'ordre de tabulation et reçoivent toujours le focus. Voici trois exemples de code qui ouvrent une fenêtre 'alert'.

a href="#"

Dans ce premier exemple, 'onclick' est utilisé comme attribut du lien:

<a href="#" onclick="alert('Exemple 1');">
  Exemple 1
</a>
Exemple 1

Event Listener

En utilisant un 'Event Listener' vous pouvez séparer le code JavaScript du HTML en le plaçant ailleurs dans le code source de la page ou dans un fichier séparé.

Nous utilisons ici jQuery pour coupler l'Event Listener au lien id="lien2".

<a href="#" id="lien2">
  Exemple 2
</a>
<script>
  $("#lien2").click(function() {
    alert('Exemple 2');
  });
</script>
Exemple 2

Dans l'attribut href

Dans cet exemple, nous n'utilisons pas d'Event Listener ou de onclick, mais nous plaçons le code JavaScript dans l'attribut href.

<a href="javascript:alert('Exemple 3');">
  Exemple 3
</a>
Exemple 3

Conseils

Il existe plusieurs façons de rendre ces éléments cliquables accessibles. Choisissez celle qui vous convient le mieux.

Evitez onMouseOver, onMouseOut, onKeyDown, onKeyUp et onDblClick qui ne fonctionnent pas pour tous les utilisateurs. Par contre OnClick est accessible si vous l'utilisez comme dans les exemples de cet article.

Réagissez

Pistes pour développer des apps accessibles

Sophie Schuermans le 01/04/2014

Les smartphones et tablettes qui tournent sur Android et iOS peuvent être bien utilisables par les personnes handicapées. Pour plus d'infos à ce sujet, voyez notre article Naviguer sur internet avec un dispositif mobile.

Vous êtes de plus en en plus nombreux à nous demander des conseils pour développer une app accessible, ou pour vérifier l'accessibilité d'une app existante. Nous voulons dans cet article vous donner quelques pistes. Vous trouverez ci-dessous quelques conseils généraux ainsi que des liens vers des ressources pour les développeurs. Nous nous limiterons pour cette fois-ci aux plateformes iOS et Android.

Pour évaluer l'accessibilité d'un site web nous nous basons sur les Web Content Accessibility Guidelines. Ces critères sont formulés indépendamment des technologies et devraient donc être utilisables pour évaluer des apps.

Quand on évalue l'accessibilité d'une app, il y a effectivement une partie des tests qui se rapprochent de ceux que l'on peut faire sur un site web. Par exemple : les boutons sont-ils bien étiquetés, les liens significatifs, les tableaux linéarisables, les validations de formulaire sont-elles claires pour ceux qui ne voient pas l'écran, etc ?

Par contre il est pour nous plus difficile de dire ce qui cause les problèmes identifiés et comment ils peuvent être résolus. Nous ne pouvons pas consulter facilement le code source comme dans un site web.

Utilisable au clavier

La première des directives AnySurfer demande que toutes les fonctionnalités soient utilisables avec le clavier. Comment cela se traduit-il dans le cas d'un écran tactile ?

Un utilisateur aveugle utilise un écran tactile d'une manière fort différente de quelqu'un qui peut voir. Les lecteurs d'écran comme VoiceOver pour iOS et Talkback pour Android font bien plus que lire ce qui est affiché à l'écran. Ils offrent tout un système d'interaction, y compris des gestes adaptés. Voyez comment cela fonctionne dans cette vidéo : balayer l'écran de gauche à droite avec un doigt déplace le focus à l'élément suivant (comme le TAB du clavier).

En tant que développeur il faut veiller à ce que ce focus puisse se déplacer à travers tous les éléments interactifs de l'app, et que ce déplacement ait lieu dans un ordre logique.

Sémantique

Utilisez le plus possible des éléments standards pour construire des éléments interactifs. Leur comportement sera alors prévisible et compréhensible quel que soit le mode d'interaction.

Les lecteurs d'écran annoncent le rôle de l'élément (case à cocher), son nom (le label du champ), et son état (cochée). Si vous programmez des éléments vous-même (par exemple une fausse case à cocher) vous devrez programmer vous-même toutes les fonctionnalités et les tester de manière approfondie (avec des lecteurs d'écran).

Les images ont une alternative textuelle

Les images d'un site web doivent avoir un attribut alt. Dans les apps les boutons doivent avoir une alternative textuelle. Le principe est le même mais la technique pour donner une alternative textuelle diffère d'un environnement de développement à l'autre.

Si vous oubliez d'étiqueter un bouton, en général c'est le nom du fichier qui est lu, au lieu de la fonction du bouton. En tant qu'utilisateur on préfère entendre "retour" que "NavBarIconBackButtonSmall".

Documentation pour les développeurs

Il existe, pour iOS ainsi que pour Android, de la documentation qui explique comment développer des applications accessibles sur ces plateformes.

A côté de ces guides, il y a également les Mobile Accessibility Guidelines de la BBC, qui ont l'avantage de donner pour chaque critère les techniques pour iOS, Android et HTML. L'article Accessibility for iPhone and iPad apps part d'une histoire plus concrète. Ne vous laissez pas décourager par la longue introduction.

Si vous connaissez d'autres bonnes ressources, n'hésitez pas à nous les signaler dans les commentaires de cet article.

Réagissez