Pour respecter les lignes directrices concernant l'accessibilité universelle énoncées dans l'initiative d'accessibilité aux contenus Web du W3C , l'institution doit veiller à ce que ses sites Web satisfassent aux critères des Priorités 1 et 2 des lignes directrices sur l'accessibilité des contenus Web, version 1.0 (WCAG) (en anglais), à l'exception du critère suivant :

• Le critère 3.4 des WCAG est remplacé par l'exigence numéro 2 des Normes sur la normalisation des sites Internet, partie 3 : Norme sur la présentation commune de pages Web.

Chacune des quatorze lignes directrices du WCAG est accompagnée d'une ou de plusieurs mesures à prendre pour s'assurer que la page répond aux exigences. Ces mesures s'appellent des « critères ».

Les institutions doivent consulter la Directive sur l'utilisation des langues officielles sur les sites Web pour savoir comment respecter les exigences relatives aux langues officielles dans les équivalents textuels et les autres éléments non textuels.

• 1.1 - Fournir un équivalent textuel à chaque élément non-textuel.
• 1.2 - Fournir des liens textes redondants pour chaque région active d'une carte cliquable côté serveur.
• 1.3 - Jusqu'à ce que les agents utilisateurs soient en mesure de lire automatiquement à haute voix l'équivalent textuel d'une piste visuelle, fournir une description auditive des informations importantes de la piste visuelle d'une présentation multimédia.
• 1.4 - Pour toute présentation multimédia temporisée (par exemple un film ou une animation), synchroniser les alternatives équivalentes (par exemples les sous-titres ou la description auditive des pistes visuelles) avec la présentation.
• 2.1 - S'assurer que toute information convoyée par des couleurs est également accessible sans couleur, par exemple à partir du contexte ou de balises.
• 4.1 - Identifier clairement les changements survenus dans le langage naturel du texte d'un document et équivalents (par exemple les légendes).
• 5.1 - Pour les tableaux de données, identifier les en-têtes de lignes et de colonnes.
• 5.2 - Pour les tableaux de données qui ont deux niveaux logiques d'en-tête de colonne ou de ligne ou plus , utiliser des balises pour associer les cellules de données et les cellules d'en-tête.
• 6.1 - Organiser les documents de manière à ce qu'ils puissent être lus sans feuilles de style. Par exemple, lorsque un document HTML est restitué sans la feuille de style lui étant associée, il doit rester lisible.
• 6.2 - S'assurer que les équivalences pour le contenu dynamique soient mises à jour lorsque ledit contenu dynamique change.
• 6.3 - S'assurer que les pages soient visibles lorsque les scripts, les applets ou autres artefacts programmables sont désactivés ou non supportés. Lorsque ce n'est pas possible, fournissez une information équivalente sur une page alternative.
• 7.1 - Jusqu'à ce que les agents-utilisateurs permettent à l'utilisateur de contrôler les changements brusques de luminosité, il convient d'éviter de causer de tels changements sur l'écran.
• 8.1 - Concevoir les éléments programmables tels que scripts et appliquettes de manière à ce qu'ils puissent être directement accessibles ou compatibles avec les différentes technologies d'assistance aux utilisateurs. [Priorité 1 si la fonctionnalité est importante et non présente ailleurs, sinon Priorité 2.]
• 9.1 - Prévoir des cartes cliquables côté client au lieu de cartes côté serveur, sauf lorsque les régions ne peuvent être définies par des formes géométriques disponibles.
• 11.4 - Si, malgré vos efforts vous ne parvenez pas à produire une page accessible, créez un lien vers une autre page accessible, qui utilise les technologies du W3C, et qui présente une information (ou fonctionnalité) équivalente, et est mise à jour aussi régulièrement que la page (originale) innacessible.
• 12.1 - Donner un titre à chaque cadre pour faciliter l'identification et la navigation entre cadres.
• 14.1 - Utiliser le langage le plus clair et le plus simple possible adapté au contenu de votre site.

