Le , par Élie Sloïm - Qualité Web
Avertissement : cet article a été publié en 2016. Son contenu n'est peut-être plus d'actualité.
Il y a quelques mois, nous avons échangé avec l’association Villes Internet pour introduire quelques règles qualité et accessibilité dans leur évaluation. Bien entendu, nul n’est censé ignorer la loi, et l’ensemble des villes Internet doivent depuis quelques années respecter le RGAA, quelle que soit sa version. Et pourtant, j’ai émis l’hypothèse depuis quelques années qu’il y avait un fossé énorme entre le niveau technique exigé pour le déploiement et l’évaluation des référentiels accessibilité dérivés de WCAG (RGAA, Accessiweb) et la réalité du quotidien et des moyens des communes. J’ai donc proposé de tester une première liste de 20 critères (voir la liste en fin de billet) parmi les critères Opquast. Ils sont fondamentaux. J’affirme que s’ils étaient déployés demain sur tous les sites français le bond en matière d’accessibilité serait considérable.
Les villes-Internet au banc d’essai
Nous avons fourni à l’association Villes Internet un extrait du livre qualité Web et l’association a proposé à ses adhérents de remplir un formulaire. La saisie était facultative, pour commencer, une trentaine de villes, souvent moyennes ou grandes ont répondu et les résultats sont très intéressants. Ils sont présentés et commentés dans l’article bonnes pratiques : les villes-Internet au banc d’essai.
Mon analyse de ces résultats :
- Certaines règles comportent des proportions énormes de “ne se prononcent pas”. Il y a deux hypothèses. La première est que la personne qui remplit le formulaire ne sait pas répondre oui ou non. L’autre hypothèse plus inquiétante est que la règle est trop complexe ou mal comprise. Et si c’est le cas avec ces quelques règles, je vous laisse imaginer la tête du répondant en face des WCAG ou d’un de ses dérivés.
- Nos référentiels accessibilité sont trop techniques, ils sont hors sols, nous mettons les responsables de sites devant des murs et malgré tous les efforts de vulgarisation des uns et des autres, lorsque même des personnes avec 15 ans d’expérience sont perdues, l’heure est grave. Je maintiens le constat d’échec ou de demi-échec que j’avais effectué en 2013.
- Les efforts actuels de l’état pour créer un label ayant des niveaux différents des WCAG, plus faciles à atteindre, sont très louables, mais c’est déjà ce que nous avions proposé il y a quelques années, et nous avons perdu presque 10 ans.
- Le problème général n’est pas la culture numérique ou digitale au sens large mais la compréhension des enjeux utilisateurs, qu’ils soient handicapés ou pas.
- Nous n’avons pas encore réussi à développer une culture de la qualité et de l’accessibilité, mais nous allons peut-être y arriver avec le certificat Opquast, qui rentre actuellement très rapidement dans les fondamentaux du Web.
Rendez-vous le 18 février
Nous serons au beffroi de Montrouge le 18 février à l’occasion de la remise du label. L’association remettra une mention Qualité et Accessibilité. C’est un premier pas. Si vous êtes une ville concernée par toutes ces questions, venez nous voir là-bas. Et si vous voulez développer votre culture Qualité et accessibilité Web, intéressez-vous au certificat Opquast ou appelez-nous.
La liste de critères (issue de la checklist Opquast V2) :
- Chaque image est dotée d’une alternative textuelle appropriée
- Le contenu de chaque page est organisé selon une structure de titres et sous-titres hiérarchisée
- Chaque demande d’information fait l’objet d’un accusé de réception.
- Les coordonnées postales et téléphoniques de la représentation locale ou du siège social des sociétés et organisations sont indiquées.
- Le titre de chaque page permet d’identifier son contenu.
- Le titre de chaque page permet d’identifier le site.
- Les sons et vidéos sont déclenchés par l’utilisateur.
- En cas de rejet des données saisies dans un formulaire, les champs contenant les données rejetées sont indiqués à l’utilisateur.
- En cas de rejet des données saisies dans un formulaire, les raisons du rejet sont indiquées à l’utilisateur.
- Chaque champ de formulaire est associé dans le code source à une étiquette qui lui est propre.
- Le libellé de chaque hyperlien décrit sa fonction ou la nature du contenu vers lequel il pointe.
- Le code source de chaque page contient une métadonnée qui en décrit le contenu.
- Le site propose un fichier sitemap indiquant les contenus à explorer.
- Si toutes les pages du site ne sont pas directement accessibles sur la page d’accueil, un plan du site est accessible sur chaque page.
- Chaque page affiche une information permettant de connaître son emplacement dans l’arborescence du site.
- Si toutes les pages du site ne sont pas directement accessibles depuis le plan du site, un moteur de recherche interne est accessible depuis chaque page
- La navigation reste possible sur l’ensemble du site en utilisant exclusivement le clavier
- Les contenus sont présentés avec un contraste suffisant par rapport à leur arrière plan
- Le serveur transmet des contenus compressés aux clients qui les acceptent
- Le serveur envoie une page d’erreur 404 personnalisée