Les listes de définitions ne varient que légèrement par rapport à d’autres types de listes, ce type de liste est composé de deux parties : un terme et une description.

L’utilisation la plus appropriée est donc celle où un mot ou une expression : <dt> serait défini par une courte explication : <dd>, comme dans un dictionnaire ou un glossaire, par exemple.

Mais si nous allons plus loin, les recommandations donnent également l’exemple d’un dialogue ou le personnage serait défini par la balise <dt> et son dialogue par la balise : <dd>, mais uniquement dans les recommandations de html 4.01 et xhtml 1.0. Dans html 5, les listes de définitions ne doivent pas servir à mettre en forme un dialogue, puisqu’initialement la balise : <dialog> devait servir à cet effet. Cette balise ayant été retirée en septembre dernier sans être (encore ?) remplacée. On reste dans l’expectative…

Concrètement, quel usage est-il fait de la liste de définition dans les sites que nous consultons tous les jours ? Est-ce qu’une liste de diffusion peut être utilisée pour un menu de navigation ? A mon sens non, puisqu’il existe les listes ordonnées : <ol> et non ordonnées : <ul> qui me semblent plus appropriées. Est-ce qu’une liste de diffusion peut remplacer un titre : <dt> = <h1> et un paragraphe : <dd> = <p> ? Réponse : non, mais c’est souvent la solution que nous avons trouvé pour répondre aux demandes des services chargés du référencement qui souhaitaient structurer les pages des sites avec des balises : <h1> à <h6> mais éviter certaines parties annexes dans les plans de document (mise en avant de promotions, services, etc.)

La seule utilisation parfaitement adaptée que j’ai pu trouver pour ces balises (hormis les exemples donnés par le W3C) concerne la structuration d’une FAQ. <dt> pour la question et <dd> pour la réponse.

Est-ce qu’il ne faudrait pas créer un autre type de liste qui conviendrait mieux pour mettre en relation deux éléments comme acteur/personnage, auteur/titre de livre, action/résultat, etc. ? Ce qui, selon moi, n’est manifestement pas le rôle de la liste de définition telle qu’elle a été « pensée » initialement.

Pourquoi ce formulaire ne fonctionnait pas , Tout bonnement parce que les personnes qui sont auteurs du code ont préféré se servir de javascript pour la validation des données plutôt que d’opter pour la solution html du bouton de type submit (button ou input) . Le script utilisé ne prenant visiblement en charge que certains navigateurs dans un seul environnement (windows), il est impossible pour l’internaute de valider les données qu’il a entré minitieusement dans les 45 champs du formulaire.

Le problème ne se pose pas uniquement lorsqu’on travaille avec os Mac ou Linux comme environnement, il se pose également pour quiconque se sert d’un autre navigateur qu’Internet Explorer pour commander, par exemple, sur un site de voyages qui a le monopole du transport ferroviaire…

Comment faire pour ne pas exclure des clients potentiels de votre site ?

Construisons notre formulaire en plusieurs étapes :

 
1° étape :  la construction du formulaire en html

La balise <form> :  elle définit un formulaire dans une page web.

Ses attributs :

* method

–  method= »post », indique que les données sont stockées dans le corps de la requête,  le contenu du formulaire est envoyé au serveur en tant que bloc de données pour y être traité.

– method= »get », indique que les données sont codées dans l’url,  le contenu du formulaire est juxtaposé à l’adresse URL

* action

– action= »url », action indique l’adresse d’envoi

* enctype

Ce paramètre ne peut être utilisé qu’accompagné par la méthode post. Il définit le type d’encodage des données, par exemple :

– enctype= »application/x-www-form-urlencoded »,  encode le contenu du formulaire selon une forme url

– enctype= »text/plain », le contenu du formulaire est retourné en format texte.t texte lisible par le destinataire; option accompagnée le plus souvent de ACTION=mailto:

– enctype= »multipart/form-data », permet d’expédier un fichier attaché au message.

