TOUTES Cette catégorie contient toutes les règles. Accessibilité P.2 W3C/WCAG Cette catégorie contient les règles d'accessibilité (priorité 2) spécifiées par le groupe W3C/WAI (http://www.w3.org/TR/WAI-WEBCONTENT). Voir les références aux normes WAI à l'adresse http://www.w3.org/WAI/References pour en savoir plus sur l'accessibilité au Web. images Cette catégorie contient les règles régissant les images incorporées aux documents HTML. manuelle Cette catégorie contient les règles nécessitant une inspection manuelle des documents HTML. formulaires Cette catégorie contient des règles régissant les formes et les éléments associés. cadres Cette catégorie contient des règles régissant les cadres et les éléments associés. tableaux Cette catégorie contient des règles régissant les tableaux et les éléments associés. images interactives Cette catégorie contient les règles régissant les images hypertexte. liens Cette catégorie contient des règles régissant les images comprenant des liens et des barres de navigation. scripts Cette catégorie contient les règles régissant les objets programmés. 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 des règles recommandant comment utiliser le service en ligne LIFT à l'adresse www.usablenet.com. Faire en sorte que le contraste soit suffisant entre les couleurs au premier plan et celles en arrière-plan fgColOverBgCol Point de contrôle 2.2 de priorité 2 WAI / WCAG 1.0 Accessibilité P.2 W3C/WCAG TOUTES manuelle images images interactives css

La page contient des images, des objets ou des applets. Des cas peuvent exister oł le contraste entre les couleurs au premier plan et celles en arrière-plan n'est pas suffisant pour les différencier.

Il existe de nombreuses situations oł un choix limité de couleurs empêche la perception et la compréhension de certaines informations ou images se trouvant sur la page.

Ceci est dû à plusieurs facteurs, notamment au fait que :

  • le choix des couleurs de premier plan et d'arrière-plan est limité ;
  • la personne visitant le site Web utilise un écran ne rendant pas la même qualité des couleurs que celui utilisé par le concepteur de la page ;
  • la personne visite le site Web sur un écran noir et blanc d'un assistant personnel ou d'un téléphone portable ;
  • la personne visitant le site Web doit imprimer la page sur une imprimante noir et blanc ;
  • la personne visitant le site Web est daltonienne.

Issu des instructions W3C :

Instruction 2. Ne pas se fier uniquement à la couleur.
Vérifiez que le texte et les images sont lisibles lorsqu'ils sont affichés en noir et blanc.

Si vous n'utilisez que la couleur, les personnes ne pouvant pas faire la différence entre certaines couleurs et celles utilisant des écrans noir et blanc et des supports autres que visuels ne peuvent pas recevoir les informations. Lorsque la teinte des couleurs au premier plan et d'arrière-plan est presque identique, le contraste risque d'être insuffisant lorsque celles-ci sont affichées sur un écran monochrome ou chez les personnes ne percevant pas correctement les couleurs.

