• Résumé
• Statut de ce document
• Introduction
• Un design accessible
• Organisation des directives
• Conventions du document
• Priorités
• Conformité
• Directive 1 : Fournir des alternatives équivalentes au contenu audio et visuel
• Directive 2 : Ne pas se reposer sur la couleur uniquement
• Directive 3 : Utilisez les balises HTML et les feuilles de style et faites le proprement
• Directive 4 : Clarifier l'usage du langage naturel
• Directive 5 : Créer des tableaux qui apparaissent de manière élégante
• Directive 6 : S'assurer que les pages utilisant les dernières technologies apparaissent de manière agréable
• Directive 7 : S'assurer du contrôle par l'utilisateur des changements de contenu dans le temps
• Directive 8 : S'assurer de l'accessibilité directe des interfaces utilisateur  imbriquées.
• Directive 9 : Concevoir le design pour l'indépendance vis à vis du dispositf
• Directive 10 : Utiliser des solutions temporaires
• Directive 11 : Utiliser les directives et les technologies W3C
• Directive 12 : Fournir de l'information sur le contexte et l'orientation
• Directive 13 : Fournir des mechanismes de navigation clairs
• Directive 14 : S'assurer que tous les documents sont clairs et simples

Ces directives expliquent comment rendre le contenu des pages web accessible aux internautes présentant un handicap. Ces directives  s'adressent à tous les développeurs de sites web (auteurs  de pages et designers de sites) et à tous les concepteurs d'outils de  développement. L'objectif principal de ces directives étant de  promouvoir l'accessibilité. Cependant, suivre ces directives rendra aussi  le contenu des sites plus accessible à tous les utilisateurs,  quel que soit le navigateur  qu'ils utilisent (cad: navigateur d'ordinateur de bureau, navigateur vocal,  téléphone mobile, ordinateur de voiture, etc.) ou les contraintes  sous lesquelles ils les utilisent (cad : environnement bruyant, pièces  sous ou sur-eclairées, besoin d'avoir les mains libres, etc.). Suivre  ces directives aidera également les internautes à trouver plus  rapidement l'information sur le web . Elles ne tentent pas de dissuader les  développeurs d'utiliser des images, des vidéos, etc. mais plutôt  d'expliquer comment rendre le contenu multimedia plus accessible à un  large public.

Ceci est un document de référence qui concerne des principes d'accessibilité et des idées de design. Certaines des stratégies proposées dans ce document concernent des problèmes d'internationalisation du web et d'accès à distance. Cependant, cette recommandation se concentre sur l'accessibilité en général et ne répond pas entièrement à tous les problèmes rencontrés par les groupes de travail du W3C. Nous vous prions de consulter le et le W3C Internationalization Activity home page pour plus d'information.

L'information contenue dans ce document est censée être pérenne et, par conséquent, n'apporte pas d'information spécifique à propos des supports de navigation pour des technologies différentes étant donné que cette information change très vite. En contrepartie, le site < Web Accessibility Initiative (WAI) apporte cette information.

Les "Directives pour une meilleure accessibilité du contenu des  sites 1.0" fait partie d'une série de directives d'accessibilité  publiées par le groupe de travail Web  Accessibility Initiative . Ces directives incluent également   les sections User Agent Accessibility Guidelines and Authoring Tool Accessibility Guidelines.

[retour à la table des matières]

Ce document à été révisé par les membres du W3C ainsi que d'autres parties intéressées et a été approuvé par le directeur en tant que Recommandation W3C. C'est un document pérenne qui peut être utilisé comme référence ou cité comme norme pour d'autres documents. Le rôle du W3C en faisant cette recommandation est d'attirer l'attention sur des fonctionnalités spécifiques, afin d'accroître l'universalité du web.

Une liste des recommandations W3C actuelles ainsi que d'autres documents techniques  à http://www.w3.org/TR .

Ce document a été produit dans le cadre des W3C Web Accessibility Initiative Un "groupe de travail" Web Content Guidelines Working Group a été crée dont les résultats sont commentés dans le Working Group charter

[retour à la table des matières]

A l'intention de ceux qui ne sont pas familiers avec les questions d'accessibilité concernant  le design de pages web, considérez que de nombreux utilisateurs  opèrent dans un contexte différent du vôtre.

• Ils peuvent ne pas être  capables de voir, entendre, bouger ou tout simplement traiter  certains types d'information aussi facilement.
• Ils peuvent avoir des difficultés à lire ou à comprendre le texte.
• Ils peuvent ne pas être capables d'utiliser un clavier ou une souris.
• Ils peuvent avoir un ecran qui ne présentent que le texte, un petit écran, ou  une connexion internet lente.
• Ils peuvent ne pas parler ou comprendre parfaitement la langue dans laquelle le document est ecrit.
• Ils peuvent être dans une une situation où leurs yeux, oreilles, ou mains sont occupées ou dérangées. (ex: en conduisant, en  travaillant dans un environnement bruyant, etc.).
• Ils peuvent posséder une ancienne version  d'un navigateur, un navigateur entièrement différent, un navigateur vocal, ou un système d'exploitation différent.

Les développeurs doivent considérer ces différentes situations  au moment du design des pages, car chaque choix d'accessibitlité bénéficie  généralement à plusieurs groupes de handicapés à  la fois et à la communauté du web dans son ensemble. Par exemple,  en utilisant des "feuilles de style"  pour  contrôler les styles de police et éliminer l'élement "<font>",  Les développeurs HTML auront un meilleur contrôle sur leur pages,  en rendant ces mêmes pages accessibles à ceux qui voient mal, et  en partageant les feuilles de style, on réduit bien souvent le temps  de téléchargement des pages pour tous les utilisateurs. 

Les directives étudient les problèmes d'accessibilité  et proposent des solutions de design. Elles considèrent des scénarios  typiques (comme l'exemple des styles de police) qui peuvent poser des problèmes  à des utilisateurs ayant certains handicaps. Par exemple, la première  directive explique comment les développeurs peuvent rendre les images  accessibles. Certains utilisateurs peuvent ne pas être en mesure de voir  les images, d'autres peuvent utiliser de navigateurs qui ne lisent que le texte,  d'autres auront peut-être éteint la fonction image afin d'accélérer  le téléchargement. Les directives ne suggèrent pas d'éviter  les images pour améliorer l'accessibilité. En revanche, elles  expliquent que proposer un équivalent texte de l'image la rendra plus  accessible. 

