Atelier WCAG 2.0 - Seminaire Accessiweb, Juin 2006

Le débat

Historique

• 
• 

• Première ébauche : janvier 2001; 9 ébauches depuis.
• Dernier appel à commentaires : document WCA2.0 du 27 avril 2006.
• 22 juin 2006 : fin des commentaires.
• Long processus avant que WCAG 2.0 ne devienne une recommandation.

But des WCAG 2.0

• 
• 

• Pour les personnes avec différents handicaps et les personnes âgées.
• Pour différentes technologies d'accès: aides techniques et technologies mobiles.
• Le but est de rendre les contenus Web accessibles au plus grand nombre.
• Les recommandations n'incluent pas des recommandations sur la facilité d'utilisation sauf si elles ont un impact spécifique sur l'accessibilité du Web.

Public visé

• 
• 

• Les créateurs de contenu Web,
• Les intégrateurs (ceux qui écrivent le code),
• Les évaluateurs de l'assurance qualité ou de l'accessibilité,
• Les politiques,
• Les gestionnaires, les directeurs
• et les utilisateurs.

Les documents des WCAG 2.0

• 
• 

• Une série de documents liés les uns aux autres.
• Des documents normatifs et des documents d'accompagnement, d'explications.
• Document normatif : ne peut être modifié.
• Document non normatif : peut évoluer...

Les documents normatifs

• Conformance to WCAG 2.0 :les règles de conformité
• Web Content Accessibility Guidelines 2.0 : les recommandations proprement dites
• Appendix A: Glossary (Glossaire des définitions)

Les documents non normatifs

• Une introduction à WCAG 2.0
• Overwiew WCAG 2.0
• Des annexes :
  • Checklist for Web Content Accessibility Guidelines 2.0 : une liste de vérification
  • Comparison of WCAG 1.0 checkpoints to WCAG 2.0 : un tableau comparatif des WCAG 1.0 et 2.0.
  • Des références et autres documents d'accompagnement.
  • “Understanding WCAG 2.0”, le document d’accompagnement indispensable

Documents d'aide à la compréhension des WCAG 2.0

“Understanding WCAG 2.0 ( Comprendre WCAG 2.0 )" est un document indispensable pour appréhender le document normatif avec des liens vers:

• la raison du critère;
• des techniques de mise en oeuvre
• des expressions du glossaire WCAG permettant de comprendre chaque critère,
• des exemples et les avantages de chaque critère.

• About Baselines for WCAG 2.0 qui présente le concept de Baseline.
• Techniques for WCAG 2.0 qui compile :
  • Des exemples pour différentes techniques comprenant du code, des exemples, et des tests.
  • De nouvelles techniques pourront être proposées à tout moment pour enrichir les recommandations.
  • Des notes pour l'application, appelées "application notes" : exemples relatifs à un type d'éléments.

Structure des WCAG 2.0

• 
• 

• 4 principes
• 13 recommandations
• 56 critères (success criteria : critères de réussite).

Les 4 grands principes

• 
• 

L'adaptation, l'alternative et la transformation, au coeur de WCAG 1.0, censées être garantes de l'interopérabilité, ne sont plus que des "moyens" au bénéfice des 4 grands principes.

• Perceivable – Perceptible, qui peut être perçu par les sens, y compris par l'esprit.
• Operable - Fonctionnel, qui peut être utilisé simplement
• Understandable - Compréhensible, qui peut être compris (langage, jargon, etc.)
• Robust - Robuste, qui est compatible avec les technologies présentes et futures

• Ces quatre principes sont les fondations nécessaires pour garantir l’accessibilité du web à tous
• Ces concepts sont suffisament ouverts pour répondre aux questions et aux besoins d’accessibilité sans être spécifiques à une technologie.
• Cela rend WCAG 2.0 appliquable à une grande variété de situations et de technologies, y compris celles qui n’existent pas encore.
• Ils sont les lignes de conduite de tout bon producteur web

 Baseline (Référence de base)

• 
• 