Vérifiez qu'il est facile de faire la différence entre les couleurs et les éléments colorés sur la page, quel que soit le support utilisé pour afficher la page Web.
Vérifiez que le contraste entre les éléments au premier plan et ceux en arrière-plan ne passe pas uniquement par les couleurs. La luminosité (c'est-à-dire le contraste noir et blanc), différents styles de police, différentes tailles ou noms de police peuvent également être utilisés.

Si vous vous servez de la couleur, accentuez les différences entre les couleurs au premier plan et celles en arrière-plan en vous aidant de ces trois paramètres :

  • teinte
  • saturation
  • luminosité

Pour tester facilement la page, vous pouvez :

  • afficher la page en noir et blanc et examinez chacun de ses éléments ;
  • imprimer la page sur une imprimante noir et blanc ;
  • photocopier deux ou trois fois la page imprimée pour contrôler si les couleurs bougent ou pas. Vous pouvez ainsi repérer les endroits nécessitant l'ajout d'aides visuelles (notamment des traits de soulignement) ou déterminer si les aides visuelles ne peuvent tenir car trop petites ou imprécises.
Utiliser des balises plutôt que des images mrkpRtImg Point de contrôle 3,1 de priorité 2 WAI / WCAG 1.0 Accessibilité P.2 W3C/WCAG TOUTES manuelle images images interactives css

La page contient des images dont les informations peuvent ne pas être correctement balisées en langage HTML.
Par exemple, vous pouvez utiliser MathML pour baliser des équations mathématiques et des feuilles de style pour mettre en forme le texte et contrôler la mise en page.
Il est déconseillé d'utiliser des images pour représenter du texte. Utilisez à la place du texte et des feuilles de style.

Selon le W3C (http://www.w3.org/TR/WCAG10-CORE-TECHS/#structure) :

Lors de la conception d'un document ou d'une série de documents, les développeurs de contenu doivent d'efforcer à identifier la structure souhaitée pour leurs documents avant de se pencher sur comment les documents doivent être perçus par l'utilisateur. Distinguer la structure d'un document de la manière dont son contenu est présenté offre de nombreux avantages, notamment une meilleure accessibilité, maniabilité et une meilleure portabilité.

Savoir identifier la structure de la présentation peut parfois être un véritable challenge. Par exemple, de nombreux développeurs de contenu considèrent qu'une ligne horizontale équivaut à une division structurelle. Cela peut être le cas chez les personnes sans troubles de la vision, mais pas chez celles ne percevant pas correctement les couleurs ou celles sans navigateur graphique. Pour ces personnes-là, la ligne horizontale risque de n'avoir aucun sens. Par exemple, dans un document HTML, les développeurs doivent utiliser les éléments d'en-tête HTML 4.01 (H1-H6) pour identifier les nouvelles sections. Ils peuvent être complétés par des aides visuelles ou tout autre élément, notamment des règles horizontales, mais ils ne doivent pas les remplacer

et vice versa. Les développeurs de contenu ne doivent pas utiliser les éléments structurels pour parvenir à réaliser des effets de présentation. Par exemple, en langage HTML, même si l'élément BLOCKQUOTE peut augmenter ou réduire le retrait du texte dans certains navigateurs, celui-ci est conçu pour identifier une citation et non pas pour créer un effet secondaire de présentation. Les éléments BLOCKQUOTE utilisés pour la mise en retrait peuvent gêner aussi bien les utilisateurs que les moteurs de recherche, qui s'attendent à ce que l'élément soit utilisé pour baliser les blocs de citation.

Pour déterminer si le contenu est de type structure ou présentation, créez une structure du document. Chaque point de la hiérarchie indique un changement structurel. Utilisez une balise de structure pour baliser ces changements et une balise de présentation pour améliorer leur qualité visuelle et audio. Sachez que les règles horizontales ne figurent pas dans cette structure et sont de ce fait de type présentation et non pas de type structure. Remarque : l'objet de ce test rapide est la structure des chapitres, des sections et des paragraphes. Pour déterminer la structure à l'intérieur d'une expression, recherchez les abréviations, les modifications en langage naturel, les définitions et les éléments de liste.

Dans un autre document (&wcag;), on peut lire :

Instruction 3. Utilisez correctement les balises et les feuilles de style.
Balisez les documents constitués des éléments de structure appropriés. Contrôlez les présentations via des feuilles de style et non pas à l'aide d'éléments.

L'utilisation incorrecte des balises (c'est-à-dire sans tenir compte des spécifications) entravent l'accessibilité. L'utilisation incorrecte d'une balise avec un effet de présentation (par exemple, en utilisant un tableau pour une mise en page ou un en-tête pour modifier la taille de la police) empêche l'utilisateur équipé d'un logiciel spécialisé de bien comprendre l'organisation de la page et d'y naviguer correctement. En outre, l'utilisation d'une balise de présentation au lieu d'une balise de structure pour créer la structure (par exemple, en concevant l'aspect d'un tableau de données à l'aide d'un élément HTML " PRE ") entrave la lisibilité de la page sur tout autre périphérique [...].

Les développeurs de contenu peuvent être tentés d'utiliser (bien ou mal) des constructions afin d'obtenir un effet de mise en page donné sur des navigateurs plus anciens. Cela peut entraîner des problèmes d'accessibilité. Si tel est le cas, demandez-vous si l'effet de mise en page est indispensable et si vous êtes prêt à prendre le risque que certains utilisateurs ne parviennent pas à accéder au document.

A l'opposé, les développeurs de contenu ne doivent pas sacrifier la balise adaptée même si un navigateur ou une technologie d'aide ne parvient pas à la traiter correctement. Par exemple, il est correct d'utiliser l'élément TABLE dans un document HTML pour baliser les informations tabulaires même si certains lecteurs d'écran anciens peuvent ne pas gérer correctement le texte côte à côte (voir le point de contrôle 10.3). L'utilisation correcte de l'élément TABLE et la création de tableaux facilement modifiables (voir instruction 5) permet au logiciel de rendre des tableaux autrement que sous forme de grille à deux dimensions.

Si l'image contient :

  • du texte rendu dans une police fantaisie, servez-vous des propriétés CSS destinées aux polices pour obtenir le même effet ;
  • une formule mathématique, utilisez MathML pour l'encoder ; voir W3C page on MathML.
Le document doit respecter les grammaires publiées docValFrmGrm Point de contrôle 3,2 de priorité 2 WAI / WCAG 1.0 Accessibilité P.2 W3C/WCAG TOUTES manuelle css

L'instruction exige que la page soit correcte.

Vérifiez cette page à l'aide de XML Validator. Vérifiez les feuilles de style associées à la page à l'aide de XML Validator. Vérifiez cette page à l'aide de Markup Validator. Vérifiez cette page XHTML à l'aide de XML Validator. Vérifiez les feuilles de style CSS associées à la page à l'aide d'un valideur CSS.

Si vous utilisez les normes de codage adaptées, il est possible de développer des documents, dont vous êtes garantis qu'ils sont (en fin de compte) potentiellement compatibles avec tout type de navigateur Internet et d'agent.

En revanche, le codage appliqué à un type et une version spécifique de navigateur peut rendre illisibles les documents par les versions actuellement utilisées, les nouvelles versions ou celles développées. Tenez compte du fait que, outre les navigateurs standard, certains utilisateurs peuvent également utiliser un navigateur vocal (par exemple, Home Page Reader), un navigateur en mode texte (par exemple, lynx) ou des navigateurs destinés aux assistants personnels et téléphones portables. En outre, les sites Web peuvent également être visités par des robots de moteurs de recherche et d'agents de collecte d'informations plus spécialisés. Ces derniers bénéficient également d'un document conforme aux normes en vigueur.

Les valideurs syntaxiques permettent de déterminer la présence d'erreurs dans les documents ; erreurs insérées par inadvertance pouvant entraîner des problèmes d'accessibilité inattendus, voire parfois indétectables.

Vérifiez que le code de la page est correct. Utilisez Markup Validator, XML Validator ou un valideur CSS pour déceler tout problème et trouver des solutions durables.

Vérifiez que la page contient du code parfaitement correct.

Se servir d'un identificateur de texte public dans une déclaration DOCTYPE publicDoctype Point de contrôle 3,2 de priorité 2 WAI / WCAG 1.0 Accessibilité P.2 W3C/WCAG TOUTES

L'élément DOCTYPE est absent ou incorrect.

La page ne contient aucun élément DOCTYPE défini. La page contient plusieurs instances de DOCTYPE. La page contient un élément DOCTYPE mal formé. La page contient un élément DOCTYPE ne faisant pas référence à une DTD publiée officielle.

Selon les normes HTML, chaque document HTML requiert une déclaration de type de document (DTD). Le DOCTYPE est situé au début du document HTML et indique la version du document HTML à laquelle vous devez vous attendre lors du traitement du document.

La déclaration DOCTYPE identifie le langage informatique et la version dans laquelle le document a été codé. A l'aide de ces informations, les navigateurs peuvent interpréter correctement les fonctions d'accessibilité du document.
Cette condition est importante en terme d'accessibilité, du fait que les technologies d'aide peuvent être amenées à se servir de cette déclaration pour déterminer le traitement du document.

Lors de l'utilisation de documents autres qu'au format HTML (par exemple, le langage SMIL ou SVG) servez-vous de la déclaration DOCTYPE adaptée à ce langage de balisage pour être sûr que les navigateurs ne se trompent en l'interprétant comme du langage HTML.

Si l'élément DOCTYPE est absent, ajoutez-en un. S'il n'est pas correct, corrigez-le.

Vérifiez la validité du DOCTYPE à l'aide du valideur.

Le DOCTYPE doit contenir la version du langage HTML utilisé. Par exemple, HTML 4.01 peut reposer sur trois variantes différentes (c'est-à-dire trois DTD). Il est important d'inclure une des déclarations de type de document suivantes dans les documents. Les DTD varient en fonction des éléments qu'ils prennent en charge.
Pour définir le DOCTYPE de la page, insérez un des DOCTYPE suivants juste avant la balise HTML, au début du document :

  <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" 
       "http://www.w3.org/TR/html4/strict.dtd">
  <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" 
       "http://www.w3.org/TR/html4/loose.dtd">
  <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" 
       "http://www.w3.org/TR/html4/frameset.dtd">
Le DOCTYPE suivant est pour XHMTL Strict (et d'autres semblables existent pour les variantes Transitional et Frameset : voir la page XHTML 1.0 par W3C) :
  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

Utiliser des feuilles de style SSCtrlLyPr Point de contrôle 3,3 de priorité 2 WAI / WCAG 1.0 Accessibilit&eacute; P.2 W3C/WCAG TOUTES tableaux cadres formulaires css

La page contient des balises ou des attributs désapprouvés (c'est-à-dire, qu'ils ne font plus partie du langage HTML 4.01 et dont l'usage est déconseillé par le W3C). Ces balises/attributs peuvent être remplacés par les règles CSS appropriées sans le moindre risque.

Voir la liste des balises du langage HTML 4.01 désapprouvées.

Vous obtenez les avantages suivants en utilisant les règles de présentation CSS plutôt que les balises et les attributs (désapprouvés) du langage HTML.

  • le code que vous développez respecte davantage les normes et sera automatiquement compatible une fois que l'ensemble des navigateurs et des agents appliqueront les normes ;
  • la gestion des pages développées est plus facile (du fait que le code de la présentation doit être isolé dans la feuille de style CSS partagée par toutes ou la plupart des pages) ;
  • les pages développées seront moins " encombrées ". En effet, il n'est pas nécessaire de répéter les balises telles que FONT pour spécifier le nom et la couleur des polices. Le téléchargement est plus rapide (du fait que la taille de la page est réduite et que le navigateur ne peut télécharger le fichier CSS qu'une seule fois depuis le site) ;
  • Il est possible de réutiliser la même page HTML et de lui appliquer plusieurs fichiers CSS pour que l'utilisateur du navigateur puisse choisir le style de rendu à utiliser (parmi ceux définis).

Remplacez les balises et les attributs désapprouvés par les propriétés et les règles appropriées. Par exemple, utilisez les propriétés CSS " font " (notamment, font-size, font-family, font-weight) au lieu de l'élément HTML FONT pour contrôler les styles de police ; utilisez style="{float: left}" à la place de align="left" ; utilisez style="border:none" à la place de border="0" (à l'intérieur des balises IMG).

Voir la liste des balises du langage HTML 4.01 désapprouvées.

Spécifier la taille des cadres en pourcentage frameSize Point de contrôle 3,4 de priorité 2 WAI / WCAG 1.0 Accessibilit&eacute; P.2 W3C/WCAG TOUTES cadres

La page contient un ou plusieurs jeux de cadres spécifiant la taille des cadres via des unités absolues plutôt que relatives.

L'attribut ROWS spécifie la hauteur fixe des cadres intérieurs. L'attribut COLS spécifie la largeur fixe des cadres intérieurs.

Utilisez autant que possible des unités relatives.

Utilisez des pourcentages plutôt que des unités absolues pour la hauteur et la largeur des cadres.

De cette façon, la présentation peut s'adapter au navigateur spécifique que vous utilisez ainsi qu'à l'écran.

Dans le cas spécifique des cadres, l'utilisation de pourcentages a pour avantage que l'utilisateur du navigateur (la personne visitant le site) peut redimensionner toute la fenêtre ou seulement un cadre sans perdre une partie du contenu de la page.

Utilisez des pourcentages plutôt que des valeurs absolues. Remplacez les valeurs des attributs ROWS ou COLS du jeu de cadres par des pourcentages.

Spécifier la taille des tableaux en pourcentage tableSize Point de contrôle 3,4 de priorité 2 WAI / WCAG 1.0 Accessibilit&eacute; P.2 W3C/WCAG TOUTES tableaux

La page contient des tableaux spécifiant la largeur ou la hauteur des lignes ou des colonnes en valeurs absolues plutôt qu'en valeurs relatives, telles que des pourcentages.

L'attribut WIDTH spécifie une taille fixe pour TABLE. L'attribut WIDTH spécifie une taille de cellule de tableau fixe. L'attribut HEIGHT spécifie une hauteur de cellule fixe.

Utilisez autant que possible des unités relatives.

Utilisez des pourcentages plutôt que des unités absolues pour la hauteur et la largeur des tableaux.

De cette façon, la présentation peut s'adapter au navigateur spécifique que vous utilisez ainsi qu'à l'écran.

Dans le cas spécifique des tableaux, l'utilisation de pourcentages a pour avantage que l'utilisateur du navigateur (la personne visitant le site) peut redimensionner toute la fenêtre sans perdre une partie du contenu de la page.

Pour spécifier la taille des tableaux et des cellules de tableau, utilisez des pourcentages plutôt que des valeurs absolues. Remplacez les valeurs des attributs WIDTH ou HEIGHT des éléments TABLE, TH ou TD par des pourcentages.

Utiliser des unités relatives dans CSS relThAbsUnitMrkpSS Point de contrôle 3,4 de priorité 2 WAI / WCAG 1.0 Accessibilit&eacute; P.2 W3C/WCAG TOUTES css

La page fait référence aux propriétés CSS spécifiées en utilisant des unités absolues (par exemple, 'in', 'px', 'mm') plutôt que des unités relatives (par exemple, '%', 'em'). Ces unités sont utilisées dans les attributs STYLE ou dans les fichiers CSS externes reliées via l'élément LINK.

Utilisez autant que possible des unités relatives.

De cette façon, la présentation peut s'adapter au navigateur spécifique que vous utilisez ainsi qu'à l'écran.

Utilisez des unités relatives plutôt qu'absolues dans les valeurs de propriétés des feuilles de style. Remplacez toutes les unités 'px', 'pt', 'pc', 'cm' et 'mm' par des pourcentages ou par 'em'.

Utilisez des unités absolues lorsque vous êtes sûr du type de périphérique utilisé par la personne visitant le site Web (tel qu'une webTV), ou dans les cas oł la géométrie de l'objet à afficher ne peut pas être modifiée sans être déformée (par exemple, une image gif).

Il est recommandé de ne pas utiliser d'unités absolues pour définir la taille de la police.

Utiliser des unités relatives dans les propriétés de champ CSS relThAbsUnitMrkpSSBox Point de contrôle 3,4 de priorité 2 WAI / WCAG 1.0 Accessibilit&eacute; P.2 W3C/WCAG TOUTES manuelle css

La page fait référence aux propriétés CSS spécifiées en utilisant des unités absolues (par exemple, 'in', 'px', 'mm') plutôt que des unités relatives (par exemple, '%', 'em'). Ces unités sont utilisées dans les attributs STYLE ou dans les fichiers CSS externes reliées via l'élément LINK.

Utilisez autant que possible des unités relatives.

De cette façon, la présentation peut s'adapter au navigateur spécifique que vous utilisez ainsi qu'à l'écran.

Utilisez des unités relatives plutôt qu'absolues dans les valeurs de propriétés des feuilles de style. Remplacez toutes les unités 'px', 'pt', 'pc', 'cm' et 'mm' par des pourcentages ou par 'em'.

Utiliser des éléments d'en-tête useHeaders Point de contrôle 3,5 de priorité 2 WAI / WCAG 1.0 Accessibilit&eacute; P.2 W3C/WCAG TOUTES

La page ne contient pas d'éléments d'en-tête (H1, H2, ... ou H7).

Utilisez des en-têtes HTML (H1, H2, ..., H7) pour créer une structure hiérarchisée des différentes sections affichées dans la page.

De cette façon, les personnes visitant le site peuvent balayer du regard la structure du document, puis identifier la partie la plus utile sans avoir à lire tout le texte.

En outre, il est possible avec plusieurs navigateurs vocaux ou lecteurs d'écran d'obtenir une liste de tous les en-têtes du document et d'afficher directement un en-tête spécifique. Cela peut s'avérer très pratique pour les personnes qui ne peuvent pas voir le document si, par exemple, les personnes sont malvoyantes, aveugles ou qu'elles accèdent au site Web par téléphone. De cette façon, la personne visitant le site n'a pas à écouter tout le texte avant d'atteindre la partie qui l'intéresse.

Insérez au moins un élément d'en-tête dans le document. Respectez la hiérarchie des niveaux : par exemple, passez du niveau d'en-tête H1 à H2,

Un test rapide pour déterminer les en-têtes nécessaires consiste à créer une structure du contenu de la page. Commencez par un niveau (par exemple, H3) et appliquez cette même balise (H3) aux sections consécutives de la structure. Lorsqu'une section plus détaillée commence, utilisez un niveau d'en-tête supérieur (par exemple, H4).

Si la mise en forme par défaut des en-têtes n'est pas acceptable, définissez une classe CSS en utilisant les propriétés de votre choix, puis utilisez cette classe chaque fois que vous insérez un en-tête.

Utiliser des éléments d'en-tête en tenant compte des spécifications hdElAccSpec Point de contrôle 3,5 de priorité 2 WAI / WCAG 1.0 Accessibilit&eacute; P.2 W3C/WCAG TOUTES manuelle

La page contient des éléments d'en-tête (H1, H2, ... ou H7).

Utilisez des en-têtes HTML (H1, H2, ..., H7) en tenant compte des spécifications.

Respectez la hiérarchie des niveaux : Passez du niveau d'en-tête H1 à H2, mais pas de H1 à H3.

Baliser correctement des listes et des éléments associés mrkLstItmPrp Point de contrôle 3,6 de priorité 2 WAI / WCAG 1.0 Accessibilit&eacute; P.2 W3C/WCAG TOUTES manuelle

La page contient au moins deux images identiques qui ne sont pas des espaces et qui peuvent être utilisées comme puces dans une liste d'éléments sous forme de tableau.

Chaque fois que des indications visuelles sont utilisées (par exemple, une mise en retrait) pour indiquer le niveau d'imbrication des éléments du texte, les personnes ne pouvant utiliser ou profiter du rendu des images à deux dimensions ne seront pas en mesure de voir ces indications. C'est le cas notamment des malvoyants et des aveugles, ainsi que toute personne utilisant un navigateur non graphique, par exemple un navigateur vocal pour téléphone portable ou assistant personnel.

Par conséquent, il est important d'utiliser la balise de structure appropriée permise par le langage HTML pour coder ces indications ayant un rôle fondamental. La personne utilisant un lecteur d'écran ou un navigateur vocal peut parcourir les niveaux des listes imbriquées si ceux-ci sont correctement codés. Ils peuvent ainsi passer directement à un élément donné.

Si plusieurs niveaux de listes ordonnées (numérotées) sont utilisés, vérifiez que les en-têtes numérotés affichés contiennent des informations contextuelles. Par exemple, les éléments de la liste de second niveau doivent être numérotés 1.1, 1.2 ... ou 1.a, 1.b, etc. Puisque les personnes peuvent naviguer librement, les informations contextuelles permettent à l'utilisateur écoutant un élément, la plupart du temps sans contexte, de mieux identifier l'élément de la liste qu'il écoute actuellement.

Par exemple, si les mêmes éléments sont numérotés : 1, 2, 3, etc., la personne qui écoute ne pourrait pas distinguer les éléments faisant partie d'une liste secondaire.

Vérifiez que les images sont utilisées comme puce sur cette page dans les listes d'objets détaillées. Si tel est le cas, remplacez le tableau et les images par la balise qui convient. Utilisez une liste comme wrapper et un élément de liste (LI ou DD et DT) pour baliser chaque élément de ces listes.

Utilisez des listes non ordonnées (UL), ordonnées (OL) (c'est-à-dire numérotées) ou des listes de définitions (DL). Les listes peuvent être imbriquées de plusieurs manières, par exemple, en utilisant une liste UL dans une liste LI d'une liste OL. Il est également possible de modifier le symbole utilisé comme puce en se servant de la propriété CSS appropriée (list-style).

Pour plus d'informations, voir &w3c_html_tech;

Baliser des citations mrkpQuot Point de contrôle 3,7 de priorité 2 WAI / WCAG 1.0 Accessibilit&eacute; P.2 W3C/WCAG TOUTES manuelle

La page peut contenir des citations (des références à des commentaires faits par une " source " extérieure) non correctement codées en HTML.

Un balisage correct des citations est nécessaire aux personnes visitant des sites Web via un lecteur d'écran ou un navigateur vocal car celui-ci peut utiliser une voix ou une hauteur tonale différente lors de lecture des citations.

De cette façon, la personne qui écoute est capable de noter le changement de voix ou de vitesse pendant son écoute.

Vérifiez que la page contient des citations (c'est-à-dire des références à des commentaires faits par une " source " extérieure). Si tel est le cas, assurez-vous qu'elles sont correctement balisées en HTML avec des éléments BLOCKQUOTE ou Q. Une meilleure option serait que les propriétés de mise en forme soient spécifiées à l'aide de règles CSS.

Utilisez l'élément BLOCKQUOTE pour baliser une longue citation (un ou plusieurs paragraphes de long). Utilisez l'élément Q pour baliser une citation plus courte (BLOCKQUOTE est une balise de bloc et Q une balise inline).

Eviter d'utiliser des balises de citation pour les effets de mise en forme noQtMrkpFrmEff Point de contrôle 3,7 de priorité 2 WAI / WCAG 1.0 Accessibilit&eacute; P.2 W3C/WCAG TOUTES manuelle

La page contient du texte balisé avec un élément BLOCKQUOTE ou Q. Si le texte n'est pas une citation, le code HTML doit être modifié.

Une mauvaise utilisation de ces balises (pour obtenir certains effets de mise en forme) entrave l'accessibilité. Lorsqu'un lecteur d'écran ou un navigateur vocal lit le texte mal balisé, celui-ci utilise une voix ou une hauteur tonale différente pour que la personne qui écoute sache qu'il s'agisse d'une citation (c'est-à-dire une référence à des commentaires faits par une " source " extérieure).

Une personne qui écoute pourrait perdre le fil si la citation faisait partie du contenu de la page simplement incorporé dans un élément BLOCKQUOTE ou Q à des fins de mise en forme.

Vérifiez que le texte inclus dans l'élément BLOCKQUOTE (ou Q) dans la page est effectivement une citation.

Dans le cas contraire, supprimez la balise BLOCKQUOTE (ou Q) et remplacez-la par une balise DIV (ou SPAN) associée à une classe CSS spécifiant que les propriétés de mise en forme seront obtenues avec un élément BLOCKQUOTE (ou Q).

Logique des tableaux de mis en page une fois linéarisés linTbUseLyNoSs Point de contrôle 5,3 de priorité 2 WAI / WCAG 1.0 Accessibilit&eacute; P.2 W3C/WCAG TOUTES manuelle tableaux

La page contient au moins un tableau censé servir à des fins de mise en page (c'est-à-dire qu'il ne contient pas de balises CAPTION, THEAD, TH et TFOOT).

Une fois linéarisé, son contenu doit être lu dans l'ordre prévu et doit être compréhensible.

Souvent lorsque l'accessibilité n'est prise en compte une fois que les modèles ont été définis et mis en place, l'organisation du tableau utilisée pour mettre en page le contenu ne fonctionne pas correctement avec les navigateurs non graphiques.

Ne pas penser que les tableaux HTML mettent en page les informations ligne par ligne est l'erreur qui revient le plus souvent.

Les navigateurs non graphiques suivent l'ordre ligne par ligne lors de la présentation du contenu du tableau, même si des indications visuelles pourraient suggérer un ordre de lecture colonne par colonne.

Par exemple (à partir de &w3c_html_tech;) :

... Si un tableau est rendu de cette manière sur l'écran :

There is a 30% chance of               Classes at the University of Wisconsin 
rain showers this morning, but they    will resume on September 3rd. 
should stop before the weekend.

Le lecteur d'écran peut lire le texte de la manière suivante :

There is a 30% chance of Classes at the University of Wisconsin
rain showers this morning, but they will resume on September 3rd. 
should stop before the weekend.

Linéarisation est le processus qui consiste à transformer une structure à deux dimensions, par exemple un tableau, en une structure à une seule dimension. Il s'agit du processus que tout navigateur vocal ou tout lecteur d'écran doit suivre pour rendre oralement le contenu de la page.

Vérifiez que le contenu linéarisé des tableaux de mise en page se trouvant dans la page peut être lu dans le bon ordre. Le principe est facile : il suffit de retirer toutes les balises.

Dans certains cas, il suffit de faire glisser un bout de papier le long de la page afin de lire ligne après ligne et ainsi obtenir certaines indications quant à d'éventuels problèmes.

Les tableaux utilisés pour présenter les données tabulaires ne doivent pas être linéarisés, contrairement à ce qui a été dit plus haut. Pour être accessibles, les tableaux doivent être correctement balisés (à l'aide de balises et d'attributs TH, SCOPE, AXIS, ID et HEADERS). D'autres tests de ce programme mettent en place les instructions du WCAG ou de la section 508 appropriées.

Eviter d'utiliser des balises de structure pour la mise en forme visuelle noStrMrkpVslFrmTbLy Point de contrôle 5,4 de priorité 2 WAI / WCAG 1.0 Accessibilit&eacute; P.2 W3C/WCAG TOUTES manuelle tableaux

La page contient un tableau utilisé pour présenter des informations tabulaires plutôt qu'à des fins de mise en page (" Informations tabulaires " signifie que la grille à deux dimensions du tableau sert à représenter les relations logiques entre les données se trouvant dans les cellules du tableau).

Vérifiez que le tableau sert effectivement à présenter des informations tabulaires.

Si le tableau ne représente pas les relations entre les informations, mais qu'il ne sert qu'à afficher une grille à l'écran, cela signifie que la page n'a pas réussi le test.

L'utilisation d'une balise telle que TH pour son effet visuel entrave l'accessibilité. En réalité, certaines technologies d'aide, c'est le cas de ses navigateurs vocaux, utilisent le contenu de l'élément TH lorsque l'utilisateur parcoure un tableau. Chaque fois qu'un utilisateur visite une cellule du tableau, le navigateur recherche la cellule d'en-tête correspondante (qui porte la balise TH) et lit son contenu. De cette façon, l'utilisateur est en mesure de connaître le contexte de la cellule visitée.

Cependant, si les balises TH ne sont utilisées qu'à des fins visuelles, le contexte paraîtra très confus pour la personne se servant d'un navigateur vocal.

Vérifiez le tableau et son contenu pour déterminer s'il est utilisé pour présenter des informations tabulaires.

Si le tableau ne sert qu'à des fins de mise en page, il ne doit pas contenir de balises, telles que CAPTION, TH, THEAD ou TFOOT pour obtenir des effets de mise en forme spéciaux.

Supprimez les balises CAPTION, THEAD et TFOOT et remplacez tous les TH par les TD correspondants. Définissez ensuite une classe CSS avec les propriétés de mise en forme nécessaires (par exemple, " font-weight: bold; text-align: center; ") et ajoutez une classe à chaque TD créé.

Utiliser des gestionnaires d'événements indépendants du périphérique inptDevIndEvHndScrApl Point de contrôle 6,4 de priorité 2 WAI / WCAG 1.0 Accessibilit&eacute; P.2 W3C/WCAG TOUTES scripts

La page contient des gestionnaires pour certains événements nécessitant l'utilisation de la souris et pour lesquels aucun gestionnaire d'événements de type clavier n'existe.

En particulier :

  • le gestionnaire d'événements ondblclick n'a, en HTML 4.01, aucun événement clavier correspondant et par conséquent, il ne doit pas être utilisé.
  • le gestionnaire d'événements onmousedown va de paire avec l'événement onkeydown ;
  • le gestionnaire d'événements onmouseup va de paire avec l'événement onkeyup ;
  • le gestionnaire d'événements onclick va de paire avec l'événement onkeypress ;
  • le gestionnaire d'événement onmouseover va de paire avec l'événement onfocus pour les liens et la plupart des contrôles de formulaire (oł il est généralement utilisé pour mettre en place des zones de survol) ; sur les champs de texte des formulaires, onclick doit être remplacé par onfocus, puisque onfocus active les champs de texte lorsque l'utilisateur appuie sur le bouton de la souris ou sur les touches Ctrl+Tab.
  • le gestionnaire d'événements onmouseout va de paire avec l'événement onblur.
Spécifiez des mécanismes de saisie redondants (par exemple, deux gestionnaires pour le même élément). En langage HTML 4.01, il n'y a pas d'équivalent au double-clic (" ondblclick ").

Un gestionnaire d'événements est un script invoqué lorsqu'un certain événement se produit (par exemple, déplacement de la souris, utilisation d'une touche du clavier, chargement d'un document, etc.). Les gestionnaires d'événements sont reliés à des éléments HTML via des attributs de gestionnaires d'événements (notamment, " ONMOUSEDOWN ", " ONCLICK ", " ONKEYUP ", etc.).

L'effet d'un gestionnaire d'événements est purement visuel : mise en surbrillance d'une portion de texte, d'une image ou changement de la couleur de certaines parties de la page. Dans d'autres cas, cependant, le gestionnaire d'événements réalise des activités plus importantes : il valide les saisies dans un formulaire ; affiche un menu déroulant ; ouvre une fenêtre, etc.
Dans tous ces cas, oł le contenu fourni est modifié ou les options de navigation offertes à l'utilisateur changent, le gestionnaire d'événements doit être entièrement accessible pour offrir les mêmes changements aux personnes se servant de technologies d'aide ou aux fonctions limitées.

Si un gestionnaire d'événements fait uniquement référence à un périphérique spécifique (par exemple, la souris, ce qui est le cas avec l'événement " ONMOUSEOVER "), l'utilisateur sans souris (par exemple, une personne ayant des troubles moteur ou un conducteur visualisant le site Web sur un ordinateur installé dans sa voiture) ne sera pas en mesure de bénéficier de l'effet du gestionnaire.

Selon le W3C, indépendance du périphérique signifie que (&wcag;) :

Les utilisateurs doivent pouvoir interagir avec un agent utilisateur (et le document qu'il rend) à l'aide des périphériques d'entrée et de sortie de leurs choix et en fonction de leurs besoins. Les périphériques d'entrée comprennent notamment les périphériques de pointage, d'entrée braille, les claviers, les licornes, les micros, etc. Les périphériques de sortie comprennent notamment les moniteurs, les synthétiseurs vocaux et les périphériques de lecture braille.

Contrôlez tous les gestionnaires d'événements définis dans la page. Ne tenez compte que des gestionnaires qui modifient le contenu de la page (en ajoutant ou supprimant du texte, des images, des calques et autres objets) ou les options de navigation (menus, nouvelles fenêtres, barres de navigation ou liens).

Si n'importe lequel de ces gestionnaires est spécifié à l'aide d'événements dépendants du périphérique (c'est-à-dire, ONDBLCLICK, ONCLICK, ONKEYPRESS, ONKEYDOWN, ONMOUSEDOWN, ONKEYUP, ONMOUSEUP, ONMOUSEOVER, ONMOUSEOUT, ONFOCUS et ONBLUR), ils doivent être également associés aux gestionnaires d'événements de l'autre périphérique.

En particulier :

  • pour les liens et les contrôles de formulaire, associez ONCLICK à ONKEYPRESS et vice versa. Vous pouvez y parvenir définissant l'événement manquant avec le même script utilisé pour celui existant ;
  • sur les champs de texte à l'intérieur des formulaires, remplacez ONCLICK par ONFOCUS
  • n'utilisez jamais ONDBLCLICK, car il n'existe aucun gestionnaire de clavier équivalent.
  • associez toujours ONKEYDOWN à ONMOUSEDOWN ;
  • associez toujours ONKEYUP à ONMOUSEUP ;
  • associez toujours ONMOUSEOVER à ONFOCUS ;
  • associez toujours ONMOUSEOUT à ONBLUR.
Eviter d'utiliser des liens JavaScript noJSLinks Point de contrôle 6,5 de priorité 2 WAI / WCAG 1.0 Accessibilit&eacute; P.2 W3C/WCAG TOUTES liens scripts

La page contient un lien qui ne peut être ouvert que par les navigateurs prenant en charge JavaScript.

Les liens qui activent des scripts ne peuvent être ouverts que par des navigateurs capables d'exécuter JavaScript. Tous les navigateurs ne peuvent exécuter JavaScript. C'est le cas, par exemple, des navigateurs en mode texte, tels que lynx, des navigateurs associés à des lecteurs d'écran ou des navigateurs pour assistant personnel ou téléphone portable.

Avec ces navigateurs, vous n'êtes pas en mesure de parcourir la page. Même s'il existe d'autres moyens d'atteindre la cible (par exemple, des liens ou des boutons), l'utilisateur suppose que ce lien fonctionne comme n'importe quel lien. Cependant, l'incapacité pour le navigateur d'ouvrir le lien peut faire que l'utilisateur se sente encore plus frustré et troublé.

Remplacez le lien qui exécute directement le script par une autre façon de l'exécuter, par exemple en définissant un bouton, en définissant séparément le script (sans oublier l'élément NOSCRIPT) et en associant un événement (tel que ONKEYPRESS et ONCLICK) sur le bouton au script.

FRAMESET doit contenir des éléments NOFRAMES corrects validNOFRAMES Point de contrôle 6,5 de priorité 2 WAI / WCAG 1.0 Accessibilit&eacute; P.2 W3C/WCAG TOUTES cadres

L'élément <NOFRAMES> est absent ou ne contient pas de lien permettant d'accéder à une autre version de la page.

La page FRAMESET ne contient pas de section NOFRAMES. La section NOFRAMES existe, mais elle est vide. La section NOFRAMES indique à l'utilisateur qu'il doit passer à un navigateur prenant en charge les cadres. La section NOFRAMES ne contient pas de lien permettant d'accéder à une autre page du site.

Si vous ne spécifiez pas d'élément <NOFRAMES>, le site peut apparaître sous forme de page blanche sur un navigateur ne prenant pas en charge les cadres, notamment les anciennes versions des navigateurs standard et ceux spécialisés, tels que les navigateurs vocaux et ceux destinés aux assistants personnels.

Si tel est le cas, l'élément <NOFRAMES> doit être utilisé comme une alternative pour accéder au site, parfois au détriment de la qualité d'interaction et des images.
Par exemple, un élément <NOFRAMES> dont le texte indique que la page ne peut être affiché par le navigateur utilisé ne permet pas aux utilisateurs d'accéder à la page.

Une section NOFRAMES correcte doit se trouver dans la section FRAMESET extérieure.
Une section NOFRAMES est correcte si elle :

  • contient au moins un mot ou un code HTML accessible ;
  • offre les liens nécessaires pour parcourir le site ;
  • n'indique pas aux utilisateurs qu'ils doivent passer à un navigateur prenant en charge les cadres.

Un élément NOFRAMES ne contenant aucun lien empêche le lecteur d'accéder aux mêmes options de navigation offertes à ceux utilisant un navigateur prenant en charge les cadres.

Ajoutez le code HTML suivant avant la dernière balise /FRAMESET> dans le document :

     <NOFRAMES>
     <P>Here is the <A href="main-noframes.html">
              non-frame based version of the document.</A></P>
     </NOFRAMES>
Le contenu dynamique doit être accessible dynCntAcc Point de contrôle 6,5 de priorité 2 WAI / WCAG 1.0 Accessibilit&eacute; P.2 W3C/WCAG TOUTES scripts manuelle

La page utilise des scripts pouvant modifier le contenu ou les options de navigation du document. Tous ces scripts doivent modifier la page de telle façon que les technologies d'aide puissent reconnaître ces changements et que la personne visitant le site puisse être correctement avertie.

Certains liens (par exemple " javascript:... ") contient des instructions JavaScript modifiant le contenu de la page. Le gestionnaire d'événements (par exemple, " onMouseOver ") contient des instructions JavaScript modifiant le contenu de la page. L'élément SCRIPT contient des instructions JavaScript modifiant le contenu de la page.

Il est conseillé de ne pas utiliser de scripts pour créer du contenu ou des options de navigation. Les personnes utilisant un navigateur ne prenant pas en charge les scripts ne pourront pas voir ni ce contenu ni ces options.

Selon le W3C (&w3c_html_tech;) :

Les développeurs de contenu doivent vérifier que les pages sont accessibles lorsque les scripts sont désactivés ou depuis les navigateurs ne prenant pas en charge les scripts.
  • Evitez de créer du contenu à la volée sur l'ordinateur client. Si le navigateur d'un utilisateur ne prend pas en charge les scripts, aucun contenu n'est généré ou affiché. Cependant, ceci est différent d'afficher ou de masquer un contenu existant via l'association de feuilles de style et de scripts. S'il n'y a aucun script, le contenu est toujours affiché. Ceci n'exclut pas non plus la création de pages à la volée côté serveur avant de les diffuser côté client.
  • Evitez de créer des liens utilisant JavaScript comme l'URI. Si un utilisateur n'utilise pas de scripts, ils ne seront pas en mesure d'ajouter de lien puisque le navigateur ne peut créer le contenu du lien.

Vérifiez que les scripts utilisés par cette page ne créent pas de contenu ou d'options de navigation. Un simple test consiste à désactiver l'exécution du script sur le navigateur et à utiliser la page.

Si certains scripts ajoutent du contenu ou des options de navigation, il est recommandé de trouver une autre façon de réaliser les effets souhaités.

Par exemple, un script côté serveur (ainsi qu'un formulaire) pourrait-il réaliser le même effet ? Est-il possible que la page affiche tout son contenu si le navigateur ne prend pas en charge les scripts (par exemple, en définissant plusieurs calques) ?

Si tout le contenu est défini dans des calques et que le script est utilisé pour ne faire apparaître un calque que lorsque certaines conditions sont réunies, les navigateurs ne prenant pas en charge les scripts rendent tous les calques dans l'ordre dans lequel ils sont définis dans le fichier HTML. Dans ce cas, il est recommandé de vérifier que cette manière de présenter le contenu est suffisamment efficace (par exemple, en fournissant le contexte adapté pour chaque calque).

Eviter de faire clignoter de contenu avdCsgCntBlk Point de contrôle 7,2 de priorité 2 WAI / WCAG 1.0 Accessibilit&eacute; P.2 W3C/WCAG TOUTES css

La page contient la balise BLINK non standard.

Cette balise active et désactive son contenu. L'utilisateur du navigateur ne pourra pas du tout interrompre ce comportement.

Ce clignotement est gênant et peut vous empêcher de vous concentrer lorsque vous lisez les informations ou que vous complétez le formulaire de la page.

Les conséquences sont bien plus importantes chez les utilisateurs souffrant de trouble cognitifs, car ils auront beaucoup de mal à se concentrer sur le contenu de la page. Tenez compte également des utilisateurs de loupes d'écran ne pouvant lire qu'une portion du texte recouverte par le texte clignotant. Dans ce cas, une grande partie de l'écran grossie clignotera, rendant très difficile pour ces utilisateurs la lecture du contenu de la page.

D'une certaine façon, toute personne stressée souffre de troubles cognitifs. Par exemple, lors de l'achat en ligne d'un billet d'avion depuis une borne se trouvant dans un aéroport bondé et très bruyant et que de nombreuses personnes font la queue pour la même borne, il est très difficile de rester concentré. Un élément clignotant sur la page peut empêcher la personne de terminer son achat.

Remplacez la balise BLINK par une autre propriété de mise en forme oł le texte ne clignote pas ou n'est pas contrôlé par la personne qui visite le site Web.

Le W3C (&w3c_html_tech;) suggère de ne pas utiliser les balises BLINK et MARQUEE.

Si l'effet de clignotement est requis, utilisez la propriété css " text-decoration: blink ". De cette façon, le résultat final sera le même, toutefois :

  • la personne visitant le site peut désactiver le traitement CSS par le navigateur, ce qui entraîne la fin du clignotement ;
  • une meilleure option consiste à associer plusieurs fichiers de styles CSS à la page. La plupart des propriétés peuvent rester identiques (dans tous les fichiers) à l'exception de la propriété " text-decoration: blink ". De cette façon, la personne visitant le site (via un navigateur à jour) peut basculer entre les fichiers de styles et choisir celui qui lui permet de tout faire ce dont elle a besoin, sauf le clignotement.
  • le fichier HTML contient du code correct et sa taille est plus petite (du fait que la propriété de clignotement n'est mentionnée qu'une seule fois dans le fichier de style externe).
Eviter d'utiliser des objets pouvant faire clignoter l'écran avdElmScrBlk Point de contr&ocirc;le 7,2 de priorit&eacute; 2 WAI / WCAG 1.0 Accessibilit&eacute; P.2 W3C/WCAG TOUTES manuelle scripts images

La page contient des objets (scripts, applets, objets HTML) qui peuvent clignoter à l'écran. Si tel est le cas, il est recommandé de les modifier ou de les supprimer.

Utilisation d'APPLET : l'écran clignote-t-il ? Si oui, modifiez ou supprimez l'applet. Utilisation d'OBJECT : l'écran clignote-t-il ? Si oui, modifiez ou supprimez l'objet. Utilisation d'EMBED : l'écran clignote-t-il ? Si oui, modifiez ou supprimez l'objet. Utilisation de SCRIPT : l'écran clignote-t-il ? Si oui, modifiez ou supprimez le script.

L'objet (script, applet, objets HTML) est à l'origine de clignotements à l'écran et l'utilisateur du navigateur n'est pas en mesure de désactiver ce comportement.

Ce clignotement est gênant et peut vous empêcher de vous concentrer lorsque vous lisez les informations ou que vous complétez le formulaire de la page.

Les conséquences sont bien plus importantes chez les utilisateurs souffrant de trouble cognitifs, car ils auront beaucoup de mal à se concentrer sur le contenu de la page. Tenez compte également des utilisateurs de loupes d'écran ne pouvant lire qu'une portion du texte recouverte par le texte clignotant. Dans ce cas, une grande partie de l'écran grossie clignotera, rendant très difficile pour ces utilisateurs la lecture du contenu de la page.

D'une certaine façon, toute personne stressée souffre de troubles cognitifs. Par exemple, lors de l'achat en ligne d'un billet d'avion depuis une borne se trouvant dans un aéroport bondé et très bruyant et que de nombreuses personnes font la queue pour la même borne, il est très difficile de rester concentré. Un élément clignotant sur la page peut empêcher la personne de terminer son achat.

Vérifiez si l'objet est à l'origine de clignotements (c'est-à-dire une partie de l'écran qui s'allume et s'éteint de manière constante) qui ne s'arrêtent pas et que la personne visitant le site ne peut pas interrompre.

Si tel est le cas, modifiez le comportement de l'objet pour interrompre le clignotement ou pour que la personne visitant le site puisse l'interrompre. Vous pouvez également définir l'objet de façon à ce qu'il ne clignote que quelques fois.

Les images GIF ne doivent pas faire clignoter l'écran gifNoScrBlk Point de contr&ocirc;le 7,2 de priorit&eacute; 2 WAI / WCAG 1.0 Accessibilit&eacute; P.2 W3C/WCAG TOUTES manuelle scripts images

La page contient des images pouvant faire clignoter l'écran. Si tel est le cas, il est recommandé de les modifier ou de les supprimer.

L'image est à l'origine de clignotements à l'écran et l'utilisateur du navigateur n'est pas en mesure de désactiver ce comportement.

Ce clignotement est gênant et peut vous empêcher de vous concentrer lorsque vous lisez les informations ou que vous complétez le formulaire de la page.

Les conséquences sont bien plus importantes chez les utilisateurs souffrant de trouble cognitifs, car ils auront beaucoup de mal à se concentrer sur le contenu de la page. Tenez compte également des utilisateurs de loupes d'écran ne pouvant lire qu'une portion du texte recouverte par le contenu clignotant. Dans ce cas, une grande partie de l'écran grossie clignotera, rendant très difficile pour ces utilisateurs la lecture du contenu de la page.

D'une certaine façon, toute personne stressée souffre de troubles cognitifs. Par exemple, lors de l'achat en ligne d'un billet d'avion depuis une borne se trouvant dans un aéroport bondé et très bruyant et que de nombreuses personnes font la queue pour la même borne, il est très difficile de rester concentré. Un élément clignotant sur la page peut empêcher la personne de terminer son achat.

Vérifiez si l'image est à l'origine de clignotements (c'est-à-dire une partie de l'écran qui s'allume et s'éteint de manière constante) qui ne s'arrêtent pas et que la personne visitant le site ne peut pas interrompre.

Si tel est le cas, modifiez l'image pour interrompre le clignotement ou pour définir l'image de façon à ce qu'elle ne clignote que quelques fois.

Les images GIF ne doivent pas entraîner de mouvements gifNoMvmPg Point de contr&ocirc;le 7,3 de priorit&eacute; 2 WAI / WCAG 1.0 Accessibilit&eacute; P.2 W3C/WCAG TOUTES manuelle scripts images

La page contient des images dont le contenu peut être en mouvement. Si tel est le cas, il est recommandé de les modifier ou de les supprimer.

Le contenu de certaines images est en mouvement et la personne utilisant le navigateur ne pourra pas du tout interrompre ce comportement.

Ce comportement est gênant et peut vous empêcher de vous concentrer lorsque vous lisez les informations ou que vous complétez le formulaire de la page.

Les conséquences sont bien plus importantes chez les utilisateurs souffrant de trouble cognitifs, car ils auront beaucoup de mal à se concentrer sur le contenu de la page. Tenez compte également des utilisateurs de loupes d'écran ne pouvant lire qu'une portion du texte recouverte par la partie en mouvement. Dans ce cas, une grande partie de l'écran grossie affiche une partie du contenu qui se déplace ou dont l'aspect change. L'utilisateur doit continuellement repositionner la loupe d'écran avec précision pour suivre le mouvement du contenu, ce qui l'empêche de rester concentré.

D'une certaine façon, toute personne stressée souffre de troubles cognitifs. Par exemple, lors de l'achat en ligne d'un billet d'avion depuis une borne se trouvant dans un aéroport bondé et très bruyant et que de nombreuses personnes font la queue pour la même borne, il est très difficile de rester concentré. Un élément en mouvement sur la page peut empêcher la personne de terminer son achat.

Vérifiez si le contenu en mouvement de l'image ne s'arrête pas ou que la personne visitant le site Web ne peut arrêter.

Si tel est le cas, modifiez l'image pour interrompre le mouvement ou pour que le contenu ne se déplace que quelques fois.

Les objets ne doivent pas entraîner de mouvements objNoMvmPg Point de contr&ocirc;le 7,3 de priorit&eacute; 2 WAI / WCAG 1.0 Accessibilit&eacute; P.2 W3C/WCAG TOUTES manuelle scripts images

La page contient des scripts, des applets ou des objets dont le contenu peut être en mouvement. Si tel est le cas, il est recommandé de les modifier ou de les supprimer.

Utilisation d'APPLET : la page contient-elle du contenu en mouvement ? Si oui, modifiez ou supprimez l'applet. Utilisation d'OBJECT : la page contient-elle du contenu en mouvement ? Si oui, modifiez ou supprimez l'objet. Utilisation d'EMBED : la page contient-elle du contenu en mouvement ? Si oui, modifiez ou supprimez l'objet. Utilisation de SCRIPT : la page contient-elle du contenu en mouvement ? Si oui, modifiez ou supprimez le script.

Le contenu de l'objet est en mouvement et la personne utilisant le navigateur ne pourra pas du tout interrompre ce comportement.

Ce comportement est gênant et peut vous empêcher de vous concentrer lorsque vous lisez les informations ou que vous complétez le formulaire de la page.

Les conséquences sont bien plus importantes chez les utilisateurs souffrant de trouble cognitifs, car ils auront beaucoup de mal à se concentrer sur le contenu de la page. Tenez compte également des utilisateurs de loupes d'écran ne pouvant lire qu'une portion du texte recouverte par la partie en mouvement. Dans ce cas, une grande partie de l'écran grossie affiche une partie du contenu qui se déplace ou dont l'aspect change. L'utilisateur doit continuellement repositionner la loupe d'écran avec précision pour suivre le mouvement du contenu, ce qui l'empêche de rester concentré.

D'une certaine façon, toute personne stressée souffre de troubles cognitifs. Par exemple, lors de l'achat en ligne d'un billet d'avion depuis une borne se trouvant dans un aéroport bondé et très bruyant et que de nombreuses personnes font la queue pour la même borne, il est très difficile de rester concentré. Un élément en mouvement sur la page peut empêcher la personne de terminer son achat.

Enfin, les lecteurs d'écran ne peuvent pas lire du texte en mouvement.

Vérifiez si le contenu en mouvement de l'objet ne s'arrête pas ou que la personne visitant le site Web ne peut arrêter.

Si tel est le cas, modifiez l'objet pour interrompre le mouvement ou pour que le contenu ne se déplace que quelques fois. Une meilleure solution consiste à modifier l'objet de façon à ce que la personne visitant le site puisse décider d'arrêter le contenu en mouvement.

Eviter les éléments MARQUEE avoidMarquee Point de contr&ocirc;le 7,3 de priorit&eacute; 2 WAI / WCAG 1.0 Accessibilit&eacute; P.2 W3C/WCAG TOUTES

La page contient l'élément MARQUEE faisant défiler une zone de texte.

Les animations ajoutées à une page ont un effet négatif sur la manière dont l'utilisateur perçoit et lit le contenu de celle-ci. Les utilisateurs auront du mal à rester concentrés sur le contenu principal de la page.

En outre, si le navigateur utilisé pour visiter cette page ne sait pas interpréter l'élément MARQUEE, celui-ci affiche une page qui ne marche pas comme prévu.

De nombreux navigateurs ne prennent pas en charge l'élément MARQUEE, notamment Netscape Navigator et Opera. En outre, MARQUEE n'est pas une balise HTML 3.2 ou HTML 4.0 standard.

L'utilisation de cet effet d'animation n'est pas conseillée. Remplacez-le par une présentation de tableau, ou mieux, utilisez de manière astucieuse les propriétés CSS.

Le W3C (HTML Techniques for Web Content Accessibility Guidelines 1.0) suggère de ne pas utiliser les balises BLINK et MARQUEE.

Eviter d'actualiser les pages automatiquement avdAutRfrPg Point de contr&ocirc;le 7,4 de priorit&eacute; 2 WAI / WCAG 1.0 m&eacute;ta Accessibilit&eacute; P.2 W3C/WCAG TOUTES

La page est automatiquement actualisée au bout d'un certain temps. Il est recommandé de supprimer ce comportement.

Les pages actualisées automatiquement peuvent gêner de manière importante les personnes handicapées ou utilisant une technologie empêchant tout modèle d'interaction normal.

Par exemple, les lecteurs d'écran risquent de ne pas fonctionner lorsque la page s'actualise ou les personnes handicapées peuvent ne pas être en mesure de parcourir rapidement ou avec précision le contenu de la page et les éléments de navigation. Les personnes sans handicap peuvent être également gênées pour diverses raisons, notamment si elles lisent lentement la page, cela peut-être le cas si elles utilisent une connexion Internet trop lente ou un écran trop petit, les forçant à lire plus lentement.

Si le navigateur vous permet de désactiver l'actualisation automatique de la page, n'utilisez pas cette fonction.

Si le navigateur vous permet de désactiver l'actualisation automatique de la page, n'utilisez pas cette fonction ni la redirection automatique.

Vous pouvez obtenir le même effet en spécifiant la date d'expiration du cache en configurant de manière appropriée le serveur Web. Cela n'aura aucun effet sur l'accessibilité des pages, car elles ne changent que lorsque l'utilisateur recharge volontairement la page depuis le navigateur.

Eviter de rediriger les pages à l'aide de balises avdRedPgMarkp Point de contr&ocirc;le 7,5 de priorit&eacute; 2 WAI / WCAG 1.0 m&eacute;ta Accessibilit&eacute; P.2 W3C/WCAG TOUTES

Lorsque cette page est chargée par le navigateur, une nouvelle page est automatiquement chargée et affichée au bout d'un certain temps. Il est recommandé de supprimer ce comportement.

Les pages actualisées automatiquement peuvent gêner de manière importante les personnes handicapées ou utilisant une technologie empêchant tout modèle d'interaction normal.

Les personnes handicapées peuvent ne pas être en mesure de parcourir rapidement ou avec précision le contenu de la page et les éléments de navigation. Les personnes sans handicap peuvent être également gênées pour diverses raisons, notamment si elles lisent lentement la page, cela peut-être le cas si elles utilisent une connexion Internet trop lente ou un écran trop petit, les forçant à lire plus lentement.

Si le navigateur vous permet de désactiver l'actualisation automatique de la page, n'utilisez pas cette fonction.

Si le navigateur vous permet de désactiver l'actualisation automatique de la page, n'utilisez pas cette fonction ni la redirection automatique.

Si la redirection automatique est nécessaire, mettez-la en place à l'aide capacités offertes par le serveur et en laissant l'utilisateur spécifier le moment oł la page suivante doit être chargée. Cela n'aura aucun effet sur l'accessibilité des pages, car elles ne changent que lorsque l'utilisateur (re)charge la page volontairement.

Si ce n'est pas possible, et que la balise META de redirection est toujours requise, il est recommandé d'ajouter des liens dans les deux pages reliés entre eux et fonctionnant dans les deux sens. De cette façon, si la redirection est trop rapide, la personne visitant le site a au moins la possibilité de revenir à la page précédente. Si la redirection est trop lente, elle peut accéder à la page suivante sans limite.

Sachez que cette solution, bien que plus facile à utiliser que la balise de redirection META seule, ne répond pas aux critères de l'instruction ou du point de contrôle en cours.

Le menu jump doit être indépendant du périphérique JmpMenu Point de contr&ocirc;le 9,2 de priorit&eacute; 2 WAI / WCAG 1.0 Accessibilit&eacute; P.2 W3C/WCAG formulaires TOUTES

La page contient un menu jump (c'est-à-dire, un menu contenant une liste d'options permettant d'accéder chacune à une page différente) en fonction d'un élément SELECT avec un gestionnaire d'événements ONCHANGE qui charge une autre page. Ce comportement empêche les personnes visitant le site d'utiliser le clavier pour faire défiler une liste afin de sélectionner une option.

La fonction MM_jumpMenu() sert à charger les pages dans la fenêtre active ou parent. Le gestionnaire d'événements ONCHANGE associé à l'élément SELECT contient une instruction JavaScript pour charger les pages dans la fenêtre active ou parent.

Le code JavaScript associé à l'élément SELECT ne permet pas à l'utilisateur de faire défiler les options disponibles via un clavier. Il est dépendant du périphérique.

Le code JavaScript est indépendant du périphérique si :
les utilisateurs peuvent interagir avec un site Web en utilisant les périphériques d'entrée et de sortie de leurs choix. Les périphériques d'entrée comprennent notamment les périphériques de pointage, d'entrée braille, les claviers, les micros, etc. Les périphériques de sortie comprennent notamment les moniteurs, les synthétiseurs vocaux et les périphériques de lecture braille.

Généralement, les pages autorisant les interactions avec le clavier sont également accessibles par commande vocale ou via une interface de ligne de commande.

N'oubliez pas qu'un menu jump ne fonctionne que si JavaScript est activé et disponible sur le navigateur de l'utilisateur. Il existe des navigateurs ne prenant pas en charge JavaScript (par exemple, les téléphones portables et les assistants personnels). En outre, certaines organisations désactivent JavaScript de leurs navigateurs standard pour des raisons de sécurité.
Ajoutez une balise NOSCRIPT avec un autre contenu et type d'interaction équivalents (c'est-à-dire des liens et des formulaires).

Ecrivez également un script côté serveur pour traiter les URL situées dans le menu et pour qu'elles ouvrent la page adéquate.

Il existe deux étapes pour rendre le menu jump indépendant du périphérique :

  1. supprimez l'attribut ONCHANGE de l'élément SELECT ;
  2. ajoutez un bouton (INPUT de type BUTTON) après le menu ;
  3. affectez un attribut ONCLICK au bouton dont le contenu de l'attribut ONCHANGE a été au préalable supprimé.
  4. Enfin, placez le même contenu à l'intérieur de l'attribut ONKEYPRESS.

Lors de l'ajout d'un objet menu JUMP Dreamweaver au document, il est possible d'insérer automatiquement un bouton après le menu. Il suffit de sélectionner la case Insert Go Button After Menu. N'oubliez pas de supprimer l'attribut ONCHANGE de l'élément SELECT et d'ajouter ONKEYPRESS au bouton.

Par exemple, le code suivant est incorrect :

<form name="select_country">
Select a country:
  <select name="country" onChange="MM_jumpMenu('parent',this,0)">
   <option value="http://www.this_site.com/be" selected>Belgium</option>
   <option value="http://www.this_site.com/us">United States</option>
  </select>
</form>

Une version accessible est :

<form name="select_country" action="http://www.this_site.com/jump.cgi">
Select a country: 
  <select name="country">
   <option value="http://www.this_site.com/be" selected>Belgium</option>
   <option value="http://www.this_site.com/us">United States</option>
  </select>
 <input type="submit" value="Go">
</form>
Les objets doivent avoir une interface indépendante du périphérique elmOwnIntfDecIndp Point de contr&ocirc;le 9,2 de priorit&eacute; 2 WAI / WCAG 1.0 Accessibilit&eacute; P.2 W3C/WCAG TOUTES manuelle scripts

La page contient des gestionnaires d'événements ou des objets (utilisant des balises OBJECT, EMBED ou APPLET) devant offrir une interface utilisateur indépendante du périphérique.

Vérifiez que les gestionnaires d'événements ou les objets proposent une interface utilisateur qui peut être contrôlée par n'importe quel périphérique d'entrée.

Utilisation d'une APPLET : vérifiez qu'elle est indépendante du périphérique. Utilisation d'un plug-in : vérifiez qu'il est indépendant du périphérique. Utilisation d'un plug-in : vérifiez qu'il est indépendant du périphérique. Utilisation du gestionnaire d'événements Javascript : vérifiez qu'il est indépendant du périphérique.

Les objets programmés peuvent avoir leur propre interface utilisateur non directement implémentée en HTML. Si cette interface ne peut être contrôlée (et perçue) par tous les périphériques d'entrée et de sortie que peuvent utiliser les personnes handicapées, la page n'est pas accessible.

Comme défini par le groupe W3C/WAI (voir &wcag;), " indépendance du périphérique " signifie que la personne visitant un site doit pouvoir interagir avec celui-ci, à l'aide des périphériques d'entrée et de sortie de leurs choix et en fonction de leurs besoins. Les périphériques d'entrée comprennent notamment les périphériques de pointage, d'entrée braille, les claviers, les licornes, les micros, etc. Les périphériques de sortie comprennent notamment les moniteurs, les synthétiseurs vocaux et les périphériques de lecture braille.

La " prise en charge indépendante du périphérique " ne signifie pas que le navigateur doit prendre en charge tous les périphériques d'entrée et de sortie. Il doit proposer des mécanismes d'entrée et de sortie redondants pour les périphériques non pris en charge. Par exemple, si un navigateur prend en charge les signaux d'entrée du clavier et de la souris, les utilisateurs doivent pouvoir interagir avec toutes les fonctions en se servant du clavier ou de la souris.

L'accès indépendant du périphérique signifie que la personne visitant le site peut interagir avec le navigateur ou le document via un périphérique d'entrée (ou de sortie) de son choix. Par exemple, si un contrôle de formulaire ne peut être activé qu'avec une souris ou un périphérique de pointage, toute personne utilisant la page sans la voir, à l'aide de commandes vocales ou d'un clavier ne pourra pas utiliser le formulaire. Celui-ci est un exemple de dépendance au périphérique, car il se peut qu'il ne puisse être contrôlé qu'avec une souris.

Généralement, les pages autorisant les interactions avec le clavier sont également accessibles par commande vocale ou via une interface de ligne de commande.

Les objets potentiellement critiques sont les applets Java, les scripts VB, les objets utilisés via des plug-in tels que Flash, Shockwave, RealAudio et RealVideo.

Examinez ces objets pour déterminer si l'interface utilisateur qu'ils proposent (boutons, images, texte, etc.) peuvent être contrôlés par des périphériques autres que la souris.

Un test rapide consiste à utiliser toutes les fonctions de la page uniquement avec le clavier (ne touchez à aucun moment la souris). Est-il possible d'accéder à tous les contrôles (liens, boutons, etc.) et de les faire fonctionner ?

Si le test échoue, la page n'est pas accessible. S'il réussit, réalisez un test plus approfondi avec une technologie d'aide.

Spécifier des gestionnaires d'événements logiques spcLgcRtDDEvHndScr Point de contr&ocirc;le 9,3 de priorit&eacute; 2 WAI / WCAG 1.0 Accessibilit&eacute; P.2 W3C/WCAG TOUTES scripts

La page contient des éléments BUTTON, INPUT, SELECT ou TEXTAREA qui spécifient les gestionnaires d'événements dépendants du périphérique (cela signifie qu'ils gèrent les événements pouvant être générés par un périphérique d'entrée spécifique).

Remplacez les gestionnaires d'événements dépendants du périphérique (par exemple, ONCLICK) par ONRESET (dans l'élément FORM). Remplacez les gestionnaires d'événements dépendants du périphérique (par exemple, ONKEYPRESS) par ONSUBMIT (dans l'élément FORM). Remplacez les gestionnaires d'événements dépendants du périphérique (par exemple, ONCLICK) par ONFOCUS (dans le champ de texte). Remplacez les gestionnaires d'événements dépendants du périphérique (par exemple, onClick) par ONCHANGE (dans le bouton radio ou la case à cocher). Remplacez l'attribut ONCLICK par ONCHANGE (dans l'élément SELECT).

L'interface utilisateur proposée par une page Web doivent être visibles et contrôlables par tous, quelles que soient leurs aptitudes physiques, cognitives ou techniques. En particulier, elle doit être indépendante du périphérique. Cela est crucial pour les pages contenant des formulaires.

Comme défini par le groupe W3C/WAI (voir &wcag;), " indépendance du périphérique " signifie que la personne visitant un site doit pouvoir interagir avec celui-ci, à l'aide des périphériques d'entrée et de sortie de leurs choix et en fonction de leurs besoins. Les périphériques d'entrée comprennent notamment les périphériques de pointage, d'entrée braille, les claviers, les licornes, les micros, etc. Les périphériques de sortie comprennent notamment les moniteurs, les synthétiseurs vocaux et les périphériques de lecture braille.

La " prise en charge indépendante du périphérique " ne signifie pas que le navigateur doit prendre en charge tous les périphériques d'entrée et de sortie. Il doit proposer des mécanismes d'entrée et de sortie redondants pour les périphériques non pris en charge. Par exemple, si un navigateur prend en charge les signaux d'entrée du clavier et de la souris, les utilisateurs doivent pouvoir interagir avec toutes les fonctions en se servant du clavier ou de la souris.

L'accès indépendant du périphérique signifie que la personne visitant le site peut interagir avec le navigateur ou le document via un périphérique d'entrée (ou de sortie) de son choix. Par exemple, si un contrôle de formulaire ne peut être activé qu'avec une souris ou un périphérique de pointage, toute personne utilisant la page sans la voir, à l'aide de commandes vocales ou d'un clavier ne pourra pas utiliser le formulaire. Celui-ci est un exemple de dépendance au périphérique, car il se peut qu'il ne puisse être contrôlé qu'avec une souris.

Généralement, les pages autorisant les interactions avec le clavier sont également accessibles par commande vocale ou via une interface de ligne de commande.

En général, il est recommandé de remplacer les gestionnaires d'événements dans les formulaires de la manière suivante :

  • dans INPUT (type=submit or type=reset or type=image) ou BUTTON, supprimez les gestionnaires d'événements, tels que ONCLICK, ONDBLCLICK, ONKEYPRESS, ONKEYDOWN, ONKEYUP, ONMOUSEDOWN et ONMOUSEUP, puis ajoutez ONRESET (if type=reset) ou ONSUBMIT à l'ensemble du formulaire ;
  • dans les cases à cocher et les boutons radio, supprimez les gestionnaires des attributs ONCLICK, ONDBLCLICK, ONKEYPRESS, ONKEYDOWN, ONKEYUP, ONMOUSEDOWN et ONMOUSEUP, puis ajoutez ONCHANGE (au bouton radio ou à la case à cocher) ;
  • dans les champs de texte, remplacez les gestionnaires des attributs ONCLICK, ONDBLCLICK, ONMOUSEDOWN et ONMOUSEUP par ONFOCUS ;
  • dans les listes SELECT, remplacez les gestionnaires des attributs ONCLICK, ONDBLCLICK, ONMOUSEDOWN et ONMOUSEUP par ONCHANGE ;
Informer les utilisateurs de l'affichage d'une nouvelle fenêtre winAppWttInfUsr Point de contr&ocirc;le 10,1 de priorit&eacute; 2 WAI / WCAG 1.0 Accessibilit&eacute; P.2 W3C/WCAG TOUTES scripts cadres manuelle

La page contient des liens pouvant s'ouvrir dans une nouvelle fenêtre (soit via un attribut TARGET, soit via une instruction javascript:window.open()). Si tel est le cas, vérifiez que la personne visitant le site a indiqué qu'il s'agit de ce comportement. Si l'utilisateur n'est pas prévenu, la page ne répond pas aux critères de ce point de contrôle.

Lorsque le navigateur ouvre une nouvelle fenêtre, après que l'utilisateur ait cliqué sur un lien ou un bouton, l'environnement dans lequel il travaille change. Celui-ci change parce que :

  • certaines fonctionnalités du navigateur dans la nouvelle fenêtre peuvent être différentes. Par exemple, les boutons du navigateur peuvent ne plus être affichés, la géométrie et la position de la nouvelle fenêtre peuvent changer, la nouvelle fenêtre apparaît au-dessus ou parfois en dessous de la fenêtre parent ;
  • même s'il n'est pas désactivé, le bouton Précédente du navigateur ne fonctionne pas, puisque dans la nouvelle fenêtre ne contient pas d'historique des URL (et des URL précédentes).

Ces deux facteurs, généralement associés, amplifient les difficultés rencontrées par les personnes visitant le site, plus particulièrement les personnes handicapées ou utilisant des technologies d'aide. Par exemple, si la nouvelle fenêtre a les mêmes dimensions et la même position que la fenêtre parent et qu'elle cache complètement la fenêtre parent, la personne visitant le site peut croire qu'il s'agit de la même fenêtre. Elle peut également croire que le bouton Précédente ne fonctionne pas et qu'il s'agit d'un bogue propre au navigateur (et elle risque de redémarrer le navigateur) ou d'un bogue propre au site (et elle risque de changer de site).

Ce phénomène est accentué chez les malvoyants : les lecteurs d'écran ne sont pas en mesure de les informer de la présence d'une nouvelle fenêtre. Les utilisateurs de loupes d'écran peuvent avoir beaucoup de mal à se rendre compte de la présence d'une nouvelle fenêtre et de sa position.

C'est pourquoi il est crucial que la personne visitant le site soit informée de l'ouverture d'une nouvelle fenêtre. Il est clair qu'elle doit en être informée avant son ouverture.

Dans tous les cas, la nouvelle fenêtre doit contenir un bouton permettant à la personne visitant le site de revenir à la fenêtre parent (ou qui la ferme). Ces boutons doivent fonctionner même si la nouvelle fenêtre a désactivé les boutons standard du navigateur.

Evitez d'ouvrir de nouvelles fenêtres de navigateur.

Si ce n'est pas possible, l'utilisateur doit être averti qu'une nouvelle fenêtre s'ouvrira s'il clique sur un certain lien ou bouton. Par exemple, écrivez " (nouvelle fenêtre) " juste avant ou dans le texte du lien, ou écrivez-le dans l'attribut TITLE du lien. Une autre option consiste à adopter systématiquement dans le site une petite icône avertissant qu'une nouvelle fenêtre est en train de s'ouvrir et placez-la dans l'étiquette du lien (par exemple, associez l'attribut ALT à " nouvelle fenêtre "). Pour plus d'informations, rendez-vous sur Qbullets (évitez les GIF animés).

Dans tous les cas, ajoutez un bouton Fermer ou Précédente à la fenêtre qui respectivement fermera la nouvelle fenêtre ou affichera la page précédente.

Informer les utilisateurs de l'affichage d'une fenêtre pop-up popAppWttInfUsr Point de contr&ocirc;le 10,1 de priorit&eacute; 2 WAI / WCAG 1.0 Accessibilit&eacute; P.2 W3C/WCAG TOUTES Scripts

La page contient un script associé à la balise BODY pouvant ouvrir une nouvelle fenêtre lorsque le navigateur charge la page (par exemple, une fenêtre pop-up). Si tel est le cas, la page ne répond pas aux critères de ce point de contrôle.

Les scripts de la page contiennent ou appellent des fonctions contenant l'instruction window.open(). L'attribut ONLOAD de la balise BODY contient une instruction window.open().

Lorsque le navigateur ouvre une fenêtre pop-up, l'environnement dans lequel l'utilisateur travaille change. Celui-ci change parce que :

  • certaines fonctionnalités du navigateur dans la nouvelle fenêtre peuvent être différentes. Par exemple, les boutons du navigateur peuvent ne plus être affichés, la géométrie et la position de la nouvelle fenêtre peuvent changer, la nouvelle fenêtre apparaît au-dessus ou parfois en dessous de la fenêtre parent ;
  • même s'il n'est pas désactivé, le bouton Précédente du navigateur ne fonctionne pas, puisque dans la nouvelle fenêtre ne contient pas d'historique des URL (et des URL précédentes).
  • pour les fenêtres pop-up, le changement est plus radical, puisqu'elles apparaissent spontanément (sauf lorsque l'utilisateur clique sur un lien ou tape une URL).

