Aller au contenu | Aller au menu | Aller à la recherche

Mot-clé - accessibilité

Fil des billets - Fil des commentaires

dimanche, février 22 2009

L'expérimentation Bespin

Comme vous le savez certainement, un nouveau projet est sorti des laboratoires de Mozilla : Bespin. C'est un éditeur de code en ligne. En découvrant ses entrailles, j'ai été bluffé par le fait qu'ils utilisent l'élément canvas pour faire le rendu.

Lire la suite...

jeudi, octobre 16 2008

L'élement video

Il y a plus d'un an, j'avais publié un billet sur l'élément <video>. Les choses ont un peu évolué, les implémentations et les interrogations aussi. Voici donc un récapitulatif des avantages de cet élément sur l'élément <object>, ainsi que quelques démonstrations. On peut espérer que la balise object ne sera plus trop utilisée pour insérer de la vidéo : l'élément <video> est déjà présent dans Safari 3.1, dans des versions expérimentales d'Opéra, et la version beta1 de Firefox 3.1 qui vient de sortir.

Lire la suite...

mardi, mars 7 2006

Un autre jacky du web

On me reprochait dans mon billet précédant sur les dérives d'utilisation de DHTML, de "taper" sur un pauvre étudiant de 17 ans, alors que j'avais pourtant bien précisé que je m'appuyais juste sur un exemple de mauvaise pratique et que je ne lui en voulais pas du tout.

Pour contrebalancer et satisfaire les grincheux, je vais taper maintenant sur un "pro". Dans un des commentaires, voilà qu'on me signale un nouvel exemple de drag and drop abusif : http://support.free.fr.

Cette page propose des manuels PDF à télécharger. Pour les télécharger, il ne faut pas cliquer sur un lien (bah oui ma bonne dame ! C'est beaucoup trop simple vous comprenez !), il faut glisser-déposer une image correspondant au pdf voulu vers une zone de l'écran, pour démarrer le téléchargement.

Interro surprise :

  • À quoi ça sert ?
  • En quoi c'est web 2.0 ?
  • En quoi cela améliore l'experience utilisateur ?

Ramassage des copies à la fin de la journée.

À la décharge du développeur, cet exemple est toutefois mieux pensé en terme d'accessibilité[1] que le précédent. En effet, en dessous de chaque image, il y a un vrai lien, qui disparait aprés chargement de la page par du javascript (et qui donc reste visible si le javascript est inactif), et que l'on peut faire apparaitre en cliquant sur un lien spécifique "Pour Télécharger avec une navigation classique cliquez ici.".

Notes

[1] Enfin, accessible, c'est tout de même vite dit, car le layout, c'est de la bonne vieille soupe de balise et tableaux à gogo : sémantique = 0. Le type ne doit pas savoir ce qu'est CSS, ni ce qu'est le HTML, ce qui est limite en 2006.

vendredi, mars 12 2004

Accessibilité pour tous !

Ça faisait un bout de temps qu'Eric Daspet n'avait pas blogué. Le voici de retour, mais sur un autre blog, celui de Denis Boudreau. (Il est ce qu'on pourrait appeler, un bloggeur itinérant, ou un SBF :-) ). Il nous livre, comme à son habitude, un excellent article : Oublions les handicapés.

Eric dénonce une tendance plutôt négative : celle de focaliser sur les handicapés visuels quand on parle d'accessibilité. Cela a pour conséquence d'oublier qu'il existe d'autres handicaps, d'autres raisons de faire un site accessible. Je suis tout à fait d'accord avec lui.

Être accessible, ce n'est pas qu'être accessible aux aveugles, c'est être accessible à tout le monde. Il ne suffit pas de mettre des attributs alt dans les balises img pour avoir un site accessible. Le meilleur moyen d'avoir un site accessible, c'est de respecter au minimum, tout simplement, la sémantique des balises. J'en suis intimement persuadé.

J'en profite pour jeter un plus gros pavé dans la marre (ça me démange depuis bien longtemps) : n'en déplaise à Braillenet ou à AccessiWeb, j'affirme que leurs sites ne sont pas accessibles contrairement à ce qu'ils prétendent : ils sont simplement optimisés pour les aveugles et mal-voyant. Quand on ne respecte pas la sémantique des balises, quand on utilise des tableaux de partout pour la mise en page, quand on fait un site "optimisé en 800*600", on ne peut pas prétendre avoir un site accessible. Loin de là.

Je ne saurais trop vous recommander la (re)lecture de l'excellent tutoriel Plongez dans l'accessibilité qui montre bien qu'avoir un vrai site accessible, cela profite à tout le monde, même aux personnes "normales".

vendredi, novembre 7 2003

Appel à commentaire de l'ADAE

L'ADAE a rédigé un référentiel pour l'élaboration des sites web accessible, dans le sens large du terme. Vous pourrez trouver ce document sur cette page. L'agence fait un appel à commentaire sur ce document, avant qu'il ne soit définitivement accepté.

Pour ma part, je n'ai pas d'autres commentaires que celui-ci : excellent ! Bien que je ne sois pas un expert en accessibilité, je trouve que ce document fait une liste tout à fait exhaustive des pratiques à adopter lors de la conception de pages et de sites web.

On y retrouve les recommandations de l'utilisation des standards W3C, que ce soit au niveau HTML, CSS, mais aussi PNG par exemple. Ils reconnaissent que les recommandations du WAI (Web Accessibility Initiative) font référence en la matière. Tout une liste de pratiques techniques (mettre des alt dans les images etc..) est énoncé. Cela peut donc servir de check-list lors du développement.

Ce document a été conçu en collaboration avec l'association braillenet.

mise à jour 21:13 : suite à des commentaires à l'OpenWebGroup, il semble que j'ai lu un peu trop rapidement ce document, et qu'en fait, il est pas si génial que ça, et qu'il y a beaucoup de choses à redire. J'ai vraiment laisser passer des énormités même.. Honte à moi !

lundi, juin 23 2003

Linux pour les non-voyants / mal-voyants

Aujourd'hui, utiliser Linux quand on est aveugle ou mal-voyant, c'est possible, et trés facilement avec la distribution Oralux.

Cette distribution est basé sur la knoppix, dont elle peut être testée sans rien installer sur son ordinateur.

A noter que le site d'Oralux respecte les standards du web, n'utilise pas de table pour la présentation mais CSS, et respecte les principales recommandations d'accessiblité pour le web.

(source : linuxfr)

(Edit : il s'agit bien d'oralux et non d'oralinux comme je l'avais écrit auparavant)

jeudi, juin 19 2003

Cookies de session et sécurité

Après la lecture du billet de Denis le cybercodeur à propos des cookies et l'accessibilité, .je me vois contraint de faire le point sur le problème que pose le passage des ID de sessions dans les urls.

En effet, cela peut-être un gros trous de sécurité pour le site concerné.

Il faut garder en tête que les urls sont stockées un peu partout.

  • dans l'historique du navigateur : imaginez l'internaute dans un cybercafé, il s'identifie sur un site et l'id est passé dans les urls. L'internaute qui le succède sur la machine à alors facilement accés à sa session, puisqu'il retrouve tout dans l'historique. On peut imaginer que cet internaute mal-veillant puisse également regarder dans les cookies pour récupérer les cookies de sessions. Mais il y a moins de chance d'en retrouver : les cookies de sessions sont automatiquement effacés à la fermeture du navigateur.
  • dans les logs du serveur : Si il est possible de voir sur le site ses statistiques d'accès (générées par exemple par des outils comme awstats ou webalyser), il est alors possible parfois de voir les derniers liens qui ont été parcouru. Donc de voir éventuellement des identifiants de sessions.
  • dans les bookmarks
  • Sur d'autres sites !! Imaginez un internaute qui, sur un forum, veut faire découvrir à tout le monde une page intéressante d'un site qu'il a visité et pour lequel l'identifiant de session est transmis dans l'url, il va donc recopier l'url dans ce forum, et ainsi montrer à tout le monde son identifiant de session !
  • via des attaques de type CSS (à ne pas confondre avec les feuilles de styles :-).

Bref, un internaute malveillant peut avoir divers moyen de récupérer un identifiant de session, et donc de prendre l'identité d'un autre sur un site et faire toutes les actions malveillantes qu'il est possible de faire dans ce cas (vol de données personnelles, destruction du compte, changement des paramètres du compte, du mot de passe etc..).

Bien sûr, coté serveur, il est possible de limiter les dégâts : limiter la durée de vie des sessions aprés un temps d'inactivité, n'autoriser l'utilisation d'une session, qu'à partir de la machine qui a initié la session (en vérifiant l'IP), etc... Mais rien n'est fiable à 100%.

Le mieux est d'interdire le passage de l'id de session dans les urls (session.use_trans_sid à 0 dans le php.ini)

Pour les internautes : ne pas bookmarquer ou transmettre les urls contenant ces identifiants de session (reconnaissable grâce à la presence d'une longue suite de chiffres et lettres), utiliser la fonction "quitter" ou "déconnecter" du site si elle est présente, fermer son navigateur après utilisation, vider l'historique.

Ca limitera les éventuels dégats.

mercredi, mars 19 2003

Le flash : à utiliser avec modération

Je viens de trouver un lien, qui énonce 25 raisons de ne pas faire un site en flash, raisons que j'approuve totalement.

Mais je pense qu'il ne faut pas non plus abandonner l'idée d'utiliser le flash. Ce n'est pas si mal pour faire des animations, donner un peu de vie au site. Mais cela doit être utilisé uniquement pour de la présentation. Pas pour du contenu ou de la navigation.
Et puis, faut eviter aussi de les utiliser pour les pubs. Non seulement beaucoup de gens en ont marre de la pub, mais en plus bouffer de la bande passante pour ça, non merci !