• Ensemble de technologies présumées être intégrées et activées dans les agents utilisateurs .
• Les Auteurs doivent s’assurer que le contenu et les fonctionnalités sont accessibles en n’utilisant que les technologies du Baseline.
• C’est le moyen choisi par WAI pour
  • Adapter WCAG à l’évolution du web
  • Prendre en compte des contextes d’utilisation particuliers (intranet…)

Défini par un auteur, une société, un gouvernement, un client,…

WCAG 2.0 ne définit aucun Baseline.

Les technologies en dehors du baseline ne doivent pas empêcher l’accès au contenu pour les UA

• Qui supportent uniquement le Baseline
• Qui supportent le Baseline et ces autres technologies
• Lorsqu’elles sont activées ou désactivées

Spécifique à des technologies et pas à :

• Un UA particulier, ou une de ses versions.
• Un public particulier.
• Toutes les technologies (W3C et non-W3C) peuvent être incluses.
• “WCAG 2.0 Quick reference” fournit un sommaire dynamique adapté au choix d’un Baseline pour les technologies communes du web.

La nouvelle situation :

• On ne produit plus d’alternative pour une technologie du baseline, pour les UA qui ne la supportent pas. ( Cf conditions).
• C’est une situation qui peut engendrer des volontés de détournement et des défauts d’interprétation.
• C’est une solution dès lors que l’on maîtrise l’environnement d’exécution (exemple : intranet, interface d’administration)

Exemples :

• Html : c’est la situation WCAG 1.0
• Html + Javascript : exemple WAI (en anglais) : absence d’alternative à la modification d’une liste de formulaire par la sélection d’un item.

 Le scoping

• 
• 

“Cette partie de votre site n’est pas accessible !”

“Mais j’ai jamais dit qu’elle l’était !”

• Nouveau concept, lié à la déclaration de conformité et au Baseline.
• Permet de pouvoir déclarer son site accessible même si l'on ne peut en garantir l’accessibilité pour une de ses parties (exemple : forum)

• Le "vertical scoping" (exclusion d’une partie d’un site par URI ou groupe d’URI) est autorisé.
• “L’horizontal scoping" (exclusion d’une technologie particulière dans une page) n’est pas autorisé

Faire un lien vers une partie non accessible est également autorisé selon les conditions suivantes :

• Le contenu visé n’est pas affiché conjointement à une page accessible (frame)
• La page n’est pas un point de passage obligatoire dans une suite de pages accessibles (panier d’achat)

• Je ne peux pas dire que : je n’ai pas rendu accessible les vidéos de mon site
• Je peux dire que : je n’ai pas rendu accessible une partie de mon site (qui les contient)

Nuance...

Conformité

• 
• 

3 niveaux de conformités :

Niveau 1 :

• Atteindre un niveau d'accessibilité minimal
• Raisonnablement applicable à toutes les ressources Web

Niveau 2 :

• Améliorer le niveau d'accessibilité.
• Raisonnablement applicable à toutes les ressources Web

Niveau 3

• Perfectionner le niveau d’accessibilité
• N’est pas nécessairement applicable à tout le contenu Web

Déclaration de conformité

• 
• 

La déclaration de conformité (en anglais) devient un processus formel comprenant notamment :

• L’indication du Baseline utilisé, qui peut faire référence à des Baselines normatifs ou réglementaires.
• L’indication de l’étendue de la déclaration ( fondée sur le concept de “scoping” )
• Le niveau de conformité :

Niveau A : Tous les critères de succès du niveau 1

Niveau AA : Tous les critères de succès des niveaux 1 et 2

Niveau AAA : Tous les critères de succès du niveau 1 et 2 et 50 %, au moins, des critères de niveau 3

Terminologie

• 
• 

Web Unit (Unité Web)

Collection d’informations identifiée par une seule URI (comme une URL) et constituée d’une ou plusieurs ressources destinées à être rendues ensemble.

Equivalent à une “page”

Authored Unit (Unité de conception)

Un ensemble de matériels créés en tant qu'entité unique par un auteur.

Par exemple :

