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 6 août 2008
En finir avec les CAPTCHAs visuels?
Posté par olivier_webyboom le mercredi 6 août 2008 - Accessibilité
Tout part d'un message de Pierre Reynaud, posté sur la liste Accessibilité-numérique. Pierre n'est pas content, et on le comprend: il se retrouve confronté à un système anti-spam, MailInBlack, basé sur l'identification de l'expéditeur, via un formulaire. Ce formulaire comporte un captcha visuel, c'est-à-dire une image destinée à filtrer les logiciels d'inscription automatique (les robots spammeurs, quoi). Cette image contient des lettres déformées, censément illisibles par un système de reconnaissance de caractères, mais faciles à déchiffrer pour un humain, qui peut alors saisir le texte incrusté dans l'image. Seulement voila, Pierre est aveugle, et n'a donc pas accès au contenu du captcha. Il n'est donc pas en mesure d'écrire à son correspondant qui a utilisé ce système pour protéger sa boite mail.
Dans le but de dépanner Pierre, je l'ai orienté vers Webvisum, un outil gratuit décrit lors d'un précédent billet. Webvisum est une extension de Firefox 3 qui comprend un décrypteur de Captcha visuel. La mise en place est un peu lourde au départ, mais sur le formulaire incriminé, ça marche:
-
D'abord il faut télécharger et installer Firefox 3 si ce n'est déjà fait
- Créer un compte sur Webvisum
Une fois Webvisum installé, se rendre sur la page où se trouve un captcha (la page de contact du système anti-spam sus-cité par exemple)
Lancer le résolveur via le menu contextuel (option "Solve CAPTCHA", raccouci clavier: 6) ou le raccourci clavier (ctrl+alt+6, mais un conseil, changez-le, car sur un clavier français il semble que ça ne marche pas). L'image est détectée par Webvisum, qui l'expédie à un serveur, et renvoie la réponse après quelques secondes. La chaine de caractères est dans le presse-papiers, il n'y a plus qu'à la coller dans le champ adéquat
Ouf!
Sur 3 essais réalisés sur cette page, ça marche à 100% (Sébastien Delorme a eu des résultats moins flatteurs avec des captchas complexes). Il faut dire que le captcha utilisé par Mailinblack paraît bien simple... et si c'est ça la clé de voute de leur système supposé "éliminer 100% des spams", j'aurais tendance à dire qu'il y a de la présomption dans l'air. Ça ne doit pas être bien dur de forcer le barrage avec un algorithme OCR de base... et du coup ruiner le principe sur lequel repose ce service.
Ça vaudrait le coup, il me semble, que nombre de gens (dont toi, ami lecteur... si si, on peut se tutoyer maintenant!) envoient un courrier à cette société pour leur expliquer en quoi leur système est discriminant, et inefficace qui plus est. Mais j'hésite sur le fait de leur expliquer comment un outil gratuit a pu contourner leur captcha en quelques secondes. En effet, deux réactions sont possibles: soit ils y réfléchissent et utilisent un système plus efficace et moins pénalisant pour les humains; soit ils se disent qu'ils n'ont pas à se remettre en cause, puisqu'après tout les non et mal-voyants peuvent quand même se débrouiller. Évidemment la seconde attitude est suicidaire commercialement, mais que voulez-vous, même en matière de business la rationalité n'est pas le propre de l'homme...
Qu'en penses-tu, lecteur? La discussion sur la liste accessibilité-numérique a permis d'avancer quelques arguments. Globalement, le consensus qui se dégage est que si on présente la solution de contournement, il faut aussi préciser sa lourdeur pour un utilisateur bien intentionné, mais souligner sa capacité de contournement, plausible pour un hacker du dimanche, donc source d'un risque de sécurité inacceptable. Certains (Sébastien) pensent qu'il faut proposer des solutions alternatives pour être constructif, ce qui est louable, mais pas forcément l'objet de ce type de message.
L'idée n'est pas de jeter l'opprobre sur cette société en particulier, bien que l'usage de technologies-barrières soit ancré bien profond au cœur de leur produit. Mais il faut faire prendre conscience aux décideurs mal informés que ce type de service n'en est pas un, et qu'ils doivent être plus exigeants avec leurs fournisseurs, et réclamer des solutions qui prennent réellement en compte tous les paramètres. C'est vrai de MailinBlack comme de tout système basé sur des captchas et autres techniques pénalisantes. C'est pourquoi je propose qu'on mette à disposition des internautes une liste de sites ou services posant ce type de problèmes, avec l'adresse e-mail de réclamation adéquate, permettant à tout un chacun d'en sélectionner et de les contacter à ce propos. Si le mouvement est suivi, l'effet de masse devrait donner au moins à réfléchir aux éditeurs.
Des volontaires?
lundi 28 juillet 2008
Se faciliter la vie (et la vue) avec les styles utilisateurs
Posté par olivier_webyboom le lundi 28 juillet 2008 - Accessibilité
Un peu de technique s’impose…
Pour surfer sur le web avec un ordinateur, nombre d’internautes utilisent un navigateur dit graphique, les plus populaires actuellement étant Internet Explorer et Firefox.
Lorsque l’on visite une page de site web avec un navigateur graphique, pour faire simple il effectue en gros deux choses :
- D’abord interpréter le code HTML, qui s’occupe du contenu : les textes, les liens, les images, le multimédia, et la façon dont ils sont organisés
- Ensuite interpréter les styles (dits CSS), pour mettre en forme et en couleurs le contenu, c’est-à-dire sa présentation
Les faits sont plus subtils, puisque pour des raisons historiques le HTML est encore trop souvent utilisé, via des « bidouilles », pour faire de la mise en forme. Une idée forte de l’accessibilité des sites internet est de respecter le principe dit de « séparation du contenu et de la présentation ». C’est-à-dire : faire en sorte que le HTML ne fasse que du contenu, et le CSS s’occupe de toute la mise en forme.
Je fais ce que je veux avec mon navigateur
Il existe un principe-clé en CSS : pour un même élément, les styles peuvent être déclarés plusieurs fois, à différents niveaux : dans une feuille de style, au cœur du HTML, ou par le navigateur. Ce sera toujours la dernière déclaration, dans l'ordre de "lecture" du code par le navigateur, qui sera prise en compte. Prenons l’exemple d’une feuille de style qui impose la couleur verte pour tous les textes. Si dans la page, du code HTML « stylé » définit que la couleur de texte doit être rouge, alors elle apparaîtra rouge.
Ce qui nous intéresse ici est la possibilité, pour l’internaute, d’indiquer à son navigateur quel style il souhaite appliquer, via ce qui est généralement désigné par « feuille de style utilisateur » (« user style sheet » en anglais). Si vous avez bien suivi : sur un site conçu avec des CSS, il est possible pour tout un chacun de définir « à volonté » la façon dont il s’affiche à l’écran…
O.K., mais ça sert à quoi d’utile ?
La nature a été très sympa avec moi, au moment de me donner des yeux : acuité visuelle, perception des couleurs, tout marche très bien… cependant des années d'usage immodéré d'écrans d'ordinateur m’ont appris deux choses : l’humilité, et la prudence.
Les moniteurs aux résolutions toujours plus élevées, et l’habitude trop répandue d’essayer de caser un maximum d’infos dans un minimum d’espace, font que de nombreux sites internet utilisent une police de caractères franchement trop petite. De plus, afin de limiter la fatigue, mon réglage de moniteur minimise la luminosité, du coup si des couleurs sont faiblement contrastées, la lisibilité est mise à mal, même avec une bonne vue.
Les concepteurs des sites qui ont fait ces choix ont des raisons qui leur appartiennent. Le gros progrès avec les feuilles de style utilisateur, c’est que l’internaute n’est plus prisonnier de ces choix, et peut appliquer les règles d’affichage qui lui conviennent.
Cet article va vous présenter des exemples d’utilisation de ces feuilles de style utilisateur, ainsi que la manière de les appliquer.
Firefox, mon ami
La plupart des grands navigateurs proposent cette fonctionnalité. Pour ma part je trouve très pratique la combinaison Firefox (en version 2 ou 3, c'est idem), et le module d’extension Stylish. Firefox est mon outil de base pour surfer et développer, et je trouve Stylish simple et pratique, surtout pour définir des styles pour un site en particulier. De plus, elle permet de piocher dans des centaines de styles utilisateurs prêts à l’emploi.
Libre à vous d’adapter les astuces qui suivent à d’autres navigateurs, bien sûr !
Mieux voir l’élément courant
Quand on navigue au clavier, via la touche Tab, avec la plupart des navigateurs l’élément courant (lien, champ de formulaire, cadre…) est entouré d’un fin liseré, en traits pointillés (souvent appelé le « focus »). Ce liseré est en général très discret… trop, en fait, car il est souvent difficile de le retrouver dans une page, au point qu’il faut le faire bouger pour finir par le repérer. Pas très commode…. Certains webdesigners avisés rendent le focus bien visible par CSS, comme le recommandent certains spécialistes. Mais c’est encore trop rare.
Heureusement un style utilisateur prêt à l’emploi permet de rendre le focus beaucoup plus voyant (un épais liseré bleu ciel), quel que soit le site visité. Il s’agit de Bright Focus. Cliquez sur « Load into Stylish », et si tout se passe bien, le style est activé ; naviguez avec la touche de tabulation pour voir le résultat (sinon, vérifiez qu’il est coché dans l’interface de Stylish, puis redémarrez Firefox).
Si vous n’utilisez pas Firefox, vous pourrez toujours voir le code en cliquant sur le bouton « Show code », et vous en inspirer.
Mon Wikipedia à moi
J'adore Wikipedia, à la fois pour les contenus, et le principe qui sous-tend cette encyclopédie en ligne. Mais deux choses me gênent sur ce site...
D'abord je trouve les textes bien trop petits, surtout pour les longs articles. C'est
vrai qu'on peut agrandir le texte, mais devoir le faire à chaque fois
qu'on ouvre une page, c'est pesant quand on explore un sujet, ce qui
souvent conduit à ouvrir nombre d'onglets. C'est vrai aussi, Firefox 3 réduit
la gêne en mémorisant le niveau de zoom pour un site, mais bon, même avec la version 2 on a le droit de vouloir mieux que ça.
Ensuite, les liens en bleu sombre non soulignés m'énervent, car on ne les distingue pratiquement pas du reste du texte. D'autre part, les liens vers des articles "pas encore écrits" sont en rouge, ce qui est une hérésie du point de vue de l'accessibilité (la couleur ne doit pas être le seul moyen de fournir une information).
Qu'à cela ne tienne! Je me suis bricolé une feuille de style "spécial wikipedia", qui augmente la taille de tous les textes et souligne tous les liens, sur tous les sites du domaine wikipedia.org.
Le code CSS (simplissime) utilisé:* {font-size:105%}
a {text-decoration:underline !important}
a.new {font-style:italic !important}
Le résultat est assez laid, mais peu m'importe, au moins je m'économise de la rétine!
Pour quelque chose de bien plus abouti, qui améliore la lisibilité, réorganise les éléments de la page, masque les éléments superflus de la page, et autres commodités, vous pouvez tester le style Wiki clean
and professional.
Les WCAG plus lisibles
Une autre application, assez ironique d'ailleurs, des styles utilisateurs: rendre les WCAG 1.0 (le socle, la source originelle, la bible...) plus lisibles - plus... accessibles, donc-, et polir un peu ce diamant brut, voire brutal. C'est la bonne idée qu'à eue Derek Featherstone, exposée dans son article "Doing it with user style". D'autant plus salvateur si l'on s'y réfère régulièrement! Un bel exemple en tous cas de ce qu'on peut faire pour plier un site à sa volonté (avec un peu de boulot, tout de même...).
Voir la langue des mots
Sous ce titre aux parfums surréalistes, une astuce permettant de détecter visuellement les changements de langue dans une page web. C'est très utile lorsque l'on audite ou conçoit des sites ayant l'ambition d'être accessibles, ce qui implique notamment de spécifier la langue des mots provenant d'une autre langue que celle de la page courante. Sans cette astuce, le contrôle de langue nécessite d'inspecter le code source, à la recherche de mots "pas français", et de vérifier leur attribut lang. Fastidieux, et en général peu efficace. Avec ce style, les mots correctement taggés sautent aux yeux, pour ainsi dire, tandis qu'on repère plus facilement ceux qui ne le sont pas. Un gain de temps loin d'être négligeable sur un audit ou des tests!
A vous!
Le but de cet article est de montrer une application utile et créative d'une fonctionnalité méconnue des navigateurs, et de susciter de bonnes idées sur le même thème. N'hésitez donc pas à partager vos trouvailles via les commentaires sur ce billet!
jeudi 3 juillet 2008
WebAnywhere, lecteur d'écran en ligne gratuit
Posté par olivier_webyboom le jeudi 3 juillet 2008 - Accessibilité
Je viens de retrouver un lien que j'avais temporairement mis de coté...
Il existe un lecteur d'écran en ligne (en version alpha, mais selon les auteurs la version est acceptable): Webanywhere.
Le principe est le suivant: l'utilisateur ouvre la page de WebAnywhere, à partir de laquelle il surfera sur d'autres pages via une frame. WebAnywhere vocalise la page, et réplique le comportement d'un lecteur type Jaws ou Windows-eyes au niveau des contrôles de navigation.
Gros avantage: ça marche sur toute machine avec une connexion haut-débit, un navigateur et le son. C'est gratuit, open-source, et ne nécessite aucune installation particulière (à la différence de FireVox par exemple). C'est donc une solution ultra-portable, utilisable en situation de mobilité, ou pour des raisons simplement économiques.
Je n'ai pas pu tester (pas de son sur le PC d'où est écrit ce billet...........), mais ça paraît être une solution très séduisante! Il y a de grandes chances que ce soit excessivement anglophone, cela dit le caractère open-source du projet le rend ouvert aux adaptations. Donc "y a plus qu'à"...
mercredi 28 mai 2008
11 outils de visualisation des contrastes et des couleurs altérées
Posté par olivier_webyboom le mercredi 28 mai 2008 - Accessibilité
L'une des thématiques bien connues de la conception de sites accessibles est la prise en compte des difficultés de perception du contraste, qui s'intensifient généralement avec l'âge. Ces difficultés s'imposent également aux personnes atteintes de daltonisme. Il s'agit d'une anomalie de la vision qui altère la perception des couleurs. Selon Wikipedia elle toucherait 8% des hommes et 0.45% des femmes en France. Elle se divise en 3 grands types, selon que c'est la perception du rouge, du vert ou du bleu qui est concernée. Outre les embûches de la vie quotidienne (association de couleurs parfois malheureuses dans le choix de vêtements, par exemple...), cela peut devenir un véritable défi de comprendre un texte ou un visuel qui ferait usage de couleurs très (trop) proches, si l'une des composantes est incorrectement perçue.
Les recommandations d'accessibilité prévoient cette situation. Ainsi
dans les WCAG 1.0 on trouve la Directive 2: Ne pas s’en remettre
exclusivement aux couleurs. Elle incite à ne pas utiliser la couleur comme seul moyen de fournir une information (directive 2.1), et de faire usage de couleurs qui resteront suffisamment contrastées même aux yeux d'un daltonien (directive 2.2).
Pour un concepteur de sites web, il est généralement très difficile de s'assurer que les choix graphiques sont pertinents de ce point de vue, en particulier pour les cas où seuls certains daltoniens sont gênés. Fort heureusement des outils très pratiques permettent de remédier à cela.
L'application dénommée "Cercle Chromatique Accessible" permet de facilement sélectionner un jeu de couleurs de texte et de fond, et de vérifier interactivement la bonne adéquation de ces couleurs au niveau du contraste et de la différence de luminosité. Les algorithmes de contrôle utilisés sont ceux du W3C, cet outil permet donc de faire des choix de couleurs qui satisferont les critères d'accessibilité internationaux. En outre, les perceptions par les personnes atteintes de l'un des 3 grands types de daltonisme sont simulées, ce qui permet de se faire une idée du résultat vu par les daltoniens.
Cet article (en anglais) liste 10 outils de contrôle du contraste. Parmi ceux-ci, une extension Firefox faisant un "bilan des contrastes" complet sur toute la page, d'un simple clic.
Avec tout cela, plus d'excuses pour faire un site aux couleurs inaccessibles!
mardi 4 mars 2008
Standards web: Amaya, un navigateur pour visualiser et éditer du code (X)HTML conforme
Posté par olivier_webyboom le mardi 4 mars 2008 - Technos web
Le logiciel Amaya 10.0 est un navigateur qui permet d’afficher une page web en s’appuyant sur une des DTD standards du W3C. Il permet également l’édition du contenu directement dans la page. Comme seul le code respectant la DTD peut être saisi, il en résulte qu’on produit obligatoirement des documents valides... très intéressant en phase de maquettage, donc, d’autant que les formats SVG, SMIL et MathML sont également supportés.
Si le serveur de pages autorise le HTTP PUT, on peut mettre les pages à jour directement sur le site.
Le support des CSS est a priori limité à CSS1 pour le moment, mais le support complet de CSS2.1 est en cours de développement.
Pour en savoir plus, consultez la fiche Wikipédia d'Amaya
mardi 4 septembre 2007
Accessibilité: détecter facilement les éléments avec un attribut lang
Posté par olivier_webyboom le mardi 4 septembre 2007 - Accessibilité
Une recommandation d’accessibilité prioritaire est de fournir à l’internaute l’information concernant la langue d’un mot ou groupe de mots d’origine étrangère.
Le point de contrôle 4.1 des WCAG : Identifiez clairement les changements dans la langue naturelle du texte d’un document et de tous les équivalents textuels (par exemple : les légendes)
Le critère 8.7 du label Accessiweb : Les changements de langue dans une page sont-ils signalés ?
En effet, ceci donne à un outil de lecture d’écran la possibilité de sélectionner le registre vocal adéquat pour prononcer un mot donné. Ainsi, le mot "newsletter" sera prononcé "niouz-lèh-teur", et non "nevzlèté", s’il est correctement balisé.
Une façon classique de coder cette fonction, est d’ajouter une balise <span>, et de lui spécifier l’attribut "lang". Exemple :
Abonnez-vous à notre <span lang="en">newsletter</span>.
Lorsqu’on évalue l’accessibilité d’une page, il est donc nécessaire de vérifier la bonne application de cette recommandation.
Cela peut être assez fastidieux avec la méthode traditionnelle : détecter les mots d’origine étrangère, examiner le code source, vérifier leur attribut lang.
L’astuce suivante permet de mettre en valeur, par une couleur de fond distincte, les mots dont l’attribut langue est "en", "de", ou "es", ou un des attributs de langue associés (par exemple, "en-us" pour l’anglais américain). Ainsi on peut les repérer facilement, et par conséquent détecter plus immédiatement ceux qui ne sont pas correctement taggés.
Deux options : soit par une feuille de style, soit par un bookmarklet (c’est-à-dire une instruction javascript exécutée dans la page via un favori, ou bookmark).
Dans les deux cas, il faut Firefox (mes essais sur IE7 ont été infructueux jusque là -- mais je suis preneur de tout conseil à ce propos). Pour l’astuce CSS, si vous ne l'avez pas déjà, vous pouvez utiliser l’excellente barre d’outils Web Developer, ou alors l'extension Stylish. Pour le bookmarklet, il faut avoir javascript activé.
En version feuille de style, cette astuce repose sur la capacité de CSS2 à sélectionner un élément en fonction de son attribut. Par exemple :
*[lang|="en"] {background :cyan ;}
va changer en bleu ciel (cyan) la couleur de fond (background) de tous les éléments (*) de la page dont l’attribut lang vaut "en" ou une déclinaison de la forme "en-..." (|=).
Il suffit de répéter cette ligne et de l’adapter à différentes langues, comme dans la feuille de style lang.css attachée à cet article. Sauvegardez-là sur votre disque local, et grâce à la barre d’outils Web Developer, utilisez-là comme feuille de style utilisateur : CSS > Add User Style Sheet... Si des mots taggés "anglais" sont définis dans la page, vous les verrez surlignés en bleu clair.
La version bookmarklet est plus pratique, mais sa personnalisation est un peu plus complexe, car il faut connaître un minimum de javascript.
Pour l’utiliser, créez un nouveau Favori dans la barre des liens (la "barre personnelle", qui bien sûr doit être définie comme visible dans votre Firefox). Dans le champ "Adresse Web", collez tel quel le code contenu dans le fichier ci-dessous.
code js pour détection des langues
Donnez à votre favori le nom qu’il vous plaira, et validez.
Vous disposez maintenant d’un bouton qui provoque le surlignement des mots anglais, allemands et espagnols correctement taggés.
La liste de langues et les couleurs ne sont pas figées, simplement il vous faudra mettre la main à la pâte !
Bon surlignage !
