Via le biais des plugins, tout le monde a pu commencer à faire des effets « wahou » en deux secondes et a pu commencé à vouloir écrire ses propres plugins… Rendons à César ce qui est à César et remercions jQuery pour avoir apporté une idée différente du framework javascript. Dans une discussion future, je me ferai peut-être moins respectueux en évoquant les différents maux que cette librairie a pu apporter.

Rapidité < Qualité

Ce qui reste très agaçant, surtout lorsqu’on commence à prendre un peu de niveau dans son métier, c’est quand un chef de projet vous pose cette question: « pourquoi tu n’as pas utilisé un plugin tout fait à la place ? »; alors que vous auriez bien aimé tout de même avoir la chance de pouvoir démontrer que vous pouviez faire mieux et surtout : plus adapté au projet.
Qui ne s’est jamais arraché les cheveux à faire rentrer un plugin dans un projet en bidouillant l’impossible, ajoutant des options dans l’objet d’options même si ce n’était pas vraiment le meilleur endroit…

Mais plus loin encore, est-ce là un vrai travail responsable que d’accepter l’utilisation de plugins par son équipe technique ?
Non seulement l’équipe ne risque pas de prendre du niveau et très certainement se ramollir, voir se démotiver, mais en plus, vous rendez votre travail dépendant de ce qui se passe ailleurs, chez les autres… dépendant donc de la veille « plugin ».
C’est un peu comme à l’époque du designers que les intégrateurs bridaient afin de pouvoir avoir des maquettes intégrables « comme on l’a toujours fait depuis des années« , à force on obtenait presque toujours les mêmes briefs: « A gauche donc, on aura une sidebar, à droite.. le contenu et puis au milieu, un jQuery Carousel de chez bidule »; Grisant.
D’ailleurs, la version 2013 de ces pratiques sera « en haut, le header, au milieu… et bah un bon gros jQuery mansonry hein ? t’en dis quoi ? le footer ? Oh y’en a pas besoin... »

Donnez-vous une année comme cela, sans faire un peu de programmation chez vous et vous allez vite voir que vous allez très rapidement perdre vos compétences.

Petite blague à part: Vous n’avez jamais remarqué que sur stackoverflow, à chaque question en js natif il y a toujours une armée de réponses type « pourquoi tu n’utilises pas jQuery« . Et si demain vous ne deviez pas l’utilisez, pour des raisons d’optimisations ? Et si sans jQuery vous vous rendiez compte que vous ne compreniez qu’une partie de la DOM API et donc, à votre métier ? True story que cela et je vous la raconterai peut-être en temps voulu… mais autre sujet, autre journée.

L’artisanat français

Oui monsieur…

Il reste aussi le problème de l’honnêteté.
La plupart de ces plugins sont souvent réalisés à des fins de promotion personnelle, donner à ceux qui ne savent pas programmer l’occasion d’avoir un petit plus sur leur blog ou de réutiliser plusieurs fois un travail réalisé pour un client ou encore simplement démontrer un concept, une idée simple.

Il est évident qu’à un certain niveau de la hiérarchie, on ne se préoccupe pas trop de comment un projet est commencé et fini, il faut tout simplement qu’il soit fini.
Là où cela devient préoccupant, c’est lorsque le chef de projet technique ne s’en préoccupe pas non plus… et encore plus préoccupant d’entendre ce genre de propos dans la bouche d’un développeur front-end.

C’est peut-être du au fait qu’en France, au delà de 8 à 10 ans en tant que technicien, il est inconcevable de ne pas rechercher ou accepter un magnifique poste de manager et / ou de chef de projet, poste qui fera systématiquement, si on n’y prête pas garde, perdre le fil de la veille technologique (en fait plutôt les compétences que la veille).
Quelle belle récompense pour tant d’année de bon et loyaux services, mais ça, c’est déjà un sujet assez récurrent sur ce blog et je n’y reviendrais plus (promis juré !)

Cela est peut-être aussi du au fait que depuis les plugins à tout va, on sait qu’ un site Internet coutera moins cher et sera surtout réalisé plus rapidement. Par conséquent, « on » est toujours plutôt gagnant… enfin sauf pour les « techos » mais eux, ils attendent patiemment leur 8 à 10 ans pour devenir chef de projet (quoi, vous voulez pas être CP ou manager ? Mais puisqu’on vous dit que vous n’avez pas le choix !)

