conceptiondepluginsdecorrectionde … · 2010. 4. 12. · clavierbraille(référence : braillex duo...

École Polytechnique de l’Université de Tours64, Avenue Jean Portalis37200 TOURS, FRANCETél. +33 (0)2 47 36 14 14Fax +33 (0)2 47 36 14 22

www.polytech.univ-tours.fr

Département Informatique5ème année2008-2009

Rapport de projet de fin d’études

Conception de plugins de correction depages web afin qu’elles respectent les

normes d’accessibilitéÉtudiant :Jonathan [email protected]

Encadrants :Sonia Colas

[email protected] Monmarché

[email protected] Slimane

[email protected]é François-Rabelais, Tours

Version du 20 mai 2009

http://www.polytech.univ-tours.fr

mailto:[email protected]




Table des matières

Remerciement 8

Introduction 9

1 Etat de l’art 111.1 L’accessibilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2 Le contexte général : L’accessibilité numérique . . . . . . . . . . . . . . . . . . . . . . . . 111.3 Le contexte restreint : L’accessibilité du Web . . . . . . . . . . . . . . . . . . . . . . . . . 121.4 Le contexte légal et organisationnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.4.1 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.4.2 La legislation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.4.3 Les associations et sociétés spécialisées . . . . . . . . . . . . . . . . . . . . . . . . 15

1.5 Dans la pratique : un site accessible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.5.1 Les avantages d’un site accessible . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.5.2 Les techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.5.3 Les validateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.5.4 Les correcteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2 Présentation du projet 202.1 Le sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.2 Définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.3 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.3.1 Présentation générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.3.2 Technologies utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.3.3 Présentation détaillée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.4 Travail à réaliser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.4.1 Présentation générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.4.2 Amélioration / correction de l’existant . . . . . . . . . . . . . . . . . . . . . . . . 352.4.3 Technologies utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3 Travail réalisé 393.1 Correction de bugs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.1.1 Problèmes de génération . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.1.2 Problèmes d’interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.2 Améliorations apportées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.2.1 Organisation des plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.2.2 Multisélection des plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.2.3 Gestion multilangue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.2.4 Plugins existants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.3 Plugins réalisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.3.1 Directive 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Plugins d’accessibilités III

TABLE DES MATIÈRES

3.3.2 Directive 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.4 Collaboration des PFE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

3.4.1 Le PFE de Jérôme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643.4.2 Le PFE de Claire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643.4.3 L’installation du webservice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653.4.4 Intégration à la spécification 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 653.4.5 Résultat de l’intégration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

3.5 Manuels et documentations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

4 Tests et analyse des résultats 694.1 Les validateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.2 Les statistiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704.3 Les bases de tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

4.3.1 Les sites généraux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.3.2 Les sites par spécification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744.3.3 Test de la directive 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754.3.4 Test de la directive 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Conclusion 78

A Cahier des charges 80A.1 Validation et Historique du cahier des charges . . . . . . . . . . . . . . . . . . . . . . . . 80

A.1.1 Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80A.1.2 Historique des modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

A.2 Préambule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81A.2.1 Présentation du Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81A.2.2 Conventions et terminologie utilisées dans le document . . . . . . . . . . . . . . . 81

A.3 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82A.3.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82A.3.2 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82A.3.3 Description de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

A.4 Description de l’environnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84A.4.1 Les acteurs du logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84A.4.2 Les relations entre les acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

A.5 Expression des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86A.5.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86A.5.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

A.6 Contraintes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88A.6.1 Contraintes techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88A.6.2 Contraintes d’interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88A.6.3 Contraintes temporelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88A.6.4 Maintenance et évolutivité du logiciel attendu . . . . . . . . . . . . . . . . . . . . 88

A.7 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89A.7.1 Documents de spécification, de conception,. . .attendus . . . . . . . . . . . . . . . 89A.7.2 Manuels utilisateurs, procédures d’installation, gestion du système . . .attendus . . . 89

A.8 Plan de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90A.8.1 Proposition de planning du développement . . . . . . . . . . . . . . . . . . . . . . 90A.8.2 Plan d’assurance qualité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

IV Plugins d’accessibilités

TABLE DES MATIÈRES

B Rubrique d’aide 92

C Manuel développeur 95C.1 Création de plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

C.1.1 Création du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95C.1.2 Création du contenu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95C.1.3 Création du Jar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

D Bases des sites tests 101D.1 Les sites d’Indre et Loire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101D.2 Les sites tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Références bibliographiques 104

Plugins d’accessibilités V

Table des figures

1.1 Différents appareils permettant aux handicapés d’accéder à l’outil informatique . . . . . . . 12

2.1 Application en mode graphique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.2 L’interface de la spécification 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.3 L’interface de la spécification 5.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.4 L’interface de la spécification 5.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.5 L’interface de la spécification 5.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.6 L’interface de la spécification 6.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.7 Diagramme d’utilisation de l’application existante . . . . . . . . . . . . . . . . . . . . . . 292.8 Schéma du fonctionnement de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . 302.9 Diagramme de classe de l’application existante . . . . . . . . . . . . . . . . . . . . . . . . 322.10 Interface du plugin de la spécification 1.1 (pour définir un texte alternatif aux image), (a)

sans puis (b) avec utilisation préalable du plugin d’intégration des images . . . . . . . . . 332.11 L’interface de l’outil statistique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.12 Répartition des erreurs (a) et des warnings (b) des sites web publics d’Indre-et-Loire entre

les directives WCAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.13 Problème de redimensionnement lors de l’utilisation d’une URL longue . . . . . . . . . . . 352.14 Liste utilisée par le PFE précédent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.1 Présentation des problèmes de générations découverts, (a) exception sans fichier d’entrée(b) compte-rendu vide sans plugin sélectionné . . . . . . . . . . . . . . . . . . . . . . . . 39

3.2 Messages d’erreurs mis en place pour sécuriser la génération, (a) si aucun fichier n’est séléc-tionné (b) si aucun plugin n’est séléctionné . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.3 Création systématique d’un fichier de sortie à la racine du projet, (a) le label ”Fichier desortie” (b) le fichier généré . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.4 Problème de redimensionnement lors de l’utilisation d’une URL longue . . . . . . . . . . . 413.5 Gestion des plugins à la reprise du PFE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.6 Passage d’un jListe à un jTree pour le moteur . . . . . . . . . . . . . . . . . . . . . . . . 433.7 Diagramme de classe de JTree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.8 Diagramme de classe des plugins avant la modification . . . . . . . . . . . . . . . . . . . 443.9 Diagramme de classe des plugins après la modification . . . . . . . . . . . . . . . . . . . . 443.10 Illustration de l’algorithme de parcours . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.11 Gestion des plugins après l’implémentation de JTree . . . . . . . . . . . . . . . . . . . . . 463.12 La fenêtre d’option permettant de choisir la langue de la plateforme . . . . . . . . . . . . 483.13 Extrait du fichier de traduction de l’application en Anglais . . . . . . . . . . . . . . . . . . 493.14 Image représentant le plan d’une ferme avec 6 zones cliquables pour accéder aux pages du site 533.15 Fenêtre de choix d’un titre pour une zone cliquable . . . . . . . . . . . . . . . . . . . . . 543.16 Fenêtre de choix d’un titre pour un input de type image . . . . . . . . . . . . . . . . . . . 553.17 IHM de la balise applet, (a) la popup permettant d’ouvrir l’applet et d’écrire le texte alternatif

(b) l’applet ouvert dans un navigateur web . . . . . . . . . . . . . . . . . . . . . . . . . . 553.18 Fenêtre permettant de commenter ou pas la balise embed . . . . . . . . . . . . . . . . . . 563.19 Fenêtre permettant de founir une alternative textuelle à un bouton . . . . . . . . . . . . . 56

VI Plugins d’accessibilités

TABLE DES FIGURES

3.20 Répartition des erreurs (a) et des warnings (b) de la directive 3 (par spécification) . . . . . 573.21 Aperçu de l’IHM de la spécification 3.2 permettant d’ajouter un DOCTYPE . . . . . . . . 583.22 Aperçu de l’IHM de la spécification 3.2 affichant un rapport de détection de plusieurs DOC-

TYPES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.23 Aperçu de l’IHM de la spécification 3.3 en mode classique . . . . . . . . . . . . . . . . . . 613.24 Aperçu de l’IHM de la spécification 3.3 en mode édition de code destination . . . . . . . . 623.25 Aperçu de l’IHM de la spécification 3.3 en mode visualisation de code source . . . . . . . . 623.26 Aperçu de l’IHM de la spécification 3.5 en mode manuel . . . . . . . . . . . . . . . . . . 643.27 Schéma de collaboration avec le PFE de Jérôme . . . . . . . . . . . . . . . . . . . . . . . 653.28 Présentation de l’ihm de la spécification 1.1 pour une image nommée next.jpg . . . . . . . 673.29 Fenêtres accessibles par le menu Aide (a) rubrique d’aide (b) rubrique à propos . . . . . . 68

4.1 Les outils de validations testés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.2 Schéma d’utilisation conjointe du validateur et du parseur pour obtenir des statistiques . . 704.3 Interface du parseur de la page HTML résultat . . . . . . . . . . . . . . . . . . . . . . . . 704.4 Extrait d’un fichier excel généré à partir du parseur de résultats de validation du site internet

de Polytech’Tours (évaluation réalisée le 22 janvier 2009) . . . . . . . . . . . . . . . . . . 714.5 Répartition des erreurs (a) et des warnings (b) des sites web publics d’Indre-et-Loire entre

les directives WCAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.6 Répartition des erreurs (a) et des warnings (b) des sites web récents . . . . . . . . . . . . 734.7 Nombre d’erreurs et de warnings avant correction sur les 30 sites récents . . . . . . . . . . 754.8 Nombre d’erreurs et de warnings après correction sur les 30 sites récents . . . . . . . . . . 76

A.1 La plateforme à la fin du PFE précédent (juin 2007) . . . . . . . . . . . . . . . . . . . . . 83A.2 L’environnement du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84A.3 Planning du PFE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

B.1 Interface de la plateforme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

C.1 Création d’un nouveau projet 1/6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96C.2 Création d’un nouveau projet 2/6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97C.3 Création d’un nouveau projet 3/6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97C.4 Création d’un nouveau projet 4/6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98C.5 Création d’un nouveau projet 5/6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98C.6 Création d’un nouveau projet 6/6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99C.7 Aperçu du code d’un nouveau plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99C.8 Fichier Jar du nouveau plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100C.9 Nouveau plugin reconnu par la plateforme de traitement . . . . . . . . . . . . . . . . . . . 100

D.1 Base des sites d’Indre et Loire 1/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101D.2 Base des sites d’Indre et Loire 2/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102D.3 Base des sites tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Plugins d’accessibilités VII

Remerciement

Je tiens à remercier, tout d’abord, l’ensemble des membres de l’équipe ”Handicap et Nouvelles Tech-nologies” du laboratoire informatique de l’Ecole Polytechnique Universitaire de Tours, et particulièrementSonia Colas, responsable de ce projet et docteur en informatique à l’Université François Rabelais de Tourspour son suivi et ses conseils qui m’ont permis de mener à bien ce projet.

Je remercie également Nicolas Monmarché, maître de conférences en Informatique, et Mohamed Slimane,professeur en Informatique, de l’Université de Tours pour m’avoir permis d’effectuer ce projet de fin d’etudeau sein de leur équipe.

8 Plugins d’accessibilités

Introduction

L’accès à l’outil informatique pour les personnes malvoyantes et non-voyantes a évolué depuis les der-nières années et l’on voit apparaître un grand nombre de technologies d’interface. Ces outils tels que lestablettes brailles et les synthétiseurs vocaux permettent aux personnes atteintes de ce type d’handicap d’uti-liser un ordinateur de façon autonome. Cependant l’accès à l’information disponible sur internet n’est pasaccessible de la même manière. Il existe des applications tels que les navigateurs textuels ou des logicielsde parcours de site qui permettent d’aider ces personnes à naviguer sur internet, mais la façon dont sontprogrammés les sites internet est également très importante. Les difficultés de compatibilité des deux rendentla navigation délicate pour ces individus malvoyants et non-voyants.

Dans un souci de faire évoluer internet dans ce sens, un certain nombre de normes ont été mises en placeau niveau national dans les différents pays et également au niveau international. Ces normes ont été établiesdans l’objectif d’assurer la compatibilité entre le code écrit pour générer un site internet et les applicationsdestinées à interpréter ce code. Le W3C (World Wide Web Consortium) qui est l’organisme de normalisationdes technologies du web au niveau international a crée une cellule s’occupant de l’accessibilité du web, WAI(Web Accessibility Initiative) qui a elle- même créé des guides expliquant aux webmasters comment rendreleurs pages accessibles, les WCAG (Web Content Accessibility Guidelines). Ces guides sont cependant trèscomplexes de par leur aspect très technique sur les technologies du web et l’intervention d’un informaticienspécialisé est souvent nécessaire pour rendre un site accessible.

Les nouvelles technologies du web 2.0 telles que les vidéos, les scripts et le flash ont accentué de manièreimportante cette inaccessibilité présente sur internet. Internet, en tant qu’outil disponible pour tous, joueactuellement un rôle majeur dans la transmission de l’information. Pour que cela soit également le cas pourles personnes handicapées, tous les sites web devraient respecter les normes établies. Vu la complexité desces normes, il est devenu important et urgent de mettre à disposition des webmestres amateurs, s’ils désirentrendre leur site accessible, un outil leur permettant un développement simpliste de celui-ci.

Sujet du PFE

Ce projet de fin d’études a été encadré par Sonia Colas, docteur en informatique à l’Université FrançoisRabelais de Tours, et a été co-encadré par Nicolas Monmarché, maître de conférences en informatique, etMohamed Slimane, professeur en informatique, de l’Université de Tours au sein de l’équipe Handicap etNouvelles Technologies (HaNT ). Cette équipe s’oriente principalement sur l’aide aux personnes handica-pées pour l’utilisation d’outils informatiques (internet, jeux vidéo, ...) ainsi que sur les nouvelles technologies(technologie du web, sécurité dans les réseaux, ...). Les outils utilisés dans cette équipe sont l’intelligenceartificielle, comprenant les algorithmes génétiques et les fourmis artificielles, et également la modélisationmathématique comme les chaînes de Markov cachées.

Ce projet reprend celui réalisé par Antoine Blais lors de son PFE durant l’année 2006-2007. Lors de ceprojet, il a réalisé une plateforme de traitement de pages web permettant de corriger leurs codes HTML selondifférents plugins appliqués à celles-ci. Il a également commencé à développer quelques plugins liés à desspécifications des WCAG. Mon projet a pour objectif de continuer le développement des plugins des spécifi-cations des WCAG et de reprendre la plateforme pour corriger un certains nombre de problèmes rencontréset l’améliorer. Une fois ces développements mis en place, je mettrais à jour les documents utilisateurs et

Plugins d’accessibilités 9

Introduction

développeurs qui ont été réalisés par Antoine.

Organisation du document

Ce document est structuré en 4 chapitres. Le premier chapitre s’intéresse à l’état de l’art concernant lesdomaines de l’accessibilité et plus précisément l’accessibilité du web qui constitue l’objet de ce projet. Cechapitre est centré sur l’accessibilité des pages web pour les personnes malvoyantes et non-voyantes et faitégalement référence au contexte légal et organisationnel. De plus, il présente ce qu’est un site accessibledans la pratique et les moyens mis à disposition des webmasters pour leur faire évoluer dans ce sens. Lesecond chapitre présente le projet en définissant les termes importants et en détaillant le sujet de façonprécise. Cette présentation est accompagnée d’une étude de l’existant et d’une partie présentant le travailqui était à réaliser dans ce projet de fin d’études. Le troisième chapitre explique l’ensemble du travail réalisétout au long de l’année en décrivant la correction des bugs, les améliorations effectuées, les plugins réaliséset les documents mis à jour. Le quatrième et dernier chapitre décrit les phases de tests réalisés au cours dece projet pour valider les objectifs : les différents validateurs utilisés pour faire les vérifications, les bases detests mises en place, et enfin les résultats obtenus pour les plugins développés. Une conclusion dresse unbilan sur l’ensemble des travaux présentés dans les chapitres 3 et 4 de ce document et définit les perspectivesd’avenir pour le projet.

Ce document comporte 4 annexes. La première annexe représente le cahier des charges établit au début dece projet et définissant l’ensemble des besoins du client. La seconde annexe est une rubrique d’aide destinéeaux webmasters utilisant la plateforme de traitement pour mieux comprendre l’ensemble des possibilitésqu’elle offre. La troisième annexe correspond à un manuel pour les futurs développeurs du projet expliquantcomment réaliser un plugin en java indépendamment du moteur de l’application. La quatrième et dernièreannexe liste les sites internet utilisés pour la base de tests destinée à valider le code développé au sein de ceprojet. Une bibliographie complète permettra aux lecteurs de retrouver facilement l’ensemble des référencesdécrites dans ce document.


CHAPITRE 1

Etat de l’art

Le terme principal de ce projet est l’accessibilité, c’est pourquoi nous allons replacer cette notion dansdifférents contextes. Tout d’abord dans la vie de tous les jours, puis au niveau de l’informatique de manièregénérale, et pour terminer nous nous attarderons sur l’accessibilité du Web qui est le thème de ce projet. Parla suite, nous parlerons de la législation en vigueur pour l’accessibilité d’Internet et nous verrons ce qu’estun site web accessible dans la pratique.

1.1 L’accessibilité

Définition de l’AFNOR (2000) :

« L’accessibilité au cadre bâti, à l’environnement, à la voirie et aux transports publics ouprivés, permet leur usage sans dépendance par toute personne qui, à un moment ou à unautre, éprouve une gêne du fait d’une incapacité permanente (handicap sensoriel, moteur oucognitif, vieillissement...) ou temporaire (grossesse, accident...) ou bien encore de circonstancesextérieures (accompagnement d’enfants en bas âge, poussettes...) »

Cela signifie qu’il est important que dans la société actuelle, tous les individus aient accès aux services,produits, lieux de travail et environnement. Pour satisfaire cela, il est nécessaire de rendre ces accès possiblesde manière individuelle pour des personnes dans l’incapacité de le faire dans une démarche commune. Cettenotion est d’autant plus importante aujourd’hui du fait d’un vieillissement de la population mondiale etde l’augmentation du nombre d’handicapés. Si l’on prend le cas de la France uniquement, la proportiondes 60 ans et plus dans la population totale est passée de 18% en 1970 à 21% en 1999 (Source : Comitédépartemental d’éducation pour la santé des Yvelines) et plus d’un français sur quatre (26,4%) souffre d’uneincapacité, d’une limitation d’activité ou d’un handicap (Source : INSEE).

Nous allons à travers ce projet de fin d’étude essayer d’améliorer l’accessibilité informatique et plusparticulièrement l’accessibilité d’Internet et de ces pages web.

1.2 Le contexte général : L’accessibilité numérique

Le domaine de l’informatique ne touche pas l’ensemble des handicapés mais seulement une partie. En ef-fet, une personne en fauteuil roulant (suite à une paralysie des jambes) pourra accéder à l’outil informatiquede la même façon qu’une personne non handicapée. Les personnes les plus touchées sont les mal-voyants nepouvant lire ce qui est affiché à l’écran (personnes âgées, aveugles, ...), les personnes ne pouvant manipulerune souris ou un clavier (personnes atteintes de la maladie de Parkinson, handicapés moteurs, ...) ou encoreles personnes ne pouvant entendre ce qui est transmis de manière orale (personnes mal-entendantes, sourds,...).

La figure 1.1 présente quelques appareils permettant aux mal-voyants et aux handicapés moteurs d’ac-céder à l’outil informatique. De gauche à droite, un système de lecture autonome avec synthèse vocale(Référence : POET COMPACT de la société Baum) permet à un mal-voyant de lire un document papier, unclavier braille (Référence : BRAILLEX Duo de la société Papenmeier) utilisé par les non-voyants pour naviguer


Chapitre 1. Etat de l’art

sur un ordinateur mais également pour lire une page électronique de façon linéaire et un système de na-vigation type souris (Référence : Access Controller de la société Benheck) notamment pour permettre à despersonnes ne pouvant pas utilisé une petite manette de jouer à des jeux vidéos.

Figure 1.1 – Différents appareils permettant aux handicapés d’accéder à l’outil informatique

1.3 Le contexte restreint : L’accessibilité du Web

L’accessibilité du Web, c’est, selon Tim Berners-Lee, directeur du W3C et inventeur du World WideWeb :

« Mettre le Web et ses services à la disposition de tous les individus, quel que soit leur ma-tériel ou logiciel, leur infrastructure réseau, leur langue maternelle, leur culture, leur localisationgéographique, ou leurs aptitudes physiques ou mentales. »

Ce projet de fin d’étude rentre dans une démarche de rendre Internet le plus accessible possible auxpersonnes handicapées et de faire en sorte que l’information transmise à travers les pages web que composela toile puisse être obtenue par tous.

1.4 Le contexte légal et organisationnel

1.4.1 Historique

1.4.1.1 1996

Le W3C créé l’Initiative WAI (Web Accessibility Initiative) qui regroupe des membres de divers horizons :des organisations issues de l’industrie, des organismes pour personnes handicapées, de la recherche et degouvernements. Elle rassemble aujourd’hui plus de 500 membres à travers des bureaux répartis dans plusieurspays des 5 continents.

1.4.1.2 1997

Création de l’association BrailleNet, une association loi 1901, qui mène campagne pour que les outils denouvelles technologies (comme le Web) soient mis au service des personnes handicapées déficientes visuelles,afin qu’elles puissent accéder également à l’information, à l’éducation et à la culture.

1.4.1.3 1998

Le 7 août 1998, le Congrès des Etats-Unis vote un amendement à la section 508 du Rehabilitation Actafin d’obliger les instances publiques à respecter des principes de base d’accessibilité dans la mise en œuvredes technologies de l’information.


Le contexte légal et organisationnel

1.4.1.4 1999

Le 5 mai 1999, le W3C publie sa première version des recommandations WCAG (Web Content Accessi-bility Guidelines 1.0). Elles font référence au niveau international.

1.4.1.5 2000

Depuis la création du langage HTML, les navigateurs web (Netscape et Microsoft Internet Explorer)ont "inventés" leurs propres balises qui étaient bien évidemment interprétées de manière différente chez leurconcurrent direct. Le W3C crée alors le XHTML (Extensible HyperText Markup Language) qui devient alorsle standard : ce langage doit fonctionner de la même manière sur tous les navigateurs. Aucune balise nepeut être créée sans l’accord du W3C.

La même année, la France se préoccupe de l’accessibilité de ces sites Web publics et oblige les sitesinstitutionnels à respecter des recommandations liées à l’accessibilité.

1.4.1.6 2001 - 2002

Le 25 septembre 2001, la Commission Européenne annonce officiellement sa volonté que les sites publicssoient rendus accessibles selon les recommandations WAI dans les différentes états membres. Le Royaume-Uni, le Danemark, le Portugal prennent des mesures en ce sens.

Courant juin 2002, le Parlement européen vote une résolution sur la communication de la Commission« e-Europe 2002 : Accessibilité des sites Web publics et de leur contenu ».

1.4.1.7 2004

En France, Jean-François Mattei, alors ministre de la santé, de la famille et des personnes handicapées,dépose le 28 janvier 2004 au Sénat un projet de loi dont l’article 25 indique qu’il est

« indispensable que les sites et services électroniques des services publics de l’Etat et descollectivités territoriales et de leurs établissements publics soient accessibles ».

Le concept d’accessibilité commence donc enfin à être pris au sérieux en France, même s’il est encorebeaucoup trop méconnu.

1.4.1.8 2005

Le 12 février 2005, la France vote la loi pour l’égalité des droits et des chances, la participation et lacitoyenneté des personnes handicapées, dont l’article 47 impose la mise en conformité des sites internet dusecteur public aux normes internationales d’accessibilité.

Le 9 juin 2005, le W3C met en route la deuxième version des recommandations WCAG (Web ContentAccessibility Guidelines 2.0 [13]), elle sera publiée le 23 novembre 2005 dans une version non finalisée. Laversion officielle des WCAG reste cependant la 1.0 jusqu’a décembre 2008.

Le 28 novembre 2005, une étude "alarmante", « eAccessibility of public sector services in the EuropeanUnion », sur l’accessibilité Web des services publics en Europe montre que seulement 3% sont accessiblessuivant les WCAG 1.0. Ces résultats ont été confirmés en 2006 par une étude menée à l’initiative del’Organisation des Nations unies sur les 100 plus importants sites privés (compagnies aérienne, banques,journaux et boutiques en ligne) ou publics (sites gouvernementaux) à travers 20 pays.



1.4.1.9 2008

Devant le retard français concernant le décret d’application de la loi de février 2005, Vincent Aniort,Aurélien Lévy et Frank Galey initient une pétition pour l’accessibilité numérique des services publics en lignele 7 mai 2008 :

« Plus de trois ans après le vote de la loi pour « l’égalité des droits et des chances,... »,le décret qui doit préciser les modalités d’application de l’accessibilité numérique n’est toujourspas sorti. Cette situation ne peut pas durer ! »

Le 11 décembre 2008, la deuxième version des recommandations WCAG (Web Content AccessibilityGuidelines 2.0 [13]), le nouveau standard pour l’accessibilité des sites Web, devient la recommandationofficielle du W3C.

(Source : Histoire des standards du web et des normes d’accessibilité [38])

1.4.2 La legislation

1.4.2.1 Legislation dans le monde

Dans de nombreux pays dans le monde, les gouvernements ont voté un certain nombre de lois pourobliger des sites Internet (la plupart du temps institutionnels) à respecter les normes d’accessibilité.

• Aux Etats-Unis, la section 508 a déjà fait ses preuves. Elle exige que tous les sites fédéraux et ressourcesélectroniques du gouvernement américain soient accessibles aux personnes handicapées.• Au Canada, le conseil du Trésor a approuvé en mai 2000 les Normes et directives sur la Normalisation

des sites Internet (NSI). Toutes les institutions visées ont dans l’obligation de respecter les règlesd’accessibilité des WCAG 1.0 de priorité A et AA.• L’Europe a avancé à grands pas depuis 2005. La création du CEN Agreement (n° 15554) [16] on

"Specifications for a Web Accessibility Conformity Assessment Scheme and a Web Accessibility QualityMark" a permis l’édification d’une méthodologie unifiée pour l’analyse des sites Web la "Unified WebEvaluation Methodology" [10] (UWEM 1.0). Ces deux étapes sont à la base de Euracert créé en début2007 qui réunit la France (Association BrailleNet [11]), l’Espagne (Fundosa Teleservicios [27]) et laBelgique (AnySurfer [9]) autour d’une même méthodologie et une même certification en plus de leurlabel national reconnu mutuellement par chacun des membres.• L’Angleterre possède depuis 1995 une loi générale rendant illégale toute discrimination vis-à-vis des

personnes handicapées. Il est donc obligatoire pour les sociétés privées d’avoir un intranet, un extranetet un site web accessible.• Au Luxembourg, le référentiel RENO [23] (pour « référentiel de normalisation ») rédigé fin 2007 et

adopté en 2008 intègre l’accessibilité dans une démarche qualité globale. Ce référentiel est intégrésystématiquement aux cahiers des charges des projets web de l’État.

1.4.2.2 Législation en France

En France, la législation de l’accessibilité est apparue avec la loi du 30 janvier 1975 [26] d’orientationen faveur des personnes handicapées. Cette loi régit l’accessibilité en termes de construction de bâtimentset de transports publics. Depuis 2003, le Comité interministériel pour la société de l’information exige quel’accessibilité numérique soit une obligation légale intégré dans les projets de lois sur les personnes handica-pées.

Suivant l’article 47 de la loi 2005-102 qui a été adoptée en France le 11 février 2005, les sites Webpublics ont l’obligation d’être accessibles pour "l’égalité des droits et des chances, la participation et la


Le contexte légal et organisationnel

citoyenneté des personnes handicapées".

Extrait de l’article 47 de la loi n°2005-102 du 11 février 2005 :

« Les services de communication publics en ligne des services de l’Etat, des collectivités ter-ritoriales et des établissements publics qui en dépendent doivent être accessibles aux personneshandicapées.

L’accessibilité des services de communication publics en ligne concerne l’accès à tout typed’information sous forme numérique quels que soient le moyen d’accès, les contenus et le modede consultation. Les recommandations internationales pour l’accessibilité de l’internet doiventêtre appliquées pour les services de communication publics en ligne.»

1.4.3 Les associations et sociétés spécialisées

On retrouve actuellement sur la toile un grand nombre d’associations luttant pour l’accessibilité du web.Nous avons parlé dans l’historique de BrailleNet mais il en existe bien d’autres se battant chacune pour lesdroits des handicapés à bénéficier de pages web accessibles pour obtenir l’information qui leur est due.

Les principales associations et communautés sont :

• BrailleNet [11] : Le rôle de l’association BrailleNet est de mettre en place toutes les actions nécessairespour augmenter le nombre de sites Web accessibles notamment en France mais aussi en Europe. Pouraccomplir sa mission, elle a créée une cellule Accessibilité "AccessiWeb" qui a développé depuis 1997une expertise sur l’accessibilité du Web sur la base des recommandations internationales de W3C/WAI.• AccessiWeb [6] : AccessiWeb est un site internet issu de l’association BrailleNet. Il met à disposition

des internautes des ressources pour aider à la conception, propose des formations et décerne destrophés d’accessibilité pour les meilleurs sites internet (dans la matière). Ces sites web reçoivent lelabel AccessiWeb qui se décompose en 3 niveaux :

1. Bronze : Le site internet prend en compte des recommandations essentielles du web,

2. Argent : En plus des recommandations essentielles, il respecte les recommandations facilitant lanavigation,

3. Or : Il respecte toutes les recommandations d’accessibilité.

• Euracert [25] : Il est le premier label européen de qualité pour les sites Web accessibles.• OpenWeb [4] : Ce site vous présentera les divers aspects du Web selon vos besoins. Les décideurs y

trouveront les informations à même d’éclairer leurs choix, les programmeurs et les designers pourrontapprendre ou renforcer leurs connaissances et les formateurs et journalistes puiseront dans les articlesà loisir.• Planète Accessibilité [1] : Planète Accessibilité liste de façon automatique l’actualité francophone

traitant de l’accessibilité numérique.• Web-pour-tous [28] : Ce site est consacré à l’accessibilité du web et ses principaux acteurs, les utili-

sateurs et concepteurs de site.Suite aux nombreuses lois depuis 2005 cherchant à rendre les sites accessibles, un certain nombre de

sociétés se sont intéressées au domaine grâce à l’avantage qu’elles peuvent en tirer en proposant aux sitesinternet qui en ont besoin des audits pour rendre leurs pages accessibles. En effet, dans certains secteurs, lessites web ont dans l’obligation de respecter les normes d’accessibilité et doivent par conséquent faire appelà une société leur proposant ce service.

Ces sociétés proposent principalement :



• Des audits sur l’accessibilité en fonction des différentes priorités (1,2 ou 3) des WCAG 1.0• Des formations de création de sites web accessibles.• Des gabarits de sites conformes pour l’accessiblité.• La création complète de sites accessibles.

Il existe de nombreuses sociétés proposant ce genre de service, parmi elles on trouve :

• Ocawa [47] : qui propose des services pour les entreprises et les particuliers, notamment un validateurdes WCAG, l’audit d’un site complet, l’intégration des standards dans un site existant, une extensionFirefox sous forme de barres de validation, etc,• AuditWeb [42] : qui d’auditer la conformité des pages de votre site aux règles d’accessibilité internet

et de tirer partie des standards d’encodage du W3C pour garantir la stabilité de votre site,• Opquast [46] : qui propose un guide des bonnes pratiques qualité pour les services en ligne ainsi qu’un

grand nombre de services liés à l’accessibilité web.

1.5 Dans la pratique : un site accessible

De manière très générale, un site est accessible s’il est utilisable et consultable dans son intégralité partous ses visiteurs. Par accessibilité, on entend que le contenu d’un site puisse être consulté par tous, peuimporte les techniques que les personnes utilisent pour naviguer.

Une étude réalisée en 2004 par la commission britannique des droits aux personnes handicapées sur unéchantillon de 1000 sites Web a identifié les principaux manquements aux directives du WCAG 1.0.

• L’absence d’alternatives pertinentes aux éléments graphiques et au javascript.• La présence de contenus en mouvement non contrôlables par l’utilisateur, et d’ouvertures de liens

dans une nouvelle fenêtre du navigateur non anticipables par l’utilisateur.• La présence de libellés de liens non explicites et de contenus rédigés dans un langage trop complexe

en fonction du contexte.• La structuration HTML insuffisante du contenu.• L’utilisation non accessible de la couleur comme véhicule de l’information.

1.5.1 Les avantages d’un site accessible

Du point de vue du créateur d’un site web (personnel ou professionnel), réaliser un site accessible procurede nombreux avantages :

1. Elargissement et fidélisation de l’audienceAvant la mise en place de la notion d’accessibilité, certains utilisateurs ne naviguaient pas de façonconvenable et ne pouvaient accéder à la totalité de l’information que le créateur du site web voulaittransmettre. Cela permet également d’avoir une meilleure visibilité du site même pour une personnenon handicapée, l’incitant à revenir ultérieurement sur les parties qui l’ont intéressé.

2. S’afficher en tant qu’entreprise citoyennePermet d’offrir un moyen de diminuer la dépendance des handicapés : une personne aveugle rempliraseule un formulaire administratif en ligne, une personne à mobilité réduite peut faire seule ses achatssur les sites de e-commerce.

3. Amélioration des services et de la maintenanceLes standards de l’accessibilité préconisent la séparation du contenu et de la forme. Il est ainsi plusfacile pour le webmaster en charge de la maintenance de garder le site à jour.


Dans la pratique : un site accessible

4. Amélioration de l’efficacité et donc du chiffre d’affairesUn meilleur référencement, une recherche interne au site plus rapide, un temps d’achat plus court,etc. Toutes ces améliorations augmentent la satisfaction de l’utilisateur et va diminuer le nombre desdemandes de support.

5. Respect des obligations légales en termes d’accessibilitéChaque gouvernement possède des lois pour l’égalité des droits et des chances des citoyens du pays.En rendant un site accessible pour tous, cela permet de se protéger d’éventuels recours en justice.

6. Amélioration dans les moteurs de rechercheUn site accessible est plus visible sur les moteurs de recherche et attire donc plus de personnes.

7. Multi-plateforme / multi-écranLa conformité aux standards permet de concevoir facilement des interfaces utilisateurs en fonction dessupports et de leurs usages. Nous ne pouvons pas proposer le même service sur un écran de téléphonemobile que sur un PC portable à écran 11’ ou un PC de bureau avec un grand écran.

1.5.2 Les techniques

Un webmaster voulant rendre un site accessible peut suivre les WCAG réalisé par le W3C. Cependant ceguide est très complet donc rapidement ennuyeux à lire pour les non-initiés au langage avancé du web. Pourles aider, le W3C a dressé une liste de 10 règles d’or de l’accessibilité d’un site internet. Le site RenaissanceNumérique [41] a recueilli et traduit ces propos pour nous :

Les 10 règles d’or

1. Donner aux images un texte alternatif (attribut « alt ») afin qu’une personne, quels que soient sondispositif d’affichage et ses caractéristiques personnelles, puisse avoir accès à l’information véhiculéepar l’image.

2. Utiliser les feuilles de style afin de pouvoir personnaliser les pages et structurer l’information. Il fautégalement éviter de recourir aux structures de tables à des fins de présentation.

3. Adapter les tableaux de données publiés sur Internet et prévoir les entêtes de colonnes et de lignes

4. Lier chaque champ d’un formulaire à un intitulé (balise « label »).

5. Offrir la possibilité de naviguer via le clavier (par la touche tabulation par exemple qui permet depasser de liens en liens sur la page) et vérifier cette possibilité lors de l’utilisation de java script, detechnologies DHTML

6. Rendre la technologie Flash aussi accessible que possible et prévoir une alternative telle que HTML.Plus généralement, les ressources graphiques doivent disposer d’une alternative au format TXT, RTFou HTML/XHTML.

7. Penser aux alternatives en cas de recours au multimédia (description d’une vidéo, transcription entexte d’une interview...).

8. Eviter l’usage de frames. Sinon penser à donner un titre à chaque frame.

9. Prévenir d’un changement de langues dans un texte en renseignant l’attribut « Lang ».

10. Penser à des liens "explicatifs". Par exemple "cliquez ici" doit être remplacé par "cliquez ici pourcommander" ou "cliquez ici pour retourner à la page d’accueil" (surtout si la page compte plusieursboutons, le cliquez ici ne veut plus rien dire).

1.5.3 Les validateurs

Pour aider un webmaster qui souhaiterait rendre conforme son site aux normes des WCAG, il existe uncertain nombre de validateurs disponibles sur internet. Ces validateurs s’utilisent de la même façon que les



validateurs HTML et CSS qui sont plus connus. On spécifie une page web en entrée ou un lien internet,le validateur vérifie l’ensemble des régles qu’il connait et affiche sur une page de résultats les erreurs etavertissements qu’il a trouvés. Les tests sont réalisés sur les spécifications des WCAG qui sont automati-sables. Contrairement à la validation HTML et CSS, le W3C ne met à disposition aucun validateur officieldes WCAG. Il existe donc de nombreuses entreprises ou communautés web qui proposent leurs propres va-lidateurs.

Ci-dessous une liste des validateurs les plus connus :

• Ocawa [47] : Validateur des WCAG 1.0 avec une version gratuite pour la priorité 1 seulement etl’intégralité pour la version payante.• Bobby [14] : un validateur qui a longtemps été la référence jusqu’à sa fermeture.• WebXACT [32] : validateur de la société IBM.• Cynthia Says [30] : un validateur web intéressant réalisé par la société HiSoftware.• EvalAccess [40] : un très bon validateur developpé par le ”Laboratory of HCI for Special Needs” à

l’université du pays Basque.• Total Validator [48] : un validateur tout en un qui reconnait de façon assez floue les erreurs d’acces-

sibilité.• TAW [22] : un validateur visuel qui affiche la page validée en ajoutant des pastilles de couleur aux

endroits qui posent problème.

1.5.4 Les correcteurs

Le travail du validateur est de detecter les erreurs d’accessibilité d’une page web, le correcteur quant àlui permet cette fois de les corriger. Il existe actuellement très peu de correcteurs, c’est d’ailleurs pour celaque nous nous intéressons au sujet, mais les existants méritent d’être étudiés.

A-Prompt [7] est un logiciel à télécharger sur son ordinateur permettant de tester des pages web enlocal. Il a l’avantage de pouvoir corriger non pas une page à la fois mais un site entier. Un certain nombrede corrections sont implémentées mais elles ne sont pas classées par spécification. Le logiciel ne possèdequ’un mode manuel et il est parfois difficile de comprendre ce qu’il faut faire. Cependant le logiciel est dequalité et certaines idées utilisées pour corriger des problèmes sont très bonnes.

Firefox Accessibility Extension [33] est une barre d’outils disponible dans firefox permettant de naviguerdans le site (grâce aux ancres) jusqu’aux erreurs détectées. Une démarche de correction est alors décritepour chaque élément mais elle n’est pas réalisable directement. Il est nécessaire que le webmaster corrigede son côté les erreurs detectées et change les pages web sur le serveur qu’il utilise.

Accessibar [37] est une extension de Firefox qui permet de corriger les problèmes de contraste directementdans le navigateur. Il est nécessaire de modifier la couleur à l’aide des outils disponibles pour les différentesparties du document qui pose problème. Les corrections sont effectuées de façon temporaire sur la page enligne et nécessite des corrections manuelles de la part du webmaster si l’on souhaite conserver les corrections.

1.6 Conclusion

De nombreuses mesures ont été prises depuis plus de 10 ans pour rendre le web accessible aux personneshandicapées, mais les résultats ne sont pas au rendez-vous et une grande partie de l’information contenuesur le web ne peut être atteinte par les handicapés. Face à cela, des outils permettant aux webmasters ayantenvie de faire changer les choses doivent exister. Ce projet de fin d’étude fait partie de cette démarche,créant un outil aidant les webmasters à rendre leur site accessible sans en modifier le contenu. Certains


Conclusion

correcteurs existent déjà mais sont soit incomplets, soit parfois difficiles de compréhension. Notre correcteura pour objectif de reprendre l’ensemble des spécifications des WCAG pour obtenir un outil capable de réalisertout ce qui est automatisable ou semi-automatisable tout en expliquant clairement l’utilité de la correctionau webmaster.


CHAPITRE 2

Présentation du projet

2.1 Le sujet

Pour naviguer sur Internet, les personnes non-voyantes ou malvoyantes utilisent des aides techniquestelles que la synthèse vocale ou le clavier braille. Ces aides permettent la lecture de l’information en par-courant les pages de façon linéaire (de haut en bas et de gauche à droite). Lorsque les pages Web sontcomplexes ou encore mal formatées, la lecture de l’information par un non-voyant devient relativement dif-ficile. Cela vient du fait que ces outils sont peu efficaces sur des sites Internet qui ne respectent pas lesstandards d’accessibilité du W3C (World Wide Web Consortium). L’objectif de ce projet de fin d’étude estde continuer un outil existant capable d’améliorer la structure des pages Web pour qu’elles respectent lesnormes du W3C et qu’elles soient par conséquent plus facilement accessibles aux personnes handicapéesvisuelles.

Par exemple, des pages dont les éléments multimédias (images, vidéos, animations flash) n’auraientpas de textes alternatifs ne pourraient être interprétées par un clavier braille ou une synthèse vocale et lapersonne non-voyante n’aurait aucune information les concernant. Il est également essentiel que la structuredu code soit correcte pour être mieux comprise par le navigateur et qu’un effort de séparation du fond etde la forme soit réalisé. Pour rendre ces pages accessibles, il est nécessaire de réécrire la page, ce qui vaconstituer le but de ce projet.

L’application finale est destinée aux webmasters novices en matière d’accessibilité pour les aider à rendreleur site web accessible sans avoir à connaître les 65 spécifications découpées en 14 directives. Pour répondreà ce besoin, nous avons réalisé un outil se découpant en 2 parties. La première partie est le moteur de l’ap-plication. Il prend en entrée une page HTML et permet la création de la même page corrigée en sortie.La seconde partie est un ensemble de plugins s’exécutant uniquement à travers ce moteur. L’interface decelui-ci propose le choix des plugins à appliquer à une page HTML. Un plugin devra être implémenté pourchaque spécification, pour permettre de rendre la page conforme à cette spécification. Les plugins réaliséslors de ce PFE seront ensuite ajoutés à ceux déjà développés pour former une application complète. En casde nécessité, il est possible de faire des modifications sur ce moteur dans l’objectif de l’améliorer.

Certaines modifications peuvent se faire de manière automatiques tandis que d’autres nécessitent l’in-tervention du webmaster pour être pertinentes. Chaque plugin devra donc pouvoir être exécuté sous deuxmodes distincts. Le mode automatique qui ne demande aucune intervention extérieure et dont les choixont été enregistrés préalablement (cela n’est pas toujours possible). Et le mode manuel qui à chaque choixpossible pour le webmaster ouvre une fenêtre lui proposant ce choix sous la forme d’une question. Cettequestion doit être la plus simple possible du fait que le webmaster ne peut avoir aucune connaissance tech-nique à priori. Le projet mettra l’accent sur le mode manuel et plus particulièrement sur l’ergonomie de lafenêtre permettant de faire comprendre très rapidement et de façon claire ce que l’on attend du webmasterdans ce choix.


Définitions

2.2 Définitions

Nous allons tout d’abord commencer par définir un certain nombre de notions indispensables à la com-préhension de ce PFE.

2.2.0.1 HaNT

Handicap & Nouvelles Technologies est le nom d’une équipe du laboratoire informatique (LI) de l’univer-sité de Tours travaillant sur l’aide aux personnes handicapées. Les principaux thèmes étudiés sont l’accessi-bilité numérique, l’habitat intelligent et la mise en place de robot pour l’aide à la thérapie d’enfant handicapé.

Site internet : http://hant.li.univ-tours.fr

2.2.0.2 W3C

Le World Wide Web Consortium est l’organisme de normalisation des technologies du web telles que leHTML, XHTML, CSS, SVG, etc. Il a été fondé en 1994 Tim Berners-Lee et est à but non-lucratif. Il n’émetpas des normes au sens strict, mais des recommandations sous forme de documentations et de guides àdestination des webmasters.

Site internet : http://www.w3.org/

2.2.0.3 WAI

La Web Accessibility Initiative a été lancé en 1997 par le W3C pour objectif de rendre les technologiesdu web accessibles aux personnes handicapées et d’une manière générale à toute personne sans nécessité deprérequis particuliers. On peut regrouper les actions de la WAI en 5 grands domaines :

1. Les technologies du Web.

2. Le développement de recommandations.

3. Le développement d’outils.

4. L’information et la formation.

5. La recherche et le développement.

Site internet : http://www.w3.org/WAI/

2.2.0.4 WCAG

Le Web Content Accessibility Guidelines est un guide de la WAI, réalisé dans le thème de développementde recommandations, expliquant aux webmasters comment rendre leurs pages accessibles. La première ver-sion (WCAG 1.0) remonte à 1999 et la deuxième version WCAG 2.0 est devenue recommandation officielletout récemment, le 11 décembre 2008.

2.2.0.5 WCAG 1.0

La version 1.0 des WCAG comporte 14 directives dont les 11 premières visent à assurer une transfor-mation élégante du contenu dans les différents contextes utilisateurs et les 3 dernières visent à rendre lecontenu compréhensible et navigable. Ces directives sont décomposées en spécifications, ce qui donne autotal 65 points de contrôle dont chacun a une priorité. Il existe 3 niveaux d’accessibilités des WCAG 1.0représentant la priorité du point de contrôle :


http://hant.li.univ-tours.fr

http://www.w3.org/

http://www.w3.org/WAI/

Chapitre 2. Présentation du projet

1. Niveau A : Ce qui doit être fait.

2. Niveau AA : Ce qui devrait être fait.

3. Niveau AAA : Ce qui peut être fait.

Site internet : http://www.w3.org/TR/WCAG10/

2.2.0.6 WCAG 2.0

Contrairement aux WCAG 1.0 qui concernent principalement les contenus HTML, les WCAG 2.0 fontabstraction de la technologie spécifiquement utilisée et ont pour objectifs d’être applicables à toutes lestechnologies actuelles, d’être plus aisées à utiliser et à comprendre (guides d’implémentation) et d’êtreplus aptes à l’évaluation humaine ou logicielle (critères de succès explicites). Les WCAG 2.0 adoptentégalement une approche thématique plus rigoureuse en structurant 12 directives principales selon 4 principesfondamentaux :

1. Des contenus perceptibles.

2. Des contenus utilisables.

3. Des contenus compréhensibles.

4. Des contenus robustes.

3 niveaux d’accessibilités existent également dans la version 2.0 des WCAG reprenant le même principeque ceux des WCAG 1.0.

Site internet : http://www.w3.org/TR/WCAG20/

2.2.0.7 HTML

L’Hypertext Markup Language est un langage de balise basé sur le langage SGML (Standard GeneralizedMarkup Language) permettant l’affichage d’information sur une page internet. Il est une des trois inventionsà la base du World Wide Web, avec le Hypertext Transfer Protocol (HTTP) et les adresses web. Il permetcomme l’indique son nom d’écrire de l’hypertexte mais aussi de structurer sémantiquement, de mettre enforme le contenu des pages, d’inclure des ressources multimédias, des formulaires de saisie, et des élémentsprogrammables tels que des applets. Le X-HTML est une évolution plus stricte de l’HTML basé sur lelangage XML (Extensible Markup Language).

Site internet : http://www.w3.org/html/

2.2.0.8 Plugin

Un plugin est un programme indépendant qui interagit avec un logiciel principal, appelé programme hôte,lui permettant ainsi de lui apporter de nouvelles fonctionnalités. L’idée du plugin est qu’il peut fonctionnerseul et peut être développé par une personne n’ayant pas nécessairement accès au code du logiciel principal.Il n’est pas nécessaire de recompiler le code du programme hôte pour lui ajouter un plugin. Cependant leplugin doit respecter un certain nombre de règles décrites par le concepteur de l’application principale.


http://www.w3.org/TR/WCAG10/


http://www.w3.org/html/

Etude de l’existant

2.3 Etude de l’existant

Ce Projet de Fin d’Etude est la reprise d’un PFE intitulé Restructuration de pages Web [8] réalisé parAntoine Blais durant l’année 2006-2007. Cette partie va présenter les différents éléments mis en place parAntoine au cours de son PFE.

2.3.1 Présentation générale

2.3.1.1 Plateforme de traitement

Commençant un nouveau projet de recherche, Antoine a tout d’abord réfléchi à la mise en place d’uneplateforme de traitement permettant d’avoir en entrée une page HTML, de faire des corrections sur cettepage en fonction des spécifications des WCAG et d’obtenir en sortie la même page web corrigée. Il a doncséparé les spécifications dans des plugins indépendants du moteur et réalisé une application java permet-tant de choisir les pages HTML, de sélectionner les plugins, de choisir le mode souhaité et éventuellementd’utiliser des aperçus des pages avant et après modifications.

L’utilisation de l’application peut se faire de 2 manières différentes :

• Le mode console permettant à l’utilisateur final d’utiliser le moteur avec une liste de plugins au formatXML et un proxy pour corriger les pages.• Le mode graphique permettant au webmaster d’utiliser une sélection de plugins pour corriger ses

pages Internet avant de les envoyer sur le serveur web.

La figure 2.1 présente le mode graphique tel que Antoine Blais l’avait réalisé.

Figure 2.1 – Application en mode graphique

2.3.1.2 Plugins des spécifications

Antoine a ensuite mis en place les spécifications des WCAG sous forme de plugins. Ces plugins per-mettent de ne pas avoir à recompiler le moteur à chaque fois qu’un développeur en crée un nouveau. Ilsuffit pour lui de respecter une norme de développement du plugin et une fois compilé de le placer dans un



dossier prévu à cet effet. La méthode de création d’un plugin peut être trouvée dans le rapport de PFE deAntoine Blais [8]. Voici différentes spécifications implémentées sous forme de plugin :

Spécification 1.1

L’objectif de ce plugin est de fournir un équivalent textuel à une image en définissant un titre et unedescription longue. Il s’agit qu’une petite partie de la spécification 1.1 qui définit des solutions équivalentespour tous les éléments multimédias (Images cliquables, applet, object, ...). Le mode manuel permet à l’uti-lisateur de voir l’image dans une partie de la popup et de lui demander un titre et une description longuepour cette image. Le mode automatique se base sur les éléments qu’il possède (nom de l’image, attributde la balise IMG) pour fournir au mieux un équivalent textuel. La figure 2.2 présente l’interface du modemanuel de la spécification 1.1.

Figure 2.2 – L’interface de la spécification 1.1

Spécification 5.1

L’objectif de ce plugin est de définir quelles sont les cases d’un tableau qui correspondent à des élémentsd’en-tête. Ce plugin ne fonctionne pas de manière automatique et ne possède qu’un mode manuel. Dans cemode, une interface propose au webmaster, pour chaque tableau de la page, de définir quelles cases corres-pondent à des en-têtes. L’interface intègre l’affichage du tableau qui permet au webmaster de connaître letableau sur lequel il travaille mais également sa forme. Une représentation structurelle du tableau permet àl’utilisateur de définir les cellules d’en-tête en utilisant le code couleur suivant :

• Bouton vert -> case d’en-tête.• Bouton gris -> case normale.

La figure 2.3 présente l’interface du mode manuel de la spécification 5.1.




Spécification 5.3

L’objectif de ce plugin est de définir si un tableau est utilisé pour faire de la mise en page. Si c’est lecas, on le transforme de manière à ce qu’il ne soit plus utilisé dans ce but. Il existe un mode manuel et unmode automatique pour cette spécification. Le mode manuel demande à l’utilisateur comment il souhaitemodifier son tableau de mise en page. Il comporte l’affichage original du tableau, la possibilité d’ajouter untitre avant le tableau et un choix de transformation de mise en page parmi les suivants :

1. Les cases du tableau sont lues de gauche à droite et de haut en bas pour être attachées et concaténéesles unes avec les autres dans la page Web.

2. Les cases du tableau sont lues de haut en bas et de gauche à droite pour être attachées et concaténéesles unes avec les autres dans la page Web.

3. Le tableau est transformé de manière à ce que toutes les cases du tableau soient remplacées par unebalise DIV qui permettra de reconstituer la forme du tableau telle quelle mais sans utiliser les balisesHTML TABLE, TR, TH et TD qui posent problème pour les lecteurs vocaux.

4. Le tableau n’est pas modifié et reste un tableau de mise en page. Ce choix ne fournit pas un résultataccessible, mais reste un choix possible à l’appréciation du webmaster. Il peut être également pertinentdans le cas d’un tableau de données.

Le mode automatique quant à lui choisit automatiquement le choix 3 qui est celui dont la représen-tation est la plus proche de la réalité. La figure 2.4 présente l’interface du mode manuel de la spécification 5.3.




Spécification 5.5

L’objectif de ce plugin est de fournir un titre et une description pour chaque tableau de la page web. Ilfonctionne de manière similaire à la spécification 1.1 mais adapté aux tableaux. Il existe le mode automatiquequi regarde si un titre et une description existent déjà, sinon il lui donne par défaut le titre ”Tableau dedonnées”. Le mode manuel quant à lui fournit une interface qui présente le tableau, et demande un titre etune description au webmaster.





Spécification 6.3

L’objectif de ce plugin est de fournir un équivalent textuel à des objets qui sont de plus en plus utiliséssur le web et qui ne permettent pas à des aveugles de savoir ce qui se passe (exemple d’une page contenantuniquement une animation flash). Le mode manuel permet au webmaster de choisir un équivalent textuelaux objets n’en possédant pas. La première partie de l’interface présente le code HTML de l’objet et ladeuxième partie est un champ permettant de remplir le texte alternatif. Le mode automatique quant à luine peut pas faire mieux que de signaler la présence d’un média sans description.



2.3.2 Technologies utilisées

2.3.2.1 Java

Java [43] est un langage de programmation informatique orienté objet créé par James Gosling et PatrickNaughton employés de Sun Microsystems. Il a été présenté officiellement le 23 mai 1995 au SunWorld. Lesavantages de ce langage est qu’il est relativement simple à prendre en main et très facilement portable surplusieurs systèmes d’exploitation tels que Unix, Windows et Mac OS. C’est la machine virtuelle java (JVM)qui garantit la portabilité des applications développées en Java.

Au début de son PFE, Antoine a choisi ce langage pour les différents avantages cités précédemment. Ila developpé le moteur de l’application ainsi que ces plugins à l’aide du JDK (Java Development kit) danssa version J2SE 5.0 sortie en septembre 2004.

2.3.2.2 Netbeans

NetBeans [39] est un IDE open source principalement utilisé pour le langage Java bien qu’il supporteégalement d’autres langages informatiques. Il a été conçu en Java et est disponible sur de nombreux sys-



tèmes d’exploitation notamment Unix, Windows et Mac OS. Issu de Xelfi, un projet étudiant il a été ensuiteacheté par Sun Microsystems en 1999 et placé sous double licence CDDL et GPL v2 en juin 2000. Il possèdeun système de plugins permettant d’y ajouter de nombreuses fonctionnalités en plus de celles de bases. Ilpossède également un designer permettant de faire facilement des fenêtres java.

Cet environnement de développement a été choisi par le PFE précédent et a été utilisé dans sa version 5.5.Ne permettant pas de modifier directement le code source des fenêtres réalisées par le designer, l’ensembledes IHM ont été conçus directement à l’aide des éléments swing en java.

2.3.2.3 Swing

Swing est une bibliothèque graphique pour Java incluse dans le JDK. Elle permet de réaliser des in-terfaces graphiques en donnant un rendu identique sur les différents systèmes d’exploitation. Swing utilisele principe Modèle Vue Contrôleur (MVC) et dispose de plusieurs choix d’apparence pour les différentscomposants standards. Swing utilise AWT qui est l’ancienne bilbiothèque des interfaces graphiques en Java.Elle sert encore de fondement à Swing, dans la mesure où de nombreuses classes Swing héritent de classesAWT.

Antoine a réalisé ces interfaces à l’aide des fonctions de Swing et en utilisant également certainesfonctions de AWT.

2.3.2.4 JDOM

JDOM [31] est une bibliothèque Java permettant de manipuler des données XML. La première releaseest la version 1.0 sortie en septembre 2004. Elle est une très bonne alternative à DOM (Document ObjectModel) et SAX (Simple API for XML) en les utilisant tous les deux d’une manière complémentaire.

Cette bibliothèque a été utilisée par le PFE précédent dans sa version 1.0. Le webmaster peut lancerl’application en ligne de commande et ainsi donner la liste des plugins à utiliser sous la forme d’un fichier XML.JDOM permet alors de parser ce fichier et de récupérer toutes les données nécessaires au bon fonctionnementde la plateforme.

2.3.2.5 Jericho

Jericho [35] est une bibliothèque Java open source permettant d’analyser et de manipuler des partiesde code HTML en se basant sur les tags. Jericho contient de nombreuses fonctions permettant de modifierdes tags HTML ainsi que leurs attributs.

Elle a été utilisée par Antoine dans sa version 2.3 sortie en novembre 2006. Elle permet aux plugins deremplacer le code source existant pour effectuer les modifications nécessaires sur les pages HTML.

2.3.2.6 Ocawa

Ocawa [47] est un service web de validation des WCAG conçu et développé par la société Urbilog. Ilpermet la détection des erreurs et des warnings des différentes spécifications des WCAG.

Antoine a utilisé entre autre ce validateur au cours de son PFE pour mesurer l’amélioration apportéepar ces différents plugins.



2.3.2.7 Apinc

Le validateur d’accessibilité fourni par l’association Apinc [5] est un outil permettant d’analyser l’acces-sibilité d’une page Web à partir des spécifications des WCAG.

Ce validateur a également été utilisé dans le PFE précédent dans le but de montrer les améliorationsapportées par les plugins developpés.

2.3.3 Présentation détaillée

2.3.3.1 Analyse UML

Nous allons maintenant présenter l’analyse UML réalisée par le précédent PFE qui présente une vuefonctionnelle du système selon différentes vues complémentaires grâce à deux diagrammes.

Diagramme d’utilisation

Le diagramme d’utilisation présente les différents besoins identifiés par Antoine lors de son analyse UML.La figure 2.7 présente ce diagramme d’utilisation.

Figure 2.7 – Diagramme d’utilisation de l’application existante

Diagramme de classe

A partir du diagramme d’utilisation ci-dessus, Antoine a réalisé le diagramme de classe suivant. La listedes différentes classes et leur utilité permettent de mieux comprendre le fonctionnement de l’application :

• Interface Plugin : Cette interface doit être implémentée par chaque Plugin pour être utilisable parle moteur. Elle contient les méthodes communes à l’ensemble des plugins.• Classe PluginXXX : Cette classe représente un exemple de plugin. Pour être utilisable, elle implé-

mente l’interface Plugin et est capable de renvoyer des PluginException.



• Classe PluginException : Cette classe permet à un Plugin de lever une exception qui peut êtreenvoyée vers le moteur de la plateforme permettant une gestion de la part de cette dernière.• Classe PluginChargeur : Cette classe est utilisée par la plateforme de traitement pour charger

dynamiquement les plugins utilisables.• Classe ParseurXML : Cette classe est utilisée pour extraire d’un fichier XML le nom des plugins qui

devront être chargés et utilisés par le moteur.• Classe Moteur : Il s’agit de classe principale du moteur de l’application. Elle permet l’utilisation des

plugins sur la page HTML en entrée.• Classe MoteurException : Cette classe permet de lever une exception provoquée par le moteur.• Classe panelEntree : Cette classe est un bean qui est intégré à l’interface principale. Elle permet de

sélectionner les paramètres d’entrée comme : la page web source, son chemin de destination...• Classe panelGestPlugin : Cette classe est un bean qui est intégré à l’interface principale. Elle permet

de sélectionner les plugins qui devront être appliqués sur la page web ainsi que leur ordre de passage.• Classe ihmMain : La classe principale de l’interface, c’est elle qui est utilisée pour l’exécution de la

plateforme.• Classe ihmApercu : Cette classe permet la création d’un aperçu de la page web.• Classe ihmInfo : Il s’agit d’une fenêtre permettant d’afficher des aides utilisateurs sous la forme de

petites page Web.• Classe ihmException : Cette fenêtre permet d’afficher les exceptions levées par l’application sous la

forme d’une fenêtre.

La figure 2.9 présente le diagramme de classe de l’application existante. Une fois cette analyse termi-née, on peut très bien voir le fonctionnement du moteur accompagné des plugins. La figure 2.8 présente lefonctionnement global de l’application.

Figure 2.8 – Schéma du fonctionnement de l’application



2.3.3.2 Techniques et outils utilisés

Lors de son projet de fin d’études, Antoine a également réalisé certains plugins qui ne sont pas liés à unespécification des WCAG mais qui sont des outils d’aide au webmaster pour la correction des pages. Certainsde ces plugins sont nécessaires pour avoir un affichage correct des pages dans la plateforme de traitement.Voici les différents plugins développés dans ce but :

Indentation du code

Le langage HTML est un langage de balise ce qui est un avantage mais peut être également un incon-vénient. L’indentation est parfois difficile à réaliser manuellement, c’est pourquoi Antoine à développer ceplugin qui permet d’indenter le code d’une page HTML afin de la rendre plus lisible et rapidement compré-hensible par le webmaster.

Exporter les feuilles de styles

Dans l’objectif de séparer le fond de la forme d’une page web, le langage HTML s’utilise très souventavec le langage CSS (Cascading Styles Sheets). Ce fichier se trouve généralement en dehors de la page webet est lié à celle-ci par l’intermédiaire d’une balise LINK. Cependant on trouve dans certaines pages web ducode CSS directement inclus. L’objectif de ce plugin est de récupérer le code CSS qui est situé dans la baliseSTYLE afin de le transférer dans un fichier CSS (.css) prévu à cet effet. La page HTML se verra ajouter labalise LINK comportant le chemin du fichier en question.

Importer les feuilles de styles

Comme nous l’avons déclaré précédemment, les feuilles de style peuvent être contenues dans un fi-chier externe comportant l’extension .css ou alors à l’intérieur d’une balise STYLE directement dans lapage HTML. Cette deuxième méthode n’est pas recommandée étant donné qu’on favorise la séparation ducontenu de la forme. Cependant pour des raisons techniques, il peut être plus facile lors du développementd’un site web d’avoir les 2 parties dans le même fichier. Etant donné que ces outils sont à destination duwebmaster, il peut être intéressant de les regrouper de façon temporaire. Ce plugin permet donc de récupé-rer du code CSS contenu dans un fichier externe et de l’incorporer directement dans la page web entre lesbalises STYLE déjà présentes ou précédemment créées.

Intégrer les images

Lors de l’utilisation d’une page HTML distante (par URL) ou d’une page en locale avec des liens relatifs,les images ne sont pas accessibles directement par la plateforme de traitement. L’objectif de ce plugin estde modifier tous les liens (chemins d’accès) des images de la page pour que celle-ci soit lue correctement.La figure 2.10 comprenant 2 figures présente l’utilisation du plugin de la spécification 1.1 avec à gauchesans avoir utilisé au préalable le plugin d’intégration des images et à droite en l’ayant utilisé.

Statistiques

L’objectif de ce plugin est d’afficher simplement quelques petites statistiques d’un page web, notammentle nombre de liens, de tableaux, d’images, etc. La figure 2.11 présente l’interface de l’outil statistique.

Technique d’affichage des pages HTML

Lors du développement de la plateforme et des plugins, le PFE précédent a dû également mettre en



Figure 2.9 – Diagramme de classe de l’application existante



(a) (b)

Figure 2.10 – Interface du plugin de la spécification 1.1 (pour définir un texte alternatif aux image),(a) sans puis (b) avec utilisation préalable du plugin d’intégration des images

Figure 2.11 – L’interface de l’outil statistique

place un moyen d’afficher des pages HTML dans des composants java pour l’interface graphique. Il existeun composant appelé jEditorPane qui permet une fois avoir défini le type ”text/html ” d’afficher du codeHTML. Cependant cela peut devenir très vite lourd lors d’affichage de pages HTML très importantes. Ila donc choisi de placer les pages HTML à afficher dans des fichiers temporaires à la racine du moteur del’application. Ces fichiers sont créés juste avant leur utilisation puis affichés par le jEditorPane. Une foisque l’utilisateur a passé la fenêtre de dialogue qui affichait cette page, le fichier temporaire est détruit. Celanécessite cependant que la plateforme de traitement ait les droits d’écritures dans son propre répertoire (cequi est majoritairement le cas).

Source partie 2.3 : PFE, Restructuration de pages Web, Antoine Blais [8]



2.4 Travail à réaliser

2.4.1 Présentation générale

Ce projet de fin d’études s’inscrit dans la reprise du PFE de Antoine Blais. Dans un premier temps,j’ai analysé l’ensemble des éléments qu’il a mis en place (plateforme de traitement + plugins). Suite àcette analyse, un certain nombre de bugs ou encore de défauts ont été détectés sur l’application existante.Ma première mission est de corriger ces problèmes présentés dans la partie suivante et de réfléchir à desaméliorations possibles de ces éléments existants. Dans un seconde temps, j’ai dû sélectionner parmi les 60spécifications restantes des WCAG lesquelles j’allais choisir de développer. Pour cela, je me suis basé surl’étude des 35 sites internet d’Indre et Loire réalisée dans le cadre de la thèse de mon encadrante [20]. Lafigure 2.12 représente sous forme de camemberts les résultats de cette étude.

(a) (b)

Figure 2.12 – Répartition des erreurs (a) et des warnings (b) des sites web publics d’Indre-et-Loireentre les directives WCAG

Suite à cette étude, j’ai choisi de terminer la directive 1 dont la spécification 1.1 avait été commencéedans le PFE précédent. Cette spécification n’a été developpée par Antoine que dans le cadre des imagesmais elle impose la présence de textes alternatifs pour tout ce qui ne peut être perçu par un handicapé visuel(mais également par un lecteur d’écran). Il s’agit également des images cliquables, des vidéos, des appletsjava, des sons, etc. Il était donc nécessaire de terminer cette spécification qui était jusque là incomplète.La directive 1 ne comporte au final que cette spécification qui permet la manipulation de la page web.Les autres spécifications concernent le contenu des éléments multimédias (synchronisation des sous-titres,vérifications coté serveur, etc) et ne seront donc pas traitées par un plugin. Il s’agit au webmaster de faireun travail en amont sur les éléments qu’il met à disposition sur le site internet.

Ensuite, je m’attarderai sur la directive 3 dont aucun travail n’a été réalisé dans le passé. Cette directiveporte l’accent sur l’utilisation des balises et des feuilles de style de façon appropriée. Ne pas utiliser desbalises là ou un style est recommandé, et inversement. Il s’agit donc d’étudier en détail cette directive, pourchaque spécification, définir si elle est automatisable ou non. Trouver selon les différents cas, des solutionsautomatisables et manuelles pour le webmaster. Imaginer les interfaces homme-machine correspondantes etimplémenter le tout en différenciant chaque spécification par un plugin autonome.


Travail à réaliser

Pour terminer, en fonction du temps j’effectuerai le même travail sur la directive 11 qui n’a pas non plusété étudiée par le passé. Cette directive concerne l’utilisation des technologies du W3C. Cela se traduit parle remplacement des balises dépréciées par leur équivalent actuel, et le fait de fournir des informations demanière à ce que les utilisateurs puissent recevoir les documents selon les préférences qu’ils ont spécifiées.

2.4.2 Amélioration / correction de l’existant

Cette partie regroupe l’ensemble des problèmes que j’ai rencontrés lors des tests de la plateforme et desplugins existants. Je vais donc dans cette partie détailler les problèmes rencontrés, puis expliquer la manièredont je les ai résolus dans le prochain chapitre concernant le travail réalisé.

2.4.2.1 Problème de la plateforme de traitement

• Tout d’abord, j’ai découvert quelques problèmes d’interface. Il était possible de lancer la générationsans sélectionner de fichiers en entrée ou de plugins. Une exception était alors levée mais peu compréhensiblepar l’utilisateur de l’application. Il est donc nécessaire de mettre en place une vérification de tout cela enamont. De plus dans le cas où l’on ne sélectionnait pas de fichiers de sortie, il créait automatiquementun fichier de sortie sans extention du nom du label présent dans le champ. Toujours d’un point de vue del’interface, lors de la recherche d’un fichier HTML sur l’ordinateur, dans le cas d’un chemin long vers lefichier sélectionné, l’application se redimensionnait, lors d’un retour du focus, de manière à afficher le liendans sa globalité. La figure 2.13 montre ce problème de redimensionnement.

Figure 2.13 – Problème de redimensionnement lors de l’utilisation d’une URL longue

• Ensuite la manière dont les plugins étaient gérés me semblait problèmatique et limitée sur les actionspossibles par l’utilisateur :

1. Il était possible d’ajouter 2 fois le même plugin.

2. Il était impossible d’ajouter 2 plugins en même temps (pas de multi-sélection).

3. Il était impossible de supprimer plusieurs plugins en même temps.

4. Il était impossible de déplacer plusieurs plugins en même temps dans l’ordre d’utilisation.

De plus l’utilisation d’une simple liste de plugins me semblait tout à fait justifiable dans le cas d’unedizaine de plugins mais paraissait problématique dans notre cas étant donné qu’il existe 65 spécificationsdes WCAG et qu’il y a 2 versions à ces WCAG. Ajouter à cela les plugins d’aide au webmaster, on arriverapidement à un nombre important d’items dans la liste de sélection. Il est donc nécessaire de créer une



organisation au sein de ces plugins pour ne pas les afficher constamment et pouvoir les trier selon certainscritères. La figure 2.14 présente la liste utilisée par le PFE précédent montrant la sélection unique et lemanque d’organisation de celle-ci.

Figure 2.14 – Liste utilisée par le PFE précédent

• Lors du parcours du code Java de l’application et des plugins, j’ai également noté que les textes affichésdans l’interface graphique étaient tous codés en dur dans l’application. Cela pose un sérieux problème dansle cas où l’on voudrait une application qui soit multilangue. Après discussion avec mon encadrante, cetteapplication pourrait très certainement être adaptée à des plugins gérant des spécifications étrangères, ilserait donc intéressant de pouvoir internationaliser facilement l’ensemble de la plateforme de traitement.

2.4.2.2 Plugins

Concernant les plugins developpés par Antoine au cours de son PFE, je n’ai pas fait beaucoup de modifi-cations à l’exception du plugin d’intégration des images. Ce plugin d’extraction des images pour les aperçusétait uniquement destiné aux pages sur internet en recréant des liens de type "http ://". Concernant lespages en local, le moteur considérait que les images avaient toutes des liens absolus. Le problème se posaitalors pour les liens relatifs. Il faudrait adapter ce plugin en conséquence.

Un dernier problème concernant cette fois l’ensemble des plugins m’a très vite interpelé. Lors du lance-ment d’un plugin en mode manuel, il était impossible de stopper le parcours des différents éléments HTML.Une fois le plugin lancé, si la page contenait 100 images, il était nécessaire de cliquer 100 fois sur le boutonOK. Il est donc nécessaire de trouver une alternative à ce problème récurrent.

2.4.3 Technologies utilisées

2.4.3.1 Java

Le langage informatique n’était pas imposé mais il est très fortement recommandé de conserver le mêmeque celui précédemment utilisé lors de la reprise d’un PFE. J’ai donc utilisé Java [43] lors de ce PFE pourl’amélioration du moteur de l’application et le développement des plugins. La version du JDK que j’ai utiliséeest la version Java SE 6 sortie à la fin de l’année 2006.

2.4.3.2 Netbeans

L’environnement de développement que j’ai utilisé est NetBeans [39] reprenant ainsi celui qui avait étéutilisé dans le PFE précédent. J’ai cependant travaillé sur la version 6.5 de cet IDE alors que le projet avaitété créé au préalable sur la version 5.5. Aucune modification de code n’a été nécessaire mais des outilssupplémentaires dans cette version, notamment le profiling, m’ont permis d’améliorer certaines parties ducode.


Travail à réaliser

2.4.3.3 Swing

Swing est également la bibliothèque graphique officielle du JDK Java SE 6. Je l’ai donc utilisée pourréaliser les interfaces homme-machine des nouveaux plugins que j’ai développés.

2.4.3.4 JDOM

Lors de mon PFE, j’ai mis à jour JDOM [31] de la version 1.0 (septembre 2004) à la version 1.1 sortieen octobre 2006. J’ai corrigé les fonctions qui étaient dépréciées dans cette nouvelle version mais je n’ai pasutilisé cette bibliothèque autre part que dans le parsing du fichier XML des plugins.

2.4.3.5 Jericho

J’ai également mis à jour la bibliothèque Jericho [35] de la version 2.3 (novembre 2006) à la version2.6 sortie en mai 2008. J’ai remplacé les nombreuses fonctions dépréciées par leurs équivalents dans lanouvelle version de cette bibliothèque. Je l’utilise constamment dans le développement de mes plugins pourla détection, le parsing et le remplacement de balises et d’attributs HTML.

2.4.3.6 Batik

Batik [3] est un ensemble d’outils réalisés en java permettant d’utiliser des images au format SVG [52](Scalable Vector Graphics) dans une application. Il s’agit d’une initiative de la fondation Apache apparte-nant au ”XML Graphics Project”. Batik est composé de nombreuses classes et méthodes de manipulationdes images SVG mais également d’un compostant swing permettant de lire des fichiers SVG.

Cet ensemble d’outils m’a permis de créer des images SVG pour identifier facilement les parties d’uneimage cliquable dans la spécification 1.1.

2.4.3.7 JabRef

JabRef [34] est un logiciel permettant de réaliser facilement un fichier bibliographique pour latex (Bib-Tex). Il me permet de remplir facilement toutes les informations que je possède sur une source bibliographiqueet de générer le code latex correspondant. Je peux également ajouter les liens URL et même les fichiersutilisés lors de mes recherches documentaires.

2.4.3.8 Ocawa

Je n’ai pas utilisé de nouveau le validateur Ocawa [47] dans mon PFE étant donné qu’il est maintenantpayant ou limité au niveau de priorité 1 (A) dans sa version d’évaluation.

2.4.3.9 Apinc

Je n’ai pas utilisé non plus ce validateur dans mon PFE étant donné que le service anciennement fournipar l’association APINC [5] n’est plus disponible sur internet.

2.4.3.10 EvalAccess

EvalAccess [40] est un validateur web des WCAG developpé par The Laboratory of HCI for Special Needsat the University of the Basque Country (UPV-EHU). Je l’ai choisi en remplacement des validateurs utilisésauparavant et désormais non disponibles. Il m’a permis de valider l’ensemble de mes pages web testées,avant et après l’utilisation de mon application, permettant dans certains cas, de valider la correction miseen place.



2.5 Conclusion

Ce projet de fin d’études reprend le travail réalisé il y a 2 ans par Antoine Blais sur le traitement despages web. Dans cette démarche, j’ai pour objectifs d’améliorer l’existant notamment en corrigeant certaineserreurs que j’aurais pu identifier, puis continuer le développement des spécifications des WCAG sous la formede plugins. Dans ce cadre, un cahier des charges a été réalisé courant décembre en collaboration avec SoniaColas mon encadrante reprenant l’ensemble des besoins identifiés pour ce projet. Il est disponible en annexeA. De plus deux documents avaient été réalisés par Antoine au cours de son PFE :

1. Une notice webmaster pour la création d’un nouveau plugin.

2. Une aide utilisateur pour l’utilisation de la plateforme de traitement.

Ces 2 documents seront repris au cours de ce PFE et mis à jour en prenant en compte les modificationsque j’aurais effectuées au cours de ce PFE sur la plateforme de traitement.


CHAPITRE 3

Travail réalisé

Ce chapitre présente le travail que j’ai réalisé tout au long de mon PFE que ce soit en programmation ouen documentation. Les phases de tests réalisés durant ce projet seront présentées dans le chapitre suivant.Ce chapitre va s’articuler en 4 parties. La première partie portera sur la résolution des bugs découvertssur l’application du précédent PFE. La seconde partie présentera les améliorations que j’ai apportées àl’application après une étude approfondie de celle-ci. La troisième partie décrira l’ensemble des plugins quej’ai réalisés au cours de l’année. Et pour terminer, la dernière partie référencera l’ensemble des documents,manuels et documentation, que j’ai écrit pendant ce projet.

3.1 Correction de bugs

Cette partie présente l’ensemble des problèmes que j’ai découvert lors de l’utilisation de la plateformede traitement du PFE précédent. J’ai réparti ces problèmes en 2 catégories : les problèmes de génération etles problèmes d’interface.

3.1.1 Problèmes de génération

La première erreur qui m’est apparue lors de l’utilisation de la plateforme est la possibilité de générer untraitement (une page de sortie) sans avoir sélectionné de page en entrée ou sans avoir sélectionné de pluginsà utiliser. L’application n’affichait pas une erreur mais dans le cas du fichier en entrée, il se contentait delever une exception sur un fichier introuvable, ce qui n’est pas très parlant pour un utilisateur, et dans lecas d’aucun plugin sélectionné, il affichait un compte rendu vide. La figure 3.1 présente ces problèmes degénérations avec à gauche l’exception levée dans le cas où aucun fichier d’entrée (ou url) n’est fourni àl’application et à droite le compte-rendu vide affiché si aucun plugin à utiliser n’est sélectionné.

(a) (b)

Figure 3.1 – Présentation des problèmes de générations découverts, (a) exception sans fichier d’entrée(b) compte-rendu vide sans plugin sélectionné


Chapitre 3. Travail réalisé

Pour résoudre ce problème, un label affichant des messages d’erreurs a été placé sur la plateforme detraitement juste à côté du choix du mode d’utilisation. Dans le cas d’un clic sur les boutons ”générer” ou”générer aperçu” sans fichier d’entrée et/ou sans plugin sélectionné, la génération n’est alors pas effectuée etun message d’erreurs apparaît. La figure 3.2 présente les 2 messages d’erreurs actuellement en place sur laplateforme avec à gauche celui affiché dans le cas d’aucun fichier spécifié en entrée et à droite celui affichési aucun plugin n’est déplacé dans la colonne de droite.

(a) (b)

Figure 3.2 – Messages d’erreurs mis en place pour sécuriser la génération, (a) si aucun fichier n’estséléctionné (b) si aucun plugin n’est séléctionné

Un deuxième problème de génération m’est apparu un peu plus tard. En effet, pour identifier la partie del’application où l’on peut entrer un fichier de sortie pour sauvegarder le résultat, un label ”Fichier de sortie”est écrit dans le champ correspondant. Il est cependant possible de ne pas sauvegarder le résultat si l’on nele désire pas mais comme aucune vérification n’était réalisée sur le chemin entrée en fichier de sortie, unfichier nommé ”Fichier de sortie” et sans extension était créé systématiquement à la racine du projet lorsquecelui-ci n’était pas renseigné. La figure 3.3 présente cette création systèmatique d’un fichier de sortie avecà gauche le label présent dans le champ texte si aucun fichier n’est choisi et à droite le fichier ”Fichier desortie” généré à la racine de l’application.

(a) (b)

Figure 3.3 – Création systématique d’un fichier de sortie à la racine du projet, (a) le label ”Fichierde sortie” (b) le fichier généré

Le même problème était présent pour les fichiers en entrée (figure 3.1 (a)), mais après correction du bugprécédent , celui-là ne pouvait plus se produire. J’ai cependant réécrit entièrement les 2 fonctions permettantde renvoyer le chemin en entrée et le chemin en sortie pour ne plus retourner simplement le texte présentdans le champ en question. Ci-dessous, la fonction java ”getCheminOut” permet de récupérer le chemin dufichier de sortie si il est défini et renvoie null sinon.

/*** Permet de retourner une chaine de caractères contenant le chemin de destination du

fichier de sortie* @return String contient le chemin de destination du fichier de sortie, null sinon.**/public String getCheminOut() {

// Si aucun fichier, on teste pour ne pas créer un fichier avec le label d’informationif (jCheminOut.getText().compareTo(tr("Fichier_sortie")) == 0){

return null;}else{

// On modifie la chaine pour définir le type : file et remplacer les \ par des /pour une compatibilité java

return jCheminOut.getText().replace("\\","/") ;}

}


Améliorations apportées

3.1.2 Problèmes d’interface

Suite aux problèmes de génération, j’ai découvert quelques problèmes d’interface dans l’application exis-tante. Lors de la recherche d’un fichier HTML sur l’ordinateur, dans le cas d’un chemin long vers le fichiersélectionné, l’application se redimensionnait, lors d’un retour du focus, de manière à afficher le lien danssa globalité. Cela entrainait la perte d’une partie de l’interface permettant de gérer le choix des plugins àutilisé. La figure 3.4 montre ce problème de redimensionnement.

Figure 3.4 – Problème de redimensionnement lors de l’utilisation d’une URL longue

Pour palier à ce problème, il a fallu déterminer dans quelle mesure ce champ texte s’agrandissait aumoment de redessiner l’ensemble de la plateforme alors qu’il ne s’agrandissait pas au moment de la sélectiondu chemin. Lors de la mise à jour d’un label en java par la fonction ”setText”, un composant ne se redessinepas. Cependant lors d’un retour de focus, l’ensemble des composants est dessiné et donc ce composantcomportant le champ texte long l’est également. Il prend en compte le texte qu’il possède pour adaptersa taille. J’ai d’abord pensé qu’un définissant une taille maximum, cela empêcherait celui-ci de s’agrandirà la taille du texte mais cela n’a pas résolu le problème. C’est après quelque temps de recherche que j’aidécouvert que la solution reposait sur la taille préférée (PreferredSize). La ligne ci-dessous a alors résolu leproblème.

jCheminInFic.setPreferredSize(new java.awt.Dimension(100, 30));

Antoine Blais avait alors autorisé le redimensionnement de l’application pour pouvoir palier à ce problèmeen attendant de trouver une solution. Ce problème maintenant résolu, j’ai préféré empécher le redimension-nement de la fenêtre pour ne pas détruire la mise en page ou cacher des boutons. La ligne ci-dessousempêche l’utilisateur de pouvoir redimensionner la plateforme de traitement.

this.setResizable(false);

Pour conclure sur cette partie correction de bugs, il s’agit d’un premier travail assez simple à réalisergénéralement lors de la reprise d’un projet existant. Cependant, malgré le caractère assez simpliste du travailde programmation mis en place dans cette partie, il s’agit d’une étape primordiale pour bien comprendre àla fois le fonctionnement de l’application d’un point de vue utilisateur et également pour pouvoir étudier lecode d’un point de vue développeur et avoir une vue d’ensemble sur le projet existant.

3.2 Améliorations apportées

Une fois l’application bien étudiée et le code bien décortiqué, j’arrive sur un projet existant avec un œilneuf, une vision fraîche et il me vient à l’idée des améliorations à apporter. Il ne s’agit bien évidemment



pas de refaire l’ensemble de l’application, mais si les choix sont bien argumentés, il peut être intéressant depasser un peu de temps à améliorer le moteur de l’application. Après en avoir discuté avec mon encadrante,j’ai réalisé les améliorations suivantes.

3.2.1 Organisation des plugins

Lors de la reprise de ce projet, le moteur comportait 13 plugins à son actif. La gestion des plugins étaitdonc réalisé en conséquence, une petite liste comportant tous ces plugins dans l’ordre alphabétique. Lapartie gestion des plugins permettait de sélectionner un plugin dans une première liste qui correspondait auxplugins disponibles et de le passer dans une seconde liste qui représentait les plugins qui seront utilisés parle moteur. Cette gestion donnait également la possibilité à l’utilisateur de supprimer un plugin ou changerl’ordre de ceux-ci dans la seconde liste. Pour finir, une description du plugin sélectionnée apparaissait dansun cadre en dessous des listes. La figure 3.5 présente la gestion des plugins tels qu’elle était lors de la reprisedu PFE précédent.

Figure 3.5 – Gestion des plugins à la reprise du PFE

Une des premières choses que j’ai remarquée était que l’on ne pouvait gérer qu’un plugin à la fois etnon pas un groupe de plugins. Un seul déplacement à la fois entre les listes, une seule suppression, etc...La première chose que j’ai réalisée était donc la mise en place de la gestion des plusieurs plugins à lafois (explications dans la partie suivante). Cependant je ne me suis pas arrêter là, en effet après l’étudedes spécifications du WCAG 1.0 , je me suis rendu compte de l’existence d’environ 65 spécifications, cequi correspond à 65 plugins. Si l’on rajoute des plugins d’aide au webmaster comme celui d’Indentation,ou encore si l’on anticipe la mise en place du WCAG 2.0 qui contient un nombre au moins équivalent despécifications, on arrive très vite à un grand nombre de plugins à gérer. La gestion de plusieurs pluginsà la fois n’est plus suffisante. Il me vient alors à l’idée de hiérarchiser ces plugins en catégories et souscatégories à travers un arbre. Après quelques recherches sur les possibilités de mettre cela en place dansune interface Java, je m’intéresse particulièrement à JTree . Cela correspond un peu près à ce que l’on peututiliser dans notre explorateur windows pour parcourir nos dossiers. Pour le gestionnaire de plugins, chaquedossier serait une catégorie et chaque plugin un fichier. La figure 3.6 représente le passage d’un jListe àun jTree au sein du moteur de l’application. Intéressons nous maintenant à la mise en place de cette méthode.



Figure 3.6 – Passage d’un jListe à un jTree pour le moteur

3.2.1.1 Mise en place de JTree

La mise en place de JTree n’a pas été simple, en effet celui-là n’est pas facile à manipuler, mais il fallaiten plus dans mon cas, pouvoir modifier en temps réel l’arborescence du JTree stockant les fichiers que l’onva utiliser (changement de l’ordre et suppression). Regardons certaines généralités sur le fonctionnement deJTree.

Généralités sur JTree

La figure 3.7 présente le diagramme de classe de JTree. Une instance de JTree ne contient pas de don-nées, mais est simplement une vue de données contenues dans son modèle (architecture MVC). Les donnéessont affichées ligne par ligne, chaque ligne contenant exactement une donnée qui est un Nœud. Un arbre aune racine. Les nœuds qui n’ont pas de fils sont des feuilles. Une instance de JTree peut être créée par unconstructeur par défaut, ou par un constructeur ayant en paramètre un TreeNode ou un TreeModel. Tree-Model est une interface, qui est implantée par exemple par DefaultTreeModel. TreeNode est une interface,qui est dérivée en MutableTreeNode, qui est implantée par exemple par DefaultMutableTreeNode.

Figure 3.7 – Diagramme de classe de JTree

La classe DefaultMutableTreeNode

La classe DefaultMutableTreeNode est celle permettant de modifier dynamiquement un JTree dans leprogramme. Je me suis rendu compte par la suite que j’allais non seulement l’utiliser lors de la manipulationdes plugins utilisés par le moteur, mais également lors de la construction de l’arbre des plugins disponibles.En effet, chaque plugin est ajouté un par un dans cet arbre après détection des les fichiers existants dans



le repertoire Plugin. Après plusieurs échecs de l’implémentation des catégories de plugins sans modifier lediagramme de classe existant, j’ai donc réfléchi à la mise en place d’une classe supplémentaire, la classeCatégorie.

La classe Categorie

L’idée de départ lors de la création de ce moteur par le précédent PFE était de pouvoir ajouter desplugins sans avoir à recompiler le moteur. Dans cette optique, je ne voulais pas imposer dans le moteurun certain nombre de catégories ce qui n’aurait pas rendu le moteur très souple lors de la création d’unnouveau type de plugin ou l’arrivée de nouvelles spécifications liées aux handicaps. La figure 3.8 présentele diagramme de classe des plugins tels qu’il était avant la modification et la figure 3.9 présente le mêmediagramme après l’ajout de la classe catégorie et des fonctions correspondantes.

Figure 3.8 – Diagramme de classe des plugins avant la modification

Figure 3.9 – Diagramme de classe des plugins après la modification

Chaque plugin a donc en plus une fonction getCategorie qui renvoie l’ensemble des catégories parentsde ce plugin. J’ai implémenté un algorithme récursif qui analyse par niveau les catégories déjà ajoutées à



l’arbre, et en fonction de la présence ou non de la catégorie, j’ajoute ou parcours les sous catégories de celle-ci.

Algorithme de parcours

Prenons l’exemple de la figure 3.10 dans lequel on a un arbre qui contient déjà des plugins classés encatégories, et où l’on veut rajouter un nouveau plugin qui correspond à la spécification 11.2. La fonctiongetCategorie renvoie une Catégorie de noms WCAG 1.0 qui ne contient un fils de nom Directive 11 quicontient pas de fils (categorie). On commence par analyser tous les nœuds de premier niveau, ici WCAG1.0 et Outils Webmaster, pour cela on parcourt les frères (parcours en largeur d’abord). Si l’on trouveune catégorie ayant le même nom que le parent le plus haut du plugin que l’on veut insérer on s’arrête etexplore les fils de celui-ci en utilisant le même algo de façon récursive. Cette fois-ci on se retrouve dans lecas où l’on ne trouve pas de catégories existantes portant le nom Directive 11, on crée donc la catégorieet on continue l’algorithme de façon récursive. Il n’y a plus de catégorie, car le fils de Directive 11 est nul.On ajoute donc le plugin à cette catégorie. On met à jour l’arbre des plugins disponibles. La figure 3.10illustre l’algorithme de parcours décrit précédemment.

Figure 3.10 – Illustration de l’algorithme de parcours

Le code java de création d’un nœud dans l’arbre lors du parcours de tous les plugins présents dans lerépertoire ”plugin” est le suivant :

/*** Cette méthode crée un noeud dans l’arbre en utilisant l’algorithme de parcours* mise en place pour le JTree. Méthode récursive.**/private void createNode(DefaultMutableTreeNode parent, Categorie cat, Plugin plug){

DefaultMutableTreeNode node = parent.getNextNode();Boolean ajout = false;//Tant qu’il existe des noeuds existantwhile((node != null) && (ajout == false)){

if(node.getUserObject().equals(cat.getNom())){//Si la catégorie n’a pas de fils, on ajoute le pluginif(cat.getFils() == null){

node.add(new DefaultMutableTreeNode(plug));parent.add(node);

}//Sinon on rapelle récursivement la fonction createNodeelse{

createNode(node, cat.getFils(), plug);}ajout = true;

}else{



//On passe au noeud frère suivantnode = node.getNextSibling();

}}//Si on a pas trouvé de noeud existant pour cette catégorieif (ajout == false){

//On crée le noeudDefaultMutableTreeNode newNode = new DefaultMutableTreeNode(cat.getNom());parent.add(newNode);//Si la catégorie n’a pas de fils, on ajoute le pluginif(cat.getFils() == null){

newNode.add(new DefaultMutableTreeNode(plug));parent.add(newNode);

}//Sinon on rappelle récursivement la fonction createNodeelse{

createNode(newNode, cat.getFils(), plug);}

}}

Il ne reste plus qu’à réaliser cet algorithme de parcours pour tous les plugins et l’on obtient un arbrecomplet. La figure 3.11 présente la gestion des plugins après l’implémentation terminée de JTree.

Figure 3.11 – Gestion des plugins après l’implémentation de JTree



3.2.2 Multisélection des plugins

Comme nous l’avons précisé précédemment, la gestion des plugins dans l’application du PFE précédentne permettait de gérer qu’un seul plugin à la fois avec une liste ne permettant qu’une seule sélection. J’avaisfait la modification sur les JListes présentes au début pour faire une multisélection et ainsi gérer plusieursplugins en même temps. J’ai reporté ces modifications à la gestion des JTree une fois l’implémentationterminée en faisant bien attention que l’on ne puisse pas avoir 2 fois le même plugin dans la liste de ceux àutiliser comme c’était le cas avant. Je ne vais pas présenter le code de l’ensemble des boutons de navigationdes plugins ici mais montrer un aperçu avec celui du passage d’un (ou plusieurs) plugins(s) de la liste desplugins disponibles à la liste des plugins à utiliser.

public void actionPerformed(ActionEvent e) {/* Lors d’un clic sur le bouton jButAdd, on effectue une copie de la liste des Plugins

selectionnés (dans disponible) vers la liste des Plugins à utilisés */if( e.getSource() == jButAdd ) {

DefaultMutableTreeNode tmp;//Recupération d’un objet comportant tous les plugins sélectionnésTreePath tp[] = jTreePluginDispo.getSelectionPaths();//Si la séléction n’est pas videif( tp.length != 0 ) {

//On ajoute les plugins à la liste des plugins qui vont être utilisés par le moteurfor(int i = 0; i < tp.length ; i++) {

tmp = (DefaultMutableTreeNode)tp[i].getLastPathComponent();addLeaf(tmp);

}jTreePluginUtil.updateUI();

}}//[...]

}

/*** Méthode permettant d’ajouter une/des feuille(s) à la liste des* plugins à utiliser.**/private void addLeaf(DefaultMutableTreeNode tmp){

DefaultMutableTreeNode node,next,tempo;Boolean ajouter=true;//Si il s’agit d’une feuille, on l’ajouteif(tmp.isLeaf()){

//On vérifie que le plugin n’a pas déjà été ajouté pour éviter les doublonsnode = new DefaultMutableTreeNode(tmp.getUserObject());next = racineUtil.getNextNode();while(next!=null){

if(next.getUserObject().equals(node.getUserObject())){ajouter=false;

}next = next.getNextNode();

}if(ajouter)

racineUtil.add(node);}else{//Sinon, il s’agit d’un noeud, donc on ajoute ces fils

int count = tmp.getChildCount();tempo = tmp.getNextNode();for(int i = 0; i < count ; i++) {

addLeaf(tempo);



tempo = tempo.getNextSibling();}

}}

3.2.3 Gestion multilangue

Lors de la programmation du moteur et des plugins par le PFE précédent, aucun accent n’a été portésur l’internationalisation de l’application. En effet, les labels affichés sont écrits en dur dans le code ce quine permet pas de changer facilement la langue de l’application dans le cas d’un développement multilangue.Après discussion avec Sonia, mon encadrante, nous avions convenu que ça pourrait être une fonctionnalitétrès intéressante étant donné que les normes du web sont différentes en fonction des pays de l’Europe et dumonde. Il existe en plus des WCAG qui sont elles internationnales, des normes locales aux différents paysqui souhaitent améliorer l’accessibilité d’Internet.

3.2.3.1 Fichier de configuration

Lorsque l’on parle de choisir une langue dans une application, il est nécessaire de stocker ce choix quelquepart. Etant donné que ce choix doit être conservé d’une exécution à l’autre de la plateforme de traitementet que la modification ne peut pas se faire sans redémmarer l’application, il est donc nécessaire de le stockerdans un fichier. Dans l’optique de créer une fenêtre d’option pour choisir la langue à sélectionner, on imaginetrès bien par la suite pouvoir configurer d’autres parties du logiciel dans cette même fenêtre. J’ai donc misen place une classe configuration qui permet le stockage et l’accès à toutes les propriétés de configurationpendant une instance de la plateforme, ainsi qu’un fichier ”Config.properties” permettant de sauvegarder ceschoix sur le disque dur entre deux exécutions de l’application.

La classe Configuration permet le chargement des propriétés à l’aide de la fonction loadProperties et lasauvegarde de ces mêmes propriétés à chaque changement grâce à la fonction saveProperties. Ces fonctionsrécupèrent le fichier ”Config.properties” contenu dans le répertoire ”config” à la racine de l’application. Sice chemin n’existe pas, le répertoire et un fichier vide sont alors créés. Le fichier ne comporte pour l’instantque la clé lang à laquelle est associé l’indice de la langue utilisée : fr, en, etc.

Ce fichier est utilisé conjointement avec la fenêtre d’option illustrée par la figure 3.12.

Figure 3.12 – La fenêtre d’option permettant de choisir la langue de la plateforme

Cette fenêtre comporte les éléments suivants :

• Une liste de sélection permettant de choisir la langue désirée.• Un bouton Ok qui sauvegarde les propriétés de configuration dans le fichier Config.properties, puis

ferme la fenêtre en affichant un message d’information indiquant la nécessité de redémarrer l’applica-tion dans certains cas.



• Un bouton Annuler et la croix rouge permettent de fermer la fenêtre sans faire aucune modificationsur la configuration.

Il est maintenant facile de rajouter d’autres options de configuration à l’application. Elles seront sauve-gardées dans le même fichier et exploitables de la même manière que la langue dans la classe Configuration.Il est cependant nécessaire de faire quelques modifications dans le code pour cela, d’ajouter le choix del’option dans l’interface ”ihmOptions” et de recompiler le moteur de la plateforme.

3.2.3.2 Fichier de langue

Les différentes langues disponibles dans l’application sont réparties dans différents fichiers propertiesavec un fichier par langue. Ces fichiers contiennent l’ensemble des traductions que ce soit pour le moteurou les différents plugins. Dans un premier temps, j’avais envie de faire un fichier de langues pour le moteuret pour chaque plugin. Ce fichier aurait été réalisé dans un package de chacun des projets java et compilédans le .jar. L’avantage de cette méthode est de bien séparer les fichiers de langues pour chaque partie del’application (moteur et plugins) et d’utiliser les Bundle en java qui sont destinés à l’internationalisation desapplications. Cependant, deux inconvénients se sont très vite posés à moi. Le premier est que le nombre defichiers serait devenu très vite important. En effet, si l’on se replace avec les 65 spécifications du WCAGet que l’on traduise l’application ne serait ce qu’en 5 langues différentes, on arrive alors à 65 * 5 = 325fichiers de langues. En plus de cela, un fichier de langue est chargé au démarrage de l’application, horsutilisant plusieurs fichiers en même temps pour gérer les différents plugins externes, cela semblait plutôtdifficile de permuter l’utilisation de plusieurs fichiers de langue en même temps. Je suis donc parti sur unseul fichier par langue avec toutes les traductions à l’intérieur (moteur + plugins). Ce fichier est bien sûrexterne à l’application et dans le cas de la création d’un nouveau plugin, il suffit de rajouter dans ce fichierles associations clé ⇔ valeurs que l’on a utilisé dans nos interfaces. L’utilisation n’est pas vraiment pluscompliquée du point de vue du développeur étant donné qu’il s’agit toujours de fichiers .properties mais il afallu cependant gérer les différentes langues disponibles à la main. L’avantage d’avoir un fichier externe estque dans le cas d’erreurs de traduction, l’utilisateur de l’application peut modifier lui même la traductionsans avoir à recompiler le moteur. Comme tous fichiers properties, il s’agit d’un ensemble de clé ⇔ valeur,dans notre cas les clés sont en français (langue de développement de l’application) et les valeurs dans lalangue souhaitée. La figure 3.13 représente un extrait du fichier de traduction de l’application en Anglais.

Figure 3.13 – Extrait du fichier de traduction de l’application en Anglais

Du point de vue du programmeur, la classe Language comporte les attributs suivants :



• Properties properties_language : Contient les associations clés ⇔ valeurs chargées à partir dufichier properties• Map<String,String> available_languages : Contient les relations indices ⇔ langue pour le choix

dans les options (ex : en ⇔ Anglais)• String default_language : Contient l’indice de la langue par défaut de l’application (Ici fr)• String current_language : Contient l’indice de la langue utilisée actuellement dans l’application

Il existe également dans cette classe une fonction tr(String clé) qui permet à partir de la clé passée enparamètre de retourner la chaîne correspondante dans la langue choisie. Les développeurs d’un plugin ontalors 3 choses à faire pour pouvoir utiliser le système de langues :

1. Faire un import statique de la fonction ”tr” pour pouvoir l’utiliser directement dans le code commes’il s’agissait d’une fonction locale.import static Moteur.Language.tr ;

2. Lors de l’affichage d’un texte à l’utilisateur utiliser la fonction tr(” mot clé ”) plutôt qu’une chaine endur

3. Faire une association ”mot clé = valeur ” dans chacun des fichiers de langues qui se trouve dans lerépertoire language.

J’ai ensuite repris entièrement le moteur et les différents plugins pour adapter tous les textes visibles parl’utilisateur (pas les traces de debug) et faire l’association avec les deux langues : le français par défaut etl’anglais. L’application est donc entièrement traduite dans les 2 langues, il convient aux futurs développeursde garder cette cohérence en remplissant les fichiers de langues (répertoire ”langage”) à chaque fois qu’ilsajoutent un libellé visible par l’utilisateur.

3.2.4 Plugins existants

Une fois les modifications terminées sur le moteur, j’ai également effectué quelques modifications sur desplugins réalisés par Antoine Blais. Le plugin d’intégration des images destiné à changer le chemin de celles-cipour les aperçus ne fonctionnait pas correctement. Il était uniquement destiné aux pages sur internet enrecréant des liens de type "http ://" et ne prenait pas en compte les liens relatifs sur l’ordinateur. J’ai doncamélioré ce plugin pour également changer ce type de lien en lien absolu pour un affichage des images. Deplus ce plugin fonctionnait uniquement pour les images, c’est à dire les balises IMG. Lorsque j’ai continué laspécification 1.1, il m’a fallu l’adapter à tous les médias existants : Images cliquables, input de type image,applet, etc. J’ai pour cela créé un nouveau plugin appelé IntrégationMédias.

Comme je l’ai expliqué dans le précédent chapitre, lors de l’utilisation du mode manuel sur un ensembled’images ou de tableaux (peu importe le plugin), il était impossible d’arrêter le parcours des différents élé-ments HTML. Une fois le plugin lancé, si la page contenait 100 images, il était nécessaire de cliquer 100fois sur le bouton OK. Il était donc essentiel de trouver une alternative à ce problème récurrent. Mon idéeétait de permettre de fermer une fenêtre popup à l’aide de la croix ce qui aurait pour action de continuer leséléments suivants en mode automatique. Cependant le mode manuel et automatique était défini comme unentier passé en paramètre des fonctions ce qui posait problème. En effet, en java, les types primitifs tels queles entiers sont passés par valeur en paramètre de fonction. Cela signifie qu’une variable locale à la fonctionest créée, et que l’on recopie dans l’espace mémoire associé à cette variable la valeur associée à la variableinitiale. Cela implique que tout changement de la variable mode dans le code de l’ihm de la fenêtre (par safermeture) ne sera pas gardé en mémoire lors de l’exécution des popups suivantes.

Pour résoudre ce problème, j’ai réalisé une classe mode comportant un seul attribut privé de type entier, 2méthodes qui sont les accesseurs de l’attribut et 2 constantes définissant la valeur du mode automatique (1)et du mode manuel (2). Il ne restait alors plus qu’à modifier tout le code du moteur et des plugins existants


Plugins réalisés

pour manipuler non plus un entier mais une classe ”Mode” comportant un attribut entier, et modifier cetattribut à l’aide du modificateurs ”setMode”. Une fois ce changement effectué, lors de la fermeture d’unepopup en mode manuel, la valeur du mode est changée et aux prochains passages dans la boucle des élémentsHTML à traiter, l’exécution se fera en mode automatique. Ce changement est irréversible étant donné quele mode automatique ne demande aucune action de la part de l’utilisateur jusqu’au compte-rendu final. Ilest alors nécessaire de relancer l’ensemble des fenêtres du mode manuel en cas d’erreur.

3.3 Plugins réalisés

3.3.1 Directive 1

L’étude qui a été réalisée sur les 35 sites internet d’Indre et Loire par mon encadrante Sonia Colas, m’afait choisir la directive 1 comme premier ensemble de plugins à réaliser. Antoine Blais au cours de son PFEa déjà réalisé la spécification 1.1 mais de façon incomplète étant donné qu’il a traité uniquement le cas oùl’on définit un texte alternatif et une description longue à une image. Il est donc nécessaire de terminer cettespécification pour tous les autres médias et balises autre que les images (balises IMG).

Les autres spécifications de la directive 1 sont les suivantes :

• Spécification 1.2 - A : Fournir des liens textes redondants pour chaque région active d’une cartecliquable côté serveur. L’ajout de textes alternatifs aux images cliquables (AREA) sont réalisés dansla spécification 1.1 que j’ai réalisée par la suite.• Spécification 1.3 - A : Fournir un équivalent textuel (par exemple des sous-titres ou la description

auditive des pistes visuelles) d’une piste visuelle (par exemple une vidéo) ou toute autre présentationmultimédia. Cela est un travail à réaliser par le webmaster en amont et ne peut être vérifié par notreplateforme.• Spécification 1.4 - A : 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 descriptionauditive des pistes visuelles) avec la présentation. Ce travail est également à faire en amont par lewebmaster lors de la mise à disposition d’une présentation multimédia sur une page web.• Spécification 1.5 - AAA : Fournir des liens textuels redondants pour chaque région active d’une carte

cliquable côté client.Les autres spécifications de la directive 1 concernent des éléments externes (vidéos) ou des éléments

côté serveur. Elles ne sont donc jamais présentes dans les rapports d’erreurs des validateurs. De ce fait, laspécification 1.1 est l’unique spécification de la directive 1 qui vaut le coup d’être implémentée.

3.3.1.1 Définition WCAG de la spécification 1.1

”Fournir un équivalent textuel à chaque élément non-textuel (par exemple via " alt ", "longdesc ", ou dans le contenu des éléments). Ceci inclut : les images, les représentationsgraphiques de texte (y compris les symboles), les zones actives de cartes cliquables, les animations(par exemple les GIF animés), les appliquettes et objets programmatiques, l’art ascii, les cadres,les scripts, les images utilisées comme puces pour les listes, les éléments d’espacement, lesboutons graphiques, les sons (joués avec ou sans interaction de l’utilisateur), les fichiers audioséparés, les pistes audio de vidéos, et la vidéo.” [17]

3.3.1.2 Présentation de la spécification 1.1

La spécification 1.1 a déjà été commencée en implémentant une IHM permettant de donner un textealternatif et une description longue à la balise IMG. Cependant cette spécification est très complète comme



nous avons pu le voir ci-dessus dans la description du WCAG et concerne l’ensemble des éléments non-textuels. Les alternatives que j’ai mis en place concernent les balises HTML suivantes :

• area• input de type image• applet• embed• button

Je vais maintenant détailler la mise en place de chacune de ces balises.

3.3.1.3 Balise area

La balise area permet de définir des zones cliquables dans une image pour pemettre d’accéder à différentsliens hypertextes. Ces zones cliquables se traduisent dans le fichier HTML par la présence d’une balise mapqui contient un nom (name). Celui-ci est utilisé dans la balise image en tant que valeur de l’attribut usemappour définir que ces zones cliquables s’appliquent à cette image. Cette map contient plusieurs balises areaqui correspondent à la délimitation des zones et à la référence d’un lien cliquable. C’est donc cette balise quidoit contenir un texte alternatif pour identifier les différentes zones d’une image avec un nom qui correspondà la partie de l’image.

Pour identifier les différentes zones cliquables au sein d’une image globale, j’ai mis en place un fichierSVG permettant de délimiter ces zones en les entourant en rouge. Ce procédé permet de montrer au web-master pour quelle partie de l’image il est en train d’écrire un texte alternatif. Cette implémentation estassez intuitive du fait que les balises area et les formes SVG utilisent la même syntaxe à quelques variantesprès.

Prenons par exemple le site internet d’une ferme découverte dont le menu serait le plan de la ferme.Pour accéder aux différentes pages, il faudrait cliquer sur les batiments qui composent le plan. On aurait uneimage cliquable composée de 6 sous parties définies dans des balises areas. La figure 3.14 présente l’aspectd’une telle page en identifiant en pointillés verts les contours de l’image et en trait de couleurs les 6 partiescliquables de l’image.

Le code HTML pour définir une telle zone est le suivant :

<area shape="poly" coords="96,249,187,246,195,366,149,368,144,291,96,291" href="./galeries/legite.html" />

Du point de vue du SVG, les zones de dessins utilisent les mêmes attributs de coordonnées que les balisesAREA. On peut donc définir la balise SVG suivante pour dessiner autour de la zone à identifier.

<svg:polygon points="96,249,187,246,195,366,149,368,144,291,96,291" style="fill:none;stroke-width:4;stroke:red;"/>

A partir de là, on peut obtenir pour chaque balise area, l’image globale avec une seule partie à la foisidentifiant la zone à laquelle donnait un texte alternatif (figure 3.15).

La création du code SVG a donc été simpliste, mais son rendu un peu moins. En effet, pour afficherjusqu’à présent le code HTML pour les images ou encore pour les tableaux dans la directive 5, nous utilisionsun JEditorPane qui ne lit pas le SVG mais affiche son code source... J’ai donc cherché un procédé pourtransformer ce code SVG en HTML ou en image. Sans succès, je me suis orienté sur une autre méthode,affiché le code SVG à l’aide d’une autre composant graphique. Je me suis tourné vers la librairie gratuite


Plugins réalisés

Figure 3.14 – Image représentant le plan d’une ferme avec 6 zones cliquables pour accéder aux pagesdu site

Batik [3] qui comporte un composant swing permettant de le faire. J’ai donc appris à la manipuler et réussi àafficher un fichier SVG. J’ai adapté le code de sélection de titre et de description d’une image au choix d’untitre pour une zone cliquable en mode manuel. Un mode automatique est également disponible dans lequelj’ai choisi l’ordre des titres possibles pour les zones cliquables. La figure 3.15 présente l’IHM permettant dechoisir un titre pour une zone cliquable.

Cette méthode est très pratique pour le webmaster mais ne fonctionne pas à 100%. En effet, la librairieBatik nécessite de connaitre la taille d’une image pour pouvoir l’afficher et pour que les zones se positionnentau bon endroit. Si la taille est définie dans les attributs ”width” et ”height” de la balise IMG ou encore dansun style directement dans la balise, il est facile de la récupérer. Cependant si aucune taille n’est définieou qu’elle est définie dans un style global à un ensemble de balises dans une feuille de style externe, il estdifficile de la récupérer. A ce moment-là, aucun aperçu ne pourra être créé. De plus certains formats decompression ne sont pas gérés par la librairie Batik mais pour essayer de palier à ce problème, un lien permetd’ouvrir l’image orginale dans votre navigateur pour avoir une information supplémentaire.

3.3.1.4 Balise input de type image

Le cas de la balise input de type image a été implémenté de façon relativement simple, on détecte laprésence de ce type de balise et on affiche la source de celle-ci dans une balise <img> pour afficher l’imageen question au webmaster qui choisit un texte alternatif. On change alors la balise <input> du formulaireen ajoutant l’attribut ”alt” contenant le texte alternatif. En mode automatique, l’attribut ”alt” sera ajoutéou conservé et contiendra dans l’ordre, soit :



Figure 3.15 – Fenêtre de choix d’un titre pour une zone cliquable

1. La valeur de l’attribut ”alt” déjà présent

2. Input de type image : nom de l’image

3. Input de type image

La figure 3.16 présente un exemple d’IHM que l’on obtient en mode manuel lors de la détection d’uninput de type image. On aperçoit bien la présence d’une image correspondant à un bouton de recherche liéeà un formulaire. Le nom proposé en titre par défaut est le nom de l’image passée en paramètre de la baliseinput.

3.3.1.5 Balise applet

Un cas plus complexe est celui des applets dans les pages HTML. En effet, un webmaster créant uneapplet en java peut l’intégrer sur une de ces pages web avec soit la balise APPLET qui est à ce jourdépréciée, ou alors à l’aide de la balise OBJECT. Dans ces 2 cas, il est nécessaire d’y associer un textealternatif étant donné qu’il s’agit d’un support inadapté pour les handicapés visuels, mais également pourdes personnes qui n’auraient pas la machine virtuelle java d’installée sur leur ordinateur. La détection de cetype de balise se fait de manière assez simple, cependant sa représentation auprès du webmaster est trèsdifficile. En effet, le composnant swing jEditorPane qui affiche du code HTML ne prend pas en compte leséléments dynamiques telles que balises HTML appelant une applet java. J’ai effectué de nombreuses heuresde recherche sur la manière d’exécuter une applet de cette manière, mais je n’ai pas trouvé de solutiondans le temps que je m’étais donné sur la tâche. Pour ne pas prendre du retard sur l’ensemble du projet,j’ai cherché une alternative à cet affichage. J’ai donc opté pour écrire le code HTML de l’applet dans unfichier HTML temporaire et permettre au webmaster de l’ouvrir dans son navigateur internet. La figure 3.17


Plugins réalisés

Figure 3.16 – Fenêtre de choix d’un titre pour un input de type image

présente les interfaces mises en place pour cette balise avec à gauche la popup donnant le nom du fichier.jar, permettant d’ouvrir l’applet et de donner un titre à celle-ci et à droite l’applet en question ouverte dansun navigateur web.

(a) (b)

Figure 3.17 – IHM de la balise applet, (a) la popup permettant d’ouvrir l’applet et d’écrire le textealternatif (b) l’applet ouvert dans un navigateur web

3.3.1.6 Balise embed

La balise embed est une balise définie par les WCAG comme inaccessibles du fait qu’il n’existe pasde méthode permettant de fournir des alternatives textuelle. Etant donné que son utilisation est multiple(intégration de documents, sons, images, vidéos, etc) il n’est pas évident de donner une alternative auwebmaster. Dans un premier temps, j’avais mis en place une fenêtre alertant le webmaster de la présence



d’une balise embed accompagnée du nom du fichier ajouté grâce à celle-ci. Etant donné que la baliseest inaccessible, dans un second temps, j’ai rajouté une option permettant de commenter l’ensemble ducode de cette balise. Il est du devoir du webmaster si il veut continuer d’intégrer ce document à sa pageHTML, de trouver la balise accessible adéquate pour le faire. La figure 3.18 présente la popup permettantde commenter une telle balise. Il pourrait être intéressant à partir du type de fichier ou de l’extension deproposer des alternatives complète à l’aide des balises IMG et OBJECT par exemple. Après avoir passé unegrande partie de mon temps sur cette spécification, je n’ai pas voulu trop développer cette partie dans cePFE.

Figure 3.18 – Fenêtre permettant de commenter ou pas la balise embed

3.3.1.7 Balise button

Le balise button est le dernier élément que j’ai réalisé pour la spécification 1.1. En effet, il s’agit d’unebalise peu utilisée par les webmaster mais qui a le mérite de posséder un attribut ”alt” permettant delui donner un texte alternatif. La fenêtre la valeur des attributs ”name” et ”value” au webmaster pourqu’il identifie le bouton en question. Il n’est pas possible de l’afficher comme un élément HTML avec lejEditorPane. La figure 3.19 présente l’ihm permettant de fournir un titre à une balise button.

Figure 3.19 – Fenêtre permettant de founir une alternative textuelle à un bouton

3.3.2 Directive 3

Pour continuer dans les priorités des directives à traiter d’après l’étude des sites internet d’Indre et Loire,je me suis penché sur la directive 3. Cette directive préconise l’utilisation des balises et des feuilles de stylede façon appropriée pour ne pas restreindre l’accessibilité. Le fait de détourner une balise pour créer uneffet de présentation (par exemple, utiliser une table pour la mise en page ou un en-tête pour changer lataille de la police de caractères) ne permet pas à un handicapé utilisant un logiciel spécialisé de comprendrel’organisation de la page ou d’y naviguer. Il en va de même pour l’utilisation de style permettant de grossir untitre à la place des balises d’en-tête, ou de donner l’effet d’une liste sans utiliser le balisage approprié.. Etantdonné qu’aucune étude spécifique n’avait été faite sur cette directive, j’ai décidé de faire ma propre étudesur les différentes spécifications qui la composent. Pour cela je suis parti de la base de tests que j’ai miseen place (voir chapitre suivant) afin d’étudier la répartition des erreurs et des warnings par les validateurs


Plugins réalisés

automatiques concernant la directive 3. La figure 3.20 présente la répartition des erreurs (à gauche) et deswarnings (à droite) de la directive 3, et cela classé par spécification.

(a) (b)

Figure 3.20 – Répartition des erreurs (a) et des warnings (b) de la directive 3 (par spécification)

L’ordre de priorité qui découle de cette analyse est le suivant :

• Spécification 3.4 - AA : utiliser des unités relatives plutôt qu’absolues dans les valeurs d’attributs dulangage et les valeurs de propriétés des feuilles de style.

• Spécification 3.1 - AA : utiliser des balises plutôt que des images quand cela est possible pour trans-mettre l’information.

• Spécification 3.5 - AA : utiliser des éléments d’entêtes pour la structure du document et les utiliseren conformité avec les spécifications.

• Spécification 3.6 - AA : utiliser les éléments de liste de façon correcte.

• Spécification 3.3 - AA : utiliser les feuilles de style pour la mise en page et la présentation à la placedes balises.

• Spécification 3.2 - AA : validation DocType et grammaires (HTML, X-HTML, CSS, ...) .

• Spécification 3.7 - AA : ne pas utiliser les balises citations pour les effets de style comme l’indentation.

Cependant les deux spécifications prioritaires sont également les plus difficiles à mettre en place.

Spécification 3.4 Utiliser des unités relatives plutôt qu’absolues me semble très difficile pour garder unecohérence dans la page. En effet, les unités relatives sont soit en pourcentage de la largeur de la page,et cela est très difficile à calculer, soit en unité "em", ce qui signifie que la taille est définie par rapportà la taille de la balise englobante.

Spécification 3.1 Comment savoir si une image peut être remplacée par une balise, il me semble troplourd pour le webmaster de lui demander pour chaque image si c’est le cas.

Etant donné que la spécification 1.1 m’a pris plus de temps que prévu, j’ai préferé me consacrer surles autres spécifications un peu moins prioritaires pour pouvoir avancer et continuer de réfléchir sur lesspécifications ci-dessus.



3.3.2.1 Spécification 3.2

WCAG

”Créer des documents qui sont validés par des grammaires formelles publiées. Par exemple,inclure une déclaration de type de document (" document type declaration ") au début dudocument, se référant à une DTD publiée (par exemple, la DTD " strict HTML 4.0 ").” [17]

Présentation

Le DOCTYPE d’un document permet de définir quelle grammaire a été utilisée pour l’écrire. Il permetentre autre de pouvoir contrôler cette grammaire à l’aide d’un validateur de document. Il est donc indispen-sable que toutes pages web comportent un DOCTYPE dans le but d’avoir un document valide. j’ai identifié3 types de problèmes qu’une page web peut avoir concernant son DOCTYPE :

1. Ne pas avoir de DOCTYPE

2. Avoir plusieurs DOCTYPE dans le même document

3. Avoir un DOCTYPE incorrect (mauvaise écriture ou mauvais placement)

Dans le cadre du développement de ce plugin, j’ai réalisé les 2 premiers points. J’ai réalisé cette spécifi-cation dans les dernières de mon PFE et je n’ai pas eu le temps d’implémenter le 3ème point.

DOCTYPE manquant

Lors du parcours de la page web, si aucune balise DOCTYPE n’est detectée, une interface est alorsaffichée à l’utilisateur en mode manuel pour lui demander quel doctype souhaite-t-il ajouter au début de sapage. La figure 3.21 présente la fenêtre permettant d’ajouter un DOCTYPE en début de page.

Figure 3.21 – Aperçu de l’IHM de la spécification 3.2 permettant d’ajouter un DOCTYPE

Le webmaster a alors 2 possibilités : il peut choisir un des DOCTYPES standard que j’ai référencé dansle plugin grâce à une liste déroulante ou copier lui même son DOCTYPE dans le champ texte présent en des-sous après avoir choisi l’option ”Autre”. En mode automatique, le DOCTYPE ”HTML 4.01 Strict” est ajoutéen début de page. Ce choix de DOCTYPE automatique est défini dans la variable DEFAULT_DOCTYPEdu code de la spécification 3.2 et peut donc être changé en recompilant le plugin en question.


Plugins réalisés

Plusieurs DOCTYPE

Dans le cas de la détection de plusieurs DOCTYPES, un rapport d’erreurs indique les différents DOC-TYPES détectés dans la page permettant ainsi au webmaster de faire du ménage dans sa page web. Lafigure 3.22 présente le mini rapport informant le webmaster de la détection de plusieurs DOCTYPES et deleurs codes.

Figure 3.22 – Aperçu de l’IHM de la spécification 3.2 affichant un rapport de détection de plusieursDOCTYPES

Évolutions futures

Dans le cas de la détection de plusieurs DOCTYPES, le webmaster est obligé de faire cette correctiondans sa page web de façon externe à notre plateforme. Par la suite, il serait intéressant de proposer desupprimer un ou plusieurs des DOCTYPES présents pour n’en garder qu’un le tout à l’aide d’une interfaceutilisateur. La correction d’un DOCTYPE incorrect ou mal placé est également une partie de cette spécifi-cation à améliorer dans l’avenir. On peut également penser à la mise en place d’un webservice permettantà partir du DOCTYPE ajouté ou corrigé, de valider l’ensemble de la grammaire HTML comme le suggérela définition de la spécification.


WCAG

”Utiliser des feuilles de style pour contrôler la mise en page et la présentation. Par exemple,utiliser la propriété ’font’ des CSS plutôt que l’élément FONT du HTML pour contrôler les stylesde polices de caractères.” [17]

Présentation

Il existe un certain nombre de balises permettant de faire de la mise en page (mettre un texte en gras,en italique, ...) et qui sont maintenant "dépréciées" dans les spécifications du W3C. Il est recommandéd’utiliser leurs équivalences en style CSS. Par exemple, utiliser la propriété "font-weight :bold" des CSS



plutôt que l’élément "B" du HTML pour contrôler si un texte est en gras. Un certain nombre de baliseset d’attributs HTML peuvent être utiliséees pour mettre en forme du contenu. Ces éléments "dépréciés"peuvent être remplacés par des styles comme le montre le tableau suivant :

Balises(@Attributs) HTML Styles CSSfont(@color,@face,@size) color, font-family, font-sizecenter text-align : centeru text-decoration : underlineb font-weight : boldi font-style : italicblink text-decoration : blinkstrong (sauf niveau sémantique) font-weight : boldem (sauf niveau sémantique) font-style : italictd pas de style fixe, dépend de l’utilisationth pas de style fixe, dépend de l’utilisationimg pas de style fixe, dépend de l’utilisation*(@align) text-align*(@border) border*(@hspace) margin : 0px YYpx*(@vspace) margin : YYpx 0px*(@bgcolor) background-color

Table 3.1 – Remplacement de balises/attributs HTML par des styles CSS

Version 1

Dans une première version de cette spécification, les balises "dépréciées" sont remplacées par une ba-lise "SPAN" comportant un attribut "@style" qui contiendra le style css relatif. Cette méthode permet decorriger le problème, mais ne sépare pas complètement le contenu de la forme. De plus, si l’on retrouve100 balises "I" dans le code, on écrira 100 fois le style "font-style :italic" alors qu’il suffirait de l’écrire uneseule fois et d’utiliser ce style sur l’ensemble des balises "SPAN" ainsi créées. Cette première méthode aété implémentée dans sa totalité mais a rapidement laisser place à une 2ème version qui corrige ce problème.

Version 2

Une deuxième version consiste à créer des classes CSS pour les balises qui reviennent régulièrement.Prenons l’exemple de l’attribut "align=’center’" qui permet de centrer du texte dans une page ou untableau. Il suffit de créer une classe "center" en début de page HTML et d’utiliser cette classe pour tous leséléments comportant cet attribut. Le code à placer en début de page est le suivant :

<style type="text/css">.center{

text-align:center;}</style>

La contrainte de cette méthode est qu’on ne peut utiliser qu’une classe par balise à la fois. Une balisecomportant les attributs "@align" et "@hspace" doivent être traités différemment.


Plugins réalisés

ihmCompare

Le mode automatique de ce plugin effectue les remplacements qu’il considère corrects à partir du tableauA.1. En ce qui concerne le mode manuel, j’ai mis en place une nouvelle IHM de comparaison pour lewebmaster. Le mode classique montre au webmaster le rendu HTML du texte ou de l’image avant lamodification (utilisant des balises/attributs HTML) et après la modification (utilisant des styles CSS). Ilpeut alors à l’aide d’un jRadioButton choisir s’il veut effectuer le changement de l’un à l’autre si celui-là luiconvient. Ce changement est celui qui serait réalisé en mode automatique. La figure 3.23 présente l’IHM decomparaison dans le mode classique.

Figure 3.23 – Aperçu de l’IHM de la spécification 3.3 en mode classique

Cependant les modifications choisies automatiquement ne sont pas fiables à 100% et dans certains casle webmaster peut apercevoir une différence entre la version avec les balises et celle avec les styles CSS. Ilpeut alors choisir de ne pas faire la modification en choisissant la case avec la croix noire (non). Dans lecas de l’utilisation de l’application par un webmaster qui connaît les styles CSS et leur fonctionnement, j’aivoulu lui donner la possibilité d’améliorer cette modification par ses soins. La figure 3.24 montre la présenced’un bouton d’édition du code de remplacement pour le modifier.

En cliquant de nouveau sur ce bouton, le webmaster peut contrôler de nouveau les modifications qu’ila effectuées grâce à la transformation du code en visualisation HTML. De la même façon, le webmasterpeut cliquer sur le bouton de visualisation du code source (avec les balises) mais ne peut pas le modifierdirectement. La figure 3.25 présente la modification de la couleur du texte et la visualisation du code source.


WCAG

”Utiliser les éléments d’en-tête pour convoyer la structure du document, et les utiliser enconformité avec les spécifications. Par exemple, en HTML, utiliser H2 pour indiquer une sous-section de H1. Ne pas utiliser les en-têtes pour réaliser des effets de polices de caractères.”[17]

Présentation



Figure 3.24 – Aperçu de l’IHM de la spécification 3.3 en mode édition de code destination

Figure 3.25 – Aperçu de l’IHM de la spécification 3.3 en mode visualisation de code source

La structure d’un document HTML doit être réalisée à l’aide des balises d’en-tête selon les normes duW3C. Cependant, ces balises peuvent être utilisées de manière incorrecte et ainsi perturber la compréhensionglobale de la page web. Il est commun que les webmasters n’utilisent pas les en-têtes de façon appropriéesoit en mettant en évidence leurs titres importants à l’aide de style (gras, italique, ...), soit en réalisant deserreurs sur leurs imbrications et organisations au sein de la page. Cette spécification permet donc de vérifierces erreurs possibles et de les corriger.

A travers cette description, on peut ressortir 4 éléments à tester :

1. L’imbrication des en-têtes : Il existe 6 en-têtes en HTML (de H1 à H6). Ces en-têtes nécessitent unecertaine organisation et il est déconseillé de les placer d’une certaine façon. Par exemple, une structurequi remonte au lieu de descendre est fortement proscrite.


Plugins réalisés

<H3>CD de U2</H3><H2>CD groupe Irlandais</H2><H1>Rock</H1>

2. Le premier titre : La spécification 3.5 permet de vérifier qu’il n’y a pas d’élément de titre dans la pageayant un niveau plus élevé que le premier titre.

3. Remplacer les styles/balises au profit des en-têtes : Il est parfois tentant de mettre une partie de texteen très gros dans une page web ou en gras pour faire apparaitre l’information. Cependant, s’il s’agitd’un titre (texte court) il est nécessaire de le faire ressortir non pas avec des styles mais avec unebalise d’en-tête. Cela permet par la suite une navigation beaucoup plus simple pour les handicapésutilisant des dispositifs spéciaux.

4. Ne pas utiliser des en-têtes pour mettre en évidence du texte : Il peut être tentant d’utiliser uneen-tête qui définira une taille et une épaisseur désirées sur un texte long telle qu’une phrase ou unparagraphe. Cela pénalisera de manière significative la navigation au sein du site notamment lors del’utilisation d’un synthétiseur vocal. Il est donc recommandé d’utiliser des styles pour mettre en formeces textes longs.

Il s’agit de la dernière spécification que j’ai réalisée cette année. Je me suis attaqué à la partie la plusdure à savoir l’imbrication des balises.

L’imbrication des en-têtes

Si les en-têtes d’un document sont utilisées de façon illogique, les personnes non-voyantes et malvoyantesauront des difficultés à naviguer dans ce document ou à interpréter correctement l’information qui s’y trouve.Il est nécessaire d’utiliser les en-têtes dans un ordre logique tel que l’exemple ci-dessous :

<H1>Les actualités</H1><H2>Région centre</H2><H3>Indre et Loire</H3>

Pour pouvoir tester cette imbrication, j’effectue tout d’abord un premier parcours de la page pour ré-cupérer toutes les balises d’en-têtes et je les stocke dans une structure de données. Je réalise ensuite undeuxième parcours cette fois des en-têtes stockées et je les compare avec l’en-tête qui se trouve au- dessusd’eux. Cela me permet de déterminer si elle est mal imbriquée.

Par exemple, une en-tête de niveau 3 doit être nécessairement précédée d’une en-tête de niveau 2, 3ou 4. Pour permettre au webmaster de corriger manuellement ces imbrications, j’ai réalisé une nouvelleinterface affichant la liste complète des en-têtes de la page avec en vert celles où il n’y a pas d’erreurs et enrouge celles où il y a un problème d’imbrication. Lorsque l’utilisateur sélectionne une en-tête mal imbriquée,il peut alors choisir dans une liste déroulante, l’en-tête qu’il veut utiliser en remplacement et effectuer lechangement en cliquant sur un bouton. Une fois l’ensemble des modifications effectuées, il peut valideren cliquant sur ”ok”. La figure 3.26 présente l’IHM réalisé pour la correction des problèmes d’imbricationd’en-têtes dans la spécification 3.5

Actuellement, cette spécification ne comporte pas de mode automatique. Je n’ai pas trouvé quel choixréalisé pour la plateforme dans le but d’améliorer la structure de la page.

Évolutions futures

Pour terminer cette spécification, il est nécessaire de corriger les autres problèmes soulevés dans laprésentation. Il s’agit de problème plus simple à mettre en place. Il faudrait parcourir l’ensemble des balisesd’en-tête et proposer pour celles contenant un texte de plus de 10 mots par exemple de la remplacer parl’utilisation de styles. On pourrait parcourir de la même manière les éléments possédant un style gras ou



Figure 3.26 – Aperçu de l’IHM de la spécification 3.5 en mode manuel

italique de moins de 10 mots et demander au webmaster s’il ne s’agirait pas plutôt d’une en-tête. Il s’agitici d’améliorations futures qui seraient bien d’apporter à ce plugin.

3.4 Collaboration des PFE

Au sein de l’équipe HaNT , 3 étudiants de 5ème année réalise leur PFE sur le thème de l’accessibilitédu web. Les 2 autres projets sont les suivants :

1. PFE de Claire Crosnier : Parcours dynamiques, efficaces et thématiques de sites web et portails

2. PFE de Jérôme Guyon : Outils d’accessibilité passive : Modification automatique et semi-automatiquede pages web non accessibles

Nous avons réalisé une réunion entre nous le 19 mars 2009 pour présenter d’un point de vue plustechnique notre projet et identifier les parties que l’on pourrait mettre en commun. Les 2 parties suivantesprésentent ce qui est ressorti de cette réunion.

3.4.1 Le PFE de Jérôme

Contrairement au mien, le PFE de Jérôme traite les pages internet qui sont déjà présentes sur un serveurweb. Le traitement est fait de manière automatique et entraine dans certains cas des erreurs. L’utilisation demots clefs par exemple pour identifier l’action d’une image (l’attribut ALT) peut s’avérer incorrecte. C’estpourquoi dans son projet, l’intervention d’un expert permet la correction de ces associations de mots clefs etd’actions et la mise en place d’une base de données de plus en plus efficace au fur à mesure des interventions.La partie que nous avons décidée d’intégrer dans mon PFE est justement cette base de données de qualitéaprès l’intervention successive d’un expert, permettant d’affiner au mieux mon mode automatique. Les choixeffectués dans le mode automatique sont également les choix proposés à l’utilisateur à l’ouverture d’unepopup pour définir le texte alternatif d’une image. L’idée est donc de mettre une base de données communeen ligne sur un serveur distant et d’utiliser un webservice pour faire des requêtes de recherche de relationentre des mots clés et des actions éventuelles. La figure 3.27 présente le lien entre le projet de Jérôme et lemien. Elle a été réalisé par Jérôme lui-même.

3.4.2 Le PFE de Claire

Le PFE de Claire traite également des pages internet déjà présentes sur un serveur web et permetd’effectuer un certain nombre d’actions sur ces pages. Par exemple, le découpage de pages trop longues,


Collaboration des PFE

Figure 3.27 – Schéma de collaboration avec le PFE de Jérôme

la suppression de menus en double, le parcours thématique d’un site internet, etc. Ce PFE a pour objectifde s’intégrer à celui de Jérome qui utilise un proxy pour le traitement des pages en ligne. Etant donnéque ces traitements ne sont pas directement liés au WCAG, nous n’avons pas trouvé pertinent de faire unecollaboration entre nos 2 projets.

3.4.3 L’installation du webservice

Pour intégrer le webservice de Jérome dans mon PFE, il m’a transmis les fichiers suivants :

1. Un serveur apache tomcat permettant de lancer le webservice en local sur ma machine

2. Une base de données comprenant des associations mots clés ⇔ actions

3. Les fichiers de la librairie ”Axis” qui permer d’utiliser un webservice en java

4. Sa librairie qui est un client au service web

A partir de là, j’ai installé le serveur apache tomcat en local sur mon ordinateur, j’ai placé la base dedonnées dans mon répertoire home de mon système d’exploitation et j’ai intégré les librairies axie et lalibrairie de Jérome au projet java. Il ne reste plus qu’à intégrer l’accès au webservice au code de mon plugin.Pour tester l’intégration, j’ai choisi d’ajouter le code au traitement des balises IMG de la spécification 1.1

3.4.4 Intégration à la spécification 1.1

Lors de la détection d’une balise IMG par la spécification 1.1, on interroge en mode manuel le webmastersur le texte alternatif qu’il désire mettre en place. Si l’attribut ”alt” est rempli, on lui propose cette valeuren premier choix, sinon on lui propose le nom de l’image sans l’extension et en dernier lieu en lui proposede dire que c’est une image. Le mode automatique ajoute l’attribut s’il n’existe pas et choisit la valeur àmettre dedans dans le même ordre que la liste des choix du mode manuel. Grâce au webservice de Jérôme,



je souhaite proposer un autre choix entre la valeur de l’attribut ”alt” et le nom de l’image. Le code suivanta été ajouté au fichier Image du plugin de la spécification 1.1 :

try {//Connection au webservice de Jérôme avec login et mot de passeActionIcsdManagerPortType service = ActionIcsdWebService.getServiceWithAuth(new java.net

.URL("http://localhost:8080/ws/IcsdActionService"), "PFE_John", "pfe");

//Création de la liste des mots clésArrayList<String> motclefs = new ArrayList<String>();if( this.srcValue != null )

motclefs.add(this.srcValue);if( this.nameValue != null )

motclefs.add(this.nameValue);if( this.idValue != null)

motclefs.add(this.idValue);if( this.classValue != null)

motclefs.add(this.classValue);

//Interrogation de la BDD sur les mots clésActionIcsd action = service.getMatchingAction((String []) motclefs.toArray (new String [

motclefs.size ()]));

//Si une action est trouvée, ajout de celle-ci à la liste des choix de titresif (action != null)

listeChoixTitre.add(action.getDescription());} catch (Exception e) {

System.out.println("Serveur TOMCAT non lancé, service web non accessible");}

La première étape est de créer une instance de la classe du web service en se connectant au serveurlocalhost et en s’identifiant. Le login est ”PFE_John” et le mot de passe ”pfe”. Je construis ensuite une listede mot clés à partir des informations contenues dans la balise image. Je récupère les valeurs des attributssuivants :• src : Chemin du fichier (retourne uniquement le nom sans extension)• name : Nom donné à la balise• id : Identifiant donné à la balise• class : Classe CSS associer à la balise

Ensuite, ces mots clés sont transformés en tableau de chaînes de caractères et sont fournis en paramètrede la fonction getMatchingAction qui interroge la base de données en ligne. Si l’action retournée est non”null”, elle comprend le titre retourné par la requête de la base de données, sinon aucune association n’a ététrouvée à partir des mots clés fournis. La description de l’action correspondant au texte alternatif est alorsajoutée à la liste des choix possibles fournis à l’utilisateur. Dans le cas où le service web n’est pas accessible,la requête n’est simplement pas effectuée.

3.4.5 Résultat de l’intégration

Une fois l’intégration terminée, j’ai testé le webservice avec plusieurs scénarios de balises et d’attributs.Prenons l’exemple du code ci-dessous :

<img id="img34" src="next.jpg">

Lors de la construction de la liste de choix possibles pour le texte alternatif, le mot clé ”next” est envoyépar le webservice sous forme de requête à la base de données. La base de données fait l’association de ce


Manuels et documentations

mot clé avec l’action de nom ”suivant” et de description ”page suivante”. Le texte ”page suivante est alorsajouté à la liste des choix du webmaster dans l’interface. La figure 3.28 présente le résultat de l’appel duweb service pour cette image nommée next.jpg.

Figure 3.28 – Présentation de l’ihm de la spécification 1.1 pour une image nommée next.jpg

On considère que les associations mots clés⇔ actions ont été validées par un expert et sont donc fiablesà 99%. Le résultat obtenu est le suivant si le webmaster ne change pas le texte proposé ou dans le cas del’exécution du mode automatique.

<img id="img34" alt="page suivante" src="next.jpg" longdesc="">

L’intégration s’est donc très bien déroulée. On peut imaginer dans le futur utiliser le webservice avecd’autres plugins ou encore améliorer l’utilisation de celui-ci.

3.5 Manuels et documentations

Lors du PFE précédent, Antoine a réalisé une rubrique d’aide destinée à l’utilisateur de la plateforme detraitement, une rubrique ”à propos” du logiciel et un manuel développeur pour créer un plugin indépendam-ment du moteur. Je devais lors de mon projet, mettre à jour l’ensemble de ces documents. J’ai attendu lafin de mon PFE pour le faire étant donné que la plateforme et les classes évoluaient au fur et à mesure.La rubrique d’aide et la rubrique à propos sont accessibles à partir du menu Aide de la plateforme (figure3.29). L’intégralité de la rubrique d’aide est disponible en annexe B.

Le manuel du développeur pour créer un nouveau plugin est réalisé sous la forme d’un tutorial. Il expliquecomment créer un projet à l’aide de l’IDE NetBeans ainsi que les différentes classes et méthodes à utiliserpour implémenter ce plugin. J’ai repris certaines parties du manuel d’Antoine et j’ai complété avec lesnouvelles classes que j’ai mises en place et refait les captures d’écrans et explication pour la dernière versionde NetBeans. L’intégralité du manuel est disponible en annexe C.



(a) (b)

Figure 3.29 – Fenêtres accessibles par le menu Aide (a) rubrique d’aide (b) rubrique à propos

3.6 Conclusion

Lors de ce projet de fin d’études, cinq étapes ont été réalisées. La première consistait à corriger les bugsdétectés dans l’application existante. Cette étape m’a également permis de prendre en main le code sourceet la plateforme de traitement créés par Antoine Blais. Suite à cette utilisation, j’ai réfléchi à plusieurs amé-liorations pour le logiciel que j’ai soumises à mon encadrante. Après validation, je les ai intégrées au cahierdes charges et les ai réalisées pendant la durée de ce PFE. Les objectifs principaux étaient la réalisationdes plugins des spécifications des WCAG que j’ai réalisée dans une troisième étape. Suite à la soutenance àmi-parcours, nous avons également réalisé une réunion entre étudiant travaillant sur l’accessibilité du web ettenté de mettre en commun des parties de nos PFE. La quatrième étape est justement axée sur la collabo-ration que j’ai réalisée avec Jérôme Guyon. Pour terminer, il était important de mettre à jour les documentsréalisés au cours du PFE précédent tels que l’aide utilisateur et un tutorial de développement d’un plugin.

La réalisation des plugins s’est très bien déroulée grâce en grande partie au code de qualité qui avaitété réalisé il y a 2 ans. Cependant, le déroulement du projet montre que j’avais sous estimé le temps deréalisation des plugins du fait que certaines spécifications renferment énormement de parties à contrôler.C’est pourquoi j’ai terminé entièrement la directive 1, pratiquement terminé les spécifications de la directive3 que j’ai considérées réalisables et je n’ai pas eu le temps de travailler avec la directive 11. Etant donnéque j’ai dans le même temps, corrigé les bugs précédents, améliorer la plateforme de traitement et mis àjour les documentations, je pense avoir réalisé les 2/3 de ce projet.

Pour la suite, il sera nécessaire de continuer la spécification 3.5 en développant des tests supplémentairessur les en-têtes. On peut imaginer également le développement d’un webservice associé à la directive 3.2pour valider la grammaire des documents HTML et CSS. La mise en place de la collaboration entre monprojet et celui de Jérôme en est à ces débuts et il serait très intéressant d’aller plus loin dans cette op-tique. En effet, l’intervention des experts sur la base du second projet permet d’avoir des données très fiables.

Cependant, un petit problème persiste concernant le plugin d’intrégation des images et celui des médias.Lors de l’utilisation de celui-ci, l’ensemble des liens de la page sont modifiés et cela pour un aperçu del’image dans l’application mais également sur la page créée en sortie. Il est alors gênant pour un webmasterqui a prévu de publier cette page sur son serveur FTP après l’avoir traité par notre plateforme de devoirremodifier tous les liens. Cela était déjà le cas dans le projet existant du fait que le traitement des pagesse fait de façon séquentielle et que les plugins sont indépendants les uns des autres. Cette souplesse deconception pose une petite limite dans ce cas bien précis. Il sera nécessaire de mettre en place un moyenpour que dans le cas d’une page en sortie, les liens soient réécrits de la même manière que la page en entrée.


CHAPITRE 4

Tests et analyse des résultats

Pour pouvoir tester l’efficacité des plugins réalisés lors de ce PFE, il est très important de mettre enplace une base de tests. Un ensemble de sites web testés par un validateur avant et après utilisation dechaque plugin pour analyser leur efficacité et également les bugs qu’ils peuvent avoir. Ces tests permettrontégalement de faire des statistiques sur les spécifications qui reviennent régulièrement et sur l’efficacité desplugins développés. A la suite de ces tests, les bugs trouvés ont été corrigés et un livrable d’un ensemble deplugins efficaces a été effectué pour chaque directive.

4.1 Les validateurs

Pour pouvoir faire des tests efficaces avant et après l’utilisation des plugins réalisés au cours de ce PFE,il nous faut évaluer convenablement les critères d’accessibilité du WCAG sur chacune de ces pages. Il m’afallu donc tester un certain nombre de validateurs étant donné que contrairement aux normes HTML etCSS, aucun validateur officiel pour les directives du WCAG n’existe. La figure 4.1 représente la liste desvalidateurs que j’ai testés.

Figure 4.1 – Les outils de validations testés

A la suite de ces tests, j’ai retenu 3 validateurs qui sortent du lot.

1. Ocawa [47] : Il s’agit d’un très bon validateur permettant de tester l’ensemble des spécifications desWCAG en donnant des résultats très précis sur l’audit de la page. Cependant il est payant ou se limiteen version démo au priorité de niveau 1. En version démo, aucune statistique globale sur la page estaffichée.

2. Cynthia Says [30] : Ce validateur posséde des options très intéressantes comme le choix du navigateurà émuler et des corrections pertinantes sur chaque erreur détectée. Cependant il ne permet pas detester une page à partir d’un fichier local et ne fournit pas de statistiques sur la page validée.

3. EvalAccess [40] : Ce service détaille de façon claire les erreurs et warning rencontrés sur une page etpermet entre autre de charger une page à partir d’un fichier local. Il effectue également des statistiquesglobales sur la page mais pas par spécification.

Pour conclure sur cette étude, l’outil qui me semble le mieux adapté pour ce PFE est EvalAccess 2.0 [40].Il permet de tester l’ensemble des directives et des spécifications qui l’en découle. Il autorise la validationdu code en local, et propose des statistiques sur le code analysé ainsi que les propositions de correctionsligne par ligne. Le seul bémol est que les statistiques sont regroupées par priorité d’erreurs et de warninget non par spécification. Il est donc nécessaire de compter le nombre d’erreurs apparentes dans le tableau


Chapitre 4. Tests et analyse des résultats

pour obtenir des statistiques par spécification. Cet outil est cependant celui qui me convient le mieux parrapport aux autres outils gratuits disponibles sur internet.

4.2 Les statistiques

Pour palier au problème des statistiques par spécification, j’ai réalisé un parseur de la page HTML résul-tat du validateur. La figure 4.2 présente le schéma d’utilisation conjointe du validateur et du parseur pourobtenir des statistiques par spécification sur une page web.

Figure 4.2 – Schéma d’utilisation conjointe du validateur et du parseur pour obtenir des statistiques

Ce parseur a été réalisé en java et utilise la librairie ”jxl.jar” qui permet de manipuler des fichiers excels.L’interface réalisée est très simple et comprend uniquement le chemin de la page HTML résultat (codesource) du validateur et un bouton permettant de lancer le parsing. La figure 4.3 présente l’interface duparseur.

Figure 4.3 – Interface du parseur de la page HTML résultat

Le programme lit le code source HTML qui suit une structure identique à chaque utilisation du valida-teur et stocke les différentes informations dans des structures de données. Il crée ensuite un fichier excel”resultat.xls” comportant toutes les données par spécification. La figure 4.4 présente un extrait du fichierexcel généré à partir des résultats de validation du site internet de Polytech’Tours (évaluation réalisée le 22janvier 2009).

4.3 Les bases de tests

J’ai réalisé 2 catégories de sites tests pour ce projet. Une première catégorie de sites généraux qui seronttestés sur chaque directive implémentée, permettant de voir l’efficacité du moteur sur un site de façonglobale. Une seconde catégorie regroupant des pages web spécifiques permettant de tester une partie précised’une spécification que l’on ne retrouve que rarement sur le net. La première catégorie a été mise en placedurant le mois de janvier lors des premiers tests sur la directive 1. La seconde catégorie elle a été agrémentéeau fur et à mesure de l’étude des différentes directives.


Les bases de tests

Figure 4.4 – Extrait d’un fichier excel généré à partir du parseur de résultats de validation du siteinternet de Polytech’Tours (évaluation réalisée le 22 janvier 2009)

4.3.1 Les sites généraux

Il y a 2 ans, il avait été choisi de travailler avec les sites internet des 50 plus grandes communes d’Indreet Loire. Sur ces 50 communes, aujourd’hui seulement 37 ont un site internet (35 en 2007 lors du PFEde Antoine). J’ai remis à jour cette base de site en sauvegardant les pages d’accueil au format HTML. Eneffet, pour pouvoir comparer des statistiques de validations des WCAG sur une page web, il est nécessaireque cette page ne soit pas modifiée. L’annexe D comporte la liste complète de ces sites et de leurs adressesinternet. Un dossier contenant l’ensemble des pages d’accueil de ces sites sera fourni à mon encadrante enmême temps que le programme réalisé.

L’étude des 35 sites d’Indre et Loire en 2007 dans le cadre du PFE d’Antoine Blais et de la thèse deSonia Colas avait permis de faire les statistiques qui m’ont fait choisir les directives à étudier. La figure 4.5représente sous forme de camemberts les résultats de l’étude menée sur les 35 sites d’Indre et Loire.

(a) (b)

Figure 4.5 – Répartition des erreurs (a) et des warnings (b) des sites web publics d’Indre-et-Loireentre les directives WCAG



Le tableau 4.1 permet de rappeler les énoncés des directives des WCAG.

Directives Description1 Fournir des alternatives équivalentes au contenu visuel et auditif2 Ne pas s’en remettre uniquement aux couleurs3 Utiliser le balisage et les feuilles de style, et cela de façon appropriée4 Clarifier l’utilisation du langage naturel5 Créer des tableaux qui se transforment de façon élégante6 S’assurer que les nouvelles technologies se transforment de façon élégante7 Assurer à l’utilisateur la variation temporelle du contrôle des changements du contenu8 Assurer un accès direct aux interfaces utilisateur intégrées9 Conception respectant l’indépendance par rapport au périphérique10 Utilisation de solutions intermédiaires11 Utilisation des technologies et directives du W3C12 Fourniture d’informations de contexte et d’orientation13 Fourniture de mécanismes de navigation clairs.14 S’assurer que les documents sont clairs et simples

Table 4.1 – Description des directives des WCAG

La répartition des erreurs montre l’importance de corriger les directives 1, 3 et 11 et celles des warningsde s’intéresser à la directive 5. Je vais maintenant rappeler les objectifs de chacun de ces directives.

• La directive 1 impose la présence de textes alternatifs pour tout ce qui ne peut être perçu par unhandicapé visuel (mais également par un lecteur d’écran). Il s’agit entre autre des images cliquables,des vidéos, des applets java, des sons, etc.• La directive 3 porte l’accent sur l’utilisation des balises de manière correcte par rapport aux normes

en vigueur ainsi que celle des feuilles de style. Il ne faut pas utiliser des balises pour mettre en formedu texte et à l’inverse ne pas utiliser des styles pour des en-têtes ou des listes.• La directive 11 s’intéresse à l’utilisation des dernières technologies du W3C. Ne pas utiliser les éléments

dépréciés mais les dernières versions supportées et fournir les options de négociation du contenu lorsquecela est possible.• La directive 5 s’occupe des tableaux en impostant un certain nombre de balises bien utilisées pour

différencier les tableaux de données des tableaux de mises en page.

Cette année, j’ai donc réalisé les directives importantes pour les sites d’Indre et Loire. Cependant, cessites sont réalisés pour des petites communes et sont souvent vieux et pas très fournis. Les méthodes utiliséespour les réaliser sont assez anciennes et les statistiques obtenues ne sont pas vraiment représentatives destechnologies du web 2.0 que l’on trouve actuellement sur le web. J’ai également voulu voir l’impact sur dessites généraux qui n’utilisent pas les mêmes technologies et pour cela réaliser des tests sur des sites plusconnus et utilisés. L’objectif est toujours de montrer l’importance de l’accessibilité sur internet ne serait-ceque pour obtenir un horaire de cinéma, ou le trajet d’une ville à une autre. Les sites choisis sont à la pointede la technologie et permettent de faire ressortir un autre type d’erreur comme :

• L’utilisation de scripts• L’utilisation d’animation flash• L’utilisation d’images cliquables• Etc


Les bases de tests

La liste comporte des sites tels que :

• http://www.allocine.fr• http://www.mappy.fr/• http://www.telecharger.com• http://www.lemonde.fr/• Etc

Cette liste est disponible de façon complète en annexe D. La figure 4.6 présente les résultats de l’analysede ces sites avec à gauche la répartition des erreurs entre les 14 directives et à droite la répartition deswarnings entre ces mêmes directives.

(a) (b)

Figure 4.6 – Répartition des erreurs (a) et des warnings (b) des sites web récents

On note tout de suite que la répartition des erreurs est différente de la précédente analyse. On retrouveles directives 1, 3 et 5 qui font partie des erreurs récurrentes sur ces sites internet mais on voit aussi laprésence significative des directive 6 et 10 pour les erreurs et la directive 13 pour les warnings. Les objectifsde ces directives sont rappelés ci-dessous.

• La directive 6 s’occupe du support des scripts et de leur compatibilité avec les différents dispositifsutilisateurs. Il est également nécessaire au travers de cette directive que les pages soient lisibles sansscripts, applets, feuilles de style, etc.• La directive 10 vérifie que le site ne produit pas de popup à répétition, respecte bien l’utilisation des

formulaires et des liens hypertextes.• La directive 13 prévoit des mécanismes de navigation clairs et cohérents telles qu’une information

d’orientation, des barres de navigation, une carte du site de manière à ce qu’un utilisateur puissetrouver ce qu’il cherche sur le site.

Ce changement de résultats provient de l’évolution des sites internet actuels vers le web 2.0 comportantbeaucoup plus d’éléments dynamiques. La directive 6 apparaît dans les erreurs du fait d’une utilisation im-portante du javascript dans ces sites. Il n’est pas possible de savoir de façon sûre pour le validateur qu’unealternative a été mis en place par le webmaster et c’est pourquoi il suggère une erreur sur les pages web. Ladirective 10 est ici représentée du fait de l’utilisation répétée de l’attribut target qui est depuis peu déprécié.


http://www.allocine.fr

http://www.mappy.fr/

http://www.telecharger.com

http://www.lemonde.fr/


Cet attribut est utilisé dans les liens hypertextes présents de façon considérable sur les sites internet. Ilest maintenant recommandé d’utiliser l’attribut ”onclick” du javascript ainsi qu’un jeu de paramètres pourréaliser des actions similaires à cet attribut target. La répartition des warnings sur ces 2 bases de tests estun peu près équivalente même si la directive 13 sort du lot.

Suite aux résultats obtenus à partir de cette base de tests, je n’ai pas modifié mes objectifs premiersmalgré les différences liées à la première étude. Cependant, ces nouveaux résultats jouent un rôle importantdans le choix futur des plugins à développer pour la plateforme de traitement. Ils seront donc très utileslorsque le projet sera repris et ces 2 bases de sites permettront une pré-étude très approfondie.

4.3.2 Les sites par spécification

Certaines parties des spécifications concernent des situations qui sont soit très techniques, soit quin’apparaissent pas souvent sur internet. J’ai testé ces parties en utilisant des sites précis ou des pagesHTML que j’ai écrits moi-même dans certains cas. Ci-dessous, des exemples de sites qui m’ont permis detester des parties de spécification :

1. Image cliquable (balise area) : http://pagesperso-orange.fr/le.campagnol/accueil.html

2. Applet (Waterpic) : http://www.durius.com/

3. Button : http://www.startyourdev.com/HTML/Balise-BUTTON.html

A partir des manuels du W3C et des possibilités des balises, j’ai par exemple réalisé le fichier suivantpour tester de façon intégrale la spécification 3.3 :

