Le but est bien sûr d’optimiser jQuery pour ces nouvelles plates-formes, mais ce n’est pas tout : une version mobile de jQuery UI est également prévue !

Et plutôt que d’adapter jQuery UI à ces nouvelles contraintes, le projet consiste dans un premier temps à réfléchir sur les évolutions possibles du framework, de manière à ce qu’il prenne nativement en compte ces nouvelles interfaces.

Un des problèmes posés actuellement par jQuery UI est son système de gestion des thèmes graphiques, Theme Roller, qui est trop « simple » pour permettre de créer des interfaces complexes.

Prototype d’interface pour jQuery UI Mobile

Évidemment, une évolution en ce sens profiterait également au web « classique ».

Mon petit doigt me dit que ce qui va en sortir risque bien de s’appeler jQuery UI 2, librairie à la fois adaptée au mobile et au desktop, de manière évolutive selon la plate-forme de destination.

Vous pouvez voir quelques prototypes et suivre les étapes de développement sur cette page : http://wiki.jqueryui.com/Mobile

jQuery UI suit donc la même direction que ExtJS, qui vient récemment de sortir en « version » mobile : Sencha Touch.

Mais pourquoi associe-t-on systématiquement tactile (nouvelles possibilités d’interaction) et mobile (espace d’affichage réduit, bande passante et puissance limitées − pour l’instant) ?
Les deux problématiques (nouveau type d’interaction, et nouvelles dimensions d’écran) sont différentes, et existent aussi indépendamment l’une de l’autre.

Tout ceci me donne l’impression que le domaine des applications web (HTML5 Apps en buzz-language ;-) ) est dans une période de transition, et se dirige doucement vers une unification de ces « multiples web », tout en respectant les spécificités et contraintes de chaque interface.

Rendez-vous dans 10 5 2 ans !

En plus d’une superbe identité spécialement réalisée pour nous par Monsieur Grégoire, ce fut également l’occasion de nous amuser un peu : HTML 5 bien sûr, une CSS universelle pour se débarrasser de pépé et utiliser l’ensemble des sélecteurs CSS 2 (enfin !), ou encore l’API Yahoo Weather pour tenter de détecter le temps qu’il fait chez vous. Nous avons également utilisé une grille horizontale comme il se doit, mais également une grille verticale. L’accessibilité n’est pas en reste : l’intégralité du site fonctionne au clavier, avec ou sans Javascript.

La publication a été réorganisée en deux thématiques : les articles, que vous connaissez déjà, et les notes. Plus courtes que les articles, sans titres, leur principal objectif est de nous permettre de publier de petites informations, en vous proposant de réagir dans les commentaires.

Voici le détail des nouveautés qui accompagnent cette nouvelle identité.

Apparition des « notes »

L’organisation du blog a été légèrement revue : nous proposons désormais une page de présentation, parce que c’est quand même plus poli.

La veille des intégristes est toujours présente, seule sa présentation a changé. Cette page regroupe les différents liens qui nous passent sous les yeux, provenant de différentes sources : Google Reader, Delicious, Diigo.

L’autre nouveauté est la partie « notes », qui nous permettra de publier de courtes informations, rapidement. Nous pourrons y publier des questions, dont chacune sera un nouveau défi pour l’humanité : Vaut-il mieux mettre un attribut title sur un lien plutôt que sur l’image qu’il contient ? Peut-on obtenir une place au paradis si l’on n’utilise pas Textmate ?

HTML 5

Pour le passage à HTML 5, deux ressources furent principalement utilisées : l’indispensable spécification HTML 5, et le blog HTML5 Doctor. L’utilisation de certains éléments d’HTML 5 a soulevé beaucoup de questions, aussi n’hésitez pas à nous indiquer vos remarques à propos de leur pertinence.

Une CSS Universelle pour Internet Explorer 6

Internet Explorer 6 a bien vécu, et nous pensons qu’il est temps de lui offrir un repos bien mérité. C’est pourquoi nous avons pris la décision de proposer à ses utilisateurs une feuille de style universelle, qui affiche un style minimaliste, presque par défaut, sur l’ensemble du blog. Ainsi débarrassés de ce vieux farceur, nous avons pu profiter de toute la richesse des sélecteurs CSS 2, plus de 10 ans après leur recommandation par le W3C. Pas mal non ?

La grille verticale

En plus de la grille horizontale, un grille verticale a été utilisée pour ce thème. Vous pouvez la voir en cliquant sur ce bouton (un clic sur la grille permet de la masquer) : Afficher la grille. Pour tester la grille sur d’autres pages du blog, faites simplement glisser le lien dans votre barre de favoris.
Ainsi, le texte de la colonne de gauche est toujours aligné sur celui de la colonne de droite. Le tout apporte un rythme vertical très intéressant, mais les différences d’interprétation entre les navigateurs nous ont posé de nombreuses difficultés pour y parvenir. Nous sommes très heureux du résultat final, un je-ne-sais-quoi qui rend l’ensemble plus agréable pour la lecture.

La météo : Yahoo Weather API

Quelle est la fonctionnalité numéro 1 que doit proposer tout thème de blog qui se respecte ? La météo bien sûr !
D’accord, ce n’est pas à ce point nécessaire, mais on s’est dit que ce serait rigolo, hahaha ! Le système fonctionne de la manière suivante : lors de votre première connexion sur le blog, votre heure locale sera détectée à l’aide de Yahoo GeoPlanet API. S’il est tard, le thème s’affichera simplement en mode nuit. S’il fait jour, une autre requête sera envoyée à Yahoo Weather API, pour tenter de détecter le temps qu’il fait chez vous.
Et parce qu’il faut laisser un peu de place à Météo France dans le domaine, nous avons simplifié les 48 types de conditions de Yahoo Weather pour obtenir 5 modes. Vous pouvez également régler le thème sur le mode que vous préférez, à l’aide du module « Météo » présent dans la colonne de droite.

Alors alors ?

Nous sommes impatients de découvrir votre avis dans les commentaires : que pensez-vous de l’esthétique et de la structure de ce nouveau thème ?

Les intégristes vous souhaitent de joyeuses fêtes, pouet !

Cet article est destiné à des personnes ne connaissant pas ARIA. Vous devriez avoir une bonne connaissance du langage HTML et des problèmes que peuvent rencontrer les personnes handicapées sur le web. Connaître quelques application web « riches » (RIA) d’un point de vue utilisateur serait un plus.

Après avoir lu cet article, vous comprendrez à quoi sert ARIA, comment l’intégrer à vos sites, et comment l’utiliser dès immédiatement et même sur le plus simple des sites pour le rendre plus accessible.

Introduction

Le langage HTML (HyperText Markup Language) n’a pas été conçu pour créer des applications web. Le nombre de contrôles (bouton, case à cocher, etc.) qu’il propose est limité, et il est basé sur une communication client / serveur séquentielle. Les développeurs d’applications web ont contourné ces limitations en créant leurs propres widgets (contrôles graphiques) associés à Javascript pour leur ajouter le comportement désiré.

Malheureusement, les techniques utilisées pour outrepasser ces limitations ne sont absolument pas accessibles. Bien que ces widgets ressemblent à ceux d’une application bureau classique comme la représentation d’une arborescence (tree view), le rôle (ce que le widget fait), l’état (sa configuration, comme « checked » pour une case à cocher), et d’autres informations importantes ne sont pas disponibles pour les technologies d’assistance (comme les lecteurs d’écran). Ce serait comme styler une ligne de texte pour qu’elle ressemble à un titre, sans utiliser un élément définissant un titre (h1 à h6). Le texte ressemble à un titre, mais les technologies d’assistance n’ont pas accès à cette information.

Les mises à jour sont souvent mal perçues par les personnes utilisant une technologie d’assistance. Ces outils s’attendent à ce que le contenu change lors d’un événement de navigation « classique », comme un clic sur un lien ou un envoi de formulaire. Les applications web utilisent des techniques comme AJAX pour mettre à jour le contenu en arrière plan, ce qui peut passer inaperçu pour les technologies d’assistance. Si elles sont tout de même informées de ces mises à jour, l’utilisateur n’est pas pour autant informé que le contenu à été mis à jour, et n’a aucun moyen de localiser la zone mise à jour.

WAI-ARIA est une spécification qui propose la possibilité de définir une description des rôles, des états et des propriétés pour les widgets personnalisés, de manière à ce qu’ils soient reconnaissables et utilisables par les utilisateurs de technologies d’assistance. WAI-ARIA propose également un système permettant de s’assurer qu’un utilisateur de technologie d’assistance est informé des mises à jour de l’application.

Petit historique du langage HTML

Le langage HTML a été conçu pour être un système hypertexte, permettant de structurer et de partager des documents liés entre eux. Les premiers brouillons de la spécification HTML définissaient des balises comme des titres, des paragraphes, des listes, ou des ancres, pour ajouter une structure à des documents texte. La première proposition d’une spécification HTML par l’IETF incluait l’élément img, permettant d’ajouter des images à l’intérieur du document. La première spécification formelle fût HTML 2, basée sur les premiers brouillons de HTML. Cette spécification a défini les formulaires, ainsi que quelques composants d’interface permettant de créer des zones éditables, des boutons, des cases à cocher, des boutons radio, et des menus déroulants. Le petit ensemble de de contrôles définis dans HTML 2 n’a quasiment pas changé jusqu’à HTML 4.01, que nous utilisons actuellement.

