Aller au contenu

Centrer un texte en hauteur

Je réagis à un billet de Jay Salvat qui explique comment centrer un texte en hauteur (et en largeur). Je n’avais pas prévu de faire un billet à la base mais de laisser un commentaire sur http://blog.jaysalvat.com. Devant l’impossibilité de laisser un commentaire avec du code html et css, je vais détailler ici deux différentes façons de centrer un texte en hauteur (deux manières qui, nous allons le voir, sont complémentaires).

Pour un code html donné :


<div id="container">
    <div class="level1">
        <div class="level2">
            Texte centré en hauteur<br />
            sur plusieurs lignes
        </div>
     </div>
</div>

Appliquons un code css qui va permettre de considérer la div contenant le texte comme une cellule de tableau :


div{width:500px;}
#container{height:80px;background-color:red;display:table;}
.level1{display:table-cell;vertical-align:middle;}

Le conteneur (#container) est considéré comme étant l’élément table (cette ligne n’est pas obligatoire comme nous l’avons vu dans un autre article des Intégristes qui explique le fonctionnement du display:table), la div qui a la classe level1 est considérée comme étant une cellule de tableau et se comportera de la même manière. Pour centrer le texte en hauteur on lui applique le couple propriété/valeur vertical-align:middle.

Un petit tour des navigateurs les plus communément utilisés, nous permet de nous rendre compte que cette solution ne convient pas à Internet Explorer (6 et 7). Nous allons nous servir de la div.level2 qui n’avait aucune utilité dans l’exemple précédent pour appliquer le code CSS suivant uniquement à Internet Explorer en utilisant les commentaires conditionnels HTML :


<!--[if IE]>
<style type="text/css" media="screen">
div{width:500px;}
#container{height:80px;position:relative;background-color:red;}
.level1{position:absolute;top:50%;}
.level2{position:relative;top:-50%;}
</style>
<![endif]-->

Pour que le code css précédemment créé et qui fonctionne dans les navigateurs hors IE ne s’applique pas à IE, nous allons ajouter, les commentaires suivants :


<!--[if !IE]>-->

<!--<![endif]-->

Ce qui donne


<!--[if !IE]>-->
<style type="text/css" media="screen">
div{width:500px;}
#container{height:80px;background-color:red;display:table;}
.level1{display:table-cell;vertical-align:middle;}
</style>
<!--<![endif]-->

Vous allez certainement me poser ma question : pourquoi ne pas appliquer la deuxième solution à tous les navigateurs et pas uniqument à IE6 ?
Tout bonnement parce que la deuxième solution ne fonctionne que dans IE !

Plus d’exemples dans ce tutorial vraiment complet du blog In The Woods”

Tags : , ,

Concevoir un formulaire HTML qui tient la route

Il ne vous est jamais arrivé de remplir un long formulaire pour, par exemple, commander un voyage ou un vol et ne pouvoir le valider parce que le clic sur le bouton de validation du formulaire ne produit aucun résultat ? C’est ce qui m’est arrivé il y a quelques semaines de celà… C’est vrai que je suis passé de PC à Mac et que je fais maintenant partie d’une minorité. L’accessibilité prends dans ce cas tout son sens. J’ai eu beau essayer avec Safari, Firefox, Opéra, Google Chrome, rien n’y a fait. Bref si je n’avais pas eu un PC pas loin pour passer ma commande avec Internet Explorer cette compagnie aérienne aurait perdu un client.

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

    formulaire remember the milk

  2. Formulaire d’inscription du site Jamendo

    formulaire de jamendo

Exemples d’Aide à la saisie avec javascript :

  1. Formulaire d’inscription du site CDiscount

    Formulaire CDiscount

  2. Formulaire d’inscription du site Twitter

    Formulaire d'inscripton 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 !

Introduction à WAI ARIA (traduction)

Illustration par Grégoire Dierendonck
Grégoire Dierendonck

L’article qui suit est la traduction de l’article “Introduction to WAI ARIA“, publié par Gez Lemon sur Dev Opera, le site d’Opera Software destiné aux développeurs.

Gez Lemon est un expert reconnu de l’accessibilité web. Il est membre du WaSP ( Accessibility Task Force ) et travaille pour The Paciello Group, entreprise de conseil spécialisée dans l’accessibilité web.

Cette traduction, comme l’article original, est placée sous licence Creative Commons by-nc-sa 2.5.

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.

Poursuivre la lecture ›

Tags : , , ,

Accessibilité VS référencement : quelles méthodes pour (ré-)concilier les deux ?

Après avoir lu sur de nombreux sites traitant de la question du référencement des pages web par les moteurs de recherches que le javascript était néfaste au référencement dans la mesure où les robots ne peuvent lire le contenu pertinent qui serait généré par javascript, ce langage serait-il devenu l’arme ultime des référenceurs, dans une utilisation à contrario ?

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 :

Tags : , ,

Quoi de neuf du côté des mises en page CSS (CSS Layouts) ?

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