La seule question qui restent à mes yeux importante :  Est-ce un service que nous rendons au métier ?
Je m’étonne bien souvent de notre retard sur les points de l’UX, de l’UI et du design de site Internet mais n’est-ce pas avant tout parce que nous travaillons presque toujours à l’inspiration en regardant un peu ce qui a déjà été fait et finalement très peu en workshop ? Que les commerciaux vendent d’office des promesses impossibles à tenir ? Ou, peut-être est-ce parce qu’on s’obstine à rechercher des ninjas en PHP/MYSQL/AS3/CSS3/HTML5/JS/ASP au lieu de profils spécialisés dans l’interface utilisateur… Ou pire, que certains bloggeurs influents parlent partout de webresponsive sans exactement comprendre les implications (encore un bon sujet potentiel que celui-ci)

Be open! Oui mais…

Alors, au final, merci jQuery mais par pitié, vous, développeurs de plugins, soyez fermes avec vos licences d’utilisations et menez la vie dure aux entreprises qui utilisent vos plugins sans en avoir l’autorisation. De cette manière, nous pourrons ainsi tous combattre l’utilisation de plugins en entreprise tout en permettant aux gens de s’inspirer et/ou regarder directement le code via GitHub pour apprendre sans pour autant réutiliser… sinon dans quelques années, il faudra ajouter la ligne « google-isation de plugins » sur nos CVs.

Il serait d’ailleurs intéressant de savoir ce que pense certaines personnes de l’utilisation de leurs plugins pour des projets professionnels vendus à quelques dizaines voir centaines de milliers de brouzoufs… qui se souvient encore de l’utilisation d’un blog Dotclear pour un site Internet vivant à promouvoir certaines lois que l’état était désireux de passer ? Et qui se souvient du prix à laquelle ce Dotclear avait été vendu ?

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

Alors que les intégrateurs, développeurs, webmasters et au sens le plus large, les créateurs de sites web échangent sur la meilleure façon d’utiliser javascript pour maintenir un site accessible, les professionnels du référencement n’hésitent pas à conseiller à leurs clients de faire des liens en javascript ou à générer des parties de leur code html via javascript de manière à ne pas référencer certaines pages ou certaines parties de leur contenu dans le but de favoriser des pages au profit d’autres. Les robots n’étant pas à l’heure actuelle en mesure de comprendre et donc d’interpréter le javascript, les liens JS ne seront pas suivis et le contenu généré ne sera pas pris en compte. J’ai également lu dernièrement que les robots seraient (je mets cette information au conditionnel) en mesure de décrypter les url dans le code javascript et donc de suivre ces liens comme des liens html, ce qui oblige actuellement les référenceurs à adopter des méthodes de cryptages – dans la limite de ce qu’il est possible de faire en javascript – pour leurs url !

Cette pratique loin d’être confidentielle se répand comme une traînée de poudre sur les sites de e-commerce français où les liens <a href="link"> sont remplacés par des <span onclick="fonction()">. (L’exemple le plus flagrant en est donné sur la page d’accueil du site de vente en ligne rueducommerce.fr sur laquelle pratiquement aucun lien de type <a href="link"> n’est présent.)

Pour bien comprendre ce que ça implique, il faut d’une part rappeler que cette pratique va totalement à l’encontre des règles d’accessibilité les plus élémentaires :

En effet toute personne ayant javascript désactivé pour une raison ou pour une autre ne pourra pas afficher la page liée. Les personnes ayant javascript activé ne pourront pas utiliser le clic milieu de leur souris ou l’option ouvrir un nouvel onglet de leur menu contextuel. Ce procédé restreint donc les possibilités de l’utilisateur qu’il ait ou pas javascript activé dans son navigateur. Il est important de rappeler que la conception de pages avec le langage html répond à des normes : les standards du web, dont les recommandations sont rédigés par le W3C, organisme qui supervise le développement des standards du web, et pour que ces pages puissent fonctionner de façon satisfaisante dans les principaux navigateurs du marché, ces recommandations ou règles doivent être suivies. Il est également important de rappeler que de nombreuses applications et extensions, notamment celles de Firefox sont basées sur ce socle commun qu’il est primordial de respecter, faute de quoi l’utilisateur s’en trouve obligatoirement lésé.