• un ensemble de balisage, une feuille de style et une ressource média, telle qu'une image ou un clip audio.
• Un ensemble de pages web destinées à être vues comme une entité unique ou une séquence

Equivalent à Site Web

Authored component (Composant de conception)

• C’est une unité de conception utilisée comme partie d’une autre unité de conception.

Par exemple, l’ensemble balisage+style CSS d’un flux RSS diffusé par un agrégateur.

Parsed unambiguously (Analysé de manière univoque)

• Analysé au travers d’une structure unique de données.

Par exemple, l’arbre d’un document restitué au travers du DOM

Programmatically determined (déterminé informatiquement )

• Déterminé informatiquement signifie qu'une valeur spécifique peut être déterminée dans une forme normalisée pouvant être lue par une machine ou un logiciel.

Par exemple, la nomenclature du DOM qui renvoie le type d’élément.

 Guideline 1.1

• 
• 

fournir des alternatives textuelles pour tous les éléments de contenu non textuels

• Principe de référence : Le contenu doit être perceptible
• nombre de critères : 1
• Le contenu doit être appréhendé par tous les internautes.

Le critère de succès vise à donner :

• Un équivalent textuel à tout élément non textuel.
• Plus de détails sur les contenus non textuels que dans WCAG 1.0

Plusieurs sortes de contenus non textuels :

• Contenu non textuel donnant de l'information : l'alternative doit être équivalente.
• Contenu non textuel permettant une action utilisateur ( bouton de soumission ) : donner une alternative équivalente.
• Si l'alternative textuelle ne peut être équivalente alors l'alternative textuelle permet, au moins, d'identifier le but de l'élément non textuel.

Plusieurs sortes de contenus non textuels :

• Nouveaux contenus : tests ou exercices requérant un sens particulier, multimédia, audio en direct uniquement, vidéo en direct uniquement : L’ alternative indique, au minimum, leur présence et les décrivent, avec leur titre.
• Les éléments de décoration doivent avoir une alternative qui permet de les ignorer.

• Equivalents aux scripts, applets, objets traités dans une autre recommandation.
• Idem pour les contenus multimédia.
• NOFRAME n'est plus exigé.
• L’ ART ASCII est inclus dans ce critère; le point de contrôle 13.10 de WCAG 1.0 n'a plus de correspondance directe.
• Attention : porte ouverte par la mention “ Si l'alternative textuelle ne peut être équivalente alors elle permet d'identifier, au moins, le but de l'élément non textuel”.(L’audio et la vidéo vont vite se retrouver avec comme alternative textuelle : vidéo/son de monsieur machin)

 Guideline 1.2

• 
• 

Fournir des alternatives synchronisées pour le multimédia

