jeudi 25 septembre 2008
Quelques ressources pour comprendre et utiliser WAI-ARIA
Posté par olivier_webyboom le jeudi 25 septembre 2008 - Accessibilité
WAI-ARIA est une spécification du W3C qui vise à rendre plus accessibles les interfaces riches du web moderne. Elle permet de définir le rôle, l'état et le changement d'état des éléments HTML d'une page, et les relations éventuelles entre ces éléments.
Ceci prend toute son importance avec la sophistication croissante des interfaces proposées par les applications web. Prenons l'exemple, volontairement simpliste, d'un menu de navigation: le HTML, jusqu'à sa version 4.01, ne dispose pas de balise spécifiquement dédiée à ce type d'élément. Pour compenser, les développeurs web utilisent généralement des balises de listes, modifiées grâce aux feuilles de style, pour ressembler par exemple au menu d'un logiciel de bureau. Puis elles sont rendues dynamiques grâce à un langage de script tel que Javascript, afin de simuler le comportement d'un menu (ouverture, fermeture, déploiement des sous-niveaux au passage de la souris, réactions aux clics...). Visuellement, le résultat est probant, et l'utilisateur comprend aisément l'intention de l'auteur, et donc la façon d'utiliser ce menu. C'est bien là la limite de ces solutions: en l'absence de perception visuelle, les informations implicites visibles telles que "le menu est ouvert", ou "la branche de ce sous-menu est déployée", ne sont pas fournies intrinsèquement aux utilisateurs de lecteurs d'écran, par exemple. D'autre part, la navigation au clavier est parfois mal, voire pas du tout, prise en compte. Cet exemple fournit un cas d'utilisation très simple; les problèmes sont encore plus délicats avec des éléments plus complexes comme des curseurs, des arbres hiérarchiques, des grilles de données éditables, etc.
En introduisant, via des attributs spécifiques des balises standards, des propriétés supplémentaires, ARIA promet de fournir aux utilisateurs des technologies d'assistance assez d'informations pour qu'ils aient une expérience de navigation similaire à la navigation visuelle. Un avantage majeur d'ARIA, bien qu'encore à l'état de draft, est qu'elle est déjà largement implémentée, et prête à être utilisée. Elle est prise en charge dans Firefox 3, Opera 9.5, Safari, et le sera dans Internet Explorer 8. De nombreuses librairies Javascript l'intègrent (Dojo, JQuery, GWT, YUI...), et les lecteurs d'écran (Jaws, Window-Eyes, FireVox, NVDA...) suivent le mouvement. Des applications grand public telles que GMail et Google Reader en bénéficient. Pour plus d'informations, une FAQ sur codetalks.org (anciennement, FAQ du centre des développeurs Mozilla) offre un panorama complet et instructif.
Cela dit, bien qu'effervescente, cela reste une technologie émergente, et les ressources et exemples d'application sont encore rares. L'Université de l'Illinois, via l'iCITA, son centre de recherches sur l'accessibilité des technologies de l'information, propose deux ressources très utiles dans le cadre d'un développement exploitant ARIA.
La première est une série d'exemples de composants (widgets) exploitant ARIA. Avec, par exemple, Firefox 3 et FireVox, on peut découvrir comment les rôles et gestions d'états sont utilisés pour renseigner l'utilisateur sur le comportement des composants.
La seconde est une barre d'outils permettant de contrôler l'accessibilité d'une page (sous FireFox). Encore une autre, me direz-vous? Celle-ci présente l'avantage de faciliter l'inspection et le test des éléments de scripts, et en particulier des widgets ARIA. Les développeurs disposent donc d'un outil de productivité supplémentaire. Par ailleurs ses fonctions de personnalisation du rendu visuel intéressera les utilisateurs ayant des problèmes de vision.
mercredi 24 septembre 2008
Scripting Enabled: les résultats
Posté par olivier_webyboom le mercredi 24 septembre 2008 - Accessibilité
Scripting Enabled, organisé par Chris Heilmann, vient de se terminer. Cette rencontre visait à mettre en relation des utilisateurs avec des besoins particuliers, et des développeurs et webdesigners passionnés, aptes à proposer des solutions innovantes, autour des mashups et autres promesses technologiques du Web2.0 (voir l'article de présentation sur Webyboom: "Scripting enabled: rencontre dédiée au Accessihacking").
L'événement semble avoir tenu ses promesses. D'ores et déjà sont disponibles les présentations sur les attentes de différents profils d'utilisateurs; ainsi qu'un wiki dédié aux travaux amorcés durant la session. Rien que les présentations fournissent une foule d'informations sur des difficultés rarement prises en compte par les recommandations: dyslexie, troubles de l'attention, hyperactivité... Le résultat du remue-méninges (brainstorming) traduit bien également l'esprit de créativité pragmatique qui a mené à la création de Scripting Enabled.
Ne souhaitant pas en rester là, Chris Heilmann espère bien que le modèle de Scripting Enabled pourra servir de base à d'autres événements. Il propose son aide à toutes les bonnes volontés souhaitant en organiser un, ainsi qu'un ensemble de recommandations. Dont acte!
mardi 15 juillet 2008
L'accessibilité des sites corrigée par les internautes?
Posté par olivier_webyboom le mardi 15 juillet 2008 - Accessibilité
Encore une info pêchée sur le blog de Chris Heilmann (si vous ne l'avez pas encore dans vos fils RSS, celui-là, il serait temps d'y songer!)... Une tendance se dessine actuellement, concernant le "crowdsourcing" ("codage par la foule", littéralement). Celui-ci consiste à permettre à tout un chacun de contribuer concrètement au code de sites internet. Dans le domaine de l'accessibilité, cela se traduit par l'ajout de méta-données (textes alternatifs, balises adaptées, attributs pertinents...) au code de la page, là où elles font défaut.
Deux projets significatifs dans ce domaine ont vu le jour récemment: Social Accessibility Project, chez IBM, et WebVisum.com. Le projet d'IBM vise à équiper les lecteurs d'écran et les navigateurs d'additifs logiciels, qui permettent de signaler un problème aux bénévoles chargés de les traiter, de le résoudre de façon collaborative, et d'alimenter un serveur de données. Celui-ci ajoutera les informations manquantes à la volée, dès la prochaine visite au site incriminé.
WebVisum est une extension de Firefox 3 (inscription au service nécessaire), qui en plus de cette fonction de résolution collaborative, propose de décoder les CAPTCHAs visuels, et différentes fonctionnalités qui facilitent la vie des déficients visuels.
Les deux projets partent des besoins des utilisateurs de lecteurs d'écran principalement, s'y intégrant de façon transparente. Rien n'interdit toutefois d'imaginer qu'on pourra apporter des améliorations qui concernent d'autres besoins spécifiques.
Restent deux points à régler, à mon sens. Assistera-t-on à une nouvelle balkanisation du web, du fait de la coexistence de différentes bases de méta-données, alimentées et utilisées par des moyens techniques différents? En attendant que tout soit unifié, faudra-t-il parcourir la même page avec les différents outils de ce type, pour être sûr d'avoir la totalité de la contribution des différentes communautés d'utilisateurs?
Ensuite, ne risque-t-on pas de dédouaner, dans une certaine mesure, les éditeurs de sites de leur devoir de mise en accessibilité? Pas d'impair: l'idée de base est puissante et productive, et on est d'accord que le service à l'utilisateur prime, quelqu'en soit le moyen et le fournisseur, finalement. Cependant, anticiper les effets pervers permet de mieux les prévenir. Le projet d'IBM positive le problème en espérant que les contributions montreront la voie aux propriétaires de sites, en leur fournissant, clé en mains, les meilleures pratiques telles que les attendent les utilisateurs. Il faudra certainement faire preuve de beaucoup de persuasion et de pédagogie, pour expliquer que ce type d'action ne doit pas remplacer l'incorporation des bonnes pratiques d'accessibilité au processus de conception et de production de tout site internet digne de ce nom.
mercredi 2 juillet 2008
Mashups et accessibilité: des solutions existent!
Posté par olivier_webyboom le mercredi 2 juillet 2008 - Accessibilité
C'est en recherchant des liens relatifs à l'accessibilité des mondes virtuels que je suis tombé sur le centre de ressources sur l'accessibilité d'IBM. Un article en particulier a capté mon attention: Web 2.0 mashup accessibility. Il y est fait le point sur les difficultés particulières à anticiper, dans le cadre des mashups (applications web permettant aux utilisateurs d'agréger des contenus et services disponibles sur Internet, pour éventuellement en créer de nouveaux).
En fin d'article, l'auteur mentionne le projet Fluid, qui démontre par l'exemple la faisabilité d'applications type mashups accessibles. Fluid est "un projet collaboratif à l'échelle mondiale, visant à améliorer l'utilisabilité et l'accessibilité de projets open source communautaires, avec une attention particulière aux logiciels d'éducation pour les universités".
Fluid propose des composants prêts à l'emploi, des méthodologies et des ressources. Parmi celles-ci, une bien appétissante liste de ressources sur le thème de l'accessibilité.
Tous ces articles sont en anglais, donc malheureusement peu accessibles si on ne maîtrise pas cette langue... toutes les bonnes volontés pour les traduire seront donc les bienvenues!
vendredi 27 juin 2008
Scripting enabled: rencontre dédiée au Accessihacking
Posté par olivier_webyboom le vendredi 27 juin 2008 - Accessibilité
On vous en parlait dans un billet précédent (Accessihacking: mieux utiliser le web 2.0 pour améliorer l'accessibilité), Chris Heilmann de Yahoo proposait une nouvelle approche des services web 2.0 en faveur de l'accessibilité. En outre, il sondait l'intérêt des lecteurs sur la possibilité d'organiser un hackday autour de ce thème.
C'est maintenant chose faite: un financement et un pitch existent: ça s'appellera Scripting Enabled, et c'est prévu à Londres, pour Septembre 2008.
Accessihackers de tous les pays: à vos claviers!
Edit (30/06/2008): il existe maintenant un site dédié à Scripting Enabled.
mercredi 4 juin 2008
Accessihacking: mieux utiliser le web 2.0 pour améliorer l'accessibilité
Posté par olivier_webyboom le mercredi 4 juin 2008 - Accessibilité
Chris Heilmann nous gratifie de nouveau, sur son blog, d'un article riche en idées très innovantes et fertiles. Il y présente le concept de "Accessihacking", terme qu'on pourrait pseudo-franciser par le terme "accessibidouillage". L'idée est de "hacker" (bidouiller, donc) des services web existants, tels qu'un moteur de recherche, un lecteur vidéo, des cartes interactives, Twitter, etc. afin de les exploiter d'une façon qui rendra un service amélioré à ceux qui vivent une problématique d'accessibilité.
Précisons ici que dans ce contexte, l'accessibilité n'est pas envisagée comme "le web pour tous", mais comme "le web pour un peu plus de monde que si on ne fait rien". Ainsi, Chris a expérimenté le concept sur une interface exploitant le lecteur vidéo de YouTube, plus facile à utiliser pour les personnes avec des difficultés d'apprentissage. Ca ne résout pas les problèmes de tout le monde, mais au moins d'une frange de la population qui se trouvait exclue jusque là.
Il nous explique que cet article trouve son origine, en premier lieu, dans sa lassitude de ne pas voir les choses bouger suffisamment concrètement au niveau de l'accessibilité.
Par ailleurs, d'un sentiment de gâchis et de relative inutilité, à propos de la tendance "mashup" (agrégation de services et contenus dans une même interface, pour en créer de nouveaux), souvent "cools", mais à quoi bon si ça ne sert à rien d'autre qu'à exister?
Et enfin, son lecteur vidéo expérimental a été reçu avec beaucoup d'enthousiasme également par des mal-voyants (à sa grande surprise). Ce qui l'a conforté dans l'idée que, par des actions simples (pour un programmeur suffisamment
doué, précisons-le...), on peut améliorer la vie de quantité de
personnes, sans même forcément le faire exprès. Deux idées qu'il a déjà expérimentées: l'automatisation de
l'application du paramètre de langue sur les messages Twitter; et une
interface simplifiant la création de sous-titres via YouTube.
Fort de ce constat, et convaincu de la nécessité de se faire rencontrer les besoins (les utilisateurs) et les talents (les "geeks", comme il appelle les as du bidouillage informatique), Chris envisage d'organiser des sessions de rencontres ("hackdays") dont il espère faire sortir des idées et surtout des réalisations concrètes et utiles. Il invite ses lecteurs à s'exprimer sur cette proposition, n'hésitez donc pas à lui faire part de votre opinion.
Nul doute qu'il y a là un champ très vaste d'exploration, qui ira dans le sens de l'amélioration pour au moins certaines personnes. Prenons l'exemple de la localisation, sur des cartes interactives, des lieux accessibles en fauteuil roulant, via les infos fournies par des internautes. Ou de sous-titres ou audio-descriptions ajoutés par des utilisateurs sur des vidéos en ligne. Ce sont des choses faisables, qui rendraient un service de grande valeur à certains utilisateurs en difficulté. Et on devrait même pouvoir en tirer un modèle économique dans bien des cas...
Et vous, qu'en pensez-vous?
samedi 1 septembre 2007
Technos: comparaison de frameworks web2
Posté par webyboom le samedi 1 septembre 2007 - Technos web
Le web 2.0 à l’instar de son aspect commercial et marketing demeure confus sur le plan technique tant la quantité de frameworks disponibles pour les développeurs est phénoménale, on les estime à l'heure actuelle à plus de 500 !
Pour les néophytes, le web 2.0 repose concrètement sur le JavaScript, particulièrement sur sa capacité à faire des appels asynchrones aux serveurs Web via l’objet XMLHttpRequest ; une technologie ancienne initiée par Microsoft avec l’objet ActiveX XMLHttp en 2001 ! Ceci permet aux visiteurs d’un site d’accéder à de nouveaux contenus dynamiquement sans avoir à cliquer sur une succession de liens pour rafraichir leur page Web. A cette fonctionnalité s’ajoute le DHTML (qui permet de modifier l’apparence d’une page HTML grâce au JavaScript sans rafraichir le navigateur) pour donner naissance au Web 2.0.
Un concept qui vise à offrir aux visiteurs une « expérience nouvelle » du Web avec des sites plus dynamiques ressemblants de plus en plus à une vraie application car offrant un haut degré d’interactivité et de réactivité. Tout ceci renforce l’impression qu’a le visiteur d’être au cœur d’une communauté le rendant plus que jamais contributeur du site sur lequel il se trouve.
La déferlante Web 2.0 a engendré une multitude de frameworks pour implémenter facilement de nouveaux contrôles Web appelés « widgets » tels que des arbres dynamiques, des grilles, des champs auto-complétés et autres fenêtres drag-and-dropables jusque-là réservées aux applications. Selon vos besoins, chaque framework aura ses avantages et inconvénients qu’il faudra confronter pour faire le bon choix.
Il existe une variété de frameworks en JavaScript ceux-ci sont en fait des bibliothèques de widgets. Les plus populaires et les plus légers sont prototype-Rico, prototype-Script.aculo.us ou encore, d’autres plus poussés offrent des widgets plus fonctionnels et variés tels que Dojo, Rialto, Yahoo UI ou Ext.
Avantages:
- Ces frameworks sont d’une grande souplesse dans la personnalisation des interfaces, on peut créer soi-même ses propres widgets , en maitriser les comportements, y ajouter des effets graphiques flatteurs, etc.
- Graphiquement, grâce aux CSS, il est facile de changer l’apparence de ces composants. Ext propose même par défaut un skin très proche des applications comme office 2003 ou Windows Vista.
- Il est vraiment possible de rendre une application Web aussi ergonomique qu’une application locale, grâce à des frameworks très poussés comme Ext.
Inconvénients:
- Requiert des connaissances en développement avancées, et de l’expérience dans le domaine pour programmer des applications complexes. Car il est très facile de développer quelque chose qui surcharge le serveur Web comme le poste client (navigateur) et qui au final, par rapport aux conditions d'exploitation (forte audience par exemple), s'avère instable et/ou peu performant.
- Pour un ingénieur spécialisé dans la programmation orientée objet, le JavaScript parait insuffisamment strict et robuste. De plus pour l’homogénéité d’un projet il est recommandé d’utiliser le même IDE coté client comme coté serveur et de base les IDE les plus connus, Eclipse ou Visual Studio ne sont pas des éditeurs/débogueurs de JavaScript performants.
- Même si les frameworks sont compatibles avec la plupart des navigateurs du marché, le JavaScript demeure un langage coté client pour les navigateurs Web, son comportement est tributaire son implémentation par ces derniers. Le code pour implémenter ces frameworks est fortement sujet à des incompatibilités entre les navigateurs voire entre les versions d’un même navigateur.
- Le code est plus difficile à maintenir : quand on se penche sur les sources d’un widget par exemple, il est difficile de le comprendre car il s’agit souvent d’un amas de <div> faisant appel à des classes CSS.
- Du code bien entendu qui peut être très éloigné du respect des normes d'accessibilité (W3C, Accessiweb)
Les frameworks en langages orientés objet:
GWT, Echo2, DWR, MagicAJAX .NET, ComfortASP.NET entre autres pour .NET, ces frameworks ont pour but de passer au niveau d’abstraction supérieur et de permettre au développeur de se défaire du code JavaScript souvent jugé complexe et couteux. Chaque framework néanmoins propose une approche différente de cette abstraction que je vous invite à découvrir en détails sur leur sites Web respectifs.
Avantages:
- Aucunes connaissances en JavaScript ne sont requises, c’est le framework qui se charge de le générer. Le coût de développement est moindre car on garde une structure monolithique dans son application, idéal pour une mise en production rapide.
- Facilité de test et de débogage car on peut travailler sur son IDE actuel avec son langage actuel Java, C#... La maintenance est donc plus aisée (ex intégration de JUnit dans GWT).
- Ces frameworks (GWT et Echo2) proposent pour la plupart des widgets : Grid, Tree, Input auto-complété ; dans le cas des frameworks .NET beaucoup utilisent un composant conteneur qui se chargera de rafraichir en asynchrone les contrôles qu’il contient.
- Les requêtes client/serveur sont gérées automatiquement par ces framework et demeurent transparentes pour le développeur. DWR va plus loin car il permet avec Javascript d’accéder à des méthodes distantes
Inconvénients:
- S’il reste possible de personnaliser ses widgets grâce au CSS, il n’est pas possible de changer complètement l’apparence de ceux-ci en changeant le code généré en HTML.
- Pour le cas de GWT, l’utilisation d’un tel framework s’est révélée plus adaptée pour des applications web riches à page unique. Or beaucoup d’applications actuelles fonctionnent selon un modèle à plusieurs pages puis essaient d’ajouter de l’interactivité avec des composants AJAX, intégrer GWT à ce genre d’applications est beaucoup plus difficile qu’avec les frameworks JavaScript.
- En implémentant GWT, l’application repose entièrement sur le JavaScript généré par le framework, ainsi si le JavaScript n’est pas supporté par le navigateur ou est désactivé rien ne s’affichera sur la page.
- DWR ne propose pas de widgets.
Alors lequel choisir ?
On le remarque bien, le choix d’un framework dépendra de plusieurs facteurs :
- D’une part du type d’application Web : beaucoup d’applications en « Web 1 » sont construites sur plusieurs pages. Pour les rendre plus attractives, il est moins couteux de faire appel à un framework JavaScript, surtout si vous voulez avoir un contrôle parfait du « look and feel » de vos widgets. Autrement si vous prévoyez de développer une application web riche entièrement « ajaxisée », les frameworks Java ou .NET sont plus adaptés.
- D’autre part les compétences des développeurs qui sont a votre disposition. En effet pour la mise en place de frameworks JS, il faut avoir une bonne maîtrise en Web développement (JS, HTML, CSS, XML) pour optimiser le code coté navigateur et les appels qui sont fait au serveur. Le coût en formation ou en temps d’adaptation d’un développeur non-initié est loin d’être négligeable.
- On peut conclure que pour implanter de manière légère quelques widgets Web 2.0 sur de l’existant les frameworks JS sont la solution la plus convenable, cette flexibilité à un coût pour des applications Web plus complexes si vous ne disposez pas des compétences en Web développement avancé.
- Les frameworks en langages orientés objet sont certes plus rigides mais ils offrent aux applications une structure plus homogène et monolithique mais qui à l’avantage d’épargner aux développeurs la complexité du JavaScript et des communications client/serveur et d'en faciliter la maintenabilité.
Notre conclusion...
Finalement une solution idéale laisserait imaginer une combinaison de frameworks comme DWR avec n’importe quel autre framework JS (en théorie) ou de framework hybride GWT-EXT ou Ruby-on-Rails. Par rapport à la typologie de notre projet en cours (intranet de gestion) le framework extjs.com nous a paru le plus adapté.
Cet article n’ayant pas pour but d’être exhaustif sur les spécificités de chaque framework, nous vous invitons à consulter les liens suivants:
Frameworks JS :
- Dojo http://dojotoolkit.org/
- ExtJS http://extjs.com/
- Script.aculo.us http://wiki.script.aculo.us/
- YUI
http://developer.yahoo.com/yui/
- Rialto http://rialto.application-servers.com/wiki/
- Rico http://openrico.org
Frameworks en langages orientés objets :
- GWT http://code.google.com/webtoolkit/
- Echo2 http://www.nextapp.com/
- DWR http://getahead.org/dwr
- XML11 http://www.xml11.org/
- MagicAJAX .NET http://www.magicajax.net/
- ComfortASP
.NET http://geekswithblogs.net/danielz/Default.aspx
GWT-EXT
GWT versus Echo2
Comparatif de frameworks
divers
Comparatif de plusieurs
frameworks .NET
Divers articles sur le sujet:
