Exporter (0) Imprimer
Développer tout
Cet article a fait l'objet d'une traduction manuelle. Déplacez votre pointeur sur les phrases de l'article pour voir la version originale de ce texte.
Traduction
Source

Accessibilité dans Visual Studio et ASP.NET

Les normes d'accessibilité permettent de générer des pages Web qui peuvent être utilisées par les personnes en situation de handicap. Cette rubrique fournit une vue d'ensemble des normes pertinentes et de certaines techniques permettant de configurer les contrôles serveur Web ASP.NET afin de garantir qu'ils génèrent du HTML accessible.

Sauf mention contraire, les normes présentées dans cette rubrique valent pour les langages HTML et XHTML, et les références au HTML s'appliquent aux deux langages de balisage. Pour plus d'informations sur les normes XHTML et comment vous y conformer dans ASP.NET, consultez Normes XHTML dans Visual Studio et ASP.NET. Pour plus d'informations sur la mise en conformité aux normes d'accessibilité du HTML restitué pour des contrôles serveur ASP.NET spécifiques, consultez Contrôles et accessibilité ASP.NET.

Cette rubrique contient les sections suivantes :

Pour certaines personnes qui naviguent sur le Web, il est difficile voire impossible de voir un écran d'ordinateur. Certaines autres ne savent pas utiliser une souris. D'autres encore ont des difficultés pour lire ou apprendre à naviguer dans un site complexe. Les personnes d'un certain âge, par exemple, sont souvent concernées par plusieurs de ces limitations fonctionnelles, mais ont pour autant besoin d'utiliser des sites Web.

Certaines limitations fonctionnelles peuvent être facilement contournées par l'utilisation de technologies d'assistance. Le logiciel de lecteur d'écran qui convertit le texte d'une page en discours pour les personnes qui ne peuvent pas voir l'écran est un exemple de technologie d'assistance. De nombreuses normes d'accessibilité visent à vérifier que les technologies d'assistance peuvent fonctionner efficacement avec les pages Web.

D'autres normes d'accessibilité visent à rendre les sites Web plus compréhensibles et faciles à utiliser pour les personnes utilisant des navigateurs standard, même si elles n'ont pas besoin d'une technologie d'assistance. La conformité à ces normes d'accessibilité profite à tous les utilisateurs et non uniquement à ceux en situation de handicap.

Aider les personnes en situation de handicap et faciliter à chacun l'utilisation de votre site sont des objectifs qui en valent la peine. Par ailleurs, vous pouvez être légalement tenu de vous conformer aux normes d'accessibilité. L'accessibilité des sites Web est mandatée par un certain nombre de lois, notamment :

  • Aux États-Unis, tout site Web développé par une agence fédérale est tenu selon la Section 508 du Rehabilitation Act d'être accessible aux personnes en situation de handicap. Cette loi s'applique aux agences fédérales et à toutes les sociétés travaillant sous contrat pour elles. Vous pouvez lire le texte complet des recommandations de la Section 508 à l'adresse Site Web Section 508

    D'autres lois américaines qui ne sont pas spécifiquement orientées vers les sites Web, telles que l'Americans with Disabilities Act (ADA), ont été appliquées aux sites Web. En 2007, un grand détaillant a fait l'objet de poursuites judiciaires car son site Web ne proposait pas de fonctionnalités d'accessibilité. Le détaillant a accepté de rendre son site Web accessible et de payer 6 millions de dollars de dommages et intérêts aux plaignants. Il s'est également soumis à une surveillance continue de l'accessibilité par les plaignants.

  • Au Canada, les normes sur la Normalisation des sites Internet du Conseil du Trésor exigent que les sites Web développés par les agences gouvernementales soient accessibles.

  • En Australie, la loi Disability Discrimination Act requiert que tous les sites Web hébergés sur des serveurs australiens (qu'il s'agisse ou non d'un site Web de l'État) soient accessibles.

  • L'Union européenne travaille actuellement sur des lois reposant sur les normes du W3C.

De nombreux autres pays adoptent une législation ou des exigences réglementaires similaires. Pour plus d'informations sur les lois relatives à l'accessibilité, consultez l'initiative d'accessibilité du Web sur le site Web du World Wide Web Consortium (W3C).

Les directives d'accessibilité le plus largement utilisées sont les Directives pour l'accessibilité des contenus Web (WCAG) du World Wide Web Consortium (W3C). La version 1.0 de WCAG a été publiée le 5 mai 1999. Cette version a été remplacée par WCAG 2.0, qui a été publiée le 11 décembre 2008 (pour connaître les spécifications complètes des deux versions, consultez le site Web W3C). De nombreux organismes d'état et organisations publient également des directives sur la création d'applications accessibles, mais la plupart d'entre elles dérivent de WCAG.

WCAG 2.0 est organisé autour de quatre principes de conception pour l'accessibilité du Web. Chaque principe contient une ou plusieurs directives< et à chaque directive sont associés des critères de succès testables. Les critères de succès sont l'élément de base pour déterminer si un site Web est conforme aux directives WCAG 2.0.

Le site W3C propose également des techniques recommandées que vous pouvez utiliser pour suivre les directives et satisfaire aux critères de succès. Ces techniques ne font pas partie de la spécification officielle. Elles sont amenées à changer avec l'évolution des technologies, alors que les directives et les critères de succès restent stables.

Principes de conception de WCAG

Les quatre principes de conception de WCAG stipulent que le contenu Web doit avoir les caractéristiques suivantes :

  1. Perceptible.

    Les informations et les composants de l'interface utilisateur doivent pouvoir être présentés aux utilisateurs de façon à ce qu'ils puissent les percevoir. Par exemple, une personne non-voyante ne peut pas voir une image sur l'écran, mais peut entendre des mots prononcés par un logiciel de lecteur d'écran. En fournissant une description textuelle de l'image, vous pouvez vous assurer que les informations qui se trouvent sur la page sont perceptibles.

  2. Utilisable.

    L'interface utilisateur ne doit pas nécessiter une interaction qu'un utilisateur n'est pas dans la capacité de fournir. Par exemple, un utilisateur qui ne peut pas utiliser une souris doit être en mesure de naviguer sur un site Web à l'aide du clavier.

  3. Compréhensible.

    Les informations proposées sur une page Web et le fonctionnement de l'interface utilisateur doivent être compréhensibles. Par exemple, il est plus facile d'apprendre à naviguer dans un site Web qui affiche des liens de navigation dans le même ordre et avec la même apparence que dans un site Web où les liens de navigation sont affichés sans aucune cohérence.

  4. Robuste.

    Le contenu d'une page Web doit être compatible avec une large gamme de navigateurs et de technologies d'assistance. Le contenu doit rester accessible à mesure que les navigateurs et les technologies d'assistance évoluent. Par exemple, même si un navigateur particulier affiche correctement une certaine forme de HTML non standard, vous devez éviter cette pratique car il est possible que cela ne soit plus le cas avec les versions futures du navigateur.

Directives WCAG

Les directives permettant de s'assurer que le contenu Web est perceptible sont les suivantes :

  • Proposer des équivalents textuels à tout contenu non textuel comme les images. (1.1)

  • Proposer des équivalents textuels aux médias temporels comme le contenu audio ou vidéo. (1.2)

  • Structurer le contenu afin qu'il puisse être présenté de différentes manières (autres que par un navigateur graphique standard) sans perte d'informations. (1.3)

    Par exemple, assurez-vous que le code HTML d'un formulaire Web indique explicitement quels éléments label concernent quels éléments input, à défaut de quoi un lecteur d'écran risque de les annoncer de manière désordonnée.

  • Faciliter la perception visuelle et auditive du contenu. (1.4)

    Assurez-vous par exemple que le contraste entre les couleurs de premier plan et d'arrière-plan est suffisant et que l'utilisateur peut mettre en pause une piste audio.

Les directives permettant de s'assurer qu'un site Web est utilisable sont les suivantes :

  • Rendre toutes les fonctionnalités accessibles au clavier. (2.1)

  • Laisser aux utilisateurs suffisamment de temps pour lire et utiliser le contenu. (2.2)

    Par exemple, si une page est affichée seulement pendant quelques secondes avant de passer automatiquement à une autre, affichez une fenêtre contextuelle donnant la possibilité à l'utilisateur de différer le passage à une autre page.

  • Ne pas concevoir de contenu susceptible de provoquer des crises. (2.3)

    Les éléments visuels qui flashent plus de trois fois par seconde peuvent provoquer des crises.

  • Fournir aux utilisateurs des éléments d'orientation pour naviguer et trouver le contenu. (2.4)

Les directives permettant de s'assurer qu'un site Web est compréhensible sont les suivantes :

  • Rendre le contenu textuel lisible et compréhensible. (3.1)

  • Faire en sorte que les pages Web apparaissent et fonctionnent de manière prévisible. (3.2)

  • Aider les utilisateurs à éviter et à corriger les erreurs. (3.3)

L'unique directive permettant de s'assurer qu'un site Web est robuste répète pour l'essentiel le principe :

  • Optimiser la compatibilité avec les agents utilisateurs actuels et futurs. Les agents utilisateurs incluent les navigateurs et les logiciels de technologie d'assistance. (4.1)

    Le meilleur moyen de suivre ces directives est de veiller à ce que les pages Web contiennent uniquement du HTML valide.

Critères de succès et niveaux de conformité de WCAG

Les critères de succès testables sont spécifiés pour chaque directive. Pour plus d'informations sur ces critères de test, consultez les spécifications de WCAG 2.0 sur le site Web W3C. Les critères de succès sont regroupés en trois niveaux qui spécifient des degrés croissants de conformité aux directives d'accessibilité :

  • Niveau A.

    Selon le W3C, vous devez suivre les directives qui permettent à un site de satisfaire à ces critères de succès de base. Dans le cas contraire, il sera impossible pour un ou plusieurs groupes d'utilisateurs d'accéder à certaines informations ou fonctionnalités du site.

  • Niveau AA.

    Vous devez également suivre les directives qui permettent à un site de satisfaire à ces directives plus rigoureuses. Dans le cas contraire, il sera difficile pour un ou plusieurs groupes d'utilisateurs d'accéder à certaines informations ou fonctionnalités du site.

  • Niveau AAA.

    Vous pouvez décider de suivre les directives qui permettent à un site de satisfaire à ces directives très rigoureuses. Ce niveau est atteint par très peu de sites Web. Le W3C ne le recommande pas comme objectif pour un site entier car il n'est pas possible d'atteindre le niveau de conformité AAA pour certains types de contenu.