Lisons ce qu’il est dit dans la documentation du groupe WAI du W3C, référence majeure pour l’accessibilité des sites web :

WCAG 1.0 (version par lagrange.net)

Guideline 6. S’assurer que les pages qui contiennent de nouvelles technologies se transforment de façon élégante.

6.3 S’assurer que les pages soient visibles lorsque les scripts, les applets ou autres artefacts programmables sont désactivés ou non supportés. Lorsque ce n’est pas possible, fournissez une information équivalente sur une page alternative. [Priorité 1]
Par exemple, assurez vous que les liens qui activent les scripts fonctionnent même lorsque ces derniers sont désactivés ou non supportés (par ex. Il ne faut pas utiliser « javascript: » comme cible des liens).

W3C : Techniques pour les règles d’accessibilité du contenu Web 1.0 (version par lagrange.net)

4.12.1 Scripts de transformation

Les développeurs de contenu doivent s’assurer que les pages sont accessibles avec les scripts désactivés ou dans des navigateurs qui ne supportent pas les scripts.

* Eviter la création de contenu à la volée par le client. Si un navigateur d’utilisateur ne gère pas les scripts, aucun contenu ne sera généré ou affiché. Cependant, Ceci est différent lorsqu’il s’agit d’afficher ou de cacher un contenu déjà existant en utilisant une combinaison de feuilles de style et de scripting ; S’il n’y a pas de scripts, le contenu sera tout de même affiché. Cela ne s’applique pas aux pages générées à la volée par le serveur et distribuées au client.
* Eviter la création de liens qui utilisent « javascript » pour l’URI. Si un utilisateur n’utilise pas les scripts, il sera alors incapable d’utiliser le lien car le navigateur ne pourra créé le lien.

Que recommande Google à ce sujet ?

Google (Centre d’aide Webmasters/propriétaires de sites web)

Si votre site contient du texte ou des liens cachés, il risque d’être considéré comme peu fiable, car il présente aux moteurs de recherche un contenu différent de celui destiné aux visiteurs […]

[…] Si votre site contient du texte et des liens cachés conçus pour induire les moteurs de rechercher en erreur, votre site peut être retiré de l’index Google et ne plus être affiché dans les pages de résultats de recherche. Lorsque vous évaluez votre site afin de vérifier s’il contient du texte ou des liens cachés, recherchez tout ce qui n’est pas facilement affichable par les visiteurs. Existe-t-il du texte ou des liens accessibles uniquement aux moteurs de recherche et non aux visiteurs ? […]

[…] Lorsque Googlebot indexe une page contenant un script JavaScript, il ne peut pas suivre ou indexer les liens cachés dans le script lui-même. L’utilisation d’un script JavaScript est une pratique Web totalement légitime. Toutefois, son utilisation dans le but de tromper les moteurs de recherche ne l’est pas. […]

Pour résumer, il n’est pas interdit d’utiliser des liens javascript dans la mesure où la page présentée aux moteurs de recherche est la même que celle présentée aux utilisateurs. Ce qui n’est pas le cas dans la mesure où les robots ne pouvant lire javascript considèrent que les liens n’existent pas et ne référencent pas la page liée…

Devons-nous considérer que puisque le nombre des visiteurs sans javascript est faible, il n’est plus utile de se préoccuper de faire du javascript non-intrusif ? Comment se maintenir dans un secteur où toutes les méthodes même les plus contestables sont utilisées pour maintenir un taux de visites important sur son site ? Est-il possible de rester concurrentiel en utilisant les bonnes pratiques et en maintenant un site accessible, sans pour autant négliger la partie référencement ?

Pour continuer la réflexion quelques liens utiles :

• Support Google : Conseils aux webmasters
• Vous aimez l’accessibilité ? Les moteurs de recherche aussi !
• Accessibilité et e-commerce : Pourquoi rendre son site accessible ?
• Target condamné pour l’inaccessibilité de son site aux non-voyants

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 ?

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/

Pourquoi utiliser des pop-up ?

Le raisonnement que j’entends souvent est : « le contenu n’est pas assez important pour une nouvelle page ». Ce raisonnement aussitôt contredit par des demandes de pop-up de 650px sur 800 px … Pourquoi tant d’acharnement ??!!

