Le HTML vous connaissez ? Mais si, les pages de texte avec des images où rien ne bouge. Bon et bien le DHTML c’est la même chose mais avec des trucs qui bougent en plus.

Plus sérieusement, je vous propose de découvrir aujourd’hui un projet bien singulier : FACE est un framewok qui permet de faire des petites animations à l’écran sans avoir à utiliser Flash, sans connaître javascript et le tout dans le respect des standards web. Quelle est l’astuce ? Le recours à des propriétés des CSS ainsi qu’à des bouts de javascript le tout dans une syntaxe qui utilise le principe des noeuds :

En résumé : c’est gratuit, c’est compatible W3C, c’est relativement léger, donc : pourquoi pas ! Qui pourrait creuser un peu plus la question et nous donner un avis plus… avisé ?

Voilà une annonce qui risque de faire grand bruit : le W3C vient de publier une nouvelle version de travail des spécifications des CSS 3 dédiées à la mise en page : CSS3 Advanced Layout Module. La grande nouveauté vient du principe de construction de page reposant sur des gabarits (template en anglais).

Le principe consiste à découper une page en grandes zones qui vont accueilir du contenu. Dans l’exemple qui suit, 4 zones sont identifiées : en-tête (a), colonne de gauche (b), corps de page (c) et colonne de droite (d) :

La structure générale de la page sera construite selon un modèle de grille à l’aide de la propriété display-model qui s’apparente à la construction d’un tableau. Une fois cette structure générale définie, les différents éléments qui la constitue vont venir s’incruster dans ces zones à l’aide de la propriété position (ex : h1 {position: a;}).

Révolution ? Oui, ça a tout l’air d’une révolution dans la mesure où les propriétés CSS se substituent au travail des outils de gestion de contenu qui jusqu’alors avaient en charge la gestion des gabarits.

Je ne sais pas comment tout ceci va être accueilli par la communauté des développeurs mais je suis sûr d’une chose : les mises en page à l’aide de tableaux sont condamnées, la sentence vient de tomber aujourd’hui.

Je viens de finir le dernier livre de Dan Cederholm qui parle de conception web et des standards W3C : Bulletproof Web Design. Outre le fait que ce livre se lise très bien et que tous les exemples de code sont très bien expliqués, ce qui m’a le plus marqué dans cet ouvrage est l’approche à toutes épreuves que l’auteur y explique.

Le concept est le suivant : que deviendrait la mise en page de votre site si les images ou le code CSS était désactivé ? C’est à partir de cette question que l’auteur nous explique comment concevoir un site et des mises en page qui se dégradent proprement ou qui restent lisibles si l’on double la taille du texte. D’ailleurs à ce sujet le site de l’auteur est un bon exemple : SimpleBits.com.

Conclusion : un livre que je vous recommande vivement.

Souvenez-vous, l’an dernier j’avais rédigé un billet sur les apports de CSS 3 pour les formulaires (voir ce billet ici : Des formulaires standardisés) et notamment sur les pseudo-classes comme :valid, :invalid ou encore :required. Le Gou Blog vient de nous publier un billet sur le même thème qui tombe à pic : Un peu de CSS3 pour les formulaires…. L’auteur nous parle entre autre de pseudo-classes comme :disabled, :focus ou encore :checked.

Pourquoi cet article tombe à pic ? Tout simplement parce qu’à l’époque où j’ai rédigé mon billet, toutes ces pseudo-classes étaient encore de la science-fiction, alors qu’avec la sortie de Firefox 1.5 et autres Opera 8.5, ces pseudo-classes peuvent enfin être exploitées. Si vous n’êtes pas convaincu, je vous invite à regarder le formulaire test du sieur Gou ou encore à admirer cette superbe mise en page à deux colonnes réalisée bien entendu à l’aide de propriétés CSS 3.

Au cas où vous ne l’auriez pas compris, l’utilité de ces pseudo-classes est de standardiser la façon de concevoir un formulaire en proposant du code toujours plus limpide et un comportement uniforme.

Je suis surpris de l’absence de réaction dans la blogosphère française du dernier édito de Jakob Nielsen : Accessibility Is Not Enough. L’article est pourtant on ne peut plus équivoque : se conformer aux critères d’accessibilité est un indiscutable progrès mais n’est pas suffisant pour s’assurer que les non-voyants, et surtout les mal-voyants puissent utiliser un site ou service en ligne dans de bonnes conditions.

Dans ce cadre là, je souhaiterais vous parler d’une solution développée par mon agence qui pourrait apporter un début de réponse : Confort de Lecture. Il s’agit d’une solution complémentaire à une démarche d’accessibilité qui améliore la prise en main et l’utilisation d’un site.

Concrètement, à partir d’un site respectant un minimum de critères d’accessibilité (l’équivalent du niveau bronze), la solution Confort de Lecture agit comme un filtre. L’internaute définit ses paramètres d’utilisation (couleur de fond d’écran et des caractères, taille des polices…). L’ensemble des contenus adoptent les paramètres de mise en forme définis mais surtout l’intégralité du système de navigation est repensé pour correspondre effectivement aux mode de consultation des personnes non-voyantes ou mal-voyante. Ainsi navigation par le contenu, fil d’ariane, retour au sommaire en fin d’article sont les principaux éléments qui conditionnent une grande facilité d’usage pour les personnes en situation de handicap visuel mais aussi pour beaucoup d’autres situations de consultation du site (navigation via un téléphone mobile, un PDA…).

Cette solution a déjà été mise en oeuvre sur le portail HandicapZero et sur des sites de collectivités locales. Pour plus d’informations, vous pouvez également allez voir cet article : Lnet et le confort de lecture.

Je ne détaillerais pas d’avantage la plue-value de cette solution pour ne pas paraître partial, mais il me semble clair qu’elle a le mérite de répondre en partie aux interrogations de Jakob Nielsen en appliquant certains principes d’utilisabilité à l’accessibilité.

Et puisque que l’on parle d’accessibilité, qui s’est penché sur la dernière version des Web Content Accessibility Guidelines 2.0 ?

Le W3C vient de lancer un groupe de travail autour des interfaces riches et des API : W3C Launches Rich Web Client Activity. Et ça, c’est un très bonne nouvelle à plus d’un titre :

• cela va permettre l’élaboration d’un référentiel d’API et de classes pour différentes fonctionnalités et comportements évolués (persistance côté client, drag & drop, file upload, timed events…) ;
• cela va permettre de faire évoluer le DOM niveau 3 dans la bonne direction ;
• le W3C est la meilleure caution pour que les développement autour des API et d’AJAX se fassent dans un cadre structuré (respectant les standards).

Plus d’infos ici : W3C Web APIs Working Group.

Comme le fait fort justement remarqué Denis Bourdeau, le W3C a publié la semaine dernière un premier jet de spécifications (Working Draft comme ils disent) sur les XFrames.

Et là vous me demandez : c’est quoi les XFrames ? Et là je vous répond : Et bien… heuuuu… c’est un peu comme les iFrames… sauf que en fait ce sont des fichiers XML qui sont utilisés… donc en fait c’est comme les Data Island… mais c’est bien parce que l’on n’a pas besoin de rafraîchir toute la page… un peu comme avec AJAX…

Et là vous êtes perplexes devant une telle débauche d’acronymes et termes techniques. Ceci étant dit, ces nouvelles spécifications représentent un potentiel très intéressant. Et je remercie par avance l’âme charitable qui voudra nous expliquer dans un commentaire la différence entre XFrames, iFrames et Data Island.

En tout cas je peux vous assurer qu’après la lecture de ces spécifications, vous n’allez plus regardez les cadres du même oeil car les XFrames représentent une alternatives plus que valable aux antédiluvienne Frames.

Voilà une question bien embarrassante posée par ce billet de François Palaci : Accessibilité, neutralité et Culture. Il y est question de la définition du mot Accessibilité sur la version française de Wikipedia et visiblement les contributeurs ne sont pas tous d’accord sur la définition…

Le fond de l’histoire est le suivant : à partir de quand peut-on dire qu’un site est accessible :

• quand il est conforme aux normes de la WAI ?
• quand il est conforme au label Accessiweb ?
• quand il est conforme à des initiatives gouvernementales comme le label européen e-government good practices ?

Et la question n’est pas simple ! De mon point de vue, l’essentiel est d’oeuvrer dans le sens de l’accessibilité en règle général et non dans le sens d’une de ces normes en particulier. Mais je vous laisse vous faire une opinion par vous-même.

Le web évolue ou pour être plus précis, le web a évolué. Le concept de web 2.0 ne plaît pas, c’est un fait, n’en parlons plus. Plutôt que de spéculer sur l’avenir de l’internet, je vous propose plutôt que de vous retourner et de méditer sur le chemin parcouru.

A la base, c’est quoi une page web ?

Sans rentrer dans les détails, et en vulgarisant, une page web est composée de trois couches :

1. le contenu
2. la présentation
3. le comportement (les fonctionnalités et interactions)

Et maintenant, c’est quoi une page web ?

