Indication du format des fichiers à télécharger et accessibilité

12 commentaires

Publié le 19 mars 2013 par Johan Ramon

Ce billet est le premier d’une série de trois portant sur l’accessibilité des liens vers des fichiers à télécharger.

Une recommandation d’accessibilité demande à ce que chaque lien pointant vers un fichier en téléchargement informe du format, du poids et éventuellement de la langue de ce dernier.

Je vous propose aujourd’hui de nous intéresser à l’indication du format du fichier en exposant, dans un premier temps, les bénéfices pour les utilisateurs ; puis, dans un second, en listant plusieurs possibilités graphiques et techniques d’y parvenir.

Avant d’entrer dans le vif du sujet, précisons que cette préconisation d’accessibilité s’applique aux liens pointant vers tous les types de fichier à télécharger.

Cela concerne donc notamment :

  • Les documents bureautiques.
  • Les fichiers audio et vidéo.
  • Les images.
  • Les fichiers compressés.

À noter que cette recommandation est étroitement liée à celle portant sur la rédaction d’intitulés de liens explicites (externe).

Bénéfices pour les utilisateurs

De manière générale, indiquer le format d’un fichier en téléchargement informe l’utilisateur de la nature du lien qu’il rencontre.

Il est ainsi prévenu qu’il n’est pas face à un lien « classique » et, qu’en l’utilisant, il ne sera pas dirigé vers une autre page ou un emplacement précis de la page courante (système d’ancre).

Concrètement, grâce à cette information, l’utilisateur est averti du changement de contexte que provoquera l’activation de ce type de lien ; à savoir : le téléchargement d’un fichier ou sa consultation dans un logiciel ou plug-in spécialisé.

Cette recommandation d’accessibilité, comme de nombreuses autres d’ailleurs, est profitable à tous les utilisateurs.

Par exemple, aux personnes :

  • Ne disposant pas du matériel et/ou du logiciel leur permettant d’exploiter le fichier.
    Ce renseignement leur évitant de le télécharger alors qu’il ne pourrait le consulter ou l’utiliser.
  • Non ou mal-voyantes utilisant un lecteur d’écran.
    Cette information leur permettant d’anticiper le fait que leur navigation sera « interrompue ».

Sans la mise à disposition de ces indications, la navigation peut rapidement devenir désagréable pour l’utilisateur. Tout comme, au passage, l’absence de signalement des liens s’ouvrant dans une nouvelle fenêtre (externe).

Intéressons-nous maintenant aux différentes possibilités graphiques et moyens techniques de présenter cette indication.

Présentation du format du fichier à télécharger

Sous forme de texte

Sans plus attendre, focus sur la méthode la plus efficace et robuste !
Il s’agit d’intégrer cette information sous forme de texte, en suffixe de l’intitulé du lien comme par exemple :

Code HTML :

<a href="#">Nom du fichier en téléchargement (<abbr>PDF</abbr>)</a>

À noter qu’il est vivement recommandé d’intégrer cette mention directement dans l’intitulé du lien.

Si elle est présentée à l’extérieur de la balise <a>, cette indication ne sera pas atteignable aisément par les utilisateurs de lecteur d’écran ; ces derniers devant, dans ce cas de figure, prendre connaissance du contexte du lien pour obtenir cette précieuse information.

Au delà de l’accessibilité, cela peut également être considéré comme une bonne pratique en terme d’ergonomie. Car intégrer cette indication directement dans l’intitulé du lien étendra de surcroît sa zone de clic.

Apparence de cette indication

Si souhaité, il est possible de styler cette indication différemment du nom du fichier à télécharger comme par exemple :

Ici, le traitement graphique de cette indication s’est résumé à :

Sous forme d’image

Une autre possibilité consiste à présenter cette information sous forme d’image.

Attention, si vous optez pour cette solution, veillez à ne pas intégrer cette image en CSS (via la propriété background-image) car cette indication serait perdue dans le cas où les styles et/ou les images d’arrière-plan ne seraient pas disponibles :

  • Volontairement désactivés par l’utilisateur.
  • Non chargés suite à un problème serveur ou de connexion.
  • Remplacées en une couleur de fond en cas de mode « Contraste élevé » (externe) activé dans le système d’exploitation de l’utilisateur.
  • Etc.