Bien sur je ne parle pas des pop-up non sollicitées qui ne méritent même pas qu’on s’y arrête ne serait-ce qu’un instant, les navigateurs tels que Firefox ou Opéra, nous en débarassent sans que nous ne nous en rendions même compte.

Alors que la plupart des sites a abandonné cette habitude d’un autre temps, certains résistent encore et toujours bien que les arguments contre l’utilisation de ces petites fenêtres ne manquent pas :

Ergonomie :

1. Les utilisateurs en navigant sur leur site préféré ne s’attendent pas à ce que les liens sur lesquels ils cliquent ouvrent une autre fenêtre.
2. Une pop-up peut passer en dessous de la fenêtre principale si on clique malencontreusement sur cette dernière.
3. Si une pop-up est ouverte et se trouve sous la fenêtre principale toutes les pages ouvertes dans la popup (si elle n’est pas nommée ou porte le même nom dans toutes les fonctions d’ouverture de la popup) demeureront invisibles pour l’internaute qui croira se trouver en présence de liens non-fonctionnels.

Accessibilité :

1. L’ouverture d’une pop up perturbe la navigation notamment pour les personnes qui utilisent des aides techniques pour naviguer. En règle générale, l’ouverture d’une nouvelle fenêtre est déstabilisant pour les personnes aveugles.
   Il est de plus impossible de revenir à la page précédente par l’historique du navigateur.
2. Une popup est ouverte par une fonction javascript, sans js la popup ne s’ouvre pas à moins qu’on prenne le soin d’avoir recours à cette technique (ce qui est loin d’être le cas, le plus souvent) :

<a href="page.htm" onclick="window.open(this.href); return false;">

Il existe d’autres solutions beaucoup plus sympa pour afficher des informations sans changer de page à l’aide de javascripts non-intrusifs (il suffit de regarder les scripts et plugins proposés par des bibliothèques comme jQuery ou script.aculo.us)

Crédibilité :

1. les pop-up nuisent à l’image du site qui les utilise et donnent une impression générale d’amateurisme.
2. Les pop-up sont dans la plupart des cas associées à de la pub et bénéficient de moins d’attention de la part des internautes.

Contraintes des navigateurs :

Dans les navigateurs modernes, et ceci pour éviter les abus, il n’est plus possible d’intervenir sur les propriétés des popup (emplacement, redimensionnement, déplacement, etc.)

Conclusion : on ne devrait plus se poser la question, les popup, c’est NON !

Quelques liens pour poursuivre cette réflexion :

• The Jarrett-Zetie Rules of Pop- ups : http://www.ergologique.com/actualites/actus.php?id_actu=123
• Interview Jakob Nielsen sur JDN : http://www.journaldunet.com/itws/it_nielsen.shtml
• Créer des popup intelligentes : http://openweb.eu.org/articles/popup/
• Lazy, stupid and evil design : http://www.guardian.co.uk/technology/2005/jun/23/columnists.comment

T’aimes pas les accroches interrogatives

Voici donc la suite de notre série d’articles consacrés à jQuery, avec aujourd’hui : le plugin !

La conception de jQuery, centrée sur un même objet, permet d’étendre naturellement notre bibliothèque en créant de nouvelles méthodes. Un plugin sera alors utilisé de cette façon :

$("p").monplugin();

Nous créerons pour l’exemple un plugin qui fait danser les éléments sélectionnés, appelons-le « jQuery Dance ».

On pourra éventuellement lui passer des options : le tempo, et la taille de la piste de danse bien entendu !

Il sera utilisé ainsi :

$("p").dance();

Ah, vous l’aviez certainement noté : la sonorité de jQuery est proche de celle de charcuterie. Et comme pour la rosette, certaines règles sont à respecter pour créer un plugin de qualité, les voici.

Nommez votre fichier

Un plugin doit toujours se nommer ainsi, de manière à ce qu’il soit immédiatement identifiable : jquery.nom_du_plugin.js
Notre fichier se nommera donc jquery.dance.js.

Isolez votre code

Dans ce fichier nouvellement créé, nous allons commencer par englober tout ce qui va être écrit dans une fonction anonyme qui sera immédiatement executée. De cette manière, toutes les variables que vous créerez ne rentrerons pas en collision avec les autres scripts présents sur la page.

