Posts taggés Accessibilité

article-mobilite-accessibilite

Accessibilité et mobilité : les limites

2

 

Quelles sont limites des Frameworks favorisant la mobilité des sites Internet sur le respect des critères d’accessibilité d’un site Internet ? Qu’en est-il des applications natives et quelles solutions existe-t-il ?

 

Avec le développement des supports mobiles et l’engouement général pour le Responsive Web Design, de plus en plus de Frameworks ont vu le jour pour répondre aux besoins des intégrateurs, tels que Foundation, Skeleton, Web Starter Kit, KNACSS et bien sûr Bootstrap pour ne citer qu’eux.

A Webnet nous travaillons essentiellement avec le Framework Bootstrap, version 3 : les maquettes fournies par nos graphistes sont conçues à partir de la grille de Bootstrap. Le système de grille de Bootstrap, avec son nommage de classes très bien pensé, ainsi que la richesse et la compatibilité de ses composants d’interface nous ont amené à choisir ce Framework pour réaliser nos projets « responsive ».
Cela nous permet d’avoir une plus grande efficacité dans la production de nos intégrations.

Outre la prise en compte quasi-obligatoire de la mobilité aujourd’hui, l’accessibilité des sites internet est capitale : l’impossibilité pour un utilisateur d’accéder à un contenu web, au motif que dans la conception de ce contenu la prise en compte des handicaps a été négligée, n’est pas acceptable.

Au final, nous nous sommes demandés si mobilité et accessibilité pouvaient cohabiter. Ou pour être plus juste : si les outils, les Frameworks utiles aux projets « responsive » ne nuisaient pas à l’accessibilité ?
Nous avons voulu en savoir plus à ce sujet à propos du Framework Bootstrap 3.

 

1. L’accessibilité et le Framework responsive Bootstrap 3

Les composants de Bootstrap ne sont pas tous accessibles, tels quels. Il existe cependant une solution développée par la PayPal Accessibility Team : le Bootstrap Accessibility Plugin, v1.0. Ce plugin permet de rendre accessible les éléments courants de Bootstrap. On pourra éventuellement en améliorer d’autres directement, comme nous le verrons.

 

1.1 Rendre Bootstrap accessible avec le Bootstrap Accessibility Plugin

bootstrap_blog

Ce plugin fournit des améliorations dans deux domaines : compatibilité avec les lecteurs d’écran et navigation au clavier. Il comporte aussi des petites modifications pour améliorer le contraste des couleurs dans les messages d’alerte, mais ceci sera peu utile pour un site personnalisé.

Présentation du plugin : http://paypal.github.io/bootstrap-accessibility-plugin/

Ce plugin permet de rendre accessible les éléments suivants :

  • Alert
  • Tooltip
  • Popover
  • Modal dialog
  • Dropdown menu
  • Tab panel
  • Collapse
  • Carousel

 

Pour ce faire, il faut inclure les fichiers bootstrap-accessibility.css et bootstrap-accessibility.js.

Détail des composants pris en charge par le plugin et des traitements qu’il effectue pour chacun d’eux : https://github.com/paypal/bootstrap-accessibility-plugin/blob/master/README.md

 

Exemple du carrousel Bootstrap avec l’utilisation du Bootstrap Accessibility Plugin :

access1

Aperçu du code HTML Bootstrap initial (non accessible), pour la partie « carousel-inner »

 

access2

 Aperçu du code HTML Bootstrap après traitement du Bootstrap Accessibility Plugin, pour la partie « carousel-inner », avec l’ajout des attributs « role » et « aria » pour le les <div> de classe « item ».

 

NB : On remarque notamment l’ajout des attributs role= »option » pour les items, ainsi que la gestion de la slide en cours avec les attributs aria-selected= »true » (ou false) et tabindex= »0″ (ou -1).
Ces deux attributs étant changés dynamiquement.

 

Quelques apports pour l’accessibilité :

  • Permet à l’utilisateur de contrôler le défilement du carrousel
  • Permet à l’utilisateur de connaître le nombre de slides présentes dans le carrousel
  • Rend le carrousel accessible au clavier

 

1.2 Exemples où l’on peut se passer du Bootstrap Accessibility Plugin

NB : Il semblerait aujourd’hui que Bootstrap prenne directement en compte l’accessibilité de la « modal » et du « collapse » notamment grâce à l’ajout des attributs « role » et « aria », sans qu’on ait besoin d’utiliser le Bootstrap Accessibility Plugin.

