Audit de l’accessibilité de x-tek 

Analyse des résultats

Après avoir testé les pages retenues, nous avons obtenu 70 rapports au format HTML. Les données de ces rapports sont cependant difficilement exploitables en l’état. Nous devons au préalable fusionner ces rapports au sein d’un document unique qui permet ensuite de réaliser une analyse des résultats ; ceci afin de faire remonter les points intéressants concernant les différents modules. Notre analyse est effectuée selon deux points de vue différents :
– Une analyse globale des erreurs, afin de faire ressortir les points communs à l’ensemble des pages.

La fusion des rapports

Afin de rendre exploitables les données des différents rapports, nous les fusionnons dans un unique document facilement manipulable. Nous avons donc décidé de regrouper les rapports dans un document Excel afin de tirer parti des fonctions de tableau croisé dynamique d’Excel.
Il aurait été particulièrement fastidieux de retranscrire les informations des rapports à la main.
C’est pourquoi nous avons rapidement développé un analyseur syntaxique en Java, qui parcourt l’ensemble des rapports présents dans un répertoire, en extrait les informations désirées et les renvoie formatées sur la sortie standard. Nous en profitons pour associer un indice au rapport testé afin de rendre la manipulation des informations plus aisée. L’indice de chaque page est donné dans le Tableau 7.
La sortie est redirigée vers un fichier texte afin d’importer les données dans Excel. Nous différencions les colonnes, à l’aide du caractère séparateur ajouté par notre application lors du formatage des données.

Les données

Nous avons obtenu, après fusion, un fichier Excel contenant 25 055 lignes d’erreurs. Chaque ligne est obtenue à partir d’un rapport TAW basé sur le WCAG 1.0. Les informations composant les lignes d’erreurs sont les suivantes :
– Le nom du rapport de la page testée
– Indice du rapport
– Le nom du module auquel appartient la page testée
– La priorité WCAG 1.0 de l’erreur
– Le point de contrôle auquel est rattachée l’erreur
– La définition de l’erreur
– L’information concernant l’identification automatique ou manuelle de l’erreur
– S’il existe, le numéro de la ligne dans le code source de la page où se situe l’erreur
– Si elle existe, la ligne de code source générant l’erreur
Bien que TAW 3.0 permette de détecter la majeure partie des erreurs, cette application est incapable de révéler toutes les erreurs comme nous avons pu le constater lors de la phase de sélection d’application de test. De plus, dans l’ensemble des erreurs retournées, l’application ne peut en identifier précisément qu’une partie.

Analyse globale

Nous passons maintenant à l’analyse globale des erreurs relevées du point de vue du WCAG 1.0. Nous commençons tout d’abord par mettre en valeur les points intéressants sur l’ensemble des pages testées. Ainsi nous pouvons voir, sur la , la répartition des erreurs selon leur niveau de priorité sur l’ensemble des pages, groupées par module. Cette figure nous permet de constater la répartition inégale des erreurs selon les modules. Les modules formulaire et calendrier possèdent ainsi le plus grand nombre d’erreurs. Nous pouvons aussi constater visuellement la prépondérance d’erreurs de priorité 2, tant manuelles qu’automatiques.

Analyse des modules

Nous analysons, dans cette partie, chaque module individuellement. Afin de faire ressortir les erreurs propres au module étudié, nous ne faisons pas apparaître les erreurs communes à l’ensemble des pages. Nous obtenons alors des graphiques ne comportant que les erreurs du module étudié.

Analyse de la partie Administration

Nous présentons uniquement les erreurs communes à la partie Administration.
Dans la Figure 12, nous mettons en valeur la répartition des erreurs communes à la partie Administration, sans les erreurs communes à l’ensemble des pages, en les groupant par point de contrôle et en différenciant les erreurs automatiques des erreurs manuelles. Nous avons ainsi 38 erreurs communes dont 12 automatiques et 26 manuelles. La majeure partie des erreurs automatiques appartient au point de contrôle 11.2 « Ne pas utiliser de composants obsolètes ou dépréciés ». Elles sont donc liées essentiellement au respect des spécifications du W3C. Ces erreurs sont facilement corrigeables en utilisant un logiciel de validation de code HTML qui permet de signaler les différentes erreurs de respect des spécifications W3C.

