ATAG
(Authoring Tool Accessibility Guidelines) 2.0

par Jean-Pierre Villain
Access42

En guise d'introduction

Quelques caractéristiques d'ATAG 2.0

  • Fruit d'un travail commencé en 2005 !
  • Document assez court mais assez difficile à lire, très technique.
  • Structure similaire à WCAG : une partie règles et critères et une partie guide d'implémentation technique.
  • Adresse les technologies Web (type CMS) et non-web (type logiciel) ce qui est une des raisons de sa complexité.
  • En Candidate Recommendation.

Structure d'ATAG 2.0

  • Deux grandes parties :
    1. Partie A : créer des interfaces accessibles.
    2. Partie B : accompagner la production de contenus accessibles.
  • Trois niveaux de priorités (A, AA, AAA).

Portée

  • Tous les types de contenus produits par l'auteur ou l'outil.
  • Tous les outils, en technologie web et non-web.

Partie A : créer des interfaces accessibles.

Partie A : créer des interfaces accessibles.

Conformes WCAG pour les interfaces en technologies Web.

Compatibles avec l'accessibilité, via une série de critères spécifiques, pour les technologies non-web.

Fonctionnalités spécifiques

Niveau A

  • Si l'interface de visualition est personnalisable, les fonctionnalités de personnalisation ne modifient pas le contenu édité.
  • L'interface, ses composants et ses fonctionnalités d'accessibilité doivent être documentés (via une aide ou directement dans l'interface).

Partie A : créer des interfaces accessibles.

Fonctionnalités spécifiques

Niveau A

  • Les actions d'édition doivent pouvoir être annulées ou un mécanisme de confirmation doit être proposé.
  • Si une fonctionnalité de prévisualisation est fournie elle utilise un agent-utilisateur du marché ou est conforme avec UAAG (niveau A).
  • Pas de limite de session ou fournir une fonctionnalité de sauvegarde automatique régulière.

Partie A : créer des interfaces accessibles.

Fonctionnalités spécifiques

Niveau AA

  • Si une fonctionnalité de visualisation du code est fournie, l'auteur peut le parcourir et l'éditer.
  • Pouvoir chercher dans le contenu édité, y compris dans les alternatives.
  • Pouvoir sauvegarder la configuration personnalisée de l'interface.
  • L'interface, ses composants et ses fonctionnalités doivent être documentés (via une aide ou directement dans l'interface).

Partie A : créer des interfaces accessibles.

Fonctionnalités spécifiques

Niveau AAA

  • Si une fonctionnalité de prévisualisation est fournie, l'auteur doit pouvoir choisir l'agent-utilisateur utilisé.
  • Fournir un historique des modifications et pouvoir les annuler.
  • Fournir une méthode pour implémenter ou modifier des raccourcis clavier pour chaque fonctionnalité (e.g menus, options de menu etc).
  • Pouvoir naviguer dans les éléments liés programmatiquement (e.g atteindre un élément par son id, par un classe de style, trouver une méthode à partir de son appel...)

Partie B : créer des contenus accessibles.

Partie B : créer des contenus accessibles.

Niveau A

Les contenus produits automatiquement par l'outil doivent être conformes avec WCAG.

S'assurer que les contenus pré-édités (par un plugin par exemple), fournis par l'outil, sont conformes WCAG.

Les processus de production d'alternatives automatiques doivent être contrôlables par l'auteur.

Partie B : créer des contenus accessibles

Niveau A

Alerter et assister l'auteur sur la production de contenus accessible, ou l'existence potentielle de problèmes, lors de l'édition ou la mise à jour des contenus.

Proposer une fonctionnalité de vérification de l'accessibilité avant la validation du contenu.

Assister l'auteur dans la réparation des problèmes d'accessibilité via des recommandations de correction ou des proposition de corrections automatiques.

Activer les options d'accessibilité par défaut et alerter du risque potentiel en cas de désactivation par l'auteur.

Proposer des exemples de contenus accessibles dans les dispositifs d'aides.

Partie B : créer des contenus accessibles

Niveau AA

Ne pas générer ou réutiliser des alternatives sans une confirmation de l'auteur.

Préserver les informations d'accessibilité lors des opérations de conversion ou d'optimisation de format ou fournir un mécanisme pour rendre conforme les contenus convertis ou alerter l'auteur.

Présenter les fonctionnalités dédiée à l'accessibilité au même niveau que celles qui ne le sont pas.

Proposer les propriétés d'accessibilités prévues pour l'élément en cours d'édition.

Les templates ou les contenus pré-formatés, fournis par l'outil, doivent indiquer s'ils supportent l'accessibilité ou pas.

Produire un résumé de la vérification d'accessibilité.

Partie B : créer des contenus accessibles

Niveau AAA

Fournir un mécanisme de sauvegarde et de réutilisation des alternatives aux contenus non-textuels pour un même contenu.

Ne proposer que des templates conformes WCAG AA.

Produire des tutoriaux pour produire des contenus accessibles.

Du rêve à la réalité

Existe-t-il un CMS conforme ATAG 2.0 : non ! (Sharepoint ?)

L'implémentation d'ATAG est complexe et très couteuse en investissement.

Récemment les vérificateurs d'accessibilité sont devenus une valeur ajoutée importante dans les RTE.

Mais le sujet se démocratise depuis le début des années 2010, des efforts sont faits, le travail est en cours...

Ressources

Merci de votre attention !