TOUT Cette catégorie contient toutes les règles. 508 accessibilité

Cette catégorie contient les 508 règles spécifiées par l'Accessibility Board (http://www.access-board.gov/sec508/508standards.htm).

Pour de plus amples informations, vous pouvez également consulter la brève formation sur l'accessibilité, disponible à l'adresse http://www.jimthatcher.com/webcourse1.htm, et le guide d'auto-évaluation à l'adresse http://www.usdoj.gov/crt/508/web.htm.

Accessibilité P.1 W3C/WCAG Cette catégorie contient les règles sur l'accessibilité (priorité 1) spécifiées par le groupe W3C/WAI (http://www.w3.org/TR/WAI-WEBCONTENT). Consultez les références du WAI à l'adresse http://www.w3.org/WAI/References pour de plus amples informations sur les problèmes d'accessibilité au Web. Accessibilité P.2 W3C/WCAG Cette catégorie contient les règles sur l'accessibilité (priorité 2) spécifiées par le groupe W3C/WAI (http://www.w3.org/TR/WAI-WEBCONTENT). Consultez les références du WAI à l'adresse http://www.w3.org/WAI/References pour de plus amples informations sur les problèmes d'accessibilité au Web. images Cette catégorie contient les règles relatives aux images incorporées dans des documents HTML. manuel Cette catégorie contient les règles nécessitant une inspection manuelle des documents HTML. formulaires Cette catégorie contient les règles traitant des FORMULAIREs et des éléments connexes. cadres Cette catégorie contient les règles traitant des CADREs et des éléments connexes. tableaux Cette catégorie contient les règles traitant des TABLEAUx et des éléments connexes. cartes graphiques Cette catégorie contient les règles traitant des cartes graphiques. scripts Cette catégorie contient les règles traitant des objets de programmation. liens Cette catégorie contient des règles régissant les images comprenant des liens et des barres de navigation. méta Cette catégorie contient les règles régissant les éléments META des documents HTML. css Cette catégorie contient les tests en rapport avec les feuilles de style en cascade. suggestions Cette catégorie contient les règles proposant plusieurs utilisations du service en ligne LIFT sur le site www.usablenet.com. IMG sans image d'espacement avec un ALT valide nspIMGwValidALT 4 Section 508 1194.22(a); WAI / WCAG 1.0 checkpoint 1.1 Accessibilité P.1 W3C/WCAG 508 accessibilité images TOUT

Les images contenues dans ce document n'ont aucune description textuelle valide correspondante. Une description valide est une valeur de chaîne de l'attribut ALT qui :

  • n'est pas une chaîne vide ("") ;
  • n'est pas une chaîne avec un ou plusieurs espaces (" ") ;
  • n'est pas le nom du fichier contenant l'image ;
  • n'indique pas uniquement la taille du fichier d'image ;
  • n'est pas une chaîne de plus de 150 caractères (il s'agit d'une simple suggestion, et non d'une obligation WCAG 1.0 ou 508).

Le rôle de l'image n'est pas seulement décoratif (c.-à-d. elle ne constitue pas une image d'espacement).

Aucun texte ALT défini pour l'image. Le texte ALT de l'image doit être vide ou vierge, ce qui n'est pas le cas. Le texte ALT de l'image est la chaîne vide "". Le texte ALT de l'image est la chaîne vierge "". Le texte ALT de l'image contient des balises HTML. Le texte ALT de l'image est trop long. Le texte ALT de l'image décrit uniquement la taille du fichier image. Le texte ALT de l'image décrit uniquement le nom du fichier de l'image. Le texte ALT de l'image semble contenir uniquement du texte de l'espace réservé.

L'attribut ALT décrit l'image à laquelle il se réfère pour permettre aux utilisateurs dont le navigateur ne prend pas en charge les graphiques de pouvoir quand même parcourir la page. L'émergence des navigateurs texte-seul portatifs rend l'utilisation de descriptions ALT plus importante que jamais.

Quant aux liens masqués (les balises A normales dont l'étiquette constitue une image d'espacement), il importe que l'attribut ALT de l'image existe et qu'il décrive la destination du lien. (La technique des liens masqués peut être utilisée pour répondre à la norme 508, paragraphe 1194.22(o), selon laquelle "il convient de trouver une méthode qui permette aux utilisateurs de passer outre les liens de navigation répétitifs", et au point de contrôle WAI 13.6.)

Les descriptions ALT s'affichent avant l'image à laquelle elles se réfèrent, ce qui est utile lorsque le téléchargement et l'affichage de l'image elle-même demandent plusieurs secondes.

L'insertion de mots-clés dans l'attribut ALT peut aussi améliorer la façon dont les pages sont répertoriées dans certains moteurs de recherche.

Pour les images qui ne jouent qu'un rôle décoratif dans la page (telles que les images d'espacement et les puces), il est recommandé de définir une chaîne ALT vide (c.-à-d. ALT="" ) pour éviter que les navigateurs ne gênent les utilisateurs en insérant des caractères du type "*" ou ">".

Ajoutez l'attribut ALT à la balise IMG. Rappelez-vous les points suivants :

  • La description doit expliquer le rôle de l'image dans la page. Imaginez que vous écoutiez le contenu de la page et la description de l'image au téléphone
  • Si l'image sert de contenu d'un lien et que vous fournissez aussi le texte du lien, utilisez un espace comme valeur de l'attribut ALT de l'élément IMG. Dans ce cas, le texte du lien doit constituer la description secondaire de l'image
  • Soyez concis. Pensez que les images telles que les logos se répètent sur toutes les pages du site et que les internautes vont devoir écouter la même description maintes et maintes fois
  • En bref, utilisez le même texte affiché par l'image pour les boutons
  • Comme les descriptions ALT ne sont pas interprétées par les navigateurs, il est préférable de n'y inclure aucune balise HTML. Les balises incorporées ne peuvent qu'embrouiller les utilisateurs, ainsi que les moteurs de recherche
  • Les descriptions ALT trop longues risquent d'être tronquées par les navigateurs et augmentent le temps de téléchargement de la page. En règle générale, il vaut mieux utiliser moins de 10 mots et 64 caractères
  • Les images utilisées uniquement dans un but décoratif (par exemple, les images d'espacement) doivent comprendre une chaîne ALT vide ("") pour que les lecteurs d'écran les ignorent. Il en va de même pour les images servant de puces
  • ATTENTION : l'attribut ALT doit constituer la chaîne vide ("") pour les cas où l'image serait déjà décrite par le texte périphérique
  • ATTENTION : il est indispensable que les images incluses dans les liens (y compris les images GIF transparentes) soient toutes accompagnées d'un attribut ALT valide décrivant la destination du lien
IMG d'espacement avec ALT valide spIMGwValidALT 4 Section 508 1194.22(a); WAI / WCAG 1.0 checkpoint 1.1 Accessibilité P.1 W3C/WCAG 508 accessibilité images TOUT

Dans ce document, les images qui semblent être décoratives uniquement (images d'espacement) n'ont pas de description textuelle valide correspondante. Une description textuelle valide constitue une chaîne vierge ou vide en guise de valeur pour l'attribut ALT.

Aucun texte ALT défini pour l'image d'espacement. Le texte ALT de l'image d'espacement doit être vide ou vierge, ce qui n'est pas le cas.

L'attribut ALT décrit l'image à laquelle il se réfère pour permettre aux utilisateurs dont le navigateur ne prend pas en charge les graphiques de pouvoir quand même parcourir la page. Les utilisateurs mal ou non-voyants n'ayant cure des images à rôle décoratif uniquement, toute description textuelle dans ce cas est donc inutile.

En outre, les navigateurs à commande vocale ou les lecteurs d'écran ne vont pas gêner les utilisateurs si le texte ALT reflète une chaîne vierge ou vide. Une chaîne vierge est composée d'un ou plusieurs espaces, comme par exemple " ". Une chaîne vide ne contient aucun espace, comme par exemple "".

L'attribut ALT doit être défini même si la valeur constitue une chaîne vierge ou vide. Sans cela, un lecteur d'écran ou un navigateur à commande vocale risque d'y insérer le nom du fichier d'image, par exemple, créant ainsi une gêne tandis que l'utilisateur écoute la page.

Ajoutez l'attribut ALT à la balise IMG.

Pour une image d'espacement, la valeur de l'attribut ALT doit être une chaîne vierge (" ") ou vide (""), mais doit exister. Le même principe s'applique aux images utilisées en tant que puces.

IMG sans image d'espacement avec ALT équivalent nspIMGwEquivalentALT 4 Section 508 1194.22(a); WAI / WCAG 1.0 checkpoint 1.1 Accessibilité P.1 W3C/WCAG 508 accessibilité images manuel TOUT

Le rôle de l'image n'est pas seulement décoratif (c.-à-d. elle ne constitue pas une image d'espacement). Elle doit disposer d'une description textuelle équivalente.

L'attribut ALT décrit l'image à laquelle il se réfère pour permettre aux utilisateurs dont le navigateur ne prend pas en charge les graphiques de pouvoir quand même parcourir la page.

La description doit fournir les mêmes informations que celles de l'image et expliquer le rôle de ladite image dans la page : pourquoi elle est là, ce qu'elle représente et comment elle présente l'information.

Si l'image est utilisée à l'intérieur d'un lien masqué (à savoir, une balise A normale avec une image d'espacement en tant qu'étiquette), son attribut ALT doit alors décrire la destination du lien. Le contenu ALT correspond à tout ce que les navigateurs non graphiques affichent pour un lien masqué. (La technique des liens masqués peut être utilisée pour répondre à la norme 508, paragraphe 1194.22(o), selon laquelle "il convient de trouver une méthode qui permette aux utilisateurs de passer outre les liens de navigation répétitifs", et au point de contrôle WAI 13.6.)

Notez que l'insertion d'une bonne description secondaire au niveau des images est très importante de nos jours vu que nombre d'utilisateurs ne peuvent profiter des graphiques, comme par exemple les utilisateurs de téléphones portables, d'un PDA et des ordinateurs de voitures.

Assurez-vous que la description ALT en cours fournit la signification de l'image.

La description doit expliquer le rôle que l'image joue dans la page : pourquoi elle est là, ce qu'elle constitue, comment elle présente l'information. Imaginez que vous écoutiez la description au téléphone.

Si l'image sert de contenu d'un lien et que vous fournissez aussi le texte du lien, utilisez un espace comme valeur de l'attribut ALT de l'élément IMG. Dans ce cas, le texte du lien doit constituer la description secondaire de l'image.

Si l'image sert de lien masqué, son attribut ALT doit alors décrire la destination du lien.

Si l'image n'a qu'un rôle décoratif (par exemple, les images utilisées en guise de puces ou d'images d'espacement), la chaîne ALT doit rester vide ("") ou vierge (" ").

IMG sans image d'espacement avec LONGDESC valide nspIMGwValidLongdesc 4 Section 508 1194.22(a); WAI / WCAG 1.0 checkpoint 1.1 Accessibilité P.1 W3C/WCAG 508 accessibilité images TOUT

L'image comprend un attribut LONGDESC considéré comme non valide pour l'une des raisons suivantes :

  • Il pointe vers un fichier ou une ressource Web inexistant.
  • Il pointe vers une ressource non-HTML.
Attribut LONGDESC non valide : le fichier mentionné n'existe pas. Attribut LONGDESC non valide : le fichier mentionné n'est pas au format HTML. Attribut LONGDESC non valide : le fichier mentionné est vide. Attribut LONGDESC non valide : son URL est caduque. Attribut LONGDESC non valide : le serveur a renvoyé un message d'erreur pour cette URL. Attribut LONGDESC non valide : il ne s'agit pas d'un fichier local ni d'une URL HTTP.

L'attribut ALT ne peut servir à fournir une description longue du contenu d'une image. Prenez l'exemple d'un diagramme, d'un histogramme, d'un tableau ou de l'image d'un produit dans un catalogue en ligne. Pour décrire son contenu, il vous faut davantage de souplesse.

L'attribut LONGDESC peut servir à fournir une longue description de l'image à laquelle il se réfère. En incluant l'attribut LONGDESC="n_importe_quel_fichier HTML" dans votre balise IMG, vous pouvez relier l'image au fichier HTML où figure une description mise en forme de l'image. La longue description (à l'inverse de l'attribut ALT) peut contenir un code HTML, avec des liens vers d'autres ressources, des instructions de mise en forme et plus encore.

Toutefois, compte tenu du petit nombre de navigateurs actuellement capables de prendre en charge l'attribut LONGDESC, il peut être aussi utile d'insérer une liaison D près de l'image. Une liaison D est un lien textuel normal pourvu d'une étiquette "D" pointant vers une page HTML où figure une description complète de l'image. Exemple :

  <IMG src="chart.gif" alt="tableau de la distribution des
  boissons" longdesc="chart.html"><A
  href="chart.html">D</A>

L'introduction d'une description au format RTF telle qu'une légende près de l'image peut s'avérer une solution tout aussi viable. Dans ce cas, l'attribut LONGDESC ou la liaison D deviennent inutiles.

L'insertion d'une bonne description secondaire au niveau des images est très importante de nos jours vu que nombre d'utilisateurs ne peuvent profiter des graphiques, comme par exemple les utilisateurs de téléphones portables, d'un PDA et des ordinateurs de voitures.

Vérifiez le fonctionnement du lien spécifié par l'attribut LONGDESC.

Compte tenu du petit nombre de navigateurs actuellement capables de prendre en charge l'attribut LONGDESC, il peut être aussi utile d'insérer une liaison D près de l'image. Une liaison D est un lien textuel normal pourvu d'une étiquette "D" pointant vers une page HTML où figure une description complète de l'image. Exemple :

  <IMG src="chart.gif" alt="tableau de la distribution des
  boissons" longdesc="chart.html"><A
  href="chart.html">D</A>

L'introduction d'une description au format RTF telle qu'une légende près de l'image peut s'avérer une solution tout aussi viable. Dans ce cas, l'attribut LONGDESC ou la liaison D deviennent inutiles.

Aucun attribut LONGDESC pour la balise IMG d'espacement spIMGwNoLongdesc 2 Section 508 1194.22(a); WAI / WCAG 1.0 checkpoint 1.1 Accessibilit&eacute; P.1 W3C/WCAG 508 accessibilité images TOUT

L'image dispose d'un attribut LONGDESC bien qu'elle s'affiche à des fins décoratives uniquement.

Les images décoratives n'ont nul besoin de longues descriptions.

L'image d'espacement contient un attribut LONGDESC superflu.

L'attribut LONGDESC permet de fournir une longue description de l'image à laquelle il se réfère lorsque l'attribut ALT ne suffit pas. Il est par exemple utile lorsque l'image représente un tableau ou diagramme qui demande souvent de longues explications.

Cependant, pour les images utilisées à des fins décoratives uniquement, une longue description est inutile et peut même parfois se révéler gênante pour les internautes qui utilisent des navigateurs pourvus de cette fonctionnalité.

Supprimez l'attribut LONGDESC de la balise IMG.

IMG sans image d'espacement nécessitant LONGDESC nspIMGneedsLongdesc 4 Section 508 1194.22(a); WAI / WCAG 1.0 checkpoint 1.1 Accessibilit&eacute; P.1 W3C/WCAG 508 accessibilité images manuel TOUT

L'image ne contient pas d'attribut LONGDESC pointant vers un fichier HTML où figure une description détaillée de l'image.

L'image (autre qu'espacement) a peut-être besoin d'un attribut LONGDESC.

L'attribut ALT ne peut servir à fournir une description longue du contenu d'une image. Prenez l'exemple d'un diagramme, d'un histogramme, d'un tableau ou de l'image d'un produit dans un catalogue en ligne. Pour décrire son contenu, il vous faut davantage de souplesse.

L'attribut LONGDESC peut servir à fournir une longue description de l'image à laquelle il se réfère. En incluant l'attribut LONGDESC="n_importe_quel_fichier HTML" dans votre balise IMG, vous pouvez relier l'image au fichier HTML où figure une description mise en forme de l'image. La longue description (à l'inverse de l'attribut ALT) peut contenir un code HTML, avec des liens vers d'autres ressources, des instructions de mise en forme et plus encore.

Toutefois, compte tenu du petit nombre de navigateurs actuellement capables de prendre en charge l'attribut LONGDESC, il peut être aussi utile d'insérer une liaison D près de l'image. Une liaison D est un lien textuel normal pourvu d'une étiquette "D" pointant vers une page HTML où figure une description complète de l'image. Exemple :

  <IMG src="chart.gif" alt="tableau de la distribution des
  boissons" longdesc="chart.html"><A
  href="chart.html">D</A>

L'introduction d'une description au format RTF telle qu'une légende près de l'image peut s'avérer une solution tout aussi viable. Dans ce cas, l'attribut LONGDESC ou la liaison D deviennent inutiles.

L'insertion d'une bonne description secondaire au niveau des images est très importante de nos jours vu que nombre d'utilisateurs ne peuvent profiter des graphiques, comme par exemple les utilisateurs de téléphones portables, d'un PDA et des ordinateurs de voitures.

Assurez-vous que l'image présente des informations qui n'apparaissent ni dans la page ni dans l'équivalent textuel de l'image (à savoir, dans son attribut ALT).

Si la description de l'image fournit des informations supplémentaires qui ne figurent pas déjà dans le texte de la page, elle est nécessaire. La quantité d'informations dans l'image et le contexte dans lequel elles seront utilisées détermineront le niveau de détail de la description.

Toutefois, compte tenu du petit nombre de navigateurs actuellement capables de prendre en charge l'attribut LONGDESC, il peut être aussi utile d'insérer une liaison D près de l'image. Une liaison D est un lien textuel normal pourvu d'une étiquette "D" pointant vers une page HTML où figure une description complète de l'image. Exemple :

  <IMG src="chart.gif" alt="tableau de la distribution des
  boissons" longdesc="chart.html"><A
  href="chart.html">D</A>

L'introduction d'une description au format RTF telle qu'une légende près de l'image peut s'avérer une solution tout aussi viable. Dans ce cas, l'attribut LONGDESC ou la liaison D deviennent inutiles.

INPUT avec ALT valide INPUTwValidALT 4 Section 508 1194.22(a); WAI / WCAG 1.0 checkpoint 1.1 Accessibilit&eacute; P.1 W3C/WCAG 508 accessibilité images formulaires TOUT

L'image utilisée en guise de bouton dans le formulaire ne contient pas une description textuelle valide.

L'image n'a pas d'attribut LONGDESC qui la relie à un fichier HTML où figure une description détaillée non adaptée à l'attribut ALT. Une description valide est une valeur de chaîne de l'attribut ALT, autre que les suivantes :

  • une chaîne vide ("") ;
  • une chaîne vierge contenant un espace ou plus (" ") ;
  • le nom du fichier d'image ;
  • la taille du fichier d'image ;
  • une chaîne de plus de 150 caractères (il s'agit d'une simple suggestion, et non d'une obligation WCAG 1.0 ou 508).
Aucun texte ALT défini pour l'image du bouton. Le texte ALT de l'image du bouton doit être vide ou vierge, ce qui n'est pas le cas. Le texte ALT de l'image du bouton est la chaîne vide "". Le texte ALT de l'image du bouton est la chaîne vierge "". Le texte ALT de l'image du bouton est trop long. Le texte ALT de l'image du bouton contient des balises HTML. Le texte ALT de l'image du bouton décrit uniquement la taille du fichier image. Le texte ALT de l'image du bouton décrit uniquement le nom de fichier de l'image. Le texte ALT de l'image du bouton semble contenir uniquement du texte de l'espace réservé.

L'attribut ALT décrit l'image à laquelle il se réfère pour permettre aux utilisateurs dont le navigateur ne prend pas en charge les graphiques de pouvoir quand même parcourir la page. L'émergence des navigateurs texte-seul portatifs rend l'utilisation de descriptions ALT plus importante que jamais.

Si l'image du bouton est dépourvue d'une description textuelle, les utilisateurs dont le navigateur ne prend pas en charge les graphiques n'auront pas la moindre idée de ce qui résultera d'un clic sur ce bouton.

Attention à un autre problème :

Lorsque vous sélectionnez l'image au moyen de la souris, les coordonnées du formulaire et du clic sont envoyées au serveur.

Si le serveur agit en fonction de l'endroit où le clic a eu lieu, les utilisateurs de navigateurs ne prenant pas en charge les graphiques seront désavantagés. Pour cette raison, il convient d'envisager des méthodes alternatives, comme ce qui suit :

  • Utilisez plusieurs boutons d'envoi (chacun avec sa propre image) plutôt qu'un seul et unique bouton graphique. Le cas échéant, vous pouvez vérifier le positionnement desdits boutons au moyen de feuilles de style.
  • Utilisez une carte graphique côté client, ainsi qu'un langage de script.

Ajoutez l'attribut ALT à l'élément INPUT, tout en gardant les points suivants à l'esprit :

  • La description doit expliquer les effets découlant d'un clic sur le bouton
  • Les descriptions ALT ne sont pas interprétées par les navigateurs et ne doivent pas inclure de balises HTML. Les balises incorporées déconcertent les utilisateurs, parfois même les moteurs de recherche.
  • Les descriptions ALT trop longues risquent d'être tronquées par les navigateurs et augmentent le temps de téléchargement de la page. En règle générale, il vaut mieux utiliser moins de 10 mots et 64 caractères.

Sachez que les coordonnées du formulaire et du clic sont soumises au serveur lorsque vous sélectionnez l'image au moyen de la souris. Si le serveur agit en fonction de l'endroit où le clic a eu lieu, les utilisateurs de navigateurs ne prenant pas en charge les graphiques seront désavantagés. Pour cette raison, il convient d'envisager des méthodes alternatives, comme ce qui suit :

  • Utilisez plusieurs boutons d'envoi (chacun avec sa propre image) plutôt qu'un seul et unique bouton graphique. Le cas échéant, vous pouvez vérifier le positionnement desdits boutons au moyen de feuilles de style.
  • Utilisez une carte graphique côté client, ainsi qu'un langage de script.
INPUT avec ALT équivalent INPUTwEquivalentALT 4 Section 508 1194.22(a); WAI / WCAG 1.0 checkpoint 1.1 Accessibilit&eacute; P.1 W3C/WCAG 508 accessibilité images manuel formulaires TOUT

L'image utilisée en guise de bouton dans le formulaire est pourvue d'une description valide.
Elle doit avoir une description textuelle équivalente.

L'attribut ALT décrit l'image à laquelle il se réfère pour permettre aux utilisateurs dont le navigateur ne prend pas en charge les graphiques de pouvoir quand même parcourir la page. L'émergence des navigateurs texte-seul portatifs rend l'utilisation de descriptions ALT plus importante que jamais.

Si l'image du bouton est dépourvue d'une description textuelle équivalente, les utilisateurs dont le navigateur ne prend pas en charge les graphiques n'auront pas la moindre idée de ce qui résultera d'un clic sur ce bouton.

Attention à un autre problème. Les coordonnées du formulaire et du clic sont envoyées au serveur lorsque vous sélectionnez l'image au moyen de la souris. Si le serveur agit en fonction de l'endroit où le clic a eu lieu, les utilisateurs de navigateurs ne prenant pas en charge les graphiques seront désavantagés. Pour cette raison, il convient d'envisager des méthodes alternatives, comme ce qui suit :"

  • Utilisez plusieurs boutons d'envoi (chacun avec sa propre image) plutôt qu'un seul et unique bouton graphique. Le cas échéant, vous pouvez vérifier le positionnement desdits boutons au moyen de feuilles de style.
  • Utilisez une carte graphique côté client, ainsi qu'un langage de script.

Testez le contenu de l'attribut ALT de l'élément INPUT.
Rappelez-vous que la description doit expliquer les effets découlant d'un clic sur le bouton.

Sachez que les coordonnées du formulaire et du clic sont soumises au serveur lorsque vous sélectionnez l'image au moyen de la souris. Si le serveur agit en fonction de l'endroit où le clic a eu lieu, les utilisateurs de navigateurs ne prenant pas en charge les graphiques seront désavantagés. Pour cette raison, il convient d'envisager des méthodes alternatives, comme ce qui suit :

  • Utilisez plusieurs boutons d'envoi (chacun avec sa propre image) plutôt qu'un seul et unique bouton graphique. Le cas échéant, vous pouvez vérifier le positionnement desdits boutons au moyen de feuilles de style.
  • Utilisez une carte graphique côté client, ainsi qu'un langage de script.
FRAME avec LONGDESC valide FRAMEwValidLongdesc 4 Section 508 1194.22(a); WAI / WCAG 1.0 checkpoint 1.1 Accessibilit&eacute; P.1 W3C/WCAG 508 accessibilité cadres TOUT

L'attribut LONGDESC du cadre n'est pas valide, pour l'une des raisons suivantes :

  • Il pointe vers un fichier ou une ressource Web inexistant.
  • Il pointe vers une ressource non-HTML.
Attribut LONGDESC non valide : le fichier mentionné n'existe pas. Attribut LONGDESC non valide : le fichier mentionné n'est pas au format HTML. Attribut LONGDESC non valide : le fichier mentionné est vide. Attribut LONGDESC non valide : son URL est caduque. Attribut LONGDESC non valide : le serveur a renvoyé un message d'erreur pour cette URL. Attribut LONGDESC non valide : il ne s'agit pas d'un fichier local ni d'une URL HTTP.

L'attribut LONGDESC peut être utilisé pour fournir une description longue d'une balise FRAME associée lorsque l'attribut TITLE ne peut pas contenir la description. Ce serait le cas, par exemple, si le cadre contenait simplement une image, sans texte autour.

L'attribut LONGDESC décrit le contenu du cadre, pour que les personnes utilisant un navigateur texte puissent comprendre aisément les éléments de la page. L'émergence des navigateurs texte-seul portatifs rend l'utilisation de descriptions textuelles plus importante que jamais.

Le W3C/WAI déconseille d'insérer une image directement dans un cadre (pour en comprendre les raisons, reportez-vous à la page http:www.w3.org/TR/REC-html40/present/frames.html#h-16.4.2) ; il est préférable que le cadre pointe vers un fichier HTML distinct incluant ladite image et un texte explicatif.

Assurez-vous que le lien spécifié par l'attribut LONGDESC fonctionne normalement.

Le W3C/WAI déconseille l'utilisation de l'attribut LONGDESC pour les images cadrées et suggère plutôt de faire pointer le cadre vers un fichier HTML séparé, comprenant l'image et un texte explicatif.

SCRIPT avec NOSCRIPT valide SCRIPTwValidNOSCRIPT 4 Section 508 1194.22(a); WAI / WCAG 1.0 checkpoint 1.1 Accessibilit&eacute; P.1 W3C/WCAG 508 accessibilité scripts TOUT manuel

L'élément SCRIPT n'est pourvu d'aucun élément NOSCRIPT valide associé :

  • Un élément NOSCRIPT doit suivre immédiatement l'élément SCRIPT
  • Le contenu de l'élément NOSCRIPT ne doit pas rester vide. Il peut inclure n'importe quelle instruction HTML.

Notez que la norme 508 n'exige pas que tous les éléments SCRIPT soient suivis de leurs éléments NOSCRIPT correspondants (il s'agit cependant d'une technique suggérée dans WAI WCAG 1.0). Selon la norme 508, dès lors que les pages font usage de langages de script pour afficher un contenu ou pour créer des éléments d'interface, il importe que les informations fournies par le script soient identifiées par un texte fonctionnel qu'une technologie d'assistance doit être capable de déchiffrer.
Deux types de scripts requièrent une attention toute particulière et l'utilisation de la balise NOSCRIPT peut s'avérer pertinente :

  • Survols : s'il modifie une image à l'écran au moment où l'utilisateur déplace le curseur sur l'image et s'il n'indique pas (via un texte déchiffrable par un lecteur d'écran) qu'il a changé le contenu de la page, le script ne peut être rendu accessible
  • Scrips ne pouvant pas être activés via le clavier : si l'événement qui déclenche le script ne peut être activé via le clavier, le script ne peut être rendu accessible
NOSCRIPT manquant : aucun NOSCRIPT ne suit le SCRIPT. NOSCRIPT non valide : le NOSCRIPT est vide.

L'attribution de l'équivalent textuel à un élément SCRIPT peut s'effectuer à l'aide d'un élément NOSCRIPT. La restitution du contenu de cet élément se fait quand les scripts ne sont pas activés.

L'élément NOSCRIPT permet aux développeurs d'offrir un autre contenu pour le cas où un script ne serait pas exécuté. Seul un agent utilisateur compétent en matière de script est habilité à procéder à la restitution du contenu d'un élément NOSCRIPT dans les conditions suivantes :

  • Le navigateur est configuré pour ne pas évaluer les scripts
  • Le navigateur ne prend pas en charge le langage sollicité par le script

Les utilisateurs de lecteurs d'écran et de navigateurs à commande vocale ne pourront tirer parti des scripts susceptibles d'affecter l'interface graphique d'une page Web.

Les utilisateurs ne faisant usage ni d'une souris ni d'une manette ne pourront tirer parti des scripts qui ouvrent fenêtres, boîtes de dialogue et menus.

Notez qu'il existe de nombreux autres cas dans lesquels l'exécution des scripts par les navigateurs n'est pas possible et que cela s'intensifiera à l'avenir. Notamment :

  • Les PDA et les téléphones portables non compatibles avec l'exécution des scripts
  • Les navigateurs sous divers systèmes d'exploitation (comme Windows, Mac OS, Linux) non compatibles avec l'exécution des scripts écrits dans un langage donné. Par exemple, Netscape installé sur une machine Linux ou sur des PDA ne peut exécuter des scripts VBScripts
  • Les utilisateurs de navigateurs graphiques qui désactivent JavaScript pour des raisons de sécurité

Vérifiez que les informations fournies par le script sont également disponibles sous forme de texte qu'une technologie d'assistance peut déchiffrer.

Pour vérifier si un script est accessible, il suffit d'afficher la page dans un navigateur où les scripts et le chargement d'images sont temporairement désactivés (consultez la documentation du navigateur pour savoir comment désactiver les scripts et le chargement d'images).
Une autre approche consiste à manipuler la page sans recourir à la souris (c.-à-d. en tabulant de part et d'autre des éléments et en utilisant le clavier uniquement). Cela permet de vous faire une idée du rôle réel du script dans l'interaction.

Sinon, songez à ajouter un élément NOSCRIPT à l'élément SCRIPT. Il peut contenir n'importe quelle balise HTML. Son contenu doit permettre aux gens qui n'exécutent pas le script de parvenir aux mêmes effets que ceux qui l'exécutent. En particulier, ils doivent pouvoir accéder au même contenu et profiter des mêmes opportunités d'interaction, y compris les liens.

SCRIPT avec NOSCRIPT équivalent SCRIPTwEquivalentNOSCRIPT 4 Section 508 1194.22(a); WAI / WCAG 1.0 checkpoint 1.1 Accessibilit&eacute; P.1 W3C/WCAG 508 accessibilité scripts manuel TOUT

Le script inclus dans ce document comporte un élément NOSCRIPT valide dont le contenu doit être équivalent au script lui-même.

Un élément NOSCRIPT est valide si les conditions suivantes s'appliquent : il existe, il est proche de l'élément SCRIPT auquel il se réfère et il n'est pas vide.

NOSCRIPT trouvé : vérifiez qu'il est bien équivalent.

L'attribution de l'équivalent textuel à un élément SCRIPT peut s'effectuer à l'aide d'un élément NOSCRIPT. La restitution du contenu de cet élément se fait quand les scripts ne sont pas activés.

L'élément NOSCRIPT permet aux développeurs d'offrir un autre contenu pour le cas où un script ne serait pas exécuté. Seul un agent utilisateur compétent en matière de script est habilité à procéder à la restitution du contenu d'un élément NOSCRIPT dans les conditions suivantes :

  • Le navigateur est configuré pour ne pas évaluer les scripts
  • Le navigateur ne prend pas en charge le langage sollicité par le script

Les utilisateurs de lecteurs d'écran et de navigateurs à commande vocale ne pourront tirer parti des scripts susceptibles d'affecter l'interface graphique d'une page Web.

Les utilisateurs ne faisant usage ni d'une souris ni d'une manette ne pourront tirer parti des scripts qui ouvrent fenêtres, boîtes de dialogue et menus.

Notez aussi qu'il existe de nombreux autres cas dans lesquels l'exécution des scripts par les navigateurs n'est pas possible et que cela s'intensifiera à l'avenir. Notamment :

  • Les PDA et les téléphones portables non compatibles avec l'exécution des scripts
  • Les navigateurs sous divers systèmes d'exploitation (comme Windows, Mac OS, Linux) non compatibles avec l'exécution des scripts écrits dans un langage donné. Par exemple, Netscape installé sur une machine Linux ne peut exécuter des scripts VBScripts
  • Les utilisateurs de navigateurs graphiques qui désactivent JavaScript pour des raisons de sécurité

Assurez-vous que le contenu de l'élément NOSCRIPT en cours véhicule les mêmes données que l'élément SCRIPT qui lui correspond.

Le contenu de l'élément NOSCRIPT doit permettre aux personnes qui n'exécutent pas le script d'obtenir les mêmes effets que celles qui l'exécutent. En particulier, ils doivent pouvoir accéder au même contenu et profiter des mêmes opportunités d'interaction, y compris les liens.

NOSCRIPT peut contenir n'importe quelle balise HTML.

AREA avec ALT valide AREAwValidALT 4 Section 508 1194.22(a); WAI / WCAG 1.0 checkpoint 1.1 Accessibilit&eacute; P.1 W3C/WCAG 508 accessibilité images TOUT

La carte graphique incluse dans ce document ne contient pas d'éléments AREA avec des descriptions textuelles valides. Une description valide est une valeur de chaîne pour l'attribut ALT, autre que les suivantes :

  • une chaîne vide ("") ;
  • une chaîne contenant un espace ou plus (" ") ;
  • le nom du fichier image ;
  • la taille du fichier image ;
  • une chaîne contenant plus de 150 caractères (il s'agit d'une simple suggestion, et non une obligation WCAG 1.0 ou 508).
Aucun texte ALT défini pour la région image. Le texte ALT de la région image est la chaîne vide "". Le texte ALT de la région image est la chaîne vierge "". Le texte ALT de la région image est trop long. Le texte ALT de la région image contient des balises HTML. Le texte ALT de la région image décrit uniquement la taille du fichier image. Le texte ALT de la région image décrit uniquement le nom de fichier de l'image. Le texte ALT de la région image semble contenir uniquement du texte de l'espace réservé.

Les attributs ALT permettent de fournir les équivalents textuels des cartes graphiques. Cette étape est importante parce que les cartes graphiques fournissent des informations visuelles essentielles pour la navigation.

L'attribut ALT doit décrire la zone associée à l'image pour que les utilisateurs dont le navigateur ne prend pas en charge les graphiques puissent consulter la page normalement. Sans description ALT, ces utilisateurs ne pourraient pas naviguer dans la carte graphique.

Chaque élément AREA de la carte graphique doit avoir son propre attribut ALT. Exemple (adapté d'un didacticiel disponible à l'adresse : http://www.jimthatcher.com/webcourse2.htm) :

  <IMG src="map.gif" alt="navigation" usemap="#navigation">
  <MAP name="navigation"> <AREA coords="1,1,40,100"
  alt="accueil" href="../index.html"> <AREA coords="1,100,40,180"
  alt="produits" href="products.html"> </MAP>

Comme avec les autres liens, le texte en soi doit être compréhensible hors contexte. Un bon texte de lien ne doit pas être trop général. N'utilisez pas des descriptions telles que "cliquez ici". Non seulement cette expression est spécifique à un périphérique (dispositif de pointage), mais elle ne renseigne en rien sur la page correspondante. Essayez au contraire de définir la nature de la cible. Par exemple, ""plus d'informations sur les otaries"" ou ""version texte de cette page""."

L'émergence des navigateurs texte-seul portatifs rend la description des ALT plus importante que jamais. Songez que de nombreux utilisateurs ont, par choix ou par nécessité, recours à des navigateurs texte-seul équipés de lecteurs d'écran ou de navigateurs vocaux. Il peut s'agir de personnes malvoyantes, de personnes utilisant Internet par téléphone ou de personnes utilisant un navigateur dans leur voiture.

En attendant que les agents puissent restituer le texte équivalent pour les liens de carte graphique côté client, vous pouvez rendre votre page accessible aux utilisateurs qui ne peuvent pas afficher les graphiques, en fournissant un lien texte redondant pour chaque région active d'une carte graphique côté client. En fournissant la description ALT des éléments AREA, votre page est cependant déjà compatible avec ces nouveaux navigateurs.

Ajoutez l'attribut ALT à la balise AREA, tout en gardant les points suivants à l'esprit :

  • La description doit expliquer la destination du lien ou pourquoi l'utilisateur voudra l'utiliser.
  • Ne mentionnez pas les mécanismes, tels que "cliquer ici" ; décrivez plutôt la destination du lien et son rôle pour l'utilisateur.
  • Les descriptions ALT ne sont pas interprétées par les navigateurs et ne doivent pas inclure de balises HTML. Les balises incorporées déconcertent les utilisateurs, parfois même les moteurs de recherche.
  • Les descriptions ALT trop longues risquent d'être tronquées par les navigateurs et augmentent le temps de téléchargement de la page. En règle générale, il vaut mieux utiliser moins de 10 mots et 64 caractères.
AREA avec ALT équivalent AREAwEquivalentALT 4 Section 508 1194.22(a); WAI / WCAG 1.0 checkpoint 1.1 Accessibilit&eacute; P.1 W3C/WCAG 508 accessibilité images manuel TOUT

La carte graphique incluse dans ce document contient des éléments AREA avec des descriptions textuelles valides.
Ces descriptions doivent être équivalentes à la carte graphique.

Les attributs ALT permettent de fournir les équivalents textuels des cartes graphiques. Cette étape est importante parce que les cartes graphiques fournissent des informations visuelles essentielles pour la navigation.

L'attribut ALT doit décrire la zone associée à l'image pour que les utilisateurs dont le navigateur ne prend pas en charge les graphiques puissent consulter la page normalement. Sans description d'ALT équivalente, ces utilisateurs ne pourraient pas naviguer dans la carte graphique.

Comme avec les autres liens, le texte en soi doit être compréhensible hors contexte. Un bon texte de lien ne doit pas être trop général. N'utilisez pas des descriptions telles que "cliquez ici". Non seulement cette expression est spécifique à un périphérique (dispositif de pointage), mais elle ne renseigne en rien sur la page correspondante. Essayez au contraire de définir la nature de la cible. Par exemple, ""plus d'informations sur les otaries"" ou ""version texte de cette page""."

L'émergence des navigateurs texte-seul portatifs rend la description des ALT plus importante que jamais. Songez que de nombreux utilisateurs ont, par choix ou par nécessité, recours à des navigateurs texte-seul équipés de lecteurs d'écran ou de navigateurs vocaux. Il peut s'agir de personnes malvoyantes, de personnes utilisant Internet par téléphone ou de personnes utilisant un navigateur dans leur voiture.

En attendant que les agents puissent restituer le texte équivalent pour les liens de carte graphique côté client, vous pouvez rendre votre page accessible aux utilisateurs qui ne peuvent pas afficher les graphiques, en fournissant un lien texte redondant pour chaque région active d'une carte graphique côté client. En fournissant la description ALT des éléments AREA, votre page est cependant déjà compatible avec ces nouveaux navigateurs.

Testez l'attribut ALT de la balise AREA, tout en gardant les points suivants à l'esprit :

  • La description doit expliquer la destination du lien ou pourquoi l'utilisateur voudra l'utiliser.
  • Ne mentionnez pas les mécanismes, tels que "cliquer ici" ; décrivez plutôt la destination du lien et son rôle pour l'utilisateur.
La couleur n'est pas essentielle DontRelyOnColorAlone 4 Section 508 1194.22(c); WAI / WCAG 1.0 checkpoint 2.1 Accessibilit&eacute; P.1 W3C/WCAG 508 accessibilité manuel TOUT

La page contient des couleurs. Aussi, veillez à ce que les informations contenues dans la page ne soient pas de couleur identique.

Il arrive souvent qu'une personne ne puisse pas voir certaines couleurs. Il peut s'agir des problèmes suivants :

  • Mauvais choix de couleurs pour le premier ou l'arrière-plan de la page.
  • Personnes utilisant un navigateur textuel.
  • Personnes écoutant un navigateur vocal.
  • Personnes utilisant un écran noir et blanc, tel qu'un PDA ou un téléphone portable.
  • Personnes daltoniennes
  • Personnes malvoyantes ou non-voyantes

Les couleurs d'une page doivent être utilisées uniquement pour améliorer l'esthétique ou le graphisme de la page. Elles ne doivent jamais être porteuses d'informations.

Veillez à ce que la page soit clairement compréhensible même si ses utilisateurs ne peuvent pas identifier ou différencier certaines couleurs.

Voici un moyen aisé de tester la page :

  • Affichez la page sur un écran noir et blanc et passez chaque élément en revue.
  • Imprimez la page sur une imprimante noire et blanc.
  • Numérisez la page et faites une recherche sur des termes tels que "appuyez sur le bouton rouge".
Les couleurs sont visibles ColorsAreVisible 4 Section 508 1194.22(c); WAI / WCAG 1.0 checkpoint 2.2 Accessibilit&eacute; P.1 W3C/WCAG 508 accessibilité manuel TOUT

La page utilise des couleurs. Il se peut que le contraste entre les couleurs de premier et d'arrière plan ne suffise pas à les différencier.

Il arrive souvent qu'un mauvais choix de couleurs affecte la perception et la compréhension des informations ou des images d'une page. Il peut s'agir des problèmes suivants :

  • Mauvais choix des couleurs pour le premier et l'arrière-plan.
  • La personne utilise un écran incapable de restituer les couleurs avec la même qualité que celle utilisée par le concepteur de la page.
  • L'utilisateur accède à la page via un PDA noir et blanc ou un téléphone portable.
  • L'utilisateur a besoin d'imprimer la page sur une imprimante noire et blanc.
  • L'utilisateur est daltonien.

Veillez à ce que les couleurs et les éléments colorés de la page ressortent toujours de leur entourage, quel que soit le contexte d'affichage de la page. Veillez à ce que le contraste entre les éléments de premier et d'arrière-plan soit garantit par d'autres facteurs que la couleur, par exemple le style, le corps ou l'œil de la police.

Voici un moyen aisé de tester la page :

  • Affichez la page sur un écran noir et blanc et passez chaque élément en revue.
  • Imprimez la page sur une imprimante noire et blanc.
  • Photocopiez cet imprimé deux ou trois fois pour voir quelles sont les parties qui s'estompent. Vous identifiez ainsi les endroits qui ont besoin d'être améliorés (les liens soulignés par exemple), ceux qui sont trop petits ou illisibles.
Les feuilles de style ne devraient pas être nécessaires StyleSheetsNotNecessary 4 Section 508 1194.22(d); WAI / WCAG 1.0 checkpoint 6.1 Accessibilit&eacute; P.1 W3C/WCAG 508 accessibilité manuel TOUT

La page requiert l'usage de feuilles de style en cascade (CSS). Assurez-vous que tout internaute peut comprendre et parcourir la page sans que des spécifications de style ne soient appliquées.

La page utilise des feuilles de style pour présenter son contenu. Il se peut que certains navigateurs ne puissent pas lire les feuilles de styles ou que ces dernières soient incompatibles avec les informations de style spécifiées par l'utilisateur.

Les feuilles de style en cascade (CSS) permettent de séparer le contenu et sa structure de la présentation. Un contenu organisé de façon logique est habituellement restitué dans un ordre sensé lorsque les feuilles de style sont désactivées ou non prises en charge. Dans certains cas, les feuilles de style en cascade peuvent pourtant entraver la situation, limitant l'accessibilité à une page Web.

Par exemple, les anciens navigateurs ne prennent pas en charge les feuilles de style en cascade et les auteurs de documents Web ne peuvent donc pas utiliser des styles pour véhiculer les informations ou activer la navigation. Aussi, les informations de style définies par l'utilisateur (comme le corps et la couleur) ne devraient pas être affectées par les styles spécifiés dans la page.

Assurez-vous que le document demeure lisible sans feuilles de style.

Des liens sont nécessaires pour une carte graphique côté serveur RdndtLnksSSimagemap 4 Section 508 1194.22(e); WAI / WCAG 1.0 checkpoint 1.2 Accessibilit&eacute; P.1 W3C/WCAG 508 accessibilité cartes graphiques manuel TOUT

La page inclut une carte graphique côté serveur. Vérifiez que chaque région active de la carte graphique dispose d'un lien textuel redondant.

La page semble contenir une carte graphique côté serveur. Chacune de ses régions actives doit disposer d'un lien redondant correspondant dans la page.

Les cartes graphiques côté serveur posent d'importants problèmes d'accessibilité, notamment :

  • Les cartes graphiques côté serveur requièrent l'usage de périphériques d'entrée spécifiques, tels que la souris, dont les utilisateurs peuvent être dépourvus (par exemple, les utilisateurs de téléphones portables ou de navigateurs à commande vocale)
  • Certaines personnes, dans certaines circonstances, peuvent ne pas être en mesure de cliquer avec précision sur la carte (par exemple, les personnes handicapées ou les personnes en train de marcher ou qui se tiennent debout)
  • Les liens spécifiés par les cartes graphiques côté serveur étant masqués dans le serveur, ils ne peuvent être manipulés d'aucune façon par les navigateurs, y compris la technologie d'assistance. Par conséquent, le navigateur ne peut communiquer aucun lien secondaire à l'utilisateur
  • Les cartes graphiques côté serveur sont moins efficaces que leurs homologues côté client compte tenu de l'interaction supplémentaire avec le serveur nécessaire à chaque clic de l'utilisateur

Pour ces raisons, l'usage de cartes graphiques côté serveur est vivement déconseillé. Exception sera faite pour les régions actives dont les formes sont si irrégulières que les cartes graphiques côté client ne peuvent les prendre en charge.

Assurez-vous que chaque région active de la carte graphique est dupliquée sous la forme d'un lien redondant dans la page. Il vous faut inspecter la mise en œuvre de la carte graphique sur le serveur pour déterminer les URL qui sont activées lorsque l'utilisateur clique sur l'une des régions actives.

Aucune carte graphique côté serveur ne doit être utilisée NoServerSideImageMaps 4 Section 508 1194.22(f); WAI / WCAG 1.0 checkpoint 9.1 Accessibilit&eacute; P.1 W3C/WCAG 508 accessibilité manuel cartes graphiques TOUT

La page inclut une carte graphique côté serveur. Vérifiez que la carte graphique peut être remplacée par une carte graphique côté client plus accessible.

La page semble contenir une carte graphique côté serveur. Pouvez-vous la convertir en carte graphique côté client ? A moins que la carte définisse des régions qui ne peuvent pas être spécifiées avec les formes géométriques disponibles, remplacez-la par une carte graphique côté client.

Les cartes graphiques côté serveur posent d'importants problèmes d'accessibilité, notamment :

  • Les cartes graphiques côté serveur requièrent l'usage de périphériques d'entrée spécifiques, tels que la souris, dont les utilisateurs peuvent être dépourvus (par exemple, les utilisateurs de téléphones portables ou de navigateurs à commande vocale)
  • Certaines personnes, dans certaines circonstances, peuvent ne pas être en mesure de cliquer avec précision sur la carte (par exemple, les personnes handicapées ou les personnes en train de marcher ou qui se tiennent debout)
  • Les liens spécifiés par les cartes graphiques côté serveur étant masqués dans le serveur, ils ne peuvent être manipulés d'aucune façon par les navigateurs, y compris la technologie d'assistance. Par conséquent, le navigateur ne peut communiquer aucun lien secondaire à l'utilisateur
  • Les cartes graphiques côté serveur sont moins efficaces que leurs homologues côté client compte tenu de l'interaction supplémentaire avec le serveur nécessaire à chaque clic de l'utilisateur

Pour ces raisons, l'usage de cartes graphiques côté serveur est vivement déconseillé. Exception sera faite pour les régions actives dont les formes sont si irrégulières que les cartes graphiques côté client ne peuvent les prendre en charge.

Pour reconnaître une carte graphique côté serveur à l'aide d'un navigateur, pointez la souris vers l'image. Les coordonnées de la souris sont affichées par le navigateur au fur et à mesure que vous la bougez sur l'image.

Déterminez si la carte graphique côté serveur est vraiment indispensable. Elle s'avère indispensable uniquement si vous devez définir des régions actives autrement impossibles à définir avec les formes disponibles. Si vous devez en utiliser une, pensez à proposer d'autres moyens tels que les liens textuels pour atteindre les mêmes pages de destination. (Vous devez inspecter la mise en œuvre de la carte graphique sur le serveur pour savoir comment les régions actives sont définies.)

Le tableau des données doit comporter des en-têtes TableWithHeaders 4 Section 508 1194.22(g); WAI / WCAG 1.0 checkpoint 5.1 Accessibilit&eacute; P.1 W3C/WCAG 508 accessibilité manuel tableaux TOUT

La page comprend un tableau dont aucune cellule spécifique n'est identifiée comme en-tête (c.-à-d. marquée d'une balise TH). Si le tableau sert à présenter des données, ajoutez-lui des en-têtes.

La page contient un tableau pouvant être utilisé pour présenter des données. Si c'est le cas, les lignes et les colonnes du tableau doivent contenir des en-têtes (c.-à-d. des chaînes avec des balises TH).

Les tableaux peuvent servir à présenter des données telles que des horaires de bus, une comparaison de chiffres de vente au niveau régional ou une liste d'informations relatives aux employés. Les cellules d'un tableau de données de ce type sont interconnectées et doivent généralement être perçues comme un groupe. Les tableaux peuvent également être utilisés pour agencer des images ou du texte sur une page. Chaque cellule d'un tableau de mise en forme comme celui-ci est généralement indépendante et peut être affichée séparément.

Les tableaux de données servent à présenter des informations sur un support bidirectionnel, qui souvent n'est pas disponible pour tous les utilisateurs. Prenez les exemples suivants :

  • Un navigateur textuel peut ne pas aligner correctement les lignes et les colonnes parce que le contenu d'une cellule contient un bouclage automatique, par exemple.
  • Un navigateur de lecture lit le contenu du tableau de façon séquentielle.
  • Un lecteur Braille analyse également le tableau de façon séquentielle.
  • Un navigateur doté d'un écran de petite taille (tel qu'un PDA ou un téléphone portable) affiche une portion limitée du tableau.

Dans chacun de ces cas, l'utilisateur doit mémoriser le contexte de chaque cellule (à quelle ligne, quelle colonne fait-elle référence ?). Ceci est parfois impossible, par exemple lorsqu'il s'agit d'un tableau long, ou que l'utilisateur est stressé ou impatient de trouver les informations requises.

Dans de telles situations, il se peut que l'utilisateur soit incapable de se déplacer directement d'une cellule à une autre dans le tableau. Il est alors contraint de se déplacer par séquences, d'une cellule à la cellule voisine uniquement (dans la même ligne, par exemple).

Les tableaux de mise en forme, au contraire, ne présentent pas d'informations et n'ont pas besoin d'être accessibles. A ce sujet, le W3C suggère toutefois d'utiliser les styles pour mettre en forme le contenu d'une page. Pour de plus amples informations, consultez la page Web suivante : http://www.w3.org/TR/WCAG10-CSS-TECHS/#style-alignment.

Notez également que les tableaux mis en forme sont linéarisés par les navigateurs non graphiques. Autrement dit, le contenu des cellules est affiché selon leur séquence d'apparition dans le fichier HTML. Cela signifie que si les cellules incluent des boutons, ceux-ci peuvent apparaître dans une séquence inutilisable. Pour plus de détails, reportez-vous à la page http://www.jimthatcher.com/webcourse4.htm.

Si le tableau présente des données, assurez-vous que chaque ligne et chaque colonne comportent des en-têtes appropriés.

Pour ce faire, il suffit de définir dans le tableau une ligne complète de cellules marquées d'une balise TH et de marquer aussi la première cellule de toutes les autres lignes avec cette même balise TH.

En outre :

  • Les balises TH doivent avoir un attribut ID pour identification.
  • Les balises TD doivent avoir un attribut HEADER qui réfère aux balises TH appropriées.

La balise TH peut également avoir un attribut SCOPE='col' ou SCOPE='row', ce qui signifie que l'en-tête réfère, respectivement, à la colonne ou à la ligne toute entière.

Il peut être judicieux d'utiliser l'attribut ABBR dans la balise TH pour fournir une description plus concise de l'en-tête que les navigateurs spécialisés doivent répéter maintes fois.

La cellule du tableau des données doit référer aux en-têtes. CellsReferToHeaders 4 Section 508 1194.22(g); WAI / WCAG 1.0 checkpoint 5.1 Accessibilit&eacute; P.1 W3C/WCAG 508 accessibilité manuel tableaux TOUT

La page inclut un tableau contenant des balises TH sans attribut ID ou SCOPE. Si le tableau est utilisé pour présenter des données, fournissez les informations d'en-tête.

La page contient un tableau qui semble être utilisé pour présenter des données. Si c'est le cas, les balises TH doivent avoir des attributs ID ou SCOPE.

Les tableaux peuvent servir à présenter des données telles que des horaires de bus, une comparaison de chiffres de vente au niveau régional ou une liste d'informations relatives aux employés. Les cellules d'un tableau de données de ce type sont interconnectées et doivent généralement être perçues comme un groupe. Les tableaux peuvent également être utilisés pour agencer des images ou du texte sur une page. Chaque cellule d'un tableau de mise en forme comme celui-ci est généralement indépendante et peut être affichée séparément.

Les tableaux de données servent à présenter des informations sur un support bidirectionnel, qui souvent n'est pas disponible pour tous les utilisateurs. Prenez les exemples suivants :

  • Un navigateur textuel peut ne pas aligner correctement les lignes et les colonnes parce que le contenu d'une cellule contient un bouclage automatique, par exemple.
  • Un navigateur de lecture lit le contenu du tableau de façon séquentielle.
  • Un lecteur Braille analyse également le tableau de façon séquentielle.
  • Un navigateur doté d'un écran de petite taille (tel qu'un PDA ou un téléphone portable) affiche une portion limitée du tableau.

Dans chacun de ces cas, l'utilisateur doit mémoriser le contexte de chaque cellule (à quelle ligne, quelle colonne fait-elle référence ?). Ceci est parfois impossible, par exemple lorsqu'il s'agit d'un tableau long, ou que l'utilisateur est stressé ou impatient de trouver les informations requises.

Dans de telles situations, il se peut que l'utilisateur soit incapable de se déplacer directement d'une cellule à une autre dans le tableau. Il est alors contraint de se déplacer par séquences, d'une cellule à la cellule voisine uniquement (dans la même ligne, par exemple).

Les tableaux de mise en forme, au contraire, ne présentent pas d'informations et n'ont pas besoin d'être accessibles. A ce sujet, le W3C suggère toutefois d'utiliser les styles pour mettre en forme le contenu d'une page. Pour de plus amples informations, consultez la page Web suivante : http://www.w3.org/TR/WCAG10-CSS-TECHS/#style-alignment.

Si le tableau est utilisé pour présenter des données, veillez à ce que chaque ligne et chaque colonne soit accompagnée des en-têtes appropriés définis par des balises TH.

En outre :

  • Les balises TH doivent avoir un attribut ID pour identification.
  • Les balises TD doivent avoir un attribut HEADER qui réfère aux balises TH appropriées.

La balise TH peut également avoir un attribut SCOPE='col' ou SCOPE='row', ce qui signifie que l'en-tête réfère, respectivement, à la colonne ou à la ligne toute entière.

Il peut être judicieux d'utiliser l'attribut ABBR dans la balise TH pour fournir une description plus concise de l'en-tête que les navigateurs spécialisés doivent répéter maintes fois.

Les tables de données doivent être définies par la balise TABLE PREisNotATable 4 Section 508 1194.22(g); WAI / WCAG 1.0 checkpoint 5.1 Accessibilit&eacute; P.1 W3C/WCAG 508 accessibilité manuel tableaux TOUT

La page inclut une balise PRE accompagnée de données tabulaires préformatées. Si la balise PRE sert à présenter les données, convertissez-la en balise TABLE.

La page contient des données pré-formatées contenant peut-être un formulaire tabulaire. Si c'est le cas, les données doivent être formatées dans un tableau avec les balises appropriées : TABLE, TR, TH, TD.

Les tableaux de données servent à présenter des informations sur un support bidirectionnel, qui souvent n'est pas disponible pour tous les utilisateurs. Prenez les exemples suivants :

  • Un navigateur textuel peut ne pas aligner correctement les lignes et les colonnes parce que le contenu d'une cellule contient un bouclage automatique, par exemple.
  • Un navigateur de lecture lit le contenu du tableau de façon séquentielle.
  • Un lecteur Braille analyse également le tableau de façon séquentielle.
  • Un navigateur doté d'un écran de petite taille (tel qu'un PDA ou un téléphone portable) affiche une portion limitée du tableau.

Dans chacun de ces cas, l'utilisateur doit mémoriser le contexte de chaque cellule (à quelle ligne, quelle colonne fait-elle référence ?). Ceci est parfois impossible, par exemple lorsqu'il s'agit d'un tableau long, ou que l'utilisateur est stressé ou impatient de trouver les informations requises.

Dans de telles situations, il se peut que l'utilisateur soit incapable de se déplacer directement d'une cellule à une autre dans le tableau. Il est alors contraint de se déplacer par séquences, d'une cellule à la cellule voisine uniquement (dans la même ligne, par exemple).

Si vous utilisez la balise PRE pour réorganiser et présenter les données sous forme de tableau, formatez lesdites données dans un tableau à l'aide des balises TABLE, TR, TH et TD et des attributs appropriés (ID, HEADERS, SCOPE).

En outre :

  • Les balises TH doivent avoir un attribut ID pour identification.
  • Les balises TD doivent avoir un attribut HEADER qui réfère aux balises TH appropriées.

La balise TH peut également avoir un attribut SCOPE='col' ou SCOPE='row', ce qui signifie que l'en-tête réfère, respectivement, à la colonne ou à la ligne toute entière.

Il peut être judicieux d'utiliser l'attribut ABBR dans la balise TH pour fournir une description plus concise de l'en-tête que les navigateurs spécialisés doivent répéter maintes fois.

Plusieurs en-têtes doivent être marqués dans les tableaux de données TABLEwithMultipleLevels 4 Section 508 1194.22(h); WAI / WCAG 1.0 checkpoint 5.2 Accessibilit&eacute; P.1 W3C/WCAG 508 accessibilité manuel tableaux TOUT

La page, bien qu'incluant une balise TABLE accompagnée d'une balise TH, ne comprend aucun élément THEAD, TFOOT, TBODY. Si le tableau sert à afficher des données et qu'il inclut des en-têtes de lignes et de colonnes sur plusieurs niveaux, pensez à utiliser des éléments THEAD, TFOOT, TBODY pour marquer ces niveaux.

La page semble contenir un tableau de données. Si le tableau contient plus d'un niveau d'en-têtes de lignes ou de colonnes, les balises THEAD, TFOOT et TBODY doivent être utilisées comme il se doit.

Les tableaux de données servent à présenter des informations sur un support bidirectionnel, qui souvent n'est pas disponible pour tous les utilisateurs. Prenez les exemples suivants :

  • Un navigateur textuel peut ne pas aligner correctement les lignes et les colonnes parce que le contenu d'une cellule contient un bouclage automatique, par exemple.
  • Un navigateur de lecture lit le contenu du tableau de façon séquentielle.
  • Un lecteur Braille analyse également le tableau de façon séquentielle.
  • Un navigateur doté d'un écran de petite taille (tel qu'un PDA ou un téléphone portable) affiche une portion limitée du tableau.

Dans chacun de ces cas, l'utilisateur doit mémoriser le contexte de chaque cellule (à quelle ligne, quelle colonne fait-elle référence ?). Ceci est parfois impossible, par exemple lorsqu'il s'agit d'un tableau long, ou que l'utilisateur est stressé ou impatient de trouver les informations requises.

Dans de telles situations, il se peut que l'utilisateur soit incapable de se déplacer directement d'une cellule à une autre dans le tableau. Il est alors contraint de se déplacer par séquences, d'une cellule à la cellule voisine uniquement (dans la même ligne, par exemple).

Si le tableau est structuré en diverses sections, chacune avec ses propres en-têtes de lignes ou de colonnes, cette structure doit être clairement indiquée pour que les navigateurs spécialisés puissent en tirer parti (éventuellement en répétant les en-têtes appropriés au moment d'aller vers une cellule).

Si vous utilisez le tableau pour présenter des données et que les données sont organisées selon diverses sections nécessitant des en-têtes différents, utilisez les balises THEAD, TFOOT, TBODY (éventuellement avec COLGROUP et COL) pour marquer ces sections.

FRAME avec TITLE valide FRAMEwValidTitle 4 Section 508 1194.22(i); WAI / WCAG 1.0 checkpoint 12.1 Accessibilit&eacute; P.1 W3C/WCAG 508 accessibilité cadres TOUT

La balise FRAME définie dans le document ne contient pas un attribut TITLE valide.

L'attribut TITLE d'une balise FRAME est valide si les conditions suivantes sont remplies : il existe et ne constitue ni une chaîne vide ("") ni une chaîne vierge (" ").

FRAME non valide : attribut TITLE manquant FRAME non valide : l'attribut TITLE existe mais correspond à la chaîne vide "" FRAME non valide : l'attribut TITLE existe mais correspond à la chaîne vierge "" FRAME non valide : l'attribut TITLE existe mais contient des balises HTML

Les cadres sont particulièrement utiles pour la mise en œuvre de structures de navigation complexes. Ils peuvent toutefois devenir un obstacle pour bon nombre d'utilisateurs s'ils ne sont pas correctement appliqués. Assurez-vous que votre page de cadres est accessible à tous, quels que soient la technologie empruntée et le contexte.

L'interface utilisateur a pour principale directive conceptuelle de "renseigner les utilisateurs sur le contexte et l'orientation afin de faciliter la compréhension des pages ou des éléments complexes".

Pour les cadres, cela signifie qu'il est impératif que l'attribut TITLE soit défini puisque sa valeur est tout ce que les navigateurs non graphiques affichent. En réalité, chaque cadre apparaît indépendamment des autres, compliquant ainsi la tâche de l'utilisateur qui a du mal à discerner la relation qui les unit. Les titres comme "Zone du contenu" ou "Outils de navigation" sont beaucoup plus explicites que "Gauche" ou "Cadre supérieur".

Il peut être utile que tous les utilisateurs aient accès aux informations contextuelles sur les relations entre les éléments. Les personnes souffrant de troubles cognitifs ou d'un handicap visuel ont parfois du mal à interpréter les relations complexes entre les diverses parties d'une page.

Troubles cognitifs ne signifient pas forcément déficience intellectuelle. Ils peuvent aussi exprimer des conditions de travail spécifiques défavorables (utilisation d'une billetterie électronique dans un hall d'aéroport, d'un navigateur à commande vocale par téléphone dans un milieu bruyant, d'un PDA (assistant numérique personnel) lorsqu'une décision rapide est nécessaire ou d'un navigateur lors d'une réunion où il est difficile de se concentrer).

De la même façon, le handicap visuel peut s'appliquer à un oubli de lunettes, l'usage d'un écran mal éclairé dans un environnement sombre ou celui d'un navigateur ou lecteur d'écran à commande vocale par téléphone.

Définissez un attribut TITLE valide pour la balise FRAME.

Intitulez le cadre pour mieux l'identifier et faciliter la navigation, en décrivant de manière concise son contenu et son rôle sur la page.

L'attribut TITLE étant peu pris en charge, le titrage sous forme d'un texte normal en haut du contenu de chaque cadre suffit aux fins de la norme 508, paragraphe 1194.22(i).

Une autre solution consiste à utiliser la même chaîne pour les deux attributs TITLE et NAME. Par exemple, le navigateur textuel Lynx a uniquement recours à l'attribut NAME.

Une valeur de chaîne TITLE est valide si elle remplit les conditions suivantes :

  • Elle ne contient pas de balises HTML
  • Elle ne constitue pas une chaîne vide ("")
  • Elle ne constitue pas une chaîne vierge (" ")
IFRAME avec TITLE valide IFRAMEwValidTitle 4 Section 508 1194.22(i); WAI / WCAG 1.0 checkpoint 12.1 Accessibilit&eacute; P.1 W3C/WCAG 508 accessibilité cadres TOUT

La balise IFRAME définie dans le document ne contient pas un attribut TITLE valide.

L'attribut TITLE d'une balise IFRAME est valide si les conditions suivantes s'appliquent : il existe et ne constitue ni une chaîne vide ("") ni une chaîne vierge (" ").

IFRAME non valide : attribut TITLE manquant IFRAME non valide : l'attribut TITLE existe mais correspond à la chaîne vide "" IFRAME non valide : l'attribut TITLE existe mais correspond à la chaîne vierge "" IFRAME non valide : l'attribut TITLE existe mais contient des balises HTML

Les cadres sont particulièrement utiles pour la mise en œuvre de structures de navigation complexes. Cependant, dans la plupart des cas, cette complication supplémentaire peut devenir un obstacle pour bon nombre d'utilisateurs. Assurez-vous que votre page de cadres est accessible à tous, quels que soient la technologie empruntée et le contexte.

L'interface utilisateur a pour principale directive conceptuelle de "renseigner les utilisateurs sur le contexte et l'orientation afin de faciliter la compréhension des pages ou des éléments complexes".

Il peut être utile que tous les utilisateurs aient accès aux informations contextuelles sur les relations entre les éléments. Les personnes souffrant de troubles cognitifs ou d'un handicap visuel ont parfois du mal à interpréter les relations complexes entre les diverses parties d'une page.

Troubles cognitifs ne signifient pas forcément déficience intellectuelle. Ils peuvent aussi exprimer des conditions de travail spécifiques défavorables (utilisation d'une billetterie électronique dans un hall d'aéroport, d'un navigateur à commande vocale par téléphone dans un milieu bruyant, d'un PDA (assistant numérique personnel) lorsqu'une décision rapide est nécessaire ou d'un navigateur lors d'une réunion où il est difficile de se concentrer).

De la même façon, le handicap visuel peut s'appliquer à un oubli de lunettes, l'usage d'un écran mal éclairé dans un environnement sombre ou celui d'un navigateur ou lecteur d'écran à commande vocale par téléphone.

Définissez un attribut TITLE valide pour la balise IFRAME.

Intitulez le cadre pour mieux l'identifier et faciliter la navigation, en décrivant de manière concise son contenu et son rôle dans la page.

L'attribut TITLE étant peu pris en charge, le titrage sous forme d'un texte normal en haut du contenu de chaque cadre suffit aux fins de la norme 508, paragraphe 1194.22(i).

Une valeur de chaîne TITLE est valide si elle remplit les conditions suivantes :

  • Elle ne contient pas de balises HTML
  • Elle ne constitue pas une chaîne vide ("")
  • Elle ne constitue pas une chaîne vierge (" ")
Une page équivalente en mode texte peut être nécessaire TextOnlyEquivPage 4 Section 508 1194.22(k); WAI / WCAG 1.0 checkpoint 6.2 508 accessibilité scripts manuel TOUT

La page contient des objets de programmation qui la rendent inaccessible. Si la page ne peut être rendue accessible, une version en mode texte de la page mise à jour doit être disponible à chaque fois que la page d'origine change.

Si une page ne peut être rendue accessible, une version équivalente accessible de la page est nécessaire. Une version en mode texte devrait suffire. Les versions secondaires en mode texte des pages inaccessibles permettent aux personnes handicapées de disposer d'un accessibilité totale à l'ensemble des informations. Les informations ou la fonctionnalité de la page secondaire doivent correspondre aux informations ou à la fonctionnalité de la page d'origine.

Il importe également de mettre à jour les pages secondaires en même temps que les pages d'origine.

Les pages secondaires étant mises à jour moins fréquemment que les pages d'origine, il convient de recourir aux pages secondaires seulement dans le cas où les autres solutions auraient échoué. Une page périmée peut être aussi frustrante qu'une page inaccessible puisque les informations présentées sur la page d'origine demeurent indisponibles. Même si une génération automatique des pages secondaires engendre des mises à jour plus fréquentes, les développeurs doivent rester vigilants et veiller à ce que les pages créées demeurent logiques, et s'assurer que les utilisateurs sont capables de parcourir un site en suivant les liens sur les pages d'origine, sur les pages secondaires ou sur les deux. Avant de recourir à une page secondaire, révisez la conception de la page d'origine. Il est fort probable qu'une résolution de l'accessibilité de la page d'origine améliore cette dernière pour tous les utilisateurs.

Déterminez si la page remplit toutes les conditions de la norme d'accessibilité 508. Si certaines conditions ne sont pas remplies et que la page ne peut être modifiée pour remédier à la situation, il vous faut alors une version en mode texte équivalent de cette page.

Assurez-vous qu'une telle page existe et qu'elle est mise à jour à chaque fois qu'une modification est apportée à la page d'origine.

Les scripts sont accessibles. AccessibleScripts 4 Section 508 1194.22(l); WAI / WCAG 1.0 checkpoints 6.3, 8.1, 9.2, 9.3 508 accessibilité scripts manuel TOUT

La page contient un objet programmable tel qu'un script, un plug-in ou une applet, qui peut servir à modifier le contenu de la page ou ses options de navigation et éventuellement réduire l'accessibilité de la page.

Une applet est en cours d'utilisation : vérifiez son accessibilité. Un plug-in est en cours d'utilisation : vérifiez son accessibilité. Un plug-in est en cours d'utilisation : vérifiez son accessibilité.

Les objets programmables peuvent modifier la présentation, le contenu et les options de navigation d'une page. Si certaines de ces modifications ne sont pas associées à du texte lisible par une technologie assistée, la page sera inaccessible. Par exemple, l'utilisation d'un script pour présenter un menu d'options qui ne serait pas accompagné de liens textuels proposant les mêmes choix, rendrait la page inaccessible.

Ce concept est proche du concept de "l'indépendance par rapport au matériel" défini par le W3D/WAI (voir http://www.w3.org/TR/WAI-WEBCONTENT/#device-independent). Il signifie que les utilisateurs doivent pouvoir interagir avec un site Web grâce aux périphériques d'entrée et de sortie, pris en charge, de leur choix et adaptés à leurs besoins. Les périphériques d'entrée peuvent inclure des dispositifs de pointage, des claviers, des dispositifs en Braille, des licornes, des microphones, etc. Les périphériques de sortie peuvent inclure des moniteurs, des synthétiseurs vocaux et des dispositifs en Braille.

L'expression "prise en charge indépendante du matériel" ne signifie pas que le navigateur doive prendre en charge chaque périphérique d'entrée ou de sortie. Il doit fournir des mécanismes d'entrée et de sortie redondants pour les périphériques pris en charge. Par exemple, si un navigateur prend en charge l'entrée par clavier et par souris, les utilisateurs doivent pouvoir utiliser toutes les fonctions avec le clavier ou la souris.

L'accès indépendant du matériel signifie que l'utilisateur peut interagir avec l'agent ou le document de l'utilisateur à l'aide de son périphérique d'entrée (ou de sortie) préféré. Par exemple, si un contrôle de formulaire peut uniquement être activé à l'aide d'une souris ou d'un autre dispositif de pointage, une personne consultant la page, qui serait non-voyante et utiliserait un dispositif vocal ou un clavier, ne pourrait pas utiliser ce formulaire. Le formulaire est un exemple de dépendance au matériel parce que son utilisation ne serait possible qu'avec une souris.

Généralement, les pages consultables par clavier sont également accessibles via un dispositif vocal ou une interface utilisant des lignes de commande.

Les objets programmables inaccessibles peuvent inclure :

  • des images survolées ;
  • des scripts présentant des options de menu ;
  • des scripts traitant des événements déclenchés par des périphériques autres qu'un clavier ;
  • des plug-in tels que Flash, Shockwave, RealAudio et RealVideo ;
  • des applets Java.

Examinez l'objet programmable inclus sur la page et vérifiez s'il fournit des informations ou des options d'interaction qui ne sont pas disponibles ailleurs sur la page.

Si le script n'est pas accessible, incluez par exemple une balise NOSCRIPT avec du contenu et une interaction secondaire ou équivalent (à l'aide d'un formulaire).

Vous pouvez également transformer le script côté client en script côté serveur équivalent, auquel cas vous devez l'écrire de telle sorte qu'il permette l'accès aux pages.

Un lien au plug-in est présent LinkToPluginIsPresent 4 Section 508 1194.22(m) 508 accessibilité scripts manuel TOUT

La page contient un objet de programmation, tel qu'un plug-in ou une applet, pouvant nécessiter un plug-in spécifique, qui va permettre au navigateur d'interpréter le contenu de la page.

Vérifiez que l'objet est accessible ou que la page contient un lien vers un objet équivalent accessible. Veillez aussi à ce que la page contienne un lien vers une ressource d'où l'on peut télécharger le plug-in.

Une applet est en cours d'utilisation : est-elle accessible ? Si ce n'est pas le cas, existe-t-il un lien vers une version accessible de l'applet ? Un plug-in est en cours d'utilisation : est-il accessible ? Si ce n'est pas le cas, existe-t-il un lien vers une version accessible de l'objet ? Existe-t-il un lien vers le plug-in requis par le navigateur ? Un plug-in est en cours d'utilisation : est-il accessible ? Si ce n'est pas le cas, existe-t-il un lien vers une version accessible de l'objet ? Existe-t-il un lien vers le plug-in requis par le navigateur ? Si ce n'est pas le cas, utilisez les attributs PLUGINSPACE ou PLUGINURL de la balise EMBED pour spécifier un lien vers le plug-in. Un fichier PDF est en cours d'utilisation : est-il accessible ? Si ce n'est pas le cas, existe-t-il un lien vers une version accessible du document ?

Les objets de programmation peuvent modifier la présentation, le contenu ou les options de navigation d'une page. Parmi les objets de programmation figurent les applets Java, les fichiers Flash, ShockWave, RealAudio ou RealVideo. Il est indispensable que chacun de ces objets soit accessible. Si tel n'est pas le cas, la page doit alors contenir des liens vers d'autres versions accessibles des objets. Au moment d'évaluer l'accessibilité des plug-ins, il peut être utile de vous référer à la norme 508 de la section de l'Access Board applicable au logiciel, 36 C.F.R., paragraphe 1194.21 (reportez-vous à la page http://www.access-board.gov/sec508/508standards.htm). En outre, si ces objets exigent un plug-in spécifique pour le navigateur, la page doit préciser comment l'acquérir et l'installer.

En règle générale, les documents PDF peuvent être créés de diverses manières, chaque technique sous-entendant un type d'accessibilité distinct. Voici quatre méthodes :

  1. La numérisation d'un document au format PDF crée un fichier appelé "Image PDF seulement", à savoir une représentation graphique du document qu'aucune technologie de lecture d'écran ne peut généralement interpréter, comme pour une photographie sans texte de référence
  2. La numérisation d'un document au format PDF, puis l'exécution via la technologie ROC ("Reconnaissance optique de caractères") convertissent les images en texte consultable. Il est important de vérifier minutieusement l'exactitude de tels documents.
  3. L'impression d'un fichier directement au format PDF convertit les informations électroniques en une représentation numérique du document qu'une technologie d'assistance peut alors déchiffrer.
  4. L'écriture dans Adobe Acrobat peut aussi produire un document qu'une technologie d'assistance peut déchiffrer.

Nous invitons les concepteurs de sites Web à utiliser les deux dernières méthodes de création de fichiers PDF et leur déconseillons vivement la première. Il importe également que vous testiez l'accessibilité de vos documents PDF en vous aidant de lecteurs d'écran avant de les poster sur des sites Web. Le site d'accessibilité d'Adobe inclut les dernières recommandations permettant de rendre les fichiers PDF accessibles (voir le site http://access.adobe.com/). Enfin, il convient de veiller à ce qu'un contenu sans texte soit accompagné de descriptions textuelles dans les fichiers PDF. Les développeurs optant pour une publication de documents Web au format PDF devraient publier simultanément ces mêmes documents sous un autre format plus accessible, tel que HTML.

Vérifiez que l'objet est accessible ou que la page contient un lien vers un objet équivalent accessible. Veillez aussi à ce qu'apparaisse un lien vers une ressource d'où l'on peut télécharger le plug-in.

APPLET avec un texte ALT valide APPLETwValidALT 4 Section 508 1194.22(a); WAI / WCAG 1.0 checkpoint 1.1 Accessibilit&eacute; P.1 W3C/WCAG 508 accessibilité scripts TOUT

Les applets incluses dans ce document n'ont pas de descriptions textuelles valides correspondantes. Une description valide est une valeur de chaîne pour l'attribut ALT, autre que les suivantes :

  • une chaîne vide ("") ;
  • une chaîne vierge contenant un espace ou plus (" ") ;
  • le nom du fichier contenant l'applet ;
  • la taille du fichier applet.
Aucun texte ALT défini pour l'applet. Le texte ALT de l'applet est la chaîne vide "". Le texte ALT de l'applet est la chaîne vierge "". Le texte ALT de l'applet décrit uniquement la taille du fichier applet. Le texte ALT de l'applet décrit uniquement le nom de fichier d'une image. Le texte ALT de l'applet décrit uniquement le nom de fichier de l'applet. Le texte ALT de l'applet semble contenir uniquement du texte de l'espace réservé.

Voici des exemples d'applet pouvant ne pas fonctionner :

  • Certains utilisateurs affichent la page sur des PDA ou des téléphones portables incapables d'exécuter les applets.
  • Certaines applets utilisent des bibliothèques écrites pour un système d'exploitation spécifique tel que Windows, Mac OS ou Linux.
  • Certains utilisateurs de navigateurs graphiques désactivent les applets pour des raisons de sécurité.

Vous utilisez l'attribut ALT pour décrire le comportement et le contenu de l'applet à ces utilisateurs.

Ajoutez l'attribut ALT à la balise APPLET.

La description ALT doit fournir les mêmes informations que celles de l'applet et doit expliquer le rôle de l'applet dans la page : pourquoi elle est là, ce qu'elle représente et comment elle présente l'information.

APPLET avec ALT équivalent APPLETwEquivalentALT 4 Section 508 1194.22(a); WAI / WCAG 1.0 checkpoint 1.1 Accessibilit&eacute; P.1 W3C/WCAG 508 accessibilité scripts manuel TOUT

Les applets contenues dans ce document doivent avoir des descriptions textuelles équivalentes dans l'attribut ALT et dans le contenu de l'applet.

Voici des exemples d'applet pouvant ne pas fonctionner :

  • Certains utilisateurs affichent la page sur des PDA ou des téléphones portables incapables d'exécuter les applets.
  • Certaines applets utilisent des bibliothèques écrites pour un système d'exploitation spécifique tel que Windows, Mac OS ou Linux.
  • Certains utilisateurs de navigateurs graphiques désactivent les applets pour des raisons de sécurité.

Vous utilisez l'attribut ALT et le contenu de l'applet pour décrire le comportement et le contenu des applets à ces utilisateurs.

Vérifiez la description textuelle de l'applet dans la valeur de l'attribut ALT et dans le contenu de l'applet. Elle doit fournir les mêmes informations que celles de l'applet et expliquer le rôle de l'applet dans la page : pourquoi elle est là, ce qu'elle représente et comment elle présente l'information.

APPLET avec CONTENT valide APPLETwValidCONTENT 4 Section 508 1194.22(a); WAI / WCAG 1.0 checkpoint 1.1 Accessibilit&eacute; P.1 W3C/WCAG 508 accessibilité scripts TOUT

Les applets incluses dans ce document n'ont pas de descriptions textuelles valides correspondantes. Une description valide est une valeur de chaîne pour le CONTENT, autre que les suivantes :

  • une chaîne vide ("") ;
  • une chaîne vierge contenant un espace ou plus (" ") ;
  • le nom du fichier contenant l'applet ;
  • la taille du fichier applet.
Aucun texte CONTENT défini pour l'applet. Le CONTENT de l'applet est la chaîne vide "". Le CONTENT de l'applet est la chaîne vierge "". Le CONTENT de l'applet décrit uniquement la taille du fichier applet. Le CONTENT de l'applet décrit uniquement le nom de fichier d'une image. Le CONTENT de l'applet décrit uniquement le nom de fichier de l'applet. Le CONTENT de l'applet semble contenir uniquement du texte de l'espace réservé.

Voici des exemples d'applet pouvant ne pas fonctionner :

  • Certains utilisateurs affichent la page sur des PDA ou des téléphones portables incapables d'exécuter les applets.
  • Certaines applets utilisent des bibliothèques écrites pour un système d'exploitation spécifique tel que Windows, Mac OS ou Linux.
  • Certains utilisateurs de navigateurs graphiques désactivent les applets pour des raisons de sécurité.

Fournissez un texte équivalent décrivant le comportement de l'applet, à l'aide de l'attribut ALT et du contenu de la balise APPLET. Le contenu peut ainsi se transformer pour les agents utilisateur qui prennent en charge l'un des deux mécanismes uniquement (ALT ou contenu).

Ajoutez du contenu à la balise APPLET.

La description textuelle doit fournir les mêmes informations que celles de l'applet et doit expliquer le rôle de l'applet dans la page : pourquoi elle est là, ce qu'elle représente et comment elle présente l'information.

Le formulaire est accessible FormIsAccessible 4 Section 508 1194.22(n) 508 accessibilité formulaires manuel TOUT

La page contient un élément FORM dont les composants semblent présentés dans un tableau. Il se peut que le tableau rende le formulaire inutilisable.

Assurez-vous que la version linéarisée du formulaire est toujours utilisable.

L'utilisation d'un tableau pour mettre en forme un formulaire peut rendre ce dernier inutilisable. Lorsque l'utilisateur consulte la page via un navigateur vocal ou un périphérique équipé d'un écran de petite taille, tel qu'un PDA ou un téléphone portable, les cellules du tableau peuvent se présenter sous forme linéaire (linéarisée). Suite à cela, les étiquettes des champs de texte, les cases à cocher et les boutons radio pourront ne plus être à la bonne place.

Pour en savoir plus sur les effets des tableaux de mise en forme sur la navigation, reportez-vous à la page http://www.jimthatcher.com/webcourse4.htm.

Gardez également à l'esprit l'ordre de tabulation des éléments du formulaire. En appuyant sur la touche de tabulation du clavier, l'utilisateur peut se déplacer de façon séquentielle d'un élément à un autre dans l'ordre défini sur la page HTML. Parfois, vous voudrez peut-être spécifier un ordre différent. Pour cela, utilisez l'attribut TABINDEX des balises INPUT, A, BUTTON, AREA, OBJECT, SELECT et TEXTAREA dans un formulaire.

Vous pouvez également utiliser l'attribut ACCESSKEY pour associer des raccourcis clavier aux éléments du formulaire.

Veillez à ce que les éléments du formulaire et leurs étiquettes soient restitués correctement par les navigateurs non graphiques. Veillez en particulier à ce que le formulaire soit toujours utilisable après que le tableau utilisé pour le mettre en forme a été linéarisé. Pour cela, il suffit d'effeuiller les balises du tableau. Vous pouvez encore apposer une feuille de papier sur la page et lire le tableau ligne par ligne.

Ignorez les liens répétitifs SkipRepetitiveLinks 4 Section 508 1194.22(o); WAI / WCAG 1.0 checkpoint 13.6 Accessibilit&eacute; P.1 W3C/WCAG 508 accessibilité manuel TOUT

Dans l'hypothèse d'un jeu de liens de navigation figurant aux emplacements habituels (souvent en haut, en bas ou sur le côté d'une page), il convient qu'un lien textuel soit présent pour permettre à quiconque utilise des navigateurs non graphiques de passer outre les liens et d'aller directement au contenu de la page.

Vérifiez qu'un lien texte est bien présent pour éviter les liens de navigation répétés sur chaque page.

Les concepteurs de pages Web placent souvent le jeu de liens de navigation à un endroit habituel, comme par exemple en haut, en bas ou sur le côté d'une page. Si des internautes sans handicap reviennent sur une page ou un site Web et souhaitent voir le contenu de ladite page plutôt que de sélectionner un lien de navigation, il leur suffit de regarder au-delà des liens et de commencer à lire le texte de leur choix. Cependant, pour les utilisateurs de lecteurs d'écran ou autres types de technologie d'assistance, le fait d'attendre la fin de la procédure et d'écouter l'énumération complète de chacun des liens avant de parvenir au contenu de la page peut s'avérer une tâche longue et ennuyeuse.

Pour résoudre ce problème, incluez un mécanisme qui permet aux utilisateurs d'ignorer les liens de navigation répétitifs.

Si la page affiche un jeu de liens de navigation à l'endroit habituel, créez un lien qui permette aux utilisateurs de passer outre les liens. Pour ce faire, il suffit d'utiliser un lien texte normal du type "Ignorer les outils de navigation" qui pointe vers une ancre nommée sur la même page.

Vous pouvez aussi faire appel à une image GIF transparente avec un attribut ALT approprié comme lien. Par exemple :

  <A href="#content"> <IMG alt="passer au contenu de la
  page" src="spacer.gif" width="1" height="1"> </A>

Le lien sera invisible pour les utilisateurs de navigateurs graphiques, mais il sera visible pour les utilisateurs de navigateurs non graphiques.

Aucun lien JavaScript n'est utilisé NoJavascriptLinks 4 WAI 1.0 checkpoint 6.5 Accessibilit&eacute; P.1 W3C/WCAG 508 accessibilité scripts TOUT

Le lien contenu dans la page n'est opérationnel que sur des navigateurs prenant en charge le langage JavaScript.

Les liens permettant d'activer les scripts ne sont opérationnels que sur des navigateurs capables d'exécuter le langage JavaScript. Tous les navigateurs ne sont pas compatibles, comme par exemple les navigateurs textuels tels que Lynx, les navigateurs couplés avec des lecteurs d'écran et les navigateurs pour PDA ou téléphones portables. Quiconque possède un tel navigateur ne pourra parcourir la page. Même si vous fournissez d'autres liens ou boutons pour atteindre la cible, une rupture de lien surviendra cependant, faisant croître un sentiment de frustration et la confusion.

Remplacez le lien qui déclenche le script par un autre moyen ; par exemple, en définissant un bouton, en définissant le script d'une façon distincte (sans oublier l'élément NOSCRIPT) ou en reliant un événement, tel que onKeyPress, sur le bouton du script.

Aucune actualisation automatique n'est utilisée NoRefreshIsUsed 4 Section 508 1194.22(p); WAI / WCAG 1.0 checkpoint 7.4 Accessibilit&eacute; P.1 W3C/WCAG 508 accessibilité TOUT

La page est automatiquement mise à jour après une période donnée. Il vous faut supprimer ce comportement.

La mise à jour automatique des pages peut poser des problèmes importants aux personnes handicapées ou aux personnes faisant appel à une technologie qui empêche une interaction ordinaire. Il peut arriver par exemple que les lecteurs d'écran s'enrayent au moment même où la page est mise à jour. De même, les personnes souffrant d'un handicap physique peuvent trouver difficile de se déplacer suffisamment rapidement ou précisément dans le contenu de la page et les éléments de navigation. Aussi, des problèmes peuvent se présenter à quiconque lit très lentement, utilise une connexion Internet à faible vitesse ou dispose d'un petit écran qui empêche de lire normalement. Tant que ces fonctionnalités de mise à jour automatique ne peuvent être désactivées, évitez d'utiliser l'option d'actualisation automatique.

Tant que les fonctionnalités de mise à jour automatique ne peuvent être désactivées, évitez d'utiliser l'option d'actualisation automatique. Tentez de créer un effet comparable en spécifiant les propriétés de mise en mémoire cache et configurez le serveur Web en conséquence. L'accessibilité des pages ne sera pas modifiée, car le changement de page n'est que la conséquence d'une demande de l'utilisateur à partir du serveur.

Aucune redirection automatique n'est utilisée NoRedirectIsUsed 4 Section 508 1194.22(p); WAI / WCAG 1.0 checkpoint 7.5 Accessibilit&eacute; P.1 W3C/WCAG 508 accessibilité TOUT

La page est automatiquement mise à jour et une nouvelle page est automatiquement chargée après une période donnée. Il vous faut supprimer ce comportement.

La mise à jour automatique des pages peut poser des problèmes importants aux personnes handicapées ou aux personnes faisant appel à une technologie qui empêche une interaction ordinaire. Il peut arriver par exemple que les lecteurs d'écran s'enrayent au moment même où la page est mise à jour. De même, les personnes souffrant d'un handicap physique peuvent trouver difficile de se déplacer suffisamment rapidement ou précisément dans le contenu de la page et les éléments de navigation. Aussi, des problèmes peuvent se présenter à quiconque lit très lentement, utilise une connexion Internet à faible vitesse ou dispose d'un petit écran qui empêche de lire normalement. Tant que ces fonctionnalités de mise à jour automatique ne peuvent être désactivées, évitez d'utiliser l'option d'actualisation automatique.

Tant que les fonctionnalités de mise à jour automatique ne peuvent être désactivées, évitez d'utiliser les options d'actualisation automatique ou de redirection automatique. Si une redirection automatique est nécessaire, mettez-la en œuvre à l'aide des fonctions de redirection proposées par le serveur. L'accessibilité des pages ne sera pas modifiée, car le changement de page n'est que la conséquence d'une demande de l'utilisateur à partir du serveur. En cas d'impossibilité, il convient de donner à l'utilisateur les moyens nécessaires pour qu'il puisse accéder et parcourir les éléments présents sur la page en cours et sur la nouvelle page qui est chargée automatiquement. De cette façon, l'utilisateur pourra quand même accéder à ces éléments lorsqu'il y a alternance entre les deux pages.

Les fichiers GIF n'occasionnent pas de scintillements d'écran NoFlickeringGIFs 4 Section 508 1194.22(j); WAI / WCAG 1.0 checkpoint 7.1 Accessibilit&eacute; P.1 W3C/WCAG 508 accessibilité manuel TOUT

Une image au format GIF contenue dans la page peut être à l'origine du scintillement de l'écran.
Assurez-vous que la page ne contient pas de fichier GIF animé dont la fréquence d'actualisation varie entre 2 et 55 images par seconde.

La page contient des images GIF : occasionnent-t-elles des scintillements d'écran ? Si c'est le cas, modifiez ou supprimez ces images.

Un écran qui scintille ou clignote peut provoquer des crises d'épilepsie chez les personnes réagissant à la photosensibilité. En conséquence, il est impératif que les développeurs de contenu fassent tout leur possible pour empêcher l'écran de scintiller.

Les crises peuvent se déclencher suite à un scintillement ou un clignotement lumineux survenant de 2 à 55 fois par seconde, avec une sensibilité maximale de 20 clignotements par seconde lors de passages rapides du sombre au clair.

Trop d'animation GIF peut également distraire certains utilisateurs et les empêcher de lire la page.

Assurez-vous que la page ne contient aucun fichier GIF animé dont la fréquence d'actualisation varie entre 2 et 55 images par seconde. Autrement dit, vérifiez qu'aucune image ne clignote ou ne passe du sombre au clair à maintes reprises, à savoir de 2 à 55 fois par seconde.

Si vous avez besoin d'utiliser l'image GIF animée, augmentez sa fréquence d'actualisation au-delà de 55 images par seconde ou modifiez ses couleurs pour réduire l'effet de scintillement.

Evitez tout scintillement de l'écran NoFlickeringObjects 4 Section 508 1194.22(j); WAI / WCAG 1.0 checkpoint 7.1 Accessibilit&eacute; P.1 W3C/WCAG 508 accessibilité manuel TOUT

Un objet graphique contenu dans la page peut être à l'origine du scintillement de l'écran.
Assurez-vous que la page ne contient pas d'objet animé dont la fréquence d'actualisation varie entre 2 et 55 images par seconde.

Un(e) applet/objet/script est en cours d'utilisation : occasionne-t-il(elle) des scintillements d'écran ? Si c'est le cas, modifiez ou supprimez l'applet.

Un écran qui scintille ou clignote peut provoquer des crises d'épilepsie chez les personnes réagissant à la photosensibilité. En conséquence, il est impératif que les développeurs de contenu fassent tout leur possible pour empêcher l'écran de scintiller.

Les crises peuvent se déclencher suite à un scintillement ou un clignotement lumineux survenant de 2 à 55 fois par seconde, avec une sensibilité maximale de 20 clignotements par seconde lors de passages rapides du sombre au clair.

Voici quelques éléments HTML capables de provoquer un scintillement :

  • SCRIPT : un langage de script peut servir à créer des animations
  • OBJECT : un OBJECT peut contenir des films, des images GIF animées ou des applets Java animées
  • EMBED : cette balise sert habituellement à inclure des films dans la page
  • APPLET : les applets Java permettent d'afficher des animations

Assurez-vous qu'aucun objet animé n'a une fréquence d'actualisation variant entre 2 et 55 images par seconde. Autrement dit, vérifiez qu'aucune image ne clignote ou ne passe du sombre au clair à maintes reprises, à savoir de 2 à 55 fois par seconde.

Si vous avez besoin d'utiliser l'objet animé, augmentez sa fréquence d'actualisation au-delà de 55 images par seconde ou modifiez ses couleurs pour réduire l'effet de scintillement.

OBJECT d'image avec CONTENT valide imgOBJECTwValidContent 4 Section 508 1194.22(a); WAI / WCAG 1.0 checkpoint 1.1 Accessibilit&eacute; P.1 W3C/WCAG 508 accessibilité scripts TOUT

La page contient des éléments OBJECT incorporant des images dont la description entre les balises <OBJECT> et </OBJECT> n'est pas valide.

Une description valide est un fragment HTML qui figure entre les balises <OBJECT> et </OBJECT> et qui contient ce qui suit :

  • au moins un mot ;
  • un autre objet ;
  • Un élément IMG accompagné d'un texte ALT valide
  • un lien vers une représentation secondaire valide.

Une description valide ne comporte aucun texte de l'espace réservé (voir la page http://www.w3.org/TR/AERT#AppendixC).

Le contenu secondaire de l'objet correspond à la chaîne vide"". Le contenu secondaire de l'objet correspond à la chaîne vierge"". Le contenu secondaire de l'objet décrit uniquement la taille du fichier d'image. Le contenu secondaire de l'objet décrit uniquement le nom de fichier de l'image. Le contenu secondaire de l'objet semble contenir uniquement du texte de l'espace réservé.

La balise OBJECT contient un mécanisme de spécification de restitution des objets secondaires. Chaque déclaration d'OBJECT incorporée peut spécifier des types de contenu secondaire. Si un navigateur ne peut pas restituer l'OBJECT le plus à l'extérieur, il essaie d'en restituer le contenu, qui peut être un autre élément OBJECT, etc.

Il est impératif qu'au moins un objet d'une telle chaîne soit accessible via une description équivalente valide afin que les utilisateurs dont le navigateur ne prend pas en charge le mode graphique puissent quand même parcourir la page. L'émergence des navigateurs texte-seul portatifs rend l'utilisation de descriptions ALT plus importante que jamais.

La définition d'une description textuelle pour un objet peut aussi améliorer la façon dont les pages sont répertoriées dans certains moteurs de recherche.

Insérez une description valide dans la balise <OBJECT>.

La description textuelle secondaire doit expliquer le contenu de l'image et son rôle dans le document.

OBJECT d'image avec CONTENT équivalent imgOBJwEquivCont 4 Section 508 1194.22(a); WAI / WCAG 1.0 checkpoint 1.1 Accessibilit&eacute; P.1 W3C/WCAG 508 accessibilité scripts manuel TOUT

Les éléments OBJECT contenant des images incorporées incluses à ce document doivent avoir une description correspondante équivalente entre les balises <OBJECT> et </OBJECT>.

L'élément OBJECT comprend un mécanisme de spécification des restitutions d'objets secondaires. Chaque déclaration d'OBJECT incorporée peut spécifier des types de contenu secondaire. Si un navigateur ne peut pas restituer l'OBJECT le plus à l'extérieur, il essaie d'en restituer le contenu, qui peut être un autre élément OBJECT, etc.

Les objets comprenant des images incorporées doivent avoir des descriptions ou des images équivalentes correspondantes afin que les utilisateurs dont le navigateur ne prend pas en charge les graphiques puissent quand même parcourir la page.

La description de l'image doit fournir les mêmes informations que celles de l'image et expliquer le rôle de ladite image dans la page : pourquoi elle est là, ce qu'elle représente et comment elle présente l'information.

Insérez une description textuelle équivalente suffisamment éloquente ou une image dans la balise <OBJECT>.

La description textuelle secondaire doit expliquer le contenu de l'image et son rôle dans le document.

OBJECT audio/vidéo avec CONTENT valide avOBJECTwValidContent 4 Section 508 1194.22(a); WAI / WCAG 1.0 checkpoint 1.1 Accessibilit&eacute; P.1 W3C/WCAG 508 accessibilité scripts TOUT

La page contient des éléments OBJECT incorporant des fichiers audio ou vidéo sans description valide entre les balises <OBJECT> et </OBJECT>.

Le contenu secondaire de l'objet correspond à la chaîne vide"". Le contenu secondaire de l'objet correspond à la chaîne vierge"". Le contenu secondaire de l'objet décrit uniquement la taille du fichier audio/vidéo. Le contenu secondaire de l'objet décrit uniquement le nom du fichier audio ou vidéo. Le contenu secondaire de l'objet semble contenir uniquement du texte de l'espace réservé.

L'élément OBJECT contient un mécanisme de spécification de restitution des objets secondaires. Chaque déclaration d'OBJECT incorporé peut spécifier des types de contenu secondaire. Si un navigateur ne peut pas restituer l'OBJECT le plus à l'extérieur, il essaie d'en restituer le contenu, qui peut être un autre élément OBJECT, etc.

Les objets inclus dans ce document incorporant des fichiers audio ou vidéo n'ont pas de descriptions valides correspondantes. Une description valide est un fragment HTML entre les balises <OBJECT> et </OBJECT>, contenant ce qui suit :

  • au moins un mot ;
  • un autre objet ;
  • un lien vers une représentation secondaire valide.

Une description valide ne contient pas le texte de l'espace réservé (voir http://www.w3.org/TR/AERT#AppendixC).

Insérez une description valide dans la balise <OBJECT>.

La description textuelle secondaire doit être une transcription du fichier audio/vidéo.

OBJECT audio/vidéo avec CONTENT équivalent avOBJwEquivContent 4 Section 508 1194.22(a); WAI / WCAG 1.0 checkpoint 1.1 Accessibilit&eacute; P.1 W3C/WCAG 508 accessibilité scripts manuel TOUT

Les éléments OBJECT contenant des fichiers audio ou vidéo incorporés inclus à ce document doivent avoir une description équivalente correspondante entre les balises <OBJECT> et </OBJECT>.

Les descriptions équivalentes pour les sons peuvent être fournies sous la forme d'une expression textuelle sur la page, reliée à une transcription ou à une description du fichier son. Le lien de la transcription doit être parfaitement visible, par exemple en haut de la page. Si un script charge un son automatiquement, il doit également charger un message visuel indiquant que le son est en cours d'exécution et fournir une description ou une transcription de ce dernier.

L'élément OBJECT contient un mécanisme de spécification de restitution des objets secondaires. Chaque déclaration d'OBJECT incorporé peut spécifier des types de contenu secondaire. Si un navigateur ne peut pas restituer l'OBJECT le plus à l'extérieur, il essaie d'en restituer le contenu, qui peut être un autre élément OBJECT, etc.

Insérez une description valide dans la balise <OBJECT>.

Vérifiez en particulier le contenu des balises <OBJECT> et </OBJECT>.

  • Si le contenu est une description textuelle, il doit être une transcription du fichier audio/vidéo.
  • Si le contenu est un lien, il doit pointer vers une transcription.
  • Si le contenu est une balise <OBJECT>, il doit être un fichier audio ou une transcription.
OBJECT avec CONTENT valide OBJECTwValidContent 4 Section 508 1194.22(a); WAI / WCAG 1.0 checkpoint 1.1 Accessibilit&eacute; P.1 W3C/WCAG 508 accessibilité scripts TOUT

La page contient des éléments OBJECT sans description valide entre les balises <OBJECT> et </OBJECT>.

Le contenu secondaire de l'objet correspond à la chaîne vide"". Le contenu secondaire de l'objet correspond à la chaîne vierge"". Le contenu secondaire de l'objet décrit uniquement la taille du fichier incorporé. Le contenu secondaire de l'objet décrit uniquement le nom du fichier incorporé. Le contenu secondaire de l'objet semble contenir uniquement du texte de l'espace réservé.

L'élément OBJECT contient un mécanisme de spécification de restitution des objets secondaires. Chaque déclaration d'OBJECT incorporé peut spécifier des types de contenu secondaire. Si un navigateur ne peut pas restituer l'OBJECT le plus à l'extérieur, il essaie d'en restituer le contenu, qui peut être un autre élément OBJECT, etc.

Les objets contenus dans ce document n'ont aucune description valide correspondante. Une description valide est un fragment HTML qui figure entre les balises <OBJECT> et </OBJECT> et qui contient ce qui suit :

  • au moins un mot ;
  • un autre objet ;
  • un lien vers une représentation secondaire valide.

Une description valide ne contient pas le texte de l'espace réservé (voir http://www.w3.org/TR/AERT#AppendixC).

Insérez une description valide dans la balise <OBJECT>.

La description ALT doit fournir les mêmes informations que celles de l'objet incorporé et expliquer le rôle dudit objet dans la page : pourquoi elle est là, ce qu'elle représente et comment elle présente l'information.

OBJECT with equivalent CONTENT OBJECTwEquivalentContent 4 Section 508 1194.22(a); WAI / WCAG 1.0 checkpoint 1.1 Accessibilit&eacute; P.1 W3C/WCAG 508 accessibilité scripts manuel TOUT

La description contenue entre les balises <OBJECT> et </OBJECT> des éléments OBJECT sur la page doit constituer une description équivalente des objets eux-mêmes.

L'élément OBJECT contient un mécanisme de spécification de restitution des objets secondaires. Chaque déclaration d'OBJECT incorporé peut spécifier des types de contenu secondaire. Si un navigateur ne peut pas restituer l'OBJECT le plus à l'extérieur, il essaie d'en restituer le contenu, qui peut être un autre élément OBJECT, etc.

Insérez une description suffisamment éloquente à l'intérieur de la balise <OBJECT>.

La description ALT doit fournir les mêmes informations que celles de l'objet incorporé et expliquer le rôle dudit objet dans la page : pourquoi elle est là, ce qu'elle représente et comment elle présente l'information.

Multimédia avec des solutions de remplacement synchronisées MuMediawSynchAlt 4 Section 508 1194.22(b); WAI / WCAG 1.0 checkpoint 1.4 Accessibilit&eacute; P.1 W3C/WCAG 508 accessibilité scripts manuel TOUT

La page contient des éléments tels que les balises OBJECT ou EMBED qui incorporent des fichiers multimédias ou des éléments y faisant directement référence (tels que les balises A ou AREA).

Assurez-vous que les solutions de remplacement équivalentes, comme les sous-titres ou les descriptions auditives de la piste visuelle, sont synchrones avec la présentation multimédia.

Un lien direct vers un fichier multimédia est présent. Un lien direct vers un fichier multimédia est présent. Un OBJECT incorporant un fichier multimédia est présent. Un élément EMBED pointant vers un fichier multimédia est présent.

Aux présentations auditives doivent se joindre des transcriptions ou équivalents textuels des événements auditifs. Lorsqu'elles sont présentées en parfaite synchronisation avec une présentation vidéo, ces transcriptions, alors appelées sous-titres, sont utilisées par quiconque ne peut entendre la piste audio du document vidéo.

Avec certains formats tels que QuickTime 3.0 et SMIL, il est possible d'introduire des sous-titres et des descriptions vidéo aux clips multimédias. La technologie SAMI permet l'insertion de sous-titres.

En attendant que le format emprunté prenne en charge d'autres pistes, vous pouvez développer deux versions du film : une avec sous-titres et vidéo descriptive, et l'autre sans. Grâce aux technologies telles que SMIL et SAMI, il est possible de créer des documents audio et films sous-titrés en combinant des fichiers audio/visuels distincts avec des fichiers de texte dans un fichier de synchronisation.

D'autres technologies permettent même de choisir parmi plusieurs jeux de sous-titres selon ses propres capacités de lecture. Pour plus de détails, reportez-vous à la spécification SMIL 1.0 à la page http://www.w3.org/TR/1998/REC-smil-19980615/.

La page contient des éléments tels que les balises OBJECT ou EMBED qui incorporent des fichiers multimédias ou des éléments y faisant directement référence (tels que les balises A ou AREA).
Vérifiez que les conditions suivantes sont remplies :

  • Quel que soit le contenu multimédia, un sous-titre accompagne toutes les sorties audibles
  • Tous les sous-titres et descriptions audio sont synchrones avec le contenu dynamique auquel ils se réfèrent
Multimédia avec une description audio équivalente MmediaEquivAuDescr 4 Section 508 1194.22(b); WAI / WCAG 1.0 checkpoint 1.3 Accessibilit&eacute; P.1 W3C/WCAG 508 accessibilité scripts manuel TOUT

La page contient des éléments tels que les balises OBJECT ou EMBED qui incorporent des fichiers multimédias ou des éléments y faisant directement référence (tels que les balises A ou AREA).

Assurez-vous que des descriptions auditives existent pour chaque piste visuelle de la présentation multimédia.

Un lien direct vers un fichier multimédia est présent. Un lien direct vers un fichier multimédia est présent. Un OBJECT incorporant un fichier multimédia est présent. Un élément EMBED pointant vers un fichier multimédia est présent.

En règle générale, les présentations multimédias exigent des utilisateurs qu'ils fassent appel à plusieurs de leurs sens, combinant par exemple l'ouïe et la vue. Bien que l'intérêt et le caractère "multidimensionnel" des pages Web aillent ainsi grandissant pour toute personne sans handicap, les personnes souffrant d'un handicap se heurtent à de nouveaux obstacles pour la compréhension du contenu de la page.

Pour garantir l'accessibilité du multimédia aux mal-voyants, il importe de s'assurer que des descriptions audio sont attribuées aux portions vidéo dans tous les cas, excepté là où la portion vidéo d'une présentation n'est pas indispensable à la compréhension.

Les descriptions auditives de la piste visuelle procèdent à la narration des éléments visuels clés sans empiéter sur le son ou sur le dialogue d'un film. Parmi les éléments visuels clés figurent les actions, les mises au point, le langage du corps, les graphiques et le texte affiché.

En attendant que le format emprunté prenne en charge des pistes secondaires, vous pouvez ajouter un lien vers un fichier de description audio existant.

La page contient des éléments tels que les balises OBJECT ou EMBED qui incorporent des fichiers multimédias ou des éléments y faisant directement référence (tels que les balises A ou AREA).

Vérifiez que des descriptions audio existent pour toutes les données visuelles importantes, comme par exemple :

  • pistes secondaires du fichier multimédia ;
  • liens vers des fichiers audio spécifiques.
Utilisez un langage clair pour le contenu du site ClearLangForSite 4 WAI / WCAG 1.0 checkpoint 14.1 Accessibilit&eacute; P.1 W3C/WCAG manuel TOUT

Une mise en page cohérente, des graphiques reconnaissables et un langage simple à comprendre profiteront à tous les utilisateurs ; en particulier les personnes souffrant de troubles cognitifs ou de problèmes de lecture.

L'utilisation d'un langage simple et clair garantit une meilleure communication. Les personnes souffrant de troubles cognitifs ou de problèmes de lecture ont parfois du mal à accéder aux informations écrites. L'utilisation d'un langage simple et clair profite également aux personnes de langue maternelle différente, y compris les personnes qui communiquent essentiellement par signes.

Ces quelques suggestions de style d'écriture pourront contribuer à rendre le contenu de votre site plus facile à lire :

  • Choisissez des en-têtes et des descriptions de liens clairs et concis. En effet, certains utilisateurs naviguent uniquement en passant de lien en lien et en écoutant uniquement le texte correspondant au lien.
  • Spécifiez le sujet de la phrase ou du paragraphe en début de texte (technique appelée "chargement frontal"). Ceci aidera les utilisateurs lisant en diagonale ainsi que les personnes utilisant un synthétiseur vocal.
  • Limitez chaque paragraphe à une seule idée principale.
  • Evitez l'argot, les jargons et les termes spécialisés ou familiers, à moins qu'ils ne soient définis dans votre document.
  • Utilisez de préférence des termes d'usage commun. Par exemple, utilisez "commencer" plutôt que "débuter", "essayer" plutôt que "s'efforcer".

Pour déterminer si votre document est facile à lire, vous pouvez recourir à l'algorithme de lisibilité Gunning-Fog, disponible à l'adresse suivante : http://isu.indstate.edu/nelsons/asbe336/PowerPoint/fog-index.htm. Il suffit d'entrer votre texte. Plus le score obtenu est faible, plus le contenu est facile à lire. Si votre score est dans les dizaines (ou plus !), vous risquez de perdre complètement votre audience.

Veillez à ce que le texte de la page soit facilement lisible par tout un chacun, en particulier les personnes souffrant de troubles cognitifs ou de problèmes de lecture.

Clarification de l'utilisation de la langue naturelle ClarifyNatLangUsage 4 WAI / WCAG 1.0 checkpoint 4.1 Accessibilit&eacute; P.1 W3C/WCAG manuel TOUT

Si la page contient des portions de texte écrits en plusieurs langues (anglais, français ou espagnol, par exemple), chaque portion doit être contenue dans une balise avec un attribut LANG.

Si vous utilisez plusieurs langues sur une même page, veillez à ce que chaque changement de langue soit clairement identifié à l'aide de l'attribut LANG.

Il est important d'identifier les changements de langue sur une page, pour les raisons suivantes :

  • Les utilisateurs lisant le document en braille pourront substituer les codes de contrôle appropriés (marqueurs) indiquant les changements de langue, pour que le logiciel de traduction en braille puisse générer les caractères adéquats (caractères accentués, par exemple).
  • Les synthétiseurs vocaux multilingues peuvent alors générer le texte avec l'accent et la prononciation appropriés. Si ces changements de langue ne sont pas indiqués, le synthétiseur prononce les mots dans sa langue de travail, ce qui produit généralement des sons incompréhensibles.
  • Les utilisateurs incapables de comprendre ces différentes langues pourront faire appel à des traducteurs automatiques.

Il est d'autant plus important d'identifier ces changements que de plus en plus de sites seront consultés depuis des périphériques audio tels que des téléphones.

L'attribut LANG peut également servir dans de nombreuses autres situations. Par exemple :

  • assister des moteurs de recherche ;
  • aider un navigateur à sélectionner des variantes de glyphes pour une typographie de haute qualité ;
  • aider un navigateur à choisir un jeu de guillemets ;
  • aider un navigateur à décider des césures, des ligatures et des espacements ;
  • assister les correcteurs d'orthographe et de grammaire.

Identifiez clairement les changements des langues utilisées dans le texte d'un document ainsi que les équivalents de texte, comme suit :

  • Identifiez les portions de texte écrits dans plusieurs langues.
  • Ajoutez un attribut LANG à l'élément le plus à l'intérieur contenant le texte, pour chaque portion identifiée précédemment.
AUDIO lié avec CONTENT équivalent linkedAUDIOwEquivContent 4 Section 508 1194.22(a); WAI / WCAG 1.0 checkpoint 1.1 Accessibilit&eacute; P.1 W3C/WCAG 508 accessibilité manuel TOUT

La page contient des éléments A ou AREA pointant vers des fichiers audio.

Assurez-vous que le fichier audio est décrit au sein du document ou que le document contient un lien vers une transcription ou vers un fichier contenant une description du fichier son.

La balise "A" pointe vers un fichier audio. La balise AREA pointe vers un fichier audio.

Les textes équivalents d'un contenu audio peuvent s'afficher sous forme de liens textuels vers une transcription ou vers une description du fichier son. Le lien de la transcription doit être parfaitement visible, par exemple en haut de la page.

A moins que des transcriptions ne soient fournies, les utilisateurs répertoriés ci-dessous ne peuvent percevoir la sortie du fichier audio, ni tirer parti de son contenu :

  • les sourds ou malentendants ;
  • les utilisateurs d'un périphérique audio dans un environnement bruyant ;
  • les utilisateurs ne disposant pas d'un plug-in approprié pour l'écoute des sons ;
  • les utilisateurs accédant au site au moyen d'un ordinateur dépourvu de périphérique audio ;
  • les utilisateurs accédant au site dans un lieu où il est interdit d'émettre des sons, comme une bibliothèque publique.

Insérez une description suffisamment éloquente du fichier audio.
Assurez-vous notamment que la page contient l'un des éléments suivants :

  • une transcription du fichier audio/vidéo ;
  • un lien pointant vers une transcription.
Des balises propriétaires sont utilisées proprietaryTagsAreUsed 4 suggestions suggestions manuel TOUT

La page contient des balises propriétaires qu'un serveur Web remplace par une ou plusieurs balises HTML. Par conséquent, il n'est pas possible de vérifier l'accessibilité du fichier d'origine. Une évaluation exhaustive exige que la version finale de la page soit testée ; pour ce faire, ouvrez la page dans un navigateur, enregistrez-la et testez la version enregistrée.

Certaines technologies Web, telles que ColdFusion, créent des types particuliers de données et de comportements en s'aidant de balises spéciales. Lorsqu'il reçoit une demande pour la page, le serveur remplace toutes les balises spéciales par des balises HTML, puis envoie la page au navigateur de l'utilisateur. La page reçue par l'utilisateur ne doit plus contenir aucune balise propriétaire.

L'accessibilité d'une page peut s'avérer impossible à vérifier pour les raisons suivantes :

  • Le site contient peut-être des pages au format ColdFusion ou ASP.NET qui sont créées d'une façon dynamique
  • Les pages locales font peut-être partie intégrante d'un site plus vaste qu'il faudrait tester globalement
  • Les pages locales contiennent peut-être des balises spéciales propriétaires que le serveur Web doit remplacer avant d'envoyer la page au navigateur de l'utilisateur
  • Pour les pages en ligne, il est aussi possible de tester la durée de téléchargement réelle et le temps de réponse du serveur
  • Le serveur peut transmettre des pages légèrement différentes selon les navigateurs
  • Les pages peuvent contenir des liens externes vers le site Web

Pour toutes ces raisons, il n'est pas toujours possible de vérifier complètement l'accessibilité d'une page dans son état d'origine. Vous devez la tester dans son état final.

A l'aide d'un navigateur, consultez la page à partir du serveur. La page qui s'ouvre dans le navigateur ne doit plus contenir aucune balise prioritaire. Enregistrez la page à l'aide de la commande Enregistrer du navigateur (dans Microsoft Internet Explorer, choisissez Fichier > Enregistrer sous), puis testez la version enregistrée pour en vérifier l'accessibilité.