• Principe de référence : Le contenu doit être perceptible
• nombre de critères : 7
• Quelques définitions d'abord :
  • Multimédia : Contenu audio ou video synchronisé avec un autre type de média et/ou avec une composante interactive temporelle (un son seul n'est donc pas un élément multimédia mais un élément non textuel)
  • Vidéo : technologie de mise en mouvement d'images (film, animation, diaporama)

• Sous titres : texte présenté et synchronisé avec le multimédia pour fournir l'équilavent des éléments parlés, mais aussi des effets sonores et, parfois, des identifications du narrateur
• Audio description : éléments narratifs ajoutés à la bande sonore pour décrire les détails visuels importants qui ne peuvent être perçus par la bande sonore seule.

Note : sur une vidéo, les informations portent sur les actions, les personnages, les changements de décors et les textes apparaissant à l'écran.

Dans l'audio description de base, ces éléments sont ajoutés pendant les pauses dans le dialogue. Dans l'audio description étendue, la vidéo sera mise en pause.

• Alternative texte multimedia incluant toutes les interactions : Document incluant, pour chaque séquence, les descriptions de l'environnement visuel, des actions et des éléments non parlés, en supplément de la transcription de tous les dialogues et des moyens de réaliser toute action qui serait réalisable dans l'élément multimedia. (ex : alternative Html à un Flash)

• Cette guideline reprend les points 1.3 et 1.4 de WCAG 1.0
• 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. [Priorité 1]
• 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. [Priorité 1]

L'objectif de WCAG 2.0 sur cette thématique multimédia est double :

• Prendre en considération l'évolution du web sur la partie multimédia depuis 1999.
• Prendre en considération tous les types de handicaps, tout en rééquilibrant les niveaux d'exigence.

Level 1

• Des sous-titres sont disponibles pour le multimédia pré-enregistré
• L’audio description pour les éléments vidéos, ou une alternative textuelle incluant toutes les interactions, est disponible pour le multimédia pré-enregistré.

Level 2

• L’Audio description pour les éléments vidéos pré-enregistrés est disponible.
• Des sous-titres pour le multimédia en direct sont disponibles.

Level 3

• Une interprétation en langue des signes est disponible pour le multimédia.
• L’Audio description étendue pour les éléments vidéos pré-enregistrés est disponible.
• Pour le multimédia pré-enregistré, une alternative textuelle multimédia incluant toutes les interactions est disponible.

On peut donc constaster que, sur cette thématique, WCAG 2.0 répond bien à ces objectifs. Cependant, quelques points sont susceptibles de faire débat :

• Audio description facultative au niveau 1
• Sous titrage des éléments en direct en niveau 2
• Pas d'audio description pour les éléments en direct
• Encore difficile à implémenter -> AOL recommande de passer le niveau 1 en niveau 2 (prb de vidéo à la demande et d'aggrégation de contenu)

 Guideline 1.3

• 
• 

Séparation structure, information, présentation

• Principe de référence : 1 - Le contenu doit être perceptible
• nombre de critères : 5
• Cette guideline reprend 17 critères WCAG 1.0
• L’objectif général est d’assurer que le contenu est perçu en adéquation avec les capacités des moyens de restitution.

Critères WCAG 1.0:

• 1.1 : alternatives textuelles (partiellement et en relation avec CSS)
• 2.1 : information restituée par la couleur
• 6.1 : contenu lisible sans style CSS
• 5.1, 5.2, 5.3, 5.4, 5.5, 10.3 : sur les tables de données, tables de mise en forme, le sommaire d’une table de données, le texte mis en colonne par une table de mise en forme.
• 3.1, 3.6, 3.7, 3.5, 10.2, 12.4 : sur la pertinence du balisage
• 3.3 : sur l’utilisation de CSS
• 13.2 : sur les métadonnées; le critère est abandoné

Critères WCAG 2.0 Niveau 1 :

• 1.3.1 : L'information et les relations au sein du contenu restitué par la présentation peuvent être déterminées informatiquement. La notification de leur modification est disponible pour les agents utilisateurs, y compris les technologies d'assistances

Note : une partie des techniques associées à ce critère est dépendante du baseline ( Par exemple CSS pour WCAG 1.0, 6.1 ).

Moyens :

• Pour Html : Utiliser CSS pour la présentation et la sémantique du balisage selon les spécifications.
• Pour Javascript : Utiliser les fonctions DOM appropriées.

Critères WCAG 2.0 Niveau 1 :

• 1.3.2 : Chaque information restituée par la couleur est également restituée sans couleur.

Moyens :

• Pour html : Les moyens habituels utilisés avec WCAG 1.0
• Pour les autres technologies : Pas d’indication encore disponible, pour Javascript, notamment.

Critères WCAG 2.0 Niveau 1 :

• 1.3.3 : Lorsque le contenu est ordonné selon une séquence qui affecte sa signification, cette séquence peut être déterminée informatiquement

Moyens :

• Pour Html : Structurer le contenu, utiliser CSS, de manière appropriée pour restituer la présentation du contenu.
• Pour les autres technologies : Structurer le contenu selon les spécifications propres aux technologies du Baseline.

Critères WCAG 2.0 Niveau 2 :

• 1.3.4 : Les informations restituées par des variations de la présentation d'un texte sont aussi restituées par le texte lui-même ou ces variations peuvent être déterminées informatiquement.

Moyens :

• Pour Html : Utiliser la sémantique appropriée du balisage ( exemple : em, strong, blockquote)
• Pour les autres technologies : Pas d’indication disponible.

Critères WCAG 2.0 Niveau 2 :

• 1.3.5 : L'information requise pour comprendre et utiliser le contenu ne se fonde pas sur la forme, la taille, la position visuelle ni l'orientation des composants.

Moyens :

• Pour Html : Les moyens habituels pour WCAG 1.0, sur le texte explicite d’un bouton de formulaire, par exemple, ou le traitement de l’iconographie.
• Pour les autres technologies : Pas d’indication disponible.

Les zones d’ombres

• Cette guideline reprend un nombre très important de points de contrôle WCAG 1.0 en généralisant les moyens et les techniques de prise en charge, ce qui peut générer des erreurs d’interprétation.
• Certaines techniques,CSS et Javascript, par exemple, sont dépendantes du Baseline, ce qui peut engendrer des volontés de détournement.
• Il n’est plus fait mention de l’obligation d’utiliser CSS pour assurer la présentation, notamment en relation avec sa structure, qui est transposée comme un des moyens de succès du critère.

 Guideline 2.4

• 
• 

Fournir des mécanismes pour aider les utilisateurs à trouver le contenu, s'orienter et naviguer dans ce contenu

• Principe de référence : les éléments d'interface du contenu doivent être utilisables
• Nombre de critères : 8

Cette guideline reprend les points WCAG 1.0 suivants :

• 1.2 et 9.1 sur les alternatives aux régions actives d’une carte cliquable [Priorité 1]
• 12.1 Donner un titre à chaque cadre pour faciliter l'identification et la navigation entre les cadres. [Priorité 1]

• 13.1 Identifier clairement la cible de chaque lien. [Priorité 2]
• 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). [Priorité 2]

• 9.4 Développer un ordre logique de tabulation, pour les liens, éléments de formulaires et objets. [Priorité 3]
• 13.6 Regrouper les liens de même nature, identifier le groupe (pour les agents-utilisateurs), et, jusqu'à ce que les agents utilisateurs le permettent, donner un moyen de s'affranchir du groupe. [Priorité 3]
• 10.3 Jusqu'à ce que les agents utilisateurs (comprenant les technologies d'assistance) puissent restituer des textes adjacents correctement, prévoir une alternative en mode texte linéaire (sur la page concernée ou sur une autre) pour toutes les tables qui formatent le texte en colonnes parallèles et qui ajustent le texte sur la largeur de la colonne. [Priorité 3]