Analyse du module « calendrier »

Nous présentons uniquement les erreurs communes au module « calendrier »

Dans la Figure 13, nous mettons en valeur la répartition des erreurs communes au module « calendrier », sans les erreurs communes à l’ensemble des pages, en les groupant par point de contrôle et en différenciant les erreurs automatiques des erreurs manuelles. Nous avons ainsi 177 erreurs communes dont 89 automatiques et 88 manuelles. Comme précédemment, nous avons une forte proportion des erreurs automatiques au niveau du point de contrôle 11.2. Mais nous constatons surtout une majorité d’erreurs liées au point de contrôle 3.4 « Utiliser des unités relatives pour la mise en forme ». Une partie des erreurs du point de contrôle 3.4 seront aussi facilement corrigeables en nous mettant en conformité avec la DTD XHTML 1.0 Transitional qui est la DTD déclarée par XTEK. En effet, une partie de ces erreurs sont liées à l’usage d’unités relatives sur des balises obsolètes en XHTML. Ici encore, l’utilisation d’un logiciel de validation du code HTML facilitera la correction des erreurs.

Analyse du module « dossier liste »

Nous présentons uniquement les erreurs communes au module « dossier liste ». Dans la Figure 14, nous mettons en valeur la répartition des erreurs communes au module « dossier liste », sans les erreurs communes à l’ensemble des pages, en les groupant par point de contrôle et en différenciant les erreurs automatiques des erreurs manuelles. Nous avons ainsi 133 erreurs communes dont 63 automatiques et 70 manuelles. Nous retrouvons encore la majorité des erreurs automatiques sur les points de contrôle 3.4 et 11.2.

Analyse du module « dossier menu »

Nous présentons uniquement les erreurs communes au module « dossier menu ». Dans la Figure 15, nous mettons en valeur la répartition des erreurs communes au module « dossier menu », sans les erreurs communes à l’ensemble des pages, en les groupant par point de contrôle et en différenciant les erreurs automatiques des erreurs manuelles. Nous avons ainsi 134 erreurs communes dont 47 automatiques et 87 manuelles. Nous relevons deux points de contrôle regroupant le maximum d’erreurs automatiques. Nous avons toujours le point de contrôle 11.2, mais nous avons aussi le 1.1 « Fournir une alternative textuelle aux éléments non textuels ». Ce dernier concerne toutes les images et les contenus textuels à l’intérieur des images. Nous pouvons remarquer que le volume des erreurs automatiques et le volume des erreurs manuelles sur le point de contrôle 1.1 sont égaux. En effet, les erreurs automatiques reposent essentiellement sur la présence d’une alternative textuelle pour un contenu non textuel, alors que les erreurs manuelles nécessitent, quant à elles, une vérification sur la nécessité d’une description longue pour ces images. Ainsi, nous avons généralement 2 erreurs par image pour ce point de contrôle. Il est à noter aussi que les descriptions longues sont rarement utiles, ce qui implique que le nombre réel d’erreurs manuelles pour ce point de contrôle est souvent nul.

Analyse du module « dossier une seule page »

Nous présentons uniquement les erreurs communes au module « dossier une seule page ». Il est à noter que nous ne prenons pas en compte la page d’accueil qui semble avoir un comportement à part des autres pages « dossier une seule page ». En effet, elle s’approche beaucoup trop des erreurs communes à l’ensemble des pages, ce qui n’a pas d’intérêt pour nous et occulterait les points communs à toutes les autres pages. Dans la Figure 16, nous mettons en valeur la répartition des erreurs communes au module « dossier une seule page », sans les erreurs communes à l’ensemble des pages, en les groupant par point de contrôle et en différenciant les erreurs automatiques des erreurs manuelles. Nous avons ainsi 125 erreurs communes dont 25 automatiques et 100 manuelles. Les erreurs portent essentiellement sur les points 1.1 et 6.3 « Proposer une alternative au code javascript et aux éléments programmables »