La balise <fieldset> : elle regroupe des éléments dans un formulaire, par exemple état civil, adresse, etc.

Ses attributs : 

– Tous les attributs habituels des autres balises (id, class, title, etc.)

<legend>

Les balises des champs des formulaires :

<input>

Cette balise dans ces différents type permet l’entrée des données, qu’elles soient libres (text), soumises à un choix (radio) ou pour la validation du formulaire (submit) 

Ses attributs de type : text, password, radio, checkbox, submit, reset, image, hidden, file, button.
Ses autres attributs : name, value, checked, disabled, readonly, size, maxlength, src (pour les input de type image), alt (pour les input de type image).

<textarea>

Comme son nom l’indique il s’agit d’une zone dans laquelle on peut saisir du texte (sur plusieurs lignes).

Ses attributs : name, rows, cols, disabled, readonly.

<select>

La balise <select> permet de présenter plusieurs options de choix sous forme d’une liste déroulante.

<option>

La balise <option> permet de définir une option dans un menu (select).

<optgroup>

Les options de même type peuvent être regroupées dans un groupe d’options.

<button>

La balise button (avec l’attribut type= »submit ») permet de valider les formulaires comme un input de type submit, tout en ayant la particularité de permettre d’insérer du code html (comme du simple  texte ou une image) entre sa balise ouvrante et sa balise fermante, ce qui laisse beaucoup plus de possibilités qu’un simple champs input.  Mais attention, dans Internet Explorer ce qui est compris entre <button> et </button> sera interprété comme étant la valeur du bouton, même si un attribut value indique une valeur différente, de plus internet explorer ne retournera pas exactement ce qui est entre les deux balises mais une interprétation de ce qui se trouve entre les deux balises.

Ses attributs de type : button, submit, reset.
Ses autres attributs : name, value, typename.

Concernant le type reset pour les boutons, qu’ils soient construit avec la balise <input> ou la balise <button>, l’utilité de cette option me semble pour le moins limitée, pourquoi voudrait-on remettre à zéro les champs d’un formulaire qu’on vient juste de remplir ? Ne risque-t-on pas d’effacer malencontreusement toutes les données saisies ? Un exemple parlant : essayez de remplir ce formulaire et de le valider ensuite… Sur quel bouton avez-vous été tenté de cliquer ?

L’attribut name des champs de formulaire permet d’identifier chacun des éléments du formulaire et est indispensable pour récuperer les données du formulaire (cet attribut est déprécié uniquement sur les balises suivantes : a, applet, form, frame, iframe, img, et map). L’ajout d’un id à chaque élément est nécessaire pour rattacher chaque champs à son label. Id ne fait pas double emploi avec name

La balise <label>

Littéralement, label signifie étiquette. Cette balise permet de rattacher un nom au champs d’un formulaire, elle permet également d’agrandir la zone de focus ou de clic, très pratique notamment pour les boutons radio ou des cases à cocher dont la zone de clic est réduite.

attribut : for

Un exemple de formulaire html conçu en suivant ces recommandations :

<form action="inscription.php" method="post">
     <fieldset class="etat-civil">
          <legend>Etat civil</legend>
         <label for="nom">Nom</label>
         <input id="nom" name="nom" type="text" /><br />
         <label for="prenom">Prénom </label>
         <input id="prenom" name="prenom" type="text" /><br />
         <label for="date-de-naissance">Date de naissance</label>
         <input id="date-de-naissance" name="date-de-naissance" type="text" />
     </fieldset>
     <fieldset class="adresse">
          <legend>Adresse</legend>
          <label>Rue</label>
          <input id="rue" name="rue" type="text" /><br />
          <label>Code postal</label>
          <input id="code-postal" name="code-postal" type="text" /><br />
          <label>Ville</label>
          <input id="ville" name="ville" type="text" />
     </fieldset>
     <button onclick="alert(this.value)">Valider</button>

Les éléments de formulaire sont de type inline, sauf les éléments <form> et <fieldset> qui sont de type bloc.