(function(){
	// Code
})()

Nous allons en profiter pour passer la variable jQuery (dont $ n’est qu’un alias) à cette fonction, de cette manière :

(function($){
	// Code
})(jQuery)

Cela permettra d’utiliser la variable $ à l’intérieur de notre fonction.
Pourquoi, puisque $ est déjà un alias de jQuery ?

jQuery permet de renommer cette fonction à l’aide de jQuery.noConflict().
Il est donc possible de faire cohabiter jQuery et l’une des nombreuses librairies utilisant la fonction $() (comme Prototype), en renommant l’alias comme bon nous semble :

var $j = jQuery.noConflict();

Nous devons donc nous assurer que la fonction $() existe bien, et que nous n’utilisons pas une autre librairie à la place de jQuery.

Ajoutez votre nouvelle méthode à jQuery.fn

Après avoir créé notre environnement, nous sommes prêts à écrire notre plugin.
Nous voulons donc ajouter une nouvelle méthode aux objets jQuery. Il faut pour cela ajouter une nouvelle fonction à l’objet jQuery.fn. Dans cette fonction, le mot-clé this représente l’objet jQuery sélectionné par l’utilisateur de votre plugin.

Dans le cas où notre plugin serait défini de cette façon :

(function($){
	$.fn.dance = function(){
		alert(this == ma_selection);
	};
})(jQuery)

Et qu’une variable globale (absence du mot var) ma_selection soit définie ainsi :

// Au chargement...
$(function(){
	ma_selection = $("p");
	ma_selection.dance();
});

Le message affiché par la fonction alert() serait true.

Bouclez sur les éléments sélectionnés

Vous devez toujours considérer que plusieurs éléments ont été sélectionnés avant d’appeler votre méthode.

Pour traiter chacun de ces éléments, la méthode each() de jQuery sera utilisée. cette méthode prend en paramètre une fonction, qui sera executée pour chaque élément. Dans cette boucle, le mot this correspondra cette fois à chacun des éléments DOM de cette sélection.
Pour obtenir un objet jQuery, il faudra passer cet élément à la fonction $().

(function($){
	$.fn.dance = function(){
		this.each(function(){
		  // this : élément DOM classique
		  // $(this) : élément jQuery
		});
	};
})(jQuery)

Gardez à l’esprit que cette fonction est executée pour chacun des éléments de la sélection. Il est donc préférable de ne placer dans cette fonction que les traitements liés à chaque élément en particulier.

(function($){
	$.fn.dance = function(){

		// Le tempo est le même pour tous les éléments,
		// inutile de le redéfinir à chaque  fois.
		var tempo = 300;

		// Cette fonction n'est définie qu'une fois,
		// puis appelée par chacun des éléments.
		function move(jElt){
			// Nous placerons ici le code permettant
			// de faire danser le Boogie Woogie à un élément
		};

		this.each(function(){
			move( $(this) );
		});
	};
})(jQuery)

Retournez l’objet sélectionné

Cette pratique permettra d’utiliser plusieurs méthodes en chaîne :

$("p").dance().css("color", "red");

Evidemment, si votre plugin renvoie une information, il ne sera alors pas possible de chaîner plusieurs méthodes (comme avec la méthode width() par exemple).

Il faudra donc que votre méthode retourne this avant de se terminer.

(function($){
	$.fn.dance = function(){

		// Code...

		return this;
	};
})(jQuery)

Et puisque la méthode each() de jQuery renvoie l’élément sélectionné, vous pouvez retourner votre sélection en bouclant sur chacun des éléments :

(function($){
	$.fn.dance = function(){

		// Code...

		return this.each(function(){
			move( $(this) );
		});
	};
})(jQuery)

Bien, nous avons vu les bases de la création d’un plugin. Le plugin « jQuery Dance » peut maintenant être utilisé de cette façon :

$("p").dance().css("border","1px");

Passez des paramètres à votre méthode

Comme nous l’avons vu au début de cet article, la méthode dance() prendra deux paramètres : tempo et dancefloorArea, correspondant respectivement à la fréquence d’execution de chaque mouvement(en millisecondes), et à la surface que pourra utiliser cet élément (en pixels).

Définir des paramètres pour notre méthode est très simple :