Analyse du module « formulaire »

Nous présentons uniquement les erreurs communes au module « formulaire ». Dans la Figure 18, nous mettons en valeur la répartition des erreurs communes au module « formulaire », sans les erreurs communes à l’ensemble des pages, en les groupant par point de contrôle et en différenciant les erreurs automatiques des erreurs manuelles. Nous avons ainsi 184 erreurs communes dont 90 automatiques et 94 manuelles. Comme pour les modules « dossier liste » et calendrier, les points de contrôle comportant le plus d’erreurs sont les points 3.4 et 11.2. Nous en tirons les mêmes conclusions, c’est-à-dire la possibilité de corriger ces erreurs à l’aide d’un logiciel de validation du code HTML

Analyse du module « messagerie »

Nous présentons uniquement les erreurs communes au module « messagerie ».
Dans la Figure 20, nous mettons en valeur la répartition des erreurs communes au module « messagerie », sans les erreurs communes à l’ensemble des pages, en les groupant par point de contrôle et en différenciant les erreurs automatiques des erreurs manuelles. Nous avons ainsi 194 erreurs communes dont 89 automatiques et 105 manuelles. Comme sur le module précédent, nous avons aussi une majorité d’erreurs sur les points de contrôles 3.4 et 11.2. Nous avons aussi des erreurs sur le point de contrôle 5.5 « Donner des informations complémentaires sur les tableaux de données » liées à l’utilisation de tableaux à des fins de présentation. TAW ne pouvant pas faire la différence entre un tableau de données et un tableau de présentation, il signale alors des erreurs comme l’absence de titre, de résumé de tableau et bien d’autres. La correction de la structure de la page, en passant d’une présentation par tableau à une présentation entièrement conçue à l’aide d’une feuille de style, permettra de résoudre ces erreurs. Nous avons aussi des erreurs sur le point de contrôle 6.1 « Maintenir la lisibilité et la compréhension des contenus lorsque les styles sont désactivés » liées à l’usage des styles dans le code source. TAW nous demande de vérifier la lisibilité de la page lorsque les styles sont désactivés. Il nous faudra passer l’ensemble des styles du code source vers les feuilles de style.

Analyse du module « trombinoscope »

Nous présentons uniquement les erreurs communes au module « trombinoscope ».
Dans la Figure 21, nous mettons en valeur la répartition des erreurs communes au module « trombinoscope », sans les erreurs communes à l’ensemble des pages, en les groupant par point de contrôle et en différenciant les erreurs automatiques des erreurs manuelles. Nous avons ainsi 166 erreurs communes dont 86 automatiques et 80 manuelles. Comme pour le module « messagerie », nous avons essentiellement des erreurs sur les points de contrôle 3.4, 11.2, 5.5 et 6.1.

Analyse du module « flux rss »

Nous présentons uniquement les erreurs communes au module « flux rss ». Il faut cependant prendre en compte le fait que nous ne possédons qu’une seule page testée pour ce module, ce qui ne permet aucunement de déduire quoi que ce soit concernant les erreurs communes à ce module.
Dans la Figure 22, nous mettons en valeur la répartition des erreurs communes au module « flux rss », sans les erreurs communes à l’ensemble des pages, en les groupant par point de contrôle et en différenciant les erreurs automatiques des erreurs manuelles. Nous avons ainsi 316 erreurs communes dont 136 automatiques et 180 manuelles. La majorité des erreurs se situe sur les points de contrôle 11.2, 3.4, 3.3 « Privilégier l’utilisation des styles CSS pour la mise en forme » et 10.1 « Signaler l’ouverture de nouvelles fenêtres ». Les erreurs 3.3 sont dues à l’utilisation de balises HTML de mise en forme dépréciées telles que la balise « font » et des attributs tels que « color ». Ces erreurs sont aisément corrigeables en passant entièrement la mise en forme en feuilles de style et en faisant disparaître les balises et attributs dépréciés. Les erreurs du point de contrôle 10.1 sont dues aux liens des flux RSS qui, pour permettre la consultation des pages qu’ils pointent, ouvrent une nouvelle fenêtre. En faisant en sorte de fournir une information sur lien avertissant de l’ouverture d’une nouvelle fenêtre, nous apporterons une solution à ces erreurs.

