[Résolu] Format de date accessible

Bonjour !

J'étudie actuellement les bonnes pratiques du web et j'ai lu que les dates (d'actualités ou d'événements) ne devaient pas figurer au format JJ/MM/AAAA sous peine d'être mal comprises.

Malgré tout, il se trouve que les contraintes m'obligent assez souvent à afficher les dates dans ce format. J'aimerais donc savoir s'il est correct d'indiquer la date au format complet dans un attribut title, comme ci-dessous, ou s'il existe un attribut aria ou une méthode plus efficace ?

<div class="date">
    <span title="28 avril 2017">28/04/2017</span>
</div>

Est-ce que cette méthode est plus correcte (bien qu'un peu lourde) ?

<div class="date">
    <span aria-hidden="true">28/04/2017</span>
    <span class="visuallyhidden">28 avril 2017</span>
</div>

D'avance merci pour vos lumières
Modifié par Saoryx (04 May 2017 - 09:56)

Bonjour.

Pour ma part, je ne sais guère plus sur le sujet que ce qu'il y a dans ce tutoriel :
https://www.alsacreations.com/article/lire/1386-html5-element-time.html

Bonjour Zelena,

Merci pour ta réponse, j'ignorais que la balise <time> pouvait servir à tant de choses 

Néanmoins ma question porte plutôt sur la lisibilité d'une date par un humain, qu'il s'agisse d'un simple confort pour une personne parfaitement apte (ce pourquoi je pense recourir au title), ou d'une meilleure lisibilité pour une personne handicapée (ce pourquoi je pense utiliser la combinaison aria-hidden/visuallyhidden)

Mes excuses si la question n'était pas claire

Bonjour,

Comme l'indique Zelena, en utilisant une balise time vous faites d'une pierre deux coups.

Ainsi avec

<time datetime="2017-04-28">28 avril 2017</time>

L'utilisateur lambda lira la date comme il en a l'habitude (28 avril 2017),
l'utilisateur "handicapé" comme vous dites utilise de toute façon un assistant qui s'occupe de lui transcrire le contenu de l'attribut datetime dans son format favori. Par ex via un assistant audio, un anglophone entendra de la voix douce et délicate qu'il aura choisit "twenty eigth of april twenty seventeen" alors qu'un francophone entendra tout simplement "vingt huit avril deux mille dix sept".

Après il faut bien se dire qu'un "handicapé" n'est pas forcément ignare et sait reconnaître une date quand il en voit une, même à travers une loupe. 28/04/17, 28-04-2017, 28 avril 2017 [...] tout ça c'est kiff-kiff bourricot.

Saoryx a écrit :
j'ai lu que les dates (d'actualités ou d'événements) ne devaient pas figurer au format JJ/MM/AAAA sous peine d'être mal comprises

Peut-on savoir où vous avez lus ceci afin de déterminer le contexte ?

Bonjour Greg_Lumière,

Merci pour votre réponse

Greg_Lumiere a écrit :
Comme l'indique Zelena, en utilisant une balise time vous faites d'une pierre deux coups.

Ainsi avec

<time datetime="2017-04-28">28 avril 2017</time>

L'utilisateur lambda lira la date comme il en a l'habitude (28 avril 2017),
l'utilisateur "handicapé" comme vous dites utilise de toute façon un assistant qui s'occupe de lui transcrire le contenu de l'attribut datetime dans son format favori. Par ex via un assistant audio, un anglophone entendra de la voix douce et délicate qu'il aura choisit "twenty eigth of april twenty seventeen" alors qu'un francophone entendra tout simplement "vingt huit avril deux mille dix sept".

Après il faut bien se dire qu'un "handicapé" n'est pas forcément ignare et sait reconnaître une date quand il en voit une, même à travers une loupe. 28/04/17, 28-04-2017, 28 avril 2017 [...] tout ça c'est kiff-kiff bourricot.

Tout à fait, et je préférerais en effet que l'outil d'assistance lise "vingt huit avril deux mille dix sept" plutôt que "vingt-huit (zéro ?) quatre deux-mille-dix-sept" ! Même si j'imagine bien qu'une personne handicapée saura qu'il s'agit d'une date, pour le confort je trouve plus pratique d'avoir une date complète (je sais, c'est un caprice ).

Greg_Lumiere a écrit :
Peut-on savoir où vous avez lus ceci afin de déterminer le contexte ?

Bien sûr, il s'agit de la bonne pratique N°15 du référentiel Opquast : http://checklists.opquast.com/oqs-v3/criteria/les-dates-sont-presentees-dans-des-formats-explicites

<edit>
De fait, dans votre exemple vous affichez la date complète, mais dans mon cas, c'est bien cette contrainte d'utiliser le format jj/mm/aaaa qui m'embête. Puis-je toujours utiliser un attribut title pour le confort d'un utilisateur à la souris ? (Je conçois qu'aucune solution ne palliera le problème de naviguer au clavier sans outil d'assistance ou celui d'utiliser un support tactile...)
</edit>
Modifié par Saoryx (29 Apr 2017 - 12:14)

Saoryx a écrit :

De fait, dans votre exemple vous affichez la date complète, mais dans mon cas, c'est bien cette contrainte d'utiliser le format jj/mm/aaaa qui m'embête.

Pour quelle raison ? Si l'affichage sous ce format ne vous siée guère, vous pouvez très bien mettre

<time datetime="2017-04-28">Avr. 2017</time>

Et si le jour est indéfinissable, mettez le premier

<time datetime="2017-04-01">Avr. 2017</time>

ou encore vous pouvez vous affranchir complètement du jour, l'attribut datetime répondant au format ISO 8601 (2017-04 sera reconnu par les techno. d'assistance comme étant le mois et l'année).

Saoryx a écrit :
Puis-je toujours utiliser un attribut title pour le confort d'un utilisateur à la souris ?

J'ai du mal à saisir l'intérêt d'un tel doublon mais l'ajouter n'enfreint aucune "règle" et reste envisageable.
N'oubliez pas que l'utilisateur d'un appareil mobile ne dispose pas de souris.


En ce qui concerne la recommandation Opquast, je doute qu'elle prennent en considération l'utilisation de la balise time. Dans le doute, pourquoi ne pas leur demander avis ?
Vous pouvez aussi prendre avis sur Atalan.
Selon moi, la chose importante à retenir de cette recommandation est l'écriture du mois en lettre (abrégé ou non) et l'année sur quatre chiffre - en tant que contenu de la balise bien sûr, l'attribut datetime devant, lui, toujours être en chiffre avec le tiret comme séparateur.


Edit: Après relecture du sujet, j'ajoute que si vraiment vous n'avez pas le choix que de devoir afficher la date en chiffre avec le slash comme séparateur, et s'il s'agissait de moi, j'utiliserai cette balise mais n'ajouterais pas d'attribut title. Mais comme j'ai le choix et toute liberté sur mon template, je préfère utiliser ceci

<style>
.pub {
  font-size: .6rem;
  display: inline-block;/* pour appliquer la transformation */
  transform: scale(1);
}
.pub:hover {
  transform: scale(1.2);
}

</style>
<body>

<p class="pub">Publié le&nbsp;<time datetime="2017-05-02">2 mai 2017</time></p>

au lieu d'un attribut title
Modifié par Greg_Lumiere (02 May 2017 - 14:39)

Saoryx a écrit :

Bien sûr, il s'agit de la bonne pratique N°15 du référentiel Opquast : http://checklists.opquast.com/oqs-v3/criteria/les-dates-sont-presentees-dans-des-formats-explicites

Je ne peux pas m'en empêcher:

Opquast a écrit :
Crée le 23/06/2014 16h29

:)

a écrit :
En ce qui concerne la recommandation Opquast, je doute qu'elle prennent en considération l'utilisation de la balise time. Dans le doute, pourquoi ne pas leur demander avis ?

ça reste une assez bonne recommandation, pour tout le monde: ça évite les méprises avec les formats américains, c'est rapidement lisible sans se poser de questions, etc. Le mois en toutes lettres est plus lisible et devrait être favorisé si possible (excepté pour des questions de place, données tabulaires, etc.)
Modifié par kustolovic (02 May 2017 - 13:42)

Bonsoir,

Les lecteurs d'écran ne sont absolument pas conscients de la balise <time> et donc n'interprètent absolument pas leur contenu de manière spéciale. IL n'y a donc pas de transcription intelligible de l'attribut datetime.
Ces balises sont considérées comme de simples <span>.

A noter que certaines synthèses vocales sont capables d'interpréter les dates écrites dans des formats spécifiques et les rendre de manière intelligible. Malheureusement:
1 - Les formats reconnus ne sont pas forcément paramétrables par l'utilisateur, ni forcément en accord avec les paramètres lingustiques de la machine
2 - Ce qui est interprété ou non dépend de la synthèse vocale utilisée et sur quel système. Ca ne dépend pas uniquement du lecteur d'écran, mais aussi de la synthèse vocale. J'insiste: on peut conserver le même lecteur d'écran mais installer une voix différente de celle par défaut.

Par exemple pour mon cas: jaws 18, windows 10, synthèse vocale eloquence (eloquence est la synthèse vocale traditionnelle de jaws):
Je peux activer ou non l'interprétation des dates dans le centre des paramètres, mais je ne peux pas spécifier précisément quel format je veux qu'il interprète ou non.
03.05.2017 => trois mai deux mile dix-sept
03.05.49 => trois mai deux mile quarante neuf
03.05.50 => trois mai mille neuf cent cinquante
3.5.17 => trois mai deux mile dix-sept
03/05/2017 => zéro trois slash zéro cinq slash deux mille dix-sept (pas interprété)
2017-05-03 => deux mille dix-sept, zéro cinq, zéro trois (pas interprété)

J'ai beau changer la langue d'eloquence ou les paramètres régionaux de ma machine, ça ne change pas que seul le format suisse/allemand est réellement interprété (ce qui m'arrange vu que je suis suisse, mais je n'ai pas fait exprès; pour rappel jaws est américain, et le format américain n'est pas interprété)

Pour les heures c'est pareil:
12:34 => douze heures trente quatre
14:00 => quatorze heures
00:44 => zéro heure quarante quatre
12h34 => douze ache trente quatre

Il y a aussi des bugs qui existent depuis plus de 10 ans:
Ma version exacte de jaws en ce moment est la 18.0.2738, mais ce numéro de version est lu: dix-huit deux mille sept cent trente huit (le zéro a disparu)
et aussi celle-ci qui est bizarre: 18:15 => dix-huit heures et quart (quand dans le langage courant on dit bien "et quart" jusqu'à midi, mais "heure quinze" s'il est 13h ou plus)

On peut s'amuser encore un moment si on continue avec le format des nombres. Parce que là aussi, toutes les synthèses vocales n'apprécient pas toutes pareillement les séparateurs de milliers et la virgule décimale.
D'ailleurs j'ai paramétré mon windows avec le format françAis pour les nombres et non pas le format suisse, parce que le format suisse n'est pas lu correctement.
Exemple rapide:
1 234 = mille deux cent trente quatre
1'234 => un deux cent trente quatre
1.234 = mille deux cent trente quatre
12.34 => douze point trente quatre
1,234 = un virgule deux cent trente quatre
1-234 => mille deux cent trente quatre
1_234 => mille deux cent trente quatre
1.234.567 => un million deux cent trente quatre mille cinq cent soixante sept
1 234 567 => un million deux cent trente quatre mille cinq cent soixante sept
1 234,567 => mille deux cent trente quatre cinq cent soixante sept
1 234.567 => un deux cent trente quatre mille cinq cent soixante sept (!!!)

ET avec les monnaies:
€1.32 => un euro trente deux
1.32€ => un euro trente deux
$1.32 => dollar un point trente deux (pas interprété spécialement, alors que pour l'euro si)
€1.999999 => un euro (et pouf, les 9 ont disparu !)

ET on pourrait s'amuser à refaire des listes similaires pour toutes les synthèses vocales du marché. Bonne chance !

De quoi devenir dingue !

Si je comprends bien, les technologies d'assistance ont encore pas mal de chemin à faire.

Si je comprends bien, rien de mieux que "3 mai 2017". Mais dans le cas de Saoryx, si on souhaite afficher différemment la date de ce format, comment l'indiquer à l'assistant ? Aria ?

QuentinC a écrit :
Une solution pourrait être <abbr title=...>, mais malheureusement le title est loin d'être systématiquement lu; par défaut l'expansion des abréviations est désactivé, et peu sont ceux qui changent ce réglage...

Aaah vous m'avez vendu du rêve l'espace d'un instant...

QuentinC a écrit :
On peut jouer avec aria-hidden et les classes CSS du genre visually-hidden ou sr-only, mais je trouve que ce n'est pas politiquement correct sémantiquement parlant, et inutilement compliqué pour ce cas.

Je vois. Ce serait pourtant à mon sens la solution la plus efficace... (Châtiez-moi pour privilégier le confort à la conformité sémantique !)

QuentinC a écrit :
Le mieux est tout simplement d'arrêter de supposer à tort que les aveugles sont également sourds, incapables de marcher et mentalement retardés. Je vous confirme que les amalgammes du genre sont malheureusement encore très très courants dans la vraie vie.
Concrètement ce que je veux dire par là pour notre cas ici, c'est que même si on entend "zéro sept barre oblique zéro cinq barre oblique deux mille dix-sept", on est suffisament malin pour reconnaître une date. Personne ne s'est jamais plaint de ne pas comprendre; et on finit par s'y habituer quand on utilise un lecteur d'écran tous les jours.

Certes, loin de moi cette idée. Je suppose que mon unique solution pour rendre la lecture plus confortable à tout un chacun reste d'éduquer les concepteurs de projets et de cesser de râler dans mon coin.

Merci pour vos témoignages, Quentin.