dess handi nouvelles technologies et handicaps … · les livres scolaires, dictionnaires, outils...
TRANSCRIPT
DESS HANDI Nouvelles Technologies et Handicaps
Sensori-moteurs
« Développement de l’interface VICKIE »
HUYNH Kim Chen Directeur de stage : Dominique ARCHAMBAULT Entreprise : Laboratoire INOVA Lieu du stage : Jussieu Coordonnateur: J. LOPEZ KRAHE Paris, Septembre 2005
2
Remerciements
Je tiens à remercier M. Dominique Archambault et Dominique Burger pour m’avoir accueilli pendant toute la durée de mon stage. Je remercie M. Archambault de m’avoir permis grâce à ce stage d’entrer dans le monde de la recherche pour l’intégration des personnes en situation de handicap visuel.
Je voudrais remercier toute l’équipe I.N.O.V.A. et de BrailleNet pour son accueil et sa
disponibilité. Et particulièrement Victor Moço pour ses conseils et son aide. Je voudrais également remercier Jaime Lopez-Krahé, le directeur du DESS Nouvelles
Technologies et Handicaps Sensoriels et Physiques.
3
Résumé
Depuis 2001, plusieurs partenaires européens participent ensemble à un projet de recherche visant à décrire, imaginer puis réaliser un ensemble d’outils facilitant l’intégration d’enfants déficients visuels en milieu scolaire. Cet ensemble constituant au final un équivalent numérique d’un cartable, comprenant de quoi communiquer, apprendre et travailler en groupe. L’idée originale de ce projet est donc de permettre l'intégration en milieu scolaire traditionnel d'un élève déficient visuel.
Dans le cadre de ce projet, de nombreux travaux ont été réalisés : des formats de transcription numérique de livres ou tous autres documents, un transcripteur de braille mathématiques permettant de faciliter l’accès aux mathématiques.
Etant arrivé à la fin du projet, mon stage, au sein du laboratoire INOVA et en collaboration avec l’association BrailleNet, a consisté à créer l’interface permettant aux enfants déficients visuels d’utiliser toutes les différentes possibilités proposées par VICKIE. Cette interface se doit d’être parfaitement compatible avec les différents environnements de la plateforme VICKIE, facile d’utilisation et tout à fait accessible aux personnes déficientes visuelles.
Mots-clés MOZILLA, XML, XUL, XSLT, XPCOM, DOM, BrailleNet, INOVA, Interface homme machine, Braille, VICKIE, déficients visuels, accessibilité, intégration, transcriptions, livre numérique, aide technique
4
Abstract
Since 2001, partners from European countries lead a project named VICKIE, which stands for Visual Impaired Children Kit Inclusive Education. The aim of this partnership is to create an environment making possible for a visually impaired child to go at mainstream school like everyone. Pupils/students will be able to access numerical documents (dictionaries, translator, mathematics work package, scholar books) thanks to the VICKIE platform.
Many research and works have already been done, making possible to translate mathematics document to Braille mathematics, to translate an original book to a numerical book with a standard format.
At the end of the VICKIE project, I have been integrated in the INOVA researcher’s team and able to collaborate with the BrailleNet association. My training course subject was to create the interface between visually impaired pupils/student, sight children/teacher and the VICKIE tools. The difficulty of this task was to make this interface compatible with each tool of the project using various languages (XML, XSLT, JAVASCRIPT, XUL, XPCOM) under the Mozilla development platform. It was also really important to develop this interface in order to make it easy to use and as accessible as possible for an assistive technology.
KeyWords MOZILLA, XML, XUL, XSLT, XPCOM, DOM, BrailleNet, INOVA, user interface, Braille, VICKIE, visually impaired children, accessibility, integrated, education, transcriptions, numerical books, assistive technology.
5
Table des matières Remerciements ........................................................................................................................... 2 Résumé ....................................................................................................................................... 3 Mots-clés .................................................................................................................................... 3 Abstract ...................................................................................................................................... 4 KeyWords................................................................................................................................... 4 Table des matières...................................................................................................................... 5 Introduction ................................................................................................................................ 7 1 Présentation du contexte de stage....................................................................................... 8
1.1 Laboratoire INOVA et Association BrailleNet .......................................................... 8 1.1.1 L’équipe INOVA................................................................................................ 8 1.1.2 Association BrailleNet ....................................................................................... 9 1.1.3 Leurs activités .................................................................................................. 10
1.2 Mon stage ................................................................................................................. 11 2 Projet VICKIE .................................................................................................................. 12
2.1 Description ............................................................................................................... 12 2.1.1 Objectifs ........................................................................................................... 13 2.1.2 Partenaires ........................................................................................................ 15 2.1.3 Fonctionnement ................................................................................................ 15
2.2 Travaux menés ......................................................................................................... 16 2.2.1 Serveur Hélène ................................................................................................. 16 2.2.2 Braille mathématique ....................................................................................... 18
3 Analyse des besoins ......................................................................................................... 19 3.1 Braille ....................................................................................................................... 19
3.1.1 Historique du braille......................................................................................... 19 3.1.2 Matériels utilisés .............................................................................................. 22
3.2 Population malvoyante............................................................................................. 22 3.2.1 Description ....................................................................................................... 22 3.2.2 Matériels pour la malvoyance .................................Erreur ! Signet non défini.
3.3 Accessibilité ............................................................................................................. 24 3.3.1 Accès au clavier ............................................................................................... 24 3.3.2 Multimedia ....................................................................................................... 27 3.3.3 Rôle de l’interface ............................................................................................ 28
4 Etat de l’art ....................................................................................................................... 30 4.1 Mozilla Framework .................................................................................................. 30
4.1.1 Avantages ......................................................................................................... 30 4.1.2 Inconvénients ................................................................................................... 31
4.2 XUL.......................................................................................................................... 32 4.2.1 Comment utiliser XUL comme interface graphique ........................................ 32 4.2.2 Les prérequis pour programmer en XUL ......................................................... 33 4.2.3 Création d’une application en XUL ................................................................. 33 4.2.4 Création d'un fichier XUL................................................................................ 36 4.2.5 Exemple............................................................................................................ 38
4.3 XML......................................................................................................................... 40 4.3.1 Règles lexicales et/ou syntaxiques ................................................................... 40
6
4.3.2 Document bien formé....................................................................................... 41 4.3.3 Document Valide.............................................................................................. 41 4.3.4 Affichage des données XML............................................................................ 42 4.3.5 Intérêt du XML et DAISY ............................................................................... 42 4.3.6 Exemple...................................................................Erreur ! Signet non défini.
4.4 Javascript et le Document Object Model ................................................................ 44 4.4.1 Définition du Javascript ................................................................................... 44 4.4.2 Description du DOM........................................................................................ 44
4.5 XPCOM.................................................................................................................... 44 4.6 XSLT........................................................................................................................ 46
5 Spécification..................................................................................................................... 47 5.1 Actions ..................................................................................................................... 47 5.2 Accessibilité ............................................................................................................. 47 5.3 Format d’entrée ........................................................................................................ 47 5.4 Format de sortie...............................................................Erreur ! Signet non défini. 5.5 IHM .......................................................................................................................... 48
6 Architecture...................................................................................................................... 52 6.1 Gestion des bureaux des utilisateurs ........................................................................ 53 6.2 Gestion des documents............................................................................................. 55 6.3 Navigation dans un document .................................................................................. 56
Conclusion................................................................................................................................ 58 Bibliographie............................................................................................................................ 59
7
Introduction
Le diplôme d’étude supérieur et de spécialité « Nouvelles technologies et handicaps physiques et sensoriels » (appelé aussi DESS. HANDI1) de l’université de Saint-Denis (Paris 8) est un diplôme pluridisciplinaire. Cette dernière année d’études permet de nous initier aux différents handicaps ainsi qu’à la conception d’aides techniques et/ou de logiciels adaptés dans le but de faciliter l’intégration de personnes en situation de handicaps physiques et sensoriels. Une des particularités de cette formation est la multidisciplinarité ; à savoir qu’elle regroupe des personnes de formations initiales différentes, partageant leurs connaissances afin d’aider des personnes en situation de handicap.
Dans le cadre de ce cursus, j’ai eu l’occasion de participer au projet VICKIE à travers mon stage de fin d’études en apportant mes compétences en informatique pour le développement d’une partie du projet. VICKIE est un projet européen de recherche ayant pour objectif final la création d’un ensemble d’outils constituant un cartable électronique pour les enfants/étudiants déficients visuels. Les livres scolaires, dictionnaires, outils pour la prise de notes sous forme numérique permettent l’intégration en milieu scolaire d’enfants utilisant des aides techniques tel qu’un terminal tablette braille ou une synthèse vocale. De plus, VICKIE offre aussi la possibilité aux enfants déficients visuels et aux professeurs et élèves voyants de travailler en collaboration. Le projet étant arrivé à son terme, il m’a été proposé comme sujet de stage d’analyser, spécifier puis développer l’interface graphique utilisée à la fois par les élèves / étudiants déficients visuels ou tout autre membre du système éducatif.
Je vais donc, dans la suite, décrire les différentes étapes de ma démarche, en passant par la description détaillée du projet VICKIE, l’analyse des besoins en terme d’accessibilité, d’actions proposées et de compatibilité avec les aides techniques. Puis nous aborderons l’état de l’art des différents langages et outils de développement nécessaire à la création de mon interface. Nous finirons ce document par les spécifications, l’architecture et le fonctionnement de celle-ci.
1http://ufr6.univ-paris8.fr/desshandi/index.php
8
1 Présentation du contexte de stage Vous trouverez dans ce chapitre une présentation générale du lieu où j’ai effectué mon
stage à savoir le laboratoire INOVA. J’ai aussi travaillé avec des membres de l’association BrailleNet, celle-ci collaborant de manière active avec INOVA.
1.1 Laboratoire INOVA et Association BrailleNet
1.1.1 L’équipe INOVA
Le sigle I.N.O.V.A. signifie Interfaces NOn Visuelles et Accessibilité. INOVA est un laboratoire de l’Université de Pierre et Marie Curie (UPMC i.e. Paris VI). Ce laboratoire fait partie de la cellule U 483 de l’Institut National de la Santé Et de la Recherche Médicale (I.N.S.E.R.M.). Il est dirigé par M. Dominique Burger et secondé par M. Dominique Archambault.
Comme son nom l’indique, le laboratoire I.N.O.V.A. travaille sur la recherche de nouvelles solutions au problème de l'insertion sociale et culturelle des personnes en situation de handicap visuel en se basant sur les nouvelles technologies de l'information et de la communication (NTIC). Leurs différentes actions consistent à créer ou adapter des logiciels ou interfaces à savoir la création ou l’adaptation de logiciels ou d’interface. L’équipe INOVA associée à BrailleNet est composée d’une douzaine de personnes travaillant sur divers projets que vous allez découvrir dans les sections suivantes.
Le laboratoire INOVA travaille en étroite collaboration avec l’association BrailleNet, dont Dominique Burger est le président. Je tiens à apporter des informations complémentaires dans la section suivante sur cette association pour l’aide qu’elle apporte dans l’intégration et l’accès à l’information des personnes en situation de handicap visuel.
9
1.1.2 Association BrailleNet
BrailleNet est une association de la loi de 1901. Elle a débuté en 1997 à la suite d’une réunion organisée au salon Autonomic96 à l'occasion du colloque sur les « Nouvelles Technologies dans l'Education des déficients visuels ». L’objectif principal de cette association est l’intégration sociale et culturelle des personnes en situation de handicap visuel. En effet, BrailleNet propose de nombreuses solutions qu’elle a regroupé selon quatre différents axes :
Internet à l’école BrailleNet soutient des établissements d’enseignement accueillant des jeunes
déficients visuels et souhaitant utiliser Internet dans leur projet pédagogique. Accès à la lecture BrailleNet développe en collaboration avec l’INRIA (Institut National de Recherche
en Informatique et en Automatique) une bibliothèque virtuelle d’ouvrages du domaine public, c’est à dire une bibliothèque contenant des livres numérisés (romans, théâtres, poésies…) pouvant être lus par des personnes aveugles à l’aide du terminal braille, i.e. le serveur Hélène.
BrailleNet travaille aussi en collaboration avec des éditeurs sur la possibilité de donner l’accès aux ouvrages protégés par les droits d’auteurs aux déficients visuels (grâce à un système d’authentification à l’accès).
. Accès au WEB BrailleNet participe au projet Web Accessibility Initiative (WAI une activité menée à
l'échelle mondiale dans le cadre du Consortium W3C), à savoir l’orientation de l'évolution des technologies liées à Internet dans le sens d'une meilleure accessibilité par les personnes handicapées visuels. Elle est associée à l'INRIA dans ce projet avec pour mission de formuler les besoins des utilisateurs handicapés visuels et de participer aux actions de sensibilisation. Elle diffuse des recommandations pour l’accessibilité des sites et les évalue.
Formations BrailleNet propose aux personnes en situation de handicap visuel des modules de
formations concernant les bases de l’Internet, la navigation et les outils de communications. Elle donne aussi la possibilité aux personnes travaillant pour des sites Internet de rendre accessible leurs sites. En plus de ces quatre axes d’activités, l’association BrailleNet participe et/ou fournit son aide dans différents projets que nous allons détailler ci-dessous.
10
1.1.3 Leurs activités Les activités d’INOVA et de BrailleNet sont très nombreuses. En effet, beaucoup de
projets ont vu le jour depuis 1993. Je vais juste vous donner une liste non exhaustive de leurs projets en cours, ainsi que d’autres qui me semblent importants. Cette liste est tirée de leurs sites Internet.
Projet EUAIN (EUropean Accessible Information Network 2004-2007) L’objectif est de promouvoir l’insertion dans la société d’information, en créant un
réseau Européen pour l’accessibilité de l’information afin d’encourager les différents acteurs et industriels de l’édition à avancer en commun vers des objectifs concernant la fourniture d’information accessible pour les personnes n’ayant pas accès aux documents imprimés. Projet soutenu par le Sixième Programme Cadre pour la Recherche et le Développement de la Commission Européenne. (Coordonné par BrailleNet)
Projet Support-EAM (Supporting the creation of an e-Accessibility Quality Mark 2004-2006)
L’objectif est de créer un label de qualité d’accessibilité pour les services Internet, dans le cadre du Plan d’Action Européen de 2005 faisant référence à la Résolution du Conseil de l’Europe sur l’accessibilité numérique pour améliorer l’accès à la Société de la Connaissance pour les personnes souffrants d’un handicap. C’est-à-dire l’harmonisation des méthodologies d’évaluation de l’accessibilité du Web selon les recommandations du W3C/WAI. (Coordonnée par BrailleNet)
Projet ADELA (ADministration ELectronique Acessible 2004-2005) Ce projet a pour objectif de participer au développement d’une e-administration et de
e-services accessible aux personnes en situation de handicap. Il étudie les moyens et les conditions d’accès aux informations électroniques. Projet soutenu par le Ministère de l’Education Nationale de l’Enseignement Supérieur et de la Recherche. (Coordonné par BrailleNet)
Le projet ETAPE (2001-2002)
Le projet vise à étendre au public des jeunes handicapés visuels les expériences et les applications mises en place actuellement autour du concept de " cartable électronique ". En effet, l’accessibilité de ces nouveaux supports représente un enjeu important pour l’intégration sociale et culturelle des personnes handicapées visuelles, à commencer par l’école et l’université. L’objectif de ce projet est de faire la démonstration concrète de ce potentiel en mettant en place un service réel dans 5 établissements d’enseignements pilotes durant une année scolaire complète, de septembre 2001 à juin 2002. Ce service concernera - dans un premier temps - 30 élèves ou étudiants handicapés visuels.
Projet TIM (Tactile Interactive Multimédia 2001- 2003)
Projet ayant pour but de fournir des jeux informatiques utilisables de façon autonome par des enfants handicapés visuels. Ces jeux doivent être adaptables à l’enfant, quelque que soit le type d’interface qu’il utilise (planche tactile, afficheur braille, synthèse vocale, ou écran). (D. Archambault dirige ce projet).
11
• Projet Vickie (Visual Impaired Children Kit of Inclusive Education 2001-2005) : L’objectif est la création d’un environnement technologique pour favoriser
l’intégration scolaire d’enfants déficients visuels en milieu ordinaire. Ce projet doit être l’occasion de développer de nouveaux schémas de diffusion des ouvrages adaptés, en partenariat avec les éditeurs. (Coordonné par D. Archambault).
Pour des informations complémentaires sur les laboratoires INOVA et BrailleNet, vous les trouverez sur les sites Internet suivantes :
• http://www.snv.jussieu.fr/inova/.: site du laboratoire INOVA • http://www.braillenet.org : site de l’association BrailleNet. • http://www.voirplus.net : c’est un portail contenant les sites qui traitent
du handicap visuel. I.NO.V.A. est partenaire de voir+.
1.2 Mon stage Mon stage (dont vous trouverez la proposition dans la suite) est en rapport avec le projet VICKIE, c’est pourquoi nous allons revenir un peu plus longuement sur ce projet.
Stage Proposal Within the framework of the European project VICKIE (Visually Impaired Children Kit for Inclusive Education), We intend to develop software tools to help inclusive education of blind pupils or students. Various applications were designed like a server for adapted documents, adapting tools, conversions tools for transcribers, a specific document reader and mathematical conversion tools. The work proposed in this stage consists in developing content services for the user: from at least 1 existing school manual that will be provided in XML by the publisher, it will be necessary to convert it into an accessible format, and to design the enduser interface. The end-user interface will be designed in the Mozilla framework. The main languages are XUL (extension of XHTML to develop Mozilla application interfaces) and Javascript. Prerequisite: � basic knowledge of XML � good programming skills � digital accessibility The work language is French but a report in English will be asked to be included in the Project documentation (for the European Commission). Additionally, if there would be enough time, a school manual in English might be developed as well.
12
2 Projet VICKIE
Pour commencer, VICKIE est le sigle pour : « Visual Impaired Children Kit for
Inclusive Education », à savoir la création d’un environnement d’apprentissage pour l’intégration en milieu scolaire des enfants non voyants ou malvoyants. Le projet VICKIE est un projet Européen s’incluant dans le programme IST (Information Society Technologies2) selon la décision du Parlement Européen et du Conseil du 22 décembre 1988. Il a débuté en octobre 2001 pour une durée de 3 ans et fait partie du mouvement mené par la Communauté Européenne pour l’intégration. L'un des partenaires du projet ayant du abandonner le projet en cours de route, le projet a été prolongé jusqu'en septembre 2005.
L’insertion sociale et culturelle est une étape primordiale pour les personnes en situation de handicap notamment le handicap visuel. Certains pays de la Communauté Européenne ont déjà comme politique, pour les enfants déficients visuels, l’intégration scolaire en milieu ordinaire, c’est le cas de l’Italie et de la Suède. En ce qui concerne la France, le gouvernement encourage de plus en plus l’insertion des enfants en situation de handicap visuel vers une scolarité ordinaire.
De ce fait, la Communauté Européenne souhaite que ses membres suivent tous la même orientation.
2.1 Description L’enjeu du projet VICKIE est de fournir un environnement technologique facilitant
l'insertion d’étudiants déficients visuels dans l'éducation traditionnelle. En effet, un ordinateur constitue un formidable outil pour ces derniers qui, grâce à un terminal braille, peuvent accéder à toutes sortes d’informations. VICKIE a été pensé selon le principe du cartable électronique, c’est à dire un système permettant d’avoir le contenu d’un cartable « ordinaire » à savoir des livres, des cahiers, un dictionnaire, etc…
Nous verrons, dans cette partie, les divers objectifs du projet VICKIE, ainsi que les partenaires et le fonctionnement de ce dernier.
2 http://www.cordis.lu/ist/
13
2.1.1 Objectifs Comme nous l’avons vu précédemment, l’objectif principal du projet VICKIE est de développer un outil modulable qui inclut tous les dispositifs pour l'intégration d'enfants déficients visuels dans une salle de classe ordinaire. Ce logiciel doit être adapté. Son utilisation doit être simple et rapide pour que les enfants aveugles puissent s’en servir de manière autonome. Il projette aussi de manipuler tous les aspects nécessaires pour faciliter l’insertion scolaire :
o Ecrire des leçons et des exercices· o Accéder aux documents (livres scolaires, dictionnaires, contenus des sites
Internet). o Lien avec les centres de ressources pour l’aide au projet éducatif.
Les objectifs du projet VICKIE sont nombreux, pour cela nous les avons rassemblé
dans trois différents axes décrits ci-dessous :
2.1.1.1 Outils pour adapter des documents VICKIE souhaite développer des outils pour faciliter la création et/ou l’adaptation de
documents électroniques accessibles pour les étudiants et enfants déficients visuels. Ces outils sont regroupés ci-après :
Choix et conception d’un format de stockage (contenant toutes les informations) permettant d’accéder aux documents de différentes manières.
Adaptation du Serveur Hélène vers ce type de format de stockage et d’extension du serveur pour les besoins de VICKIE (traduit en plusieurs langues et accessible depuis Internet).
Développement de la production d’outils permettant de créer des documents avec ce type de format.
Développement d’outils de conversion pour générer des documents sous ce format provenant des fichiers des éditeurs.
Développement des outils de conversion pour produire des documents appropriés pouvant être lus par les enfants et étudiants déficients visuels selon les différentes manières d’accéder à ce document (lecture en ligne, braille ou gros caractères papiers).
2.1.1.2 Plateforme Web La plateforme Web, elle, se trouve sous 2 différents aspects :
Le premier étant la livraison sécurisée de documents par l’intermédiaire de la plateforme WEB : pour cela, il faut spécifier le protocole de livraisons sécurisées de documents et en implémenter une démonstration.
Le second étant de faire l’état de l’art des plateformes Web existante et utilisée dans les environnements scolaires afin de vérifier leur compatibilité avec le schéma du fonctionnement de VICKIE :
14
pour cela, il faut étudier les différents portails web existants dans l’éducation traditionnelle et en choisir un,
Spécifier les taches nécessaires pour rendre les outils VICKIE facilement utilisable et bien sûr vérifier leurs accessibilités pour les personnes déficientes visuelles,
Faire un prototype de ces outils, Etablir une communication avec les utilisateurs afin de perfectionner
l’accessibilité et l’ergonomie de ces outils.
2.1.1.3 Environnement des élèves et étudiants déficients visuels.
L’objectif global de cette plateforme de travail est de fournir un logiciel simple d’utilisation pour accéder, lire et créer des documents. Pour cela, deux plateformes ont été considérées :
La première utilisant un ordinateur de bureau, une plage braille et une synthèse vocale. Pour le travail sur l’interface, le désistement après une année du partenaire devant créer cette partie du logiciel a créé un énorme manque pour le consortium, spécifiquement du fait que le matériel utilisé jusque là n’était pas approprié au développement de cette partie. Nous avons donc dû repenser l’architecture du logiciel, pour cela nous avons :
Développé une interface basée sur la plateforme Mozilla Etendu la bibliothèque libbraille (librairie d’interfaçage avec les terminaux
braille) ainsi que développé un composant XPCOM de Mozilla permettant l’utilisation cette librairie
Développé un transcripteur pour le braille mathématique. Rappel : Les deux derniers items (libbraille et maths) ont été développés pour être des librairies de développement pouvant aussi être utilisées indépendamment du projet VICKIE.
La deuxième étant une plateforme Braille autonome. Le but ici est de démontrer qu’il est possible d’utiliser le principe de VICKIE sur une plateforme braille autonome existante comme celle développée par notre partenaire industriel ; EuroBraille. (« Iris » pour prise de note braille)
Comme nous venons de le dire, un partenaire s’est désisté laissant ainsi le travail sur l’interface pour les enfants déficients visuels aux mains du laboratoire INOVA. C’est dans ce contexte et pour pallier à ce désistement que le sujet de mon stage était composé de l’analyse, des spécifications et du développement de cette interface.
15
2.1.2 Partenaires Dans cette partie, nous vous présentons la liste des différents participants européens au
projet VICKIE ainsi que leur site permettant d’accéder directement à de plus amples informations :
• L’Université Pierre et Marie Curie (UPMC): représentée par l’équipe I.N.O.V.A. qui coordonne le projet et devra développer les services.
• Centro di Recerca, Sviluppo e Studi Superiori in Sardegna (CRS4) : qui s’occupe de l’interface « général », celle qui propose les services.
• La librairie nationale pour les aveugles Regina Margherita à Monza (BRM): définit les besoins des utilisateurs.
• L’association BrailleNet (BNET): aide la librairie Regina Margherita dans la définition des besoins. Puis avec leurs « collaborateurs » (association de parents d’enfants mal ou non voyants, des écoles), ils évalueront les prototypes.
• L’école Saint Joseph (Ireland) : définit les besoins des utilisateurs. • Eurobraille : a rejoint l’équipe le 2 janvier 2003 et est partenaire commercial.
2.1.3 Fonctionnement Nous allons maintenant décrire les principes qui permettraient à un enfant déficient
visuel d’étudier dans des conditions normales grâce à VICKIE.
Figure 2-2-1 : Schéma du fonctionnement du projet VICKIE
Sur ce schéma, nous pouvons voir la collaboration dans une classe entre un professeur
voyant et deux élèves dont un est non-voyant (utilisant un terminal braille). L’élément
16
principal de ce schéma est l’ordinateur en réseau qui contient une base de données de l’école et bien sûr VICKIE. Celui-ci permet à ces trois participants d’accéder à différents services :
• Accès à Internet : pour les échanges et les communications par le courrier électronique ou pour accéder au Serveur Hélène…
• Services fournis par l’école : les documents que les professeurs auront mis sous format électronique.
• Librairie numérique : livre scolaire, dictionnaire…
Le modèle de la figure 2-1 nous montre qu’un élève voyant peut soit utiliser un manuel scolaire ordinaire papier, soit le même livre sous format numérique grâce à un ordinateur. Pour l’élève non-voyant, le système informatique est primordial. En effet, à l’aide d’un terminal braille relié à un ordinateur, l’enfant non voyant peut grâce à VICKIE accéder à l’ensemble des outils scolaires, lui permettant ainsi d’évoluer comme n’importe quel autre enfant i.e. :
• Un traitement de texte pour prendre des notes • Les documents fournis par le professeur • Les manuels scolaires • Des dictionnaires • Des services Internet.
Le professeur, quant à lui, peut voir l’évolution du travail de l’élève non-voyant sur un
écran d’ordinateur. Un tel système permet aux deux élèves d’accéder à des outils équivalents et ils
peuvent ainsi travailler ensemble grâce à VICKIE. Le professeur, lui, peut conseiller, aider ou corriger le travail des deux élèves puisqu’il les voit évoluer en temps réel ou presque (pas le cas pour les mathématiques par exemple).
2.2 Travaux menés
Le premier travail fut de créer une librairie et un format pour les documents tels que les manuels scolaires, les dictionnaires, les livres …Cette bibliothèque a ensuite donné lieu à la création du serveur Hélène avec beaucoup plus de perspectives. Nous allons donc faire une brève présentation du serveur Hélène développé par BrailleNet et d’un autre travail réalisé.
2.2.1 Serveur Hélène
Le serveur Hélène est un serveur sécurisé de documents français (ouvrages scolaires ou non, cours universitaires, documentations techniques…), ayant leur utilisation limitée au réseau d'écoles intégrant des handicapés visuels, institutions spécialisées et associations spécialisées partenaires de BrailleNet. Ils peuvent les utiliser pour une impression Braille ou en gros caractères en les téléchargeant au préalable sur le site http://www.serveur-helene.org. Son accès étant sécurisé, les personnes peuvent seulement y accéder grâce à un mot de passe
17
individuel. Ce serveur est alimenté par des éditeurs et des centres spécialisés (associations, écoles) qui réalisent des adaptations en braille et en gros caractères. Pour le projet VICKIE, une « extension » du serveur a été produite. Celle-ci possède des documents en Italien et en Anglais fournit par nos partenaires. Ces documents nous permettent de faire différents tests.
Un des points essentiels du serveur Hélène est de s’adapter aux différents formats utilisés par les maisons d’éditions ou les centres spécialisés afin de les distribuer ensuite sous un format accessible aux personnes en situation de handicap ou pour être lu par les différentes aides techniques (tablette Braille, synthèse vocale). Le schéma suivant récapitule le fonctionnement de transcription par le serveur Hélène des différents ouvrages et documents.
Ce schéma nous montre que le format, qui va permettre la transformation d’un document quelconque et non adapté vers des documents accessibles pour les personnes en situation de handicap à travers leurs aides techniques, est le DAISY DTBook décrit dans la suite.
Fichiers préparés pour l’impression Braille
Formats éditeurs
Fichiers RTF
XML upCastXML fourni par les éditeurs
DTbook XML
XHTML plusieurs fichiers
Impression Braille
XHTMLZ36.86 Texte
Figure 2-2 : Schéma des différents formats de la récupération de documents jusqu'à leur diffusion
18
2.2.2 Braille mathématique En règle général, une transcription est une réécriture d’une version à une autre version,
d’une langue à une autre.
2.2.2.1 Exemples Dans le cadre du projet VICKIE, un transcripteur de Braille mathématiques a été crée.
En effet, après concertation avec les membres du groupe International pour l’accessibilité universelle des mathématiques, le transcripteur développé au sein du projet VICKIE fut inclut dans la libraire « Universal Maths Conversion Library ». Cette librairie basée sur de nombreux modules d’entrées et de sorties indépendants suivant une API public. Les différents membres du groupe travaillant sur des transcripteur de leur Braille national vers le MathML ou l’inverse. Après avoir présenté rapidement le projet VICKIE ainsi que son déroulement, je vais entrer dans les parties qui concernent plus spécifiquement l’interface que je dois développer. En commençant bien sûre par les attentes, besoins et obligations que notre interface se doit de remplir.
Document électronique
Synthèse Vocale Terminal braille
Alphabet Braille Braille Mathématique
Codification Braille
logiciel
19
3 Analyse des besoins
Mon travail s’est focalisé sur la création d’une interface adaptée aux besoins d’une certaine population. Celle-ci étant les enfants déficients visuels, je me suis donc intéressée aux différents aspects de cette déficience. Cette dernière étant très complexe, nous n’allons pas nous attarder dessus mais simplement donner quelques définitions de chacune d’entre-elles : à savoir la cécité et la malvoyance, détailler les adaptations nécessaires.
3.1 Braille Par définition, le terme cécité (du mot latin «caecus») signifie aveugle. La cécité est
donc «l´état d´une personne aveugle». L´aveugle, au sens strict, est celui qui est privé de ses yeux, celui qui est privé de la vue. Dans le sens réglementaire français, la cécité commence dès que l´acuité devient inférieure à 1/20.
Pour cette déficience, l’accès aux informations visuelles n’est pas possible. Ce handicap très invalidant n’empêche cependant pas un enfant d’apprendre à lire et écrire. L’accès au texte se faisant par un autre sens que la vue, le toucher. En effet, le braille maintenant largement utilisé a permis de simplifier l’accès aux informations pour les personnes déficientes visuelles. Je vais donc faire un petit récapitulatif sur le braille, son histoire ainsi que les matériaux permettant de faciliter la lecture et l’écriture en braille.
3.1.1 Historique du braille Nous commencerons par donner un bref historique du procédé braille. Celui-ci a été
inventé par Louis Braille en 1829. Ce dernier est né le 4 janvier 1809 à Coupvray, en Seine et Marne. A l’âge de trois ans, jouant dans l'atelier familial, le jeune Louis se blesse à l'œil. L'infection qui suit gagne l'autre oeil et 1 an plus tard c'est la cécité. A l’âge de 5 ans, Braille est définitivement aveugle. En 1819, Louis Braille fût admis à l'école pour aveugle fondée par Valentin Haüy et cette année-là le capitaine d'artillerie Charles Barbier de la Serre présente aux aveugles sa "Sonographie" ou "Écriture nocturne" qui permet aux militaires de tracer et de lire des messages dans l'obscurité. Il s'agit d'un système phonétique d'écriture en points saillants : c’est à dire deux matrices de 6 lignes et 6 colonnes pour représenter les lettres de l’alphabet et certains sons usuels. Louis Braille a alors 12 ans et n'est pas satisfait : trop de points, absence d'orthographe, aucun accent, aucune ponctuation, pas de signes pour les mathématiques et la musique. Il propose alors, à l'age de 15 ans, un code alphabétique, construit d'une manière moins complexe à partir d’une matrice de 6 points en relief. Cette méthode « s’écrit » en formant des bosses sur un papier très épais à l’aide d’un poinçon. En 1826, Louis devient professeur à l'institution royale des aveugles. Ses élèves accueillent alors cette invention avec enthousiasme. Ils adoptent le Braille car ils en vérifient immédiatement la supériorité sur le système classique de représentation en relief des lettres ordinaires. En 1829, Louis Braille publie un opuscule pour expliquer son écriture : 64 combinaisons donnant toutes les lettres de l'alphabet, les voyelles accentuées, les chiffres, la ponctuation, la notation
20
mathématique et musicale. En 1836, il effectua sa première transcription. Louis braille atteint de tuberculose mourût en 1852.
Le caractère braille
Le braille est modélisé par une matrice de trois lignes et de deux colonnes comme un
jeu de dominos.
Chaque élément de cette matrice peut être soit formé de bosses, soit lisse. Prenons par exemple, la représentation de la lettre A : Nous remarquons que seul le point 1 est formé. Ce codage permet d’alléger l’apprentissage de l’alphabet : en effet, le caractère est symbolisé par une suite de 6 chiffres. Pour apprendre l’alphabet, il suffit juste de mémoriser le (1, , , , , ) pour la lettre A, (1,2, , , , ) pour A et ainsi de suite… Pour vous donner une idée de ce qu’est l’alphabet en braille, nous vous invitons à regarder la figure 3-1 située ci-dessous.
Figure 3-1 : L’alphabet braille
21
Cette méthode permet aux personnes non voyantes de comprendre et d’appréhender
plus facilement un texte ainsi que des expressions mathématiques. Cependant, ce système produit des documents assez volumineux. Ce codage à 6 points est une invention formidable, cependant, celle-ci reste limitée du fait qu’elle permet seulement 64 combinaisons. Depuis l'arrivée de l'outil informatique, le braille a dû suivre une certaine évolution afin d’augmenter le nombre de caractères. Un codage possédant huit points a donc été créé afin de coder tous les caractères possibles et de limiter la taille des documents braille (la taille des plages tactiles des terminaux brailles étant très limitée).
La plupart des outils tels que les terminaux braille utilisent le braille à 8 points. De ce fait, je vais vous donner une brève explication sur ce codage. Braille à 8 points
Le braille à 8 points est représenté d’une manière très simple. Pour ce faire, il suffit de garder la notation du braille classique et de lui rajouter 2 points comme présenté ci-dessous.
Cet ajout permet ainsi de multiplier les possibilités de représentation par 4. On arrive donc précisément aux 256 caractères disponibles sur les équipements informatiques. On peut affecter une combinaison unique à chacun des caractères pouvant constituer un texte littéraire ou des caractères informatiques.
Prenons par exemple, les signes de parenthèses et celui de l’addition ont une particularité qui est l’ajout des points 7 et 8. Pour écrire les majuscules, on rajoute à l’alphabet classique le point 7. Cette table peut varier d’une personne à une autre. En effet, certaines personnes souhaitent personnaliser le codage de caractères pour des besoins d’utilisations importantes ou pour faciliter :
la mémorisation la lecture l’écriture.
22
Après quelques explications sur le braille, nous allons donner un bref aperçu des outils nécessaires pour la lecture et l’écriture.
3.1.2 Matériels utilisés Pour l’étude des matériels utilisés par des personnes déficientes visuelles, je voulais
juste donner un exemple de matériel : le BrailleNote.
C’est un terminal standard qui permet la lecture et l’écriture pour la prise de notes possédant 32 caractères.
3.2 Population malvoyante
La population des personnes en situation de handicap visuel est largement constituée de personnes malvoyantes, ceci en raison de la population vieillissante et du nombre de maladie invalidante au niveau des yeux.
3.2.1 Description Le mot malvoyant a été créé en 1960 pour désigner, nous dit le Petit Robert, «la
personne dont l'acuité visuelle est diminuée». Le substantif malvoyance a été créé récemment et recouvre une grande diversité de cas qu'on a classifiés en trois catégories à partir des expériences suivantes: si vous présentez des photos à des malvoyants, il y aura différents résultats : «Il y a les personnes qui voient la photo toute floue, à des degrés divers, comme s'il y avait un épais brouillard; celles qui ne voient que le centre de la photo, le contour restant dans le noir; et celles qui ont un gros point noir au centre de la photo et ne voient qu'en périphérie. (...) On emploie les termes de vision périphérique ou centrale. C'est en général la rétine qui a des ratés , certaines parties étant plus détériorées que d'autres» (passage tiré du livre de Monique Bélanger et Hervé Rutkowski, Un malvoyant ouvre les yeux d'une voyante, Illustration de BVD, Préface de Claude Foucher, v.-p. de RETINA FRANCE, L'Harmattan 2002, Paris).
Les picots permettant la lecture
Les touches permettant la prise de notes
23
La déficience visuelle ne peut être appréhendée globalement. D'une faible altération de la vue à l'absence totale de perception, il existe une multitude de nuances, qui présentent des caractéristiques et recouvrent des handicaps très différents. L'œil est un organe délicat, très perfectionné, par lequel nous arrive la majeure partie des informations que nous utilisons. Un rayon lumineux qui rencontre l'œil va successivement traverser :
• La cornée ; • L'humeur aqueuse ; • Le cristallin, diaphragmé par l'iris ; • Le corps vitré.
Il aboutit, ensuite, sur la rétine, dont les cellules vont le transformer en influx nerveux, transporté jusqu'au cerveau par le nerf optique. Chacun de ces éléments peut être cause de déficience visuelle à la suite de maladie, dégénérescence, malformation ou traumatisme.
La cornée peut être altérée par projection de corps solides (éclats métalliques notamment), coups, brûlures... Elle perd de toute façon de sa transparence avec l'âge.
Une pression trop forte de l'humeur aqueuse est la cause du glaucome, qui entraîne une dégénérescence du nerf optique.
Le cristallin, avec l'âge, peut devenir opaque ; c'est la cataracte, qui, heureusement, s'opère couramment de nos jours.
Le corps vitré a tendance à se rétracter avec l'âge, entraînant parfois un décollement de la rétine. Celle-ci peut être atteinte de diverses maladies : la dégénérescence maculaire liée à l'âge (DMLA), la rétinopathie diabétique, la rétinite pigmentaire …A chaque altération d'un de ces éléments vont correspondre un ou plusieurs types de déficience visuelle.
24
A part les loupes pour la lecture sur l’écran d’un ordinateur, il existe d’autres moyens de rendre l’affichage plus accessible. C’est pourquoi, je me suis intéressée à l’accessibilité des logiciels.
3.3 Accessibilité
Comme nous l’avons vu précédemment, les différentes déficiences visuelles nous entraînent à analyser quelques points essentiels du point de vue de l’accessibilité de l’interface. De plus, nous ne pouvons imaginer restreindre notre travail sur l’accessibilité à un seul type de handicap. En effet, une personne déficient visuel peut aussi avoir des problèmes de mobilité et donc avoir comme interface d’accès n’importe quel matériel (contacteur, un pointeur …)
3.3.1 Accès au clavier
Dans de nombreux handicaps, l’utilisation de la souris est impossible :
Une personne non voyante utilise sa tablette braille pour naviguer entre les différents éléments d’une application grâce aux informations retournées par leur plage braille ou leur synthèse vocale.
Une personne souffrant d’un handicap moteur n’arrive pas à diriger simplement la souris ou n’arrive même pas à mouvoir sa main de manière précise. Dans ces cas, l’utilisation des raccourcis clavier est essentielle pour la navigation dans l’écran.
Toute personne peut gagner un temps considérable, en accédant à une action par une simple combinaison de touches. En lieu et place d’un accès répétitif à la souris.
Au final, une interface accessible doit permettre d’accéder à toutes les commandes
d’une application par des raccourcis clavier. Ceux là ne doivent pas rentrer en concurrence avec les raccourcis clavier du système d’exploitation. En effet, la combinaison Ctrl +Tab permet par exemple de passer d’une fenêtre à une autre, il serait peu pratique de redéfinir ce raccourci entraînant ainsi deux actions, la première venant du système d’exploitation et la seconde provenant de notre application.
J’ai fait un récapitulatif non exhaustif des raccourcis clavier classés en deux catégories : les raccourcis clavier du système d’exploitation que notre application ne devra surtout pas réutiliser et les raccourcis standards employés en général dans de nombreuses applications et que les utilisateurs connaissent par cœur.
25
Raccourcis claviers du système d’exploitation
CTRL + ECHAP Affiche le menu démarrer
CTRL + ALT + SUPPR Bien connu de tout le monde, permet de forcer la fermeture d'un programme récalcitrant
ALT + ESPACE Affiche le menu contextuel pour la fenêtre active ALT + TAB Passe d'une fenêtre à l'autre, dans l'ordre d'ouverture ALT + SHIFT + TAB Même chose que alt + tab mais dans le sens inverse MAJ DROITE + DE 8 SECONDES
Activer ou désactiver les touches filtres
ALT + MAJ GAUCHE + VERR.NUM
Activer ou désactiver les touches souris
ALT + MAJ GAUCHE + IMPR.ECRAN
Activer ou désactiver le contraste élevé
MAJ GAUCHE 5 FOIS Activer ou désactiver les touches rémanentes
VERR.NUM PENDANT 5 SECONDES
Activer ou désactiver les touches bascules
26
Raccourcis claviers standard :
CTRL + A Sélectionne tout le document en cours CTRL + C copier .CTRL + F . Recherche dans le document
CTRL + N Crée un nouveau document
CTRL + O Ouvre un document existant
CTRL + P : Imprime le document en cours
CTRL + S Enregistre le document en cours
CTRL + V Coller CTRL + X Couper CTRL + Z Annuler CTRL + F4: Ferme le document en cours
CTRL + F6 Permet de basculer d'une fenêtre à une autre à l’intérieur d’une même application
CTRL + DROITE Ramène le point d'insertion au début du mot suivant CTRL + GAUCHE Ramène le point d'insertion au début du mot précédent CTRL + BAS Ramène le point d'insertion au début du paragraphe suivant CTRL + HAUT Ramene le point d'insertion au début du paragraphe précédent CTRL + SHIFT AVEC UNE DIRECTION
Mettre en surbrillance un bloc de texte
CTRL + MOLETTE = CTRL ++ CTRL +-
Augmente ou diminue la taille de la police à l'écran
ALT + F4 Ferme l'élément actif ou quitter le programme actif SHIFT + UNE DIRECTION
Sélectionne plusieurs éléments d'une fenêtre ou du bureau ou sélectionner du texte dans un document
F1 Affiche l'aide F3 Recherche un fichier ou un dossier F6 Parcourt les éléments d'écran d'une fenêtre ou du bureau F11 Bascule en mode plein écran ALT + GAUCHE Page précédente ALT + DROITE Page suivante
27
3.3.2 Multimedia
Un des points les plus importants est le retour d’information. En effet, quand on utilise les raccourcis clavier, il est essentiel de savoir où se trouve la focalisation dans l’application. Cela passe par la modification de la forme de la souris ou par des informations textuelles. Les retours doivent aussi être sonores dans le cas d’un handicap visuel. En conclusion, l’utilisateur doit avoir le choix du retour dont il a besoin que cela soit visuel, sonore ou les deux.
Un autre point bien connu est la nécessité de fournir pour chaque élément visuel ou multimédia une alternative textuelle. Un exemple étant la commande ALT définie dans le HTML. L’information de ALT étant utilisée soit par la synthèse vocale soit par la plage braille pour être fournie aux personnes mal ou non-voyantes.
Les couleurs et les contrastes sont essentiels pour une personne malvoyante.
Cependant, l’information ne doit pas être fournie seulement par la couleur, celle-ci étant souvent mal reconnue. Une interface doit obligatoirement fournir à l’utilisateur la possibilité de choisir les couleurs du fond et du texte afin de respecter ou de fournir des forts contrastes. Le texte doit aussi être paramétrable, un bon exemple est celui de Mozilla, qui fournit à l’utilisateur les raccourcis clavier ctrl ++ et Ctrl – pour modifier la taille de la police de texte.
En conclusion, l’interface devra être accessible et pour cela il sera essentiel de la vérifier en utilisant les outils tels que :
• JAWS : (Job Access With Speech) un logiciel qui utilise une synthèse vocale intégrée et la carte son afin de faire entendre le contenu de l'écran sur les hauts-parleurs. Il envoie aussi l'information aux afficheurs braille. Cette technologie offre donc un accès à une grande variété d'applications, d'informations, d'éducation et de bureau.
• La barre d'outil « Web Accessibility Toolbar » a été développée par l'équipe de Accessible Information Solutions du Service national de l'information et des bibliothèques de l'Australie. Le logiciel contient une gamme d'outils:
o Pour examiner les aspects spécifiques (structure/code/contenu) d'un document HTML;
o Pour faciliter l'utilisation des applications de tiers; o Pour simuler l'expérience de différents utilisateurs;
o Ainsi qu'une gamme de références et de ressources additionnelles.
Cette barre d’outil me permettra de vérifier les contrastes des couleurs utilisées et la bonne accessibilité de mon interface.
Après avoir décrit les différents points à respecter au niveau de l’accessibilité, nous
allons nous intéresser à celui de notre logiciel.
28
3.3.3 Rôle de l’interface
Les enfants déficients visuels intégrés dans une classe vont pouvoir, avec leurs ordinateurs, travailler comme les autres sur les manuels scolaires ou livres à étudier. L’interface qu’il m’a été proposée de faire doit permettre à un enfant aveugle ou malvoyant de lire et au professeur de suivre l’évolution de l’élève. Les livres pourront être téléchargés à partir du serveur HELENE ou être n’importe quel document numérique.
Mon but est donc de créer l’interface qui permettra à l’élève non voyant d’accéder aux différents services proposés par VICKIE mais aussi au professeur à visualiser ces actions afin de vérifier son travail.
Sur le schéma de départ, j’ai mis en exergue (flèche rouge) où se situe l’interface que je dois développer.
Afin de rendre l’interface indépendante de l’ordinateur, les ordinateurs pouvant être
utilisé par plusieurs élèves, nous avons définis le concept de « Bureau » virtuel où l’enfant pourra retrouver ces documents et ces choix. Ce bureau sera l’élément principal de l’interface, permettant à l’élève de le gérer virtuellement, il pourra :
• Ouvrir un document numérique dans le bureau • Conserver une liste de documents déjà ouverts par le biais du bureau de l’élève • Mettre à jour cette liste (suppression, ajout, …) • Accéder au sommaire (de façon plus ou moins développé) d’un document ouvert • Lire le contenu avec une grande facilité pour passer de chapitre en chapitre, de page en
page mais aussi se diriger directement vers une page.
L’interface de VICKIE
Figure 3-1 : schéma de fonctionnement de VICKIE sur lequel j’ai situé mon interface
29
• Ajouter un commentaire personnel ou un post-it de mémorisation • Quitter rapidement
Les besoins principaux de cette interface sont donc de rendre chacune des actions définies ci-dessus faciles d’accès d’un point de vue ergonomique pour un enfant déficient visuel.
30
4 Etat de l’art Dans mon stage, il m’a été demandé avant tout, de faire des recherches sur
l’environnement de travail : Mozilla. Par la suite j’ai du m’initier aux différents langages sur lesquels devaient se baser mon interface tel que le XUL, XML, etc., dont je vais faire ci-dessous une brève description.
4.1 Mozilla Framework
Mozilla est un ensemble de logiciels libres multi-plateformes destinés à Internet. Il est composé d'un navigateur Web, un gestionnaire de courrier électronique, un éditeur HTML (Mozilla Composer) et un client IRC (Internet Relay Chat ChatZilla).
Mozilla a commencé en mars 1998 avec pour objectif le développement d’un navigateur respectant les standards web, performant, sécurisé et offrant de multiples fonctionnalités (la navigation par onglets, le bloquer de fenêtre pop-up, etc.). Au-delà de son but initial, Mozilla est devenu en fait, une véritable plateforme pour développer des applications pouvant s’installer localement ou s’exécuter à distance via Internet et fonctionnant également sur la plupart des systèmes d'exploitations.
Comme notre travail se base essentiellement sur cette plateforme, nous allons vous énumérer quelques uns de ces avantages mais également ces inconvénients.
4.1.1 Avantages Mozilla est un outil très puissant puisqu’il permet des développements d’applications
multi-plateformes. En effet, il est important pour une interface, dédiée à un grand nombre, de fonctionner sur n’importe quels systèmes d’exploitation (Windows, Unix, MacOs…). Ceux ci grâce aux composants XPCOM, un modèle composant multi-plateforme, qui permet des liaisons/communications entre différents langages et des descriptions IDL (Interface Definition Language). Ainsi, on peut récupérer des fonctionnalités des différents composants et les relier pour créer notre application. Il permet également des développements indépendants de la plateforme puisqu’il est multi-plateforme.
Les langages utilisés dans les applications Mozilla sont pour la plupart des standards recommandés par le W3C. Ce sont des langages utilisés un peu partout. Ils ne sont pas spécifiques à Mozilla. Voici une liste non exhaustive de ces langages et ces technologies qui sont explicités dans les sections suivantes :
XML, XSLT, XPath 1.0 (W3C recommendation) XUL, RDF, XBL, CSS MathML (W3C recommendation) JavaScript XHTML (W3C recommendation)
Mozilla fournit aussi un cadre de travail pour la création des interfaces utilisateurs tel que le XUL. Celui-ci est un outil d’interface utilisateur multi-plateforme structuré basé sur le XML.
31
Il est possible d'utiliser les technologies Mozilla (Gecko : Moteur d’affichage de Mozilla employé dans d'autres navigateurs tel que Firefox pour par exemple l’interprétation du XUL) dans le cadre d'une application web : il faut alors installer un navigateur comme Mozilla ou Firefox.
Les différents logiciels de développement de Mozilla sont open source, i.e. libre d’accès. Ceci permet à quiconque d’exécuter, de copier, de distribuer, d'étudier, de modifier et d'améliorer le logiciel.
4.1.2 Inconvénients Développer une application Mozilla nécessite de connaître une multitude de langages,
ce qui entraîne parfois une certaine lenteur dans le développement. De plus, Mozilla possède une architecture étendue et une documentation peu explicite, cela implique une autre difficulté à maîtriser son environnement (cf. site de Mozilla).
L’inconvénient majeur de Mozilla est l’installation de sa plateforme pour le développement, celle-ci nécessite de compiler le code source de Mozilla en mode débug. En effet, la version téléchargée sur site n'est qu'un exécutable. Il est difficile de coder une nouvelle application sans avoir de retour de la part de Mozilla. Par exemple pour la version Windows, il faut installer des composants au départ prévu pour un environnement Unix, de posséder le logiciel Visual Studio C++ et de télécharger un ensemble de pilotes et d'outils indispensables pour la compilation à partir de la plateforme Mozilla.
Conclusion
Mozilla fournit de nombreuses possibilités pour créer des applications et d’autant plus en ce qui concerne le développement des interfaces utilisateurs : XUL
Après avoir décrit assez brièvement les différentes fonctionnalités qu’offraient Mozilla,
je vais vous définir le langage de mon interface : le XUL.
32
4.2 XUL XUL (eXtensible User-interface Language : langage d’interface utilisateur extensible)
est un langage de description d'interface graphique basé sur XML et utilisé dans Mozilla.
XUL comprend un ensemble de balises permettant de définir des boutons, des listes, des menus ou encore des zones d'édition, bref tous les éléments d'une véritable interface utilisateur. Un tel langage facilite le travail du développeur et permet d'écrire l'interface d'une application aussi aisément qu'une page Web.
Cette technologie permet aussi aux développeurs de définir des interfaces utilisateurs graphiques utilisant un mélange de XML, HTML, CSS et ECMAScript (JavaScript). Un utilisateur peut modifier n'importe quel aspect de l'interface utilisateur d'une application Mozilla basé sur XUL (comme le produit Mozilla lui-même) simplement en modifiant des fichiers qui utilisent la syntaxe standard d'une page Web.
Une autre particularité de XUL est que c’est un langage conçu spécialement pour créer des interfaces utilisateurs portables.
4.2.1 Comment utiliser XUL comme interface graphique
Il faut connaître les widgets3 disponibles Les définitions (xul, rdf et autres fichiers) doivent être placées dans le répertoire
chrome de Mozilla Votre application doit être enregistrée dans le fichier d'installation de chrome. L'application est lancée par la commande: mozilla -chrome suivie par le chemin
du fichier xul principal.
Je vais faire un schéma récapitulatif des fichiers de l’interface utilisateur XUL
Figure 4-1-1 Arborescence des fichiers de l'interface utilisateur xul
3 Eléments graphiques
mozilla -- chrome -- monfichierxul --content//fichiers xul, rdf, js --skin//fichiers css --locale//fichiers de texte DTD
33
4.2.2 Les prérequis pour programmer en XUL Pour apprendre le langage XUL et l’utilisation de la plateforme Mozilla, cela nécessite
un certain nombre de technologies à connaître. Celles-ci sont pour la plupart des standards. En effet, le XUL étant un langage XML, il faut donc bien entendu connaître le monde XML à savoir :
Le langage XML en lui-même
Le DOM : le Document Object Model. C'est une API, un ensemble d'objet qu'implémente la majorité des logiciels de traitement XML, pour pouvoir lire, modifier du contenu XML. Cela sert donc dans Mozilla à pouvoir modifier dynamiquement du XUL ou tout autre fichier XML. Il est donc indispensable de connaître le DOM.
Les CSS : ce langage permet de spécifier l'apparence d'un contenu XML à l'affichage. Très utilisé dans Mozilla pour spécifier l'apparence d'un fichier XUL. En effet, les composants graphiques XUL ont un habillage par défaut (celui en général imposé par le système d'exploitation ou par le navigateur) mais il est possible de créer sa propre CSS pour personnaliser l’apparence de l’interface XUL.
Javascript : le langage de script utilisé dans Mozilla pour définir le comportement de l'interface XUL. Il faut donc savoir ce qu'est le Javascript, (Ecmascript), savoir créer, manipuler des objets, des fonctions en Javascript etc... Cependant, dans ma première phase d’apprentissage des composants et du
développement en XUL, j’ai construit différentes interfaces sans me soucier des interactions avec les autres langages (ci-dessus). Celle-ci étant nécessaire plus tard pour mon interface.
4.2.3 Création d’une application en XUL
On crée un dossier dans le répertoire Mozilla/chrome avec un nom quelconque par exemple Teste qui contient lui-même trois répertoires spécifiques : content, skin et local
Figure 4-1 Schéma de création d’une application en XUL
34
Content - Fenêtres et scripts Contient les déclarations des fenêtres et des éléments d'interface utilisateur. Ceux-ci sont stockés dans les fichiers XUL, qui ont l'extension xul. Il peut y avoir plusieurs fichiers XUL, mais la fenêtre principale devrait toujours avoir un nom de fichier identique au nom du paquetage. Par exemple, le paquetage editor contiendra un fichier appelé editor.xul. Les scripts (NdT : javascript) sont placés dans des fichiers séparés à côté des fichiers XUL.
Skin - feuilles de style, images et autres fichiers de thèmes Les feuilles de style décrivent des détails de l'aspect d'une fenêtre. Elles sont stockées séparément des fichiers XUL pour faciliter la modification du thème d'une application. Toutes les images utilisées sont également stockées ici.
Local - fichiers spécifiques de langues Tous les textes qui sont affichés dans une fenêtre sont stockés séparément. De cette façon, un utilisateur peut avoir une configuration pour sa propre langue.
On crée alors dans le répertoire content deux fichiers : un fichier contents.rdf et un
fichier xul test.xul: Le fichier RDF est :
content
contents.rdf teste.xul
skin
contents.rdf teste.css
<?xml version="1.0"?> <RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:chrome="http://www.mozilla.org/rdf/chrome#"> <!-- list all the packages being supplied --> <RDF:Seq about="urn:mozilla:package:root"> <RDF:li resource="urn:mozilla:package:test"/> </RDF:Seq> <!-- package information --> <RDF:Description about="urn:mozilla:package:test" chrome:displayName="test" chrome:author="[email protected]" chrome:name="test"> </RDF:Description>
35
On fait de même dans le répertoire skin : Un fichier contents.rdf et une feuille de style pour avoir un rendu personnel de l’interface utilisateur.
On rajoute, dans le fichier : installed-chrome.txt, deux lignes de codes pour que l’interpréteur sache l’existante du programme qu’on vient de créer.
<?xml version="1.0"?> <RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:chrome="http://www.mozilla.org/rdf/chrome#"> <RDF:Seq about="urn:mozilla:skin:root"> <RDF:li resource="urn:mozilla:skin:classic/1.0" /> </RDF:Seq> <RDF:Description about="urn:mozilla:skin:classic/1.0"> <chrome:packages> <RDF:Seq about="urn:mozilla:skin:classic/1.0:packages"> <RDF:li resource="urn:mozilla:skin:classic/1.0:test"/> </RDF:Seq> </chrome:packages> </RDF:Description> </RDF:RDF>
36
4.2.4 Création d'un fichier XUL
Un fichier XUL peut avoir n'importe quel nom mais il doit avoir l'extension .xul. Le fichier XUL le plus simple a la structure suivante :
Cette fenêtre ne sert à rien tant qu'elle ne comporte pas d'éléments d'interface utilisateur. Ceux ci seront ajoutés dans la section suivante. Voici l'analyse ligne par ligne du code ci-dessus :
1. <?xml version="1.0"?>
Cette ligne déclare simplement qu'il s'agit d'un fichier XML. Elle est obligatoire pour chaque fichier xul.
2. <?xml-stylesheet href="chrome://global/skin/" type="text/css"?>
Cette ligne est utilisée pour spécifier la feuille de style à utiliser pour le fichier situé dans le répertoire chrome global/skin. C'est la syntaxe que les fichiers XML emploient pour importer des feuilles de style. Ce fichier contient toutes les déclarations par défaut pour tous les éléments XUL. De façon générale, vous mettrez cette ligne au début de chaque fichier XUL. Vous pouvez également insérer d'autres feuilles de style en utilisant la même syntaxe tout en gardant la feuille de style par défaut.
3. <window
Cette ligne déclare que vous allez décrire une fenêtre window qui sera la balise principale du fichier xul. Chaque fenêtre d'interface utilisateur est décrite dans un fichier séparé. Plusieurs attributs peuvent être placés dans l'élément window.
4. id="findfile-window"
L'attribut id est utilisé comme un identifiant, de sorte que des scripts puissent y référer. Vous mettrez normalement un attribut id sur tous les éléments.
5. title="Recherche de fichiers"
L'attribut title décrit le texte qui apparaîtra dans la barre de titre de la fenêtre quand elle sera affichée. Dans le cas présent, le texte Recherche de fichiers sera affiché.
6. orient="horizontal"
<?xml version="1.0" encoding="ISO-8859-1"?> <?xml-stylesheet href="chrome://global/skin/" type="text/css"?> <window id="findfile-window" title="Recherche de fichiers" orient="horizontal" xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"> ... </window>
37
L'attribut orient spécifie l'arrangement des éléments de la fenêtre. La valeur horizontal indique que les éléments doivent être placés horizontalement dans la fenêtre. Vous pouvez également utiliser la valeur vertical signifiant que les items seront affichés en colonne. Comme c'est la valeur par défaut, vous pouvez omettre cet attribut si vous souhaitez avoir l'orientation verticale.
7. xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
Cette ligne déclare l'espace de nommage pour XUL que vous devrez mettre dans l'élément window pour indiquer que tous ses enfants sont XUL. Notez que cette URL n'est jamais téléchargée réellement. Mozilla reconnaîtra cette URL en interne.
8. ...
C'est ici que les éléments (les boutons, les menus et les autres composants de l'interface utilisateur) sont déclarés. Nous en ajouterons quelques-uns dans les prochaines sections.
9. </window>
Et enfin, nous devons fermer la balise window à la fin du fichier.
Après avoir créé tous ces fichiers, il ne reste qu’à lancer l’interpréteur Mozilla dans « Invite de Commande » pour voir le résultat grâce à la commande suivante :
mozilla –chrome chrome://teste/content/teste.xul
38
4.2.5 Exemple
Dans cette section, vous trouverez un exemple assez simple d’une interface faite en XUL.
Code en XUL : test.xul
En quelques lignes de code, on peut faire une jolie interface.
J’ai rajouté une ligne pour spécifier une feuille de style CSS personnelle.
<?xml-stylesheet href="chrome://teste/skin" type="text/css"?>
Celle-ci possède juste un ligne pour spécifier la couleur de font de la fenêtre.
Une ligne de commande pour fermer la fenêtre.
<?xml version="1.0" encoding="ISO-8859-1"?> <?xml-stylesheet href="chrome://global/skin" type="text/css"?> <?xml-stylesheet href="chrome://teste/skin" type="text/css"?> <!DOCTYPE window> <window id="main_windows" title="Exemple d'une interface" width="300px" height="200px" xmlns:html="http://www.w3.org/1999/xhtml" xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"> <box orient="vertical" flex="1"> // boite principale <box orient="horizontal" pack="center"> <button id="find-button" label="Hibiscus" default="true" style="list-style-image: url(chrome://txul/skin/image.jpg);)" orient="vertical"/> </box> <box flex="1" pack="center"> <button label="Belle"/> <button label="Pas Terrible"/> <button label="Moche"/> </box> <box orient="horizontal" pack="center"> <button id="bExit" label="Exit" flex="1" oncommand="window.close();"/> <textbox id="infobox" size="25" flex="2"/> </box> </box> </window>
window { background-color: #E0FFFF; }
39
<button id="bExit" label="Exit" flex="1" oncommand="window.close();"/>
Dans cet exemple, nous avons eu recours qu’au fichier en XUL et d’une CSS pour créer une interface située ci-dessous :
L’exemple ci-dessus montre qu’il est facile de créer une interface personnalisée en quelques lignes de programmation grâce au XUL, néanmoins cette interface ne possède pas de fonctionnalités. Pour qu’elle puisse être fonctionnelle, il faudrait ajouter des scripts afin de faire interagir les boutons de cette interface.
Après avoir défini le XUL, je vais vous donner de plus amples explications sur les différents prérequis qu’ont suscité ce langage, à commencer par le XML. En effet, Le langage XUL comme de nombreux langages de description d’interface se base au départ sur des documents XML contenant la structure de l’interface graphique. Le XML étant principalement un langage structuré et très standardisé, il permet de réutiliser le document XML pour passer l’interface graphique d’un environnement à l'autre ou même d'un langage de programmation à l'autre. Remarque : Avant de commencer à décrire le XML, je voulais juste vous faire remarquer que cela semble un peu incohérent de commencer par le XUL, puisque c’est la partie graphique qui devait donc être développé en dernier. La raison pour laquelle j’ai commencer par là était pour me familiariser avec le XUL (que je ne connaissais pas) en créant des interfaces basiques.
40
4.3 XML
XML (eXtensible Markup Language : langage de balisage extensible ou étendu) est un langage à balise défini par le W3C (World Wide Web Consortium) comme un standard de l’Internet tout comme le HTML. Il offre un format de description de données structurées. Il autorise ainsi des déclarations de contenu plus précises et des résultats de recherche plus significatifs sur diverses plateformes. En outre, le XML permettra la création d'une nouvelle génération d'applications capables d'afficher et de manipuler les données sur le Web.
Les documents XML suivent un ensemble de règles qui en font des documents structurés. Nous allons donc en énumérer quelques-uns dans la suite. Puis nous allons décrire les principes d’un document XML, les différents modes de visualisations, l’intérêt d’un tel langage et nous finirons par un exemple pour mieux appréhender la structure XML.
4.3.1 Règles lexicales et/ou syntaxiques Voici une liste de quelques règles d’un document XML :
• Un document XML ne peut comporter qu'un seul et unique marqueur racine • Chaque marqueur d'ouverture doit être suivi d'un marqueur de fermeture. • Le nom du marqueur d'ouverture doit correspondre exactement au marqueur de
fermeture • Le contenu d'un élément est ce qu'il y a entre les balises de début et de fin de
l'élément (possibilité de balises imbriquées) • Les noms d'éléments sont sensibles à la casse (majuscule/minuscule). • Un élément vide (i.e. dont le contenu est vide) peut être représenté par une balise
d'élément vide, qui est fait d’une contraction des balises de début et de fin de l'élément • On ne peut pas spécifier deux fois le même attribut dans une balise de début • Le document XML doit suivre une DTD (déclaration de type définition, nous allons
en faire une explication dans la section XML et le format DAISY). • Avoir un encodage (les jeux de caractères : par exemple, le français possède des
accents tandis que l’anglais n’en possède pas) Ces règles permettent de savoir si un document XML est bien formé ou valide. On dit
qu’un document est bien formé s’il obéit aux règles syntaxiques du langage XML. Le document valide, quant à lui, est un document bien formé qui obéit en outre à une DTD.
41
4.3.2 Document bien formé Un document bien formé est un document qui obéit aux règles syntaxiques du langage
XML. Prenons par exemple :
<book>
<chapter>
<title>Introduction</title>
</chapter>
<chapter>
<title>Récit</title>
<subChapter>
<title>Partie 1</title>
</subChapter>
<subChapter>
<title>Partie 2</title>
</subChapter>
</chapter>
<chapter>
<title>Index</title>
</chapter>
</book>
Un document mal formé :
<text>
<bold><italic>XML</bold></italic>
</text>
Ce document n’est pas bien formé puisqu’il y a des entrelacements de balise. Ceux-ci sont strictement interdits dans la règle syntaxique du langage XML.
4.3.3 Document Valide Un document XML est valide s'il est associé à une définition de type de document et
s'il respecte les contraintes qui y sont définies. La définition de type de document doit apparaître avant le premier élément du document. Le nom qui suit le mot DOCTYPE dans la définition de type de document doit correspondre au nom de l'élément racine.
Une définition de type de document est une sorte de grammaire permettant de créer le document XML.
42
Par exemple :
<!ELEMENT tutorial (#PCDATA)>
Définition d’un élément racine tutorial contenant du texte (#PCDATA).
• Déclaration valide dans le document XML. <tutorial>Ceci est un document XML</tutorial>
Document valide comportant du texte.
• Valide <tutorial/>
Ce document est également valide (élément vide).
• Non valide <text>Ceci est un document XML</text>
L'élément racine n'est pas conforme à la DTD spécifiée.
4.3.4 Affichage des données XML Si les données XML sont lisibles en mode texte, il peut être souhaitable d'afficher ces
données de manière plus claire. Il existe différentes façons de présenter les données XML, parmi celles-ci :
• Les feuilles de style en cascade (CSS) • XSLT (Extensible Style Sheet Language)
Ces deux feuilles de styles sont plus détaillées par la suite.
4.3.5 Intérêt du XML et DAISY L’intérêt général d’une structuration de documents de type XML est :
• L’échange de données avec le monde extérieur • Communiquer n’importe quelle information entre systèmes hétérogènes.
A l’intérieur du projet VICKIE, de nombreux documents numériques suivent la
spécification DAISY comprenant des formats de fichier DTBook (Digital Talking Book). J’ai donc eu l’occasion d’initier à la spécification DAISY ainsi que le format DTBook afin de mieux comprendre leur fonctionnement. Me permettant ainsi à terme d’ajouter les documents suivant cette spécification dans mon interface. Je vais faire un court résumé de DAISY. Le projet Daisy est né en Suède en 1994, son objectif était de créer un format numérique pour les livres enregistrés. La première version de ce format était propriétaire. En 1996, le consortium DAISY décida d’utiliser les standards de l’Internet développés par le W3C. La version 2.0 disponible dès 1998 était donc basée sur le HTML et sur le SMIL 1.0.
43
Une version 2.02 fournie en 2001 fut une étape importante de l ‘évolution puisqu’elle se basait sur le XML du W3C lui donnant ainsi tous les intérêts du XML défini plus tôt. La dernière version approuvée en 2002 par Daisy et la NISO (National Information Standard Organisation, organisme américain) sous le terme de Z39.86-2002 possède de nombreuses améliorations (utilisation des nouveaux standards Internet, facilité de navigation). Un ouvrage respectant cette dernière spécification DAISY comprend :
un ou plusieurs fichiers sons contenant une narration humaine d´une partie ou de la totalité d´un texte,
un fichier balisé contenant une partie ou la totalité du texte - XML DTBook, un fichier décrivant la synchronisation entre le texte et une position dans les fichiers
sons - SMIL, un fichier contrôlant la navigation - NCX, un fichier permettant de relier les trois types de fichiers précédents, l´utilisateur peut
se déplacer à l´intérieur et entre les fichiers pendant que le système maintient la synchronisation entre le texte et le son.
Les apports de ce standard sont nombreux :
améliore radicalement la lecture pour les aveugles, flexibilité dans le niveau de structure (chapitre, page, paragraphe, phrase,...), de
fonctionnalités et le mélange de texte et de son fournis, flexibilité dans le choix de l´outil de lecture (matériel et logiciel) et dans le support de
distribution à utiliser (CD, DVD, carte mémoire, Internet,...), tire avantage du développement des technologies grand public en se basant sur les
formats de fichiers et les principes d´architecture de l´Internet, utilisable pour les aveugles, les personnes avec des difficultés d´apprentissage ou les
personnes souhaitant lire un livre enregistré, déjà adopté dans de nombreux pays, en train d´être accepté par l´industrie pour des usages grand public, conçu pour des sorties multiples (gros caractères, impression braille).
C’est la raison pour laquelle le standard DAISY est aujourd´hui le seul standard pour l´accessibilité et la navigation des documents numériques.
44
4.4 Javascript et le Document Object Model
4.4.1 Définition du Javascript Javascript est un langage de script, orienté objet, conçu pour rendre les pages HTML
interactives. Ce langage est aussi un langage interprété, ce qui signifie que, pour l’exécution, celui-ci ne nécessite pas d’être compilé.
Javascript est généralement utilisé pour programmer le comportement de l'interface graphique et effectuer les traitements en réponse aux actions sur les composants graphiques des pages HTML (suite à un click de souris sur un bouton par exemple).
Javascript est très employé, par Mozilla, pour créer des comportements et coller des différents composants graphiques. Par exemple, lors de la mise à jour d’un valeur d’une textbox utilisant un bouton XUL.
4.4.2 Description du DOM Le DOM est l'interface de programmation (API) qui permet au développeur web
d'accéder et de manipuler le contenu d'une page web, aussi appelée document. Il fournit une représentation structurée et orientée objet des éléments et du contenu d'une page avec les méthodes permettant de modifier les propriétés de ces objets. Il fournit aussi des méthodes (récupérer des attributs, créer des éléments, cacher des éléments et ajouter des fils tous impliquent la manipulation direct du DOM) permettant l'ajout et la suppression de tels objets, permettant ainsi au développeur de créer du contenu dynamique en modifiant le contenu, la structure et le style du document. Conclusion : JavaScript utilise le DOM (Document Object Model) pour accéder à des parties de l’interface utilisateur : grâce a l'interface XUL et de son interaction avec le DOM, > on peut directement modifier un document.
4.5 XPCOM Pour les besoins du développement de mon interface, j’ai appris à utiliser la
technologie XPCOM, je vais donc en faire ici une courte introduction.
XPCOM est l'acronyme de « Cross Platform Component Object Model », autrement dit modèle d'objets composants mutli-plateformes. XPCOM est une architecture open source dont le but est de développer des applications mutli-plateformes et modulaires. Il s’agit d’ une version légère et simplifiée de l’architecture CORBA (Common Object Request Broker Architecture) qui permettrait l’interopérabilité via le réseau.
XPCOM est une bibliothèque logicielle permettant de concevoir une application comme un ensemble de plug-ins. Ces composants peuvent être développés dans des langages distincts en C/C++ ou Javascript (etc …), leur interopérabilité sera faite grâce à l’ajout d’une
45
définition d’interface IDL (interface definition language). La bibliothèque XPCOM a servi, notamment, à développer Mozilla, Mozilla Firefox, Mozilla Thunderbird, Mozilla Composer.
Cette technologie permet la communication multi-plateforme entre des composants logiciels et du code grâce à la technologie XPConnect. En effet, tous les composants XPCOM peuvent s'appeler entre eux et sont accessibles en Javascript dans les fichiers XUL via l'interface XPConnect. Les appels des fonctions javascript correspondants à des fonctions des composants XPCOM. XPCOM et XPConnect permettent d'utiliser JavaScript pour accéder à des bibliothèques C/C++ depuis l'application XUL, permettant au final de créer des applications totalement indépendantes et mutli-plateforme. Par exemple, un code, qui contrôle les interactions des boutons d’un navigateur, est l’appel d’une fonction XPCOM suit exactement le même schéma à travers toutes les plateformes.
L'architecture est :
• dynamique o les composants sont chargés lors de l'exécution o de nouveaux composants peuvent être ajoutés lors de l'exécution, sans avoir à
recompiler ou recharger les composants existants • typée semi-dynamiquement
o certaines informations sur un composant sont connues statiquement o un composant peut être interrogé afin d'apprendre s'il dispose de certaines
capacités, qui pourront être utilisées si le composant répond par l'affirmative • « polyglotte »
o le langage de base de XPCOM est C++ o les langages JavaScript, Python, Ruby, Perl peuvent utiliser et définir des
composants XPCom o le projet BlackConnect vise à permettre de faire de même en Java o le projet Mono prévoit d'ajouter un support XPCom pour .Net à une date
ultérieure • multi-plateforme
o un composant C++/XPCOM rédigé selon les consignes de Mozilla pourra être recompilé et réutilisé tel quel sur toute plate-forme Mozilla
o les composants JavaScript peuvent être réutilisés immédiatement sur toute plate-forme Mozilla, tout comme les composants non compilés Python, Ruby, Perl
Remarque : XPCONNECT est une pièce qui peut être simplement décrite comme la « glue ». Il permet de relier JavaScript aux composants XPCOM disponibles, afin de les manipuler de manière transparente. JavaScript n'est qu'un des langages pouvant être utilisé pour atteindre XPCOM depuis XPConnect (on peut utiliser Python avec PyConnect par exemple), et est celui choisi par Mozilla
46
Figure 2 : Communications entre les trois différents composants Javascript, XPConnect et
XPCOM.
Conclusion : L’intérêt principal de XPCOM pour notre application est que nous utilisons certains composants XPCOM à partir de notre interface XUL dans le but d’ouvrir des boites de dialogues, créer des fichiers ou appeler des fonctions afin de créer une feuille de style…
4.6 XSLT La plateforme Mozilla propose une API permettant d'utiliser des fichiers XSLT, et
ainsi de transformer des fichiers XML en d'autres fichiers XML. XSLT (Extensible Style Language Transformations) est, comme son nom l'indique, un
langage destiné à transformer un fichier XML en quelque chose d'autre. Ce quelque chose d'autre sera le plus souvent un fichier XML ou HTML. Mais ce pourra être tout aussi bien un fichier d'un autre format : par exemple du texte pur, ou du Rich Text Format …
Dans notre application, nous avions eu besoin des feuilles XSLT pour transformer les
documents XML en HTML. Il était possible de créer manuellement des documents HTML mais cela était plus long et peu maniable.
Après avoir décrit tous les langages qui me seraient utiles pour le développement de mon interface, je vais spécifier tout ce qui constituera l’interface.
47
5 Spécification
5.1 Actions
L’interface, qui est fourni aux enfants et aux professeurs, permet l’interaction avec les différents outils proposés par VICKIE. Ainsi, nous avons faire ressortir les différentes actions que devra proposé notre interface :
Ouvrir le bureau de l’élève (dossier en html) Ouvrir un document numérique (livre, dictionnaire,…) Parcourir un document numérique, chapitre en chapitre, page par page, aller
directement vers une page, Supprimer un livre de son bureau Ajouter un document numérique Créer un nouveau bureau Supprimer un bureau Afficher le Braille de manière visuelle Quitter
5.2 Accessibilité Comme nous l’avons vu plus tôt, il faut rajouter différentes options afin de rendre
l’interface accessible : Choisir les couleurs de fond et texte Modifier la police ou la taille d’affichage Modifier la feuille de style Ajouter/supprimer les retours sonores Ajouter/supprimer les retours visuels
Ces différentes actions seront possibles à partir de documents en entrée dont nous
allons spécifier le format.
5.3 Format d’entrée Il existe différents formats de document électronique : Word, pdf, latex, rtf. Cependant, pour l’application VICKIE nous avons préférer nous basé sur le format DTBook XML suivant la spécification Daisy afin d’avoir en entrée un format standard rendant facile l’interfaçage avec différentes aides techniques (Synthèse vocal, Plage Braille, …). De plus, s’ajoutera à ce format le mathML pour la lecture de manuel de mathématiques.
48
5.4 IHM
Nous avons du point de vue de l’aspect graphique de notre interface de décomposer les différentes actions possibles dans 3 interfaces d’aspects différents. Ces 3 propositions se présenteront sous la forme suivante :
Figure 5-1 : Schéma descriptif de notre première IHM, regroupant la visualisation des documents, leur gestion, ainsi que la gestion du bureau.
49
Figure 5-2 : Schéma descriptif de notre seconde IHM regroupant la visualisation du sommaire du document ouvert. Cette visualisation permettant surtout de se diriger directement vers un chapitre du document.
Figure 5-3 : Schéma décrivant notre troisième IHM. Celle-ci permettant la lecture du document ainsi que la navigation dans le document.
50
Afin de gérer ces trois différentes IHM nous avions deux choix :
• Créer 3 interfaces différentes qui s’appellent entre elles. • Créer une seule interface qui va modifier la position et le nom de ces différents
boutons pour devenir une des 3 IHM décrites ci-dessus.
Pour des raisons de simplicité, nous avons choisis de créer une seule interface qui pourra passer d’une forme à une autre. Le schéma suivant décrit les différentes actions sur l’IHM permettant de passer d’une interface à une autre.
Figure 5-4 : Schéma représentant les interactions entre les différentes IHM. Les flèches vertes permettant de retourner en arrière vers les IHM précédentes. Les flèches bleus permettant d’aller plus loin dans le livre et donc d’aller vers la prochaine interface. Les flèches orange sont justes des modifications de la même IHM (passage vers une autre page ou vers un autre bureau). Finalement, la navigation se fait soit par clic sur les boutons situés en bas des IHM, soit en cliquant sur le titre du livre ou de chapitre que l’on veut lire, soit par les raccourcis clavier.
51
Une autre partie de l’IHM est bien sur la définition des raccourcis claviers. Comme
nous l’avons vu précédemment, ceux-ci sont primordiale du point de vue de l’accessibilité, Nous avons donc spécifier pour chaque action un raccourci clavier.
Raccourcis claviers Action Autre accès Ctrl + O Ouvrir un bureau, lance la
boîte de dialogue d’ouverture d’un fichier
Bouton Ouvrir
Ctrl + N Créer un nouveau bureau Bouton Créer Ctrl + D Ajouter un document Bouton Ajouter Ctrl + X Supprimer un document Bouton Supprimer Ctrl + B Retourne au bureau de
l’élève Bouton Bureau
Ctrl + RetArr Retourner à l’interface précédente
Bouton Bureau ou Sommaire
Alt + flèche Droite Page suivante Bouton page suivante Alt + flèche Gauche Page précédente Bouton page précédente Ctrl + Q / Alt + F4 Quitter Bouton Quitter
On pourrait ajouter pour ces mêmes actions un retour sonore très utile pour que
l’utilisateur sache si son clic, raccourci clavier ou autres a bien fonctionner. Les différentes spécifications permettront donc de créer l’interface la plus fonctionnelle, accessible et agréable pour l’utilisateur, en basant nos choix sur l’analyse des besoins de notre population cible.
52
6 Architecture
Après avoir détailler notre cahier des charges du point de vue de l’accessibilité, de l’IHM et des différentes actions proposées par l’interface VICKIE, nous allons détailler l’architecture globale comprenant les interactions entre les différents langages et fenêtres de notre interface. Nous détaillerons ensuite chaque cas d’utilisation, c'est-à-dire le déroulement et le fonctionnement des différentes actions de notre interface.
Le schéma globale ci-dessous décrit comment vont interagir les différents langages
rendant l’interface accessible et dynamique.
Figure 6-1 : Voici le schéma globale des différents composants et leurs interactions. L’interface XUL utilise les CSS pour personnaliser l’affichage et gère les événements grâce au Javascript. Celui-ci utilise les composants XPCOM pour parser les documents XML, gérer les feuilles XSLT ou ouvrir des boîtes de dialogue.
53
6.1 Gestion des bureaux des utilisateurs La gestion des bureaux se décompose en 2 grandes actions :
• Créer un bureau (un fichier HTML du nom de l’élève contenant l’ensemble des titres des documents ouverts par l’enfant).
Lorsque l’utilisateur clique sur le bouton « Créer Bureau » ou utilise le raccourci
clavier correspondant, le JavaScript va gérer l’événement par l’ouverture d’une boîte de dialogue permettant de nommer le nouveau bureau (composant XPCOM). Ensuite, lorsque l’utilisateur aura confirmer le choix du nom le JavaScript va créer un document HTML vide.
Figure 6-2 : Schéma fonctionnel de la création d'un bureau
54
• Ouvrir un Bureau
Lorsque l’utilisateur choisis d’ouvrir un nouveau bureau à travers l’interface XUL, JavaScript va ouvrir un composant XPCOM permettant d’ouvrir la boîte de dialogue d’ouverture de fichier. Une fois le chemin du fichier récupéré un composant DOMParser va créer un arbre à partir du document HTML permettant ainsi aux composants DOM appelé par JavaScript de récupérer les titres enregistré dans le bureau. Finalement, l’interface sera actualisée avec l’ensemble des titres contenus dans le bureau.
Figure 6-3 : Schéma fonctionnel de l'ouverture d'un bureau
55
6.2 Gestion des documents
Une fois le bureau ouvert l’utilisateur peut gérer sa liste de documents en les ajoutant ou supprimant. Cette action lancée par l’interface XUL va ouvrir une boite de dialogue permettant de choisir le document à ajouter au bureau de l’élève. Le composant XPCOM DOMParser permettra de créer un arbre à partir du document numérique afin que la partir JavaScript puisse récupérer le titre du document afin de l’insérer dans le fichier bureau.html. Finalement, l’interface sera actualisée et composée de l’ensemble des titres compris dans bureau.html. La suppression suit le même modèle. Seules les fonctions JavaScript seront différentes puisqu’elle permettront de supprimer un élément du fichier bureau.html ainsi que de l’interface.
Figure 6-4 : Schéma fonctionnel de l'ajout d'un livre
56
6.3 Navigation dans un document
La première étape permettant de rentrer dans un document est d’ouvrir un sommaire contenant les liens vers l’ensemble des chapitres de celui-ci. Le niveau des titres affichés dans le sommaire dépendra du choix de l’utilisateur.
L’élève va cliquer sur le lien du livre qu’il veut ouvrir. Une fonction JavaScript va
lancer la création d’un arbre grâce au composant XPCOM DOMParser. A partir de cet arbre, les feuilles XSLT vont créer, à partir de l’arbre, un fichier HTML avec l’ensemble des liens vers les chapitres du document ouvert. Cette page sera ensuite directement intégrer dans l’interface.
Figure 6-5 : Schéma de la navigation grâce au sommaire
57
La seconde étape consiste à passer du sommaire vers la partie désiré du document.
Celle-ci se décompose de la même manière que la création du sommaire mais le document HTML fournit dans l’interface est composé du titre voulu mais aussi du contenu de ce chapitre. Celui-ci pourra être facilement lu à travers l’interface en passage de page en page ou directement vers une page précise.
Figure 6-6 : Schéma du fonctionnement de l’ouverture d’une page du document dans l’interface.
Ces différents schémas d’architecture et de cas d’utilisation montrent bien comment
fonctionne l’interface en détails. Cependant si vous avez encore une vision limitée de celle-ci, vous trouverez en Annexe différentes captures d’écran montrant comment se dessine l’interface graphique du projet. Celle-ci n’étant pas encore finalisée mais le sera pour la fin de mon stage.
58
Conclusion Au cours de mon stage, j’ai donc eu l’occasion de développer l’interface graphique
d’un projet européen. Cette interface est le point de contact entre les outils proposés par VICKIE dans le but de faciliter l’intégration scolaire et les élèves, étudiants, professeurs qu’ils soient déficients visuels ou non. Etant partie de l’analyse des besoins et d’un long apprentissage des différents langages nécessaires, j’ai pu spécifier puis développer une interface graphique facilement utilisable et accessible.
Tout ce travail m’a beaucoup apporté d’un point de vue personnel puisque j’ai eu l’occasion de travailler en équipe sur une aide technique qui pourrait être très largement utilisé en milieu scolaire dans les prochaines années. J’ai aussi beaucoup appris du monde de la recherche, du travaille en collaboration visant à intégrer toutes les parties d’un projet pour en faire un ensemble d’outil cohérent et facilement utilisable. Du point de vue de mon cursus, il m’a été très intéressant de pouvoir mettre mes connaissances au service d’un projet de grande importanct me permattant d’accroitre mes connaissances et surtout de gagner en expérience. Mon travail touchant à sa fin je regrette cependant de ne pas avoir eu l’occasion de travailler en collaboration avec des enfants déficients visuels dans le but de rendre l’interface encore plus accessible et facilement utilisable. J’aurai aussi aimé pouvoir assister à la suite et la fin de ce projet, i.e. le déploiement dans des classes avec des enfants en situation de handicap.
59
Bibliographie Livre consulté Creating Applications with Mozilla Auteurs : David Boswell, Brian King, Ian Oeschger, Pete Collins and Eric Murphy. Editeur :O’reilly XSLT, Développement en XML & HTML Auteur : Khun Yee Fung Editeur : Campuspress Site sur les informations concernant le braille: Education&Savoir – les non-voyants et les nouvelles technologies de communication : http://www.unesco.org/pao/braille Le Braille http://ophtasurf.free.fr/lebraille.htm Terminal braille http://libbraille.org/displays.php Site sur l’accessibilité et la malvoyance : AIR : La déficience visuelle http://www.air-asso.org/deficienceVisuelle Accessibilité des personnes malvoyantes – veblog - http://www.veblog.com/fr/2002/0527-accessibilite.html http://membres.lycos.fr/pierreg/Biblio1.html Raccourcis claviers http://www.ekinox-team.com/tuto_raccourcis.php Raccourcis d'accessibilité http://reguiny.joueb.com/news/81.shtml JAWS http://www.visuaide.com/jawsf.html Site concernant Mozilla : Geckozone – Suites Internets – Compiler Mozilla sur les plateformes de Win32-bits – Mozilla Firefox http://www.geckozone.org/articles/2004/06/30/9-compiler-mozilla-sur-les-plateformes-windows-32-bits
60
Site sur INOVA et BrailleNet Site sur DAISY http://inova.snv.jussieu.fr/helene/tools/macro/help/dtb-bm-l08-l15-l17.html Serveur Hélène http://www.braillenet.org/colloques/bnet2003/villette2003
61
ANNEXE
62