Synthèse

Après cette analyse des données, nous allons maintenant synthétiser ces informations afin d’en extraire les points les plus importants, pour préconiser des solutions d’amélioration de l’accessibilité. Nous commencerons par exploiter les résultats de l’analyse et nous donnerons nos conclusions.

Exploitation

Nous avons mis en valeur, précédemment, des informations intéressantes concernant les erreurs communes à chaque module, sans les erreurs communes à l’ensemble des pages et les erreurs communes à l’ensemble des pages testées. Dans le Tableau 10, nous mettons en valeur la part des erreurs communes dans l’ensemble des erreurs des pages testées. On peut constater aisément que les 92 erreurs communes à toutes les pages représentent à elles seules 25% de l’ensemble des erreurs des pages testées. De plus, l’ensemble des erreurs communes, soit 2099, représentent 61% des erreurs des pages testées.
Nous pouvons maintenant mettre en valeur la part des erreurs communes dans l’ensemble des erreurs par module. Pour ce faire, nous additionnons aux erreurs communes propres au module, les erreurs communes à l’ensemble des pages comme nous pouvons le voir dans le Tableau 12. Nous ne tenons pas compte des modules « page web », « flux rss » et « liste des utilisateurs » qui, ne comportant qu’une seule page dans notre test, donnent un rapport de 100%. Nous avons de même exclu la page d’accueil pour son fonctionnement particulier. Nous pouvons cependant constater que les erreurs communes représentent en général plus de 50% des erreurs des modules à l’exception du module calendrier. Il est intéressant de noter que le calendrier représente une grande part des erreurs mais ses erreurs communes ne correspondent qu’à 35% des erreurs du module. Ce module demandera donc le plus de travail pour le rendre accessible.

Conclusions

Bien que nous ayons relevé 25055 erreurs pour 70 pages testées, soit 358 erreurs par page, la tâche de mise en conformité n’est pas insurmontable. En effet, l’outil X-TEK étant de conception modulaire, nous avons pu découper l’analyse en nous axant sur les modules. Nous avons pu mettre en évidence les erreurs communes aux pages des modules et les erreurs communes à l’ensemble des modules qui correspondent, en grande partie, à la charte graphique. Nous en avons déduit qu’en corrigeant les 2099 erreurs communes identifiées, nous pouvons corriger 61% des 25055 erreurs relevées.
Nous avons aussi identifié le pourcentage d’erreurs que nous pouvons corriger dans chaque module, dans un premier temps, en nous focalisant uniquement sur les erreurs communes. Par la même, nous avons pu identifier les modules demandant le plus de travail pour être mis en conformité.
Enfin, nous avons aussi pu constater le problème de génération de contenu accessible de l’éditeur de texte enrichi embarqué dans X-TEK. Il est indéniable qu’il faudra trouver un nouvel éditeur afin de garantir l’accessibilité des plateformes générées.

Mise en conformité

Nous allons, dans un premier temps, présenter le fonctionnement de X-TEK afin de donner une vue plus concrète des parties de l’application sur lesquelles nous allons travailler. Puis nous présenterons le déroulement de la mise en conformité suivi de l’application des tests RGAA 2.2. Ensuite, nous aborderons notre recherche d’un nouvelle éditeur de texte enrichi et nous finirons par la présentation de nos résultats, lors de la réunion marquant la fin de la mise en conformité du module « dossier une seule page » de X-TEK.

