Zen-coding :

• Smashing Magazine a consacré récemment un tutoriel sur le sujet ;
• quelques curieux s’y essayent en ce moment sur Twitter.

Suffisamment d’éléments pour donner envie d’en parler un peu ici. Il faut dire aussi que je suis plutôt convaincu par les possibilités offertes.

De quoi s’agit-il exactement ?

Zen-coding propose simplement quelques automatisations qui viennent se greffer sur votre éditeur habituel.

La fonctionnalité principale (implémentée en premier sur les éditeurs) est basée sur la syntaxe des sélecteurs CSS : idéal pour ne pas être dérouté.

Par exemple si j’entre :

div#content>p.intro+ul>li*3>a

J’obtiens immédiatement :

<div id="content">
    <p class="intro"></p>
    <ul>
        <li><a href=""></a></li>
        <li><a href=""></a></li>
        <li><a href=""></a></li>
    </ul>
</div>

On joue donc entre les sélecteurs enfants et adjacents pour construire sa structure d’une ligne.

Les « abréviations » permettent également donc de générer un grand nombre d’éléments HTML pré-construits ainsi que des propriétés CSS.

Tout cela est très efficace, d’autant qu’une fois le code généré, il suffira de tabuler pour que l’éditeur fasse passer votre curseur sur les endroits où du contenu doit être ajouté.

Sur l’exemple précédent, c’est :

<div id="content">
    <p class="intro">ici,</p>
    <ul>
        <li><a href="ici,">ici,</a></li>
        <li><a href="ici,">ici,</a></li>
        <li><a href="ici,">et ici.</a></li>
    </ul>
</div>

Autre fonctionnalité intéressante : la possibilité de sélectionner de manière progressive des portions de code. Toujours en reprenant l’exemple précédent, et en supposant que je place mon curseur entre « et » et « ici. », à chaque fois que je déclenche la fonctionnalité je sélectionne :

• et ici. ;
• <a href="ici,">et ici.</a> ;
• <li><a href="ici,">et ici.</a></li> ;
• etc.

Et bien sûr la sélection est faite de manière à pouvoir supprimer le bloc proprement d’un coup.

Arrive également la possibilité d’ajouter autour de la structure sélectionnée une nouvelle abréviation.

Je peux par exemple facilement produire en quelques raccourcis claviers :

<div id="content">
    <p class="intro">ici,</p>
    <div class="blocs ajoutes par la suite">
        <div class="blocs">
            <ul>
                <li><a href="ici">ici,</a></li>
                <li><a href="ici">ici,</a></li>
                <li><a href="ici">et ici.</a></li>
            </ul>
        </div>
    </div>
</div>

Tout cela sans devoir à aucun moment revoir mes indentations.

Pour les utilisateurs avancés, il est également possible de (re)définir finement de nouveaux modèles, en précisant syntaxes, positions du curseurs, etc.

Plongez-vous également dans les filtres de sortie qui semblent eux aussi très puissants.

Parfait ?

Pratique en tout cas. Il faudra cependant prendre le temps d’appendre les raccourcis clavier propres à votre éditeur pour en profiter pleinement. Et surtout croiser les doigts pour que votre éditeur favori supporte le plugin convenablement.

Difficile de se défaire de nos petites habitudes acquises au jour le jour pour en adopter d’autres… mais il semblerait que ça vaille le coup d’essayer.

Les objectifs

Bien qu’en apparence très basique, le travail du développeur web client requiert de s’assurer d’une multitude de choses (non, nous ne nous occupons pas que du rendu visuel). Pour de ne rien oublier, j’utilise une check-list qui répond aux besoins habituels.

Ce document (à adapter à fonction des besoins du projet) permet une bonne vision d’ensemble sur l’avancement et les éventuels oublis lors de la phase d’intégration.

Je la fournis aussi au format « Markdown » pour plusieurs raisons :

• ce format en texte brut est facilement compréhensible et modifiable par n’importe qui ;
• il peut être aisément convertit au format HTML et être placé à la racine du projet ;
• c’est un format que j’ai adopté dans mes processus avec lequel j’ai l’habitude de travailler.