Comment un équivalent texte rend-il l'image accessible? Les deux mots,  "texte" et "équivalent" sont importants

• Le contenu du texte  peut être présenté sous forme de voix synthétisée, de  braille, ou de texte visuel. Chacun de ces trois  mécanismes fait appel à un sens différent (ouïe, toucher, vue)  -- rendant l'information accessible à des groupes représentant divers handicaps  sensoriels ou autres.
• Afin d'être utile, le texte doit véhiculer la même fonction  ou le même but que l'image. Par exemple, considérez un équivalent  texte pour une photo de la terre vue depuis l'espace.  Si le but de l'image  est essentiellement décoratif, un texte du type "Photo de la terre  vue depuis l'espace" pourra remplir cette fonction. Si le but de la photographie  est d'illustrer une information spécifique sur la géographie  de la planète, alors l'équivalent texte devra transmettre cette  information. Si la photo a été faite pour dire à l'utilisateur  de cliquer sur l'image pour obtenir de l'information sur la terre, l'équivalent  texte serait "Information sur la terre". On considérera comme  équivalent texte un élément textuel remplaçant  une image tout en gardant la même signification, le même but.

Remarquez que, en plus de profiter aux utilisateurs présentant des handicaps, les équivalents texte peuvent aider les utilisateurs à trouver les pages plus vite, car les moteurs de recherche peuvent utiliser le texte alternatif quand ils indexent les pages.

