LadyARwen Posté 5 Janvier 2005 Posté 5 Janvier 2005 Bonjour, On me demande de réaliser un portail multilingue regroupant des formations dont certaines on été réalisées à l'aide d'E-Learning Maker de Dokeos. Pour l'instant, les séances qui ont été faites sont lisibles via Shockwave, par la suite ce sera Flash. J'ignore si ce logiciel est connu, je n'en avais jamais entendu parler avant. On me demande également de prendre en compte des critères d'accessibilité, et j'ai cru lire sur un site que les documents Flash ne sont pas accessibles aux personnes malvoyantes... Je n'arrive malheureusement plus à retrouver le document où j'ai lu cela. J'aimerais vos conseils car le travail de développement a été commencé avant mon recrutement et j'ai la charge de relever les éventuels dysfonctionnements et non conformités. Merci d'avance de vos réponses !
Denis Posté 5 Janvier 2005 Posté 5 Janvier 2005 Bonjour LadyARwen, bienvenue sur le Hub. Pour l'instant, les séances qui ont été faites sont lisibles via Shockwave, par la suite ce sera Flash. J'ignore si ce logiciel est connu, je n'en avais jamais entendu parler avant. Quel logiciel ? Flash ou Shockwave ? On me demande également de prendre en compte des critères d'accessibilité, et j'ai cru lire sur un site que les documents Flash ne sont pas accessibles aux personnes malvoyantes... Pour ce qui est de développer des applications Flash qui soient accessibles, bien peu de gens savent faire... mais c'est néanmoins tout à fait possible depuis Flash MX et Flash Player 6. Il y a ce livre blanc écrit par Bob Regan qui pourrait peut-être t'aider : http://www.markme.com/accessibility/archives/005515.cfm
Monique Posté 5 Janvier 2005 Posté 5 Janvier 2005 Bonjour LadyARwen, Et bienvenue sur le Hub D'abord, quelques infos à propos de E-Learning Maker de Dokeos (que je ne connaissais pas non plus) : Dokeos est une plateforme de téléformation basée sur un "fork" de Claroline (v.1.4.2). Un fork peut être considéré comme un clonage à un instant T dun logiciel libre dans le but de le faire évoluer dans une direction différente du logiciel original. Intéressants (en anglais), un article Creating Accessible Macromedia Flash Content et les pages du site Macromedia Accessibility and Macromedia Flash MX 2004 que je n'ai pas encore lus Enfin, aussi dans ma liste des articles à lire... Ergonomie et Flash annoncé par Frédéric Cavazza dans son billet L'année 2005 sera Flashy
Stephane Posté 5 Janvier 2005 Posté 5 Janvier 2005 En termes d'accessibilité, le passage de Shockwave à Flash sera déjà un progrès important je pense. D'après ces statistiques, 98,2% des internautes disposent du player Flash, contre seulement 55,5% pour Shockwave. Ce rapport de Jakob Nielsen présentant des recommandations pour l'amélioration de l'accessibilité des sites Flash te sera peut-être utile. http://www.nngroup.com/reports/accessibility/flash/
LadyARwen Posté 6 Janvier 2005 Auteur Posté 6 Janvier 2005 (modifié) Denis, le logiciel dont je parle est ELM qui permet de réaliser des formations qui pour l'instant sont publiées en Shockwave mais on a reçu hier la mise à jour qui permettra de publier en Flash, par contre j'ignore quelle version du Plugin ça va être. Pour l'accessibilité je vais lire vos articles car je ne vois pas trop comment rendre accessible une animation à une barrette braille ou la synthèse vocale, j'espère trouver la réponse dans vos liens. Pour l'instant je suis juste chargée de prévoir l'accessibilité pour la version 3 de notre projet (là on prépare la v2) mais il faut prévoir à l'avance ! Merci je vais lire tout ça et à plus tard ! Modifié 6 Janvier 2005 par LadyARwen
LadyARwen Posté 6 Janvier 2005 Auteur Posté 6 Janvier 2005 Bon à la lecture de tout ça, j'ai déjà trouvé un point qui me chiffonne... ELM permet de réaliser des petits tests, genre QCM pour lesquels il s'agit de classer des propositions dans un tableau selon certains critères par un glisser déposer.. Et ça il semblerait que ce ne soit pas gérable par les appareils d'assistance... Est-ce que vous connaîtriez une parade à ce système ?
Denis Posté 7 Janvier 2005 Posté 7 Janvier 2005 Ne connaissant pas ELM ou même ce que veut dire QCM, je ne saurais pas trop t'aider. Par contre, pour ce qui est de rendre un truc accessible, peut-être votre solution résiderait-elle dans la création d'une source alternative ou parallèle à cet éventuel contenu qui serait purement textuelle pour le bénéfice de ceux qui ne pourraient l'utiliser ?
Monique Posté 7 Janvier 2005 Posté 7 Janvier 2005 Bonjour, Sans connaître le logiciel, il est difficile de t'aider Serait-il possible que tu mettes une page test en ligne, avec un exemple très simple du type de QCM que tu voudrais réaliser ?
Denis Posté 7 Janvier 2005 Posté 7 Janvier 2005 QCM = Questions à Choix Multiples C'est juste ça ? Je suis un peu déçu Autrement je suis d'accord avec Monique... ça prendrait un peu plus d'informations pour que nous puissions t'être d'une quelconque utilité.
jpv Posté 10 Janvier 2005 Posté 10 Janvier 2005 Bon à la lecture de tout ça, j'ai déjà trouvé un point qui me chiffonne...ELM permet de réaliser des petits tests, genre QCM pour lesquels il s'agit de classer des propositions dans un tableau selon certains critères par un glisser déposer.. Et ça il semblerait que ce ne soit pas gérable par les appareils d'assistance... Est-ce que vous connaîtriez une parade à ce système ? <{POST_SNAPBACK}> J'ai eu à m'occuper d'un cas de ce genre, tu à deux solutions: La première consiste à créer une couche applicative (avec actionscript) pour effectuer ce genre de comportement avec les touches du clavier, c'est assez facile mais ça ne résoudra pas completement le problème de l'accessibilité de flash qui est quelquefois possible et toujours une vraie galère... La seconde est de produire, chaque fois que nécessaire des alternatives adaptées avec une couche comportementale basée sur Ecmascript (javascript). Pour ce qui me concerne, je propose toujours cette seconde solution, car le travail à réaliser pour rendre des modules flash accessible est souvent supérieur à celui qui est nécessaire pour créer une alternative complète. L'autre aspect du problème est la structure générale du produit final, si ce sont des modules 100% flash, tu es dans la pire des situations... Si les modules flash ne sont utilisés que comme fonctionnalités du produit final alors une bonne analyse te permettra de jongler avec les deux solutions, adapter le module flash ou proposer une alternative selon ce qui est souhaitable et possible, au cas par cas. En tout état de cause, le domaine de l'e-learning fait partie des domaines toujours assez compliqué à rendre accessible, ça demande beaucoup de temps et beaucoup de test et de retour d'expérience utilisateur. Les problèmes auxquels tu vas te trouver confronté vont concerner essentiellement la prise en charge des fonctions du clavier, la gestion de l'historique de navigation et la gestion des comportements "souris", car sur ces trois domaines il va te falloir tout refaire, navigation tabulaire, raccourcis claviers, gestion du curseur par les touches de direction du clavier et l'élaboration d'un historique de navigation propre aux modules flash. Macromedia propose nativement certaines adaptations mais qui sont rarement utilisables telles qu'elles. Par contre, le controle de la synchronisation images/son peut t'offrir beaucoup de possibilités... Un dernier petit conseil : si il y à une vraie volonté de rendre ce produit accessible la première chose à faire est de voir comment tu peut limiter au maximum l'utilisation des modules flash au profit de solutions basées sur Ecmascript (javascript) qui, si elles sont bien pensées, offre souvent des possibilités équivalentes où à tout le moins satisfaisantes.
Denis Posté 10 Janvier 2005 Posté 10 Janvier 2005 Pour ce qui me concerne, je propose toujours cette seconde solution, car le travail à réaliser pour rendre des modules flash accessible est souvent supérieur à celui qui est nécessaire pour créer une alternative complète. Je ne suis pas sûr d'être 100% d'accord avec cette idée... peut-être que le travail initial serait moins long en adoptant une version alternative, mais à long terme, la maintenance et l'évolutivité des deux versions ne représentera t-elle pas un investissement en temps plus considérable que de bien faire le travail à travers Flash la première fois ? si il y à une vraie volonté de rendre ce produit accessible la première chose à faire est de voir comment tu peut limiter au maximum l'utilisation des modules flash au profit de solutions basées sur Ecmascript (javascript) qui, si elles sont bien pensées, offre souvent des possibilités équivalentes où à tout le moins satisfaisantes. Un autre truc qui me chifonne un peu... que l'on parle de Flash ou d'ECMAscript, le problème est le même.. à la base ce sont des technologies qui ont le potentiel d'exclure un certain pourcentage d'utilisateurs, soit par absence du module d'extension dans le premier cas, soit par non-support de la technologie dans le second cas.
Ganf Posté 10 Janvier 2005 Posté 10 Janvier 2005 Attention Denis : toute technologie exlue ceux qui ne la supportent pas, HTML compris. Quelqu'un qui n'a pas de navigateur te dira que le HTML exclue des gens. Le tout c'est de choisir une technologie qui *peut* être accessible au plus grand nombre, qui prévoit les accès pour intéragir avec tous les éléments source et pas avec le rendu. Après effectivement tout n'est pas accessible à tout le monde, mais il y a un moment où il faut avancer et dire "moi je fais ce qui est de ma responsabilité". Sinon on restera en texte pur et HTML pour tout le monde. Je ne suis pas sûr d'ailleurs qu'un texte pur soit fondamentalement meilleur coté accessibilité qu'un HTML+js, l'accessibilité ne se résumant pas à l'accès des handicaptés .. et le js peut aider.
Denis Posté 10 Janvier 2005 Posté 10 Janvier 2005 Attention Denis : toute technologie exlue ceux qui ne la supportent pas, HTML compris. Quelqu'un qui n'a pas de navigateur te dira que le HTML exclue des gens. C'est vrai, je suis d'accord, même si le HTML demeure de loin le format le plus universel qui soit pour le Web - à part peut-être le txt, mais faudrait pas charrier... Il importe de reconnaître ce que les technologies peuvent apporter de positif et les apprécier comme telles. La tendance à démoniser les technologies est encore présente (j'ai quelques rechutes à l'occasion moi aussi), et avec un peu de patience, elle disparaîtra aussi de nos habitudes. Tout ce que je voulais dire avec ma récente intervention, c'était simplement qu'il ne faut pas forcément se rabattre sur celles-ci lorque des soltions plus efficaces peuvent faire l'affaire (pensons simplement à quelques manipulations du côté serveur pour limiter un peu le javascript).
jpv Posté 11 Janvier 2005 Posté 11 Janvier 2005 (modifié) Un autre truc qui me chifonne un peu... que l'on parle de Flash ou d'ECMAscript, le problème est le même.. à la base ce sont des technologies qui ont le potentiel d'exclure un certain pourcentage d'utilisateurs, soit par absence du module d'extension dans le premier cas, soit par non-support de la technologie dans le second cas. Tout dépends de la cible finale, le fameux end-user qui est au web ce que la ménagère de moins de 50 ans est à la télé A l'évidence, si le produit final cible le "tout public" la question de rajouter une couche ecmascript peut se poser encore que ... Par contre si le produit final est à destination d'un public controlé, par exemple au travers d'un systeme utilisateur, la question de se pose plus, l'alternative ecmascripté est tout à fait crédible et assez avantageuse. Je ne suis pas sûr d'être 100% d'accord avec cette idée... peut-être que le travail initial serait moins long en adoptant une version alternative, mais à long terme, la maintenance et l'évolutivité des deux versions ne représentera t-elle pas un investissement en temps plus considérable que de bien faire le travail à travers Flash la première fois ? Le projet auquel je faisais référence était un framework QCM pour la formation online de personnel administratif. Les concepteurs avaient trouvés "joli" de faire tous les formulaires en flash avec moult effets typiquement US-flashy... Pour adapter ces modules il m'aurait fallu un travail monstrueux pour rendre ça accessible à la navigation tabulaire, aux touches de direction du clavier, à la gestion de l'historique et j'en passe ... Pour quel bénéfice réel ?, pour un non-voyant la question de se pose même pas, les petites étoiles qui pivotent sur elle-même il s'en passe fort bien et je suis content de lui éviter le load d'un objet flash, les raccourcis/touches spécifiques et l'éventuelle perte de focus suite à une fausse manoeuvre... Pour les utilisateurs de la navigation tabulaire et les déficients visuels, même remarque, particulièrement pour ceux qui auraient besoin d'agrandir la taille de caractère, ce qui imposait une autre adaptation... Du coup, quand bien même cela demande effectivement un travail de maintenance plus important, les bénéfices de la solution scripté n'apportait que des avantages. Et il ne s'agissait là que de modules ultra simples, des cases à cocher et des réponses à tester, Si tu rajoutes à ça du drag and drop, des boucle d'animation et des rétro-actions complexes, le travail pour rendre ça accessible à tous et dans toutes les situations est colossal. (pensons simplement à quelques manipulations du côté serveur pour limiter un peu le javascript). Quand à la solution serveur, là encore il faut bien en mesurer les enjeux. Le scripting client, du moins dans ses applications basiques est remarquablement bien géré par les screens readers par exemple surtout en ce qui concerne la gestion d'evenement et les effets de focalisation (focus, select...). Du coup, pourquoi leur imposer un aller retour serveur, un rechargement de page, et une gestion de la reprise de focus ??? C'est pourquoi j'insistais sur l'analyse préalable du end-user, car si tant est que l'on puisses controler les minimum requis d'un applicatif de ce genre, alors franchement du script bien pensé et bien organisé c'est quand même extrèmement avantageux... Mais bon c'est vrai qu'il n'y à pas de solutions unique, ce sont toujours des cas d'espèces et c'est tant mieux sinon on s'ennuierait un peut... Modifié 11 Janvier 2005 par jpv
LadyARwen Posté 7 Avril 2005 Auteur Posté 7 Avril 2005 Hello, Je m'excuse j'ai mis un peu de temps à vous répondre. Nous avons eu une formation d'introduction à l'accessibilité la semaine dernière, ce qui a permis de voir certains points de façon plus claire. Le public visé par notre projet est le plus large possible, et cela inclut les non-voyants. Ce qui signifie : support de la synthèse vocale, barette braille... Nous avons eu une démonstration d'une jeune étudiante aveugle, et j'avoue que ça nous a fait froid dans le dos. La solution idéale, serait d'oublier : - Flash - Javascript - PDF et privilégier les formats non propriétaires, genre RTF... L'alternative serait de réaliser des pages sans mise en forme avec autant de feuilles de style que nécessaire. Pour en revenir à mon projet ELM, voici des détails. En fait, l'application génère des fichiers XML à la volée, encore pire que Dreamweaver dans ses premières versions. Le tout est publier à l'aide d'un player Flash "maison"... Donc ce n'est même pas du Flash pur ! Je n'y connais pas grand-chose en XML, mais je peux d'ores et déjà préciser que les fichiers ne sont pas "bien formés" (pas de DTD, balises de mise en forme html en plein dans le code XML...). Bref l'horreur... On va tenter de bosser là-dessus avec e-doceo et les formateurs de la formation citée ci-dessus, dans quelle mesure ces fichiers XML seraient exploitables et nettoyables...
Xavier Posté 8 Avril 2005 Posté 8 Avril 2005 Attention Denis : toute technologie exlue ceux qui ne la supportent pas, HTML compris. Quelqu'un qui n'a pas de navigateur te dira que le HTML exclue des gens. <{POST_SNAPBACK}> Il me semble qu'il y a quand-même une grande différence entre le flash et le HTML. Le HTML est un format ouvert, implémentable par n'importe qui, ou à défaut au moins cela peut être fait sous n'importe quel OS s'il y a des gens compétents qui s'y mettent. Pour le flash c'est différent. La licence est très claire, il est strictement interdit de faire un "lecteur flash" alternatif. Seul Macromedia peut le faire. On exclu donc d'emblée un nombre important de systèmes pour lesquels Macromedia n'a pas la volonté d'implémenter le flash. Chose que l'on ne fait pas a priori avec le HTML... (il est peu probable d'ailleurs qu'il reste des OS pour lesquel il n'y a pas de navigateur... et dans ce cas je doute que les utilisateurs ne soient connectés à Internet).
Sujets conseillés
Veuillez vous connecter pour commenter
Vous pourrez laisser un commentaire après vous êtes connecté.
Connectez-vous maintenant