Les indications et le code pour l’accessibilité sont indiqués dans la partie JavaScript de Bootstrap pour les éléments concernés. Ce sont ces indications que nous avons suivies pour les deux exemples qui viennent, celui de la modal et de l’accordéon.

Exemple de la modal : pour rendre la modal accessible, il faudra utiliser les attributs suivants au <div> de classe « modal » :

role= »dialog »,
aria-labelledby,
aria-hidden= »true »,
et éventuellement aria-describedby si on souhaite décrire le contenu de la modal

access3

 Aperçu du code HTML avec les attributs « role » et « aria » 

 

Description des apports pour l’accessibilité après la mise en place de ces attributs :

  • Un lecteur d’écran comme NVDA pourra lire le contenu à l’intérieur de la boîte de dialogue,
  • Le bouton de fermeture de la modal sera accessible aux lecteurs d’écran et son contour sera visible au focus (outline),
  • Lorsque la modal sera fermée, le focus sera renvoyé à l’élément qui a ouvert la boîte de dialogue.

 

Exemple de l’accordéon : pour rendre l’accordéon accessible (le « Collapse »), il faudra utiliser les attributs suivants :

role=« tablist »,
role=« tab »,
role=« tabpanel »,
aria-expanded,
aria-controls

 

access4

Aperçu du code HTML avec les attributs « role » et « aria » 

 

Apports pour l’accessibilité après la mise en place de ces attributs :

  • Permet de connaître le contenu actif (déplié)
  • Rend l’accordéon accessible au clavier

L’attribut « aria-expanded » étant changé dynamiquement.

 

1.3 Autres points pouvant améliorer l’accessibilité

NB : Les thématiques suivantes (selon le référentiel AccessiwebHTML5/ARIA) : Images, Couleurs, Cadres, Liens, Éléments Obligatoires, Structuration de l’information, Présentation de l’information, Consultation, ne concernent pas directement Bootstrap (mais dépendent surtout du projet final sur lequel celles-ci seront implantées), elles ne seront donc pas évoquées ici.

La thématique Scripts a quant à elle été évoquée précédemment (pour les composants Bootstrap seulement, comme le carrousel).
Il reste donc les thématiques suivantes, pour lesquelles on peut trouver des points d’amélioration :

 

Thématique n°5 : tableaux

Pour que les tableaux Bootstrap satisfassent aux critères d’accessiblité, il faudra leur ajouter les éléments suivants :

  • ajouter un résumé pertinent avec l’attribut « summary » (Critères 5.1 et 5.2)
  • ajouter un titre pertinent avec la balise « caption » (Critères 5.4 et 5.5)
  • ajouter un attribut « id » unique ou un attribut « scope » pour les en-têtes (balise th).

 

-> On ajoutera l’attribut « id » si l’entête ne s’applique pas à la totalité de la ligne ou de la colonne.
Dans ce cas, ajouter l’attribut « headers » à chaque cellule (balise td ou th) associée à un ou plusieurs en-têtes.
Cet attribut doit posséder la liste des valeurs des en-têtes associés à la cellule, par exemple :
<td headers= »entete-1 entete-2″>Contenu cellule</td>

-> On ajoutera l’attribut « scope » si l’entête s’applique à la totalité de la ligne ou de la colonne. Avec scope= « row » pour les en-têtes de ligne et scope=« col » pour les en-têtes de colonne (Critères 5.7)

Difficulté de mise en place : facile

Thématique n°11 : formulaires

  • Bootstrap prend bien en compte le critère 11.1, c’est-à-dire l’association label / champ de formulaire.
  • Il pourra être utile de regrouper les informations de même nature dans une balise « fieldset » (Critères 11.5) (Le glossaire du référentiel Accessiweb HTML5/ARIA donne comme exemple les champs successifs pour saisir une date : jour/moi/année).

La balise « fieldset » devant elle-même inclure la balise « legend » (cette dernière jouant le rôle de titre du groupe d’informations de même nature).

  • Sans oublier de respecter les autres règles d’accessibilité des formulaires, mais nous sortons ici du cadre de Bootstrap.

Difficulté de mise en place : facile

Thématique n°12 : navigation

On peut envisager d’ajouter un attribut « id » à la navbar de Bootstrap afin de satisfaire le critère 12.10.2.

Difficulté de mise en place : facile

 

1.4 Conclusion sur Bootstrap et l’accessibilité