Selon les besoins de présentation du formulaire on pourra intercaler des éléments <div> ou <p> pour structurer le formulaire (le débat reste ouvert sur l’utilisation de l’une ou l’autre des balises)

2° étape : Ne pas oublier les bonnes pratiques !

• En cas de rejet des données saisies dans un formulaire, les champs contenant les données rejetées sont indiqués à l’utilisateur.
• En cas de rejet des données saisies dans un formulaire, toutes les données saisies peuvent être modifiées par l’utilisateur.
• Les champs obligatoires des formulaires sont indiqués.
• En cas de rejet des données saisies dans un formulaire, les raisons du rejet sont indiquées à l’utilisateur.
• Les étapes des processus comportant des interactions multiples (commande, formulaires répartis sur plusieurs pages, etc.) sont décrites et imprimables avant leur commencement.

La liste exhaustive des bonnes pratiques pour les formulaires est consultable sur le site des bonnes pratiques Opquast

3° étape : Utilisation du javascript : Ajout de fonctionnalités et vérification du format des données.

Javascript est défini comme une surcouche à html et doit donc être distinct de ce dernier selon la règle de séparation du contenu, de la forme et des comportements. Un formulaire pour être accessible doit pouvoir fonctionner sans javascript. Javascript n’étant là que pour apporter plus de conforts à l’utilisateur. On pourra donc tester si un champs est vide ou bien compléter, si une date, un code postal ou un numéro de téléphone est renseigné dans le bon format. Cette première « validation » javascript peut être faite soit lorsque le bouton valider est cliqué, soit au fur et à mesure de la saisie en utilisant la techno Ajax, la dernière solution étant la plus communément utilisée aujourd’hui.

Exemples de formulaires vérifiés avec javascript :

1. Formulaire d’inscription du site Remember the milk

   

2. Formulaire d’inscription du site Jamendo

   

Exemples d’Aide à la saisie avec javascript :

1. Formulaire d’inscription du site CDiscount

   

2. Formulaire d’inscription du site Twitter

   

4° étape : la validation des données

L’utilisation de javascript nous a permis de vérifier le formulaire sur différents points : champs obligatoires non renseignés, formats non conformes, etc. au fur et à mesure de la saisie sans envoyer de requête inutile au serveur. Toutefois, il ne faut pas perdre de vue que sans javascript ces éléments doivent également pouvoir être testés.

Ce que nous ne pouvons pas tester en javascript sera testé après l’envoi des données, par exemple : est-ce que l’identifiant choisi n’existe pas déjà dans la base de donnée ?

Une fois toutes ces données testées, elle pourront être ajoutées à la base de données.

Dernier test à effectuer : désactivez javascript dans votre navigateur pour vérifier que le formulaire est accessible !

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

Bien qu’incomplètement prise en compte par les différents navigateur, il est possible de l’utiliser avec quelques connaissances supplémentaires, démonstration :

Prenons l’exemple simple d’un formulaire d’inscription, où il faut aligner des label à 150px du bord d’input de type texte :

Pour le code html suivant :

<form action="http://www.example.net/" method="post" id="inscription">
  <fieldset>
    <label for="prenom">Prénom <em>*</em></label>
    <input type="text" id="prenom" /><br />
    <label for="nom">Nom <em>*</em></label>
    <input type="text" id="nom" /><br />
    <label for="email">Email <em>*</em></label>
    <input type="text" id="email" /><br />
    <label for="password">Mot de passe <em>*</em></label>
    <input type="password" id="password" /><br />
    <label for="confirm-password">Mot de passe <em>*</em></label>
    <input type="password" id="password" /><br />
    <input type="submit" value="valider" class="input-submit" />
  </fieldset>
</form>

Je définis le styles des base, auxquels je vais ajouter (en gras) la propriété inline-block et les styles qui vont avec :

#inscription fieldset{border:none;}
#inscription label{display:inline-block;padding:5px 0 0;width:150px;font-weight:bold;}
#inscription input{border:1px solid #666;}