• Certains critères de WCAG 1.0 sont également partiellement traités via cette guideline :
• Le points 12.3 sur la division en blocs d'information. [Priorité 2]
• Les points 9.5, 13.5, 13.7 et 13.8 sur les raccourcis clavier, les barres de navigation, les moteurs de recherche, et les informations distinctives au début des en-têtes, des paragraphes, des listes etc. [Priorité 3]

Level 1

• 2.4.1 un mécanisme est disponible pour passer les blocs de contenu qui sont répétés sur plusieurs unités web

Grâce à :

• Skip link en début de page ou avant les blocs
• Liens regroupés dans une liste non ordonnée
• Utilisation de h1...h6
• Utilisation de frame avec des titres !!!!

Level 2

• 2.4.2 Il y a plus d'une façon disponible pour localiser du contenu sur un ensemble de pages où le contenu n'est pas le résultat ( ou bien une partie ) d'un processus ou d'une action

Grâce à un :

• plan du site
• moteur de recherche
• plan de page

Level 2

• 2.4.3 Les unités web ont un titre

Grâce à :

• Balise title ( + documents non Html : exif, meta, id3)
• Mettre un titre explicite est un conseil supplémentaire mais non obligatoire

Level 2

• 2.4.4 Chaque lien est associé informatiquement (progammaticaly associated non défini) avec les textes à partir desquels leur fonction peut être déterminée.

Grâce à :

• Les intitulés explicites
• Utilisation de title ou de alt (area shape)
• Du texte masqué dans le lien via CSS
• La position du lien dans un élément Html englobant; le W3C donne, par exemple, un paragraphe p qui contiendrait une liste de liens (p->ul->li->a), ce qui n'est pas valide Html