Il semble tout à fait possible d’utiliser Bootstrap 3 pour un site à la fois responsive et accessible, à la condition d’ajouter les attributs « aria » et « role » selon les conseils d’accessibilité fournis par Bootstrap, ou à défaut en implémentant le Bootstrap Accessibility Plugin, et pour finir en effectuant quelques retouches sur les tableaux ou les formulaires notamment. Il est cependant important de garder à l‘esprit qu’il est toujours possible d’avoir à gérer quelques cas particuliers.

2. Qu’en est-il des Applications Mobile natives ?

Nous prendrons comme exemple iOS, Android et Windows Phone.

2.1 iOS

Grâce au lecteur d’écran intégré (VoiceOver), des informations sont données à l’utilisateur en fonction de la zone d’écran touchée. Il fonctionne avec toutes les apps intégrées, dont Safari, Mail, App Store, iTunes Store, Musique, Calendrier, Rappel et Notes.

Source : https://www.apple.com/fr/accessibility/ios/voiceover/

Pour améliorer l’accessibilité des apps natives iOS, l’ajout d’ « attributs d’accessibilité » est important. Ces attributs décrivent les éléments d’interface utilisateur. Les attributs d’accessibilité sont les suivants :

  • Label
  • Traits
  • Hint
  • Frame
  • Value

 

On pourra consulter la documentation d’Apple :

 

2.2 Android

Les options d’accessibilité sont nativement intégrées depuis Android 4.2.
Android utilise le lecteur d’écran intégré Talkback, avec une exploration de l’écran au toucher (comme VoiceOver pour iOS)

On pourra consulter la documentation Android :

L’article « Accessibility » (introduction générale), et ses trois sous-rubriques :

 

2.3 Windows Phone

Windows Phone utilise quant à lui le lecteur d’écran intégré Narrateur.

On pourra consulter la documentation Microsoft :
Accessibilité pour les applications Windows Runtime en C#/VB/C++ et XAML (introduction générale), et notamment les sous-rubriques suivantes :

 

2.4 Conclusion

Les critères et la méthodologie d’accessibilité des applications natives sont dans l’ensemble très spécifiques au système utilisé.

NB : Si on sort du cadre des applications natives, que ce soit sur iOS, Android, Windows Phone ou tout autre système, toutes les pages web mobile devront répondre aux critères habituels d’accessibilité, selon le référentiel Accessiweb HTML5/Aria, tout comme la partie web des applications hybrides.

3. Conclusion générale

Que ce soit pour les applications web ou natives, pour les sites « responsive » ou non, nous avons peu de statistiques disponibles sur leur accessibilité.

  • En 2011, 5% des sites seulement étaient accessibles, d’après le site greenit.fr.
  • Plus récemment, AnySurfer (organisation de prestation de services pour les personnes aveugles et malvoyantes, située en Belgique) publie quelques chiffres suite à une étude effectuée essentiellement sur des sites belges en 2013.

Résultat : seulement 14,16 % des sites seraient accessibles : voir l’étude sur le site d’AnySurfer.

  • Enfin, pour en savoir plus sur le nombre de sites labellisés en France chaque année par Accessiweb, on pourra consulter leur galerie de sites labellisés.

 

Par exemple : en 2013, 6 sites ont été labellisés et 9 en 2012.
Ce qui semble extrêmement faible par rapport au nombre de sites produits chaque année.

Si la mobilité profite d’un engouement naturel aujourd’hui, il n’en est pas tout à fait de même de l’accessibilité, bien que d’énormes progrès aient été faits chez les professionnels du web et leurs clients, tant dans la prise de conscience de l’importance de l’accessibilité que des actions enclenchées (les professionnels et leurs clients communiquent plus sur l’accessibilité, avec parfois une ap-proche pédagogique, et même une véritable démarche d’accessibilité, avec ou sans labellisation). Mais il y a encore beaucoup de progrès à faire.

Rappelons que pour Tim Berners-Lee, inventeur du World Wide Web, l’objectif d’internet est de « Mettre le web et ses services à la disposition de tous les individus, quels que soient leur matériel ou logiciel, leur infrastructure réseau, leur langue maternelle, leur culture, leur localisation géographique, ou leurs aptitudes physiques ou mentales. »

On voit bien ici que Tim Berners-Lee tient compte aussi bien des contextes d’utilisation que des handicaps utilisateurs. N’oublions pas que l’accessibilité, pour sa partie web, permet aussi d’améliorer la qualité des réalisations en faisant appliquer les standards et les normes internationales (W3C/WAI), améliorant ainsi la portabilité et la compatibilité des sites.
Au final, mobilité et accessibilité sont complémentaires : elles permettent toutes deux d’élargir le champ de diffusion de l’information numérique. A nous de les faire cohabiter par nos compétences techniques.

