Licence CC BY

VPAT/WCAG les acronymes qui rendent votre site accessible

Pour un internet pour tous et sans pépin

Le Web est une technologie fantastique qui a permis de mettre en avant un nombre incroyable de personnes en contacte mais aussi de publier des contenus sur tous les sujets et dans tous les formats.

Cependant le Web reste assez difficile d’usage pour beaucoup de personnes:

  • Tout le monde ne peut pas naviguer avec une souris
  • Tout le monde ne peut pas avoir accès au son
  • Tout le monde ne peut pas voir des petits caractères
  • Ni des trop gros
  • Ni des trop contrastés
  • Ni de pas assez contrastés
  • Et parfois tous ne voient pas la différence entre deux teintes de couleur.

Faire en sorte que votre de limiter les soucis de ce genre, ça s’appelle rendre son site accessible. Et vous trouverez, sur ZDS, un grand nombre de contenus qui vous aideront dans cette quête. Mais vous aurez peut être besoin d’une méthodologie plus formelle pour réussir cette entreprise. De même, si vous développez une application professionnelle et cherchez à la rendre accessible, vous aimerez sûrement avoir un document à rendre pour prouver vos efforts aux hautes sphères.

Ce billet est fait pour vous.

La déclaration volontaire d'accessibilité des produits (VPAT)

Les entreprises qui veulent signer des contrats avec le gouvernement américain améliorer l’accessibilité de leur logiciel vont souvent vouloir obtenir une sorte "certification" pour prouver qu’elles font vraiment ce qu’elles prétendent. Pour cela une norme états-unienne (Section 508) et une équivalente européenne (EU 301 549) existent.

Ce normes décrivent un document où l’entreprise va montrer qu’elle essaie de se plier aux règles d’accessibilités standard qui sont décrites par le W3C dans un document appelé WCAG (on en parle juste après).

Dans ce document, l’entreprise va décrire si les directives sont applicables à son cas ou pas et ce qu’elle fait pour les appliquer. C’est donc une "autocertification", mais qui peut avoir un impact business donc… disons que c’est mieux que rien.

Si vous désirez voir à quoi ressemble un VPAT, voici celui de la console cloud de Google, je vous laisse juge: https://static.googleusercontent.com/media/www.google.com/fr//accessibility/static/pdf/google-cloud-cli-vpat.pdf?hl=fr.

Ah et "VPAT", ça veut dire "Volontary Product Accessibility Template", la traduction que j’ai donnée est celle officielle.

Les guides d'accessibilité (WCAG)

Comme souvent dans ce genre de situation, le W3C est une source assez complète de documentation qui vous aideront à mettre en place votre modèle d’accessibilité. Cette documentation est rassemblée sous le nom de "Web Content Accessibility Guidelines", et sont évidemment en anglais. Vous pourrez les trouver sur le site officiel.

La catégorie des "certifications volontaires" à base de checklist sont nombreuses en informatique. Peut-être qu’un jour je vous parlerai de l’ASVS pour la sécurité des applications. Mais je peux vous le dire : la checklist du W3C pour l’accessibilité fait partie des listes les plus facilement exploitables.

Comme souvent dans ce genre de situation, les règles sont classées selon des notes "A, AA, AAA" en fonction du niveau d’exigence qu’elles demandent. L’idée, quand vous avez un site web ou une application que vous voulez rendre accessible, vous allez tenter d’abord de remplir tous les critères "A" puis "AA" etc. jusqu’à ce que vous soyez satisfaits ou que vous n’ayez malheureusement plus le budget pour.

Autre intérêt du W3C, il vous donne une liste d’outils qui valideront une ou plusieurs pages de votre site web de manière automatique. J’utilise souvent l’outil portugais "qualweb" qui est présent sur cette page. Il ne scanne qu’une page publique à la foi, mais c’est souvent un bon démarrage sur beaucoup de wordpress sites.

L’avantage de ce site c’est qu’il permet aussi de classifier les règles en quatre catégories qui rappellent que l’accessibilité c’est pas juste "rendre le site utilisable par les aveugles" (c’est un cliché assez moche que ce billet bat en brêche d’ailleurs):

  • Perceivable: est-ce qu’on peut percevoir les informations sur votre site (s’il manque de contraste, même une personne avec 10/10 d’acuité aux deux yeux ne verra pas grand chose, par exemple)
  • Operable: est-ce que votre site est utilisable avec l’ensemble des outils du web (lecteur d’écran, zoom, thèmes fortement contrasté, connexion faible…), vous pouvez déjà vous baser sur ce tuto pour faciliter la navigation au clavier
  • Understandable: est-ce que l’information importante est vue comme importante sur le site? Mettre en gras souligné capital avec une police fancy des informations peu importantes risque de casser cet item
  • Robust: est-ce que naviguer un peu sur votre site ne va pas casser l’utilisabilité (overlay qui bloque les interactions je pense à toi?)

Comme je suppose que vous l’attendez tous, voici le rapport de zds au moment de faire ce billet : https://qualweb.di.fc.ul.pt/evaluator/https%253A%252F%252Fzestedesavoir.com. Cela correspond à certains retours qu’on a déjà eu : pas mal et globalement utilisable mais améliorable.

Si vous avez envie de faire un cadeau de noël aux curieux pour qui internet est parfois une jungle, vous pouvez faire une PR pour corriger un de ces items :).


1 commentaire

Par curiosité j’ai testé une des pages de mon site avec Qualweb. Je pensais naïvement que ça allait être globalement ok, car n’ayant pas une fibre très artistique j’ai tendance à aller au plus simple niveau design. Pas de font fancy, pas trop de couleurs, etc. Eh bien en réalité, même en ne visant que le niveau A il y a déjà pas mal de choses et de subtilités à gérer, même sur un site simple orienté texte.

Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte