Département Informatique 5ème année Cahier des Charges

Transcription

1 École Polytechnique de l Université de Tours 64, Avenue Jean Portalis TOURS, FRANCE Tél. +33 (0) Fax +33 (0) Département Informatique 5ème année Cahier des Charges Conception de plugins de correction de pages web afin qu elles respectent les normes d accessibilité Étudiant : Jonathan Courtois jonathan.courtois@etu.univ-tours.fr Encadrants : Sonia Colas sonia.colas@univ-tours.fr Nicolas Monmarché nicolas.monmarche@univ-tours.fr Mohamed Slimane mohamed.slimane@univ-tours.fr Université François-Rabelais, Tours Version 1

2

3 Table des matières 1 Validation et Historique du cahier des charges Validation Historique des modifications Préambule Présentation du Client Conventions et terminologie utilisées dans le document Présentation du projet Contexte Objectifs Description de l existant Description de l environnement Les acteurs du logiciel Les relations entre les acteurs Expression des besoins Besoins fonctionnels Besoins non fonctionnels Contraintes Contraintes techniques Contraintes d interfaces Contraintes temporelles Maintenance et évolutivité du logiciel attendu Documentation Documents de spécification, de conception,...attendus Manuels utilisateurs, procédures d installation, gestion du système...attendus Plan de développement Proposition de planning du développement Plan d assurance qualité Références bibliographiques 14 3

4 CHAPITRE 1 Validation et Historique du cahier des charges 1.1 Validation Référence : Cahier de charges du PFE n 41 Projet : Conception de plugins de correction de pages web afin qu elles respectent les normes d accessibilité Emetteur : Jonathan Courtois - salle HaNT - ordinateur n 4 Date d émission : Le 10/12/2008 Nom Date Validation(0/N) Commentaires Sonia Colas 10/12/2008 O Table 1.1 Validation 1.2 Historique des modifications Version Date Description des modifications Table 1.2 Historique des modifications 4

5 CHAPITRE 2 Préambule 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 sur l aide aux personnes handicapé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 sont l intelligence artificielle comprenant les algorithmes génétiques et les fourmis artificielles et également la modé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 Rabelais de Tours. Je suis également suivi par Nicolas Monmarché, maître de conférences en Informatique, et Mohamed 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 accessibilité du web pour les personnes visuellement handicapées [4]. 2.2 Conventions et terminologie utilisées dans le document HaNT : Terme désignant l équipe Handicap & Nouvelles Technologies du laboratoire informatique de l université de Tours. W3C : Le World Wide Web Consortium est l organisme de normalisation des technologies du web telles 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 du web accessible aux personnes handicapés et d une manière générale à toute personne sans nécessiter de prérequis particulier. WCAG : Le Web Content Accessibility Guidelines est un guide du WAI expliquant aux webmasters comment rendre leurs pages accessibles. Directive : Une directive est un thème du WACG 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 de définir l importance de celles-ci. HTML : L Hypertext Markup Language est un langage de balise permettant l affichage d information sur une page internet. IHM : L interface homme machine est la partie graphique d une application permettant à l utilisateur d interagir avec le système. 5

6 CHAPITRE 3 Présentation du projet 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 la communication, etc. Un certains nombres d outils ont été developpé dans le secteur de l informatique pour permettre aux handicapés d utiliser plus facilement un ordinateur. Parmis les plus connus, on trouve le lecteur d écran qui retransmet de façon auditive un texte ou une page internet, ainsi que la tablette braille permettant de lire un texte à l aide du langage braille. Cependant, les handicapés ne sont pas tous égaux face à l accessibilité informatique. En effet, certains mal 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, concernant l accessibilité numérique, pour assurer la compatibilité des sites avec les aides techniques. Elles précisent que les sites web doivent respecter les Web Content Accessibility Guidelines (WCAG)[3] qui regroupent un ensemble de spécifications à destination des webmaster sur la manière de développer des sites internet. 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 en question accessible en respectant au mieux les différentes normes. Cette plateforme doit offrir deux modes différents aux webmaster, un mode manuel qui permet au webmaster 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 au mieux 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 convertir en direct les sites visonnés par la personne handicapée en utilisant exclusivement le mode automatique décrit précédemment. Cet objectif est secondaire au PFE, et sera étudié en fonction de l avancement de l objectif principal. 3.3 Description de l existant Ce projet de fin d études est la continuation de celui d Antoine Blais intitulé Restructuration de pages Web [1] réalisé en L objectif initial du projet étant sensiblement le même, Antoine a réalisé une première version de la plateforme composé d un moteur et de plugin. Les plugins sont des éléments indépen- 6