Le modèle de communication de HTML est basé sur un modèle client / serveur : le client envoie des requêtes et reçoit des réponses ; Le serveur web attend les requêtes, les traite, puis renvoie une réponse au client. Puisque HTML ne définit pas de gestion de comportement, la communication est séquentielle : le client demande une page au serveur, le serveur traite la requête et renvoie une page au client.

Applications web

Les applications web essaient d’imiter les applications bureau classiques, mais ces applications web sont elles-mêmes exécutées à l’intérieur d’une application bureau : le navigateur. Il existe deux différences fondamentales entre HTML, avec son modèle de communication, et une application de bureau traditionnelle :

• Les applications de bureau possèdent une couche de comportement qui ne repose pas sur des requêtes serveur.
• Les applications de bureau possèdent un nombre bien plus élevé de widgets.

Reproduction d’applications bureau

Requêtes serveur en arrière plan

Pour simuler les applications bureau classiques, les applications web utilisent Javascript pour la partie comportement. Javascript peut par exemple être utilisé pour ouvrir et refermer un élément de menu lorsque l’utilisateur intéragit avec l’élément. Des données doivent parfois être récupérées sur le serveur : l’application peut par exemple récupérer des enregistrement dans une base de données pour mettre à jour des informations sur la page. Lorsque l’application doit interagir avec le serveur, des techniques comme AJAX ou un élément IFrame masqué sont utilisés pour communiquer de manière transparente avec le serveur.

Reproduire des composants riches (widgets)

Puisque HTML propose très peu de widgets (ndt : dans la suite de l’article, ce mot sera souvent utilisé pour désigner les contrôles d’interface), il est parfois nécessaire de créer des composants plus complexes pour une application web, comme une case à cocher proposant trois états, ou un bouton glissant (slider). Ces composants sont habituellement créés en utilisant des éléments graphiques couplés à Javascript pour qu’ils ressemblent et se comportent comme des composants natifs.

Figure 1 — Une boîte de dialogue avec une case à cocher proposant trois états.

Figure 2 — Un bouton glissant (slider) pouvant être utilisé pour indiquer la qualité d’un service.

Problèmes d’accessibilité avec la reproduction de composants natifs

Visuellement, créer des contrôles riches et effectuer des requêtes serveur en arrière plan permet de créer une meilleure expérience utilisateur. Malheureusement, ces techniques posent de graves problèmes d’accessibilité pour les utilisateurs de technologies d’assistance, comme les lecteurs d’écran.

• Les composants créés de cette manière sont rarement accessibles au clavier.
• Le rôle d’un composant, « ce qu’il fait », n’est pas accessible aux technologies d’assistance.
• Les états et propriétés d’un composant ne sont pas accessibles aux technologies d’assistance.
• Les mises à jour ne sont pas signalées aux technologies d’assistance.

WAI-ARIA à la rescousse

Tous les problèmes listés ci-dessus sont résolus par la specification WAI-ARIA (qui sera abrégée ARIA jusqu’à la fin de cet article) : Web Accessibility Initiative’s Accessible Rich Internet Applications. ARIA est une technologie positive : plutôt que de dire aux développeurs ce qu’ils ne peuvent pas faire, elle leur propose simplement de créer des applications web riches. ARIA est de plus une technologie très facile à implémenter.

Navigation au clavier

En plus de proposer une alternative aux éléments non-textuels, permettre d’interagir avec les contrôles d’interface à l’aide du clavier fait partie du minimum à mettre en place pour rendre un système plus accessible. Un développeur sensibilisé à l’accessibilité devrait réaliser des widgets dont les éléments permettent de recevoir le focus, tout comme le fait par défaut un élément input de type image (<input type="image" ...>). Malheureusement, la plupart des widgets ne sont pas réalisés de cette manière : ils utilisent plutôt des éléments comme img, ou peuvent être composés de plusieurs éléments placés dans un conteneur div qui ne reçoit pas le focus.

L’attribut tabindex est arrivé avec HTML4, utilisable sur les éléments suivants : a, area, button, input, object, select, et textarea. Cet attribut accepte un nombre positif compris entre 0 et 32767. La navigation commence avec les éléments ayant la plus petite valeur tabindex, et se poursuit jusqu’à l’élément ayant la valeur la plus élevée. Les éléments ayant pour valeur 0 sont visités dans leur ordre naturel d’apparition dans le code. Si le document a une structure logique, l’attribut tabindex n’est pas requis car les éléments d’interface sont naturellement définis dans l’ordre de tabulation.

ARIA étend l’attribut tabindex, lui permettant d’être utilisé sur tous les éléments visibles. ARIA autorise également l’utilisation d’une valeur négative pour les éléments ne devant pas être proposés à la navigation au clavier, mais pouvant recevoir le focus par programmation. Bien que la valeur d’un attribut tabindex négatif n’aie pas d’importance (l’élément ne pourra jamais recevoir le focus au clavier), la valeur -1 est couramment utilisée lorsqu’un élément ne doit pas recevoir le focus au clavier, mais uniquement par programmation.
Par exemple, vous pourriez réaliser un menu dont l’élément conteneur est accessible à l’aide de la tabulation clavier, mais pas les éléments qu’il contient. Ces éléments peuvent alors être programmés pour être parcourus à l’aide des touches fléchées du clavier. Ainsi, les utilisateur n’ont pas à utiliser la touche tabulation sur chacun des éléments du menu, ce qui leur permet de mieux accéder au document. C’est vrai pour tous les widgets ayant une série de composants nécessitant un accès au clavier, comme la représentation d’une arborescence.

Ajouter un élément à l’ordre naturel des tabulations

L’exemple suivant affecte la valeur 0 à l’attribut tabindex pour placer l’élément div dans l’ordre des tabulations, ce qui permettra d’y accéder à l’aide de la navigation clavier.

<div tabindex="0">
...
</div>

Tabindex négatif

L’exemple suivant utilise un tabindex d’une valeur négative, cet élément pourra alors recevoir le focus par programmation.

<div id="progaccess" tabindex="-1">
...
</div>

Dans cet exemple, l’élément div n’est pas placé dans l’ordre des tabulations, mais possède un attribut tabindex d’une valeur de -1. Le script qui suit sélectionne l’élément précédemment défini et utilise la méthode focus() pour activer le focus sur cet élément.

var objDiv = document.getElementById('progaccess');

// Focus on the element
objDiv.focus();

Que suis-je ?

ARIA propose l’attribut role pour définir les widgets, comme un bouton glissant (slider), ou définir la structure de la page, comme un menu. Un problème majeur des applications web est que n’importe quel élément peut être utilisé pour créer un widget. Les éléments HTML possèdent déjà des rôles prédéfinis. Le rôle d’un élément est « ce qu’il fait » – le rôle qu’il a dans la structure. Par exemple, le rôle des titres est bien compris par les technologies d’assistances. Lorsque des widgets sont réalisés à partir d’éléments existants, le rôle d’un élément est ce que la technologie d’assistance définit plutôt que ce qu’il représente visuellement en tant que widget. Par exemple, si le visuel d’un slider est créé en utilisant un élément img avec un texte alternatif approprié, un lecteur d’écran pourrait annoncer le contrôle comme ceci : « Image d’un slider », plutôt que quelque chose de plus intéressant, comme « Bouton glissant, 16 pour cents ».

Figure 3 — L’image d’un bouton glissant (slider) classique.

Le rôle donné par l’attribut role prend le pas sur le rôle natif de l’élément. Dans l’exemple suivant, un élément input possède un attribut role dont la valeur est slider (nous verrons d’autres propriétés ARIA plus loin dans cet article) — le rôle indiqué à la technologie d’assistance est slider (bouton glissant), plutôt que input (entrée utilisateur).

<input type="image" src="thumb.gif"
alt="Effectiveness"
role="slider"
aria-valuemin="0"
aria-valuemax="100"
aria-valuenow="42"
aria-valuetext="42 percent"
aria-labelledby="leffective">

Lorsque le focus est placé sur cet élément, un utilisateur de lecteur d’écran comprend ce que fait ce widget. La spécification ARIA propose une liste de rôles.

Rôle des sections du document (document landmark roles)

Les rôles que nous venons de voir permettent de décrire des widgets, mais il existe également des rôles permettant de décrire la structure du document. Les document landmarks (ou description des zones) sont un sous-ensemble des rôles classiques permettant aux utilisateurs de lecteurs d’écran de comprendre le rôle d’une zone pour mieux s’orienter dans le document.

Figure 4 — Une page classique avec une bannière, une barre latérale et une zone de contenu principale.

ARIA définit les rôles de document landmarks (zones du document) suivants :

article

Contenu ayant du sens par lui-même, comme un article ou un commentaire de blog, un message sur un forum, etc.

banner

Contenu à propos du site, comme le titre de la page ou le logo.

complementary

Permet éventuellement de définir une partie du contenu principal, mais est plus approprié pour du contenu séparé : la météo sur un portail web par exemple.

contentinfo

Contenu dépendant d’un autre, comme des notes de bas de page, un copyright, un lien vers la déclaration de confidentialité, un lien vers les paramètres de l’application, etc.

main

Contenu directement lié ou englobant le contenu central du document.

navigation

Contient des liens pour naviguer dans ou en dehors du document.

search

Cette section contient un formulaire de recherche permettant de chercher sur le site.

Les exemples suivants utilisent les rôles banner, navigation et main pour définir la structure de la page visible sur la figure 4.