• 2.2 - S'assurer que la combinaison de couleurs entre le premier plan et l'arrière-plan utilise suffisamment de contraste lorsqu'elle est utilisée par des personnes souffrant d'un déficit de perception des couleurs ou sur un écran noir et blanc. [Priorité 2 pour les images, Priorité 3 pour le texte.]
• 3.1 - Quand un langage de balisage approprié existe, utiliser des balises plutôt que des images pour convoyer l'information.
• 3.2 - Créer des documents qui sont validés par des grammaires formelles publiées.
• 3.3 - Utiliser des feuilles de style pour contrôler la mise en page et la présentation.
• 3.4 - Utiliser des unités relatives plutôt qu'absolues dans les valeurs d'attributs du langage et les valeurs de propriétés des feuilles de style.
• 3.5 - Utiliser les éléments d'en-tête pour convoyer la structure du document, et les utiliser en conformité avec les spécifications.
• 3.6 - Marquer les listes et les éléments de listes correctement.
• 3.7 - Baliser les citations. Ne pas utiliser le balisage correspondant aux citations pour obtenir des effets de présentation comme l'indentation.
• 5.3 - Ne pas utiliser les tables pour la mise en page, à moins qu'elles n'aient un sens lorsqu'elles sont déchiffrées en mode linéaire. Autrement, si la table n'a pas de signification, prévoir une version alternative (qui pourra être une version linéaire).
• 5.4 - Dans le cas ou une table est employée pour la mise en page, il ne faut pas utiliser de balises structurelles dans un but de formatage visuel.
• 6.4 - Pour les scripts et les applets, faites en sorte que les gestionnaires d'événements soient indépendants du dispositif d'entrée.
• 6.5 - S'assurer que le contenu dynamique reste accessible, ou fournir une présentation alternative de la page.
• 7.2 - Jusqu'à ce que les agents-utilisateurs permettent de désactiver le clignotement, éviter de faire clignoter le contenu (par ex. Changer une présentation à intervalles régulier, comme une activation ou une désactivation).
• 7.3 - Jusqu'à ce les agents-utilisateurs permettent de geler le contenu mobile, éviter les mouvements sur les pages.
• 7.4 - Jusqu'à ce que les agents-utilisateurs permettent de stoper les mises à jour, éviter de créer des pages se mettant à jour automatiquement.
• 7.5 - Jusqu'à ce que les agents-utilisateurs permettent de désactiver la fonction de redirection automatique, ne pas utiliser de commandes pour rediriger automatiquement les pages. Configurez plutôt le serveur pour accomplir cette fonction.
• 8.1 - Concevoir les éléments programmables tels que scripts et appliquettes de manière à ce qu'ils puissent être directement accessibles ou compatibles avec les différentes technologies d'assistance aux utilisateurs. [Priorité 1 si la fonctionnalité est importante et non présente ailleurs, sinon Priorité 2.]
• 9.2 - S'assurer que tout élément qui possède sa propre interface peut être activé d'une manière indépendante du dispositif.
• 9.3 - En ce qui concerne les scripts, il importe de spécifier les gestionnaires d'événements logiques plutôt que des gestionnaires d'événements dépendants de l'interface.
• 10.1 - Jusqu'à ce que le agents-utilisateurs permettent aux utilisateurs de fermer les fenêtres générées, ne pas produire de fenêtre successives ou à ouverture automatique, et ne pas modifier la fenêtre active sans prévenir l'utilisateur.
• 10.2 - Jusqu'à ce que le agents-utilisateurs supportent les associations explicites entre étiquettes et contrôles de formulaires, s'assurer que les étiquettes sont correctement positionnées pour tous les contrôles de formulaire avec étiquettes implicitement associées.
• 11.1 - Utiliser les technologies du W3C lorsque elles sont disponibles et adaptée à une tache. Utilisez les dernières versions supportées.
• 11.2 - Eviter d'utiliser les options des technologies du W3C qui ne sont plus supportées.
• 12.2 - Décrire l'objectif des cadres et la manière dont les cadres interagissent les uns avec les autres, si ce n'est pas évident à la la seule lecture des titres.
• 12.3 - Lorsque c'est approprié, diviser les grands blocs d'information en groupes plus petits et plus facilement manipulables.
• 12.4 - Associer les étiquettes avec leurs éléments de contrôle de manière explicite.
• 13.1 - Identifier clairement la cible de chaque lien.
• 13.2 - Prévoyez des meta-données pour ajouter des informations d'ordre sémantique aux pages et aux sites.
• 13.3 - Fournir des informations concernant la mise en page générale d'un site. (par ex. la carte d'un site, ou une table présentant le contenu).
• 13.4 - Utiliser les mécanismes de navigation de manière cohérente.