<font color="red" size="6" face="Verdana">Remplacement de la balise FONT</font><br/><FONT>FONT sans rien</FONT><br/><FONT color="green">Font en vert</font><br/><FONT color="green">Font en vert encore</font><br/><Font color="red" size="1">Font tout petit en rouge</Font><br/><font color="red" size="6" face="Verdana">Font en gros, rouge et police verdana</font><br/><font size="7">Font le plus gros possible</font><br/><center id="toto"> <u>Souligné</u> <b>Gras</b> </center><br/><i>Italic</i><br/><BLINK>Ca clignote!!!</BLINK><br/><em>Hého</em><br/><strong>Coucou</strong><br/>

La version 2 de la spécification 3.3 utilisant des classes de styles plutôt que l’ajout de styles dans lesbalises HTML donne le résultat suivant :

<style type="text/css">.center{text-align:center}.blink{text-decoration:blink}.font1{color:red; font-family:Verdana; font-size:x-large; }.font2{color:green; }.i{font-style:italic}.b{font-weight:bold}.font4{font-size:xx-large; }.u{text-decoration:underline}.font3{color:red; font-size:xx-small; }</style><span class="font1">Remplacement de la balise FONT</span><br/><span>FONT sans rien</span><br/><span class="font2">Font en vert</span><br/><span class="font2">Font en vert encore</span><br/><span class="font3">Font tout petit en rouge</span><br/>


http://pagesperso-orange.fr/le.campagnol/accueil.html

http://www.durius.com/

http://www.startyourdev.com/HTML/Balise-BUTTON.html

Les bases de tests

<span class="font1">Font en gros, rouge et police verdana</span><br/><span class="font4">Font le plus gros possible</span><br/><div class="center"> <span class="u">Souligné</span> <span class="b">Gras</span> </div><br/><span class="i">Italic</span><br/><span class="blink">Ca clignote!!!</span><br/><span class="i">Hého</span><br/><span class="b">Coucou</span><br/>

Il faut cependant faire attention à l’utilisation de petits fichiers hors contextes pour corriger les problèmesrencontrés. En effet, ces balises qui posent problèmes seront intégrées dans un ensemble de balises quicomposent une page globale. Le comportement du moteur et du plugin peut parfois être différent, c’estpourquoi il est toujours nécessaire de tester les résultats définitifs sur un site réel, voire plusieurs sites.

4.3.3 Test de la directive 1

Une fois la directive 1 terminée, j’ai réalisé un livrable sous la forme d’une version du moteur avec lesplugins réalisés jusque là. Pour valider la directive 1 que je venais de teminer, j’ai testé les 30 sites récentsde la base de tests à l’aide du validateur EvalAccess, avant et après utilisation de la spécification 1.1. Pourrappel, seule la spécification 1.1 a été implémentée dans la directive 1. Ces tests ont été réalisés en modeautomatique du fait que le validateur ne peut pas déterminer la pertinence des résultats mais uniquementla présence et la syntaxe des éléments mis en place. La figure 4.7 et la figure 4.8 présentent respectivementle nombre d’erreurs et de warnings avant et après correction sur les 30 sites récents de la base globale.

Figure 4.7 – Nombre d’erreurs et de warnings avant correction sur les 30 sites récents

Ces statistiques montrent bien l’efficacité totale du plugin de la spécification 1.1 sur les erreurs de ladirective 1. Il est également efficace sur les warnings mais ne permet pas de les corriger dans la totalité. Celavient du fait que lorsque le validateur détecte une balise de scripts, il lève systématiquement un warning surla page pour signaler au webmaster que le contenu généré à partir de ce script risque d’être inaccessible.



Figure 4.8 – Nombre d’erreurs et de warnings après correction sur les 30 sites récents

Malgré l’ajout de balise NOSCRIPT, le warning est quand même présent à titre d’information. Je considèredonc que les résultats sont très concluants et que l’on ne pourra pas faire mieux concernant les warnings.

4.3.4 Test de la directive 3

La directive 3 ne permet pas d’être testée par le validateur de la même manière que la directive 1. Eneffet, les éléments telles que les balises de titre (H1, H2, H3, ...) ou les puces de listes (UL, LI, ...) sontsystématiquement detectés par le validateur comme posant un problème. Le parseur automatique utilisé parEvalAccess ne permet pas d’identifier si par exemple la balise d’entête détectée est bien utilisée pour untitre ou pour de la mise en forme. Dans le doute, il signale un warning et c’est au webmaster de savoir cequ’il fait. Les plugins que j’ai réalisés pour la directive 3 permettent donc au webmaster qui ne connait pasl’utilisation correcte de ces balises de corriger sa page en fonction, mais les warnings seront toujours présentslors de la validation des WCAG. Il est donc de la responsabilité du webmaster de vérifier de la validité del’utilisation de ses balises.

4.4 Conclusion

Les bases de tests comprenant un plus grand nombre de sites internet permettent d’identifer les problèmesrécurrents sur les pages web. Que ce soit sur la base des sites des communes d’Indre et Loire ou sur la basedes sites récents, cela m’a aidé à mettre en évidence des priorités au niveau du développement des pluginsde spécification. Une fois les plugins réalisés, ces bases ont un deuxième objectif : valider les résultatsobtenus après utilisation des plugins. Lorsque le livrable de la directive 1 a été remis (au moment dela soutenance à mi-parcours), j’ai réalisé une batterie de tests avant et après utilisation du plugin de laspécification 1.1 permettant d’approuver l’efficacité de celui-ci par des résultats très concluants. La directive3 n’a malheureusement pas pu être testée de la même manière du fait d’un manque de pertinence desrésultats du côté du validateur. La directive 11 qui n’a pas été réalisée faute de temps aurait été très


Conclusion

facilement contrôlée par ces tests du fait de l’utilisation ou non des dernières technologies du W3C (pas debalises dépréciés, présence des options de négociations, etc). Cela pourra être réalisé lors de la reprise duprojet.


Conclusion

Des innovations technologiques permettent désormais à des personnes handicapées visuelles d’accéderà l’outil informatique et à internet. Cependant il est nécessaire pour cela que les webmasteurs aient réaliséun travail en amont permettant de rendre leur site compatible avec les dispositifs mis au point dans cebut. Les normes actuellement en place au niveau international sont peu connues et très peu respectéespar les nombreux participants de la mise en commun de l’information sur la toile. De plus certaines de cesspécifications sont très techniques et nécessiteraient d’être simplifiées ou clarifiées pour des webmasters nonspécialistes cherchant à rendre leur contenu accessible.

Ce projet de fin d’études contribue à l’avancement du domaine de l’accessibilité du web en fournissantun outil à destination des webmasters pour corriger leurs pages web en vue de les rendre le plus accessiblepossible. Cette application décrit de façon simple et claire les différentes étapes que doit réaliser le webmas-ter dans le but de corriger les pages web de son site internet. Une fois corrigées, ces pages sont à mettre àla disposition de tous pour une transmission de l’information optimale.

Présentations

Au cours du projet, j’ai réalisé une présentation de celui-ci durant les portes ouvertes du départementinformatique de Polytech’Tours le 14 mars 2009. Cela m’a permis de le présenter à des personnes ne connais-sant pas le domaine de l’informatique et encore moins de l’accessibilité du web et ainsi voir leur retour surle sujet. La plupart trouvait l’initiative très intéressante et portait un intérêt réel pour le projet.

J’ai également effectué une démonstration lors de la venue de l’entreprise InfoetMat de Vierzon pourrencontrer l’équipe HaNT et discuter des partenariats possibles entre les deux parties. Ces personnes avaientelles une connaissance très précise de l’outil informatique et de l’accessibilité du web. Ils se sont égalementfortement intéressés à l’ensemble des travaux réalisés au sein de l’équipe sur l’accessibilité du web et enparticulier sur le correcteur de pages web à destination des webmasters.

Organisation du projet

D’un point de vue de l’organisation de ce PFE, je pense avoir respecté le planning que je m’étais fixé àl’exception de la directive 11 que je n’ai pas pu étudiée étant donné que j’avais sous estimé le développementdes spécifications de la directive 3. Cependant, un livrable de la directive 1 avec un ensemble de tests trèsconcluants avaient été livrés à mi parcours et en cette fin de PFE, je rends un livrable de la directive 3 avecles spécifications que j’ai pu réaliser dans le domaine de faisabilité que j’avais. Je suis également conscientd’avoir perdu un certain temps sur le développement de la spécification 1.1 à vouloir faire trop parfaitementalors que ce n’était pas toujours réalisable dans le temps imparti. Ayant commencé à rédiger mon rapportde PFE durant le mois de décembre et les manuels durant le mois d’avril, je me suis senti à l’aise dans larédaction de ceux-ci me permettant de prendre mon temps et d’améliorer des parties au fur et à mesure.

Évolutions futurs

Les évolutions futures se situent essentiellement dans le développement de nouveaux plugins des nom-breuses spécifications des WCAG qui n’ont pas été étudiées et également d’apports éventuels sur les spéci-fications existantes. Plus de plugins de spécification seront réalisés et plus la plateforme de traitement sera


Annexe

efficace sur les pages web. On pourrait également imaginer de faire évoluer la plateforme de traitement dansle but de corriger non plus une page web à la fois mais un site dans son intégralité (ensemble de pages). Ilpourrait être intéressant d’ajouter dans ce moteur la possibilité d’obtenir un rapport d’erreurs syntaxiquespour les balises HTML à partir d’un validateur sous la forme d’un service web en ligne. Dans cette mêmeoptique, la relation entre mon projet et le webservice développé par un autre PFE donnant accès à une basede données d’action associée à des mots clefs nécessiterait d’être renforcée et améliorée.


ANNEXE A

Cahier des charges

A.1 Validation et Historique du cahier des charges

A.1.1 Validation

Référence : Cahier de charges du PFE n°41Projet : Conception de plugins de correction de pages web afin qu’elles respectent les normes d’accessibilitéEmetteur : Jonathan Courtois - salle HaNT - ordinateur n°4Date d’émission : Le 10/12/2008

Nom Date Validation(0/N) CommentairesSonia Colas 10/12/2008 O Version 1Sonia Colas 09/01/2009 O Version 2

Table A.1 – Validation

A.1.2 Historique des modifications

Version Date Description des modifications2 08/01/2009 Détails des besoins fonctionnels.

Différenciation entre besoins non-fonctionnels et contraintes. Amélio-ration du planning

Table A.2 – Historique des modifications


Annexe Préambule

A.2 Préambule

A.2.1 Présentation du Client

Ce Projet de Fin d’Etudes (PFE) se déroule au sein de l’équipe Handicap & Nouvelles Technologies(HaNT) du Laboratoire Informatique (LI) de l’université de Tours. Cette équipe s’oriente principalement surl’aide aux personnes handicapées pour l’utilisation d’outils informatiques (internet, jeux vidéo, ...) ainsi quesur les nouvelles technologies (technologie du web, sécurité dans les réseaux, ...). Les outils utilisés sontl’intelligence artificielle comprenant les algorithmes génétiques et les fourmis artificielles et également la mo-délisation mathématique comme les chaînes de Markov cachées. Ces techniques sont par la suite appliquésà des problèmes que l’on trouve dans l’informatique : apprentissage, classification, optimisation, ...

Mon encadrante principale est Sonia Colas, doctorante en informatique à l’Université François Rabelaisde Tours. Je suis également suivi par Nicolas Monmarché, maître de conférences en Informatique, et Moha-med Slimane, professeur en Informatique, tous les deux de l’Université de Tours.

Ce PFE se déroule dans le cadre de la thèse de mon encadrante intitulé Outils d’amélioration de l’ac-cessibilité du web pour les personnes visuellement handicapées [20].

A.2.2 Conventions et terminologie utilisées dans le document

– HaNT : Terme désignant l’équipe Handicap & Nouvelles Technologies du laboratoire informatique del’université de Tours.

– W3C : Le World Wide Web Consortium est l’organisme de normalisation des technologies du webtelles que le HTML, XHTML, CSS, SVG, etc.

– WAI : Le Web Accessibility Initiative a été lancée par le W3C pour objectif de rendre les technologie duweb accessible aux personnes handicapés et d’une manière générale à toute personne sans nécessiterde prérequis particulier.

– WCAG : Le Web Content Accessibility Guidelines est un guide du WAI expliquant aux webmasterscomment rendre leurs pages accessibles.

– Directive : Une directive est un thème du WCAG regroupant un ensemble de spécification.– Spécification : Une spécification est un point précis des WCAG sur lequel le webmaster doit porter

attention pour rendre son site accessible. Les spécifications sont classées en 3 priorités permettant dedéfinir l’importance de celles-ci.

– HTML : L’Hypertext Markup Language est un langage de balise permettant l’affichage d’informationsur une page internet.

– IHM : L’interface homme machine est la partie graphique d’une application permettant à l’utilisateurd’interagir avec le système.


82

A.3 Présentation du projet

A.3.1 Contexte

L’accessibilité désigne la possibilité pour une personne d’accéder à un lieu (liberté de déplacement)ou à une information (compréhension). Certains aspects de l’accessibilité sont spécifique aux handicapés,essentiellement dans le domaine de l’informatique, mais également dans le domaine des transports, de lacommunication, etc.

Un certains nombres d’outils ont été developpé dans le secteur de l’informatique pour permettre auxhandicapés d’utiliser plus facilement un ordinateur. Parmis les plus connus, on trouve le lecteur d’écran quiretransmet de façon auditive un texte ou une page internet, ainsi que la tablette braille permettant de lireun texte à l’aide du langage braille.

Cependant, les handicapés ne sont pas tous égaux face à l’accessibilité informatique. En effet, certainsmal voyants ne connaissent pas le braille et certains mal-entendants ne connaissent pas le langage des signes.

En ce qui concerne l’internet, certaines lois ont vu le jour il y a quelques années maintenant, concernantl’accessibilité numérique, pour assurer la compatibilité des sites avec les aides techniques. Elles précisentque les sites web doivent respecter les Web Content Accessibility Guidelines (WCAG)[17] qui regroupent unensemble de spécifications à destination des webmaster sur la manière de développer des sites internet.

A.3.2 Objectifs

Ce projet a pour premier objectif de réaliser une plateforme permettant à un webmaster ayant développéun site internet sans s’être occupé des spécifications d’accessibilité du web, de pouvoir rendre ce site enquestion accessible en respectant au mieux les différentes normes.

Cette plateforme doit offrir deux modes différents aux webmaster, un mode manuel qui permet auwebmaster d’effectuer des choix pour chaque spécification qui le nécessite (donner un titre à une image,organiser un tableau, ...) et un mode automatique qui ne demande rien au webmaster et essaye de faire aumieux pour rendre la page la plus accessible possible en fonction des informations que la plateforme dispose.

Le second objectif de ce projet est de pouvoir utiliser cette même plateforme du côté client pour convertiren direct les sites visonnés par la personne handicapée en utilisant exclusivement le mode automatique décritprécédemment. Cet objectif est secondaire au PFE, et sera étudié en fonction de l’avancement de l’objectifprincipal.

A.3.3 Description de l’existant

Ce projet de fin d’études est la continuation de celui d’Antoine Blais intitulé Restructuration de pagesWeb [8] réalisé en 2007. L’objectif initial du projet étant sensiblement le même, Antoine a réalisé unepremière version de la plateforme composé d’un moteur et de plugin. Les plugins sont des éléments indépen-dants, par conséquent ils peuvent être développés sans avoir besoin de recompiler le moteur de la plateforme.

Le moteur permet au webmaster de charger une page web en entrée à partir d’un fichier local ou d’uneURL distante et de définir une page en sortie sur l’ordinateur. Il propose également l’aperçu du rendu HTMLde la page avant et après la modification de celle-ci. Il comporte un gestionnaire de plugins donnant lapossibilité au webmaster d’en sélectionner un certain nombre, de les ranger dans un certain ordre et de lesutiliser en mode manuel ou en mode automatique. Dans le cas de l’utilisation du mode manuel, pendant le


Annexe Présentation du projet

processus, un certain nombre de fenêtres apparaîtront pour proposer au webmaster différentes options.

Un mode console a également été developpé permettant à l’internaute d’utiliser la plateforme pour mo-difier directement les pages internet en ligne à l’aide du mode automatique. Ce mode ne peut être utiliséqu’en ligne de commande et est donc difficile d’utilisation pour un utilisateur lambda.

En ce qui concerne les plugins, chacun correspond à une spécification du WCAG ou à un outil aidant lewebmaster à modifier sa page web. Le précédent PFE s’est intéressé principalement à la directive 5 concer-nant les tableaux dans les pages HTML. Il a pour cette directive développé toutes les spécifications qu’il ajugé possible de réaliser dans les deux modes. Il a également travaillé sur une petite partie de la spécification1.1 qui conseille d’ajouter un texte alternatif pour tous les médias (images, applets, sons, vidéos) sur inter-net et la 6.3 qui permet de s’assurer qu’une alternative est présente quand un élément est désactivé (codejavascript, applet, ...). Pour terminer, il a implémenté des outils d’aide au webmaster permettant d’intégrerles feuilles de style directement dans la page, d’indenter le code, ou encore de changer les liens des imagespour les pages distantes.

La figure A.1 représente la plateforme à la fin du PFE précédent dans son mode avec interface destinéau webmaster.

Figure A.1 – La plateforme à la fin du PFE précédent (juin 2007)


84

A.4 Description de l’environnement

A.4.1 Les acteurs du logiciel

Les acteurs principaux du logiciel sont :– Les webmaster utilisant la plateforme comme outil leur permettant de rendre leur site web le plus

accessible aux personnes handicapées. En fonction du temps qu’ils ont, ils peuvent utiliser le modemanuel et faire leur propre choix ou utiliser le mode automatique, dans ce cas là, les plugins font lechoix à leur place.

– Les internautes utilisant la plateforme pour transformer les pages directement à partir de celles pré-sentes sur internet.

– Les développeurs voulant intégrer un nouveau plugin à la plateforme et l’utiliser comme outil.

A.4.2 Les relations entre les acteurs

La figure A.2 présente l’environnement du projet ou l’on peut voir les différents acteurs ainsi que lelogiciel composé du système (le moteur) et des plugins.

Figure A.2 – L’environnement du projet

1. Le webmaster utilise le système pour donner les pages de son site internet en entrée. Il sélectionne lesplugins qu’il souhaite utiliser et il obtient en retour après traitement les pages modifiées de son siteen sortie.

2. L’internaute utilise le système pour naviguer sur internet, les pages des sites peu accessibles sontmodifiées par le mode automatique du moteur puis sont renvoyées à l’internaute.


Annexe Description de l’environnement

3. Le développeur d’un nouveau plugin, l’implémente indépendamment sans avoir besoin de modifier etde recompiler le système. Il n’interagit donc pas directement avec le système.

4. Le système communique avec les plugins en leur envoyant le code source de la page selectionné. Lesplugins effectuent leur traitements respectifs et demandent en mode manuel des informations à saisirpar le webmaster. Ils retournent ensuite au moteur le code source modifiés des pages web. En modeconsole, la communication est la même, cependant comme il s’agit du mode automatique, aucunesaisie n’est demandé à l’internaute via les plugins.


86

A.5 Expression des besoins

A.5.1 Besoins fonctionnels

1. Mise en place d’une hiérarchie entre les différents plugins.

Actuellement, le moteur comporte 13 plugins à son actif, developpé par le PFE précédent. La gestiondes plugins était donc réalisée en conséquence, une petite liste comportant tous ces plugins dansl’ordre alphabétique. Après l’étude des directives du WCAG 1.0, je me suis rendu compte de l’exis-tence d’environ 65 spécifications, ce qui correspond à 65 plugins. Si l’on rajoute des plugins d’aideau webmaster comme celui d’indentation par exemple, ou encore si l’on anticipe la mise en place duWCAG 2.0 qui doit contenir un nombre au moins équivalent de spécifications, on arrive très vite àun grand nombre de plugins à gérer. La gestion d’une simple liste de plugins n’est plus suffisante. Ilfaudra réfléchir à la mise en place d’une nouvelle méthode de gestion des plugins,en les hiérarchisantpar catégories, et en ne les affichant pas nécessairement tous à chaque instance du moteur.

2. Terminer la Directive 1, commencé par le PFE précédent.

Antoine Blais a réalisé au cours de son projet, un plugin permettant d’ajouter un texte alternatif à uneimage. Il s’agit de l’exemple classique en matière d’accessibilité de page internet. Hors cette démarchefait partie de la spécification 1.1 de la directive 1 du WCAG. Il est nécessaire de la terminer pour avoirune spécification complète et non partielle. Cette spécification impose la présence de textes alternatifspour tout ce qui ne peut être perçu par un handicapé visuel (mais également par un lecteur d’écran).Il s’agit entre autre des images cliquables, des vidéos, des applets java, des sons, etc. Cette partie visedonc à donner des alternatives, automatisables ou non pour ces éléments contenus dans les pages web.

3. Réaliser des plugins pour les spécifications de la directive 3 des WCAG qui correspondent à l’utilisationdes balisages et des feuilles de style de façon approprié.

Aucun travail n’a été réalisé sur la directive 3 dans le passé. Il s’agit donc d’étudier en détail cette di-rective, pour chaque spécification, définir si elle est automatisable ou non. Trouver selon les différentscas, des solutions automatisables et manuelles pour le webmaster. Imaginer les interfaces homme-machine correspondantes et implémenter le tout en différenciant chaque spécification par un pluginautonome.

4. Réaliser des plugins pour les spécifications de la directive 11 des WCAG qui correspondent à l’utilisa-tion des technologie du W3C quand cela est possible.

Même chose que pour la directive 3.

5. Transformer le moteur en application gérant plusieurs langues (secondaires).

J’ai également pensé à mettre en place une classe permettant la gestion de langues étrangères. Eneffet, le moteur sera très certainement adapté à des plugins gérant des spécifications étrangères parla suite. Il peut donc être intéressant de lui rajouter rapidement cette fonctionnalité avant que celadevienne trop de modifications à faire.

Les directives 3 et 11 ont été choisis suite à une étude (réalisé par mon encadrante dans le cadre de sathèse) des sites web public d’Indre-et-Loire entre les différentes directives du WCAG. Cette étude a montré


Annexe Expression des besoins

que 43% des erreurs d’accessibilités des pages webs venaient de la directive 3 et 42% pour la directive 11.Ensuite on compte 9% pour la directive 1, puis 1% ou moins pour les autres directives.

A.5.2 Besoins non fonctionnels

1. Le code doit être réalisé en java.

2. L’application doit être multi-plateforme (Mac OS, Unix, Windows).

3. Réaliser de la documentation (cf chapitre documentation)

4. Tester les plugins réalisés sur un ensemble de pages internet.


88

A.6 Contraintes

A.6.1 Contraintes techniques

La plateforme doit pouvoir accueillir un nouveau plugin sans avoir à recompiler le moteur. Les pluginssont des fichiers .jar indépendants placés dans un repertoire "plugin" contenu dans le même dossier que lemoteur. Il doit être facile pour un développeur lambda de réaliser un plugin, de le placer dans ce dossier, etde pouvoir l’utiliser en lançant le moteur et en le séléctionnant.

A.6.2 Contraintes d’interfaces

L’interface de la plateforme doit être la plus claire possible pour le webmaster utilisant le logiciel.Actuellement, l’utilisation de la plateforme par l’internaute se fait en mode console. Une partie optionnellede ce projet (en fonction du temps), serait de permettre à l’ihm (interface homme machine) de la plateformede gérer également cette partie là.

A.6.3 Contraintes temporelles

Ce projet doit être réalisé pendant la période des projets de fin d’étude d’octobre 2008 à juin 2009. Unbilan à mi parcours au mois janvier ou février sera réalisé avec l’ensemble de l’équipe HaNT.

A.6.4 Maintenance et évolutivité du logiciel attendu

– La structure du code doit être la plus claire possible, bien indentée et commentée, pour une réutilisationultérieure du projet.

– la modularité du code doit être telle que la plateforme soit facilement extensible, et qu’une personnepuisse aisément rajouter des fonctionnalités, et dans notre cas inclure facilement des plugins.

– La portabilité du code doit permettre d’utiliser l’application aussi bien sur Mac OS, Unix ou Windows.


Annexe Documentation

A.7 Documentation

A.7.1 Documents de spécification, de conception,. . .attendus

Dans le cadre de ce PFE, un cahier des charges de l’application demandé par le client comprenantl’ensemble des besoins fonctionnels et non-fonctionnels devra être réalisé. Il sera validé par l’encadrant etremis au responsable des PFE avant les vacances de noël. Ce document permettra à la fin de ce PFE depouvoir juger si le travail demandé par le client a bien été mené à terme.

Un rapport de projet est également attendu pour le mois de juin. Ce rapport regroupera l’ensemble desdémarches du projet, expliquées de façon précise et appuyées de différents schémas, ainsi que les différentesméthodes mises en place pour les appliquer.

Pour terminer, une documentation java (javadoc) sera également fournie avec le code source de l’appli-cation permettant une réutilisabilité du code par de futurs développeurs de ce projet.

A.7.2 Manuels utilisateurs, procédures d’installation, gestion du système . . .attendus

Une aide utilisateur sera fournie avec l’application, expliquant chaque élément de l’ihm, pour une priseen main plus facile d’un webmaster ou d’un internaute handicapé.

Un tutorial à destination du webmaster sera également réalisé pour lui expliquer la façon d’implémenterun nouveau plugin.


90

A.8 Plan de développement

A.8.1 Proposition de planning du développement

J’ai mis en place un planning de répartition du développement des plugins tout au long de l’année illustrépar la figure A.3. Il est normalement facilement réalisable et j’espère avoir le temps de l’allonger au fur et àmesure. Avant l’étude des directives en question pour les périodes entre Noël et février, et entre février etpâques, il est difficile d’estimer pleinement le temps que cela va prendre. J’effectuerais à la fin de chaquephase de tests des différentes directives, un livrable sous forme d’un groupe de plugins correspondant auxspécifications implémentées et testées. La figure A.3 représente le planning du projet, découpé en différentesétapes, tout au long de la période du projet.