Faciliter l’accessibilité des liens web

0

Cet article résume les principaux éléments à considérer pour faciliter l’accessibilité des liens dans une page web.

Sommaire :

  1. Un lien doit être explicite
  2. Cas particulier des fichiers en téléchargement
  3. Cas particulier de l’ouverture dans une nouvelle fenêtre
  4. Un lien doit être identifiable
  5. Que faire de l’attribut title ?
  6. Quelles balises pour agencer les liens ?

  

1. Un lien doit être explicite, et autant que possible en dehors de son contexte

 

Pour qu’un lien soit explicite hors contexte, son intitulé doit permettre d’en connaître et d’en comprendre la fonction et la destination. C’est-à-dire :

  • Quel objet va-t-on afficher ou déclencher ?

On doit pouvoir comprendre s’il va s’agir de l’affichage d’une page Web, du téléchargement d’un fichier, ou de la génération d’un évènement par un script.

  • Quel sera le contenu de cet objet ?

On doit pouvoir comprendre les informations qu’on va trouver en cliquant sur le lien.

 

Qu’appelle-t-on intitulé de lien ?

 

C’est toute l’information textuelle comprise entre :

<a href= »… »>   et   </a>

que ce soit du texte proprement dit ou le contenu de l’attribut alt d’une image, ou la combinaison deux.

 

Il existe 3 différents types de liens, donc 3 types d’intitulés de lien :

  • Lien texte :lien composé uniquement de texteDans ce cas l’intitulé du lien est :

<a href= »… »>Intitulé du lien</a>

 

  • Lien image: lien qui entoure une image seule, sans texte (image cliquable). Dans ce cas l’intitulé du lien est le contenu de l’alternative textuelle de l’image :

<a href= »… »><img src= »… » alt= »Intitulé du lien » /></a>

NB : si l’attribut alt est vide, cela équivaut à un lien vide (sans intitulé).
Il faut  donc toujours renseigner le alt de ces images.

  1. Lien composite : lien composé d’au moins 2 éléments de types différents, par exemple du texte et une ou plusieurs images :

<a href= »… »>Lorem ipsum dolor sit amet<img src= »… » alt= »Consectetur adipiscing elit » /></a>

Dans ce cas l’intitulé du lien est l’ensemble du texte proprement dit, ajouté au contenu de l’alternative textuelle de l’image (ou des images), ce qui donne, avec l’exemple ci-dessus :

Intitulé du lien = Lorem ipsum dolor sit amet’ + ‘Consectetur adipiscing elit

 

Si le lien ne peut pas être explicite par son intitulé seul, on peut alors avoir recours au contexte du lien pour déterminer si celui-ci est explicite dans son contexte.

 

Qu’appelle-t-on contexte du lien ?

Ce sont les informations supplémentaires qui peuvent être mises en relation avec l’intitulé du lien, comme un titre précédent, le texte du paragraphe contenant le lien, un item de liste précédent, une cellule d’en-tête (de tableau) correctement liée…

Les liens pour lesquels on est obligé de faire appel au contexte pour en déterminer le caractère explicite ou non sont les liens du type Lire la suite, En savoir plus, Lire l’article, Cliquez ici, etc.

 

Exemples de contexte de liens :

 

  1. 1.      Un titre en tant que contexte :

<h2>Ce titre appartient au contexte du lien ‘lire la suite’</h2>
<p>Lorem ipsum dolor sits amet, consectetur adipiscing elit. Donec mi sapien, tristique vitae semper <a href=’…’>Lire la suite</a></p>

  1. 2.      Un paragraphe en tant que contexte :

<p>Ce paragraphe fait aussi partie du contexte du lien ‘lire la suite’

<a href=’…’>Lire la suite</a>

</p>

  • 3. Un item de liste en tant que contexte :

<ul>

<li></li>

<li>Ce texte appartient au contexte du lien ‘Cliquez ici’

<a href=’…’>Cliquez ici</a>

</li>

<li>…</li>

</ul>

 

2. Cas particulier des fichiers en téléchargement

 

L’intitulé d’un lien vers un fichier en téléchargement doit idéalement spécifier le nom du fichier (le nom ou le titre correspondant au contenu du fichier, pas le nom sous lequel celui-ci est enregistré), le format du fichier et son poids.

 

Exemples :

 

  1. 1.      Toutes les informations sont dans l’intitulé du lien (idéalement) :

<p><a href=’…’>Charte graphique de la société X (PDF, 40 ko)</a></p>

  1. 2.      Le format et le poids sont dans le contexte du lien (à défaut) :