<div role="banner">
...
</div>
<div role="navigation">
...
</div>
<div role="main">
...
</div>

États et propriétés d’ARIA

Les états (states) et propriétés (properties) d’ARIA permettent de décrire des informations supplémentaires sur les widgets et de les mettre à la disposition des technologies d’assistance, afin d’aider l’utilisateur à comprendre comment intéragir avec le widget. L’état définit une configuration ou une information unique sur un objet. Par exemple, la propriété aria-checked possède trois valeurs pour définir ses états : true, false et mixed.

Dans l’exemple du bouton glissant vu un peu plus haut, nous avons inclus différentes propriétés que nous allons voir ci-dessous, aidant à décrire un widget à une technologie d’assistance.

aria-valuemin

Stocke la valeur minimale qu’un bouton glissant peut avoir.

aria-valuemax

Stocke la valeur maximale qu’il peut avoir.

aria-valuenow

Stocke la valeur actuelle.

aria-valuetext

Stocke du texte lisible permettant à l’utilisateur de comprendre le contexte. "30 dollars", par exemple.

aria-labelledby

Stocke l’identifiant (attribut id) d’un élément contenant une description appropriée du widget.

Certaines propriétés peuvent être modifiées par programmation. Dans l’exemple suivant, les propriétés arial-valuenow et arial-valuetext de notre widget de bouton glissant sont mises à jour lorsque le bouton change de position :

// Définit les valeurs des propriétés ARIA
// lorsque le bouton change de position
objThumb.setAttribute('aria-valuenow', iValue);
objThumb.setAttribute('aria-valuetext', iValue + ' %');

Ajouter des rôles et attributs ARIA ne sera pas valide HTML 4.01 ou XHTML1.0, mais rassurez-vous, ARIA ne fait qu’ajouter des informations importantes à des spécifications écrites depuis un bon moment maintenant. Des travaux sont en cours pour définir une DTD pouvant être utilisée avec du XML modulaire, comme XHTML1.1. La spécification ARIA fournit une liste complète des états et propriétés permettant de définir des widgets accessibles.

Les « Live Regions » (zones mises à jour)

Les Live Regions permettent à certains éléments du document d’annoncer qu’ils ont été mis à jour, sans que l’utilisateur ne soit dérangé dans son activité. Cela signifie que les utilisateurs vont pouvoir être informés des mises à jour sans modifier leur position dans le contenu. Par exemple, une application de chat pourrait signaler une réponse de la personne avec qui l’utilisateur est en train de discuter, sans être déplacé en-dehors du champ permettant d’envoyer un nouveau message à la personne.

aria-live

Pour un utilisateur de lecteur d’écran, il est très difficile de comprendre ce qui a été mis à jour sur une page. ARIA propose la propriété aria-live, dont la valeur indique l’importance des mises à jour de la région. Voici les différents niveaux d’alerte pouvant être utilisés avec la propriété aria-live :

off

Il s’agit de la valeur par défaut, indiquant que la zone ne sera pas mise à jour.

<ul aria-live="off">

polite

C’est une notification normale, le comportement généralement attendu d’une Live Region. La valeur polite indique qu’il n’est pas nécessaire d’y répondre tant que l’utilisateur n’a pas terminé ce qu’il est actuellement en train de faire.

<ul aria-live="polite">

assertive

Ce niveau d’alerte est plus élevé que la normale, mais n’interrompt pas nécessairement l’utilisateur.

<ul aria-live="assertive">

rude

Cette valeur est la plus élevée, et interrompt l’utilisateur pour lui notifier la mise à jour. Il peut s’en trouver désorienté, et peut empêcher l’utilisateur de reprendre la tâche qu’il effectuait. Elle ne devrait être utilisée qu’en cas d’absolue nécessité.

<ul aria-live="rude">

Quelques autres propriétés peuvent être utilisées lorsqu’une Live Region est créée, en voici la liste.

La propriété aria-atomic

aria-atomic est une propriété optionnelle des Live Regions pouvant prendre comme valeur true ou false (par défaut si la propriété n’est pas définie).

Lorsque la zone est mis à jour, la propriété aria-atomic permet à la technologie d’assistance de savoir si elle doit décrire à l’utilisateur la zone entière ou seulement la partie ayant été mise à jour. Si cette propriété est définie à true, la technologie d’assistance devrait décrire complètement la zone. Si sa valeur est false, seule la partie mise à jour devrait être annoncée.

Dans l’exemple suivant, tous les éléments de la liste non-ordonnée seront annoncés à l’utilisateur, à moins qu’un de ces éléments ne surcharge la propriété aria-atomic.

<ul aria-atomic="true"
aria-live="polite">

La propriété aria-busy

aria-busy est une propriété optionnelle des Live Regions pouvant prendre comme valeur true ou false (par défaut si la propriété n’est pas définie). Si plusieurs parties d’une Live Region ont besoin d’être chargées avant que la mise à jour ne soit annoncée à l’utilisateur, la propriété aria-busy peut être définie à true jusqu’à ce que la dernière partie soit chargée, puis à false lorsque la mise à jour est complètement terminée. Cette propriété empêche les technologies d’assistance d’annoncer un changement avant qu’une mise à jour ne soit complétée.

<ul aria-atomic="true"
aria-busy="true"
aria-live="polite">

La propriété aria-channel

aria-channel est une propriété optionnelle des Live Regions pouvant prendre comme valeur main (par défaut si la propriété n’est pas définie) ou notify. Les canaux (channels) ont trait au matériel disponible sur le système de l’utilisateur, comme un synthétiseur vocal ou une plage Braille (ndt: lien ajouté). Si un seul canal est disponible, main et notify utiliseront tous deux le même canal. Le canal notify a une priorité plus élevée que le canal main.

<ul aria-atomic="true"
aria-channel="notify"
aria-live="polite">

La propriété aria-relevant

aria-revelant est une propriété optionnelle des Live Regions indiquant quels types de changements sont considérés comme significatifs à l’intérieur d’une zone (ajout d’un élément, suppression d’un élément et modification de texte). Cette propriété accepte une ou plusieurs des valeurs suivantes, séparées par des espaces :

additions

Des noeuds sont ajoutés au DOM à l’intérieur de la zone.

removals

Des noeuds sont supprimés du DOM à l’intérieur de la zone.

text

Du texte est ajouté ou supprimé du DOM (modification de texte).

all

Toutes les valeurs définies précédemment (additions, removals, text) s’appliquent à la zone.

En l’absence de la propriété aria-revelant, le comportement par défaut considère que les modifications significatives sont les modifications de texte et les ajouts de noeuds (aria-revelant="text additions"). L’exemple suivant n’annoncera des changements que si des noeuds sont ajoutés à la région. Si des modifications de texte surviennent ou que des noeuds sont supprimés, l’utilisateur n’en sera pas averti.

<ul aria-relevant="additions"
aria-atomic="true"
aria-live="polite">

Quand pourrons nous utiliser ARIA ?

L’utilisation d’ARIA ne présente aucun inconvénient, vous pouvez l’utiliser dès à présent. Les quatre principaux navigateurs du marché ont commencé ou prévoient de supporter ARIA. Opera 9.5 et Firefox 1.5+ disposent déjà d’un support ARIA. Internet Explorer 8 beta supporte ARIA, et l’équipe de développement de Webkit, le moteur libre utilisé par Safari (ndt: et Google Chrome), a annoncé que l’intégration d’ARIA avait commencé.

ARIA est également en train d’être largement adopté par les technologies d’assistance. JAWS 7.1+, Window-Eyes 5.5+, NVDA, Zoomtext 9+, et d’autres offrent déjà un support basique d’ARIA, et ce n’est qu’un début.

Soyez parmi les premiers à l’utiliser

Puisque nous venons de voir que l’utilisation d’ARIA ne provoque aucun effet de bord et que le support est déjà présent, il n’y a rien à perdre à l’utiliser dès maintenant, et beaucoup à gagner. Même si votre site web est le plus simple du monde, vous pouvez y inclure des document landmarks (rôles des sections) pour aider l’utilisateur à mieux naviguer et à s’orienter à l’intérieur du contenu.

Utilisez les rôles de section (document landmark roles)

Sur mon site web personnel, j’ai utilisé les rôles de zones main, navigation, search, et secondary. Prenons la structure suivante.

<div id="ads">
...
</div>
<div id="nav">
<form id="searchform" ...>
...
</form>
...
</div>
<div id="content">
...
</div>

Nous pourrions écrire l’attribut role pour nos document landmarks directement dans le code HTML :

<div id="ads" role="banner">
...
</div>
<div id="nav" role="navigation">
<form id="searchform" role="search" ...>
...
</form>
...
</div>
<div id="content" role="main">
...
</div>

Alternativement, puisque les pages sont structurées de manière à pouvoir être stylées avec CSS, la page a des chances d’être structurée à l’aide d’attributs id pouvant être passés à une fonction Javascript. L’exemple suivant est une fonction Javascript simple acceptant l’attribut id d’un élément et une valeur de role, lui permettant de définir l’attribut role de l’élément correspondant.

function addARIARole(strID, strRole)
{
// Find the element to add a role property to
var objElement = document.getElementById(strID);

if (objElement)
{
// Add the role property to the element
objElement.setAttribute('role', strRole);
}
}

La fonction peut alors être appelée en passant en paramètre l’attribut id de la section et son rôle dans le document. Considérez la structure de document ci-dessous : nous pourrions utiliser cette fonction Javascript pour insérer un attribut role, plutôt que de l’écrire dans le code HTML.