(function($){
	$.fn.dance = function(tempo, dancefloorArea){

		// Code...

	};
})(jQuery)

La méthode pourra donc être appelée de cette façon :

$("p").dance(300, 400)

Etendez vos paramètres optionnels

Avant d’avancer dans la réalisation de jQuery Dance et de permettre à nos éléments de se déhancher sur le dancefloor, nous allons voir une dernière technique, permettant de passer des paramètres optionnels à une méthode jQuery.

Nos paramètres ne seront alors plus passés directement, mais à l’aide d’un tableau associatif :

$("p").dance({tempo: 300, danceFloorArea: 400})

La fonction jQuery.extend(a, b) permet d’étendre un objet a avec un objet b, en écrasant les propriétés redéfinies.
Voici un exemple :

var objet_a = {
	param_1: "Bonjour",
	param_2: "les p'tits gars"
};
var objet_b = {
	param_2: "tout le monde",
	param_3: "ça va ?"
};

$.extend(objet_a, objet_b);

alert(objet_a.param_1); // Bonjour
alert(objet_a.param_2); // tout le monde
alert(objet_a.param_3); // ça va ?

En plus de l’étendre, cette fonction renvoie le premier objet modifié, ce qui est très pratique lorsque le premier objet est défini en paramètre :

var objet_b = {
	param_2: "tout le monde",
	param_3: "ça va ?"
};

var objet_a = $.extend({
	param_1: "Bonjour",
	param_2: "les p'tits gars"
}, objet_b);

Nous utiliserons cette technique pour étendre nos paramètres par défaut avec ceux passés à la méthode, de cette façon :

(function($){
	$.fn.dance = function(params){

		// Si aucun paramètre n'est passé
		// et que params est vide, alors $.extend()
		// renverra simplement le premier objet passé
		var params = $.extend({
			tempo: 300,
			dancefloorArea: 400
		},params);

		function move(jElt){
			// Boogie Woogie
		};

		return this.each(function(){
			move( $(this) );
		});
	};
})(jQuery)

Voulez-vous danser mademoiselle ?

Chacun de nos éléments sera déplacé, au hasard, sur la surface définie par dancefloorArea (400px par défaut). Chacun de ces déplacements sera déclenché selon l’intervalle définie par tempo (300 millisecondes par défaut).

Nous allons définir une nouvelle fonction (tirée de la documentation Mozilla), permettant d’obtenir un nombre entier situé entre les deux passés en paramètres.

Nous allons également définir les variables minPosition et maxPosition d’après params.dancefloorArea

(function($){
	$.fn.dance = function(params){

		// Paramètres
		var params = $.extend({
			tempo: 300,
			dancefloorArea: 400
		},params);

		// Renvoie un entier situé entre min et max
		function getRandomInt(min, max){
		  return Math.floor(Math.random() * (max - min + 1)) + min;
		};

		// Positions minimales et maximales
		// que pourra prendre un élément
		var minPosition = -(params.dancefloorArea/2);
		var maxPosition = params.dancefloorArea/2;

		// Mouvement d'un élément
		function move(jElt){
			var topPos = getRandomInt(minPosition, maxPosition);
			var leftPos = getRandomInt(minPosition, maxPosition);
		};

		return this.each(function(){
			move( $(this) );
		});
	};
})(jQuery)

Pour chaque élément, une position sera définie à l’aide des variables leftPos et topPos.

Il nous reste donc à animer notre élément vers cette position pendant le temps défini par tempo, puis à appeler cette fonction, encore et encore, jusqu’au bout de la nuit. Nous utiliserons la méthode animate() de jQuery. Les éléments seront également positionnés en relatif pour être déplacés par rapport à leur position, sans gêner les voisins parce que bon, ils n’ont rien demandé eux.