Étude du fonctionnement de X-TEK

Afin de fournir une vue plus concrète de l’application, nous présentons brièvement le fonctionnement de X-TEK à travers la partie graphique et le code source. Nous terminons par une présentation du patron de conception rencontré lors de la mise en conformité.

Partie graphique

La partie graphique de X-TEK repose sur l’utilisation de templates et de feuilles de styles.
Pour mettre en œuvre son système de templates, X-TEK utilise le moteur de Template Smarty en version 2.6.7. La structure de la page s’articule autour des 4 templates « haut.tpl », « bas.tpl », « menu.tpl » et « menua.tpl ».
Le template « haut.tpl » est appelé en premier et gère la barre d’outils, les rubriques, les sousrubriques et la barre de boutons d’administration. Le template « bas.tpl » est appelé après la zone dynamique et gère le logo, l’appel aux différents menus, les publications, la recherche et la zone de pied de page. Le template « menu.tpl » gère le menu des pages standard tandis que le template « menua.tpl » gère le menu de la partie administration de la plateforme. La Figure 25 décrit le découpage type des différents templates. Les données des templates sont générées par l’application et transférées aux templates en initialisant des variables utilisées par Smarty.
Le contenu propre de la page n’est pas géré par les templates et est directement introduit entre le template « haut.tpl » et « bas.tpl » dans la zone dynamique. Le code HTML est, dans ce cas, produit à partir du code PHP et/ou récupéré en base de données. La mise en forme de la page est gérée à l’aide des deux feuilles de styles « index.css » et « default.css ».

Déroulement de la mise en conformité

La mise en conformité s’est déroulée de manière itérative, en commençant par la mise en conformité de la page d’accueil, afin de rendre la charte graphique accessible. Puis, nous avons élargi la mise en conformité à différentes pages simples, aux pages contenues dans les « dossier menu » et « dossier liste », pour terminer par les pages de consultation des formulaires.
Nous avions débuté la mise en conformité en nous appuyant sur le RGAA 1.0. Puisque nous avons connu une évolution du RGAA au cours de notre mise en conformité, nous avons alors repris entièrement ce qui a été fait en appliquant le RGAA 2.2. Faute d’outil d’analyse de l’accessibilité selon le WCAG 2.0, nous avons entrepris une analyse manuelle systématique des pages, en nous appuyant sur les 187 tests du RGAA 2.2 permettant de valider les critères de succès du WCAG 2.0 (Cf. annexe 2).
Comme il nous l’avait été demandé, nous avons autant que possible essayé de respecter l’apparence de la charte graphique précédant la mise en conformité, ainsi que le fonctionnement global de l’application.
Tout au long de cette mise en conformité, nous nous sommes formés en nous appuyant sur les ressources disponibles sur les sites traitant de l’accessibilité et du respect des standards [ALSAC1] [OPENW1].

Application des tests

Le RGAA 2.2 propose d’offrir une application concrète du WCAG 2.0. Pour ce faire, il décompose les critères d’accessibilité du WCAG 2.0 en différents tests. Cependant selon les critères d’accessibilité, ces tests s’étendent sur une trop grande plage de domaines techniques.
Le RGAA les a alors regroupés en thématiques. Nous avons alors déroulé ces tests selon ces thématiques.
Pour chaque test, le RGAA nous renvoie vers les techniques du WCAG 2.0 correspondantes. [TWCAG2] Ces techniques se décomposent ainsi.

Thématique « Navigation »

Cette thématique vise à garantir une navigation aisée à travers la page et dans les liens vers d’autres documents ou pages. Il existe 36 tests que nous pouvons regrouper en 7 sous-ensembles de cette thématique.

Accessibilité des liens doublant les zones cliquables côtés serveur