7 Description de l existant 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 une URL distante et de définir une page en sortie sur l ordinateur. Il propose également l aperçu du rendu HTML de la page avant et après la modification de celle-ci. Il comporte un gestionnaire de plugins donnant la possibilité au webmaster d en sélectionner un certain nombre, de les ranger dans un certain ordre et de les utiliser en mode manuel ou en mode automatique. Dans le cas de l utilisation du mode manuel, pendant le 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 modifier 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 le webmaster à modifier sa page web. Le précédent PFE s est intéressé principalement à la directive 5 concernant les tableaux dans les pages HTML. Il a pour cette directive développé toutes les spécifications qu il a jugé possible de réaliser dans les deux modes. Il a également travaillé sur une petite partie de la spécification 1.1 qui conseille d ajouter un texte alternatif pour tous les médias (images, applets, sons, vidéos) sur internet et la 6.3 qui permet de s assurer qu une alternative est présente quand un élément est désactivé (code javascript, applet,...). Pour terminer, il a implémenté des outils d aide au webmaster permettant d intégrer les feuilles de style directement dans la page, d indenter le code, ou encore de changer les liens des images pour les pages distantes. La firgure 3.1 représente la plateforme à la fin du PFE précédent dans son mode avec interface destiné au webmaster. Figure 3.1 La plateforme à la fin du PFE précédent (juin 2007) 7

8 CHAPITRE 4 Description de l environnement 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 mode manuel et faire leur propre choix ou utiliser le mode automatique, dans ce cas là, les plugins font le choix à 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. 4.2 Les relations entre les acteurs La figure 4.1 présente l environnement du projet ou l on peut voir les différents acteurs ainsi que le logiciel composé du système (le moteur) et des plugins. Figure 4.1 L environnement du projet 8

9 Les relations entre les acteurs 1. Le webmaster utilise le système pour donner les pages de son site internet en entrée. Il sélectionne les plugins qu il souhaite utiliser et il obtient en retour après traitement les pages modifiées de son site en sortie. 2. L internaute utilise le système pour naviguer sur internet, les pages des sites peu accessibles sont modifiées par le mode automatique du moteur puis sont renvoyées à l internaute. 3. Le développeur d un nouveau plugin, l implémente indépendamment sans avoir besoin de modifier et de 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é. Les plugins effectuent leur traitements respectifs et demandent en mode manuel des informations à saisir par le webmaster. Ils retournent ensuite au moteur le code source modifiés des pages web. En mode console, la communication est la même, cependant comme il s agit du mode automatique, aucune saisie n est demandé à l internaute via les plugins. 9