Level 3

• 2.4.5 Les titres de page ou de parties de page et les textes, les images ou les sons donnés à l'utilisateur, sont explicites (descriptive).

Grâce à :

• Des titres aux unités web (encore...)
• Des titres de sections explicites
• Des textes, images, ou sons explicites donnés à l'utilisateur (répétition du critères)
• Des titres aux frames (attribut title)

Level 3

• 2.4.6 Quand une unité web ou un élément de conception est parcouru de façon séquentielle, leurs éléments reçoivent le focus dans un ordre lié aux relations et à l'ordre dans le contenu

Grâce à :

• Des éléments d'interaction ordonnés de façon logique et respectant le flux
• Utilisation de tabindex

Level 3

• 2.4.7 Des informations sur la position de l'utilisateur dans un ensemble d'unités web sont disponibles.

Grâce à :

• Un fil d‘Ariane
• Un plan de site
• L'utilisation de la balise link Rel (liens relationnels)
• Des barres de navigation contextuelles (couleur+ icone, suppression du lien, emphase)

Level 3

• 2.4.8 La fonction de chaque lien peut être informatiquement déterminée par le lien lui-même.

Grâce à :

• Idem 2.4.4 sauf texte présent dans un élément parent

• Les critères de succès de cette guideline sont loin d'être aisément compréhensibles et cohérents entre eux
• le document how to meet (non normatif) est loin d'être clair, et conseille même des éléments dommageables à l'accessibilité ou à la validité du code
• Il faut attendre le niveau 3 pour être sûr d'avoir une page aux liens, titres de section ou titres de page explicites

 Guideline 3.1

• 
• 

Rendre le contenu textuel lisible et compréhensible

• Principe de référence : compréhensible, qui peut être compris.
• Nombre de critères : 6
• Critère 3.1.1, niveau 1 : Les logiciels doivent être capables d'identifier la langue naturelle du document et le sens de lecture
Correspond au point de contrôle 14.3 de WCAG 1.0, priorité 3. Le critère 14.1 sur le langage clair et explicite est supprimé et fait partie de cette recommandation.
• Critère 3.1.2, niveau 2 : Identifier les changements de langue dans le document. Correspond au point de contrôle 14.1 de WCAG 1.0.
• Critère 3.1.4, niveau 3 : Définir les abréviations.

Nouveaux critères :

• Critère 3.1.3, niveau 3 : définir les mots peu compréhensibles dans un contexte inhabituel (idiomes, jargon)
• Critère 3.1.5: proposer une alternative à un texte qui est difficilement compréhensible si on n'a pas le niveau secondaire.
• Critère 3.1.6: déterminer la prononciation d'un mot.

Deux points sont susceptibles d'être problématiques pour cette guideline :

• La notion de niveau d'éducation secondaire du critère 3.1.5 est totalement inutilisable
• Le choix des mots difficilement compréhensibles dans un contexte inhabituel est laissé à l'auteur

 Guideline 4.1

• 
• 

Compatibilité avec les Agents utilisateurs actuels et futurs (y compris les technologies d’assistances)

• Principe de référence : 4 - Le contenu doit être assez robuste pour fonctionner avec les technologies actuelles et futures
• nombre de critères : 2
• Cette guideline reprend 4 critères WCAG 1.0
• L’objectif général est d’assurer les conditions suffisantes pour une interopérabilité de base (« assez robuste »).

Critères WCAG 1.0 :

• 12.1 : Donner un titre aux frames en relation avec la robustesse de la restitution du DOM ( WCAG 2.0 – 4.1.2)
• 3.2 : Créer des documents valides
• 12.4 : Associer des labels explicites aux contrôles de formulaires
• 8.1 : Produire des scripts et des applets compatibles avec les technologies d’assistances

Critères WCAG 2.0 :

• 4.1.1 Les unités web ou les composants de conception peuvent être analysés de manière univoque et les relations restituées par la structure de données sont aussi univoques.

Moyens :

