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. (Lire la suite…)

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

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

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

(Lire la suite…)

Qu’elle soit intuitive, claire, que le regroupement des catégories soit logique, que les risques d’erreurs soit limités, que les messages d’information soient clairs ?
Tout ça et bien d’autres choses encore.

Je voudrais aujourd’hui parler plus particulièrement des boutons d’actions que ce soit des boutons de validation de formulaire ou des liens de navigations.
(Lire la suite…)

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.
(Lire la suite…)

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.

(Lire la suite…)

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 avez certainement lu comme moi, que tout ce que vous saviez sur les css étaient faux en lisant l’article de Digital Web par Rachel Andrew. Je n’ai pas lu le livre, mais à la lecture de l’article j’ai voulu tester une nouvelle manière de mettre en page mon code html. Avec l’arrivée d’IE8, on va pouvoir enfin utiliser les propriétés CSS display:table, display:table-row et autres display:cell. Et je me pose la question suivante : à quoi servent réellement ces propriétés ? Parce que si on a bataillé, argumenté et convaincu des dizaines de personnes que les tableaux c’est mal, c’est pas pour simuler des tableaux en CSS ! Justement l’auteure nous réponds à ce sujet :

L’élément table en HTML est une structure sémantique, il décrit des données. Par conséquent, l’élément table est à utiliser uniquement pour des données tabulaires, par exemple un tableau mettant en forme des informations financières. Ces informations seraient normalement stockées dans une feuille de calcul sur votre ordinateur, il faudrait probablement un tableau pour les présenter en HTML.

La valeur table de la propriété display, d’un autre côté est simplement une indication de la présentation à afficher dans le navigateur – elle n’a pas de signification sémantique. Utiliser un élément table pour votre mise en page donne l’information suivante au user-agent : ces données sont tabulaires. Utiliser plusieurs divs qui ont la propriété display avec les valeurs table ou table cell, ne dit rien de plus au user agent que demander de les rendre visuellement d’une certaine façon, s’il en a la capacité.

Donc pas de problème, du moment que notre code html reste sémantique, on peut y aller ?

Quels sont actuellement les moyens dont nous disposons pour mettre notre code html en forme ?

1. Mise en forme à l’ancienne

   Il y a quelques années (au temps de netscape 4 et IE 5.5), j’aurais fait (à peu près) une mise en forme de ce style :

   Mise en page en tableau

2. Mise en page avec des éléments flottants *

   Pour moi la façon la plus fluide de mettre une page en forme, et qui permet beaucoup de flexibilité.

   Mise en page avec des divs flottants

3. Mise en page avec des éléments en absolu *

   Pratique dans certains cas mais je ne la conseillerais pas, trop figée pour des sites qui évoluent en permanence.

   Mise en page avec des éléments en absolu

4. Mise en page avec des display:table

   L’article de Digital web présente cette façon de faire. En lisant l’article, ça a l’air simple. Bon sang, mais c’est bien sur ! Pourquoi n’avions nous pas pensé à cette façon de faire plus tôt ? Bon, ok, on l’oublie à cause d’IE6, mais parfois on aime bien se projeter dans le futur et essayer de nouvelles choses, juste pour le sport… Je reprends donc mon design minimaliste : un header, une colonne de gauche, une colonne de droite et un footer. Simple. Je me base sur mon intégration old school et essaie d’appliquer la méthode vue dans l’article cité ci-dessus. Pas besoin de reprendre l’intégralité du code des tableaux (thead, tbody, tfoot, tr, etc…) puisque les éléments manquants sont créés virtuellement par le navigateur.

   Une esquisse de résultat…

Essayons maintenant de faire un colspan… hum, comment fait-on ? Puisque les propriétés du tableau sont définies en CSS et pas en HTML ? Après maintes recherches je déclare forfait. Avez-vous la réponse ?

En reprenant l’article, je me rends compte que ce n’est pas évoqué. Les seuls cas envisagés sont simples voire simplistes. Ok pour un site perso, mais ce n’est vraiment pas adapté pour un environnement professionnel. Loin de révolutionner notre façon d’utiliser les CSS, cette démonstration reste pour moi rien de plus qu’un exercice de styles…

On devra certainement attendre longtemps avant de voir arriver des CSS spécialement dédiés à la mise en forme de page web, en attendant vous pouvez toujours aller voir le document de travail Advanced Layout du W3C.

* Des tas d’exemples de mise en page sur les sites suivants :

http://layouts.ironmyers.com/100_percent_Layouts/
http://blog.html.it/layoutgala/
http://sherina.blogsome.com/2008/07/29/10-css-layout-demos/
http://www.smashingmagazine.com/2007/01/12/free-css-layouts-and-templates
http://css-discuss.incutio.com/?page=CssLayouts
http://www.free-css.com/free-css-layouts/page1.php
http://www.code-sucks.com/css%20layouts/faux-css-layouts/
http://www.free-css.com/free-css-layouts/page1.php

• 50% des pages n’ont pas de doctype
• la proportion des types de page est de l’ordre  de 1 doctype strict pour 10 doctypes transitionnels
• 4,13% des pages sont conformes
• Les tableaux sont présents dans plus de 80% des documents, essentiellement pour faire de la mise en page et non pour présenter des données tabulaires

Autant dire que les automatismes ne sont pas acquis par tout le monde et que faire respecter les standards est un travail de longue haleine. Il n’est pas inutile de rappeler comment bien structurer ces pages et comment appliquer les bonnes pratiques. Ce que nous ne manquerons pas de faire dans nos prochains billets.

Cette idée nous a paru sympathique et séduisante et chez Les Intégristes nous avons choisi de l’adopter. Seulement voilà, en retournant sur le site cette semaine, nous avons été fortement étonnés d’être redirigés vers la page de téléchargement des deux dernières versions d’Internet Explorer, chez Microsoft. J’ai donc essayé de rechercher des informations et je n’ai rien trouvé à ce sujet, nulle part…

La traduction française du site ayant été faite par Le détracteur constructif, je suis donc allé leur poser la question :

Q:Bonjour,
Nous adhérons fortement, chez les “intégristes”, à l’idée de progressivement délaisser IE6 pour enfin évoluer vers d’autres possibilités d’intégration et de développement que ne permets pas IE6, alors forcément l’idée de “savethedeveloppers” nous parait sympathique. Cependant depuis quelques jours l’URL “http://www.savethedevelopers.org” renvoie vers “http://www.microsoft.com/windows/internet-explorer/download-ie.aspx” la page de téléchargement de la dernière version d’Internet Explorer. J’ai essayé de trouver des infos à ce sujet sans succès… Qu’en est-il ?

A:Wow en effet… Hmm il je me demande si le projet a été “avorté” par Microsoft, à grand coups d’argent. Je vais essayer de voir si j’ai encore mon contact avec les gens qui faisaient ce site, et je vous reviens là dessus…

Si tel est le cas, cette initiative doit être très récente parce que le dernier message posté sur Twitter par savethedeveloppers est daté du 15 octobre dernier : » New products for winter and site supporters added. »

Est-on en présence d’une affaire du type Mikerowsoft ? En tout cas chez Les Intégristes nous avons retiré ce script qui maintenant incite les internautes à télécharger exclusivement Internet Explorer…

Nous vous communiquerons plus d’informations dès que possible, si de votre côté vous pouvez éclairer notre lanterne n’hésitez pas à poster.