Ce qui ne se produira pas si l’image est placée directement dans le code HTML, avec un texte de remplacement (attribut alt) correctement renseigné.

Donc concrètement, une implémentation valide du point de vue de l’accessibilité serait par exemple :

Code HTML :

<a href="#">Nom du fichier en téléchargement <img alt="PDF" title="PDF" src="pdf.png" /></a>

À noter que la présence de l’attribut title dans la balise <img /> n’est pas requise en matière d’accessibilité.

Toutefois, nous vous recommandons de l’ajouter (mais davantage pour des raisons ergonomiques) car si le pictogramme utilisé n’est pas connu ou reconnu par l’utilisateur, son infobulle s’affichant au survol à la souris pourrait lui en préciser le sens.

Limites de cette méthode

Bien que cette méthode soit totalement valide du point de vue de l’accessibilité, on peut lui trouver quelques légers inconvénients :

  • Le pictogramme ne s’agrandit pas lorsque la taille des caractères est augmentée par l’utilisateur (en mode zoom texte seulement). Cette indication peut donc être difficilement perceptible dans ce contexte de consultation.
  • Le pictogramme utilisé ne sera pas forcément connu ou reconnu de tous.
    A priori, le pictogramme « PDF » (et ses variantes) est fréquemment utilisé donc potentiellement compris par la plupart des personnes.
    Mais qu’en est-il des pictogrammes « Excel   Powerpoint   RAR » ou d’autres encore moins communs et répandus ?
  • Pour les contributeurs, si ce pictogramme ne peut pas être intégré automatiquement par l’outil de publication utilisé (CMS), cela peut-être fastidieux de l’ajouter manuellement, bien plus que sous forme de texte.

Dans l’attribut title du lien

Il est également possible d’inclure cette indication dans l’attribut title du lien comme par exemple :

Pour que cette méthode soit considérée comme valide, il faut impérativement que le nom du fichier à télécharger soit également présent dans cet attribut title.

Code HTML :

<a href="#" title="Nom du fichier en téléchargement (PDF)">Nom du fichier en téléchargement</a>

Cette solution n’est pas optimale, le contenu de l’attribut title n’étant pas disponible dans tous les cas de figure :

  • Sans survoler le lien (et attendre patiemment l’affichage de l’infobulle), l’utilisateur passera à côté de cette information.
  • L’utilisateur naviguant exclusivement au clavier n’aura pas accès à cette indication, l’infobulle ne s’affichant pas à la prise de focus du lien.
  • Il en est de même pour les personnes naviguant sur périphériques mobiles (smartphones ou tablettes) ; sur certains d’entre-eux, l’infobulle ne s’affichant pas au toucher.
  • L’utilisateur de lecteur d’écran, l’ayant configuré pour restituer uniquement les intitulés de liens (contenu entre les balises <a> et </a>), ne disposera pas de cette information. De plus, certains lecteurs d’écran ne restituent jamais le contenu de l’attribut title.

Ce pourquoi, de manière générale, il est préférable d’éviter d’utiliser l’attribut title pour expliciter les liens (externe).

Via du texte caché

Enfin, une dernière possibilité (hors utilisation d’ARIA) consiste à placer cette indication dans l’intitulé du lien ; mais, cette fois, en la masquant à l’écran comme par exemple :

Attention, si vous optez pour cette technique, n’utilisez pas les propriétés CSS « display: none; » et/ou « visibility: hidden; » pour cacher cette mention car elle ne serait pas restituée aux utilisateurs de revue d’écran.

La technique appropriée consiste donc à sortir ce contenu de l’écran comme par exemple :

Code HTML :

<a href="#">Nom du fichier en téléchargement <span class="masquer">(PDF)</span></a>

Code CSS :

.masquer {
   position: absolute;
   left: -99999px;
}

En l’état, cette solution est loin d’être idéale, cette indication n’étant ici transmise que lorsque les CSS sont désactivés ou aux personnes aveugles ou mal-voyantes se servant d’un lecteur d’écran.