<p><a href=’…’>Charte graphique de la société X</a>(PDF, 40 ko)</p>

Si le document est rédigé dans une langue étrangère, l’intitulé doit idéalement préciser cette langue.

On reprend les dispositions précédentes en ajoutant la mention de la langue.

Exemples :

 

  1. 1.      Toutes les informations sont dans l’intitulé du lien :

<p><a href=’…’> Charte graphique de la société X (Version anglaise, PDF, 40 ko)</a></p>

  1. 2.      La langue est spécifiée dans le contexte du lien :

<p><a href=’…’> Charte graphique de la société X</a> (Version anglaise, PDF, 40 ko) </p>

 

3. Cas particulier de l’ouverture dans une nouvelle fenêtre

L’utilisateur doit être informé de l’ouverture d’un lien dans une nouvelle fenêtre, idéalement dans l’intitulé du lien.

Exemples :

 

  1. 1.      La mention « nouvelle fenêtre » est dans l’intitulé du lien :

<p><a href=’…’> Charte graphique de la société X (PDF 40 ko, nouvelle fenêtre)</a></p>

  1. 2.      La mention « nouvelle fenêtre » est dans le contexte du lien :

<p><a href=’…’ title=’Charte graphique de la société X’> Charte graphique de la société X</a> (Nouvelle fenêtre, PDF 40 ko) </p>

4. Un lien doit être visuellement identifiable

 

Lorsqu’un lien se situe en dehors des zones qui lui sont habituellement dédiées (Barres de navigation,  listes de liens (par exemple dans un encart d’une colonne contextuelle),  pieds de page, etc.) et qu’il est noyé dans un texte, on doit pouvoir différencier le texte proprement dit des liens textes.

On peut alors donner au lien une couleur différente, mais pas seulement : il est préférable d’utiliser en substitution ou en complément d’autres moyens que sont : le soulignement, le surlignement, le soulignement-surlignement, un effet de bordure (pleine, en pointillé,…) etc.

D’une manière générale, y compris pour les liens qui sont dans les zones dédiées évoquées plus haut, il faudra aussi pouvoir visuellement différencier le lien qui reçoit le focus du lien en état normal (sans focus).

Exemple :

En résumé, on doit pouvoir visuellement distinguer les trois aspects textuels suivants :

  • Le texte proprement dit
  • Les liens textes sans le focus
  • Le lien texte qui reçoit le focus

 

5. Que faire de l’attribut title ?

Il ne faut jamais utiliser de title au contenu vide (title=’’), et ne jamais utiliser de title reprenant exactement l’intitulé du lien.

L’attribut title ne doit être utilisé que s’il est nécessaire pour expliciter le lien et il doit dans ce cas reprendre l’intitulé du lien en y ajouter une information complémentaire.

Dans le Référentiel Accessiweb,  la recommandation de la thématique « Liens » préconise d’utiliser le moins possible l’attribut title :

« Donner des intitulés de lien explicites, grâce à des informations de contexte notamment, et utiliser le titre de lien le moins possible […] ».

Avant d’utiliser l’attribut title, il convient donc de vérifier deux points :

  •     Vérifier si l’intitulé du lien est explicite hors contexte (Voir 1.) ;
  •     Si ce n’est pas le cas, vérifier si le contexte du lien peut permettre d’expliciter le lien.

Ainsi, on ne mettra un attribut title que s’il apporte une information complémentaire visant à expliciter le lien, quand tous les autres moyens à disposition n’ont pas permis d’expliciter le lien.

 

NB : les lecteurs d’écran, en fonction de leur type et/ou du réglage de leurs paramètres peuvent ne pas retranscrire l’attribut title. 

 

6. Quelles balises pour agencer les liens ?

 

Deux exemples fréquents :

 

1. Pour un ensemble de liens consécutifs (horizontaux ou verticaux), privilégier une liste :

<ul>

<li><a href=’’>Intitulé du lien 1</a></li>

<li><a href=’’>Intitulé du lien 2</a></li>

<li><a href=’’>Intitulé du lien 3</a></li>

<li><a href=’’>Intitulé du lien 4</a></li>

</ul>

2. Pour un lien seul ou directement environné de texte, privilégier un paragraphe :

  • Lien seul :

<p><a href=’’>Intitulé du lien</a></p>

  • Lien directement environné de texte :

<p>Lorem ipsum dolor sits amet, consectetur adipiscing elit. Donec mi sapien, tristique vitae semper <a href=’’>Intitulé du lien</a></p>