Première constatation : ça fonctionne sur la plupart des navigateurs (IE6, IE7, Opera, Safari) mais pas sur les versions de Firefox antérieures à Firefox 3…

On ajoute alors la propriété display:-moz-inline-box; pour Firefox 2 et les versions antérieures, mais attention, il faut la placer avant display:inline-block, sinon ça ne fonctionne plus pour Internet Explorer et Firefox prend en compte display:-moz-inline-box; au lieu de prendre en compte display:inline-block.

#inscription fieldset{border:none;}
#inscription label{display:-moz-inline-box;display:inline-block;padding:5px 0 0;width:150px;font-weight:bold;}
#inscription input{border:1px solid #666;}

Dans certains cas j’ai constaté des problème de layout avec Internet Explorer, dans ce cas ajouter la propriété display:inline dans une déclaration séparée :

#inscription fieldset{border:none;}
#inscription label{display:-moz-inline-box;display:inline-block;padding:5px 0 0;width:150px;font-weight:bold;}
#inscription input{border:1px solid #666;}
#IE #inscription label,
#IE #inscription .input-submit{display:inline;}

On obtient le résultat suivant, un formulaire structuré sans tableau, sans éléments flottant ou positionnés en dehors du flux html :

Seule limitation constatée, les éléments mis en inline-block dans Firefox se comporte comme ayant une propriété white-space:nowrap appliquée, il n’est pas possible d’avoir des textes sur plusieurs lignes…

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.

Habituellement faire cohabiter deux versions d’IE suffit, mais étant donné qu’une partie encore importante des internautes se cramponne au vieux navigateur IE6, il est souhaitable de pouvoir tester ses pages dans les trois dernières version du navigateur.

1ère étape : Installer Internet Explorer 8 version beta.

Pour celà aller sur le billet de Pierre du 6 mars dernier ou encore plus rapide : ici.

Une fois que c’est fait le navigateur installé, vous pouvez passer à l’étape 2.

2ème étape : Installer les précédentes versions d’IE

Il y a une solution que j’avais adopté pour la version précédente (la 7) : multiple IE, le soucis c’est que ça ne fonctionne pas avec Windows Vista. Si vous avez Windows XP, c’est nickel, mais le problème c’est que vous n’aurez pas IE7 puisque multiple IE s’arrête à IE6.

La deuxième solution consiste à installer IE7 en version standalone. Pour les infos : c’est ici ou encore ici.

Une fois avoir installé IE7, on va essayer d’installer multiple IE, mais auparavant on va voir si IE8 et IE7 s’entendent… D’après mes tests, ça marche pas trop mal, mais il ne faut pas être gêné par les messages d’erreurs. J’ai principalement ce message au chargement de la première page dans IE7 :

L'ordinal 14 est introuvable dans la bibliothèque de liaisons dynamiques iertudil.dll

On peut ensuite installer Multiple IE. D’après mes test cette solution n’est pas pleinement fonctionnelle. Je n’ai pas pu accéder au champs de recherche de Google, impossible de prendre le focus…

Si vous n’avez pas XP mais Vista, vous allez forcément opter pour la troisième solution : installer un émulateur de PC pour faire tourner windows… sous windows. Virtual PC est disponible sur le site de Microsoft, mais je n’ai pas réussi à l’installer jusqu’au bout, il est vrai que je dispose de la version light de Vista, la home premium*, donc si vous êtes comme moi, vous allez plutôt vous porter sur mon deuxième choix : Virtual Box. Là pas de problème l’install se passe sans encombre. Il ne reste plus qu’à installer la version native d’IE6 ou IE7 en téléchargement sur le site de Microsoft. Après, à vous de voir : soit installer multiple IE ou IE7 en version standalone, soit opter pour une version différente par PC virtuel…

Vous avouerez que ça fait pas mal de soucis pour un navigateur qu’on n’utilise uniquement pour tester ses pages, non ?