• Pour Html : Contrôler la restitution du DOM dans les différents agents utilisateurs
• Valider l’unité web
• Pour d’autres technologies : se conformer aux spécifications

Critères WCAG 2.0 :

• 4.1.2 : Pour tous les éléments d'interface, le nom et le rôle peuvent être informatiquement déterminés. Les valeurs modifiables par l'utilisateur peuvent être changées informatiquement et la notification de ces modifications est disponible pour les agents utilisateurs, y compris les technologies d'assistances.

Moyens :

• Pour Html : utiliser les éléments et les propriétés appropriés selon les spécifications pour leur traitement
• Pour les autres technologies : utiliser les éléments et leurs propriétés fournis par une API dédiée à l’accessibilité
• Créer vos propres composants, selon les spécifications de l’API de la plateforme sur laquelle sera implémentée l’interface.

Les zones d’ombres :

• Pour Html : l’abandon, en tant qu’obligation, de la validation du langage Html qui a été transposé comme un des moyens de valider ces critères.
• Dans le cas où le moyen de la validation est choisi, il ne concerne que les éléments impliqués dans le traitement et la restitution de la structure de données.

 Les critères WCAG 1.0 abandonnés

• 
• 

Un certain nombre de critères ou d’objets liés à des critères WCAG 1.0 sont abandonnés par WCAG 2.0 :

• 1.1 et 12.2 : Noframes et la description des cadres et de leurs interactions.
• 4.1 : L’indication de changement de langue pour un mot si celui-ci est habituel dans la langue d’usage
• 11.1 : L’utilisation des technologies W3C.
• 11.2 : L’interdiction de l’usage d’éléments dépréciés (liée à la problèmatique de la validation)
• 12.3 : La division du contenu en blocs d’informations identifiables
• 13.2 : L’obligation des métadonnées (transposée en technique)
• 9.5 : Les raccourcis clavier (accesskey) qui font l’objet d’une note de renseignements sont transposés en tant que technique supplémentaire.
• 1.5 : Les liens redondants pour une image map
• 5.5 et 5.6 : L’obligation d’un sommaire pour les tables et d’abréviations pour les en-têtes, transposées comme techniques supplémentaires.
• 10.3 : La production d’un contenu alternatif pour les textes en colonnes au moyen de tables est prise en charge différemment par les critères 1.3.3 (ordre d’un contenu) et 2.4.6 (ordre du focus séquentiel)
• 10.4 : La gestion des contrôles de formulaire vide

 Conclusion

• 
• 

Les points forts :

• WCAG 2.0 est indépendant des technologies et a été conçu pour accompagner le développement du web.
• Il corrige les défauts de WCAG 1.0 pour Html; les quatre principes ont une valeur ajoutée plus orientée vers l’utilisateur.
• Le concept de Baseline permet de prendre en compte le contexte d’exécution et d’utilisation d’une application web particulière.
• Le concept de Scoping permet de formaliser des démarches d’accessibilité « responsable »
• Son indépendance vis-à-vis des technologies permet de développer des méthodes d’application propres à des technologies ou des usages exclus de WCAG 1.0

Les points faibles

• WCAG 2.0 change complètement de point de vue, ce qui peut poser des problèmes vis-à-vis des pratiques habituelles liées à WCAG 1.0
• Le document normatif est très complexe, ne peut pas être compris tout seul, pose des problèmes d’interprétations voire de cohérence, particulièrement pour les néophytes et, enfin, pourrait se prêter à des volontés de détournement.
• Le concept de Baseline nécessitera d’établir des consensus ou un effort réglementaire, même si le Baseline Html seul revient à faire du WCAG 1.0
• L’implémentation de WCAG 2.0 nécessitera d’établir des méthodes d’application propres aux technologies concernées et relatives aux variations du Baseline.
• WCAG 2.0 demandera de très gros efforts pédagogiques fondés sur des documents d’accompagnement à l’exclusion du document normatif, trop complexe et trop abstrait.

---

Forg� avec Xhtml - CSS 2
Conforme WCAG 1.0

Copyright 2006 : WebOnorme / fairytells - Licence Creative Common