Ces facteurs, généralement associés, amplifient les difficultés rencontrées par les personnes visitant le site, plus particulièrement les personnes handicapées ou utilisant des technologies d'aide. Par exemple, si la nouvelle fenêtre a les mêmes dimensions et la même position que la fenêtre parent et qu'elle cache complètement la fenêtre parent, la personne visitant le site peut croire qu'il s'agit de la même fenêtre. Elle peut également croire que le bouton Précédente ne fonctionne pas et qu'il s'agit d'un bogue propre au navigateur (et elle risque de redémarrer le navigateur) ou d'un bogue propre au site (et elle risque de changer de site).

Ce phénomène est accentué chez les malvoyants : les lecteurs d'écran ne sont pas en mesure de les informer de la présence d'une nouvelle fenêtre. Les utilisateurs de loupes d'écran peuvent avoir beaucoup de mal à se rendre compte de la présence d'une nouvelle fenêtre et de sa position.

C'est pourquoi il est crucial que la personne visitant le site soit informée de l'ouverture d'une nouvelle fenêtre. Il est clair qu'elle doit en être informée avant d'ouvrir la fenêtre, ce qui n'est pas une solution acceptable pour les fenêtres pop-up.

Dans tous les cas, la nouvelle fenêtre doit contenir un bouton permettant à la personne visitant le site de revenir à la fenêtre parent (ou qui la ferme). Ces boutons doivent fonctionner même si la nouvelle fenêtre a désactivé les boutons standard du navigateur.