(function($){
	$.fn.dance = function(params){

		// Paramètres
		var params = $.extend({
			tempo: 300,
			dancefloorArea: 400
		},params);

		// Renvoie un entier situé entre min et max
		function getRandomInt(min, max){
		  return Math.floor(Math.random() * (max - min + 1)) + min;
		};

		// Positions minimales et maximales
		// que pourra prendre un élément
		var minPosition = -(params.dancefloorArea/2);
		var maxPosition = params.dancefloorArea/2;

		// Mouvement d'un élément
		function move(jElt){
			var topPos = getRandomInt(minPosition, maxPosition);
			var leftPos = getRandomInt(minPosition, maxPosition);

			// Préfixer une variable par la lettre j
			// (ou ce qui vous semblera pertinent)
			// permet d'identifier facilement un objet jQuery.
			jElt.animate(

				// Premier paramètre : les nouvelles propriétés CSS
				// vers lesquelles l'élément va être animé.
				{
					top: topPos + "px",
					left: leftPos + "px"
				},

				// Deuxième paramètre : le temps que durera l'animation
				params.tempo,

				// Troisième paramètre, la fonction qui sera appelée
				// lorsque l'animation sera terminée.
				function(){
					move(jElt); // Nous appelons à nouveau la fonction move()
				}
			);
		};

		return this.css("position", "relative").each(function(){
			move( $(this) );
		});
	};
})(jQuery)

Vous trouverez une démonstration de notre plugin à cette adresse : /demos/jquery/dance.html

Je dois avouer, et vous le reconnaîtrez sûrement, que le résultat est affligeant. Mais bon, hein.

Puisque IE7 est sorti, et que certaines limitations sont encore d’actualités, le script a été scindé en deux parties : IE7.js se limite maintenant aux améliorations d’IE7 qu’il apporte à IE5/6, tandis qu’IE8.js reprend les fonctionnalités d’IE7.js toujours absentes dans Internet Explorer 7.

Un projet a été créé chez Google Code pour l’occasion : http://code.google.com/p/ie7-js/

Voici un bon moyen d’accompagner doucement ce vieux navigateur vers ses derniers instants, tout en profitant des sélecteurs (classes multiples, sélecteurs d’attributs, :hover sur tous les éléments, …) et propriétés (min-height, max-height…) CSS. Sans même utiliser IE8.js, placer IE6 au même niveau que son jeune frérot procure un sacré confort !

Evidemment, cette solution n’est pas parfaite : le style de vos pages sera en partie altéré pour un utilisateur d’IE6 ayant désactivé javascript. Il faut alors s’assurer que chaque page reste bien accessible.

Nous allons maintenant voir ce qu’il est possible de faire à partir de cet objet.

Méthodes de jQuery

L’objet jQuery, comme tout objet, dispose de méthodes. Grossièrement, il s’agit d’actions qu’un objet sait accomplir.
Pour comparaison, si notre objet était une grosse voiture rouge (on vend du rêve sur lesintegristes.net), elle aurait la faculté d’avancer vite.

Ca pourrait donner en français la syntaxe suivante :
Voiture, avance (vite) !

jQuery dispose de la méthode fadeOut(), pour masquer les éléments englobés dans notre objet jQuery avec un effet de fondu certifié « Ouais bah deux pouin zéro. »
– « Hein ? »
– « Ouais bah j’dis c’que j’veux. »

Prenons pour exemple ce petit morceau de HTML, qui ne se doute de rien :

<p class="outi">Lalalala, je me balade dans la forêt...</p>

Nous allons maintenant sélectionner ce paragraphe, et le faire disparaître avec un effet de fondu :

$("p.outi").fadeOut();

Notre objet est $("p.outi"), à qui nous demandons de disparaître ( .fadeOut() ).

La méthode fadeOut() accepte un paramètre qui permet de modifier la vitesse de l’effet : on peut lui passer le temps, en millisecondes, ou les chaînes « slow », « normal » et « fast » :

$("p.outi").fadeOut("slow");
$("p.outi").fadeOut(300);

Il est également possible de passer un deuxième paramètre, appelé callback. Il s’agit d’une fonction qui va être appelée lorsque l’effet sera terminé. Essayons !

// Au chargement du DOM...
$(function(){
	// On sélectionne notre paragraphe
	$("p.outi")
	// On lui applique l'effet fadeOut()
	.fadeOut(
		// Avec "slow" en premier paramètre
		"slow",
		// Et une fonction de "callback"
		// en deuxième paramètre
		function(){$(this).fadeIn("slow");}
	);
});

Dans notre callback, nous utilisons this, qui correspond dans ce contexte à l’objet DOM sur lequel l’effet est appliqué.
Nous le transformons donc en objet jQuery avant de lui appliquer la méthode fadeIn(), qui va comme vous l’avez deviné faire exactement l’inverse de fadeOut(), et faire apparaître de nouveau notre paragraphe.