Si votre site Web est conforme aux directives WCAG, vous pouvez afficher un logo qui annonce cet état de fait aux utilisateurs du site. Le logo indique le niveau de conformité que votre site a atteint.

Si votre site Web satisfait à tous les critères de succès du Niveau A, vous pouvez afficher un logo indiquant Niveau de conformité A Pour atteindre le niveau de conformité AA, vous devez remplir tous les critères de succès des niveaux A et AA (pas seulement ceux du niveau AA). Pour atteindre le niveau de conformité AAA, vous devez remplir tous les critères des niveaux A et AA, ainsi que ceux du niveau AAA. Pour plus d'informations, consultez la page relative aux logos de conformité à WCAG 2.0 sur le site Web W3C.

Le W3C travaille actuellement à une nouvelle norme visant à s'assurer que les technologies d'assistance fonctionnement correctement avec les applications Internet riches (RIA, Rich Internet Applications). Dans ce contexte, une application Internet riche est une page Web qui inclut des contrôles côté client (appelés des widgets dans les documents du W3C). Ces widgets se composent généralement d'éléments HTML et de code JavaScript ou AJAX. Un contrôle Calendar qui affiche un calendrier dans lequel vous pouvez sélectionner une date à insérer dans une zone de texte de date est un exemple de widget. Le balisage côté client généré par certains contrôles serveur ASP.NET peut être considéré comme un widget, de même que les contrôles dans ASP.NET AJAX Control Toolkit.

La norme ARIA concerne principalement les nouveaux attributs qui peuvent être ajoutés aux éléments HTML. Des logiciels de technologie d'assistance peuvent utiliser ces attributs pour identifier la fonction, la propriété et l'état des widgets. Ces normes comprennent également des directives spécifiant la manière dont les widgets doivent répondre à l'entrée au clavier, afin de s'assurer qu'ils sont accessibles au clavier de façon cohérente.

Le nouvel attribut le plus important introduit par ARIA est role, qui identifie le type de widget, comme indiqué dans l'exemple suivant :

<table role="datepicker">

Cet attribut notifie la fonction du widget à la technologie d'assistance afin que cette dernière sache comment représenter et utiliser le widget. Dans cet exemple, au lieu d'annoncer une série de cellules de tableau, un lecteur d'écran peut annoncer qu'un calendrier est présenté dans lequel l'utilisateur peut sélectionner une date.

Les attributs de propriété et d'état fournissent d'autres informations sur le widget, comme indiqué dans l'exemple suivant :

<button role=slider

  aria-valuemin="0"

aria-valuemax="100"

  aria-valuenow="0">

Ces attributs non seulement fournissent des informations supplémentaires sur le widget, mais permettent à la technologie d'assistance d'utiliser le widget par programmation. Dans l'exemple, un lecteur d'écran peut annoncer que ce widget est un contrôle Slider et que le paramètre actuel du curseur est zéro. Le lecteur d'écran peut déplacer par programmation le curseur en mettant à jour l'attribut aria-valuenow dans les limites indiquées par les valeurs maximales et minimales.