Alors que les développeurs doivent donner des équivalents texte  à leurs images et le reste du contenu multimédia, c'est la responsabilité  des navigateurs (cad, navigateurs et autres technologies comme les synthétiseurs  vocaux, les appareils en braille, etc.) de présenter l'information aux  utilisateurs.

Les équivalents à caractère non texuel, censés remplacé du texte  (icônes, discours pré-enregistrés, vidéo d'une personne  traduisant le texte en langage des sourds, peuvent rendre les documents accessibles  à des gens ayant des difficultés à accéder au texte  écrit, des problèmes de compréhension, ou atteints de surdité.  Ils pourront aussi aider les analphabètes.  Une description  auditive d'un élément textuel ou multimédia est un exemple  d'équivalent non textuel à une information visuelle.

[retour à la table des matières]

Les directives concernent deux questions générales: Assurer une transformation de qualité, et rendre le contenu compréhensible et navigable.

Assurer une transformation élégante

En suivant ces directives, les développeurs peuvent créer des  pages qui se transforment de manière élégante. Des pages  qui se transorment de manière élégante restent accessibles  quelles que soient les contraintes décrites dans l'introduction, ce qui  inclut les handicaps physiques, sensoriels et cognitifs, les contraintes de  travail, et les barrières technologiques. Voici quelques clés  pour créer des pages qui se transorment de manière élégante:

• Séparer la structure de la présentation (ceci réfère  à la différence entre le contenu, la structure et la présentation).
• Fournir du texte (inclus les équivalent textes). Le texte peut être  présenté de telle manière qu'il soit accessible à  tous les appareils de navigation .
• Créer des documents qui fonctionnent même si l'utilisateur  ne peut pas entendre et/ou voir. Fournir de l'information qui sert les mêmes  buts ou fonctions qu'un support audio ou vidéo adapté à  tous les sens. Ceci ne veut pas dire qui'il faut créer une autre version  enregistrée de tout un site pour le rendre accessible aux aveugles.  Les aveugles peuvent utiliser des sythétiseurs vocaux pour entendre  toute l'information textuelle d'une page. 
• Créer des documents qui ne reposent pas sur un seul type de hardware.  Les pages doivent être utilisables par des gens n'ayant pas de souris,  avec des petits écrans, des écrans à faible résolution,  écrans noir et blanc, pas d'écran, seulement avec du son ou  seulement avec du texte etc.

Le thème de la transformation élégante est traité dans les directives 1 à 11.

Rendre le contenu compréhensible et navigable

Les développeurs doivent rendre le contenu compréhensible et  navigable. Ce qui veut dire non seulement rendre le langage clair et simple,  mais aussi fournir des méchanismes compréhensibles pour naviguer  dans et entre les pages. Fournir des outils de navigation et d'orientation à  l'intérieur des pages maximisera l'accessibilité. Tout les utilisateurs  ne peuvent pas utiliser des éléments visuels comme les images  mapées, les barres de défilement, les frames, ou tous les éléments  graphiques qui guident les utilisateurs de navigateurs graphiques d'ordinateurs  de bureau. Les utilisateurs perdent aussi de l'information contextuelle lorsqu'ils  ne voient qu'une portion d'une page, ou qu'ils accèdent à la page  mot par mot (synthèse vocale ou braille), ou section par section (petit  affichage, ou affichage élargi). Sans information sur l'orientation,  les utilisateurs peuvent ne pas être capables de comprendre de grands  tableaux, des listes, ou des menus.

Ce thème est traité dans les directives 12 à 14.

[retour à la table des matières]

Ce document comprend 14 directives, ou principes généraux d'accessibilité. Chaque directive inclut:

• Le numéro de la directive.
• L'objectif de la directive.
• Les liens de navigation de la directive. 3 liens permettent la navigation  vers la directive suivante (flèche rouge vers la droite), la directive  précédente (flèche rouge vers la gauche), ou la position  de la directive dans la table des matières (flèche rouge vers  le haut).
• l'objectif que sous-tend la directive et les groupes d'utilisateurs qui  en bénéficient.

[retour à la table des matières]

Les conventions éditoriales suivantes sont utilisées dans ce document :

• Les noms d'éléments sont en majuscules
• Les noms d'attributs sont cités en minuscules

[retour à la table des matières]

A chaque point de contrôle est associé, par le groupe de travail, un niveau de priorité basé sur l'impact du point de contrôle sur l'accessibilité.

[Priorité 1] 
        Un développeur doit satisfaire à ce point de contrôle. Sans quoi un ou plusieurs groupes ne pourront pas accéder à l'information du document. Satisfaire à ce point de contrôle est une exigence de base pour utiliser des documents web. 
[Priorité 2]
        Un développeur devrait satisfaire à ce point de contrôle. Sans quoi un ou plusieurs groupes auront  des problèmes à accéder à l'information dans le document. Satisfaire à  ce point de contrôle améliorera sensiblement l'accès aux documents web.
[Priorité 3]
        Un développeur pourra satisfaire à ce point de contrôle. Sans quoi un ou plusieurs  groupes pourront avoir des problèmes pour accéder à l'information dans le document. Satisfaire à ce point de contrôle améliorera l'accès aux documents web.

Certains points de contrôle ont un degré de priorité qui peut changer sous certaines conditions.

Cette section défini 3 niveaux de conformité à ce document.

• Niveau de  Conformité "A". Tous les points de contrôle de priorité 1 sont satisfaits.
• Niveau de Conformité "Double A".Tous les points de contrôle de priorité 1 et 2 sont statisfaits
• Niveau de Conformité "Triple A".Tous les points de contrôle de priorité 1, 2 et 3 sont  satisfaits

Note. Les niveaux de conformité sont épelés en texte afin qu'ils soient compris vocalement.

Les déclarations de conformité à ce document doivent utiliser l'un des deux formats suivants.

Format 1, spécifier:

• Le titre des directives: "Directives d'accessibilité du contenu des sites 1.0"
• L'URL des directives: http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505
• Le niveau de conformité satisfait: "A", "Double-A", ou "Triple-A".
• L'étendue couverte par la déclaration (cad.  page, site, ou une portion définie d'un site).