Les méthodes en chaîne

La plupart des méthodes de jQuery ont une particularité : elles renvoient l’objet jQuery lui-même.
Prenons un exemple, à l’aide de Mozilla Firefox et de son excellent plugin Firebug, qui permet (entre autres) d’afficher n’importe quel objet à l’aide de l’objet console.
Nous allons utiliser la méthode css(), qui permet de modifier une ou plusieurs propriétés CSS des éléments sélectionnés :

$(function(){
	console.log( $("p.outi") );
	// Affiche [p.outi]

	console.log( $("p.outi").css("color", "red") );
	// Affiche [p.outi], la méthode css()
	// renvoie bien notre objet.
});

Ainsi, il va être possible de réutiliser notre objet, pour lui appliquer tout ce que l’on veut.

Pour illustrer ceci, nous allons créer notre premier script « utile ».
Notre client s’est réveillé cette nuit pour noter une idée, qui va à coup sûr donner un énorme avantage technologique à son site sur la concurrence :
– « Le texte de ce paragraphe apparaîtra en… glissant, après avoir survolé le bouton rouge : Survolez-moi ! »
– « Ha »
– « Imaginez la tête du visiteur ! »
– « … »
– « Sinon ça va, vous ? »
– « … O… Oui, ça va. »

Bon, il est temps d’enfiler notre costume de Superman pour trouver une solution accessible avec ça.

–  » Ca gratte un peu, mais bon.  »

Pour que ce texte reste accessible à tout ce qui n’utilise pas Javascript, il va devoir être masqué au chargement de la page, en Javascript.
Le bouton qui permettra de l’afficher n’ayant aucun sens sans script, nous allons également le générer. Il nous restera ensuite à créer l’effet voulu.
Hop :

$(function(){
	$("p.outi").before("<span>Survolez-moi !</span>").hide();
});

Nous avons sélectionné le paragraphe, ajouté un élément <span> qui va nous servir de bouton, puis nous avons masqué notre paragraphe, car la méthode before(), qui permet d’ajouter un élément avant celui sélectionné, va retourner l’objet jQuery.

Nous allons maintenant modifier notre sélection jQuery, à l’aide de la méthode prev(), qui permet de sélectionner l’élément précédent (le <span>).
Nous voyons donc ici notre première méthode qui ne retourne pas l’objet jQuery premièrement sélectionné.
C’est très intéressant, car cela va nous permettre de continuer à « chaîner » nos méthodes à partir de l’élément <span> nouvellement créé.

Nous lui appliquerons ensuite un style à l’aide de la méthode css() que nous avons vu précédemment.
Mais plutôt que de modifier une seule propriété en passant deux chaînes de caractère, nous allons lui passer un tableau associatif, contenant toutes les propriétés CSS que nous voulons définir.

$(function(){
	$("p.outi").before("<span>Survolez-moi !</span>").hide()
	.prev().css({
		display: "block",
		height: "30px",
		width: "100px",
		lineHeight: "30px",
		textAlign: "center",
		border: "1px solid #f00",
		cursor: "pointer"
	});
});

Facile, non ?

Il ne nous reste plus qu’à attacher un événement au survol de cet élément. jQuery propose un tas de méthodes, permettant d’associer des événements à des éléments. Leur nom reprend ceux de DOM, sans le préfixe « on ». Ils prennent en paramètre une fonction.
Nous allons donc utiliser la méthode mouseover() :

$(function(){
	$("p.outi").before("<span>Survolez-moi !</span>").hide()
	.prev().css({
		display: "block",
		height: "30px",
		width: "100px",
		lineHeight: "30px",
		textAlign: "center",
		border: "1px solid #f00",
		cursor: "pointer"
	})
	.mouseover(function(){
		$(this).next().slideDown();
	});
});

A l’intérieur de cette fonction, qui va se déclencher au survol, nous avons englobé notre <span>, représenté par this, dans un objet jQuery, puis sélectionné l’élément suivant à l’aide de next(), et finalement affiché notre paragraphe à l’aide de la méthode slideDown().

Vous avez remarqué ?
Nous sommes partis d’une unique sélection, $("p.outi").

Oui, c’est beau. Oui, c’est propre. C’est jQuery.