Evitez d'ouvrir de nouvelles fenêtres pop-up.

Si l'ouverture de nouvelles fenêtres pop-up est nécessaire, ajoutez un bouton Fermer à la nouvelle fenêtre pour pouvoir la fermer.

Positionner correctement des étiquettes implicites dans des formulaires implAssLblFrmCtrlPrPos Point de contr&ocirc;le 10,2 de priorit&eacute; 2 WAI / WCAG 1.0 Accessibilit&eacute; P.2 W3C/WCAG TOUTES manuelle formulaires

La page contient des formulaires avec des contrôles. Si les étiquettes de ces contrôles ne sont pas correctement placées (à gauche ou au-dessus du contrôle), la page ne répond pas aux critères de ce point de contrôle.

Tenez compte du fait que seulement quelques personnes visitant le site peuvent afficher le formulaire en deux dimensions et qu'elles risquent de ne pas profiter des indications visuelles qui ont été ajoutées à la présentation du formulaire (notamment l'alignement vertical des contrôles, les cases servant de cadre à certaines contrôles ou différentes couleurs d'arrière-plan).

Cela peut se produire, car la personne visitant le site utilise un support différent pour afficher le formulaire (par exemple, via le rendu audio du formulaire), parce qu'elle utilise une loupe d'écran n'affichant qu'une toute petite partie du formulaire, ou parce qu'elle utilise un tout petit écran noir et blanc d'un assistant personnel.