A.8.2 Plan d’assurance qualité

Pour tester la qualité de l’application et plus particulièrement des différents plugins de spécification quej’aurais mis en place lors de ce PFE, je réaliserais après avoir terminé chaque directive, une série de testsdes spécifications WCAG avant et après utilisation de la plateforme sur un ensemble de sites internet choisispréalablement. Ces tests permettront de voir l’efficacité des plugins sur les différentes spécifications quej’aurais réalisées et ainsi déterminer leur utilité auprès d’un webmaster ou d’un internaute.


Annexe Plan de développement

Figure A.3 – Planning du PFE


ANNEXE B

Rubrique d’aide

Figure B.1 – Interface de la plateforme

Barre de menu

La barre de menu permet d’accéder aux menus suivants :

• Fichier : Comporte un accès à la fenêtre d’option qui permet de changer la langue de l’application.On peut également quitter l’application par ce menu.• Aide : Comporte une rubrique d’aide sur le fonctionnement de la plateforme ainsi qu’un sous-menu à

propos présentant le projet et les auteurs.

Page Web d’entrée

Dans cette partie est indiquée quelle est la page Web d’entrée qui sera utilisée pour être transforméepar la platerforme de traitements. Cette page peut être de deux types :

• une page Web locale : chargée à partir d’un emplacement local (disque dur...),• une page Web distante : chargée à partir d’un site Web.


Annexe

Page Web de sortie

Cette partie permet d’indiquer à l’application, le fichier local qui contiendra la page Web transformée.

Aperçus

Cette page permet de définir les aperçus qui l’on souhaite voir. Les aperçus disponibles sont :

• aperçu de la page d’entrée : qui affiche un aperçu de la page Web avant de la transformer,• aperçu de la page de sortie : qui affiche un aperçu de la page Web une fois modifiée.

Pour que les aperçus sélectionnés soient affichés, il faut cliquer sur le bouton "Générer aperçu" (cf 10).

Plugins disponibles

Cette partie indique quels sont les plugins disponibles dans l’application. Le nom d’un plugin est composéde deux parties :

• le nom du plugin qui fournit une indication sur son rôle,• le niveau d’accessibilité dans lequel est classé le plugin. Si ce champ est vide, cela signifie que le plugin

associé n’est pas un plugin améliorant l’accessibilité de la page Web et dans certains cas, il peut mêmedétériorer l’accessibilité de la page Web sur laquelle il est appliqué.

Ces plugins sont hiérarchisés grâce à un arbre de naviguation permettant ainsi de mieux s’y retrouverlorsqu’un nombre important de plugins est chargé.

Niveau de priorité

• priorité 1 : doit être satisfaite pour rendre le contenu accessible à certains groupes,• priorité 2 : en étant satisfaite, certaines barrières seront levées et le document Web en sera davantage

accessible,• priorité 3 : si elle est satisfaite, seuls certains groupes éprouveront des difficultés à accéder aux infor-

mations. Cependant ce critère améliore l’accès au contenu Web.

Niveau de conformité

• A : tous les points de priorité 1 sont satisfaits,• AA : tous les points de priorité 1 et 2 sont satisfaits,• AAA : tous les points de priorité 1,2 et 3 sont satisfaits.

Les niveaux de conformité A, AA, AAA peuvent être reconnus par les logos suivants

Plugins à appliquer

Cette partie indique quels sont les plugins qui sont sélectionnés par l’utilisateur et qui seront donc uti-lisés pour modifier la page Web. L’ordre dans lequel ces plugins sont ordonnés indique dans quel ordre ilsseront utilisés lors de la transformation de la page Web. Pour modifier cet ordre, ou supprimer un plugin


94

ou des plugins de la liste, les boutons situés à droite permettent (de haut en bas) de déplacer vers le hautle(s) plugin(s) sélectionné(s), supprimer le(s) plugin(s) sélectionné(s) et déplacer vers le bas le(s) plugin(s)sélectionné(s).

Description du plugin

Ce champ fournit une description du plugin sélectionné dans la liste des plugins disponibles (cf 4). Cettedescription indique les actions qui seront effectuées sur la page Web et peut également fournir quelquesastuces/conseils sur l’utilisation de ce plugin.

Message d’erreur

Un message d’erreur peut apparaitre dans le cas où l’on tente de générer la transformation d’une pagesans l’ensemble des éléments nécessaires. Par exemple si aucune page n’est sélectionnée en entrée ou encoreaucun plugin n’est placé dans la liste des plugins à appliquer. Lorsque cette erreur s’affiche, la générationn’est pas lancée.

Mode d’utilisation

Ce paramètre permet de choisir entre une utilisation manuelle ou une utilisation automatique de la pla-teforme.

• Mode manuel : des choix sont proposés à l’utilisateur quant à la modification de la page Web,• Mode automatique : les modifications sur la page Web sont effectuées automatiquement sans proposer

de choix à l’utilisateur.

Générer aperçus

Permet de générer la page Web à partir des plugins sélectionnés et affiche le résultat à l’écran. Lesaperçus qui sont affichés à l’écran sont ceux qui ont été choisis dans la partie 4 (Aperçus). Le résultatgénéré ici ne sera pas sauvegardé, mais sert seulement à fournir un aperçu du résultat avant une sauvegardede celui-ci grâce au bouton Générer.

Générer

Permet de générer la page Web finale à partir des plugins sélectionnés et d’enregistrer le résultat dansle fichier html choisi dans la partie 3 (page Web de sortie).


ANNEXE C

Manuel développeur

C.1 Création de plugin

Cette partie est un tutorial consacré à la création d’un plugin à partir de l’IDE Netbeans.

Les pré-requis pour commencer sont (les versions sont celles utilisées dans ce tutorial et sont ici à titred’information) :

• Java JDK 1.6 : la plateforme Java,• Netbeans 6.5 : l’IDE de développement Java,• Jericho html 2.6 : la librairie de traitement HTML jericho html,• moteur.jar : qui est le .jar contenant l’exécutable de la plateforme de traitement.

C.1.1 Création du projet

La première étape consiste à la création du projet. Pour cela, il faut aller dans ”File -> New Project”.On arrive alors sur la fenêtre de la figure C.1 dans laquelle on spécifie le type de projet puis on arrive dansla fenêtre de la figure C.2 dans laquelle on indique le nom et l’emplacement du projet.

Une fois cette étape réalisée, NetBeans nous fournit un environnement de travail contenant déjà uneclasse (Main). Pour l’instant l’important est d’ajouter les librairies ”Jericho-HTML” et le jar contenant lemoteur ”moteur.jar”. Pour cela, on clique avec le bouton droit sur librairie et on sélectionne ”add Jar/folder”(figure C.3).

On ajoute alors moteur.jar et jericho-html-2.6.jar (figure C.4 et figure C.5).

La création du projet est maintenant terminée. Votre projet doit ressembler à la figure C.6. Si c’est bienle cas, il est alors possible de créer notre plugin.

C.1.2 Création du contenu

Pour commencer, certains packages doivent être importés pour ne pas avoir de problèmes par la suite :

import static Moteur.Language.tr;import Moteur.Constantes ;import Moteur.Mode;import Moteur.plugin.* ;import au.id.jericho.lib.html.* ;

Enuite, pour que notre plugin soit reconnu par la plateforme de traitement de page Web, il doit implé-menter l’interface Plugin de moteur.jar :

public class Main implements Plugin{}

Cette interface comporte 5 méthodes qui sont :


96

Figure C.1 – Création d’un nouveau projet 1/6

public Categorie getCategorie()public String getLibelle() ;public int getType() ;public String getDescription() ;public void actionOnSource(Source source,OutputDocument destination,

int mode, int level) throws PluginException;

La méthode ”getCategorie” permet de définir la ou les catégories parents d’un plugin en utilisant l’im-brication de catégorie. L’exemple ci-dessous présente un plugin ayant 2 catégories parents :

public Categorie getCategorie(){return new Categorie(tr("WCAG_1_0"), new Categorie(tr("Directive_10")));}

Il vous est possible de créer de nouvelles catégories pour vos plugins. Les catégories déjà mises en placesont :

• WCAG 1.0• Directive 1• Directive 3• Directive 5• Directive 6• Outils Webmaster


Annexe Création de plugin



En utilisant le même nom que ces catégories, vos plugins se retrouveront dans le même répertoire queceux déjà existants.

La méthode ”getLibelle” permet de définir le nom du plugin. L’exemple ci-dessous utilise la fonctiontr(”nom”) pour traduire ce libellé automatiquement grâce aux fichiers de langues correspondants.

public String getLibelle(){return tr("nouveauplugin_Libelle") ;}


98



La méthode ”getType” permet de définir le type du plugin (A, AA, AAA).

public int getType(){return Constantes.ACCESS_A ;}

La méthode ”getDescription” permet de donner une description sur l’action du plugin.

public String getDescription(){return tr("nouveauplugin_Description");}

La méthode ”actionOnSource” permet de définir les actions qui seront effectuées sur la page web. Ils’agit de la fonction principale de votre projet dans laquelle se trouvent les modifications à faire en fonction


Annexe Création de plugin


du mode choisi (manuel ou automatique). La figure C.7 présente un aperçu du code d’un plugin une foisimplementé.

Figure C.7 – Aperçu du code d’un nouveau plugin

C.1.3 Création du Jar

Pour compiler le code du plugin et créer le .jar correspondant, il faut appuyer sur la touche ”F11”. Lecode est alors compilé et un .jar est créé dans le dossier ”dist” du projet comme le montre la figure C.8.

Ce fichier jar peut ensuite être placé dans le dossier ”plugin” de notre plateforme de traitement et être


100

Figure C.8 – Fichier Jar du nouveau plugin

utilisé par celle-ci. La figure C.9 présente la plateforme de traitement après avoir reconnu le nouveau pluginque nous venons de réaliser ensemble.

Figure C.9 – Nouveau plugin reconnu par la plateforme de traitement


ANNEXE D

Bases des sites tests

D.1 Les sites d’Indre et Loire

Figure D.1 – Base des sites d’Indre et Loire 1/2


102

Figure D.2 – Base des sites d’Indre et Loire 2/2


Annexe Les sites tests

D.2 Les sites tests

Figure D.3 – Base des sites tests


Références bibliographiques

[1] Planète Accessibilité : Planète accessibilité - la fraiche actualité de l’accessibilité numérique, Janvier2009. http://planete-accessibilite.com/ - dernier accès le 25/01/2009.

[2] Apache : Apache maven project, 2008. http://maven.apache.org/ - dernier accès le 15/10/2008.

[3] Apache : Batik java svg toolkit, Septembre 2008. http://xmlgraphics.apache.org/batik/index.html -dernier accès le 20/11/2008.

[4] APINC : Openwebgroup pour les standards du web, 2008. http://openweb.eu.org/openwebgroup/openwebgroup - dernier accès le 25/01/2009.

[5] APINC : Apinc - association pour l’internet non commercial, 2009. http://validateur-accessibilite.apinc.org/ - dernier accès le 04/04/2009.

[6] Atalan : Accessibilité du web - centre de ressources et de recherche sur l’accessibilité du web, Janvier2009. http://www.accessiweb.org/ - dernier accès le 25/01/2009.

[7] ATRC : Vérificateur d’accessibilité web, 2009. http://aprompt.snow.utoronto.ca - dernier accès le02/05/2009.

[8] Antoine Blais : Restructuration de pages Web. Projet de fin d’étude, Ecole polytechnique de l’uni-versité de Tours, département informatique, 2007.

[9] BLL : Anysurfer - label de qualité belge pour les sites web accessibles, 2009. http://www.anysurfer.be/fr/ - dernier accès le 28/01/2009.

[10] Denis Boulay et Pierre Guillou : Méthodologie Unifiée d’Evaluation de l’Accessibilité du Web(UWEM 1.0). AccessiWeb, 2006. http://www.accessiweb.org/fr/uwem/index.html/ - dernier accès le09/10/2008.

[11] BrailleNet : Braillenet : Une porte sur le web pour les personnes handicapées visuelles, Janvier2009. http://www.braillenet.org/ - dernier accès le 25/01/2009.

[12] Ben Caldwell, Michael Cooper, Loretta Guarino Reid et Gregg Vanderheiden : Techniquesfor Web Content Accessibility Guidelines 2.0. Working Draft, avril 2008. http://www.w3.org/TR/WCAG20-TECHS/ - dernier accès le 13/07/2008.

[13] Reid Caldwell, Cooper et Vanderheiden : Web Content Accessibility Guideline 2.0, WCAG 2.0,Decembre 2008. http://www.w3.org/TR/WCAG20/ - dernier accès le 01/02/2009.

[14] CAST : Bobby, 2009. http://www.cast.org/products/Bobby/index.html - dernier accès le02/04/2009.

[15] Bernard Caylux : Jtree, 2008. http://prevert.upmf-grenoble.fr/Prog/Java/swing/JTree.html - der-nier accès le 23/10/2008.

[16] CEN, éditeur. Spécifications pour un schéma d’évaluation de la conformité à l’accessibilité du Web etpour une marque de qualité de l’accessibilité du Web, numéro 15554 de 1. CEN, CEN, Juin 2006.

[17] Wendy Chisholm, Gregg Vanderheiden et Ian Jacobs : Web Content Accessibility Guideline 1.0,WCAG 1.0, 1999. http://www.w3.org/TR/WAI-WEBCONTENT - dernier accès le 09/10/2008.

[18] WAB Cluster : Unified Web Evaluation Methodology (UWEM 1.2 Core), Septembre 2007.

[19] WAB Cluster : Unified Web Evaluation Methodology (UWEM 1.2 Tests), Septembre 2007.

http://planete-accessibilite.com/

http://maven.apache.org/

http://xmlgraphics.apache.org/batik/index.html

http://openweb.eu.org/openwebgroup/openwebgroup

http://openweb.eu.org/openwebgroup/openwebgroup

http://validateur-accessibilite.apinc.org/

http://validateur-accessibilite.apinc.org/

http://www.accessiweb.org/

http://aprompt.snow.utoronto.ca

http://www.anysurfer.be/fr/

http://www.anysurfer.be/fr/

http://www.accessiweb.org/fr/uwem/index.html/

http://www.braillenet.org/

http://www.w3.org/TR/WCAG20-TECHS/

http://www.w3.org/TR/WCAG20-TECHS/


http://www.cast.org/products/Bobby/index.html

http://prevert.upmf-grenoble.fr/Prog/Java/swing/JTree.html

http://www.w3.org/TR/WAI-WEBCONTENT

RÉFÉRENCES BIBLIOGRAPHIQUES

[20] Sonia Colas : Outils d’amélioration de l’accessibilité du web pour les personnes visuellement handi-capées. Thèse pour obtenir le grade de docteur de l’université de tours, Université François Rabelaisde Tours, Novembre 2008.

[21] Sonia Colas, Nicolas Monmarché et Mohamed Slimane : Correcteur automatique ou assistanceau webmestre pour obtenir un web accessible. In Cépaduès, éditeur : Handicap 2008, Eds. NadineVigouroux et Philippe Gorce, Cépaduès éditions, ISBN 978-2-85428-848-3, numéro ISBN 978-2-85428-848-3 de 1, pages 122–127, France (Paris), 10 - 12 juin 2008.

[22] CTIC : Taw3 online, 2009. http://www.tawdis.net/taw3/cms/en - dernier accès le 02/04/2009.

[23] Commité de Coordination pour la Modernisation de L’Etat, éditeur. Référentiel de normalisationpour les sites web du Gouvernement luxembourgeois. Commité de Coordination pour la Modernisationde L’Etat, Commité de Coordination pour la Modernisation de L’Etat, Octobre 2007.

[24] Developpez.com : Quelles différences entre arraylist, linkedlist et vector ?, 2006. http://java.developpez.com/faq/java/?page=langage_donnees#LANGAGE_COLLECTIONS_info_list - dernieraccès le 05/11/2008.

[25] Euracert : Euracert : Label européen (accessibilité du web), 2009. http://www.euracert.org/ -dernier accès le 25/01/2009.

[26] République Française : Loi du 30 juin 1975, Janvier 1975. http://handy.univ-lyon1.fr/loi/recueil/accessibilite/loi75534.html - dernier accès le 28/01/2009.

[27] Fundosa : Technosite - la accesibilidad potentia la web, 2009. http://www.technosite.es/ - dernieraccès le 28/01/2009.

[28] Frank Galey : Web-pour-tous, 2007. http://www.web-pour-tous.org/ - dernier accès le 25/01/2009.

[29] Afnor group : Normes accessibilité afnor dédié à l’accessibilité, 2008. http://www.afnor.org/accessibilite/ - dernier accès le 25/01/2009.

[30] HiSoftware : Welcome to the hisoftware® cynthia says portal, 2009. http://www.contentquality.com/ - dernier accès le 02/04/2009.

[31] Jason Hunter : Jdom, Novembre 2007. http://www.jdom.org/ - dernier accès le 19/11/2008.

[32] IBM : Rational policy tester accessibility edition, 2009. http://www-01.ibm.com/software/awdtools/tester/policy/accessibility/ - dernier accès le 02/04/2009.

[33] iCITA : Firefox accessibility extension. http://firefox.cita.uiuc.edu/ - dernier accès le 02/05/2009.

[34] JabRef : Jabref reference manager, Novembre 2008. http://jabref.sourceforge.net/ - dernier accèsle 28/03/2009.

[35] Jericho : Jericho html parser, Juin 2008. http://jerichohtml.sourceforge.net/doc/index.html - dernieraccès le 19/11/2008.

[36] Wilson Mar : Java internationalization, 2005. http://www.wilsonmar.com/1javaintl.htm - dernieraccès le 06/11/2008.

[37] Mozdev : Accessibar, June 2008. http://accessibar.mozdev.org/ - dernier accès le 02/05/2009.

[38] Interactive NEOMA : Histoire des standards du web et des normes d’accessibilité, 2005. http://www.neoma-interactive.com/2006/09/27/histoire-des-standards-du-web-et-des-normes-d-accessibilite/ -dernier accès le 25/01/2009.

[39] NetBeans : Netbeans ide 6.5, Mars 2009. http://www.netbeans.org/ - dernier accès le 28/03/2009.

[40] Laboratory of HCI for Special Needs : Evalaccess 2.0, 2009. http://sipt07.si.ehu.es/evalaccess2/index.html - dernier accès le 28/03/2009.

[41] RenaissanceNumérique : Renaissance numérique, 2009. http://www.renaissancenumerique.org/- dernier accès le 01/02/2009.


http://www.tawdis.net/taw3/cms/en

http://java.developpez.com/faq/java/?page=langage_donnees#LANGAGE_COLLECTIONS_info_list

http://java.developpez.com/faq/java/?page=langage_donnees#LANGAGE_COLLECTIONS_info_list

http://www.euracert.org/

http://handy.univ-lyon1.fr/loi/recueil/accessibilite/loi75534.html

http://handy.univ-lyon1.fr/loi/recueil/accessibilite/loi75534.html

http://www.technosite.es/

http://www.web-pour-tous.org/

http://www.afnor.org/accessibilite/

http://www.afnor.org/accessibilite/

http://www.contentquality.com/

http://www.contentquality.com/

http://www.jdom.org/

http://www-01.ibm.com/software/awdtools/tester/policy/accessibility/

http://www-01.ibm.com/software/awdtools/tester/policy/accessibility/

http://firefox.cita.uiuc.edu/

http://jabref.sourceforge.net/

http://jerichohtml.sourceforge.net/doc/index.html

http://www.wilsonmar.com/1javaintl.htm

http://accessibar.mozdev.org/

http://www.neoma-interactive.com/2006/09/27/histoire-des-standards-du-web-et-des-normes-d-accessibilite/

http://www.neoma-interactive.com/2006/09/27/histoire-des-standards-du-web-et-des-normes-d-accessibilite/

http://www.netbeans.org/

http://sipt07.si.ehu.es/evalaccess2/index.html

http://sipt07.si.ehu.es/evalaccess2/index.html

http://www.renaissancenumerique.org/

106

[42] Groupe SQLI : Auditweb : audit d’ergonomie et conseil en utilisabilité web, 2008. http://www.auditweb.net/ - dernier accès le 25/01/2009.

[43] Sun : JavaTM 2 Platform, Standard Edition, v 1.4.2 - API Specification, 2003. http://java.sun.com/j2se/1.4.2/docs/api - dernier accès le 06/11/2008.

[44] Sun : How to Use Trees, 2007. http://java.sun.com/docs/books/tutorial/uiswing/components/tree.html - dernier accès le 23/10/2008.

[45] Sun : Example of Internationalization, Février 2008. http://java.sun.com/docs/books/tutorial/i18n/intro/quick.html - dernier accès le 06/11/2008.

[46] Temesis : Opquast - bonnes pratiques qualité pour les services en ligne, 2009. http://fr.opquast.com/- dernier accès le 25/01/2009.

[47] Urbilog : Ocawa validateur d’accessibilité, 2009. http://www.ocawa.com/ - dernier accès le25/01/2009.

[48] Total Validator : http ://www.totalvalidator.com/, 2009. http://www.totalvalidator.com/ - dernieraccès le 10/05/2009.

[49] W3C : Scalable Vector Graphics (SVG) 1.1 Specification, Janvier 2003. http://www.w3.org/TR/SVG11/ - dernier accès le 16/10/2008.

[50] W3C : W3Schools Online Web Tutorials, 2008. http://www.w3schools.com - dernier accès le16/10/2008.

[51] W3C : Web accessibility initiative (wai), 2008. http://www.w3.org/WAI/ - dernier accès le09/10/2008.

[52] Xul.fr : Svg - scalable vector graphic, 2008. http://www.xul.fr/xml-svg.html - dernier accès le20/11/2008.


http://www.auditweb.net/

http://www.auditweb.net/

http://java.sun.com/j2se/1.4.2/docs/api

http://java.sun.com/j2se/1.4.2/docs/api

http://java.sun.com/docs/books/tutorial/uiswing/components/tree.html

http://java.sun.com/docs/books/tutorial/uiswing/components/tree.html

http://java.sun.com/docs/books/tutorial/i18n/intro/quick.html

http://java.sun.com/docs/books/tutorial/i18n/intro/quick.html

http://fr.opquast.com/

http://www.ocawa.com/

http://www.totalvalidator.com/

http://www.w3.org/TR/SVG11/

http://www.w3.org/TR/SVG11/

http://www.w3schools.com

http://www.w3.org/WAI/

http://www.xul.fr/xml-svg.html

Index

A-Prompt, 18Accessibilité, 11, 14Accessibilite numérique, 11AccessiWeb, 15AFNOR, 11Apinc, 29, 37AuditWeb, 16

Batik, 37Bobby, 18BrailleNet, 12, 15

Correcteurs, 18Cynthia Says, 18, 67

DOCTYPE, 61

Euracert, 14, 15EvalAccess, 18, 37, 67, 73

HaNT, 9, 21, 62, 76HTML, 22

IHM, 28, 54, 59

JabRef, 37Java, 27, 36JDOM, 28, 37Jericho, 28, 37JTree, 42, 47

Netbeans, 27, 36Niveau d’accessibilité, 21NSI, 14

Ocawa, 16, 18, 28, 37, 67OpenWeb, 15Opquast, 16

Planète Accessibilité, 15Plugin, 22

RENO, 14

SGML, 22Statistiques, 68

Swing, 28, 37

TAW, 18Total Validator, 18

UWEM, 14

Validateur, 73Validateurs, 17, 67

W3C, 9, 12, 17, 21WAI, 9, 12, 21WCAG, 9, 13, 14, 17, 21, 70WCAG 1.0, 21, 42WCAG 2.0, 22Web 2.0, 9, 70Web-pour-tous, 15Webservice, 63, 65WebXACT, 18

X-HTML, 22XHTML, 13XML, 22


Conception de plugins de correction depages web afin qu’elles respectent les

normes d’accessibilité

Département Informatique5ème année2008-2009

Rapport de projet de fin d’études

Résumé: Les personnes malvoyantes et non-voyantes utilisent des aides techniques telles que les claviersbrailles ou la synthèse vocale pour naviguer sur internet. Pour que cette navigation soit possible et efficaceil est nécessaire que les pages web disponibles sur internet soient réalisées de manière conforme aux guidesdes WCAG (Web Content Accessibility Guidelines). L’outil réalisé au cours de ce PFE est une plateformede traitement à destination des webmasters dont l’objectif est de fournir des plugins par spécification desWCAG pour l’aider à corriger ces pages web. L’objectif de ce projet est de continuer la réalisation des pluginscommencés par Antoine Blais en prenant en compte la priorité de chacun suite aux analyses des erreursd’accessibilité testées sur une base de site internet.

Mots clefs: Accessibilité, Personne non-voyantes, Internet, pages web, WCAG, W3C, HaNT

Abstract : The persons partially-sighted and visually handicapped use technical helps such as Braillekeyboards or the speech synthesis to navigate on internet. If we want this navigation possible and effective,it is necessary that pages available on internet are realized in a way in compliance with Web Content Acces-sibility Guidelines (WCAG). The tool realized during this PFE is a treatment platform for the webmasters.The objective of this application is to add plugins by specifications of the WCAG to help the webmaster tocorrect these web pages. The goal of this project is to continue the realization of plugins begun with AntoineBlais by taking into account the priority of each further from the analyses of the errors of accessibility testedon a base of web site.

Keywords : Accessibility, Visually handicapped person, Internet, web pages, WCAG, W3C, HaNT

Étudiant :Jonathan [email protected]

Encadrants :Sonia Colas

[email protected] Monmarché

[email protected] Slimane

[email protected]é François-Rabelais, Tours