function setupARIA()
{
// Add ARIA roles to the document
addARIARole('content', 'main');
addARIARole('nav', 'navigation');
addARIARole('searchform', 'search');
addARIARole('ads', 'banner');
}

window.onload = setupARIA;

Indiquer les champs requis

Si certains de vos formulaires contiennent des champs requis, vous pouvez utiliser la propriété aria-required. Cette propriété indique qu’une entrée utilisateur est requise pour envoyer le formulaire. L’exemple suivant ajoute la propriété aria-required à un élément input classique.

<label for="contactname">Name</label>
<input type="text"
id="contactname"
name="contactname"
size="30"
aria-required="true">

Le système de blog WordPress a déjà commencé à utiliser l’attribut aria-required pour les champs requis du formulaire d’envoi de commentaire.

Ajouter d’autres propriétés pertinentes

Beaucoup de propriétés ARIA peuvent être utilisées sur des sites web très simples, comme aria-labelledby et aria-describedby. La propriété aria-labelledby pointe sur un ou plusieurs éléments considérés comme le libellé de l’élément, tandis que l’attribut aria-describedby pointe sur un ou plusieurs éléments considérés comme la description de l’élément.

<h2 id="limg">Paragliding</h2>
<p id="dimg">
A long description of our paragliding trip ...
</p>

<div>
<img src="takeoff.png"
alt="Getting ready to take off"
aria-labelledby="limg"
aria-describedby="dimg">
</div>

Priorité des attributs HTML

Les attributs ARIA ont la priorité sur le code HTML de base. C’est à dire que si aria-labelledby est utilisé parallèlement à <label for="">, seul l’attribut aria-labelledby sera pris en compte. L’élément label est toujours encouragé pour les anciens navigateurs ne supportant pas ARIA. Une technique simple pour éviter les conflits est d’utiliser l’attribut aria-labelledby pour faire référence à l’élément
label, ce qui permet d’être sûr que le libellé est lisible, quel que soit le support d’ARIA.

<label id="lblef" for="effectiveness">Effectiveness</label>

<input type="image"
role="slider"
id="effectiveness"
aria-labelledby="lblef"
...>

Parcourez la liste complète des états et propriétés pour en apprendre plus sur la manière dont ARIA peut vous aider à rendre votre contenu plus accessible.

Ensemble, maintenant

HTML n’a pas été conçu dans le but de créer des applications web, mais les développeurs les ont créées en dessinant leurs propres widgets, et en leur ajoutant des comportements avec Javascript. Le problème est que le rôle, l’état et les propriétés des widgets et du contenu mis à jour sur ces pages n’est pas correctement transmis aux technologies d’assistance. La spécification ARIA résoud ce problème en permettant aux développeurs de décrire précisément leurs éléments d’interface, leur structure de document, et les zones de la page qui seront modifiées.
Que vous développiez une application web complète avec de nombreux wigets et mises à jour dynamiques, ou le plus simple des sites web, vous pouvez commencer à utiliser ARIA dès maintenant pour vos utilisateurs handicapés.

Pour en savoir plus

• Bonnes pratiques WAI-ARIA
• Utiliser aria-required
• Utiliser aria-labelledby et aria-describedby
• Utiliser aria-invalid et role alert
• Exemple de case à cocher à trois états
  
• Un exemple de bouton glissant (slider) avec ARIA

Vous connaissez certainement jQuery, l’excellente bibliothèque Javascript. Non ? Alors c’est ici.

Le développement DOM/Javascript repose en grande partie sur les événements. Vous savez certainement qu’il est possible d’affecter un événement à un objet jQuery, c’est à dire qu’une fonction se déclenchera lors d’un événement sur l’objet sélectionné.

jQuery propose deux manières de définir les événements : nous allons les analyser.

Les « Event Helpers »

Joli nom. Pas très causant, mais sympa comme tout.

Il s’agit d’une série de méthodes, reprenant le nom des événements DOM. Elles prennent comme unique paramètre une fonction, et leur nom correspond à celui de l’événement DOM, allégé de son préfixe « on » (onclick, onmouseout, etc. ).

Si aucun paramètre n’est passé, cette méthode déclenche l’événement.

Si une fonction est passée en paramètre, elle s’exécutera lorsque l’événement sera déclenché (depuis le code comme vu juste au-dessus, ou « naturellement »).

Vous trouverez la liste complète de ces méthodes sur la page de documentation des événements : http://docs.jquery.com/Events.

Définir un événement

Commençons par un exemple. Tout le monde aime les exemples !

L’événement onclick peut être défini sur un objet jQuery à l’aide de la méthode click() à laquelle est passée une fonction :

$("a#test1").click(function(){
  window.alert("Clic sur a#test1.");
});

La fonction passée en paramètre peut attendre un paramètre. Il représente l’objet événement, et possède plusieurs propriétés et méthodes. J’ai l’habitude d’utiliser une variable nommée « e » (event), mais on peut évidemment utiliser un autre nom.

La méthode preventDefault() de cet objet permet d’empêcher le navigateur de déclencher son comportement par défaut.
Sur un lien, cette méthode empêchera simplement le navigateur de le suivre.

Exemple.

$("a#test1").click(function(e){
  e.preventDefault(); // Empêche le navigateur de suivre le lien.
  window.alert("Clic sur a#test1.");
});

Démonstration : a#test1

Déclencher un événement depuis le code

Il est parfois utile de déclencher un événement depuis le code. Pour cela, les mêmes méthodes seront appelées, mais cette fois sans paramètre.

Un exemple. « 例 », dirait un japonais, mais vous n’êtes pas obligé de me croire.

Nous allons réutiliser l’événement précédemment défini dans le premier exemple, en le déclenchant depuis le code.

