(Lire la suite…)

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

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

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