Du Velours : - blog

Codes series

2007-08-19T00:12:00Z

Javascript :

la table des compatibilités DOM entre les navigateurs par Paul Peter Koch : W3C DOM Compatibility Tables
The window.onload Problem – Solved!
L’attribut defer de la balise <<script> pour IE : JavaScript: Defer Execution
javascript testing : OpenQA: Selenium
JavaScript 2 and the Future of the Web
Draw Line, Circle, Ellipse (Oval), Polyline, Polygon, Rectangle
Drag&Drop, DHTML for Images and Layers
ecmascript
Créer une extension Firefox : How to create Firefox extensions

Divers :

Des fiches de synthèses très pratiques sur HTML, CSS, javascript, PHP… : Cheat Sheets

Accessibilité :

joe Clark – le livre en ligne : Building accessible websites
Flash and Accessibility

[ tags: javascript accessibilité ]

Etre accessible ou ne pas être ? (partie2)

2007-03-11T23:54:00Z

Le 28 février dernier, je me posais une série de questions ici-même sur l’accessibilité des sites web. Comme bon nombre de disciplines sur le web, je me disais qu’il suffisait d’appliquer les bonnes pratiques d’accessibilité collectées ici ou là sur le web.

Or depuis j’ai eu la chance d’assister à la formation “Expert AccessiWeb en évaluation de l’accessibilité des sites web”. Enfin je n’ai assisté qu’à la première partie de la formation, la suite est prévue fin mars.

Tout ça pour dire que mes interrogations se sont largement dissipées, je vous délivre point par point les réponses que j’ai obtenues.

1. L’accessibilité fait-elle obstruction à l’esthétique ? Et donc est-elle un frein à la créativité ?
J’avais tendance à croire qu’effectivement il était difficile d’allier créativité et accessibilité. Je pense désormais que si on intégre les contraintes d’accessibilité dans le processus de création, l’esthhétique n’en pâtira pas spécialement. Le graphisme est une discipline comportant également des règles qu’il vaut mieux respecter si l’on veut aboutir à une bonne composition. Comme le support web a son lot de contraintes (de taille, de mise en page, de typographie), l’accessibilité a également les siennes.

2. Comment intégrer les critères d’accessibilité dans le processus de création, hormis le critère de contraste des couleurs ?
L’accessibilité affecte la création sur essentiellement deux points :

le contraste des couleurs : cette contrainte vise à rendre parfaitement lisible des textes qui peuvent parfois se fondre trop avec l’arrière-plan. En général, cette disposition est prise en compte sans se faire prier à de rares exceptions près. Il faut simplement apporter une attention particulière à ce critère pour qu’il n’y ait aucun doute sur des problèmes de lisibilité.
l’information donnée par la couleur est-elle aussi lisible lorsque la couleur est désactivée ? Par exemple un menu rendu actif par un simple changement de couleur n’est pas considéré comme accessible. En effet, un individu qui ne distingue pas les couleurs n’aura pas l’information. Ce critère est plus sensible pour la créativité. Il faut trouver une astuce graphique qui supplée le changement de couleur (une puce ou un souligné par exemple)

3. L’utilisation de javascript est-elle limitée pour des raisons d’accessibilité ?
Encore une idée reçue mais il est vrai qu’il est alors nécessaire de bien penser l’application web. Par exemple, ne pas oublier de rendre les actions javascript sur la souris également accessibles par le clavier, soit concrètement doubler ses fonctions onclick avec des onkeydown et ses fonctions onmouseover avec des onfocus.

4. L’accessibilité ne bride-t-elle pas les sites en Ajax ?
Il existe toujours une solution, essayez par exemple d’utiliser votre compte Gmail en désactivant javascript, et vous serez étonné de voir que ça fonctionne. En gros, il faut éxécuter côté serveur ce que l’on fait avec javascript côté client.

5. En pratique, les contrôles javascript sur les formulaires sont-ils considérés inaccessibles ?
Les contrôles javascript ne sont pas antiaccessibles, il faut simplement comme cité précédemment doublé ses contrôles côté serveur.

6. L’accessibilité est-elle un objectif ou un devoir ? ou doit-on plutôt se fixer comme objectif d’atteindre le plus haut niveau d’accessibilité possible ?
La première partie de cette question relève plus d’un problème politique sociale. Je répondrais simplement que le droit à l’information tout comme la liberté d’expression ne doivent pas être réservées à certaines catégories de populations. Il n’existe aucune justification à l’exclusion. Rendre les sites web accessibles serait donc un devoir. Il va sans dire donc qu’il faut autant que possible atteindre le plus haut niveau d’accessibilité.

7. Des concessions à l’accessibilité sont-elles possibles et lesquelles ?
Oui et les trois niveaux d’accessibilité définis par le WCAG (niveau A – niveau AA – niveau AAA) sont là pour prioriser les critères d’accessibilité.

8. Quel est le coût en termes de temps de dévelopement, et donc en termes financiers des nouvelles contraintes imposées par le souci d’accessibilité ?
Cela est très variable, je dirais que pour un site sans contenu multimédia, si l’on adopte les bonnes pratiques de codages à la source, la rallonge de temps est d’environ 10 à 20%. Pour les contenus plus riches (flash, vidéo, son) cela peut engendrer un surcoût énorme (sous-titrer les vidéo, faire une version texte d’un contenu sonore…)

Il ne me reste plus qu’à rendre mon site accessible ;)

[ tags: accessibilité développement ajax intégration standards ]

Les enseignements de Maître Zen

2007-03-06T22:07:00Z

Dave Shea a qui l’on doit le fameux CSS Zen Garden nous délivre ses bons conseils pour faire face aux difficultés de mise en page avec les CSS.

Un must !

[ tags: css dave shea conseils xhtml ]

Etre accessible ou ne pas être ?

2007-02-27T22:45:00Z

L’accesssibilité, dont il est désormais admis qu’elle constitue une avancée dans la manière de délivrer l’information sur le web, soulève un certains nombre de questions :

l’accessibilité fait-elle obstruction à l’esthétique ? Et donc est-elle un frein à la créativité ?
Comment intégrer les critères d’accessibilité dans le processus de création, hormis le critère de contraste des couleurs ?
L’utilisation de javascript est-elle limitée pour des raisons d’accessibilité ?
L’accessibilité ne bride-t-elle pas les sites en Ajax ?
En pratique, les contrôles javascript sur les formulaires sont-ils considérés inaccessibles ?
L’accessibilité est-elle un objectif ou un devoir ? ou doit-on plutôt se fixer comme objectif d’atteindre le plus haut niveau d’accessibilité possible ?
Des concessions à l’accessibilité sont-elles possibles et lesquelles ?
Quel est le coût en termes de temps de dévelopement, et donc en termes financiers des nouvelles contraintes imposées par le souci d’accessibilité ?

[ tags: accessibilité ajax développement intégration standards ]

CSS : retour aux sources

2006-12-27T03:52:00Z

Dans la série j’ai décidé de ne plus laisser la place aux lignes de codes hasardeuses, je me suis plongé dans les textes qui font office de bibles en matière de CSS, à savoir :

Design web : utiliser les standards de Jeffrey Zeldman
CSS de Eric Meyer
Le Zen des CSS de Dave Shea et Molly Holzschlag (à venir)

En effet, j’ai, comme on dit, appris sur le tas, c’est-à-dire la plupart du temps fureté sur internet toutes les bonnes sources disponibles. J’en profite pour rendre hommage aux sites qui m’ont le plus influencés qui sont dans le désordre “pompage.net” et sa mailing-liste “pompeurs”, openweb, et un peu plus tard, alsacréations. Je ne saurais être exhaustif de peur d’en oublier mais j’ai appris l’essentiel grâce à ces trois sources incontournables du web francophone.

Néanmoins comme dit l’adage, rien ne vaut un bon bouquin, j’ai donc décidé de rattraper mon retard en lisant ces trois livres anglosaxons de référence cités plus haut. Car il faut l’avouer, nos amis anglosaxons ont une certaine longueur d’avance en ce domaine, même si nos éminents webdesigners francophones sont d’un niveau exceptionnel. Je pense à Tristan Nitot, Laurent Denis, Eric Daspet, Denis Boudreau, Raphael Goetter, Emmanuel Clément, Stéphane Deschamps, Karl Dubost parmi les plus illustres (à mon sens bien sûr).

Au cours de ces lectures, j’ai donc pris note de quelques notions qui me semblaient jusqu’alors floues, voire totalement ignorées. Voici donc les principales :

une boîte de type “en ligne” devient de type “block” dès lors qu’elle est affectée de la propriété “position:absolute”
le prologue xml <?xml version="1.0" encoding="utf-8"?> fait passer Internet Explorer en mode Quirks, à éviter donc !
la propriété “text-align” ne s’applique qu’à des éléments de type “block”
les marges négatives ne font pas bon ménage avec IE, à éviter aussi !
un élément flottant sort du flux, la hauteur de l’élément parent ne tiendra donc pas compte de ses enfants flottants

[ tags: css standards astuces hommage ]