Dans tous les cas, les personnes visitant le site risquent de passer à côté de la fonction d'un champ ou d'un contrôle et de ne pas savoir ce qu'ils doivent taper ou faire.

Vérifiez que les étiquettes des champs et des contrôles existent et qu'elles sont placées à gauche ou au-dessus du contrôle auquel elles se rapportent. Tenez compte des éventuels problèmes pouvant se présenter lors de l'utilisation de tableaux pour disposer le contenu du formulaire.

Utiliser les propriétés W3C appropriées les plus récentes useLstW3CTch Point de contr&ocirc;le 11,1 de priorit&eacute; 2 WAI / WCAG 1.0 Accessibilit&eacute; P.2 W3C/WCAG TOUTES manuelle

Il s'agit d'un avertissement général. Il est recommandé de toujours utiliser les technologies les plus récentes diffusées par W3C adaptées à la tâche en cours.

Il est recommandé de toujours utiliser le langage de programmation le plus récent ; les navigateurs (et les autres technologies) s'adapteront sans problème. De cette façon, les pages développées n'ont pas à suivre l'évolution des navigateurs.

Cela suppose que vous utilisiez par exemple XHTML, CSS, SMIL (langage d'intégration de synchronisation multimédia), MathML (pour le balisage des formules mathématiques), XML et XSL (pour séparer complètement le contenu de la présentation) et P3P (pour la description des informations confidentielles).

Consultez les recommandations W3C les plus récentes sur le World Wide Web Consortium.

Eviter les fonctionnalités désapprouvées des technologies W3C avdDepFtW3CTch Point de contr&ocirc;le 11,2 de priorit&eacute; 2 WAI / WCAG 1.0 Accessibilit&eacute; P.2 W3C/WCAG TOUTES

La page contient des balises désapprouvées en HTML 4.0.1. Evitez de les utiliser.

Les balises et les attributs désapprouvés ne sont pas reconnus par le langage HTML standard. W3C les a retirés de cette norme parce qu'ils sont identiques à d'autres balises ou d'autres technologies les plus récentes.

Par exemple, la balise FONT est désapprouvée, car il est possible de spécifier toutes les propriétés de la police à l'aide de règles CSS (redondance). En outre, vous obtenez un meilleur niveau de modularité et une meilleure séparation entre la structure et la présentation (tendances).

Pour connaître les balises et les attributs désapprouvés, reportez-vous au document HTML officiel &w3c_html401;.

Certaines de ces balises y sont mentionnées :

  • APPLET
  • BASEFONT
  • CENTER
  • DIR
  • FONT
  • ISINDEX
  • MENU
  • S
  • STRIKE
  • U
  • LISTING
  • PLAINTEXT
  • XMP
Décrire les cadres et leurs relations dscFrmRlshTtNoClr Point de contr&ocirc;le 12,2 de priorit&eacute; 2 WAI / WCAG 1.0 Accessibilit&eacute; P.2 W3C/WCAG TOUTES manuelle cadres

La page contient des éléments FRAMESET et FRAME avec un attribut TITLE. Vérifiez que l'attribut décrit le rôle du cadre et comment celui-ci s'associe aux autres cadres de la page.

Si nécessaire, ajoutez également un attribut LONGDESC.

Les cadres sont principalement utilisés pour regrouper des informations et des éléments de navigation, ainsi que pour les afficher avec une certaine mise en page. Cependant, certaines technologies d'aide (navigateurs vocaux ou en mode texte, lecteurs d'écran) ne peuvent pas profiter de la mise en page. Par conséquent, ces outils rendent chaque cadre hors contexte, sans la moindre référence aux autres cadres. La personne utilisant ces outils ne peut pas voir les autres cadres et leur contenu. C'est pourquoi il est important que chaque cadre indique une description permettant à l'utilisateur d'élaborer le contexte.

