Sémantique et accessibilité de la balise HTML time

Il existe plus de 100 balises HTML (essayez le HTML Tags Memory Test pour voir combien vous en connaissez). Chaque balise a ses spécificités et permet, dans la plupart des cas, d'attributer un sens au contenu qu'elle contient. C'est ce qu'on appelle la sémantique, obligatoire entre autres pour rendre un site accessible.

Quand on développe des sites, on a souvent dans le contenu des éléments temporels (date de publication d'une recette, durée de lecture d'un article de blog...). Il existe pour ce type de contenu la balise <time>.

Lien vers la sectionAnatomie de la balise <time>

La balise <time> attend un contenu temporel qui peut se présenter de 3 manières différentes :

• Une heure : "L'heure du goûter c'est 16h00".
• Une date : "On fête la nouvelle année le 1er janvier".
• Une durée : "Le Seigneur des anneaux : Le Retour du roi dure 4 heures et 22 heures et 36 minutes".

<p>
  Le Seigneur des anneaux : Le Retour du roi dure
  <time datetime="PT4H23M">4 heures et 23 minutes</time>
</p>

La balise <time> est une élément inline qui apparaît sans style par défaut dans la plupart des navigateurs.

Elle est d'ailleurs supportée partout sauf sur Internet Explorer. Mais le HTML étant un langage qui dégrade gracieusement, elle est rendue comme un texte générique lorsqu'elle n'est pas supportée.

Lien vers la sectionUn attribut, mais pour les machines

En plus des attributs globaux, l'élément <time> possède un attribut un peu particulier : datetime. Ce dernier est destiné aux machines qui vont l'interpréter plutôt qu'aux personnes. C'est à dire les navigateurs, les clients email, les lecteurs de flux RSS, les lecteurs d'écran...

Il attend par conséquent une valeur normée dont les formats sont détaillés sur MDN. Ces formats pour la balise <time> sont détaillés sur CSS-tricks.

La valeur de cet attribut peut aussi servir à parser plus facilement en JavaScript des valeurs de date. Entre "2021-09-18" et "18 septembre 2021", le premier est plus facilement manipulable.

Lien vers la sectionComment est-ce interprété par les lecteurs d'écran ?

C'était la plus grande question en écrivant cet article : est-ce que les lecteurs d'écran comprennent la balise <time> et est-ce qu'elle améliore l'expérience de navigation ?

Voici les résultats de vocalisations effectuées sur plusieurs combinaisons populaires de navigateurs et de lecteurs d'écran pour les contenus suivants (et le code d'exemple):

• Date : 8 septembre 2021 (avec et sans attribut datetime).
• Date : 08/09/2021 (avec et sans attribut datetime).
• Durée : 3 minutes (avec et sans attribut datetime).

Lien vers la sectionAvec l'attribut datetime

Lien vers la sectionSans l'attribut datetime

En résumé :

• Il n'existe a priori pas de rôle ARIA particulier pour ce type d'élément. Dans les 2 cas, il est perçu comme un texte standard.
• L'attribut datetime est seulement lu et interprété par la combinaison VoiceOver + Safari (pas la possibilité de tester sur iOS) mais cela provoque un doublon dans l'annonce.
• Certains lecteurs d'écran comprennent le format abrégé 08/09/2021 (ce n'est pas lié à la balise <time>) et le traduisent en toutes lettres sauf VoiceOver qui lit les séparateurs (/) littéralement.

Hormis un doublon qui peut apparaître lors de la vocalisation avec VoiceOver (mais qui peut être bénéfique si la date affichée est abrégée), l'attribut datetime permet a priori uniquement d'apporter du contexte en pour les agents utilisateurs (navigateur, client email...).

La balise <time> est-elle donc intéressante ? Oui, même si sa valeur sémantique n'est pas aussi marquée que sur d'autres éléments comme les listes ou les tableaux, elle peut apporter un léger bonus de navigation.