* Host operating system: Windows Vista Business, Windows Vista Enterprise, Windows Vista Ultimate, Windows Server 2003 Standard Edition, Windows Server 2003 Standard x64 Edition, Windows XP Professional, or Windows XP Tablet PC Edition (source site microsoft.com)

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

L’annonce sur le blog du WHATWG : http://blog.whatwg.org/html-5-published-as-w3c-first-public-working-draft

Vous trouverez sur la page suivante les différences entre HTML4 et HTML5 : http://www.w3.org/TR/html5-diff/

Laurent Jouanneau a publié un excellent article à ce sujet : http://ljouanneau.com/blog/2008/01/23/747-premier-brouillon-de-html5

Il va cibler les éléments un par un, plutôt que d’utiliser le sélecteur universel (non, rien à voir avec quelque puissance divine) pour diverses raisons :

• Il ne faut pas styler les intouchables : Boutons radio, Cases à cocher et leurs amis peuvent se montrer très capricieux…
• Certaines propriétés sont spécifiques à un élément. Quelle doit être la réaction d’un navigateur lorsqu’une propriété CSS ne correspond pas à l’élément ciblé ?

Corinne Schillinger a publié sur le blog d’alsacreations un billet dans lequel se pose la question suivante :

Est-ce une bonne chose de remettre à 0 certains styles par défaut ?

Le principal argument en défaveur du reset est l’oubli dans notre CSS de styler certains éléments.

Ma réponse sera précise, tranchée et définitive : mmm… ça dépend.

Prenons la feuille de style par défaut recommandée par la spécification CSS2.

Cette CSS a été établie dans une « logique XML », c’est à dire de séparation stricte entre le contenu et la mise en forme. Pour prendre un exemple, elle part du principe que <head> est un élément du document, et lui applique une propriété display:none.

Comme précisé en haut de ce document, il est uniquement publié à titre informatif, et ne fait pas partie de la norme : chaque navigateur est libre d’appliquer ses propres styles par défaut : on pourrait par exemple imaginer un navigateur qui appliquerait une couleur pour chaque titre, suivant son importance.

Je pense que le problème est là : et si les navigateurs n’appliquaient les styles par défaut qu’en l’absence de CSS ?

Difficilement concevable en l’état actuel des choses :

• 99% des auteurs ajouteraient cet énorme bloc dans leurs CSS.
• La plupart des éléments ont été conçus par rapport à leur display par défaut, comme l’élément table et ses enfants, et il est rarement modifié.
• Comment réaliser l’élément <legend> d’un <fieldset> en CSS (Non ce n’est pas un défi, lâchez cet éditeur et je vous promets qu’il ne vous arrivera rien) ?

Néanmoins, je pense que le concept est intéressant : pourquoi devrait-on s’appuyer sur une CSS imprévisible pour construire la nôtre ?

Dans le monde réel, la réponse est simple : nous savons que les navigateurs, à quelques différences près, appliquent les mêmes styles par défaut.

Il faut je pense, se reposer sur le plus évident en supprimant les différences : la propriété display de chaque élément est définie dans la DTD HTML4, par exemple. Chaque navigateur l’interprète de la même façon et il est inutile de la redéfinir. Tant que nous n’avons pas vu de navigateur aux titres multicolores, nous pouvons encore compter sur l’héritage de body pour définir un color:#000 sur tous les textes.

La solution d’Eric Meyer est un très bon compromis pour le moment, en attendant de trouver une solution idéale (…ce qui risque de prendre un moment), et à condition d’adhérer au principe de séparation stricte contenu / mise en forme.

Et le risque d’oublier le style d’un élément ?

En appliquant une CSS à une page, on assume le fait de ne pas respecter le style par défaut du navigateur en proposant à l’utilisateur une nouvelle présentation. Je pense qu’il faut alors aller jusqu’au bout en prenant en charge le style de tous les éléments.

On peut oublier de styler certains éléments, mais on ne devrait pas.

On peut oublier son anniversaire de mariage, mais on ne devrait pas.