Les noms tels que "haut", "en bas à gauche" généralement attribués aux cadres ne sont pas suffisamment descriptifs et n'aident pas l'utilisateur à reconstruire le contexte.

Prenons un exemple (issu de HTML Techniques for Web Content Accessibility Guidelines 1.0 et légèrement modifié) :

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN">
<HTML>
  <HEAD>
    <TITLE>Today's news</TITLE>
  </HEAD>

  <FRAMESET cols="10%,*,10%">

  <FRAMESET rows="20%,*">
    <FRAME src="promo.html" name="promo" title="promotions">
    <FRAME src="sitenavbar.html" name="navbar" 
       title="Sitewide navigation bar" longdesc="frameset-desc.html#navbar">
  </FRAMESET>

  <FRAME src="story.html" name="story" title="Selected story - main content" 
     longdesc="frameset-desc.html#story">

  <FRAMESET rows="*,20%">
    <FRAME src="headlines.html" name="index" title="Index of other 
      national headlines" longdesc="frameset-desc.html#headlines">
    <FRAME src="ad.html" name="adspace" title="Advertising">
  </FRAMESET>

  <NOFRAMES>
    <p><a href="noframes.html">No frames version</a></p>
    <p><a href="frameset-desc.html">Descriptions of frames.</a></p>

  </NOFRAMES>

  </FRAMESET>