Lorsque le lien du second exemple ( « a#test2″ ) sera cliqué, un clic sera déclenché sur le lien du premier exemple ( « a#test1″ ).

Exemple.

$("a#test2").click(function(e){
  e.preventDefault();
  window.alert("Clic sur a#test2, déclenchement du clic sur a#test1...");
  $("a#test1").click();
});

Démonstration : a#test2

La méthode ready()

Vous avez certainement déjà utilisé la méthode ready() d’un objet jQuery contenant l’objet DOM document.

Si un script est défini et exécuté dans la partie <head> d’une page et qu’il essaie de manipuler des éléments, le navigateur se comportera comme s’ils n’existaient pas.

Le script est exécuté au moment où il est lu par le navigateur (sauf avec l’attribut defer). Puisque la suite du document n’a pas encore été chargée, le navigateur n’a pas connaissance de ces éléments.

Pour remédier à cela, il est possible d’attacher un événement onload sur l’objet window, qui sera déclenché lorsque la page et tous ses éléments seront chargés.

Exemple.

$(window).load(function(){
  // Le code placé ici sera déclenché
  // au chargement complet de la page.
});

Il s’agit de l’équivalent jQuery du célèbre window.onload = function(){}. Évidemment, si un élément appelé sur votre page met un certain temps à répondre (une image hébergée ailleurs, ou votre outil d’analyse de statistiques basé sur un script externe), un long moment peut s’écouler avant que votre script ne soit exécuté.

C’est pourquoi la méthode ready() de l’élément document a été créée : la fonction affectée à cet événement sera déclenchée dès que le document HTML et les CSS seront chargés.

Le mécanisme de cet événement jQuery est plutôt intéressant. Il ne s’agit pas d’un événement natif DOM, ou pas tout à fait : Mozilla Firefox, Opera et les dernières versions de Webkit déclenchent bien un événement DOMContentLoaded lorsque le document HTML est chargé, mais Opera n’attend pas que les styles soient chargés pour le déclencher. On ne peut pas vraiment lui donner tort, puisque sur le brouillon de la spécification HTML5 rien n’est précisé à propos du chargement des styles.

jQuery résout ce problème sur Opera en attendant que chaque feuille de style soit disponible. Pour cela, la propriété disabled de chacun des objets contenus dans document.styleSheets (chaque fichier CSS) est testée jusqu’à ce qu’elle renvoie false, c’est à dire lorsque la CSS est chargée.

Pour Internet Explorer, l’astuce consiste à tester la méthode document.documentElement.doScroll("left"); jusqu’à ce qu’elle ne retourne plus d’erreur. Dès que c’est le cas, cela signifie que les styles sont chargés.

Pour Webkit, c’est la propriété document.readyState qui est testée, puis un test similaire à celui utilisé pour Opera se charge de vérifier le chargement complet des CSS.

Certains navigateurs supportent l’événement document.DOMContentLoaded (Mozilla Firefox), c’est donc ce dernier qui est utilisé.

Pour les navigateurs ne supportant pas document.DOMContentLoaded et n’entrant pas dans les cas particuliers traités par jQuery (Opera, Webkit, Internet Explorer), c’est un simple événement window.onload qui est utilisé.

Voilà, vous oubliez ça, jQuery le fait pour vous :

function bindReady(){
	if ( readyBound ) return;
	readyBound = true;

	// Mozilla, Opera (see further below for it) and webkit nightlies currently support this event
	if ( document.addEventListener && !jQuery.browser.opera)
		// Use the handy event callback
		document.addEventListener( "DOMContentLoaded", jQuery.ready, false );

	// If IE is used and is not in a frame
	// Continually check to see if the document is ready
	if ( jQuery.browser.msie && window == top ) (function(){
		if (jQuery.isReady) return;
		try {
			// If IE is used, use the trick by Diego Perini
			// http://javascript.nwbox.com/IEContentLoaded/
			document.documentElement.doScroll("left");
		} catch( error ) {
			setTimeout( arguments.callee, 0 );
			return;
		}
		// and execute any waiting functions
		jQuery.ready();
	})();

	if ( jQuery.browser.opera )
		document.addEventListener( "DOMContentLoaded", function () {
			if (jQuery.isReady) return;
			for (var i = 0; i < document.styleSheets.length; i++)
				if (document.styleSheets[i].disabled) {
					setTimeout( arguments.callee, 0 );
					return;
				}
			// and execute any waiting functions
			jQuery.ready();
		}, false);

	if ( jQuery.browser.safari ) {
		var numStyles;
		(function(){
			if (jQuery.isReady) return;
			if ( document.readyState != "loaded" && document.readyState != "complete" ) {
				setTimeout( arguments.callee, 0 );
				return;
			}
			if ( numStyles === undefined )
				numStyles = jQuery("style, link[rel=stylesheet]").length;
			if ( document.styleSheets.length != numStyles ) {
				setTimeout( arguments.callee, 0 );
				return;
			}
			// and execute any waiting functions
			jQuery.ready();
		})();
	}

	// A fallback to window.onload, that will always work
	jQuery.event.add( window, "load", jQuery.ready );
}

Vous l’aurez compris, il s’agit d’un extrait du code de jQuery.

Il existe deux autres « Event Helpers » particuliers, appelés « Interaction Helpers ». Les deux fonctionnent de la même manière, à la différence qu’ils attendent deux fonctions en paramètre plutôt qu’une.

La méthode hover() permet de spécifier deux événements, pour l’entrée et la sortie du curseur souris dans la zone que couvre le ou les éléments de notre objet jQuery. Mon vieil ami Superman appelle ce comportement le « survol ».

Ils ne sont pas tout à fait équivalents aux événements onmouseover et onmouseout, existant nativement en DOM.
En utilisant ces derniers, lorsque le curseur se déplace d’un élément à un autre au sein de l’élément sur lequel est attaché l’événement (par exemple lorsqu’il passe sur une image se trouvant à l’intérieur d’un élément <div>), onmouseover sera déclenché sur l’image (sur laquelle aucun événement n’est défini), et « remontera » jusqu’à son conteneur, pour déclencher une seconde fois l’événement. La cible de l’événement va également changer, ce sera l’image et non le conteneur.
En sortant le curseur de l’image, même problème : c’est cette fois l’événement onmouseout qui sera déclenché sur le conteneur, mais avec l’image pour cible.

Pour en savoir plus, c’est ici : http://www.quirksmode.org/js/events_mouse.html

Si nous ne voulons pas de ce comportement, il faut vérifier que l’élément survolé au déclenchement de l’événement corresponde bien à l’élément sur lequel l’événement a été défini. C’est fastidieux. jQuery s’en charge automatiquement lorsque vous utilisez hover().

La seconde méthode est toggle(). Elle est équivalente à la méthode click(), mais la deuxième fonction passée sera déclenchée une fois sur deux à la place de la première, ce qui est très intéressant, par exemple pour faire apparaître et disparaître en alternance un élément à chaque clic sur un bouton. Vous pouvez également passer plus de deux fonctions, elles seront alors exécutées les unes à la suite des autres, à chaque clic.

Les méthodes bind et trigger (affecter et déclencher)

La méthode bind()

Vous pouvez utiliser la méthode bind() pour affecter un ou plusieurs événements à un objet jQuery. Voici une première différence avec les « Event Helpers » vus au-dessus. Le premier paramètre doit être une chaîne de caractère, représentant les événements (séparés par des espaces) sur lesquels sera exécutée la fonction passée en deuxième paramètre. Allez !

Exemple.

$("a#test3").bind("mouseover mouseout", function(e){
  $(this).text( "-- " + $(this).text() + " --" );
});

Démonstration : a#test3

Deux événements « spéciaux » sont disponibles avec la méthode bind() : mouseenter et mouseleave.
Ils correspondent à l’entrée la sortie du curseur sur un élément, sans déclencher l’événement lorsqu’un élément enfant est survolé. Ces événements correspondent à ceux définis par la méthode hover().

La méthode trigger()

Comme pour les « Event Helpers », il est possible de déclencher depuis le code un événement défini sur un élément. La méthode trigger() sera utilisée.

Exemple.

$("a#test4").bind("click", function(e){
  e.preventDefault();
  jQuery("a#test3").trigger("mouseover");
});

Démonstration : a#test4 : un clic sur ce lien déclenchera un survol sur l’élément a#test3 (démonstration précédente)

Supprimer un événement avec unbind()

Supprimer un événement est trivial. Il suffit d’appeler la méthode unbind() en lui passant en paramètre le ou les événements à supprimer. Si aucun événement n’est passé en paramètre, tous les événements affectés à cet objet jQuery seront supprimés.

Vous avez également la possibilité de passer en second paramètre une référence vers une fonction en particulier, de manière à ne pas supprimer toutes les fonctions attachées à cet événement.

Exemple.

function affiche1(){
  window.alert('1');
};
function affiche2(){
  window.alert('2');
};

$("#test").bind("click", affiche1);
$("#test").bind("click", affiche2);

// Si le script s'arrêtait ici, un clic sur l'élément afficherait "1" puis "2"

$("#test").unbind("click", affiche1);

// Mais la première fonction attachée à l'événement a été supprimée en passant sa référence, seul "2" est affiché

Passer des données à un événement

La méthode trigger() permet également d’envoyer des données à la fonction déclenchée par l’événement. On passera alors ces données en second paramètre, après le nom de l’événement. Elles seront regroupées dans un tableau, sauf si un seul paramètre est passé : vous avez alors la possibilité de le passer directement.

$("a#test5").trigger("click", ["paramètre 1", 2, {parametre: "3"}]);

Lors de la définition de l’événement avec la méthode bind(), la fonction passée en paramètre devra définir ces paramètres pour pouvoir les utiliser.
Tous les paramètres supplémentaires sont ajoutés après le premier, qui représente toujours l’objet événement (« e » dans l’exemple suivant).

Exemple.

$("a#test5").bind("click", function(e, param1, param2, param3){
  e.preventDefault();
  window.alert(param1); // Affiche "paramètre 1"
  window.alert(param2); // Affiche "2"
  window.alert(param3["parametre"]); // Affiche "3" (cet argument est un tableau associatif)
});

Démonstration (cliquez sur le bouton) : Déclencher un clic sur a#test5, a#test5

Essayez maintenant de cliquer sur le lien juste au-dessus, vous verrez que les paramètres ont la valeur undefined la boîte de dialogue déclenchée par window.alert ne s’affiche même pas pour le troisième paramètre : le fait d’appeler une clé inexistante (param3["parametre"]) déclenchera une erreur Javascript.

Comme dit plus haut, si un seul paramètre est passé, vous pouvez l’utiliser directement :

Exemple.

$("a#test5").trigger("click", "paramètre 1");

Bien entendu, la fonction n’attend qu’un paramètre dans ce cas :

$("a#test5").bind("click", function(e, param1){
  e.preventDefault();
  window.alert(param1); // Affiche "paramètre 1"
});

Les événements « sur mesure »

Il est possible d’utiliser bind() pour affecter un événement personnalisé. Cet événement ne pourra être déclenché qu’avec la méthode trigger().

- A quoi ça sert, exactement ?
- Principalement, à découper certaines parties d’un script, liées à un objet jQuery, en événements. Mais c’est quoi ces questions ? C’est pour me déstabiliser, c’est ça ?

Prenons un lien, auquel nous attacherons l’événement « StyleFunky ». Lorsque cet événement sera déclenché, notre lien va naturellement s’imposer dans le page, montrer à tous qu’il n’est pas le genre de lien qu’il fait bon prendre pour une ancre. En réalité, un ensemble de propriétés CSS seront définies sur cet élément, ainsi qu’un window.setInterval() pour changer sa couleur de fond, mais ce sera transparent pour nous, une fois notre fonction définie. Seul l’événement « StyleFunky » sera ensuite déclenché.

Nous attacherons également un autre événement à ce lien, « StyleNormal », qui annulera les effets de l’événement précédent (y compris le window.setInterval) :

Exemple.

$("a#test6").bind("StyleFunky", function(){
  var jElt = $(this);
  jElt
  .css({
    "display": "block",
    "padding": "20px",
    "fontSize": "300%",
    "fontWeight": "bold",
    "textAlign": "center",
    "color": "#fff",
    "background": "#f00"
  });
  jElt.data("redBackground", true);
  jElt.data("interval", window.setInterval(function(){
    if (jElt.data("redBackground")) {
      jElt.css("background", "#f0f")
    } else {
      jElt.css("background", "#f00");
    }
    jElt.data("redBackground", ! (jElt.data("redBackground")) );
  }, 500));
});
$("a#test6").bind("StyleNormal", function(e){
  var jElt = $(this);
  window.clearInterval(jElt.data("interval"));
  jElt.css({
    "display": "inline",
    "padding": "0",
    "fontSize": "100%",
    "fontWeight": "normal",
    "textAlign": "left",
    "color": "#7F89A6",
    "background": "none"
  });
});

Demostración (c’est de l’espagnol) :
$(« a#test6″).trigger(« StyleFunky ») $(« a#test6″).trigger(« StyleNormal »)

a#test6

Les Namespaced Events (événements nommés)

Nous avons vu qu’il était possible avec unbind() de supprimer une seule des fonctions attachées à un événement, mais cette méthode est peu élégante, puisqu’elle n’autorise pas l’utilisation de fonctions anonymes.

Pour remédier à cela, jQuery permet de nommer une fonction attachée à un événement.
Une notation similaire à celle des classes CSS est utilisée, accolée au nom de l’événement (« .action1″, « .action2″ et « .action3″ ici) :
$(element).bind("click.action1", function(){ /* Action 1 */ });
$(element).bind("click.action2", function(){ /* Action 2 */ });
$(element).bind("click.action3", function(){ /* Action 3 */ });

Il sera alors possible de déclencher un événement en particulier en ciblant une fonction événement en particulier, ou toutes les fonctions attachées, en déclenchant simplement l’événement « click » :
$(element).trigger("click.nom1"); /* Déclenche l'action 1 */
$(element).trigger("click"); /* Déclenche les actions 1, 2 et 3 */

Évidemment, il sera possible de les supprimer, individuellement, ou non.
$(element).unbind("click.nom1"); /* Supprime l'action 1 */
$(element).trigger("click"); /* Déclenche les actions 2 et 3 (la 1 vient d'être supprimée, sois attentif) */

La méthode .triggerHandler()

Pour finir, la méthode triggerHandler() permet de déclencher les différentes fonctions attachées à un événement, sans déclencher l’action par défaut du navigateur.

Prenons l’événement focus sur un champ texte de formulaire. Si vous lui affectez une action particulière (comme afficher une bulle d’information), vous pourrez alors déclencher cette action sans déplacer le curseur de l’utilisateur dans le champ :
$(input[type=text]).bind("focus", function(){ /* Affichage de la bulle d'information */ });
$(input[type=text]).trigger("focus"); /* Déplacement du curseur dans le champ texte, affichage de la bulle d'information */
$(input[type=text]).triggerHandler("focus"); /* Affichage de la bulle d'information seulement */

Voilà, c’est fini.

La date de sortie de Firefox 3 a été fixée au 17 juin.

Safari 3.1 attend ses nouveaux camarades depuis quelques temps déjà.

Dans quelques jours, les internautes auront à disposition trois navigateurs web d’excellente qualité.

Javascript

Les performances de Javascript sont plus élevées que jamais, et c’est loin d’être fini :

Firefox 4 utilisera le moteur ECMAScript de Flash Player, Tamarin.

Le projet Webkit (le moteur de rendu utilisé par Safari) est lui aussi en train de passer à un nouveau moteur Javascript, SquirrelFish, qui est extrêmement rapide.

Le nom de code de la prochaine version du navigateur Opera est Peregrine, « pèlerin » en français, et il n’a pas été choisi au hasard :

Le faucon pèlerin, ou Falco peregrinus (Tunstall, 1771), est un rapace robuste de taille moyenne, réputé pour être l’oiseau le plus rapide du monde. Les mesures de la vitesse lors de la phase plongeante de l’attaque varient généralement entre 130 et 184 km/h. La vitesse maximale mesurée serait de 390 km/h.

CSS

CSS 2.1 est maintenant correctement supporté dans ces trois navigateurs (Firefox 3 permet enfin d’utiliser la propriété display:inline-block !), et de plus en plus de propriétés CSS 3 (qui n’est pas une recommandation et continue d’évoluer) sont d’ores et déjà implémentées.

Évidemment, Firefox passe avec succès le test Acid2.

HTML

Certains éléments de la future recommandation HTML5 (encore loin d’être finalisé) commencent réellement à être utilisables.

L’élément canvas est en plein explosion. Les exemples suivants utilisent cet élément et fonctionnent sur Firefox 3, Opera 9.5 et Safari 3.1 :

• Canvascape, une démo de moteur 3D de type « Doom-like ».
• Un clone de Mario Bros
• Un clone de Super Mario Kart
• Bomomo, une expérimentation très intéressante
  
• Pixastic, un outil de retouche photo
• Un jeu d’échecs en 3D

Ce n’est qu’un début : l’élément canvas3D devrait permettre d’utiliser l’accélération 3D des cartes graphiques.

Le support de SVG s’améliore encore, et il est maintenant aussi simple d’afficher des images vectorielles que d’afficher une image bitmap (Jpeg, PNG) dans une page. Les nouvelles versions de Safari et d’Opera permettent d’utiliser des images SVG dans la propriété CSS background-image.

Des versions expérimentales de Firefox, Opera et Safari permettent d’utiliser l’élément video défini dans HTML5.

Et Internet Explorer ?

Il semblerait que plus personne n’attende quoi que ce soit de ce navigateur. L’innovation sur le web, longtemps paralysée, est enfin repartie à plein régime, laissant de côté ce navigateur.

Internet Explorer 6 est toujours en circulation, et la plupart des sites se doivent encore de le prendre en compte aujourd’hui, mais on est très loin des méthodes de conception utilisées il y a quelques années : créer différentes versions d’un site par navigateur est non seulement impossible, mais également inadapté au web d’aujourd’hui, standard et universel.

Les méthodes de travail ont changé : un site est d’abord conçu pour les standards, puis adapté pour Internet Explorer, de manière plus ou moins élégante. Des hacks existent pour émuler SVG, l‘élément canvas et CSS2.1. Les exigences pour ce navigateur ont été globalement revues à la baisse : l’essentiel est que l’internaute accède aux informations.

Internet Explorer 8 nous promet de belles choses, mais personne ne l’attend plus. Le choix et l’innovation sur le web sont définitivement de retour, et ils s’en passeront volontiers.

Comment voyez-vous l’évolution du web dans les douze prochains mois ?

Pour cela, il existe plusieurs solutions.

Eviter les embrouilles

Avec la pratique, un certain nombre de réflexes se mettent en place, et on anticipe immédiatement les problèmes.
Un float:left, avec une marge sur sa gauche ? Un display:inline placé dans la même déclaration permet d’éviter le bug de la double marge. Tous les navigateurs ignorent ce display:inline, car la propriété float est prioritaire. C’est toujours ça de pris.

Malheureusement ça ne suffit pas toujours, et il n’y a parfois d’autre solution que de déclarer une propriété spécialement pour IE.

Le bon vieux hack

Allons-y joyeusement, il faut résoudre un bug sur IE6, et les hacks semblent pratiques et simples à utiliser.
Allez, au hasard… Le sélecteur d’enfant : html > body

IE6 ne comprend pas le sélecteur « > ». Il donc est possible de profiter de ce bug pour cibler IE6, de cette façon :

.my_element{margin-left:5px;} /* Cette déclaration est interprétée par tous les navigateurs */
html > body .my_element{margin-left:8px;} /* ... Puis est écrasée par la suivante, sauf pour IE6 qui ne comprendra pas cette déclaration. */

C’est pratique. Seulement IE7 ne corrige pas le bug pour lequel nous devions corriger la propriété margin. Pour le sélecteur d’enfants, pas de problème, IE7 l’interprète. Logiquement, le bug réapparaît.

En suivant la même méthode, il faut donc trouver un nouveau bug de sélecteur dans IE7, et revoir la CSS. Il arrive également que IE7 ne doive pas recevoir la même correction. Il faut donc trouver un bug qui s’applique à IE7 mais pas à IE6.
Et comment être sûr de ne cibler qu’IE6 ? Un autre navigateur ne prenant pas en charge ce sélecteur pourrait exister.

Il nous faut une autre solution, permettant de cibler efficacement Internet Explorer.

Les commentaires conditionnels

Microsoft a ajouté quelque chose de formidable à Internet Explorer : les commentaires conditionnels.

Ils permettent de ne servir un contenu qu’à Internet Explorer en général, ou à une de ses versions, en utilisant une syntaxe particulière à l’intérieur de commentaires HTML.

Ils n’ont certainement pas être prévus pour ça au départ, mais ils sont aujourd’hui principalement utilisés pour corriger les bugs de ce navigateur.

Il est donc possible d’utiliser le code suivant :

<!--[if IE 6]> <link rel="stylesheet" href="styles/internet-explorer-6.css" type="text/css" media="screen" /> <![endif]-->

Pour un navigateur suivant la spécification HTML4.01, la balise <link> est simplement ignorée car elle est placée dans un commentaire, mais pas pour Internet Explorer. Il va lire ce commentaire, et si une condition est déclarée, et qu’elle correspond au navigateur utilisé, le code sera tout de même interprété.

Cette solution est fiable, car il n’existe aucune raison pour qu’un autre navigateur interprète, dans le passé ou l’avenir, un commentaire de ce type.

Il est donc possible de créer une CSS pour IE6, une autre pour IE7 au cas où, et allez, encore une pour les versions d’IE inférieures à 8, histoire de cibler toutes les version passées de ce vieil ami.

Nous voici donc avec notre feuille de style, et une, deux voire trois nouvelles pour Internet Explorer. Si les CSS du site sont réparties sur plusieurs fichiers, il va falloir créer autant de nouveaux ensembles de fichiers « IE », ou les utiliser de manière globale en prenant le risque d’appliquer à certaines pages des styles qui ne leur sont pas destinés.

Avec le temps, cette solution est beaucoup moins pratique : il faut jongler avec plusieurs fichiers, se souvenir que la déclaration de la ligne 310 du fichier « home.css » est corrigée à la ligne 14 du fichier « internet-explorer-6.css », mais aussi à la ligne 8 du fichier « internet-explorer-7.css ».

Il se pourrait aussi qu’un jour cette correction provoque un effet indésirable, placée dans un certain contexte. Il faudrait alors se souvenir que cet élément a été corrigé dans l’autre CSS, et que cette correction peut être la cause du dysfonctionnement.

Mais existe-t-il une méthode fiable et pratique ? P’t'êt’ bien, ouais.

Les commentaires conditionnels, en plus malin

Il s’agit avec cette technique d’utiliser les commentaires conditionnels non pas pour appeler une feuille de style, mais pour entourer la page d’un conteneur qui prendra comme attribut « id » IE6, IE7, IE ou encore NOTIE.

Cet identifiant permettra de cibler précisément une version d’Internet Explorer, dans une CSS « normale ».

Le code se présente sous cette forme :

<body>
<!--[if IE 6]><div id="IE6"><![endif]-->

Et avant la balise de fermeture </body> :

<!--[if IE 6]></div><![endif]-->
</body>

Pour les navigateurs « normaux » et un outil de validation html, il s’agit de commentaires html tout à fait classiques, et sont ignorés.

De cette manière, il est aussi possible d’ajouter le support d’IE, en ajoutant une balise d’ouverture <div id="IE7"> en haut et en modifiant la condition du bas pour cibler IE6 et IE7 à la fois.

Nous pouvons aussi utiliser des conditions de type « n’est pas », ce qui permet de cibler tous les navigateurs sauf IE.

Voici le code modifié :

<body>
<!--[if IE 6]><div id="IE6"><![endif]-->
<!--[if IE 7]><div id="IE7"><![endif]-->
<!--[if (IE) & (!IE 6) & (!IE 7)]><div id="IE"><![endif]--> <!-- Pour les anciennes et prochaines versions d'Internet Explorer (autres que 6 et 7) -->
<!--[if !IE]>--><div id="NOTIE"><!--<![endif]--> <!-- Le commentaire est fermé, puis rouvert -->

<!-- Structure HTML de la page -->

</div> <!-- Une simple fermeture de balise à la fin, car tous les navigateurs sont ciblés. -->
</body>

Il suffit ensuite d’utiliser ces sélecteurs de la même manière qu’un hack, mais plus clairement, plus facilement et surtout de manière fiable :

.mon_element{margin-left:2px;}
#IE .mon_element{margin-left:3px;}
#IE6 .mon_element{margin-left:4px;}
#IE7 .mon_element{margin-left:5px;}
#NOTIE .mon_element{margin-left:6px;}

Evidemment l’exemple est stupide, puisqu’il n’y a aucune raison de cibler tous ces éléments à la fois.

Les avantages sont nombreux :

• C’est fiable : une nouvelle version d’Internet Explorer sera considérée comme « standard » (mais attention à l’utilisation de #NOTIE, qui ne sera vraisemblablement pas reconnue par les futures version d’Internet Explorer)
• Une seule CSS à maintenir
• Le code HTML et CSS reste parfaitement valide
• La déclaration a du sens, il n’est pas utile de commenter ceci : #IE6 .mon_element{margin:-3px;}
• Lors de la sortie d’une nouvelle version d’IE, il suffit de lister les bugs qui n’ont pas été corrigés, et d’ajouter une nouvelle déclaration (IE8) pour ceux-ci.

A vous ensuite de composer avec ces différents exemples pour créer une structure adaptée à vos besoins : l’utilisation des éléments <div id="IE6"> et <div id="IE7"> devraient suffire à la majorité des cas.

Il y est question de différentes solutions regroupées sous l’appellation « engagement progressif », permettant à vos visiteurs de comprendre et d’utiliser votre service avant (ou pendant) l’inscription, en évitant autant que possible le classique et indigeste formulaire d’inscription.

Les formulaires d’inscription doivent disparaître

Nous sommes heureux de vous présenter un extrait du chapitre 13 du prochain livre de Luke Wroblewski : Web Form Design: Filling in the Blanks (Rosenfeld Media, 2008). — Ed.

Je vais simplement dire ceci : les formulaires d’inscription doivent mourir. Dans l’introduction de ce livre, je décris le processus de découverte ou de recommandation d’un service web. Vous arrivez sur le site, empressé d’essayer ce nouveau service, et que trouvez-vous en guise d’accueil ? Un formulaire d’inscription.

Nous pouvons faire mieux. En fait, je pense que l’on peut amener des personnes à utiliser un service web en leur expliquant comment il fonctionne, et pourquoi ils devraient l’utiliser. Je pense également que nous pouvons y parvenir sans leur faire remplir un formulaire dès la première étape.

Mais avant d’aborder le potentiel de l’engagement progressif (la route vers un enregistrement « imperceptible »), regardons comment fonctionne le processus d’engagement classique pour un service en ligne. 2007 fut une grande année pour la vidéo en ligne. Nous pouvons supposer que nombre de personnes se connectent aujourd’hui pour publier une de leurs vidéos. Peut-être ont-ils entendu que Google Video était un bon service pour y parvenir. Dès l’arrivée sur le site, ils trouvent un lien pour partager leurs vidéos, et que se passe-t-il ensuite ? Le formulaire illustré sur la figure 13.1. apparaît.

Figure 13.1
Un formulaire d’enregistrement accueille les nouveaux clients de Google Vidéo.

Vous devez leur donner votre adresse email, choisir un mot de passe, indiquer votre nom, votre adresse, déchiffrer cet étrange mot, accepter les conditions d’utilisation et enfin, vous verrez ce qu’il y a après ce formulaire.

Contrastons maintenant cette approche avec celle d’un autre service vidéo en ligne : Jumpcut. Sur la page d’accueil, les actions principales sont « Make a movie » (Créer un film) et « Try a demo » (Démonstration), comme illustré sur la figure 13.2 (Ndt : la page a changé : un bouton « Register » -Créer un compte-, dirigeant sur l’identification ou la création d’un compte Yahoo, a pris place au centre de la page…). Jumpcut vous explique immédiatement comment fonctionne leur service, et en quoi il peut vous intéresser. Allons-y.

Sélectionner « Make a movie » (Créer un film) affichera un simple champ permettant saisir le titre de votre vidéo, et quelques options que vous pouvez utiliser pour envoyer les différents fichiers utilisés pour la création de votre vidéo. Choisir « Upload » (Téléchargement) dans cette liste vous permettra d’ajouter des images, du son et de la vidéo depuis votre ordinateur. Ceci fait, vous êtes dirigé vers l’outil de création vidéo en ligne de Jumpcut. Vous pouvez modifier votre vidéo, ajouter des styles, coordonner vos sons, vidéos, images, etc.

Figure 13.2
Le processus d’ajout de vidéo à Jumpcut vous présente le service que propose le site : l’édition vidéo en ligne.

Jusqu’à présent, aucun formulaire. Ce n’est qu’au moment où vous voudrez publier ou partager votre film que Jumpcut vous demandera votre nom et votre email, ainsi vous et les autres utilisateurs pourrez accéder au film que vous venez de créer. A travers ce processus, vous avez vu ce que permettait de faire Jumpcut, et cela sans avoir à passer par un formulaire d’inscription. Il s’agit d’un engagement progressif.

Voyons un autre exemple. Geni est un service web permettant à quiconque de créer un arbre généalogique et de le partager avec ses amis ou sa famille. Quelle est la première chose que les clients potentiels doivent faire en arrivant sur Geni ? Remplir un formulaire d’inscription ? Non, ils créent un arbre généalogique. Après tout, c’est ce pourquoi Geni est fait.

La page d’accueil de Geni (Figure 13.3) indique clairement ce que propose le site. On commence par créer une famille en entrant son nom et son adresse email. Ensuite, vous pouvez entrer vos parents, leurs frères et sœurs ou les vôtres, et en quelques instants, vous obtenez un petit arbre généalogique. Pendant ce temps, Geni vous a envoyé un email contenant votre nom d’utilisateur et votre mot de passe : vous pourrez ainsi revenir sur votre arbre généalogique quand vous le désirerez.

Figure 13.3
La création d’un arbre généalogique sur Geni ne contient pas de formulaire d’enregistrement explicite et informe immédiatement les utilisateurs.

Encore une fois, au travers du processus d’engagement progressif, vous avez appris ce que proposait un service web, et ceci sans inscription explicite vous obligeant à fournir une certaine quantité d’informations. Dans le cas de Geni, l’approche de l’engagement progressif leur a donné cinq millions d’utilisateurs en cinq mois. Pas mal.

Un autre exemple d’engagement progressif nous est proposé par TripIt : ce service web propose aux utilisateurs d’assembler un itinéraire de voyage complet, comprenant la météo et les feuilles de route, en utilisant uniquement leurs emails de confirmations de vols, d’hôtels et de location de voiture.
La première étape pour commencer à utiliser ce service est d’envoyer à TripIt un email de confirmation d’un voyage passé ou à venir. TripIt vous renverra un email vous permettant d’accéder à un itinéraire de voyage personnel créé automatiquement (Figure 13.4).

Figure 13.4
Pour commencer à utiliser TripIt, il faut lui renvoyer ses emails de confirmation, et pas s’inscrire en utilisant un formulaire.

Encore une fois, la première étape pour utiliser TripIt n’est pas de s’inscrire en passant par un formulaire. A la place, vous découvrez le service tout en l’utilisant. TripIt récupère votre nom et votre email à l’aide des emails que vous renvoyez au service. Ensuite, si vous voulez modifier votre nom, votre email, ou créer un mot de passe pour accéder au site, vous pouvez le faire. Il y a de grandes chances pour que vous le fassiez, maintenant que vous savez en quoi consiste ce service et ce qu’il peut vous apporter.

En étudiant si l’engagement progressif peut être utilisé sur votre service web, il est important de penser à la façon dont une série d’interactions pourrait expliquer à vos clients potentiels comment ils peuvent utiliser le service et ce qu’il peut leur apporter. L’engagement progressif ne consiste pas simplement à répartir les champs de votre formulaire d’inscription en plusieurs pages séparées.

Je salue volontiers la tentative de Fidelity’s myplan de simplifier leur formulaire de planification de placements financiers (Figure 13.5), mais je ne suis pas sûr que séparer leurs différents champs de saisies en plusieurs pages sous forme de curseurs glissants soit le meilleur moyen d’atteindre leur but, qui est d’expliquer aux visiteurs ce que Fidelity peut faire pour eux.

Figure 13.5
Le formulaire de Fidelity’s myplan divise une série de champs de saisie en plusieurs curseurs glissants, présentés l’un après l’autre.

Bonnes pratiques

• En étudiant la première expérience d’un utilisateur sur votre site web, pensez à la manière dont vous pouvez éviter l’utilisation d’un formulaire d’inscription en faveur d’un engagement progressif.
• Si vous optez pour une solution d’engagement progressif, assurez-vous qu’elle apporte à vos clients potentiels des informations sur le fonctionnement de votre service, et ce qu’il peut leur apporter.
• Si vous choisissez d’auto-générer les comptes de vos clients potentiels, assurez-vous qu’ils disposent d’un moyen clair d’accéder à leur compte. Il y a des chances pour que les utilisateurs ignorent ou ne voient pas votre email confirmation indiquant la création de leur compte, et qu’ils ne sachent pas exactement s’ils ont un compte ou pas.
• Evitez les solutions d’engagement progressif qui répartissent simplement les différents champs de votre formulaire d’inscription sur plusieurs pages. Il y a de fortes chances que cela en réduise l’efficacité, sans pour autant l’alléger.

Translated with the permission of A List Apart Magazine and the author[s].”

Un article sur le blog dédié nous en liste les différentes améliorations :

1. La version définitive apportera un support complet de CSS 2.1.
2. Ils ont contribué à la création de plus de 700 tests en collaboration avec le Groupe de travail CSS du W3C, publiés sous licence BSD. Selon l’équipe, la spécification CSS est bien conçue mais pas suffisante, car ambigüe sur de nombreux points. Une suite de tests devrait permettre aux éditeurs de mieux les interpréter, en s’appuyant sur des tests pouvant être suivis par l’ensemble des éditeurs.
3. De meilleures performances pour les scripts. Il s’agit d’un gros enjeu pour les navigateurs ( Firefox 3 sera lui aussi bien plus rapide, et Safari se présente d’emblée comme [Le] navigateur web [...] le plus rapide de la planète. ) : les bibliothèques Javascript permettent aujourd’hui de créer de véritables applications en ligne, bien plus complexes et gourmandes qu’il y a quelques années. Le navigateur est allé bien au-delà de son rôle principal : il est devenu une plate-forme de choix pour de nombreuses applications innovantes.
4. Un début de support d’HTML5.
5. La création prochaine d’outils pour débugger les CSS et le Javascript.
6. Une fonctionnalité appelée « Activities » apparaît. Elle permet de mieux intégrer les différents services web au navigateur, comme sélectionner du texte sur une page et l’envoyer vers son blog, ou rechercher directement une adresse sur un service de cartes en ligne. Voici une excellente occasion d’ajouter un support des microformats, mais en fait non. C’est une bonne opportunité pour Microsoft d’amener plus d’utilisateurs vers ses différents services, bien que des concurrents soient également présents, comme Facebook Yahoo eBay. Non, pas Google.
7. Une autre fonctionnalité a été intégrée, appelée « WebSlices« . Globalement, ça ressemble aux Web Clips de Safari, mais ne nous y laissons pas prendre : ce sont les WebSlices, d’Internet Explorer.

Le test Acid2 ne passe pas tout à fait s’il est effectué sur un autre domaine que www.webstandards.org, pour une raison de sécurité. Ce devrait être réglé dans la prochaine beta.

Vous pourrez le télécharger ici : http://www.microsoft.com/windows/products/winfamily/ie/ie8/default.mspx
Tristan Nitot en parle : http://standblog.org/blog/post/2008/03/05/Internet-Explorer-8-et-les-standards-le-retour

Peu de temps après l’abandon in extremis de solutions permettant d’activer le moteur de rendu « moderne » pour finalement l’activer par défaut (il faudra à l’inverse demander explicitement à passer en « mode compatible »), Microsoft semble plus que jamais impliqué dans une nouvelle guerre des navigateurs, mais du côté des standards cette fois.

Qu’en pensez-vous ?

]]> http://www.lesintegristes.net/2008/03/06/internet-explorer-8-beta-1/feed/ 2 http://www.lesintegristes.net/2008/02/13/des-problemes-avec-firebug-depuis-firefox-20012/ http://www.lesintegristes.net/2008/02/13/des-problemes-avec-firebug-depuis-firefox-20012/#comments Wed, 13 Feb 2008 22:43:18 +0000 Pierre Bertet http://www.lesintegristes.net/2008/02/13/des-problemes-avec-firebug-depuis-firefox-20012/ Depuis la dernière mise à jour de Firefox (2.0.0.12), l’onglet « HTML » de Firebug n’affiche plus le style des liens.

Firebug 1.1 beta n’a pas ce problème : vous trouverez cette version sur le site du projet Fireclipse, dont le but est d’apporter une interaction entre Firebug et Eclipse.
Diverses améliorations et corrections de bugs ont été apportées au passage à notre très chère extension, mais il ne s’agit pas d’un fork : la version 1.1 finale sera bien distribuée sur getfirebug.com, comme l’indique un billet sur le blog du site.

Fireclipse regroupe les éléments suivants :

1. L’extension Firebug patchée
2. Un plugin Eclipse
3. Une extension à Firebug, lui permettant d’interagir avec Eclipse

Ainsi, l’extension Firebug améliorée est totalement indépendante, et peut être installée seule.

Voici la liste des modifications apportées :

• eval() debugging
• External editor interface
• Browser-generated event handler debugging
• Executable lines marked with green line numbers
• User-controlled naming of eval() buffers
• Stack side panel on « Script » panel for callstack
• Supports Firefox 3
• « Better » debugging icons
• CSS errors report against source lines
• Bug fixes (incl. issues 8, 69, 218, 230, 239, 249, 269, 314, 321, 345)
• Internal firebug debug output

Je profite du sujet pour mentionner l’extension YSlow pour Firebug proposée par Yahoo!, permettant d’analyser vos pages (poids des éléments, nombre de requêtes, …) puis de consulter diverses optimisations afin d’en accélérer le rendu. Très pratique !

Télécharger Fireclipse / Firebug 1.1b : http://fireclipse.xucia.com/#Downloads
Télécharger YSlow : https://addons.mozilla.org/en-US/firefox/addon/5369

]]> http://www.lesintegristes.net/2008/02/13/des-problemes-avec-firebug-depuis-firefox-20012/feed/ 2 http://www.lesintegristes.net/2008/02/10/webkit-supporte-documentqueryselectorall/ http://www.lesintegristes.net/2008/02/10/webkit-supporte-documentqueryselectorall/#comments Sun, 10 Feb 2008 12:00:33 +0000 Pierre Bertet http://www.lesintegristes.net/2008/02/10/webkit-supporte-documentqueryselectorall/ Le seul moyen de sélectionner des éléments en Javascript est d’utiliser les méthodes DOM classiques : document.getElementById(), getElementsByTagName(), nexSibling(), etc.