Pour s'assurer que tous les visiteurs d'un site pourront avoir accès au contenu quelle que soit la configuration technique du système ou des appareils qu'ils utilisent, l'institution doit adopter le langage XHTML 1.0 Strict et les feuilles de style en cascade 1.0 (CSS1) comme technologies de base pour le balisage, la présentation et la conception de pages Web.

Pour garantir l'accessibilité à ses produits, l'institution doit mettre en oeuvre des méthodes normalisées, en appliquant les langages décrits dans les recommandations formulées par le World Wide Web Consortium (W3C). Toutefois, il ne suffit pas d'avoir recours à ces langages pour le balisage ou la conception pour qu'un produit soit naturellement accessible.

Lorsque, en dépit des mesures prises, il n'est pas possible de rendre le contenu ou l'application accessible, c'est-à-dire lorsqu'un document ne peut pas être présenté en langage XHTML 1.0 Strict ou dans un langage décrit dans les recommandations formulées par le W3C, l'institution doit :

• insérer un avis concernant l'accessibilité dans la page, immédiatement avant l'élément inaccessible, pour informer les visiteurs de la marche à suivre pour obtenir une version accessible imprimée, en braille ou audio;
• insérer un avis concernant l'accessibilité dans la ou les pages d'aide du site Web.

La publication de versions accessibles dans un format autre que le format XHTML recommandé ne doit se faire qu'en dernier recours. Il ne s'agit pas d'un moyen pratique d'éviter les interventions minimales nécessaires pour rendre accessibles les pages et les applications Web.

Pour respecter les lignes directrices concernant l'accessibilité universelle, l'institution doit s'assurer que les pages Web présentant de l'information dans différents formats «médias substituts» comprennent des indications textuelles sur le format, le type et la taille des fichiers pour chaque lien pointant vers un fichier qui n'est pas en format XHMTL. Pour chaque format nécessitant un logiciel spécialisé, un lien hypertexte vers un site où le navigateur ou le module d'extension peut être téléchargé doit être fourni. Si l'accessibilité à une version d'un module d'extension est aussi connue, une note ou un lien menant à ce produit devrait également figurer.

La présente norme et les lignes directrices sur l'accessibilité des contenus Web du W3C ne sous-entendent pas qu'il soit interdit à un fournisseur de contenu d'offrir l'information en de divers formats «médias substituts». La seule exigence formulée est que le premier format chargé par un visiteur soit celui de la version la plus accessible.

Des exemples de la façon de traiter les documents offerts dans différents formats «médias substituts» et les fichiers multimédia en divers formats «médias substituts» sont fournis dans la boîte à outils de la NSI.

L'institution doit s'assurer qu'il existe un contraste évident entre les éléments textuels et les couleurs ou les images d'arrière-plan, lorsque la page en question est visualisée par une personne daltonienne ou sur un écran noir et blanc.

Pour respecter les lignes directrices sur l'accessibilité universelle, l'institution doit faire appel à une méthodologie de validation pour évaluer l'accessibilité, l'interopérabilité et la facilité d'emploi de ses sites Web. Tous les sites doivent être mis à l'essai sous différents navigateurs, plateformes et technologies, afin de s'assurer que les pages Web sont toujours accessibles et interopérationnelles.

La validation des pages Web existantes et futures en fonction de la définition de type de documents (DTD) au format XHTML 1.0 Strict ou à un format similaire recommandé par le W3C permet de s'assurer que la syntaxe des pages est correcte. Le W3C propose une méthodologie de validation.

La mise à l'essai auprès d'utilisateurs actuels ou éventuels est également essentielle, et doit porter sur la facilité d'utilisation, la navigation, la compréhension et la satisfaction des utilisateurs.