10 CHAPITRE 5 Expression des besoins 5.1 Besoins fonctionnels 1. Mise en place d une hiérarchie entre les différents plugins. 2. Terminer la Directive 1, commencé par le PFE précédent. 3. Réaliser des plugins pour les spécifications de la directive 3 des WCAG qui correspondent à l utilisation des balisages et des feuilles de style de façon approprié. 4. Réaliser des plugins pour les spécifications de la directive 11 des WCAG qui correspondent à l utilisation des technologie du W3C quand cela est possible. 5. Transformer le moteur en application gérant plusieurs langues (secondaires). Les directives 3 et 11 ont été choisis suite à une étude (réalisé par mon encadrante dans le cadre de sa thèse) des sites web public d Indre-et-Loire entre les différentes directives du WCAG. Cette étude a montré 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. 5.2 Besoins non fonctionnels 1. La plateforme doit pouvoir accueillir un nouveau plugin sans avoir à recompiler le moteur. 2. Le code doit être réalisé en java. 3. L application doit être multi-plateforme (Mac OS, Unix, Windows). 4. Rédaction d un cahier des charges avant les vacances de noël. 5. Réalisation d une javadoc du code source. 6. Mise en place d une aide utilisateur pour la plateforme. 7. Tester les plugins réalisés sur un ensemble de pages internet. 10

11 CHAPITRE 6 Contraintes 6.1 Contraintes techniques Ce projet de fin d étude étant la reprise d un PFE existant, doit conserver le même langage de programmation à savoir le Java. Il doit être portable pour être lancé et utilisé sur les systèmes d exploitation Mac OS, Unix et Windows. L application doit être utilisable par tous sans connaissances approfondies sur les technologies du web. 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 optionnelle de ce projet (en fonction du temps), serait de permettre à l ihm (interface homme machine) de la plateforme de gérer également cette partie là. 6.3 Contraintes temporelles Ce projet doit être réalisé pendant la période des projets de fin d étude d octobre 2008 à juin Un bilan à mi parcours au mois janvier ou février sera réalisé avec l ensemble de l équipe HaNT. 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éutilisation ultérieure du projet. la modularité du code doit être telle que la plateforme soit facilement extensible, et qu une personne puisse 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. 11

12 CHAPITRE 7 Documentation 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 comprenant l ensemble des besoins fonctionnels et non-fonctionnels devra être réalisé. Il sera validé par l encadrant et remis au responsable des PFE avant les vacances de noël. Ce document permettra à la fin de ce PFE de pouvoir 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 des démarches du projet, expliquées de façon précise et appuyées de différents schémas, ainsi que les différentes méthodes mises en place pour les appliquer. Pour terminer, une documentation java (javadoc) sera également fournie avec le code source de l application permettant une réutilisabilité du code par de futurs développeurs de ce projet. 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 prise en 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émenter un nouveau plugin. 12

13 CHAPITRE 8 Plan de développement 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 8.1. 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 et pâques, il est difficile d estimer pleinement le temps que cela va prendre. Figure 8.1 Planning du PFE 8.2 Plan d assurance qualité Pour tester la qualité de l application et plus particulièrement des différents plugins de spécification que j aurais mis en place lors de ce PFE, je réaliserais vers la fin de celui-ci une série de tests des spécifications WCAG avant et après utilisation de la plateforme sur un ensemble de sites internet choisis préalablement. Ces tests permettront de voir l efficacité des plugins sur les différentes spécifications que j aurais réalisées et ainsi déterminer leur utilité auprès d un webmaster ou d un internaute. 13

14 Références bibliographiques [1] A. Blais, Restructuration de pages web, projet de fin d étude, Ecole polytechnique de l université de Tours, département informatique, [2] B. Caldwell, M. Cooper, L. Guarino Reid, and G. Vanderheiden, Techniques for Web Content Accessibility Guidelines 2.0. Working Draft, avril [3] W. Chisholm, G. Vanderheiden, and I. Jacobs, Web Content Accessibility Guideline 1.0, WCAG 1.0, W3C Recommendation 5-May [4] S. Colas, Outils d amélioration de l accessibilité du web pour les personnes visuellement handicapées, thèse pour obtenir le grade de docteur de l université de tours, Université François Rabelais de Tours, Novembre [5] S. Colas, N. Monmarché, and M. Slimane, Correcteur automatique ou assistance au webmestre pour obtenir un web accessible, in Handicap 2008, Eds. Nadine Vigouroux et Philippe Gorce, Cépaduès éditions, ISBN , Cépaduès, ed., no. ISBN , France (Paris), juin 2008, pp