Exemple de Format 1:

Cette page est conforme aux "Directives d'accessibilité du contenu des sites  1.0" de W3C, disponible au  http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505, niveau Double-A.

Format 2: Inclure, sur chaque déclaration de conformité de page, une des 3 icones de conformité fournis par W3C et relier l'icone à l'explication appropriée de la declaration du W3C. L'information sur les icones et comment les insérer est disponible [WCAG-ICONS].

[retour à la table des matières]

Fournir du contenu qui, présenté à l'utilisateur, véhicule le même sens ou le même but qu'un contenu audio ou visuel.

Même si les gens ne peuvent pas lire les images, les films, les sons  ou les applets directement, ils sont cependant susceptibles d'utiliser des pages  qui incluent une information équivalente au contenu visuel ou audio.  Cette information équivalente doit servir le même but que le contenu  visuel ou audio. C'est à dire que l'équivalent texte d'une image  représentant une flèche vers le haut qui dirige vers la table  des matières devra être "Aller à la table des matières".  Dans certains cas, un équivalent devra également décrire  l'apparence du contenu visuel (ex: pour des graphiques compliqués, des  diagrammes etc.) ou le son du contenu audio.

Cette directive met l'accent sur l'importance de fournir des équivalents  texte du contenu non textuel (images, audio, video). Le  pouvoir des équivalents texte réside dans leur capacité  à être affichés sous toutes les formes, avec toutes les  technologies. Le texte peut être facilement transcrit par des synthétiseurs  vocaux ou par l'affichage de type braille, et peuvent être présentés  visuellement (dans toutes les tailles) et sur tous les supports. Le synthétiseur  vocal est essentiel pour les aveugles ou les analphabètes. Le braille  est essentiel pour ceux qui sont à la fois sourd et aveugle. Enfin, le  fait d'avoir du texte à l'écran profite autant aux sourds qu'à  tous les autres utilisateurs du web.

