Cet article est destiné aux utilisateurs d’un système de gestion de contenu (Content Management System en anglais) et aux webmestres.

Quelques clarifications pour débuter :

• chaque image doit avoir un attribut alt
• chaque attribut alt ne doit pas être renseigné par du texte
• l’attribut alt n’est pas une légende de l’image
• pour faire apparaître un texte au survol d’une image, il faut utiliser l’attribut title.

Alors comment écrire le texte de l’attribut alt ?

Réponse : en fonction de la raison d’être de l’image et pas nécessairement de son contenu.

Images informatives

Faire le test du téléphone : essayer de lire la page web à quelqu’un au téléphone, est-ce que l’information contenue dans l’image est suffisamment importante pour que vous la mentionnez ? Si oui, il faut écrire le texte de l’attribut alt. Si non, l’image n’a pas besoin de texte et son code sera <img src="image.jpg" alt="" />.
Exemple : page de présentation du Pdg avec une photo, cette image contient une information (à quoi ressemble le pdg), alors on écrira pour l’attribut alt : Photo de M X, Pdg.

Images décoratives

C’est facile, si l’image est purement décorative alors la balise alt doit être laissée vide <img src="image.jpg" alt="" />.

Encore mieux, le webmestre peut la retirer du code HTML et la mettre en image de fond dans la feuille de style CSS.

Images de texte

Répéter le texte de l’image.

Images complexes

Il s’agit des graphes et de tout ce qui ne peut se résumer en quelques mots, alors il faut écrire l’attribut alt du style « graphe montrant la croissance régulière du chiffre d’affaires sur ces 5 dernières années » et soit inscrire la description complète à côté de l’image ou ajouter à l’image l’attribut longdesc avec cette description en plusieurs lignes.

Précisions destinées principalement aux webmestres :

Images fonctionnelles

Le texte de l’attribut alt doit correspondre à la fonction de l’image. Pour des liens, il s’agit de la destination du lien (accueil, produit, contact), pour le bouton d’un formulaire à sa fonction (rechercher, annuler) et pour un logo (nom_de_la_société accueil si c’est un lien vers sa page d’accueil ou juste nom_de_la_société si c’est un lien vers un autre site web). pas besoin d’écrire le mot « logo ».

Images de layout

Elles devraient être remplacées par des feuilles de style, mais sinon laisser l’attribut alt vide.

Images structurelles

À remplacer par la feuille de style, mais si elles existent alors inscrire leur nature structurelle dans l’attribut alt (bullet, * ou -).

Image Maps

Chaque image a besoin de texte pour l’attribut alt, ainsi que les éléments AREA.
L’image principale pourrait être quelque chose comme « carte des arrondissements de Paris » et les élements AREA auraient un attribut alt selon la règle pour les images fonctionnelles.

Cet article est une traduction / interprétation de l’article Better Connected, Better Results: Alt Text de Ann du Royal National Institute of Blind People

Les handicaps affectant la vision sont très souvent évoqués en matière d’accessibilité web. Les handicaps moteurs le sont moins. Pourtant, de multiples pathologies sont à l’origine de ce type de handicaps : attaques cérébrales, maladie de Parkinson, sclérose en plaques, tétraplegies, hémiplégies… On estime que les handicapés moteurs représentent environ 60% (PDF) de la population handicapée en France. Webcredible publie ce mois-ci un article sur l’amélioration de l’accessibilité pour ces utilisateurs.

Bref résumé des recommandations :

• Maximisez la taille de la zone cliquable des liens.
• Indiquez visuellement le focus sur les liens, afin que l’utilisateur puisse identifier le lien sur le point d’être visité.
• Proposez une lien d’évitement visible, pour permettre l’accès direct au contenu.
• Evitez de jouer automatiquement des fichiers audio, qui peuvent interférer avec les commandes vocales de certains utilisateurs
• Evitez en général d’utiliser l’attribut tabindex. Conservez l’ordre de tabulation par défaut.
• N’utilisez pas les access keys.

Les deux derniers points sont controversés car ils font partie de la norme et sont faciles à tester automatiquement. Pourtant les tabindex engendrent fréquemment des problèmes de collision (2 liens ont le même tabindex, l’un est dans la navigation, l’autre dans le corps de l’article) et des problèmes de « masquage » (un lien important car contextuel n’a pas de tabindex et apparaît donc qu’à la suite d’une longue liste de liens déjà connus). Les access keys posent fréquemment le problème des collisions avec les raccourcis d’autres applications. De plus les gouvernements ont choisi systématiquement des raccourcis clavier différents, certains impossibles à réaliser. Le plus sage est donc d’avoir un contenu clair et de respecter l’ordre naturel des liens, ainsi que de conserver ce même ordre sur l’ensemble des pages.

• 358 erreurs sur la validation XHTML
• 160 erreurs sur l’accessibilité et 641 avertissements, rien que pour la norme WAI Priorité 1

Il est difficile de faire un site répondant parfaitement aux standards et respectant toutes les normes d’accessibilité et surtout de le maintenir dans ce respect, néanmoins un effort sérieux doit être fait en ce sens dans l’intérêt de ceux qui ont besoin d’applications spéciales (agrandisseurs d’écran, lecteurs vocaux, etc.) pour partager les contenus et participer au débat.

Il n’est pas n’ont plus trop tard pour bien faire ; des actions correctrices peuvent être mises en oeuvre rapidement.

L’accès au web aux personnes handicapées et le respect des normes de développement ne doivent pas être seulement du ressort du prestaire, mais doivent être réellement une préoccupation du donneur d’ordre qui doit effectuer les tests et refuser de signer la recette en cas d’échec de la même manière que lorsque que la couleur du logo ne lui convient pas.

Lien vers l’Université de Washington (en anglais) : http://www.cs.washington.edu/research/MobileASL/

Sign Language On Your Cellphone: « 

With the help of a grant from the National Science Foundation, researchers at the University of Washington and Cornell are working on software to help transmit compressed video of sign language using cellphones.

MobileASL is a video compression project at the University of Washington with the goal of making wireless cell phone communication through sign language a reality.

The current wireless telephone network has inadvertently excluded over one million deaf or hard of hearing Americans.

With the advent of cell phone PDAs with larger screens and photo/video capture, people who communicate with American Sign Language (ASL) could utilize these new technologies. However, due to the low bandwidth of the wireless telephone network, even today’s best video encoders likely cannot produce the quality video needed for intelligible ASL. Instead, a new real time video compression scheme is needed to transmit within the existing wireless network while maintaining video quality that allows users to understand semantics of ASL with ease. For this technology to exist in the immediate future, the MobileASL project is designing new ASL encoders that are compatible with the new H.264/AVC compression standard using x264 (nearly doubling compression ratios of MPEG-2). The result will be a video compression metric that takes into account empirically validated visual and perceptual processes that occur during conversations in ASL.

This material is based upon work supported by the National Science Foundation under Grant No. 0514353.

• la navigation doit précéder le contenu : ce qui va à l’encontre des recommandations d’experts
• le titre de page fait trop souvent double emploi avec la balise h1
• la taille de la police compte bien sûr, mais aussi sa graisse

Peu d’enquêtes terrains sont malheureusement publiées et il en faudrait bien d’autres pour émettre les recommendations d’avantage à partir d’usages réels que de discussions d’experts.
A lire aussi, les réactions de Shirley Kaiser sur son blog Brainstorm and Raves