A peu près la même chose. Dans le fond, si vous observez bien la page que vous êtes en train de lire, hormis la date, vous auriez bien des difficultés à dater cette page.

Mais alors, y a-t-il eu évolution ? Oui ! Mais elle est subtile cette évolution.

Contenu : tout le monde lit-il la même chose ?

Non, définitivement. La preuve :

• si vous surfez sur mon site, vous aurez accès à l’ensemble du contenu des pages ;
• si vous utilisez un lecteur de flux RSS, il se peut que vous n’ayez accès qu’à des extraits de pages (les x premiers caractères) ;
• si vous utilisez un portail de syndication du type NetVibes, vous n’aurez accès qu’aux titres de mes billets ;
• si le contenu était formaté en XML et transformé à la volé via une feuille de style XSL vous pourriez aussi bien voir une page WAP qu’un fichier PDF.

En fonction de votre contexte d’utilisation, le contenu auquel vous aurez accès peut être complètement différent (plus ou moins riche).

Présentation : version dégradée ou allégée ?

Pour la présentation, c’est la même chose :

• si vous surfez sur mon site avec un navigateur récent (comme Firefox ou Opera) vous aurez devant vos yeux une mise en page sobre avec de jolis coins arrondis ;
• si vous utilisez un navigateur comme IE, vous aurez les mêmes couleurs mais plus de coins arrondis ;
• si vous imprimez cette page, plus de couleurs, mais une police de caractère plus adaptée à la lecture sur papier ;
• si vous utilisez un lecteur de flux RSS, c’est le style par défaut du lecteur qui sera utilisé ;
• si vous utilisez un navigateur alternatif (lecteur d’écran, PDA…) vous aurez une version encore plus dégradée ;
• si en plus, vous utilisez une extension du type GreaseMonkey qui altère le comportement de la page pour l’enrichir (ou la détourner), alors là… c’est la porte ouverte à tout.

En fonction du terminal et du logiciel d’accès à internet, la présentation de cette page sera également très différente.

Comportement : plus ou moins riche ?

Prenons l’exemple de la page suivante : The accessible AJAX calculator.

• si vous utilisez un navigateur qui se respecte, la réponse est rapatriée de façon dynamique sans avoir besoin de recharger la page ;
• si votre navigateur est plus ancien, il aura plus de mal à interpréter le bout de code AJAX et devra rafraîchir la page pour rapatrier le résultat ;
• si le javascript est désactivé sur votre navigateur la calculatrice ne fonctionnera pas, seuls les liens hypertextes seront actifs.

En fonction de la capacité de votre navigateur à interpréter des bouts de code, le comportement d’une page sera plus ou moins riche.

Conclusion

Vous l’aurez bien compris : une page web reste une page web, mais la notion même de page arrive à expiration :

• du contenu syndiqué (via RSS?) et modulaire (via XSL??) ;
• une présentation flexible (via CSS) et adaptable (à l’aide de l’attribut media) ;
• un comportement qui peut être dégradé (avec les balises <script> et <noscript>)…

Autant de petites évolutions qui au fil des ans ont fait évoluer les concepts de pages et de sites web. Les standards W3C, l’accessibilité, le web sémantique l’utilisabilité… sont autant de leviers pour proposer une utilisation plus riche de l’internet. Le tout au service des utilisateurs, pour une expérience en ligne plus agréable, plus performante, plus simple, plus puissante, plus… mieux, non ?

Et ce n’est qu’un début : les réseaux sociaux, les interfaces riches, les microformats… seront les leviers de demain pour bâtir celui-dont-on-ne-doit-pas-nommer-le-nom (pour ceux qui ne suivent pas, il ne s’agit pas de Voldemort !).

J’ai déjà eu l’occasion de faire l’article sur les standards du W3C. Aujourd’hui je vous propose de lire un article très intéressant sousl a forme d’une interview entre deux gourous du web : Why eBay needs Standards-Oriented Design: An Interview with Eric A Meyer. D’un côté il y a Jared Spool, l’un des ergonomes les plus influent de la planète et de l’autre il y a Eric Meyer, le dieu des CSS.

Le plus étonnant dans cet article, c’est que les points de vue de ces deux personnes se rejoignent : les standards web (XHTML, CSS, DOM…) améliorent le confort d’utilisation et sont une vrai source d’économie. Ils prennent ainsi l’exemple du site d’eBay qui pourrait économiser des millions de dollars s’ils se conformaient aux standards. Mais bon, il faut croire qu’ils ont de l’argent à dépenser… (rapport au rachat de Skype).