Fournir des équivalents non textuels (images, vidéos, audio) au texte bénéficie également à certains utilisateurs, particulièrement les gens qui éprouvent des difficultés à lire. Dans les films ou les présentation visuelles, il est important d'accompagner l'information d'un soutien audio qui véhicule le même message. A moins que des descriptions verbales ne soient fournies, les gens qui ne peuvent pas voir le contenu visuel ne pourront pas le percevoir.

[retour à la table des matières]

S'assurer que les textes et graphiques sont compréhensibles lorsqu'ils sont vus en noir et blanc.

Si c'est seulement la couleur qui est utilisée pour véhiculer  l'information, les gens qui ne peuvent pas différencier certaines couleurs,  ou ceux qui utilisent du materiel en noir et blanc ou à affichage non  visuel ne recevront pas l'information. Quand les couleurs de premier plan et  d'arrière plan sont trop proches, elle peuvent ne pas fournir un contraste  suffisant quand elles sont vues par des affichages monochromes ou par des gens  avec divers déficits de la vue.

[retour à la table des matières]

Les documents HTML avec les bons éléments structurels. Controlez la présentation avec des feuilles de style plutôt qu'avec des éléments de présentation et des attibuts

Utiliser les balises de manière incorrecte -- pas en accord avec les  spécifications-- gène l'accessibilité. Mal utiliser les  balises pour un effet de présentation (utiliser un tableau pour le layout  ou un titre pour changer la taille de la police) rend difficile la navigation  et la compréhension de l'organisation de la page aux utilisateurs possédant  un logiciel spécialisé. De plus, utiliser des balises de présentation  plutôt que des balises structurelles pour véhiculer la structure  (ex: construire quelquechose qui ressemble à un tableau de données  avec un élément HTML PRE) rend la page difficilement intelligible  avec d'autres dispositifs.

Les développeurs peuvent être tentés de mal utiliser des concepts qui obtiennent l'effet de formattage désiré sur les navigateurs plus anciens. Ils doivent savoir que ces pratiques posent des problèmes d'accessibilité et doivent se demander si l'effet de formattage est important au point de rendre le document inaccessible à certains utilisateurs.

D'un autre coté, les développeurs ne doivent pas sacrifier les  balises appropriées parce que certains navigateurs ne les traitent pas  correctement. Par exemple, il est approprié d'utiliser l'élément  <TABLE> en HTML pour donner de l'information relative à un tableaumême  si certains vieux navigateurs ne supportent pas le texte mis côte à  côte correctement. Utiliser l'élément <TABLE> correctement  et créer des des tableaux qui apparaissent de manière élégante  (se référer à la directive 5) rend le navigateur capable  d'afficher d'autres tableau que les grilles en deux dimensions.

[retour à la table des matières]

Utiliser des balises qui facilitent la prononciation ou l'interprétation de texte abrégé ou en langue étrangère.

Quand les développeurs font intervenir des changements du langage naturel  dans un document, les sythétiseurs vocaux ou les dispositifs en braille  peuvent automatiquement basculer vers le nouveau langage, rendant le document  plus accessible aux utilisateur multilingues. Les développeurs devraient  identifier le langage naturel prédominant du contenu d'un document (avec  les balises ou les titres HTTP). Ils devraient également fournir des  formes complètes des abréviations et acronymes.

En plus de supporter certaines technologies, le 'balisage' du langage naturel permet aux moteurs de recherche de trouver les mots clé dans le langage désiré. Il améliore également la lisibilité du web pour tous, en incluant ceux subissant un handicap.

Quand les abréviations et les changements de langage naturel ne sont  pas identifiés, il pourront être indéchiffrables par les  sythétiseurs vocaux ou par les traducteurs en Braille.

[retour à la table des matières]

S'assurer que les tableaux ont les balises nécessaires pour être lus par tous les outils de navigation.

Les tableaux ne devraient être utilisés que pour montrer de l'information  qui doit être mise dans un tableau (tableaux de données).  Les développeurs doivent éviter de s'en servir comme outil de  mise en page. Les tableaux utilisés pour une autre finalité présentent  également des problèmes spécifiques aux synthétiseurs vocaux.