C’est assez fastidieux, et n’incite pas vraiment les développeurs à concevoir leurs scripts de manière non-intrusive.

Voilà pourquoi plusieurs librairies Javascript ont ajouté une couche supplémentaire : il suffit de passer une chaîne de sélecteur CSS, et cette chaîne est retranscrite en méthodes DOM classique par le moteur de la librairie pour retourner un tableau d’éléments correspondant à ce sélecteur. Evidemment, toutes ces opérations ont un coût en termes de performances.

Selectors API propose de régler ce problème : il sera tout simplement possible de passer une chaîne CSS à la méthode document.querySelectorAll();, qui renverra un tableau d’éléments correspondant à la sélection. Bien entendu, cette méthode sera exécutée par le navigateur, ce qui est beaucoup plus intéressant.

La dernière version de Webkit vient d’intégrer cette méthode, et les résultats sont très concluants. Pour le démontrer, ils ont utilisé le benchmark slickspeed du projet mootools, permettant justement de comparer les performances des sélecteurs CSS pour chaque bibliothèque : http://webkit.org/perf/slickspeed/ .

Les différentes bibliothèques utilisant un sélecteur de ce type, comme jQuery, peuvent d’ores et déjà prendre en compte les navigateurs supportant cette méthode : il suffit de tester document.querySelectorAll(), et de lui passer la main s’il existe.

L’article sur Webkit.org : http://webkit.org/blog/156/queryselector-and-queryselectorall/
Télécharger la dernière version de Webkit : http://nightly.webkit.org/

]]> http://www.lesintegristes.net/2008/02/10/webkit-supporte-documentqueryselectorall/feed/ 0