En pratique, il s’agit au cours du développement d’annoter le document, et de compléter chaque ligne par un OK / NOK / N/A.

La première partie concernant des résultats attendus pour chaque page, elle servira aussi aisément d’index.

Comme précisé dans le document, je ne suis pas l’auteur de cette liste : je n’ai fait que reprendre et combiner plusieurs existants.

La checklist

Voici donc :

• le fichier markdown ;
• sa transformation en HTML.

Si vous travaillez en PHP le code de transformation est simpliste :

<?php
    include_once('markdown.php');
    include_once('smartypants.php');
    echo(SmartyPants(Markdown(file_get_contents('checklist.markdown'))));
?>

Et vous trouverez les sources nécessaires dans le lien donné plus haut.

Checklist
=========

Conformité et affichage {#conformite}
-------------------------------------

Maquette                     | Validation XHTML                | Validation CSS                  | Safari | Fx   | IE 6 | IE 7 | IE 8 | Opera | Chrome | Lynx [^1] | Impression | iPhone | YSlow
-----------------------------|---------------------------------|---------------------------------|--------|------|------|------|------|-------|--------|-----------|------------|--------|-------
[Accueil](accueil.html)      |   erreur(s),   avertissement(s) |   erreur(s),   avertissement(s) |        |      |      |      |      |       |        |           |            |        |
[Contact](contact.html)      |   erreur(s),   avertissement(s) |   erreur(s),   avertissement(s) |        |      |      |      |      |       |        |           |            |        |
[Rechercher](recherche.html) |   erreur(s),   avertissement(s) |   erreur(s),   avertissement(s) |        |      |      |      |      |       |        |           |            |        |
[...](#)                     |   erreur(s),   avertissement(s) |   erreur(s),   avertissement(s) |        |      |      |      |      |       |        |           |            |        |


[^1]: L’affichage Lynx est proche de la restitution faite par un lecteur d'écran ou de ce qui est perçu par un moteur de recherche.

Sur l'ensemble des maquettes [^2]
---------------------------------

Contenu et style                                                                                                                             | Validité
---------------------------------------------------------------------------------------------------------------------------------------------|----------
Vérifier la ponctuation : particulièrement les apostrophes, les guillemets, les marques de citations, les traits d’union et les tirets       |
Ne faire ni d'faute d'orthographe ni de grammaire                                                                                            |
La capitalisation doit être uniforme et traitée par CSS                                                                                      |
Proscrire les phrases passe-partout ou récurrentes ("En savoir plus...")                                                                     |
Éviter les variations dans les mots ("email" vs "e-mail" vs "courriel")                                                                      |
Traitement des listes (points, virgules, ou point-virgules à la chaque fin d’élément)                                                        |
S’assurer qu’aucun contenu de test ne subsiste ("lorem ipsum...")                                                                            |
Vérifier tous les textes cachés (les `alt`, retranscriptions, les textes dans les fonctions JS)                                              |

Visibilité moteur de recherche                                                                                                               | Validité
---------------------------------------------------------------------------------------------------------------------------------------------|----------
Les titres (`title`) des pages sont importants, s’assurer qu’ils aient un sens et soient représentatifs des mots clefs présents dans la page |
Créer des `metadata description` pour les pages importantes                                                                                  |
S’assurer que le marquage du contenu respecte la sémantique HTML (`h1`, `p`,...)                                                             |
Vérifier le format des urls (urls simples à retenir pour les utilisateurs et les moteurs de recherche)                                       |

Conformité                                                                                                                                   | Validité
---------------------------------------------------------------------------------------------------------------------------------------------|----------
Voir [tableau ci-dessus](#conformite)                                                                                                        |


Accessibilité                                                                                                                                | Validité
---------------------------------------------------------------------------------------------------------------------------------------------|----------
Indiquer le langage humain principal du document en utilisant l'attribut lang au sein de la balise `<html>`                                  |
Indiquer les passages en langage secondaire dans d'autres balises encadrant le passage concerné                                              |
Proposer des liens de navigation dès le début du balisage lorsque les pages contiennent beaucoup de contenu avant le contenu principal       |
Indiquer des en-têtes dans les tableaux de données avec des balises `<th>`, et associer toutes les cellules de données à leurs en-têtes      |
S'assurer que l'ordre des tabulations est logique, en utilisant tabindex au besoin                                                           |
S'assurer que la page fonctionne toujours quand les images sont désactivées                                                                  |
S'assurer que les pages restent utilisables quand les utilisateurs agrandissent le texte au double de sa taille originale                    |
Vérifier que chaque élément de la page est accessible et manipulable au clavier                                                              |
Rédiger des textes d'appel de liens qui puissent être compris hors contexte (pas de liens titrés "cliquez ici")                              |
Pour les daltoniens ou les malvoyants, s'assurer de proposer un contraste suffisant entre le contenu et le fond de la page                   |
N'utiliser aucun contenu qui clignote plus de trois fois par seconde                                                                         |
Ne pas cacher l'indicateur de focus. Quand un utilisateur navigue au clavier, il doit toujours savoir où ces éléments se trouvent            |
Ne pas attendre des utilisateurs qu'ils perçoivent du sens grâce aux polices, aux couleurs ou à d'autres modifications de style              |
Être brefs dans les textes alternatifs, mais donner du détail dès lors qu'il y a du sens à transmettre                                       |
Fournir un script, des sous-titres, et/ou une traduction en langue des signes pour toutes les vidéos ou les sons contenant du discours       |
Fournir une version "descriptive" d'une vidéo lorsqu'il est essentiel d'en comprendre le contenu pour des utilisateurs non-voyants           |
S'assurer que toutes les vidéos, si elles ne se lancent pas automatiquement, offrent au minimum une touche de lecture accessible             |
Quand du texte peut être interprété visuellement par le navigateur aussi bien que s'il s'agissait d'une image, éviter d'utiliser des images  |
Éviter les CAPTCHAs (questionnaires de test visuels anti-robots)                                                                             |
Marquer tous les champs de formulaire avec la balise d'étiquetage `<label>`                                                                  |
Utiliser les regroupements de champs (`<fieldset>`) avec des balises de titrage (`<legend>`) pour associer des demandes de saisie            |
Recenser toutes les erreurs de saisie au format texte, et placer le message à côté du champ concerné ou à un emplacement bien repérable      |
Offrir des liens d'aide ou des instructions en ligne pour remplir les champs si nécessaire                                                   |
Ne pas laisser les utilisateurs effectuer des actions importantes sans leur proposer une confirmation ou un moyen d'annuler                  |

Tests fonctionnels                                                                                                                           | Validité
---------------------------------------------------------------------------------------------------------------------------------------------|----------
Vérifier toutes les fonctionnalités complexes                                                                                                |
Tester avec différentes configurations de résolutions d’écran                                                                                |
Tester tous les formulaires, incluant les filtres anti-spam, les réponses aux formulaires et emails, etc.                                    |
Tester sans JS, Flash et tous les autres plugins                                                                                             |
Vérifier que tous les liens externes sont valides                                                                                            |

Performances                                                                                                                                 | Validité
---------------------------------------------------------------------------------------------------------------------------------------------|----------
Vérifier l’optimisation des images                                                                                                           |
Vérifier et mettre en place le cache quand nécessaire                                                                                        |
Vérifier le temps de chargement et le poids des pages                                                                                        |
Minimiser/compresser les fichiers statiques une fois les développements terminés (JS/CSS)                                                    |
Optimiser votre CSS : utiliser des chemins courts vers les images, utiliser la nature du CSS c’est à dire l’héritage, etc.                   |

Touches finales                                                                                                                              | Validité
---------------------------------------------------------------------------------------------------------------------------------------------|----------
Créer des pages d’erreur / 404                                                                                                               |
Créer un favicon                                                                                                                             |

[^2]: Fortement inspiré de
      "[The Ultimate Website Launch Checklist](http://www.boxuk.com/blog/the-ultimate-website-launch-checklist)" et de
      "[La checklist d’accessibilité que je m’étais juré de ne pas rédiger](http://www.pompage.net/pompe/checklistaccessibilite)".

*[vs]: Versus
*[IE]: Internet Explorer
*[Fx]: Firefox
*[JS]: JavaScript
*[etc]: Et cætera
*[NOK]: Non OK
*[N/A]: Non applicable
*[CSS]: Cascading Style Sheets
*[AJAX]: Asynchronous JavaScript and XML
*[ARIA]: Accessible Rich Internet Applications
*[XHTML]: eXtensible HyperText Markup Language

Pour rebondir sur l’article précédent de STPo et ses nombreux commentaires, j’ai voulu tester plusieurs choses :

• le support des pseudo-selecteurs version selecteur::pseudo-selecteur ;
• le support du pseudo-selecteur :first-line ; notamment quand on effectue un zoom-texte associé ;
• la prise en compte (ou non) des caractères typographiques combinés avec first-letter (ici le guillemet suivi ou non d’un espace et l’apostrophe).

Support

:first-letter et :first-line sont supportés sur tous les navigateurs habituels :

• IE 6 ;
• IE 7 ;
• IE 8 ;
• Firefox ;
• Opera ;
• Safari ;
• Chrome.

Assez étonnement ::first-letter et ::first-line ne sont pas pris en compte par IE 7 et IE 8 alors qu’ils marchent partout ailleurs (IE 6 compris).

Le comportement de first-line correspond bien au comportement attendu : la sélection varie en fonction du zoom effectué sur la page et il s’agit bien en permanence de la première ligne qui est sélectionnée.

Subtilités typographiques

En théorie devrait first-letter s’appliquer à la première lettre et donc à la ponctuation qui l’accompagne.

Les caractères de ponctuation […] qui précèdent la première lettre devraient également être pris en compte

En pratique on constate un rendu plus ou moins correct de :

• Chrome (hormis un petit bug avec les espaces insécables encodés  ) ;
• Safari (avec le même petit bug) ;
• Firefox (mais sans le support des espaces) ;
• Opera (mais uniquement avec des guillemets droits et sans le support des espaces) ;
• IE6 et IE 7 (mais uniquement avec des guillemets droits, exit donc les guillemets à la française) ;
• et IE 8 (mais sans le support des espaces, ce qui est fortement pénalisant là encore).

En une phrase : seul le moteur de rendu WebKit s’en sort correctement.

Voici le fichier qui m’a permis de faire mes tests, si vous voulez compléter mon analyse ou tester à votre tour. Vous pouvez également regarder le support navigateur proposé sur Web Devout.

Non, ce blog n’est pas mort ! Bien que ce soit encore STPo qui s’y colle…

La lettrine, c’est la première lettre d’un paragraphe mise en exergue. Le plus souvent, elle est sublimée grâce à un corps de texte plus important et parfois à l’aide d’ornements graphiques.

Je m’intéresserai ici au cas d’une lettrine simple en utilisant la pseudo-classe CSS first-letter, a priori toute indiquée pour un contenu en HTML.

Quelques règles typographiques

En fouinant sur le web, je suis tombé sur ce vieil article qui rappelle les règles à suivre concernant les lettrines. Je les reproduis honteusement ici :

1. La lettrine porte généralement sur deux lignes, parfois plus ;
2. Elle ne doit pas être découverte ; au moins une ligne doit doubler sous la lettrine ;
3. L’espace du premier mot doit être adapté en fonction de la lettrine ;
4. La fin du premier mot s’écrit en petites capitales ;
5. Le sommet de la lettrine doit être visuellement aligné avec les ascendantes des lettres de la première ligne du texte.

C’est le point 5 qui va nous poser problème ici, à cause des différences d’interprétation par les moteurs graphiques des navigateurs (une fois n’est pas coutume)…

Un peu de code

Le code, ici, est enfantin. Le CSS :

/* font-size à 1em et line-height à 1.5 */
p{ 
    font-size: 1em;
    line-height: 1.5;
    width: 30em;
    margin: 3em auto;
}

/* font-size à 3em et line-height à 1, ce qui correspond en théorie à la hauteur de 2 lignes de texte courant
    et float pour laisser courir le texte */
p:first-letter{
    float: left;
    font-size: 3em;
    line-height: 1;
    margin-right: 0.2em;
}

/* juste pour mettre le premier mots en petites capitales */
p span{ font-variant: small-caps; }

Et le HTML :

    <p>
        <span>Lorem</span>
        ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
    </p>

Et maintenant, la partie désagréable…

Firefox le pénible

Voici les résultats des interprétations de la démo par les navigateurs :

On constatera que c’est globalement homogène chez Internet Explorer (versions « modernes »), Webkit et Opera, mais que Firefox 3.6 décale inexplicablement la lettrine vers le haut. Même Firefox 2 s’en sortait mieux (bon, il sautait une ligne supplémentaire mais au moins c’était aligné).

En tant qu’ayatollah affiché du rythme vertical, tout cela me chiffonne un brin. Non pas que j’utilise les lettrines très souvent (c’est même plutôt rare), mais j’aimerais bien comprendre d’où vient ce défaut.

J’ai trouvé cet article qui en parle mais n’aborde pas le point qui me gêne ici et se contente d’affirmer que la lettre ne passe pas en type block (malgré le float).

J’en appelle donc aux fans de prises de tête. À vos plumes, à vos idées, à votre bon cœur !

STPo

(english version below)

C’est au tour de Christophe Andrieu de prendre le clavier. Décidément, on n’est plus chez soi !

Même si sur le moment il ne m’avait pas frappé outre mesure, je repense assez fréquemment au coup de gueule de Gilles Vauvarin lors de sa conférence à Paris-web cette année : il était consterné que les intégrateurs ne respectent pas le rythme vertical de ses designs.

Ce fut l’occasion de me rappeler à quel point c’était super, le rythme vertical. Et à quel point j’en avais bavé à chaque fois que j’ai essayé de l’implémenter en CSS.

(C’est quoi le rythme vertical ? Allez lire cet excellent article de David sur le sujet)

Blueprint et les navigateurs sont dans un bateau

Remotivé par le sujet, j’attaque donc mon nouveau design avec Blueprint, framework CSS bien connu pour gérer intelligemment ce genre de problématiques délicates. On me l’a notamment conseillé pour éviter de me prendre la tête avec les calculs d’interlignages en em, qui donneraient des cauchemars à Pythagore en personne.

Hélas ! J’ai déchanté assez vite. Conserver un rythme vertical avec un vrai design (même minimaliste) est excessivement complexe, Blueprint ou pas Blueprint.

J’ai notamment buté sur les arrondis générés par les moteurs de rendu des navigateurs, qui ne sont apparemment pas calculés de la même manière.

Comme tout est défini en em, on se retrouve assez rapidement avec des styles générés assez exotiques : si mon line-height est de 1.5 et ma font-size de base de 11 px (12 px c’était trop facile), mon line-height généré va être de 1.5 × 11 = 16.5 px… et les demi-pixels, les navigateurs, en gros, n’aiment pas.

Ou du moins, ils ne l’interprètent pas tous de la même façon (ou alors j’ai vraiment raté un train). Ce qui oblige à une certaine gymnastique pour retomber sur des calculs de pixels générés entiers – qui eux sont interprétés de la même manière partout. Par exemple là, pour avoir un line-height généré de 17 px (mettons), je vais devoir mettre line-height:1.565… et encore, ça reste un arrondi.

Imaginez maintenant qu’on rajoute des bordures CSS, des images, bref toutes sortes de contenus et de styles qui décalent tout au fur et à mesure avec toujours plus d’arrondis.

Je ne vous fais pas de dessin, c’est un enfer !

Tout passer en pixels ?

Bref, j’ai été vite écœuré de cette mélasse d’em qu’on nous a pourtant appris à aimer dogmatiquement durant toutes ces années d’évangélisation aux bonnes pratiques.

D’où une question bien légitime : « mais pourquoi n’utilise-t-on pas tout simplement le pixel, unité native de notre medium ? ».

Évidemment, on sait qu’IE ne comprend pas grand-chose aux agrandissements de textes dès qu’on lui parle en pixels… et on entre alors dans des considérations plus philosophiques que techniques. Doit-on laisser IE sur le carreau ? N’est-il de toute manière pas intéressant de conserver des unités relatives pour les marges entre paragraphes (par exemple), afin de conserver nativement des proportions harmonieuses ?

Stéphane en parlait il y a deux ans de ça, les choses n’ont pas évolué depuis, et c’est bien dommage.

Bref, une piste à oublier, probablement.

Vers un mode de calcul normalisé pour tous les navigateurs ?

Revenons aux em : pourquoi les moteurs graphiques des navigateurs sont-ils infoutus de gérer les arrondis de décimales de pixels de la même manière ?

Y a-t-il des groupes de travail là-dessus ? Des ressources en ligne ? Est-ce que j’ai loupé quelque chose en route ?

Si vous avez des éléments de réponse je suis avide de les entendre…

Pour le moment, j’ai cette phrase de Stéphane qui me reste en travers de la gorge : « le rythme vertical pour moi, ne peut se tenir qu’avec des bricoles en JS : CSS n’est pas assez solide pour ça ».

Dites-moi que c’est faux !

Éric a récemment abordé le cas des boutons activés, je prends le relais et je m’interroge cette fois sur le survol des liens.

La convention veut que les liens soient identifiés par le soulignement de ceux-ci et je reste donc dans ce cas classique. Bien souvent ensuite (dans le but de signaler l’interaction) ce soulignement sera retiré au survol.

<style type="text/css">
    a:focus,
    a:hover
    {
        text-decoration:none;
    }
    a:active
    {
        outline:none;
    }
</style>

Remarquez au passage :

• que je complète mon sélecteur pour le cas d’une navigation au clavier (j’y reviendrai plus tard) ;
• la définition de l’état actif, trouvée via ce très bon billet sur la suppression de l’outline.

Je ne sais pas pour vous, mais j’ai tendance à trouver cette technique (pourtant répandue !) contre-intuitive. C’est comme si le lien « disparaissait » au survol, et que du coup il n’était plus possible (en apparence) de cliquer.

J’aurais tendance à préférer tout autre mise en forme au survol. Comme par exemple un changement de couleur. On pourrait même reprendre celle des liens visités tiens…

<style type="text/css">
    a
    {
        color:#1C6280;
        background-color:inherit;
    }
    a:hover,
    a:focus,
    a:visited
    {
        color:#1C6280;
        background-color:inherit;
    }
    a:active
    {
        outline:none;
    }
</style>

J’aimerais lire vos avis et vos arguments, je n’arrive pas à trancher cette question.

Question bonus : les sélecteurs enrichis pour les navigations au clavier, ça ne pose pas de souci ? Je pense notamment à une personne qui d’une part survol un lien à la souris, tant en tabulant sur un autre lien en parallèle : il se retrouve alors avec deux liens mis en évidence à la fois.

Petite astuce de rien du tout pour créer une bordure d’un ou plusieurs pixels entre deux colonnes.

C’est difficile à faire ?

Pas vraiment, mais ça se complique quand on souhaite que cette bordure soit toujours de la hauteur de la colonne le plus grande. Faut-il la placer sur le conteneur de gauche ou de droite ?

Solutions

On peut dans un premier temps penser à utiliser la techniques des colonnes factices et placer un background-image sous les colonnes, mais cela présente deux petits soucis :

• la largeur des colonnes sera alors fixée ;
• on fait appel à une image alors qu’un simple style CSS pourrait suffire.

Voici la méthode que j’utilise à la place :

<div style="overflow:hidden;height:1%;">
    <div style="float:left;width:200px;border-right:5px solid #000;">
        <p>
            Colonne A.
        </p>
    </div>
    <div style="float:left;width:200px;border-left:5px solid #000;margin-left:-5px;display:inline;">
        <p>
            Colonne B.
        </p>
    </div>
</div>

L’astuce consiste donc à placer deux bordures et à les faire se superposer ensuite via une marge négative de la largeur de la bordure. Simple, mais efficace.

Stéphane Deschamps me pique la plume. Le sujet se prête mieux au format de ce blog qu’au sien.

Un peu d’histoire

L’idée d’ARIA c’est de permettre de décrire des rôles et des états, pour améliorer l’accessibilité des clients riches. Ainsi on peut légalement avec ARIA faire une case à cocher en image, pourvu qu’on la décrive comme une case à cocher (role="checkbox") et qu’on indique son état, cochée (aria-checked). C’est pratique pour faire des graphismes modernes, tout en permettant de ne pas sacrifier l’accessibilité au seul profit de ceux qui ont des yeux et une souris, pour résumer.

Quand ARIA a été introduit, on ne parlait pas encore de HTML 5 au W3C : c’est XHTML qui prévalait. Or en XHTML une notion fondamentale est celle des espaces de nommage, permettant de rattacher au document courant (dont l’espace de nommage HTML est implicite) des extensions. ARIA bénéficiait donc d’une déclaration dans le document pour permettre à chacun de ses attributs d’être déclaré avec le préfixe aria:. Par exemple le rôle d’un élément s’écrivait aria:checkbox. Facile.

Avec l’avènement de HTML 5 et ses choix différents en termes de formalisme, qui privilégient l’écriture de code avec la syntaxe HTML, ARIA a dû faire machine arrière : tout a été renommé sans espace de nommage. Les deux points des propriétés spécifiques à ARIA ont été remplacés par des tirets : aria:checked devient aria-checked. Certains attributs quant à eux, qui ont du sens même hors du contexte d’ARIA, n’ont carrément pas de préfixe. C’est le cas de role, qui était prévu dans la spécification XHTML 2.

Pour l’accessibilité dans le monde réel, c’est presque une bonne chose : à ce jour, la revue d’écran la plus utilisée (Jaws) ne reconnaît pas les attributs préfixés. J’en ai fait la douloureuse expérience lorsque mon site est passé en XHTML : Jaws ne comprenait pas les attributs xml:lang et les ignorait purement et simplement ! (Il a fallu doubler tous ces attributs avec l’attribut HTML classique lang).

Oui mais voilà : et la validation dans tout ça ?

À ce jour, le validateur du W3C s’appuie sur le DOCTYPE que vous déclarez dans votre code pour vérifier que vous respectez bien sa grammaire. Or dans une spécification ancienne (XHTML 1.1 date de 2001), il n’était évidemment pas prévu d’intégrer des attributs dont on ignorait qu’ils existeraient un jour ! Sans compter que la logique même d’extensibilité du XHTML venait de l’idée qu’on intégrerait tout ça avec des espaces de nommage, donc l’extension était prévue, mais avec un formalisme que le brouillon courant de HTML 5 remet en cause. Bref, nous voilà au pied du mur : faut-il faire du code invalide, ou respecter maniaquement la spécification et trouver des contournements « légaux » ?

Une solution : opter pour du code invalide

La solution simple serait d’opter pour du code invalide. Eric Meyer considère qu’on peut prôner les standards en étant fidèle à l’esprit mais pas toujours à la lettre : c’est ce qu’il appelle standards-oriented.

En l’occurrence, imaginons que j’aie écrit une page conforme et que j’y rajoute des attributs ARIA. Elle devient non-valide, mais j’ignore les erreurs en connaissance de cause parce que je suis un développeur Web avisé, et que je sais que ça ne posera pas de souci aux navigateurs tout en améliorant l’accessibilité pour tous.

Utiliser un attribut HTML existant et manipuler ses valeurs avec JavaScript

La deuxième solution est plus sportive : je crée du code valide, et je profite de JavaScript pour ajouter les attributs qui me manquent.

Cas classique : je repère l’élément via son id (identifiant unique dans la page), et j’ajoute le ou les attributs dont j’ai besoin pour faire de l’ARIA.

Oui mais : tous mes éléments ne sont pas forcément nommés, pourtant je risque d’avoir besoin de nombreux endroits auxquels me raccrocher pour ajouter des propriétés ARIA.

Le plus simple sera alors d’utiliser un attribut HTML, d’en extraire le contenu et de générer les attribut ARIA à partir de là.

Quel attribut choisir ?

J’ai déjà vu des gens utiliser l’attribut rel des liens, par exemple pour faire des popins (rel="popin,450,300" indique qu’à ce lien sera ajouté un comportement JavaScript d’affichage de la popin, et les dimensions de ladite popin). Pour ma part j’en suis très gêné, il me semble qu’il s’agit là d’un détournement assez osé de l’attribut. Par ailleurs, ça ne fonctionne que sur des liens ; il faut donc trouver un attribut plus générique.

En revanche, la bonne idée depuis plusieurs années, c’est tout de même qu’on tente de ne pas mettre de comportement dans le code. On s’appuie sur le DOM pour inventorier les éléments auxquels affecter tel ou tel comportement, souvent en passant par l’attribut class. Pour revenir à notre exemple de popins, il y a quelques années on aurait fait la même chose en popup, en s’appuyant sur la classe : class="popup".

Essayons donc de nous appuyer sur la classe : il nous semble moins nocif d’utiliser cet attribut plutôt qu’un autre.

Quelle méthode ?

Maintenant que nous avons choisi la classe, quelle convention d’écriture adopter pour tous ces attributs ?

Première proposition, utiliser une notation héritée de JSON : class="{role:contentinfo;}". Son intérêt c’est qu’elle est facile à interpréter, et qu’elle sera extensible si nous devons ajouter plusieurs attributs : class="{role:checkbox;aria-checked:true;}". Son gros défaut c’est qu’elle a l’apparence d’une verrue dans le code, sans compter que cette notation ressemble suffisamment à la notation classique des paires propriété / valeur de CSS pour au mieux prêter à confusion chez le développeur moins au fait que vous, au pire faire tousser un navigateur dont le parseur de code y reconnaîtrait de la CSS (scénario catastrophe, me direz-vous ; oui mais on a déjà vu pire dans certains navigateurs).

Deuxième proposition : utiliser une notation à base de tirets, class="role-contentinfo", et manipuler la chaîne en l’explosant pour générer l’attribut et sa valeur.

Deux situations à différencier

Attention cependant, ARIA propose une approche deux-en-un :

1. description d’éléments de structure de la page à travers le rôle (les landmarks) ;

2. description d’éléments interactifs (typiquement les éléments de formulaire).

Selon moi ces deux cas peuvent impliquer une approche différente : le premier cas doit tant qu’à faire fonctionner même sans JavaScript, le deuxième n’a souvent de sens que si JavaScript fonctionne (puisque le changement dynamique d’état ne peut se faire qu’avec JavaScript).

Conclusion

Je serais enclin à faire du code invalide, en particulier dans le cas des landmarks, mais plus partagé sur les propriétés dynamiques (rôles et états des éléments interactifs).

À votre avis ? Faut-il du code invalide, et si oui, quelle méthode choisiriez-vous ?

Je découvre tout à fait par hasard ce billet de Nicole qui expose une solution très intéressante pour faire des colonnages.

L’astuce consiste à placer la propriété overflow sur le contenu, pour que celui-ci puisse s’adapter en fonction de son contexte : il n’est alors plus besoin de lui préciser une largeur. On peut alors, modifier la largeur de la colonne, en ajouter, en supprimer : le contenu s’adaptera toujours.

Elle utilise d’ailleurs cette technique sur son projet Object-Oriented CSS.

Seules précautions à prendre pour IE 6 :

• appliquer un hasLayout (via un zoom:1 ou un height:1% au contenu ;
• ne pas oublier de corriger le « Three Pixel Text Jog » (via un margin-left:-3px ou margin-right:-3px;).

Seuls inconvénients trouvés :

• l’impossibilité de « faire sortir » un élément en dehors du cadre contenu, celui-ci ayant un overflow ;
• l’ordre du contenu qui se trouve inversé par rapport à l’affichage lorsqu’on utilise une colonne placée à droite.

Mon petit fichier de tests est ici si vous le souhaitez.