Certains agents de navigation permettent aux utilisateurs de naviguer entre les cellules du tableau et d'accéder au titre et à d'autres informations sur le tableau. A moins qu'ils ne soient balisés correctement, ces tableaux  n'apporteront pas l'information appropriée à tous les navigateurs.

[retour à la table des matières]

S'assurer que les pages sont accessibles même si les technologies les plus récentes ne sont pas disponibles ou éteintes.

Même si les développeurs sont encouragés à utiliser des nouvelles technologies qui résolvent les problèmes posés par les technologies existantes, ils doivent savoir comment faire pour que leurs pages fonctionnent encore avec les anciens navigateurs ou pour les utilisateurs qui choisissent de ne pas utiliser certaines fonctionnalités.

[retour à la table des matières]

S'assurer que les objets ou pages qui bougent, clignotent, scrollent, ou se mettent à jour automatiquement puissent être arrêtés ou suspendus.

Certaines personnes avec des handicaps visuels ou cognitifs sont incapables  de lire du texte qui bouge, le mouvement peut aussi causer une distraction telle  que des utilisateurs ne peuvent plus lire le reste de la page. Les synthétiseurs  vocaux ne peuvent pas lire le texte en mouvement. Les personnes avec certaines  incapacités physiques peuvent ne pas être capables de bouger de  manière assez précise pour interagir avec des objets en mouvement.

[retour à la table des matières]

S'assurer que l'interface utilisateur suit certains principes d'accessibilité: accès à la fonctionnalité indépendant de l'agent utilisé, utilisable depuis n'import quel clavier, compatibilité audio etc.

Quand un objet est lié à sa propre interface, l'interface doit être accessible. Si l'interface n'est pas accessible, une solution d'accessibilité alternative doit être fournie.

Note. Pour plus d'informations information sur les interfaces accessibles, consultez le User Agent Accessibility Guidelines ([WAI-USERAGENT]) et le Authoring Tool Accessibility Guidelines ([WAI-AUTOOL]).

< [retour à la table des matières]

Utiliser des spécificités qui rendent possible l'activation des éléments via plusieurs dispositifs d'input différents.

L'acces "indépendant du dispositif" signifie que l'utilisateur  peut interagir avec le navigateur ou le document avec son dispositif (input  ou output) préféré (souris, clavier, voix, etc). Si, par  exemple, un bouton de formulaire ne peut être activé que par un  dispositif de pointage, quelqu'un qui utilisera une page sans vue exacte, un  input vocal, ou un clavier ne pourra pas utiliser le formulaire.

Note. Fournir des équivalents texte pour des images  mapées ou des images utilisées comme liens permet aux utilisateurs  d'interagir avec elles sans dispositif de pointage.

Généralement, les pages qui permettent une interaction clavier sont aussi accessibles à travers un input vocal ou une interface de type "ligne de commande".

[retour à la table des matières]

Utiliser des solutions d'accessibilité temporaires pour que toutes les technologies fonctionnent.

Par exemple, les anciens navigateurs ne permettent pas à l'utilisateur  de naviguer vers les champs de formulaire vide. Les anciens synthétiseurs vocaux lisent les listes de liens consécutifs comme un seul lien. Ces éléments actifs sont donc difficiles d'accès (voire impossible).  De plus, changer la fenêtre active ou faire apparaître une nouvelle  fenêtre peut considérablement désorienter l'utilisateur  qui peut ne pas se rendre compte que c'est arrivé.

[retour à la table des matières]

Utiliser les technologies W3C (selon les spécifications) et suivre les directives d'accessibilité. Là où il est  impossible d'utiliser une technologie W3C, ou là où cela pose des problèmes d'affichage, les développeurs devront fournir une version alternative du contenu auquel il s'agit d'accéder.

Les directives dont nous parlons recommandent les technologies W3C (HTML, CSS etc.) pour diverses raisons.