Certains attributs ARIA ne s'appliquent pas spécifiquement aux widgets. Par exemple, les rôles d'éléments géographiques (qui sont indiqués à l'aide du même attribut role) indiquent la fonction logique de régions d'une page Web, comme dans les exemples suivants :

<div role="banner">

<div role="navigation">

<div role="main">

<div role="complementary">

Une page dont les sections principales sont marquées avec des rôles d'éléments géographiques autorise le logiciel de lecteur d'écran à lire à l'utilisateur une liste de titres de sections. L'utilisateur peut ensuite sélectionner l'une des sections pour indiquer au lecteur d'écran de commencer la lecture au niveau d'une partie spécifique de la page. Cela fait gagner du temps aux utilisateurs en leur permettant d'ignorer les sections qui ne les intéressent pas.

Étant donné qu'ARIA est relativement nouveau et en cours de développement, la prise en charge de ses attributs est limitée dans les navigateurs Web et dans les logiciels de technologie d'assistance. De plus, les pages qui incluent les attributs ARIA peuvent être jugées incorrectes dans le service de validation du balisage du W3C. Vous pouvez toutefois inclure des attributs ARIA dans les pages Web car ils sont simplement ignorés par les navigateurs qui ne les prennent pas en charge.

Pour plus d'informations sur ARIA, consultez la vue d'ensemble d'ARIA sur le site Web du W3C. Pour plus d'informations sur les contrôles ASP.NET qui génèrent du HTML conforme aux normes ARIA, consultez Contrôles et accessibilité ASP.NET. Pour ajouter la prise en charge ARIA pour les contrôles ASP.NET qui ne le prennent pas fondamentalement en charge, vous pouvez utiliser des attributs JavaScript ou expando.

WCAG 1.0 requiert que les pages Web fonctionnent sans utiliser de script client. Ces spécifications stipulent les points suivants :

Vérifiez que les pages sont utilisables lorsque les scripts, les applets ou d'autres objets de programmation sont désactivés ou non pris en charge. Si cela n'est pas possible, fournissez des informations équivalentes sur une autre page accessible. (6.3)

Cette exigence correspondait à l'état de la technologie en 1999. Depuis, la prise en charge de JavaScript a été ajoutée par les logiciels de technologie d'assistance et WCAG 2.0 autorise les pages Web à se reposer sur le script client.

Toutefois, si vous devez vous conformer à une norme d'accessibilité plus ancienne, vous serez probablement toujours soumis à cette exigence. Dans ce cas, vous devez éviter les contrôles ASP.NET qui requièrent JavaScript pour fonctionner. Par exemple, les contrôles LinkButton et ImageButton requièrent le script client pour exécuter des publications (postbacks). Pour obtenir la liste de tous les contrôles ASP.NET qui utilisent le script client, consultez Contrôles serveur Web ASP.NET qui utilisent un script client.

WCAG 2.0 exige qu'un site Web puisse être utilisé en se servant du clavier. Par conséquent, un site Web accessible ne peut pas utiliser JavaScript d'une façon qui rend les fonctionnalités disponibles uniquement au moyen d'actions de souris. Par exemple, si vous écrivez du code JavaScript qui propose une certaine fonctionnalité en réponse à un événement mouseover, assurez-vous que cette même fonctionnalité est accessible à partir du clavier. Tous les contrôles ASP.NET autorisent par défaut l'accès au clavier ou peuvent être configurés pour permettre l'accès de clavier.

Les contrôles ASP.NET sont conçus pour être accessibles par défaut. Cela signifie qu'ils restituent automatiquement le code HTML accessible si possible, ou qu'ils exposent des propriétés que vous pouvez définir pour rendre les pages accessibles. Par exemple, les contrôles ASP.NET proposent les fonctionnalités suivantes pour prendre en charge l'accessibilité par défaut :

  • Générez du HTML qui utilise des feuilles de style en cascade (CSS) pour la mise en forme visuelle.

  • Utilisez des tableaux pour présenter des données, pas pour organiser les éléments visuels sur une page.

  • Fournissez des indications de structure du tableau en marquant les lignes d'en-tête et de pied de page.

  • Associez des étiquettes aux contrôles auxquels elles correspondent.

  • Générez le script client qui est indépendant du périphérique tel que le script qui répond à la fois aux clics de souris et aux actions de clavier.

  • Spécifiez les paramètres de l'index de tabulation pour les éléments d'entrée.

  • Fournissez un moyen de spécifier un texte équivalent pour tout élément de non-texte.

Certains contrôles génèrent le code HTML en fonction de modèles pour lesquels vous fournissez le code HTML. Dans ce cas, vous devez configurer manuellement le balisage dans les modèles afin que le code HTML généré soit conforme aux directives d'accessibilité.

Il existe des situations exceptionnelles dans lesquelles les contrôles génèrent du HTML qui peut ne pas être conforme aux normes d'accessibilité. ASP.NET 4 inclut de nombreuses améliorations éliminant la plupart des exceptions qui existaient dans les versions antérieures d'ASP.NET, ou fournissant des alternatives. Pour plus d'informations, consultez Nouveautés dans ASP.NET 4 et Visual Web Developer.

Les sections qui suivent présentent des techniques permettant de créer des pages Web accessibles qui sont conformes à chaque directive WCAG à l'aide de Visual Studio et d'ASP.NET. Pour certaines directives, aucune considération n'est spécifique à ASP.NET. Par conséquent, les sections consacrées à ces directives sont omises dans cette partie de la rubrique.

Chaque image dans une page Web doit inclure un attribut alt. L'attribut alt est utilisé par les technologies d'assistance comme les lecteurs d'écran pour annoncer le contenu de l'image à un utilisateur qui ne peut pas voir l'image. L'exemple suivant montre un attribut alt sur un élément HTML img :

<img src="Products23.gif" alt="Image of Widgets" />

Pour décider ce que vous devez placer dans l'attribut alt, vous devez déterminer si l'image est présente uniquement à des fins décoratives ou si elle fournit des informations. Si elle fournit des informations, vous devez également déterminer si ces informations peuvent être résumées en une phrase courte ou si elles requièrent un plus long bloc de texte.

Cette section explique comment s'assurer que les types d'images suivants sont accessibles dans les sites Web ASP.NET :

  • Images décoratives.

  • Images qui véhiculent des informations.

  • Images complexes.

  • Images générées par les contrôles ASP.NET.

Images décoratives

Si une image est utilisée uniquement en tant qu'élément de conception et ne véhicule aucune information utile, vous devez inclure un attribut alt, mais le définir sur une chaîne vide, comme illustré dans l'exemple suivant :

<img src="PageDivider.gif" alt="" />

Si vous omettez l'attribut alt, de nombreux lecteurs d'écran annonceront le nom de fichier, créant ainsi une confusion inutile.

Les contrôles ASP.NET qui restituent des images omettent l'attribut alt dans le code HTML restitué si vous affectez une chaîne vide à la propriété AlternateText. Supposons par exemple que vous ajoutiez le contrôle Image suivant à une page :

<asp:Image ImageUrl="PageDivider.gif" AlternateText=""

    runat="server" />

Le HTML suivant est alors restitué :

<img src="PageDivider.gif" />

Notez que l'attribut alt n'a pas été restitué. Il s'agit là du comportement par défaut de tous les attributs de contrôle ASP.NET. Lorsque vous n'affectez pas de valeur à un attribut, celui-ci n'est pas restitué. Dans ce cas toutefois, vous souhaitez qu'ASP.NET restitue une chaîne vide comme valeur de l'attribut alt. Pour s'assurer que le code HTML restitué pour un contrôle Image inclut alt="", vous devez définir la propriété GenerateEmptyAlternateText sur true, comme indiqué dans l'exemple suivant :

<asp:Image ImageUrl="PageDivider.gif" GenerateEmptyAlternateText="true"

    runat="server" />

Images qui véhiculent des informations

Pour les images qui véhiculent des informations, l'attribut alt doit contenir une description de l'image ou de sa fonction sur la page. Par exemple, si l'image d'un bouton de recherche montre une loupe, le texte de remplacement approprié est « Rechercher », et non « Loupe ».

Le texte de remplacement ne doit pas simplement répéter le contenu de l'attribut de nom de fichier. L'attribut alt est supposé véhiculer à une personne non-voyante les mêmes informations que celles véhiculées par l'image à une personne voyante.

La définition de la valeur d'un attribut alt requiert l'interprétation humaine de la signification d'une image. Pour cette raison, le processus de création des attributs alt ne peut pas être automatisé.

Les contrôles Image, ImageButton et ImageMap incluent une propriété AlternateText que vous pouvez utiliser pour définir l'attribut alt, comme illustré dans l'exemple suivant :

<asp:Image ImageUrl="Products23.gif" AlternateText="Image of widgets"

    runat="server" />

Images complexes

L'attribut alt vise à fournir une description courte ou un résumé de l'image. Il peut ne pas être suffisant pour les images complexes, comme les organigrammes. Dans ce cas, vous pouvez fournir un résumé dans l'attribut alt et des informations détaillées dans une page Web distincte. Vous liez l'image à la page Web descriptive à l'aide de l'attribut longdesc, comme indiqué dans l'exemple suivant d'un élément HTML img :

<img src="OrgChart.gif"

  alt="Company Organization Chart"

  longdesc="OrgChartDescription.aspx" />

Le contrôle ASP.NET Image inclut une propriété DescriptionUrl qui correspond à l'attribut HTML longdesc. L'exemple suivant montre comment utiliser cette propriété.

<asp:Image ImageUrl="OrgChart.gif"

    AlternateText="Company Organization Chart"

    DescriptionUrl="OrgChartDescription.aspx"

    runat="server" />

Images générées par les contrôles ASP.NET

Certains contrôles, comme le contrôle TreeView, le contrôle Menu et les contrôles WebPart, restituent automatiquement des images ou des liens dans leur balisage. Dans ces cas, le contrôle crée le texte de remplacement pour chaque image ou lien.

Par exemple, le contrôle TreeView restitue des images pour les boutons de développement et de réduction pour chaque nœud. Le contrôle TreeView génère le texte de remplacement pour ces images selon le texte du nœud. Par défaut, le texte de remplacement pour l'image de développement d'un nœud nommé Début est restitué en Développer Début. Vous pouvez spécifier un texte de remplacement personnalisé en définissant les propriétés ExpandImageToolTip et CollapseImageToolTip du contrôle TreeView.

De même, le contrôle Menu restitue le texte de remplacement pour les liens qu'il génère afin de développer ou de réduire des éléments de menu.

Les boutons d'une barre de titre de contrôle WebPart restituent de la même façon le texte de remplacement qui décrit la fonction de chaque bouton.

Les contenus vidéos et audios sont appelés médias temporels dans les directives WCAG. Vous pouvez proposer un média temporel dans votre page Web en utilisant le plug-in Silverlight. Dans ce cas, vous devez réfléchir à la manière de mettre les mêmes informations à disposition des personnes ayant des troubles de la vision ou de l'audition. Les directives permettant de garantir l'accessibilité lorsque vous utilisez le lecteur multimédia diffèrent selon que le contenu est en direct ou préenregistré et selon que le média inclut de la vidéo, de l'audio ou les deux. Les critères de succès du Niveau A s'appliquent uniquement au contenu préenregistré (autrement dit, ils ne s'appliquent pas au contenu en direct) :

  • Pour un clip audio qui inclut un discours ou un dialogue, vous devez mettre à disposition un texte fournissant les mêmes informations. Par exemple, en regard d'un plug-in Silverlight, vous pouvez ajouter un lien hypertexte vers une page qui fournit une transcription.

  • Pour un clip vidéo sans contenu audio, vous devez mettre à disposition une version de remplacement textuelle ou ajouter une piste audio dans laquelle quelqu'un décrit le contenu visuel. Par exemple, si la vidéo montre comment accomplir une tâche, en regard du plug-in, vous pouvez positionner un lien hypertexte qui pointe vers une page fournissant des instructions pas à pas dans le texte.

  • Pour un clip vidéo qui inclut une piste audio synchronisée, vous devez fournir des légendes pour les personnes ayant des troubles de l'audition et du texte ou un clip audio pour les personnes ayant des troubles de la vision.

Ces directives s'appliquent uniquement si le média temporel fournit des informations qui ne se trouvent pas dans le texte de la page Web. Si le média ne fait que répéter des informations déjà fournies dans le texte, il n'est pas nécessaire de fournir une version de remplacement supplémentaire.

Silverlight peut également être utilisé pour créer des applications Internet riches (RIA). Pour plus d'informations sur le suivi de directives d'accessibilité dans les applications Silverlight, consultez la Vue d'ensemble de l'accessibilité sur le site Web de la documentation Silverlight.

L'un des principes fondamentaux de la conception de pages Web accessibles est que le code HTML doit être sémantiquement correct. Cela signifie que vous devez utiliser les éléments HTML comme ils sont supposés l'être.

Par exemple, les éléments d'en-tête (h1, h2, h3) sont supposés indiquer une hiérarchie d'en-têtes qui décrivent le contenu des sections. Les navigateurs donnent une apparence par défaut à chaque élément d'en-tête pour indiquer la fonction de l'élément sur la page. Toutefois, un développeur peut utiliser un élément d'en-tête pour obtenir une apparence particulière ou peut donner un style personnalisé aux en-têtes sans utiliser aucun élément h.

Si une page Web ne contient que des éléments h3 car le développeur n'aimait pas la taille de police par défaut des éléments h1 et h2, l'utilisateur d'un lecteur d'écran peut se demander où se trouvent les sections de niveau supérieur manquantes. Ou bien, si une page Web utilise du texte gras à la place d'éléments h pour les en-têtes, l'utilisateur peut être perdu car le lecteur d'écran ne peut pas faire la différence entre le texte qui est en gras pour l'accentuer et celui qui est en gras parce qu'il s'agit d'un en-tête.

La façon correcte de structurer le balisage consiste à utiliser correctement les éléments HTML et à utiliser des règles de feuille de style en cascade (CSS) pour spécifier leur apparence. Par exemple, utilisez des éléments d'en-tête (h) pour structurer correctement un document et utilisez des règles CSS pour spécifier la taille de police appropriée pour chaque niveau d'en-tête.

Cette section contient les sections suivantes qui expliquent comment éviter d'utiliser des tableaux pour définir la mise en page, et comment s'assurer que les tableaux créés par les contrôles ASP.NET sont accessibles :

  • Conception d'une mise en page sans tableaux.

  • Rendre accessibles des tableaux HTML.

  • Association de champs d'entrée à des étiquettes.

Conception d'une mise en page sans tableaux.

Les développeurs mélangent souvent la structure et la présentation dans la conception de pages Web en utilisant des éléments table pour définir la disposition de la page ou pour spécifier l'emplacement des éléments visuels les uns par rapport aux autres sur la page. Lorsque des tableaux sont utilisés pour définir la disposition, le résultat est souvent un système complexe de tableaux externes et de tableaux internes incorporés. Avec de telles structures, les lecteurs d'écran annonceront très probablement le contenu des cellules selon une séquence déroutante n'ayant aucun lien avec la structure logique réelle de la page.

Il existe de nombreuses manières d'utiliser des feuilles de style en cascade avec des éléments HTML div et autres pour contrôler l'apparence et l'emplacement des fonctionnalités visuelles de la page. Toutefois, si vous ne pouvez pas éviter d'utiliser des tableaux pour définir la disposition, vous devez vérifier que le contenu des tableaux a de sens lorsqu'il est linéarisé (autrement dit, lorsqu'il est lu dans l'ordre des cellules du tableau : ligne du haut en premier, puis ligne suivante vers le bas, et ainsi de suite).

Pour plus d'informations sur l'utilisation de CSS, consultez Vue d'ensemble de l'utilisation de CSS.

Utilisation de contrôles ASP.NET qui génèrent des tableaux pour la mise en page

Certains contrôles ASP.NET génèrent automatiquement des tableaux HTML pour la mise en page, selon la façon dont ils sont configurés. Le tableau suivant répertorie ces contrôles et explique comment les configurer pour éviter qu'ils ne génèrent des tableaux non conformes aux directives d'accessibilité.

RemarqueRemarque

Ces contrôles génèrent du HTML sémantiquement correct et peuvent utiliser des feuilles de style en cascade à la place de tableaux pour la mise en forme lorsque la propriété Control.RenderingCompatibility a la valeur 4.0 ou une valeur supérieure.

Contrôles

Commentaires

Par défaut, ces contrôles restituent du HTML inclus dans un wrapper dans un élément table dont le but est d'appliquer des styles intralignes au contrôle entier. Vous appliquez des styles intralignes en définissant des propriétés telles que BackColor ou CssClass. Vous n'avez pas besoin d'utiliser des styles intralignes si vous utilisez des modèles pour spécifier comment le code HTML sera restitué pour ces contrôles. Dans ce cas, vous pouvez définir la propriété RenderOuterTable sur false pour empêcher la restitution du tableau externe.

Par défaut, ces contrôles restituent des listes sous la forme d'éléments table. Toutefois, ils peuvent restituer à la place des éléments ul (liste non triée), des éléments ol (liste triée) ou des éléments span, selon la définition de la propriété RepeatLayout. Pour restituer un balisage sémantiquement correct, définissez la propriété RepeatLayout sur UnorderedList ou OrderedList.

Les limitations de mise en forme suivantes s'appliquent si vous utilisez une liste triée ou une liste non triée :

  • L'orientation de la disposition doit être verticale.

  • Vous ne pouvez pas spécifier plusieurs colonnes.

  • Les en-têtes, les pieds de page et les séparateurs ne sont pas pris en charge.

Par défaut, ce contrôle génère du code HTML conforme aux directives d'accessibilité qui présente les caractéristiques suivantes :

  • Le code HTML généré est structuré sous forme de liste non triée (élément ul).

  • CSS est utilisée pour la mise en forme visuelle.

  • Le menu se comporte conformément aux normes ARIA pour l'accès au clavier.

  • Les attributs de propriété et de rôle ARIA sont ajoutés au code HTML généré.

Toutefois, le contrôle fournit la propriété RenderingMode pour la compatibilité descendante. Si vous définissez cette propriété sur Table, le contrôle générera du code HTML qui utilise des éléments Table pour la mise en forme, comme c'était le cas dans ASP.NET 3.5 et les versions antérieures

Rendre accessibles des tableaux HTML

Même si vous utilisez des tableaux HTML pour présenter des données sous forme de tableau et non pour la mise en page, ils peuvent être à l'origine de problèmes d'accessibilité. Lorsque le contenu d'un tableau est lu à haute voix, la personne qui écoute peut facilement perdre de vue la position actuelle dans le tableau et difficilement se rappeler à quel en-tête se rapporte une cellule particulière. Vous pouvez toutefois inclure des fonctionnalités qui simplifient la compréhension des tableaux.

Éléments thead et th

Pour s'assurer que les logiciels de lecteur d'écran peuvent clairement associer des cellules de tableau à leurs en-têtes, les en-têtes de tableaux doivent être placés dans des éléments th, et la ligne d'en-tête doit être dans un élément thead, comme indiqué dans l'exemple suivant :


<table>
  <thead>
    <tr>
        <th>Product</th>
        <th>Price</th>
    </tr>
  </thead>
  <tbody>
    <tr>
        <td>Milk</td>
        <td>$2.33</td>
    </tr>
    <tr>
        <td>Cereal</td>
        <td>$5.61</td>
    </tr>  
  </tbody>
</table>


Table avec éléments de thread et éléments th

Certains développeurs évitent d'utiliser des éléments th car qu'ils n'aiment pas l'apparence visuelle par défaut de ces éléments. Toutefois, l'apparence par défaut d'un élément HTML ne doit pas être le facteur déterminant dans le choix d'utiliser ou non un élément à une fin particulière. Si vous souhaitez que les en-têtes de colonnes se présentent comme des cellules de tableau normales, vous pouvez ajouter une règle de style comme la suivante :

<style type="text/css">

  th {text-align:left;font-weight:normal}

</style>

Attributs scope, headers et axis

Pour rendre un tableau accessible, vous devez également indiquer explicitement le ou les en-têtes associés à chaque cellule. Plusieurs attributs peuvent être utilisés à cette fin : scope, headers et axis.

L'attribut scope peut être utilisé pour indiquer si un élément th est un en-tête de colonne ou un en-tête de ligne. Par exemple, le tableau suivant contient à la fois des en-têtes de colonnes et des en-têtes de lignes, marqués avec les balises th qui utilisent l'attribut scope :


<table>
  <thead>
    <tr>
      <th></th>
      <th scope="col">First Train</th>
      <th scope="col">Last Train</th>
    </tr>
  </thead>
  <tbody>
  <tr>
      <th scope="row">Alewife</th>
      <td>5:24am</td>
      <td>12:15am</td>
  </tr>
  <tr>
      <th scope="row">Braintree</th>
      <td>5:15am</td>
      <td>12:18am</td>
  </tr>  
  </tbody>      
</table>


Tableau avec attributs d'étendue

Cet exemple de tableau contient les horaires de la Red Line du métro de Boston, Massachusetts. Notez que chaque en-tête de colonne inclut un attribut scope="col", et que chaque en-tête de ligne inclut un attribut scope="row".

L'attribut scope fonctionne bien pour les tableaux simples. Pour les tableaux plus complexes, il est préférable d'utiliser l'attribut headers Par exemple, un tableau imbriqué peut avoir trois en-têtes ou plus associés à une cellule unique. Dans l'exemple suivant du tableau Red Line Schedule, la cellule qui contient 5:24am se rapporte à trois en-têtes : First Train, Weekday et Alewife :

Tableau avec en-têtes et attributs d'axe

L'attribut headers vous permet d'identifier explicitement les en-têtes se rapportant à chaque cellule. Vous pouvez spécifier plusieurs en-têtes sous forme de liste délimitée par des espaces.

L'attribut axis vous permet de catégoriser les en-têtes. Dans le tableau Red Line Schedule, vous pouvez identifier Alewife et Braintree comme en-têtes location, Weekday et Saturday comme en-têtes day, puis First Train et Last Train comme en-têtes train. Si un même en-tête appartient à plusieurs catégories, vous pouvez spécifier une liste délimitée par des virgules pour l'attribut axis.

La page .aspx suivante restitue le tableau Red Line Schedule à l'aide des attributs headers et axis.


<%@ Page %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>

<head id="Head1" runat="server">
  <title>Red Line Subway Schedule</title>
  <style type="text/css">
    caption {color:white;background-color:red;font-size:xx-large}
    table {width:500px;border-collapse:collapse}
    td,th {padding:5px}
    td {border:1px solid black}
    tbody th {text-align:right}
    .headerRow th {font-size:x-large;text-align:left}    
  </style>
</head>

<body>
  <form id="form1" runat="server">
  <div>

  <table summary="This table contains the schedule of train 
                  departures for the Red Line">
    <caption>Red Line Schedule</caption>
    <thead>
      <tr>
        <th></th>
        <th id="hdrFirstTrain" axis="train">First Train</th>
        <th id="hdrLastTrain" axis="train">Last Train</th>
      </tr>
    </thead>
    <tbody>
      <tr class="headerRow">
          <th id="hdrWeekday" axis="day" colspan="3">Weekday</th>
      </tr>
      <tr>
        <th id="hdrAlewife1" axis="location">Alewife</th>
        <td headers="hdrAlwife1 hdrWeekday hdrFirstTrain">5:24am</td>
        <td headers="hdrAlwife1 hdrWeekday hdrLastTrain">12:15am</td>
      </tr>
      <tr>
        <th id="hdrBraintree1" axis="location">Braintree</th>
        <td headers="hdrBraintree1 hdrWeekday hdrFirstTrain">
          5:15am
        </td>
        <td headers="hdrBraintree1 hdrWeekday hdrLastTrain">
          12:18am
        </td>
      </tr>  
      <tr class="headerRow">
        <th id="hdrSaturday" axis="day" colspan="3">Saturday</th>
      </tr>
      <tr>
        <th id="hdrAlewife2" axis="location">Alewife</th>
        <td headers="hdrAlewife2 hdrSaturday hdrFirstTrain">8:24am</td>
        <td headers="hdrAlewife2 hdrSaturday hdrLastTrain">11:15pm</td>
      </tr>
      <tr>
        <th id="hdrBraintree2" axis="location">Braintree</th>
        <td headers="hdrBraintree2 hdrSaturday hdrFirstTrain">
          7:16am
        </td>
        <td headers="hdrBraintree2 hdrSaturday hdrLastTrain">
          10:18pm
        </td>
      </tr>  
    </tbody>      
  </table>

  </div>
  </form>
</body>
</html>


Chaque en-tête est un élément th ayant une valeur id unique, et chaque cellule de tableau est un élément td ayant un attribut headers Chaque attribut headers contient une liste des valeurs id d'en-tête qui se rapportent à cette cellule. Chaque élément th a également un attribut axis qui identifie la catégorie associée à l'en-tête.

RemarqueRemarque

Le balisage HTML pour un tableau complexe qui est illustré ici constitue l'une des deux approches possibles. Au lieu d'utiliser des attributs headers, vous pouvez regrouper les lignes dans des éléments tbody et identifier un en-tête de groupe en utilisant un attribut scope="rowgroup". Pour plus d'informations, consultez les recommandations du W3C pour les tableaux HTML sur le site Web du W3C et tout particulièrement la section relative à la restitution des tableaux pour les agents utilisateurs non visuels.

Éléments caption et summary

La manière sémantiquement correcte de fournir un titre pour un tableau HTML est d'utiliser l'élément caption. Par défaut, les navigateurs restituent le contenu de l'élément caption en tant que titre du tableau. Le titre du tableau Red Line Schedule indiqué dans la section précédente est un élément caption mis en forme avec un arrière-plan rouge et un premier plan blanc à l'aide de CSS.

Vous pouvez également fournir une description plus longue du tableau à l'aide de l'attribut summary. L'attribut summary n'est pas restitué par le navigateur mais peut être annoncé par un lecteur d'écran, de la même manière qu'un attribut alt pour une image. La page .aspx de l'exemple précédent définit également un attribut summary pour le tableau Red Line Schedule.

Utilisation du contrôle Table

Si vous utilisez le contrôle ASP.NET Table pour créer un tableau, vous pouvez définir l'attribut caption en définissant la propriété Caption. Vous pouvez créer des en-têtes de tableaux en créant des instances de la classe TableHeaderRow et en définissant la propriété TableSection sur la valeur d'énumération TableRowSection.TableHeader. Le tableau restitue alors les éléments thead et tbody. Lorsque vous créez une cellule à l'aide du contrôle TableCell, vous pouvez définir la propriété AssociatedHeaderCellID sur l'ID d'une cellule d'en-tête de tableau. En conséquence, la cellule restitue un attribut header qui associe la cellule à l'en-tête de colonne correspondant.

L'exemple suivant montre comment utiliser le contrôle Table pour créer un tableau identique à celui de la Figure 2. Le code HTML restitué pour ce tableau inclut des éléments thead et tbody, de même que des attributs header.


<asp:Table ID="Table1" runat="server">
    <asp:TableHeaderRow TableSection="TableHeader">
        <asp:TableHeaderCell ID="productheader">Product</asp:TableHeaderCell>
        <asp:TableHeaderCell ID="priceheader">Price</asp:TableHeaderCell>
    </asp:TableHeaderRow>
    <asp:TableRow>
        <asp:TableCell AssociatedHeaderCellID="productheader">Milk</asp:TableCell>
        <asp:TableCell AssociatedHeaderCellID="priceheader">$2.33</asp:TableCell>
    </asp:TableRow>
    <asp:TableRow>
        <asp:TableCell AssociatedHeaderCellID="productheader">Cereal</asp:TableCell>
        <asp:TableCell AssociatedHeaderCellID="priceheader">$5.61</asp:TableCell>
    </asp:TableRow>
</asp:Table>


Utilisation de contrôles de données pour créer automatiquement des tableaux

Les contrôles ASP.NET qui affichent automatiquement des données dans des tableaux HTML incluent les suivants :

Les tableaux générés par ces contrôles incluent par défaut des fonctionnalités d'accessibilité, comme les éléments th qui ont des attributs scope. De plus, vous pouvez activer des fonctionnalités d'accessibilité supplémentaires en définissant certaines propriétés. Par exemple, le contrôle GridView prend en charge plusieurs propriétés relatives à l'accessibilité :

  • Caption et CaptionAlign. Utilisez ces propriétés pour ajouter une légende au tableau HTML généré par le contrôle GridView.

  • RowHeaderColumn . Utilisez cette propriété pour indiquer une colonne utilisée pour les en-têtes de lignes. Définissez la propriété sur le nom d'une colonne retournée par la source de données (comme CustomerID). Cette propriété fonctionne uniquement avec les champs liés. Elle ne fonctionne pas avec les champs de modèle.

  • HeaderRow et FooterRow. Utilisez la propriété de ces propriétés pour générer les éléments thead, tbody et tfoot. Définissez la propriété TableSection de la propriété HeaderRow sur TableHeader pour générer les éléments thead, et définissez la propriété TableSection de la propriété FooterRow sur TableFooter pour générer les éléments tfoot. Si les éléments thead ou tfoot sont générés, les éléments tbody le sont également.

  • UseAccessibleHeader . Utilisez cette propriété pour indiquer si les en-têtes de colonnes doivent être restitués dans des éléments th ou td. Par défaut, elle est définie sur true.

Le contrôle GridView n'a pas de propriété prédéfinie qui est mappée à l'attribut summary. Toutefois, vous pouvez déclarer l'attribut summary dans le balisage en tant qu'attribut expando.

Dans l'exemple suivant, un contrôle GridView est lié à un contrôle SqlDataSource qui récupère les lignes de la table Customers de la base de données. Lorsque la page est ouverte dans un navigateur, les informations sur les clients sont affichées dans un tableau HTML.


<%@ Page Language="C#"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<script runat="server">
  protected void Page_Load(object sender, EventArgs e)
  {
      GridView1.HeaderRow.TableSection = TableRowSection.TableHeader;
  }
</script>

<html xmlns="http://www.w3.org/1999/xhtml">
<head id="Head1" runat="server">
    <title>Display Customers</title>
</head>
<body>
    <form id="form1" runat="server">
    <div>
        <asp:GridView ID="GridView1" runat="server" 
            AutoGenerateColumns="False"
            RowHeaderColumn="CustomerID"
            Caption="Customers"
            summary="This table shows a list of customers."
            DataKeyNames="CustomerID" DataSourceID="SqlDataSource1">
            <Columns>
                <asp:BoundField DataField="CustomerID" 
                    HeaderText="Customer ID" 
                    InsertVisible="False" ReadOnly="True" 
                    SortExpression="CustomerID" />
                <asp:BoundField DataField="FirstName" 
                    HeaderText="FirstName" 
                    SortExpression="FirstName" />
                <asp:BoundField DataField="MiddleName" 
                    HeaderText="MiddleName" 
                    SortExpression="MiddleName" />
                <asp:BoundField DataField="LastName" 
                    HeaderText="LastName" 
                    SortExpression="LastName" />
            </Columns>
        </asp:GridView>
        <asp:SqlDataSource ID="SqlDataSource1" runat="server" 
            ConnectionString="<%$ ConnectionStrings:AdventureWorksLTConnectionString %>" 
            SelectCommand="SELECT CustomerID, FirstName, MiddleName, 
                LastName FROM SalesLT.Customer">
        </asp:SqlDataSource>
    </div>
    </form>
</body>
</html>


Table GridView affichant des fonctionnalités d'accessibilité

La source de la page restituée montre les fonctionnalités suivantes dans le code HTML généré :

  • Les éléments th ayant des attributs scope pour la ligne d'en-tête sont générés automatiquement.

  • Les éléments thead et tbody sont générés car la propriété HeaderRow est définie dans la méthode Page_Load.

  • L'élément caption est généré car la propriété Caption est définie dans le balisage.

  • Les éléments th avec des attributs scope sont générés pour la colonne Customer ID car la propriété RowHeaderColumn est définie dans le balisage.

  • L'attribut summary est généré car un attribut expando summary est défini dans le balisage.

Utilisation de Dynamic Data ASP.NET

Dynamic Data ASP.NET utilise des contrôles GridView pour afficher des données et des contrôles FormView pour afficher des formulaires dans lesquels vous pouvez mettre à jour les données du tableau.

Les tableaux affichés par les contrôles GridView n'ont pas d'attributs caption, d'éléments thead ni d'éléments tbody. Toutefois, vous pouvez ajouter ces fonctionnalités en créant une page pour chaque table de données dans le dossier CustomPages et en personnalisant le balisage et le code de la page pour le contrôle GridView.

Les formulaires affichés par les contrôles FormView utilisent des tableaux HTML pour la mise en page. Toutefois, ils sont conformes aux directives d'accessibilité car ils ont un sens une fois linéarisés et car les étiquettes de champ sont restituées à l'aide d'éléments label qui ont des attributs for.

Pour plus d'informations sur Dynamic Data ASP.NET, consultez Organigramme des informations relatives à Dynamic Data ASP.NET.

Utilisation de contrôles de données nécessitant des modèles

Pour certains contrôles de données, vous pouvez utiliser des modèles afin de définir explicitement les éléments et attributs HTML dans lesquels les données seront affichées. Les contrôles ASP.NET suivants nécessitent l'utilisation de modèles :

Ces contrôles ne restituent aucun balisage automatiquement. Vous définissez les modèles d'en-tête, de corps et de pied de page pour le contrôle, puis spécifiez le balisage de ces modèles. Si vous souhaitez que l'un de ces contrôles restitue un tableau HTML, vous devez inclure le balisage approprié pour respecter les normes d'accessibilité.

La flexibilité des modèles permet de générer des tableaux complexes. Imaginons par exemple que vous souhaitiez afficher une liste de clients et en-dessous de chaque client un liste de ses adresses (un client peut avoir plusieurs adresses). En d'autres termes, vous souhaitez créer un formulaire maître/détail d'une page. Dans ce cas, vous devez inclure l'attribut headers pour chaque cellule du tableau.

La page ASP.NET de l'exemple suivant crée un formulaire maître/détail d'une page. Cet exemple illustre la manière dont vous pouvez imbriquer un contrôle ListView dans un deuxième contrôle ListView de manière à générer un tableau complexe qui suit les directives d'accessibilité.


<%@ Page Language="C#" %>

<%@ Import Namespace="System.Data" %>
<%@ Import Namespace="System.Data.SqlClient" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<script runat="server">
  private DataTable AddressesTable = new DataTable();

  protected void Page_Load(object sender, EventArgs e)
  {
    SqlDataAdapter AddressesAdapter = new SqlDataAdapter(
        "SELECT SalesLT.CustomerAddress.CustomerID, " +
        "SalesLT.CustomerAddress.AddressID, " +
        "SalesLT.Address.AddressLine1, " +
        "SalesLT.Address.City, SalesLT.Address.StateProvince, " +
        "SalesLT.Address.PostalCode FROM SalesLT.CustomerAddress " +
        "INNER JOIN SalesLT.Address ON " +
        "SalesLT.CustomerAddress.AddressID = SalesLT.Address.AddressID",
        @"Data Source=.\SQLEXPRESS;" +
        @"AttachDbFilename=|DataDirectory|\AdventureWorksLT_Data.mdf;" +
        @"Integrated Security=True;User Instance=True");
    AddressesAdapter.Fill(AddressesTable);
  }

  protected DataView GetAddresses(object customerID)
  {
    DataView view = AddressesTable.DefaultView;
    view.RowFilter = "CustomerID=" + customerID.ToString();
    return view;
  }

  private string GetCustomerHeaderID(ListViewItem item)
  {
    return "hdrCustomer" + item.DataItemIndex.ToString();
  }

  private string GetAddressHeaderID(ListViewItem item)
  {
    return "hdrAddress" +
        ((DataRowView)item.DataItem)["AddressID"].ToString();
  }

  protected string GetColumnHeaderIDs
      (ListViewDataItem item, string columnHeader)
  {
    string customerHeaderID =
        GetCustomerHeaderID
            ((ListViewItem)item.NamingContainer.NamingContainer);

    string addressHeaderID = GetAddressHeaderID(item);

    return string.Format("{0} {1} {2}",
        customerHeaderID, addressHeaderID, columnHeader);
  }

  protected void CustomersListView_ItemDataBound
      (object sender, ListViewItemEventArgs e)
  {
    ListView addressesListView = new ListView();
    addressesListView = e.Item.FindControl("AddressesListView")
        as ListView;
    DataRowView drv = e.Item.DataItem as DataRowView;
    addressesListView.DataSource = GetAddresses(drv["CustomerID"]);
    addressesListView.DataBind();
  }
</script>

<html xmlns="http://www.w3.org/1999/xhtml">

<head id="Head1" runat="server">
  <title>Customers and Addresses</title>
  <style type="text/css">
    .customerRow { background-color: yellow; }
    th { text-align: left; }
  </style>
</head>

<body>
  <form id="form1" runat="server">
  <div>
    <asp:SqlDataSource ID="CustomersSqlDataSource" runat="server" 
    ConnectionString="<%$ ConnectionStrings:AdventureWorksLTConnectionString %>"
    SelectCommand="SELECT CustomerID, 
      FirstName, MiddleName, LastName FROM SalesLT.Customer" />
    <asp:ListView ID="CustomersListView" runat="server" 
      DataKeyNames="CustomerID" DataSourceID="CustomersSqlDataSource"
      OnItemDataBound="CustomersListView_ItemDataBound">
      <LayoutTemplate>
        <table summary="A list of customers with one or more addresses for each customer.">
          <caption>Customers and Addresses</caption>
          <thead>
            <tr>
              <th id="hdrID">ID</th>
              <th id="hdrStreet">Street</th>
              <th id="hdrCity">City</th>
              <th id="hdrState">State</th>
            </tr>
          </thead>
          <tbody>
            <tr id="itemPlaceholder" runat="server"></tr>
          </tbody>
        </table>
      </LayoutTemplate>
      <ItemTemplate>
        <tr class="customerRow">
          <th colspan="4" id='<%# GetCustomerHeaderID(Container) %>'>
            <%# Eval("FirstName") %>
            <%# Eval("MiddleName") %>
            <%# Eval("LastName") %>
          </th>
        </tr>
        <asp:ListView ID="AddressesListView" runat="server">
          <LayoutTemplate>
            <tr id="itemPlaceHolder" runat="server"></tr>
          </LayoutTemplate>
          <ItemTemplate>
            <tr>
              <th id='<%# GetAddressHeaderID(Container) %>'>
                <%# Eval("AddressID") %>
              </th>
              <td headers='<%# GetColumnHeaderIDs(Container, "hdrStreet") %>'>
                <%# Eval("AddressLine1") %>
              </td>
              <td headers='<%# GetColumnHeaderIDs(Container, "hdrCity") %>'>
                <%# Eval("City") %>
              </td>
              <td headers='<%# GetColumnHeaderIDs(Container, "hdrState") %>'>
                <%# Eval("StateProvince") %>
              </td>
            </tr>
          </ItemTemplate>
        </asp:ListView>
      </ItemTemplate>
    </asp:ListView>
  </div>
  </form>
</body>
</html>


Table complexe utilisant des contrôles ListView imbriqués

Dans cet exemple, le contrôle ListView externe répertorie les noms des clients, et le contrôle ListView interne répertorie les adresses correspondantes. Les fonctions GetCustomerHeaderID et GetAddressHeaderID génèrent des valeurs id pour les en-têtes de nom de client et d'ID d'adresse. La méthode GetColumnHeaderIDs génère des valeurs pour l'attribut headers pour les cellules de tableau.

La page ASP.NET illustrée dans l'exemple précédent génère un tableau HTML qui ressemble à ce qui suit :

<table>
  <thead>
    <tr>
      <th id="hdrID">ID</th>
      <th id="hdrStreet">Street</th>
      <th id="hdrCity">City</th>
      <th id="hdrState">State</th>
    </tr>
  </thead>
  <tbody>
    <tr class="customerRow">
      <th colspan="4" id='hdrCustomer0'>Orlando N. Gee</th>
    </tr>
    <tr>
      <th id='hdrAddress832'>832</th>
      <td headers='hdrCustomer0 hdrAddress832 hdrStreet'>
         2251 Elliot Avenue
      </td>
      <td headers='hdrCustomer0 hdrAddress832 hdrCity'>
         Seattle
      </td>
      <td headers='hdrCustomer0 hdrAddress832 hdrState'>
         Washington
      </td>
    </tr>
    <tr class="customerRow">
      <th colspan="4" id='hdrCustomer1'>Keith Harris</th>
    </tr>
    <tr>
      <th id='hdrAddress833'>833</th>
      <td headers='hdrCustomer1 hdrAddress833 hdrStreet'>
         3207 S Grady Way
      </td>
      <td headers='hdrCustomer1 hdrAddress833 hdrCity'>
         Renton
      </td>
      <td headers='hdrCustomer1 hdrAddress833 hdrState'>
         Washington
      </td>
    </tr>
    <tr>
      <th id='hdrAddress297'>297</th>
      <td headers='hdrCustomer1 hdrAddress297 hdrStreet'>
         7943 Walnut Ave
      </td>
      <td headers='hdrCustomer1 hdrAddress297 hdrCity'>
         Renton
      </td>
      <td headers='hdrCustomer1 hdrAddress297 hdrState'>
         Washington
      </td>
    </tr>
    [remaining rows of the table]
  </tbody>
<table>

Notez que chaque balise td contient un attribut headers approprié.

Association de champs d'entrée à des étiquettes

Si vous accédez à un formulaire de page Web via un lecteur d'écran, il peut être difficile d'associer les champs de formulaire aux étiquettes correspondantes. Imaginons par exemple qu'une page Web contienne le formulaire suivant qui affiche des champs d'entrée pour le prénom et le nom d'une personne :

First Name, Last Name: 
<input name="txtFirstName" />
<input name="txtLastName" /></td>

Le texte et les éléments s'affichent tous sur la même ligne et il est évident pour toute personne visualisant l'écran de déterminer quelle zone d'entrée va avec quelle étiquette de champ. Toutefois, le texte « Nom » étant en regard de la zone de texte txtFirstName, il peut être difficile pour l'utilisateur d'un lecteur d'écran d'associer chaque étiquette au champ de formulaire correspondant.

Dans HTML 4.0, vous pouvez résoudre ce problème en utilisant l'élément label pour associer explicitement une étiquette de champ de formulaire à un champ de formulaire. L'exemple suivant montre comment le formulaire précédent doit être écrit en utilisant un élément label :

<label for="txtFirstName">First Name</label>, 
<label for="txtLastName">Last Name</label>: 
<input name="txtFirstName" id="txtFirstName" />
<input name="txtLastName" id="txtLastName" />

Notez que les champs d'entrée incluent un attribut id. La valeur de l'attribut for doit être la valeur d'attribut id d'un champ d'entrée et non sa valeur d'attribut name.

Utilisation des contrôles ASP.NET Label

Le contrôle ASP.NET Label génère normalement un élément span. Toutefois, si vous définissez la propriété AssociatedControlID du contrôle, il restitue un élément label. L'exemple suivant montre comment vous pouvez générer un formulaire accessible avec des contrôles ASP.NET Label et TextBox.

<asp:Label AssociatedControlID="txtFirstName" 
  runat="server">First Name</asp:Label>, 
<asp:Label AssociatedControlID="txtLastName" 
  runat="server">Last Name</asp:Label>:
<asp:TextBox ID="txtFirstName" runat="server" />
<asp:TextBox ID="txtLastName" runat="server" />

Lorsque vous fournissez une étiquette pour un contrôle ASP.NET, vous devez utiliser le contrôle ASP.NET Label à la place de l'élément HTML label. En effet, ASP.NET restitue par défaut une valeur d'attribut HTML id différente de l'ID que vous affectez lorsque vous déclarez un contrôle d'entrée comme un contrôle TextBox. Par conséquent, si vous utilisez un élément label et placez l'ID déclaré du contrôle TextBox dans l'attribut for de l'élément label, l'attribut id et l'attribut for correspondant qui sont restitués peuvent ne pas correspondre. Lorsque vous utilisez le contrôle ASP.NET Label, ASP.NET s'assure automatiquement que l'attribut id restitué correspond à l'attribut for correspondant.

RemarqueRemarque

Vous pouvez également définir la propriété ClientIDMode du contrôle TextBox sur Static. L'attribut id restitué en HTML est alors le même que l'ID déclaré. Pour plus d'informations, consultez Identification du contrôle serveur Web ASP.NET.

Utilisation des contrôles ASP.NET CheckBox et RadioButton

Les contrôles ASP.NET suivants restituent automatiquement des éléments label :

Lorsque vous ajoutez l'un de ces contrôles dans une page, assurez-vous que vous utilisez la propriété Text au lieu d'inclure du texte entre les balises d'ouverture et de fermeture dans le balisage. Par exemple, vous ne devez pas faire ce qui suit :

<asp:CheckBox runat="Server">Include Gift Wrap</asp:CheckBox>

À la place, créez le balisage comme le montre l'exemple suivant :

<asp:CheckBox text="Include Gift Wrap" runat="Server" />

Un élément label avec un attribut for est généré pour l'un de ces contrôles uniquement lorsque vous définissez explicitement sa propriété Text.

Les contrôles ASP.NET rendent automatiquement les fonctionnalités commandées par souris disponibles via le clavier. Cette section explique les différentes façons d'améliorer l'expérience des personnes qui utilisent le clavier :

  • Fourniture de touches d'accès rapide.

  • Spécification d'un ordre de tabulation logique.

Fourniture de touches d'accès rapide.

L'une des façons de faciliter l'utilisation d'un site aux personnes qui ne peuvent pas se servir de la souris est d'inclure des attributs accesskey pour les éléments HTML pouvant recevoir le focus, comme les éléments input ou les liens. Toutefois, l'implémentation de touches d'accès rapide (raccourcis clavier) sans planification précise peut générer des problèmes d'utilisation, tels que :

  • Tous les navigateurs ne prennent pas en charge les touches d'accès rapide.

  • Parmi les navigateurs qui les prennent en charge, les touches d'accès rapide qui sont affectées ne sont pas toujours bien claires pour l'utilisateur. À moins de vous assurer que les touches d'accès rapide sont identifiées, certains utilisateurs peuvent ne jamais découvrir qu'elles sont disponibles.

  • Une touche d'accès rapide définie par une page Web peut en masquer une définie pour un navigateur. L'utilisateur peut être habitué à utiliser la touche d'accès rapide du navigateur et peut être gêné par sa réaffectation à un champ de formulaire ou un lien.

  • Il est d'usage d'utiliser une lettre de l'étiquette de l'élément auquel les touches d'accès rapide sont liées, généralement la première lettre. Mais si vous concevez des pages Web qui seront restituées dans plusieurs langages, ces lettres peuvent être différentes dans chacune des langues. Vous pouvez minimiser ce problème en utilisant uniquement des touches numériques comme touches d'accès rapide, mais ceci limite le nombre des touches d'accès rapide qui peuvent être affectées.

Il y a tellement de limitations associées aux touches d'accès rapide que certains défenseurs de l'accessibilité vont jusqu'à dire qu'elles créent plus de problèmes qu'elles n'en résolvent. Pour plus d'informations, recherchez « access key » sur le site Web WebAIM.

Si vous décidez de définir des touches d'accès rapide, vous pouvez utiliser la propriété AccessKey pour définir l'attribut accesskey pour le contrôle ASP.NET. Lorsque vous associez un contrôle Label à un contrôle d'entrée tel qu'un contrôle TextBox, vous définissez la propriété AccessKey sur le contrôle Label. Pour plus d'informations, consultez Comment : utiliser des contrôles serveur Web Label en tant que légendes.

L'exemple suivant montre l'utilisation des attributs accesskey :


<asp:Label ID="Label1" AssociatedControlID="txtFirstName" 
    AccessKey="f" runat="server">
    <u>F</u>irst Name
</asp:Label>
<asp:TextBox ID="txtFirstName" runat="server" />
<br />
<asp:Label ID="Label2" AssociatedControlID="txtLastName" 
    AccessKey="l" runat="server">
    <u>L</u>ast Name
</asp:Label>
<asp:TextBox ID="txtLastName" runat="server" />


Formulaire de saisie montrant l'utilisation des touches d'accès rapide

Lorsqu'Internet Explorer restitue ce balisage, la première lettre des étiquettes Prénom et Nom est soulignée. La lettre soulignée fournit à l'utilisateur du site Web une indication visuelle des touches d'accès rapide. Il s'agit de la méthode standard pour marquer les touches d'accès rapide dans les applications Microsoft Windows. Si vous exécutez cette page dans Internet Explorer, vous remarquerez aussi que vous ne pouvez plus ouvrir le menu Fichier du navigateur à l'aide de la touche d'accès rapide F car la touche d'accès rapide F de la page est prioritaire.

Spécification d'un ordre de tabulation logique

Il existe une autre méthode pour déplacer le focus sur un élément d'entrée ou un lien qui consiste à utiliser la touche TAB. Les formulaires d'entrée doivent être conçus de telle sorte que l'ordre de tabulation par défaut fournisse un chemin logique à travers les champs d'entrée et les liens hypertexte.

L'ordre de tabulation par défaut ne fonctionne pas bien avec certaines conceptions de page. Supposons par exemple que vous ayez une page avec trois colonnes de champs de formulaire. L'ordre de tabulation logique pourrait être d'accéder avec la touche TAB à tous les champs d'une colonne, puis à la fin de la colonne, de passer à la colonne suivante. Or, l'ordre de tabulation par défaut du navigateur peut être de parcourir tout d'abord une colonne horizontalement, puis de descendre d'une ligne. Dans ce cas, il est difficile pour une personne qui utilise un clavier de remplir les champs dans l'ordre attendu.

Dans de telles cas, la meilleure solution est de reconcevoir la page afin que l'ordre de tabulation par défaut corresponde à l'ordre de tabulation logique. Toutefois, si cela n'est pas pratique, l'ordre de tabulation peut être contrôlé par l'attribut HTML tabindex. Cet attribut peut être placé sur des éléments conçus pour l'entrée utilisateur et sur des liens hypertexte. Spécifier l'ordre de tabulation de cette façon peut être utile pour les utilisateurs qui se servent du clavier pour la navigation dans les formulaires, mais rend la page moins accessibles aux utilisateurs de lecteur d'écran. Les utilisateurs de lecteur d'écran peuvent être désorientés par un ordre de tabulation modifié car le sens de lecture ne correspond pas à l'ordre de tabulation.

Dans les contrôles ASP.NET, vous pouvez utiliser la propriété TabIndex pour définir l'attribut HTML tabindex des éléments HTML générés.

L'exemple suivant ajoute des attributs tabindex à l'exemple accesskey illustré précédemment dans cette rubrique. Ces attributs spécifient que les deux champs d'entrée affichés doivent être le premier et le second élément dans l'ordre de tabulation de la page :

Les normes ARIA autorisent l'attribut tabindex sur tout élément HTML car tout élément peut être défini comme widget RIA (pour plus d'informations sur ARIA, consultez Accessibilité pour les applications Internet riches plus haut dans cette rubrique). ARIA spécifie également que vous pouvez affecter à tabindex la valeur « -1 » afin d'empêcher le navigateur de définir un taquet de tabulation sur un élément qui en possède généralement un. Toutefois, tous les navigateurs ne prennent pas en charge ces fonctionnalités ARIA, et le balisage qui les utilise peut être jugé incorrect dans le service de validation du balisage du W3C.

RemarqueRemarque

Vous pouvez définir le focus initial lorsqu'une page est chargée en utilisant des méthodes comme Page.SetFocus ou en définissant la propriété DefaultFocus pour un formulaire.

La navigation sur un site Web revêt des difficultés particulières pour les utilisateurs d'un logiciel de lecteur d'écran. Cette section explique les tâches suivantes :

  • Fournir un moyen d'ignorer les grands blocs de liens

  • Veiller à ce que le texte des liens soit explicite

  • Diviser les longs formulaires en sections

Fournir un moyen d'ignorer les grands blocs de liens

Peu importe la longueur d'un menu, une personne qui consulte une page Web peut rapidement consulter le menu permettant d'accéder au contenu d'une page. Mais pour une personne qui utilise un lecteur d'écran, écouter toutes les options de menu annoncées peut être une grande perte de temps.

Les contrôles ASP.NET fournissent automatiquement des liens Ignorer la navigation pour résoudre ce problème. Un lien Ignorer la navigation n'est pas visible sur la page mais peut être annoncé par un lecteur d'écran afin de donner à l'utilisateur la possibilité d'ignorer un bloc entier de liens. Les contrôles ASP.NET suivants génèrent automatiquement des liens Ignorer la navigation :

L'exemple suivant montre une page Web ASP.NET contenant un contrôle Menu utilisé pour afficher une liste de liens vers d'autres pages du site Web.


<%@ Page %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html >
<head id="Head1" runat="server">
  <title>Skip Navigation</title>
</head>
<body>
  <form id="form1" runat="server">
  <div>

  <asp:Menu 
    id="Menu1"
    Runat="server">
    <Items>
      <asp:MenuItem Text="Home" NavigateUrl="Home.aspx" />
      <asp:MenuItem Text="Products" NavigateUrl="Products.aspx" />
      <asp:MenuItem Text="Services" NavigateUrl="Services.aspx" />
      <asp:MenuItem Text="About" NavigateUrl="About.aspx" />
    </Items>
  </asp:Menu>

  <hr />

  Here is the main content of the page...

  </div>
  </form>
</body>
</html>


Menu simple, pour afficher le lien de navigation ignoré

Le contrôle de page restitue le code HTML suivant, qui inclut un lien en haut du menu :

<a href="#Menu1_SkipLink"><img alt="Skip Navigation Links"

  src="/WebResource.axd?d=ChXz41GuDxNm-7TcWyCl_w2&amp;t=632495684475122400"

  width="0" height="0" style="border-width:0px;" />

La page n'affiche pas le lien Ignorer la navigation. L'image dans le lien a une largeur et une hauteur nulles. Toutefois, si vous accédez à cette page avec un lecteur d'écran, le texte de remplacement associé à l'image est lu. Une personne non-voyante peut ignorer tous les liens de navigation et accéder directement à la zone de contenu principale du site Web.

Chaque contrôle qui génère des liens Ignorer la navigation possède une propriété SkipLinkText qui détermine le texte du lien Ignorer la navigation. Par défaut, cette propriété est définie sur « Liens Ignorer la navigation ». Si vous définissez cette propriété sur une chaîne vide, le contrôle ne restitue pas le lien Ignorer la navigation.

Pour plus d'informations, recherchez « skip-navigation links » sur le site WebAIM.

Veiller à ce que le texte des liens soit explicite

Un texte complet et précis pour les liens hypertexte est une aide importante à la navigation pour tous les utilisateurs d'une page Web et est une technique importante d'optimisation du moteur de recherche. Toutefois, ceci est également important pour les utilisateurs de lecteurs d'écran. Un lecteur d'écran peut faciliter la navigation dans une page en annonçant tous les liens hypertexte dans l'ordre. Si les liens hypertexte n'ont de sens que par le texte qui les entoure, comme les liens Cliquez ici ou En savoir plus, ils seront incompréhensibles si une personne écoute tous les liens d'une page.

Par exemple, les deux paragraphes de l'illustration suivante remplissent le même objectif pour une personne pouvant visualiser l'écran. Toutefois, le paragraphe situé à droite est plus utile à une personne qui utilise un lecteur d'écran.

Exemple montrant une alternative aux liens « En savoir plus »

Le balisage ASP.NET qui génère ces pages est indiqué dans l'exemple suivant :


<%@ Page %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<script runat="server">

</script>
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title>Meaningful Link Text</title>
    <style type="text/css">
        #leftColumn
        {
            float: left;
            width: 45%;
            border: 1px solid black;
            padding: 10px;
        }

        #rightColumn
        {
            float: right;
            width: 45%;
            border: 1px solid black;
            padding: 10px;
        }
    </style>
</head>
<body>
    <form id="form1" runat="server">
    <div id="leftColumn">
        <strong>Providing Skip-Navigation Links</strong><br />
        With a simple modification to a navigation bar, 
        you can dramatically improve the
        accessibility of your Web pages.
        <asp:HyperLink ID="HyperLink1" runat="server" 
            NavigateUrl="~/Default.aspx">
            Read more.
        </asp:HyperLink>
        <br />
        <br />
        <strong>Providing Meaningful Link Text</strong><br />
        Providing complete and accurate text for hyperlinks 
        is an important navigational
        aid for all users of a Web page and is an important 
        search engine optimization technique.
        However, it is also important for users of screen readers.
        <asp:HyperLink ID="HyperLink3" runat="server" 
            NavigateUrl="~/Default.aspx">
            Read more.
        </asp:HyperLink>
    </div>
    <div id="rightColumn">
        <asp:HyperLink ID="HyperLink2" runat="server" 
            NavigateUrl="~/Default.aspx">
            <strong>Providing Skip-Navigation Links</strong>
        </asp:HyperLink><br />
        With a simple modification to a navigation bar, 
        you can dramatically improve the
        accessibility of your Web pages.
        <br />
        <br />
        <asp:HyperLink ID="HyperLink4" runat="server" 
            NavigateUrl="~/Default.aspx">
            <strong>Providing Meaningful Link Text</strong>
        </asp:HyperLink><br />
        Providing complete and accurate text for hyperlinks 
        is an important navigational
        aid for all users of a Web page and is an important 
        search engine optimization technique.
        However, it is also important for users of screen readers.
    </div>
    </form>
</body>
</html>


Diviser les longs formulaires en sections

Si une page contient un long formulaire, il peut être bénéfique de diviser le formulaire en sections, tout particulièrement en cas d'utilisation d'un lecteur d'écran. Vous pouvez diviser un formulaire en section à l'aide de l'élément fieldset, comme indiqué dans l'exemple suivant :


<form id="form1" runat="server">
<div>
    <div>
        <fieldset>
            <legend>Contact Information</legend>
            <br />... form fields ...<br /><br />
        </fieldset>
        <fieldset>
            <legend>Payment Information</legend>
            <br />... form fields ...<br /><br />
        </fieldset>
    </div>
</form>


Formulaire divisé en sections à l'aide de l'élément fieldset

Ce formulaire est divisé en deux sous-formulaires à l'aide des éléments fieldset. L'élément legend est utilisé pour indiquer l'objet des sous-formulaires. La plupart des navigateurs affichent une bordure pour séparer visuellement ces zones. Toutefois, l'élément fieldset est là pour créer des sous-formulaires, pas pour fournir une bordure. Si l'apparence visuelle par défaut de l'élément fieldset ne vous plaît pas, vous pouvez la modifier via une règle de feuille de style, ou vous pouvez masquer l'élément à l'aide des attributs CSS display ou visibility.

Dans ASP.NET, vous pouvez utiliser le contrôle Panel pour créer des sous-formulaires. Si vous définissez la propriété GroupingText du contrôle Panel sur une chaîne, le contrôle restitue un élément div qui contient un élément fieldset pour le contenu et un élément legend contenant la chaîne que vous avez utilisée dans la propriété GroupingText.

Vous pouvez identifier la langue d'une page en définissant l'attribut lang sur l'élément html. Si vous utilisez des pages maîtres, vous pouvez définir cet attribut dans une page maître pour toutes les pages de contenu liées à cette page maître. L'exemple suivant affiche une balise html pour une page écrite en Anglais :

<html xmlns="http://www.w3.org/1999/xhtml" lang="en-us">

Si une page omet l'attribut lang, le lecteur d'écran suppose généralement que la page est écrite dans la langue définie pour le navigateur. Par conséquent, il est particulièrement important de définir cet attribut pour les sites Web ayant un contenu multilingue (certaines pages dans une langue, d'autres dans une langue différente) ou les sites Web qui seront utilisés par des personnes dont la langue natale est différente de la langue du site Web.

Lorsque vous créez une page Web à l'aide de Visual Studio, les modèles qui créent de nouvelles pages Web ou des pages maîtres créent l'élément html sans élément lang. C'est à vous de décider si vous voulez ajouter l'élément lang. Si vous le faites, IntelliSense fournit une liste des codes de langue et de culture disponibles.

Une page Web qui se comporte de manière imprévisible peut être difficile à utiliser, d'autant plus pour les utilisateurs d'un lecteur d'écran. Le principe de base est que si une action utilisateur, telle que le déplacement du focus ou un clic sur un élément, provoque des modifications significatives de la page Web, l'utilisateur doit être informé de ce à quoi il doit s'attendre.

Par exemple, dans un questionnaire, la réponse à une question peut afficher dynamiquement des questions supplémentaires. Certaines pages Web gèrent ceci en affichant ou masquant dynamiquement une section du formulaire lorsque l'utilisateur clique sur un élément de liste déroulante. Si une page Web ASP.NET implémente ce comportement à l'aide de la propriété AutoPostBack, la page Web entière peut être actualisée. Dans ce cas, une personne qui utilise un navigateur graphique pourra voir son écran scintiller au moment de l'ajout d'une section supplémentaire. Toutefois, une personne qui utilise un lecteur d'écran devra peut-être réécouter l'ensemble du formulaire. Dans un cas comme dans l'autre, l'expérience utilisateur sera meilleure si l'étiquette ou la description de la liste déroulante indique clairement ce qui va se passer en cas de clic. Vous pouvez faire en sorte que ces mises à jour de page soient moins intrusives en utilisant un script client ou Ajax afin que le navigateur ne mette à jour qu'une partie de la page. Toutefois, la page doit toujours indiquer clairement le comportement auquel peut s'attendre l'utilisateur.

L'une des manières d'aider les utilisateurs à savoir quels champs sont obligatoires consiste à afficher un astérisque (*) en regard des champs obligatoires ou à restituer leurs étiquettes dans une police en gras. Si vous utilisez cette convention, vous devez expliquer sur la même page ce que signifie cette convention. Évitez de marquer les champs obligatoires ou de signaler les champs contenant une erreur uniquement en modifiant la couleur de police. Certaines personnes peuvent ne pas discerner certaines couleurs, comme le rouge et le noir.

Pour aider les utilisateurs à corriger les erreurs, fournissez un texte expliquant le genre d'entrée qui est attendu. Lorsque vous utilisez des contrôles de validateur ASP.NET, vous devez toujours spécifier des messages d'erreur explicites dans les propriétés Text et ErrorMessage.

Note de sécuritéNote de sécurité

Lorsque vous créez des messages d'erreur, veillez à ne pas fournir d'informations que les utilisateurs malveillants pourraient utiliser dans une attaque Web. Pour plus d'informations, consultez Méthodes de sécurité de base pour les applications Web.

Les pages Web accessibles doivent fonctionner correctement dans autant de navigateurs et de versions de navigateur que possible. Le critère de succès 4.1.1 de WCAG 2.0 stipule que la page doit être composée de code HTML valide conforme aux règles suivantes :

  • Les éléments ont des balises de début et de fin complètes.

  • Les éléments sont imbriqués conformément à leurs spécifications. Par exemple, il est acceptable d'avoir une structure comme <h1><h2></h2></h1>, mais pas une structure <h2></h2> seule sans être précédée de <h1>. De la même manière, il n'est pas acceptable de créer une hiérarchie désordonnée, telle que <h1><h3><h2><h2/></h3></h1> ou de spécifier des balises de fin sans balise de début, comme <h1><h2></h1></h2>.

  • Les éléments ne contiennent pas d'attributs dupliqués.

  • Les ID des éléments sont uniques.

Par défaut, les contrôles ASP.NET génèrent du code HTML conforme à ces règles. Toutefois, vous devez faire bien attention à ne pas créer du code HTML non valide lorsque vous utilisez des modèles de contrôle pour spécifier du code HTML personnalisé. De même, lorsque vous utilisez le paramètre Static de la propriété ClientIDMode, vous devez éviter de créer des attributs id dupliqués.

RemarqueRemarque

Dans certains cas, ASP.NET génère des balises d'auto-fermeture au lieu de balises de début et de fin distinctes (par exemple, <input type="text" /> au lieu de <input type="text"></input>). Les validateurs HTML qui appliquent les règles HTML 4.01 peuvent marquer ces éléments comme mal fermés. Toutefois, les balises de fermeture automatique sont prises en charge par tous les navigateurs majeurs, sont valides dans les spécifications XHTML et HTML 5 et sont gérées correctement par logiciel de technologie d'assistance

Les pages Web accessibles doivent également s'assurer que tous les composants de l'interface utilisateur d'une page peuvent fonctionner efficacement avec la technologie d'assistance. Le critère de succès 4.1.2 de WCAG 2.0 stipule que la technologie d'assistance doit être en mesure de déterminer le type, les propriétés et l'état de tous contrôles d'une page. Par définition, tous les éléments HTML standard sont accessibles. Toutefois, les contrôles côté client qui redéfinissent le rôle des éléments HTML ne sont généralement pas conformes à cette norme. C'est ce problème qu'ARIA essaie de résoudre. Comme indiqué précédemment, ARIA est un projet en cours, et ce document ne fournit pas d'informations détaillées sur l'implémentation d'ARIA dans les pages Web ASP.NET.

Visual Studio (contrairement à Visual Web Developer Express) inclut un vérificateur d'accessibilité. Pour exécuter cet outil, sélectionnez Vérifier l'accessibilité dans le menu Outils. La boîte de dialogue Vérification de l'accessibilité s'affiche :

Boîte de dialogue Validation de l'accessibilité

Pour les projets de site Web (contrairement aux projets d'application Web), vous pouvez également spécifier que le vérificateur d'accessibilité doit être exécuté chaque fois que vous générez le site Web. L'onglet Générer de la boîte de dialogue Pages de propriétés contient des cases à cocher que vous pouvez utiliser pour intégrer la vérification de l'intégrité au processus de génération, comme indiqué dans l'illustration suivante :

Boîte de dialogue Pages de propriétés

Le vérificateur d'accessibilité vous donne la possibilité de valider un site Web en fonction des points de contrôle de Priorité 1 de WCAG 1.0, des points de contrôle de Priorité 2 de WCAG 1.0 ou des directives de la Section 508.

Les résultats de la validation d'un site Web peuvent être affichés en ouvrant la fenêtre Liste d'erreurs (sélectionnez l'option de menu Affichage, Autres fenêtres, Liste d'erreurs).

Le vérificateur d'accessibilité vous permet également de créer une liste de contrôle manuelle des problèmes d'accessibilité. Si vous sélectionnez cette option, une liste standard d'éventuels problèmes d'accessibilité est affichée dans la fenêtre Liste d'erreurs chaque vous que vous validez un site Web. Cette liste de contrôle contient des problèmes qui ne peuvent pas être validés automatiquement par le vérificateur d'accessibilité.

Le vérificateur d'accessibilité est un outil utile pour vous aider à trouver les problèmes qui pourraient sinon vous échapper. Toutefois, vous devez avoir conscience de ses limites. L'absence de messages d'erreur ne signifie pas qu'un site Web suit correctement les directives d'accessibilité, et les messages d'erreur signalés peuvent ne pas s'appliquer à votre site Web.

Les limites du vérificateur d'accessibilité sont les suivantes :

  • De nombreuses directives d'accessibilité requièrent un jugement humain et ne peuvent pas être vérifiées automatiquement. Par exemple, un outil automatisé peut vérifier qu'un attribut alt est présent sur une balise img. En revanche, il ne peut pas vérifier que le texte de l'attribut alt convient à l'image.

  • Le vérificateur d'accessibilité valide les directives WCAG 1.0, et non les directives WCAG 2.0. WCAG 1.0 a plus de dix ans et de nombreuses directives d'accessibilité ont changé. Certains sites peuvent avoir l'obligation légale de suivre des directives plus anciennes. Si ce n'est pas votre cas, vous devez connaître les nouvelles directives et être capable de déterminer quels messages du vérificateur d'accessibilité se rapportent aux directives plus anciennes.

  • Le vérificateur d'accessibilité valide uniquement le code HTML. Il ne valide pas le balisage ASP.NET. Par exemple, il signale un attribut alt manquant sur un élément img. Toutefois, il ne signalera pas une propriété AlternateText manquante sur un contrôle Image.

Ajouts de la communauté

AJOUTER
Microsoft réalise une enquête en ligne pour recueillir votre opinion sur le site Web de MSDN. Si vous choisissez d’y participer, cette enquête en ligne vous sera présentée lorsque vous quitterez le site Web de MSDN.

Si vous souhaitez y participer,
Afficher:
© 2014 Microsoft