Mes impressions sur le web, les standards et autres…

L’autre visage de l’accessibilité

On parle beaucoup de l’accessibilité des pages en termes de code propre, aux normes et respectant les règles d’accessibilité telles que l’attribut alt sur les images, de vrais entêtes (balise th) pour les tableaux de données et bien d’autres choses encore. Mais on oublie souvent que la question de l’accessibilité se joue également à d’autres niveaux.

Définir une nomenclature pour ses URLs

On y pense pas souvent, ou pas avec l’importance qui lui est dû mais choisir des URLs représentatives est très important. (Note pour les puristes : Attention, je fais court et simple)

Tout d’abord, il faut dissocier clairement l’URL qu’utilise le visiteur du véritable chemin du document cible sur le serveur. Vous pensez vous trouver dans le dossier /journal/ de mon espace web ? raté, l’URL http://webnaute.net/Journal/ pointe sur http://webnaute.net/scripts/journal.php. Pour les archives (quand elles seront en place), l’URL http://webnaute.net/Journal/2003/10/ par exemple pointera sur http://webnaute.net/scripts/journal.php?​annee=2003&mois=10 (la première est tout de même plus belle et plus significative que la seconde vous ne trouvez pas ?). Les deux exemples précédents sont rendus possibles par quelques lignes simples dans mon fichier .htaccess : 

RewriteEngine on
RewriteRule ^Journal/([0-9]{4})/([0-9]{1,2})/?$ scripts/journal.php?annee=$1&mois=$2 [L]
RewriteRule ^Journal/?$ scripts/journal.php [L]

On peut donc de façon simple définir des URLs qui ont un sens pour le visiteur (après tout, qu’est ce qu’il en a à foutre qu’il y ait .html ou .php à la fin) en ayant par ailleurs toute latitude pour gérer et modifier le classement des fichiers et dossiers de son espace web sans que cela affecte le visiteur (vous savez, les erreurs 404 à la pelle lorsqu’on fait une recherche avec un moteur de recherche. cf les deux dernières parties de ce billet).

Apache fournit des outils très pratiques pour arriver à ce résultat, tels que la négociation de contenu et/ou la réécriture d’URLs grâce au module mod_rewrite (Voir aussi ce tutoriel très clair).
Lisez surtout l’article Les URLs sympas ne changent pas assez long mais très enrichissant, et qui expliquera bien mieux que moi et de façon beaucoup complète.

Compression des pages

C’est très simple à faire en PHP, voir ici, là ou encore sur cette page. Et c’est trèèès efficace. Vos pages seront beaucoup moins grosses et donc beaucoup plus rapides à charger pour les navigateurs qui gèrent les pages compressées (Pensez aux personnes, majoritaires, qui utilisent une connexion bas débit en France).
Et si le module mod_gzip (Apache) ou mod_deflate (Apache 2) est installé sur votre serveur, vous pouvez même envoyer la plupart des fichiers textes (feuilles de style, fichiers javascript, …) en compressé également. :)

Gestion de l’indexation

Vous est-il déja arrivé, en faisant une recherche via un moteur de recherche, et en suivant le lien d’un des résultats retournés, de tomber sur une page qui n’a plus grand chose à voir avec l’objet de votre recherche ? Moi, ça m’arrive souvent.
Ne permettez pas aux robots des moteur de recherche d’indexer n’importe quoi ! Les moteurs de recherche sont là pour indexer des documents (ou pages si vous préférez), pas des sites. La nuance n’est pas forcément évidente, et pourtant, elle existe. Prenons l’exemple d’un site portail. La page d’accueil affiche par exemple les derniers articles publiés, les derniers liens ajoutés dans l’annuaire ou que sais-je encore. Ce genre de page change au fil du temps (du genre, plus rien à voir d’un mois sur l’autre).
La règle d’or dans l’idéal est de ne permettre l’indexation que des documents qui ne changent pas ou pour lesquels il n’y a pas de suppression de contenu. Pour cela, vous pouvez utiliser le meta tag robots dans votre code HTML en indiquant les valeurs qui vont bien, ou placer un fichier robots.txt à la racine de votre site, comme l’explique cet article (Premier lien retourné après une rapide recherche sur Google).

Ne laissez pas tomber vos visiteurs

Le titre n’est pas très évocateur. Je m’explique.
Il n’y a rien de plus frustrant que de suivre un lien (résultat d’une recherche, lien qui traine au fin fond des marques-pages) et de tomber sur une page d’erreur 404 (à recouper avec les deux premières parties de ce billet). Le document a t-il été simplement supprimé ? déplacé ? Impossible de savoir, sauf à faire une recherche potentiellement longue et laborieuse sur le site en question. Le protocole HTTP (Voir entre autre la RFC 1945 sur le protocole HTTP 1.0 et la RFC 2616 sur le protocole HTTP 1.1) contient tout ce qui est nécessaire pour réaliser un dialogue clair et riche en informations avec le client (navigateur web ou autres…). Pour un document supprimé, l’idéal est de renvoyer l’entête HTTP/1.1 410 Gone ce qui signifie littéralement que l’url est correcte mais que le document n’existe plus. Pour un document déplacé, deux cas de figure :

  • Le déplacement est temporaire. On veillera dans ce cas à renvoyer l’entête 307 Temporary Redirect
  • Le déplacement est définitif. On renvoie l’entête 301 Moved Permanently

Pour envoyer les entêtes nécessaires au client, PHP dispose de la fonction header(). Vous pouvez aussi utiliser les directives Apache RedirectPermanent, RedirectTemp et RedirectMatch dans un fichier .htaccess.