• Les technologiesW3C  incluent des spécificités d'accessibilité associées.
• Les spécifications W3C sont proposées  en amont pour s'assurer que les problèmes d'accessibilité sont  traités pendant la phase de design.
• Les spécifications W3C sont  développées dans un processus ouvert de consensus avec  l'industrie.

Beaucoup de formats non conformes avec le W3C (ex: PGF, Shockwave etc.) exigent  soit des plug-ins, soit des applications stand-alone. Souvent, ces formats ne  permettent pas une vision ou une navigation avec des navigateurs standards. Eviter les spécifications non conformes au W3C et les spécifications  non standard (éléments propriétaires, attributs,  propriétés et extensions) tendra à rendre les pages plus  accessibles à plus de gens utilisant une plus grande variété  de plates-formes et de logiciels. Quand des technologies inaccessibles doivent  être utilisées, des pages équivalentes facilement accessibles  doivent être fournies.

Même lorsque les technologies W3C sont utilisées, elles devront l'être en accord avec les directives d'accessibilité. (voir aussi la directive 6.).

Note. Convertir des documents (depuis PDF, PostScript, RTF  etc.) en langages W3C (HTML, XML) ne crée pas systématiquement  un document accessible. C'est pourquoi il faut valider chaque page en vue de  son accessibilité après le processus de conversion. Si une page  ne se convertit pas correctement, une solution consiste à réviser la page jusqu'à ce que la représentation originelle se convertisse  normalement, une autre consiste à fournir une version HTML ou texte.

Note. Les développeurs  ne devraient recourrir aux pages alternatives que lorsque les autres solutions  ont échoué car les pages alternatives sont généralement  mises à jour moins souvent que les pages "primaires". Une  page non mise à jour peut être aussi frustrante qu'une page inaccessible  car dans les deux cas; l'information désirée n'est pas disponible.  La génération automatique de pages alternatives peut conduire  à une mise à jour plus fréquente, mais les développeurs  devront s'assurer que les pages ainsi générées ont un  sens, et que les utilisateurs peuvent naviguer sur un site en suivant les  liens sur les pages primaires, les pages alternatives, ou les deux. Avant  de recourrir à une page alternative, reconsidérez le design  de la page originelle, la rendre accessible la rendra certainement plus agréable  pour tous les utilisateurs.

[retour à la table des matières]

Fournir de l'information sur le contexte et l'orientation pour aider les utilisateurs à comprendre des pages ou des éléments complexes.

Grouper les éléments et fournir de l'information contextuelle sur les relations entre les éléments peut être bénéfique à tous les utilisateurs. Les relations complexes entre les parties d'une page peuvent être difficiles à interpréter pour les personnes ayant des handicaps cognitif ou visuels.

[retour à la table des matières]

Fournir des mechanismes de navigation clairs et consistents. - information sur l'orientation , des barres de navigation, un site map, etc. -- pour augmenter la probabilité qu'un utilisateur trouve ce qu'il cherche dans un site.

Des mechanismes de navigation clairs et consistents sont importants pour les  personnes avec des handicaps cognitifs, et bénéficient à  tous les utilisateurs. 

[retour à la table des matières]

S'assurer que tous les documents sont clairs et simples afin d'être compris facilement.

Une mise en page consistante, des éléments graphiques reconnaissables, et un langage facile à comprendre bénéficient à  tous les utilisateurs. En particuler, ils aident les personnes avec des difficultés  cognitives ou qui ont des difficultés à lire. (Cependant, s'assurer  que les images ont des équivalents texte pour les aveugles ou les personnes  dont la vue est basse, ou pour quelqu'utilisateur qui ne peut pas ou a choisi  de ne pas voir les images).

Utiliser un langage clair et simple permet une communication efficace. L'accès à l'information écrite peut être difficile pour les personnes ayant des handicaps cognitifs. Utiliser un langage clair et simple bénéficie aussi à ceux dont la langue maternelle n'est pas celle utilisée sur le site. Et même ceux qui communiquent principalement en langage des signes.