Afin de rendre accessibles les « zones cliquables » côté serveur comme les régions sélectionnables d’une image utilisant l’attribut « ismap », il nous est demandé de doubler les « zones cliquables » en fournissant, immédiatement après l’image, des liens remplissant le même rôle.
Au niveau de X-TEK, il n’existe pas de cas concret d’image exploitant les « zones cliquables » côté serveur. Toutefois, puisqu’il est possible pour un contributeur d’importer du code HTML, il nous faut tout de même évoquer leur possible utilisation dans X-TEK. La seule solution est de rappeler aux contributeurs de penser à doubler les « zones cliquables » avec des liens.

Identification du rôle des liens

Selon le handicap de l’utilisateur ou son mode de consultation du site Web, il est possible qu’il ne puisse pas saisir parfaitement le rôle des différents liens qui lui sont présentés. Une personne souffrant d’un déficit visuel peut ne pas percevoir le site comme un utilisateur ayantune bonne  vision. Son approche sera séquentielle et il n’aura pas accès au contexte visuel.
Par exemple, un site Web propose le téléchargement d’un logiciel. Il affiche en début de page, le nom du logiciel suivi d’une description et enfin, le lien permettant le téléchargement intitulé simplement « télécharger ». Un utilisateur sans déficience aura visuellement accès au nom du logiciel et au lien téléchargé, et il comprendra aisément que ce lien permet de télécharger le logiciel.

Table des matières
REMERCIEMENTS 
TABLE DES MATIERES 
LISTE DES FIGURES 
LISTE DES TABLEAUX 
LISTE DES ABREVIATIONS ET ACRONYMES
1. INTRODUCTION 
1.1. Contexte
1.2. Objectif du stage
1.3. Présentation de X-TEK
1.3.1. Les CMS
1.3.2. X-TEK
1.4. Plan du Mémoire
2. RAPPEL SUR L’ACCESSIBILITE DU WEB 
2.1. Les normes
2.1.1. WCAG 1.0
2.1.2. WCAG 2.0
2.2. Les référentiels d’accessibilité de la DGME
2.2.1. RGAA 1.0
2.2.2. RGAA 2.2
2.3. Synthèse
3. AUDIT DE L’ACCESSIBILITE DE X-TEK 
3.1. Mise en place d’une plateforme de test
3.1.1. Les différents modules disponibles
3.1.2. La structure de la plateforme de test
3.2. La recherche de logiciels de tests d’accessibilité
3.3. Analyse des résultats
3.3.1. La fusion des rapports
3.3.2. Les données
3.3.3. Analyse globale
3.3.4. Analyse des modules
3.4. Synthèse
3.4.1. Exploitation
3.4.2. Conclusions
3.5. Recommandations générales
3.6. Définition du plan de mise en conformité
3.7. Conclusion
4. MISE EN CONFORMITE 
4.1. Étude du fonctionnement de X-TEK
4.1.1. Partie graphique
4.1.2. Code source
4.1.3. Patron de conception
4.2. Déroulement de la mise en conformité
4.3. Application des tests
4.3.2. Thématique « Navigation »
4.3.3. Thématique « Scripts »
4.3.4. Thématique « Images »
4.3.5. Thématique « Couleurs »
4.3.6. Thématique « Présentation »
4.3.7. Thématique « Structure »
4.3.8. Thématique « Tableau »
4.3.9. Thématique « Texte »
4.3.10. Thématique « Formulaire »
4.3.11. Thématique « Cadre »
4.3.12. Thématique « Multimédia »
4.4. Recherche d’un nouvel éditeur de texte enrichi
4.5. Présentation des résultats
4.6. Synthèse
5. CONCLUSION
5.1. Rappel des objectifs
5.2. Travail réalisé
5.3. Perspectives
5.4. Bilan personnel
6. BIBLIOGRAPHIE
7. ANNEXES
7.1. Annexe 1 : Points de contrôle du WCAG 1.0
7.2. Annexe 2 : Critères de succès du WCAG 2.0
7.3. Annexe 3 : Outils testés
7.3.1. Outils testés et retenus
7.3.2. Outils testés et non retenus

Lire le rapport complet