</HTML>

Voici un exemple de fichier frameset-desc.html :

#Navbar - this frame provides links to the <a href="sitenavbar.html">major 
          sections of the site</a>:  World News, National News,
          Local News, Technological News,
          and Entertainment News.

#Story  - this frame displays the <a href="story.html">currently selected story</a>.

#Index  - this frame provides links to the day's 
          <a href="headlines.html">headline stories</a> within this section.  

L'élément NOFRAMES est utile lorsque des navigateurs spéciaux ne prenant pas en charge les cadres sont utilisés (par exemple, ceux utilisés sur les assistants personnels et les téléphones portables).

Vérifiez que l'attribut TITLE de l'élément FRAME décrit clairement le rôle du cadre et sa relation avec les cadres associés. Si l'attribut TITLE ne suffit pas (par exemple parce que des images, des liens ou autres balises sont requises), utilisez également l'attribut LONGDESC pour attribuer un lien à un fichier HTML contenant une description plus longue.
Voir la section Explication pour consulter un exemple détaillé.

L'attribut NAME est généralement utilisé pour faire de la programmation et il ne doit contenir aucun espace. L'attribut TITLE, autorisé à contenir des espaces, peut servir à définir une meilleure description. En général, il est plus sûr d'utiliser les deux.

FRAME doit contenir des éléments LONGDESC corrects FRAME_vLDESC Point de contr&ocirc;le 12,2 de priorit&eacute; 2 WAI / WCAG 1.0 Accessibilit&eacute; P.2 W3C/WCAG TOUTES cadres

La page contient des éléments FRAMESET et FRAME avec un attribut LONGDESC non correct.

Attribut LONGDESC incorrect de l'élément FRAME : vide. Attribut LONGDESC incorrect de l'élément FRAME : ne contient pas d'espaces. Attribut LONGDESC incorrect de l'élément FRAME : le fichier mentionné est vide. Attribut LONGDESC incorrect de l'élément FRAME : le fichier mentionné n'existe pas. Attribut LONGDESC incorrect de l'élément FRAME : le fichier mentionné n'est pas un fichier HTML. Attribut LONGDESC incorrect de l'élément FRAME : erreur HTTP (fichier introuvable ?). Attribut LONGDESC incorrect de l'élément FRAME : il ne s'agit pas d'une adresse URL de type HTTP ou FTP.

Les cadres sont principalement utilisés pour regrouper des informations et des éléments de navigation, ainsi que pour les afficher avec une certaine mise en page. Cependant, certaines technologies d'aide (navigateurs vocaux ou en mode texte, lecteurs d'écran) ne peuvent pas profiter de la mise en page. Par conséquent, ces outils rendent chaque cadre hors contexte, sans la moindre référence aux autres cadres. La personne utilisant ces outils ne peut pas voir les autres cadres et leur contenu. C'est pourquoi il est important que chaque cadre indique une description permettant à l'utilisateur d'élaborer le contexte.

Les noms tels que "haut", "en bas à gauche" généralement attribués aux cadres ne sont pas suffisamment descriptifs et n'aident pas l'utilisateur à reconstruire le contexte.

Prenons un exemple (issu de HTML Techniques for Web Content Accessibility Guidelines 1.0 et légèrement modifié) :

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN">
<HTML>
  <HEAD>
    <TITLE>Today's news</TITLE>
  </HEAD>

  <FRAMESET cols="10%,*,10%">

  <FRAMESET rows="20%,*">
    <FRAME src="promo.html" name="promo" title="promotions">
    <FRAME src="sitenavbar.html" name="navbar" 
       title="Sitewide navigation bar" longdesc="frameset-desc.html#navbar">
  </FRAMESET>

  <FRAME src="story.html" name="story" title="Selected story - main content" 
     longdesc="frameset-desc.html#story">

  <FRAMESET rows="*,20%">
    <FRAME src="headlines.html" name="index" title="Index of other 
      national headlines" longdesc="frameset-desc.html#headlines">
    <FRAME src="ad.html" name="adspace" title="Advertising">
  </FRAMESET>

  <NOFRAMES>
    <p><a href="noframes.html">No frames version</a></p>
    <p><a href="frameset-desc.html">Descriptions of frames.</a></p>

  </NOFRAMES>

  </FRAMESET>
</HTML>

Voici un exemple de fichier frameset-desc.html :

#Navbar - this frame provides links to the <a href="sitenavbar.html">major 
          sections of the site</a>:  World News, National News,
          Local News, Technological News,
          and Entertainment News.

#Story  - this frame displays the <a href="story.html">currently selected story</a>.

#Index  - this frame provides links to the day's 
          <a href="headlines.html">headline stories</a> within this section.  

L'élément NOFRAMES est utile lorsque des navigateurs spéciaux ne prenant pas en charge les cadres sont utilisés (par exemple, ceux utilisés sur les assistants personnels et les téléphones portables).