Néanmoins, des optimisations sont envisageables pour afficher cette indication dans tous les contextes de navigation. Les voici présentées ci-après.

Affichage au survol et à la prise de focus clavier

En déclarant quelques propriétés CSS aux pseudo-classes « :hover » et « :focus » , il est respectivement possible d’afficher cette mention au survol et à la prise de focus du lien comme par exemple :

Cette méthode est d’ailleurs prescrite par le W3C pour signaler les liens déclenchant l’ouverture d’une nouvelle fenêtre (externe) (technique WCAG G201 – en anglais) et mise en pratique sur cette démonstration : Pop-Up Warning (externe).

Mais, tout comme celle du title, cette solution impose à l’utilisateur de survoler le lien pour avoir accès à cette information. Ce qui, selon nous, n’est pas idéal pour l’anticipation de la navigation.

Affichage sur périphériques mobiles

Pour remédier au fait que les utilisateurs sur smartphones ou tablettes ne peuvent accéder à cette information cachée, une solution peut consister à la rendre visible par défaut sur ces périphériques.

L’intervention technique à prévoir est assez simple et légère.
Il suffit, via Media-Queries (RWD) (externe), de forcer l’affichage de cette indication sur ces supports de consultation.

Concrètement, il s’agit, à partir d’une certaine résolution d’écran, de surcharger les propriétés initialement appliquées à cette mention.

Ce qui donne par exemple, en reprenant notre classe CSS « .masquer » de tout à l’heure :

@media screen and (max-width: 640px) {
  .masquer {
     position: static;
  }
}

Toute la difficulté de cette « parade » résidant dans le choix de la résolution maximale à cibler…

Conclusion

Il existe donc plusieurs possibilités plus ou moins efficaces pour indiquer le format d’un fichier à télécharger. Information qui, pour rappel, informera l’utilisateur de la nature du lien et du changement de contexte qu’entrainera son activation : rendant par conséquent sa navigation plus agréable.

Bien que toutes les solutions présentées soient tout à fait valides du point de vue de l’accessibilité, force est de constater que la plus efficace en la matière s’avère être la solution la plus simple ; soit, présenter le format du fichier à télécharger sous forme de texte visible intégré directement dans l’intitulé du lien.

Seulement, cette mention seule n’est pas suffisante pour assurer l’accessibilité de ce type de liens. Pour d’autres raisons, il est également attendu de spécifier le poids et (éventuellement) la langue de ces fichiers à télécharger.

Ces indications, tout aussi importantes, vous seront détaillées dans deux prochains billets.

Ressources