Une longue description de cadre est requise, car un attribut LONGDESC est déjà défini. Cependant, la valeur de l'attribut LONGDESC n'est pas correcte.
Un attribut LONGDESC correct doit satisfaire toutes les conditions suivantes :

  1. ne doit pas être vide (c'est-à-dire différent de "")
  2. ne doit pas contenir un ou plusieurs espaces (par exemple, " ")
  3. le fichier auquel il fait référence n'est pas vide ou ne contient pas d'espaces
  4. le fichier auquel il fait référence existe et contient du code HTML
  5. le fichier auquel il fait référence est accessible HTTP ou FTP.

Voir la section Explication pour consulter un exemple détaillé.

Diviser les informations en groupes gérables dvdInfAppMngGrp Point de contr&ocirc;le 12,3 de priorit&eacute; 2 WAI / WCAG 1.0 Accessibilit&eacute; P.2 W3C/WCAG TOUTES manuelle tableaux formulaires

Vérifiez que le texte de la page est correctement divisé en groupes gérables (en-têtes, éléments de liste, etc.).

La méthode de lecture sur l'écran d'ordinateur diffère de celle sur papier du fait des différences physiques des propriétés des deux supports et des deux tâches pour l'utilisateur.

Lorsqu'une personne lit une page Web sur un écran d'ordinateur, elle la balaye du regard pour identifier sa structure générale et les sections qui la composent. Les titres, les en-têtes, le texte en gras, souligné ou mise en en retrait attirent rapidement l'attention du lecteur.

Les gros blocs de texte ne sont lus qu'une fois le balayage terminé et uniquement si le contenu du texte intéresse le lecteur.

En outre, les technologies d'aide permettent souvent de regrouper automatiquement des informations et de les rendre séparément. Par exemple, elles rendent un cadre à la fois ; elles permettent à l'utilisateur de passer directement à une certaine section (entre deux balises d'en-tête H1, H2...) ; elles rendent une zone sensible (par exemple, une image interactive) en un groupe, etc. De cette façon, une personne se servant d'une technologie d'aide peut bénéficier de la division d'informations en groupes ou en éléments de navigation.

Utilisez tous les moyens possibles pour diviser de gros blocs de texte, des contrôles de formulaire et des liens en plus petits groupes.

Par exemple, utilisez OPTGROUP pour regrouper les éléments OPTION dans un élément SELECT ; regrouper des contrôles de formulaire avec FIELDSET et LEGEND ; utilisez des listes imbriquées aux endroits appropriés ; utilisez des en-têtes pour structurer les documents, etc.

Ajouter des étiquettes claires aux contrôles de formulaire assLblExpCtrl Point de contr&ocirc;le 12,4 de priorit&eacute; 2 WAI / WCAG 1.0 Accessibilit&eacute; P.2 W3C/WCAG TOUTES formulaires

La page contient un formulaire dont les contrôles ne sont pas explicitement associés aux éléments LABEL.

L'élément de champ de texte (INPUT avec type TEXT) n'est associé à aucune étiquette. L'élément de champ de texte de ligne multiple (TEXTAREA) n'est associé à aucune étiquette. L'élément de champ de texte de mot de passe (INPUT avec type PASSWORD) n'est associé à aucune étiquette. L'élément de bouton radio (INPUT avec type RADIO) n'est associé à aucune étiquette. L'élément de case à cocher (INPUT avec type CHECKBOX) n'est associé à aucune étiquette. L'élément de champ de fichier (INPUT avec type FILE) n'est associé à aucune étiquette. L'élément de liste/menu (SELECT) n'est associé à aucune étiquette.

Lorsqu'un utilisateur voyant normalement parcoure un formulaire à l'aide de la touche de tabulation, il peut facilement associer les contrôles aux étiquettes placés près d'eux. Cependant, pour une personne utilisant un lecteur d'écran, cette information est insuffisante. Il est nécessaire de spécifier explicitement quelle étiquette est associée à quel contrôle de formulaire.

La meilleure façon pour y arriver consiste à utiliser l'élément LABEL. Celui-ci doit contenir l'étiquette et le contrôle de formulaire actuels ; son attribut FOR doit contenir l'ID du contrôle.

Un élément LABEL peut ne pointer que vers un seul contrôle ou plusieurs éléments LABEL peuvent pointer vers le même contrôle. Cette fonctionnalité n'étant pas disponible sur tous les lecteurs d'écran, il est recommandé d'attribuer un seul élément LABEL à chaque contrôle.

Il est possible d'associer implicitement une étiquette à un contrôle : insérez à la fois l'étiquette et le contrôle comme contenu de l'élément LABEL. Bien que cette technique soit proposée dans la spécification HTML 4.01 Recommandation, elle n'est pas encore prise en charge par tous les lecteurs d'écran.

Trois étapes sont nécessaires pour associer une étiquette à un contrôle :

  1. attribuez un identifiant unique au contrôle à l'aide de l'attribut ID ;
  2. créez un élément LABEL contenant l'étiquette texte ou image à associer au contrôle ;
  3. ajoutez l'attribut FOR à l'élément LABEL avec l'ID du contrôle comme valeur.

Exemple :

<form action="submit" method="post">
   <label for="firstname">First name: </label>
   <input type="text" id="firstname">
   <label for="lastname">Last name: </label>
   <input type="text" id="lastname">
</form>
Identifier clairement la cible de chaque lien clrIdtTrgLnk Point de contr&ocirc;le 13,1 de priorit&eacute; 2 WAI / WCAG 1.0 Accessibilit&eacute; P.2 W3C/WCAG TOUTES manuelle liens images interactives

La page contient des liens avec des étiquettes texte (c'est-à-dire des éléments A avec du texte). Vérifiez que les étiquettes sont compréhensibles, informatives et courtes.

Le texte du lien doit être compréhensible si vous le lisez hors contexte (qu'il soit isolé ou qu'il fasse partie d'une séquence de liens). Le texte du lien doit être également concis. Par exemple, en HTML, écrivez " Informations à propos de la version 4.3 " plutôt que " cliquez ici ", " cliquez ", " ici " ou " aller ". En outre, les développeurs de contenu peuvent préciser encore plus la cible d'un lien en ajoutant un titre de lien informatif (par exemple, en HTML, l'attribut " title ").

L'attribut TITLE est vide ou ne contient aucun espace. L'attribut TITLE ne se trouve pas dans le texte du lien.

La plupart des technologies d'aide peuvent extraire tous les liens de la page avant de les rendre dans une liste distincte. Dans ce cas, à partir des informations contenues dans l'étiquette du lien (c'est-à-dire le contenu) et dans l'attribut du titre du lien, les utilisateurs doivent pouvoir déduire la cible du lien.

C'est pourquoi, des liens comme " plus d'infos ", en particulier s'ils apparaissent plusieurs fois dans la même page, ne sont pas suffisamment clairs hors contexte.

Les étiquettes de lien doivent contenir le maximum d'informations pour que l'utilisateur puisse savoir la destination du lien. Il est important que l'utilisateur sache exactement la destination d'un lien avant de cliquer dessus. Autrement, il doit attendre que la nouvelle page se charge et s'affiche avant de savoir si le contenu l'intéresse vraiment.

Ceci est particulièrement important pour les pages dont le temps de chargement peut être plus long que celui d'une page normale ou celles nécessitant des plug-in spécifiques (par exemple, PDF, Flash, MS Word, etc.).

Modifiez l'étiquette du lien de façon à ce qu'elle décrive clairement la direction du lien. La description doit être concise et suffisamment claire pour être comprise hors contexte (par exemple, une liste dressant tous les liens de la page).

Si l'étiquette du lien n'est pas suffisante, utilisez également le titre du lien (qui apparaît dans de nombreux navigateurs sous forme d'info-bulle lorsque le pointeur de la souris est placé au-dessus du lien). Toutefois, si vous utilisez des liens de titre, le texte doit être cohérent sur tout le site.

Utiliser des étiquettes de lien compréhensibles useMngLblLnk Point de contr&ocirc;le 13,1 de priorit&eacute; 2 WAI / WCAG 1.0 Accessibilit&eacute; P.2 W3C/WCAG TOUTES liens images interactives

La page contient des liens dont l'étiquette (c'est-à-dire le contenu de l'élément A) ou le titre (l'attribut TITLE de l'élément A) n'est pas assez descriptif. Vérifiez que les étiquettes sont compréhensibles, informatives et courtes.

Le texte du lien doit être compréhensible si vous le lisez hors contexte (qu'il soit isolé ou qu'il fasse partie d'une séquence de liens). Le texte du lien doit être également concis. Par exemple, en HTML, écrivez " Informations à propos de la version 4.3 " plutôt que " cliquez ici ", " cliquez ", " ici " ou " aller ". En outre, les développeurs de contenu peuvent préciser encore plus la cible d'un lien en ajoutant un titre de lien informatif (par exemple, en HTML, l'attribut " title ").

Le contenu de la cible du lien n'est pas clair. L'attribut du titre de la cible du lien n'est pas clair.

La plupart des technologies d'aide peuvent extraire tous les liens de la page avant de les rendre dans une liste distincte. Dans ce cas, à partir des informations contenues dans l'étiquette du lien (c'est-à-dire le contenu) et dans l'attribut du titre du lien, les utilisateurs doivent pouvoir déduire la cible du lien.

C'est pourquoi, des liens comme " plus d'infos ", en particulier s'ils apparaissent plusieurs fois dans la même page, ne sont pas suffisamment clairs hors contexte.

Les étiquettes de lien doivent contenir le maximum d'informations pour que l'utilisateur puisse savoir la destination du lien. Il est important que l'utilisateur sache exactement la destination d'un lien avant de cliquer dessus. Autrement, il doit attendre que la nouvelle page se charge et s'affiche avant de savoir si le contenu l'intéresse vraiment.

Ceci est particulièrement important pour les pages dont le temps de chargement peut être plus long que celui d'une page normale ou celles nécessitant des plug-in spécifiques (par exemple, PDF, Flash, MS Word, etc.).

Modifiez l'étiquette du lien de façon à ce qu'elle décrive clairement la direction du lien. La description doit être concise et aussi claire que possible pour être comprise hors contexte (par exemple, une liste dressant tous les liens de la page).

Si l'étiquette du lien n'est pas suffisante, utilisez également le titre du lien (qui apparaît dans de nombreux navigateurs sous forme d'info-bulle lorsque le pointeur de la souris est placé au-dessus du lien). Toutefois, si vous utilisez des liens de titre, le texte doit être cohérent sur tout le site.

Ne pas utiliser le même texte de lien lorsque les liens vers des URL différentes sameLnkDiffUrls Point de contr&ocirc;le 13,1 de priorit&eacute; 2 WAI / WCAG 1.0 Accessibilit&eacute; P.2 W3C/WCAG TOUTES liens

La page contient au moins deux liens portant la même étiquette, mais pointent vers des URL différentes.

Une étiquette de lien est considérée comme l'équivalent texte et du titre du lien. En d'autres termes, tout le texte contenu entre A et /A, l'attribut ALT des images contenues entre A et /A et la valeur de l'attribut TITLE, si spécifié.

N'utilisez pas plusieurs fois le même texte de lien lorsque les liens pointent vers des URL différentes. Si au moins deux liens sur une page partagent le même texte de lien, tous ces liens doivent pointer vers la même ressource. Une telle cohérence facilite la conception de la page ainsi que son accessibilité.

Lorsque la même étiquette de lien se répète, cela sous-entend que le lien pointe vers la même direction. Si ce n'est pas le cas, les utilisateurs risquent d'êtres surpris et désorientés. Il est préférable de considérer que de nombreux utilisateurs ne sont pas habitués au mode de fonctionnement du Web, par conséquent, le risque qu'ils soient désorientés et qu'ils quittent le site est élevé.

En outre, les lecteurs d'écran et les navigateurs vocaux permettent souvent de rendre la liste des liens de la page dans une fenêtre pop-up distincte. Chaque lien y figure hors contexte. Si deux liens portent la même étiquette, l'utilisateur peut croire qu'ils pointent vers la même direction. L'utilisateur peut ne plus être en mesure d'atteindre une certaine page ou le service en ligne.

Utilisez des étiquettes de lien différentes pour les liens pointant vers des documents différents. En outre, il est recommandé d'utiliser au maximum des étiquettes informatives.
Si ce n'est pas possible, (par exemple, lorsqu'il est nécessaire de répéter le même lien " Achat en ligne " pour plusieurs produits figurant dans la même liste), distinguez les liens en attribuant une valeur différente à l'attribut " title " de chaque élément A.

Fournir des métadonnées aux pages et aux sites prvMtdtPgSt Point de contr&ocirc;le 13,2 de priorit&eacute; 2 WAI / WCAG 1.0 Accessibilit&eacute; P.2 W3C/WCAG TOUTES liens m&eacute;ta images interactives

La page ne contient, dans sa section HEAD, aucun élément LINK spécifiant les relations entre cette page et les autres documents ou éléments d'information.

Par exemple, utilisez RDF pour indiquer l'auteur du document, le type de contenu, etc. Certains agents utilisateur du langage HTML peuvent créer des outils de navigation à partir des relations des documents décrites par l'élément HTML LINK et les attributs " rel" ou " rev " (c'est-à-dire, rel="next", rel="previous", rel="index", etc.).

L'élément LINK définit un lien que l'utilisateur ne voit pas, mais qui est utilisé par le navigateur dans des cas bien précis. Il transmet des informations que le navigateur peut traiter de plusieurs façons (par exemple, Mozilla peut afficher une barre de navigation spéciale ; lynx présente ces liens dans une section spéciale de cet affichage).

En général, LINK représente une relation entre le document actif et un autre élément. C'est le cas, par exemple, entre le document HTML actif et un fichier CSS externe. Un autre exemple consiste à représenter le document suivant et précédent dans une séquence de documents (comme pour les différents chapitres d'un didacticiel).

Cet exemple est présenté par le W3C (&w3c_html401;) :

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
   "http://www.w3.org/TR/html4/strict.dtd">
<HTML>
<HEAD>
  <TITLE>Chapter 2</TITLE>

  <LINK rel="Index" href="../index.html">
  <LINK rel="Next"  href="Chapter3.html">
  <LINK rel="Prev"  href="Chapter1.html">
</HEAD>
...the rest of the document...

Dans l'exemple suivant, provenant de la même source, utilisez l'attribut HREFLANG pour indiquer aux moteurs de recherche oł trouver la version hollandaise, portugaise et arabe d'un document. Notez l'utilisation de l'attribut CHARSET pour le manuel arabe. Notez également l'utilisation de l'attribut LANG pour indiquer la valeur de l'attribut de titre pour l'élément LINK indiquant que le manuel français est en français.

<HEAD>
<TITLE>The manual in English</TITLE>
<LINK title="The manual in Dutch"
      type="text/html"
      rel="alternate"
      hreflang="nl" 
      href="http://someplace.com/manual/dutch.html">
<LINK title="The manual in Portuguese"
      type="text/html"
      rel="alternate"
      hreflang="pt" 
      href="http://someplace.com/manual/portuguese.html">
<LINK title="The manual in Arabic"
      type="text/html"
      rel="alternate"
      charset="ISO-8859-6"
      hreflang="ar" 
      href="http://someplace.com/manual/arabic.html">
<LINK lang="fr" title="La documentation en Fran&ccedil;ais"
      type="text/html"
      rel="alternate"
      hreflang="fr"
      href="http://someplace.com/manual/french.html">
</HEAD>

Dans l'exemple suivant, on indique aux moteurs de recherche oł chercher la version imprimée d'un manuel.

<HEAD>
<TITLE>Reference manual</TITLE>
<LINK media="print" title="The manual in postscript"
      type="application/postscript"
      rel="alternate"
      href="http://someplace.com/manual/postscript.ps">

</HEAD>

Et oł chercher la première page d'une collection de documents.

<HEAD>
<TITLE>Reference manual -- Page 5</TITLE>
<LINK rel="Start" title="The first page of the manual"
      type="text/html"
      href="http://someplace.com/manual/start.html">

</HEAD>

Ajoutez les éléments LINK à la section HEAD pour représenter les relations entre cette page et les autres documents.

Liste des relations possibles entre les documents pouvant être représentés par l'élément LINK depuis &w3c_html401;.

Le titre de la page doit être correctement défini validPageTitle Point de contrôle 13,2 de priorité 2 WAI / WCAG 1.0 Accessibilit&eacute; P.2 W3C/WCAG TOUTES m&eacute;ta

La page n'a pas d'élément TITLE correct.

La page ne contient aucun élément TITLE. Contenu vide ("") spécifié pour l'élément TITLE. La page contient plusieurs instances de TITLE. L'élément TITLE de la page contient plus de 64 caractères. L'élément TITLE de la page n'est pas inclus dans l'élément HEAD. L'élément TITLE de la page contient des balises HTML. L'élément TITLE de la page semble ne contenir que du texte d'espace réservé.

La balise TITLE définit le titre du document pour :

  • les fenêtres de navigateur
  • les navigateurs vocaux
  • les listes de signets
  • les listes d'historique
  • les listes de résultats des moteurs de recherche

Un élément TITLE absent ou insuffisant rend beaucoup plus difficile la localisation et la compréhension de la page à chaque fois que l'utilisateur doit identifier une fenêtre, deviner le contexte, en sélectionnant un élément d'une liste de signets ou de résultats d'une recherche.
Cela se produit souvent lors de l'utilisation de technologies d'aide, puisque le titre de la page est la première chose présentée à l'utilisateur, ce qui devrait clarifier le nouveau contexte apporté par la page.

Pour être efficaces, les titres doivent être concis et informatifs (c'est-à-dire qu'ils doivent suffisamment décrire le contenu de la page).
Selon Nielsen, le titre d'une page doit être d'une grande clarté.

Les titres ne doivent pas contenir de balises HTML, car elles ne peuvent être interprétées par les navigateurs (ce qui empêcherait de comprendre entièrement le titre).

En somme, une page doit contenir exactement un seul titre : S'il y a plusieurs titres, seul un sera pris en compte par le navigateur.

Tenez également compte du fait que souvent les lecteurs d'écran, lors de la présentation des cadres disponibles à l'utilisateur, lisent l'élément TITLE des pages contenant des cadres (pas seulement l'attribut TITLE de l'élement FRAME). Par conséquent, il est important que les éléments TITLE des pages contenant des cadres soient bien définis et compréhensibles.

Pour définir le titre de la page pour qu'il comprenne le code HTML suivant en dessous de la balise HTML au début du document :

<HEAD>
 <TITLE>
  Buy the best strawberries fields in the world
 </TITLE>
</HEAD>

Avec Dreamweaver, vous pouvez y parvenir plus facilement : il suffit simplement de remplir le champ titre situé en haut de la fenêtre d'édition.

Pour que le titre soit efficace, celui-ci doit répondre aux conditions suivantes :

  • un titre doit être concis et informatif ;
  • un titre ne doit contenir aucune balise HTML ;
  • un titre ne doit être défini qu'une seule fois dans un document.
Fournir des informations sur l'organisation du site prvInfGnrLytSt Point de contrôle 13,3 de priorité 2 WAI / WCAG 1.0 Accessibilit&eacute; P.2 W3C/WCAG TOUTES manuelle images interactives liens tableaux

S'il n'a pas de plan du site, ajoutez-en un et décrivez comment son contenu est organisé à travers le site. Mettez également en valeur les fonctionnalités d'accessibilité disponibles sur le site.

Le plan du site est en quelque sorte la table des matières du site. Il permet à la personne visitant le site d'obtenir une vue globale de la structure de ce dernier.

Pour les personnes malvoyantes, la prise de contact avec un site peut nécessiter plus de temps, puisqu'elles doivent écouter le contenu des pages qu'elles visitent. Cela prend plus de temps que balayer la page du regard.

Mettez en place un plan du site de manière graphique ou comme une liste d'éléments imbriqués (comme la table des matières d'un livre) ou utilisez tout autre moyen permettant de décrire efficacement les catégories des éléments d'informations.

Si les fonctionnalités d'accessibilité mises en place sur la page sont décrites, les utilisateurs peuvent configurer la technologie d'aide spécifique qu'ils utilisent pour appliquer ces solutions.

Utiliser les mécanismes de navigation correctement useNvgMchApp Point de contrôle 13,4 de priorité 2 WAI / WCAG 1.0 Accessibilit&eacute; P.2 W3C/WCAG TOUTES manuelle scripts liens images interactives

La page semble contenu une barre de navigation. Vérifiez que les barres de navigation sont cohérentes partout dans le site.

La cohérence est un facteur crucial pour faire de votre site Web un site accessible et utilisable. En fait, si une fonctionnalité (par exemple, une barre de navigation) est utilisée de manière cohérente dans toutes les pages du site, l'utilisateur saisira rapidement le rôle de la barre de navigation et de ses boutons/liens, et sera en mesure de s'en servir sans hésitation.

Si, d'autre part, un groupe de liens ne cesse de changer d'une page à l'autre, l'utilisateur doit à nouveau comprendre son rôle chaque fois qu'elle apparaît. L'utilisateur perd son temps, doit faire un effort supplémentaire et le risque d'erreurs est plus important (celui-ci risque de cliquer involontairement sur un lien).

Vérifiez toutes les barres de navigation du site et que leurs liens sont cohérents le plus possible quant à leur ordre, leur position, leur mise en forme et leur étiquetage.