Vos commentaires

  • Par Vincent De Oliveira, le 19 mars 2013 à 18h21.

    Merci pour ces infos.
    Qu’en est-il de l’utilisation des pseudo-éléments, combinés aux sélecteurs d’attributs ?

    Pour des fichiers PDF:

    a[href*=.pdf]:after{
    content: '(PDF)';
    }
    

    Pour des liens externes au site:

    a:not([href*=blog.atalan.fr]):after{
    content: url('image.png');
    }
    

    Est-ce une bonne pratique ? Sont-ils correctement restitués par les lecteurs d’écrans ?

    Répondre

  • Par Sébastien Delorme, le 19 mars 2013 à 19h41.

    Bonjour Vincent,

    Si ces deux solutions sont très pratiques, elles ne sont malheureusement pas accessibles.

    Pour les fichiers PDF, cette information ne sera pas restituée par les lecteurs d’écran. Il peut toutefois être envisagé de l’utiliser en doublon avec la solution du texte caché proposée dans l’article.

    Même remarque pour les liens externes puisqu’il s’agit d’une image qui ne disposera pas d’alternative.

    Répondre

    • Par Vincent De Oliveira, le 19 mars 2013 à 21h26.

      Merci pour cette réponse.

      Pour l’image, je me doutais oui, mais je pensais quand même que l’information textuelle de «content» aurait pu être lue.

      Dommage. :(

      Répondre

    • Par Johan Ramon, le 20 mars 2013 à 9h49.

      À noter que NVDA (v. 2012.3) restitue bien les textes générés en CSS.

      Ce qui n’est pas le cas pour JAWS (testé sur la version 11).

      Répondre

      • Par Olivier Nourry (@OlivierNourry), le 20 mars 2013 à 13h30.

        Hello,
        il fallait bien se douter que les TA finiraient par lire le contenu généré en CSS.
        Néanmoins, les use cases où les CSS ne sont soit pas appliquées, soit pas restituées, sont bien trop nombreux pour que l’on puisse transmettre une information (au sens: contenu « utile ») via CSS sans exclure une partie des internautes (et ça va bien sûr au-delà de la problématique des lecteurs d’écran, et même de l’accessibilité).

      • Par Villain, le 20 mars 2013 à 15h11.

        Je ne suis pas certain que le fait que des AT particulières vocalisent ou pas des contenus générés ou calculés via CSS change beaucoup la situation.
        Les méthodes à base de contenus générés ou calculés par CSS restent incompatibles avec l’accessibilité, au sens de WCAG, autrement qu’à des fins purement décoratives.
        A moins d’utiliser des baselines restrictives comme celles utilisées en environnement maitrisé.
        Si la situation du contenu généré est relativement simple à contrôler avec un gros baton, la possibilité d’opérer sur du contenu via du calcul CSS est autrement plus problématique.
        Les possibilités très sophistiquées de CSS3 permettent des manipulations surprenantes. On commence même à trouver des drôles d’idées où les directives CSS sont utilisées pour patcher l’accessibilité d’un contenu.
        Un contenu généré fondé sur une extension de fichier calculé via CSS (comme dans le commentaire de Vincent) ou l’utilisation de technique WCAG comme C7 (rendre un lien explicite via du texte caché en alternative de title) sont deux exemples de ce genre d’approches.
        Il reste simplement à souhaiter que tout le monde continue de considérer que CSS devrait rester confiné à la couche de présentation.
        A moins de considérer, ce qui reste possible, que le support de CSS est requis pour l’affichage de contenu Web comme ce que nous allons devoir faire en HTML5 pour JavaScript.

        JPV

  • Par Johan Ramon, le 20 mars 2013 à 14h12.

    @Olivier Complétement d’accord.

    Toutefois, je pense que cette solution doit être conservée dans un petit coin de notre tête pour la préconiser/l’utiliser en dernier recours.

    Par exemple pour améliorer un site en ligne à moindre coût pour lequel il n’est pas envisageable de re-prévoir du développement ou une reprise des contenus.

    Répondre

    • Par Villain, le 20 mars 2013 à 16h01.

      Ha ben du coup mon premier commentaire à été mal aiguillé.

      Donc j’en profite pour en rajouter une couche : il y à une tendance qui commence à émerger qui consiste justement à imaginer des méthodes de patchs au lieu de méthode de réparation.
      Je n’ai rien contre ces méthodes qui peuvent être très poussées jusqu’à devenir des services très élaborés comme amaze de deque.
      En HTML5 par exemple on va utiliser massivement JavaScript et ARIA pour patcher et améliorer l’accessibilité.
      Javascript étant le langage dédié au développement HTML5 c’est légitime et d’autant plus que JavaScript est compatible avec l’accessibilité.
      En revanche pour CSS la situation est très différente puisque ce langage n’est pas compatible avec l’accessibilité. Partant de là, un patch fondé sur CSS, faute de disposer d’une alternative compatible, n’est pas accessible.
      Certes on améliore quelque chose (ergonomie, qualité, tout ce qu’on veut) mais pas l’accessibilité.
      Il me semble important de garder ça aussi dans un petit coin de notre tête pour éviter les malentendus.

      JPV

      Répondre

  • Par Armony, le 20 mars 2013 à 16h04.

    CSS, c’est pour la présentation. WCAG 2 n’autorise pas la restitution de texte par CSS. Dont acte.

    Mais on sait très bien que les recos évoluent au rythme des évolutions technologiques. Comment demander une alternative à JS quand HTML 5 est piloté par JS ?!

    Le fait que NVDA prenne l’initiative de restituer du texte généré en CSS ouvre de nouvelles perspectives. Il est sûr que les recos ne bougeront pas de sitôt, mais il est important de s’intéresser à l’utilisateur avant tout et donc de faire une veille pour savoir ce qu’il en est.

    Bon ou mauvais, l’avenir nous le dira. Mais après tout, pourquoi pas ? Je serais plutôt favorable à garder un œil sur ces évolutions, quitte à ce que cela contredise tout ce qu’on a pu dire jusqu’ici (cf discours sur JS).

    Mais ne me faites pas dire ce que je n’ai pas dit. À l’heure actuelle, un texte généré en CSS n’est tout simplement pas accessible, c’est certain. Mais demain, qui sait ?

    Répondre

    • Par Villain, le 20 mars 2013 à 17h41.

      WCAG 2 ne se prononce pas sur le contenu généré (on n’a pas de failure par exemple).
      D’un point de vue plus technique l’information en contenu généré est bien disponible via les APIs d’access, même si il existe des cas où l’accessible name c’est juste ‘PDF » dans l’exemple du commentaire.
      Donc la méthode du contenu généré ne pose, à priori, pas de soucis et c’est sans doute la raison pour laquelle certains imaginent (il y à des discussion intéressantes à ce sujet dans les listes W3C) pouvoir utiliser du contenu généré comme patch.
      En revanche c’est le support de CSS qui pose (en tout cas qui me pose pour être précis) un soucis.
      A partir du moment où l’affichage d’un contenu Web est fondé sur le principe de séparation du contenu, de la structure et de la présentation, un contenu généré à partir de la couche de présentation me semble, intrinsèquement, non compatible avec l’accessibilité.
      Et pour reprendre le parallèle avec Javascript on a pas ce soucis avec du patch JS/ARIA en HTML5 où le cas d’utilisation JS désactivé devient quasiment vide de sens alors que le cas de consultation CSS désactivé doit être considéré comme un cas légitime, il correspond à l’architecture de base d’un contenu HTML.

      JPV

      Répondre

  • Par Xavier Zalawa, le 21 mars 2013 à 14h53.

    Bonjour Johan,
    Je tiens d’abord à te remercier pour cet excellent article et ceux qui viendront l’étayer.
    A mon sens, cette recommandation « simple » devrait faire partie des bases (tous corps de métiers confondus). Celle-ci est malheureusement trop souvent (voir toujours) oubliée/négligée par beaucoup. La faute aux CMS peut être.

    Tes arguments viennent compléter avec beaucoup de maturité la publication de Frédéric Cavazza faite en 2010 : Comment bien formater un lien vers un fichier PDF ?. L’article certes succinct est suivi de commentaires enrichissants.

    Dans tes propositions, à aucun moment tu ne fais référence à l’attribut type de l’élément HTML <a>. Considères-tu celui-ci comme inutile ?

    Je me permets, car comme tu soulignes l’abréviation du mot « Portable Document Format » par la balise HTML <abbr>, pourquoi ne pas accompagner l’identification le format du fichier cible avec cet attribut ?

    L’extension n’est pas toujours représentative du format ;)

    Répondre

    • Par Johan Ramon, le 26 mars 2013 à 12h14.

      Bonjour Xavier,

      Merci pour ton commentaire et le lien vers la publication. Effectivement, les commentaires de ce dernier sont très intéressants.

      Je n’ai pas mentionné l’attribut type car, sauf erreur de ma part, il n’a pas d’impact sur l’accessibilité ; tout du moins, intégré dans une balise <a>.

      Oui, les extensions de fichiers comme « PDF » , « RAR » ou encore « AVI » ne sont pas toujours représentatifs et probablement pas connus de tous. Cependant, je ne suis pas certain que le fait de fournir leur version déployée tel que respectivement « Portable Document Format » , « Roshal ARchive » ou « Audio Video Interleave » les rendent davantage explicites.

      Pour tenter de remédier à cela, une solution peut être d’indiquer quelque part sur le site quels sont les logiciels permettant de consulter ou d’exploiter les différents types de fichiers proposés en téléchargement.
      Un peu comme ce qui est écrit dans la page d’ aide de ce blog au sujet de la consultation des documents PDF (externe) par exemple.

      Répondre

Ajouter un commentaire

Les champs avec astérisque (*) sont obligatoires.

Haut de page