Est-ce qu’on pourrait pas garder malgré tout les emojis (en supposant que du vrai texte y soit accolé) sans que les lecteurs ne les prennent en compte ?
Soit avec ARIA (que je connais pas plus que ça en vrai) ou bien en gérant en CSS à coup de …:before { content: '[EMOJI]'; } appliquée à des span par exemple ?
Si, bien sûr qu’on peut faire ça. La technique classique se résume à ceci:
<span class="sr_only">Texte réservé aux lecteurs d'écran invisible à l'écran</span>
<span aria-hidden="true">Texte visible à l'écran mais ignoré par les lecteurs d'écran</span>
Où .sr_only est une classe CSS présente dans plusieurs frameworks, parfois aussi appelée visually-hidden, screen-reader, ou des noms approchant.
De mémoire le code CSS correspond plus ou moins à:
.sr_only {
position: absolute !important;
border: 0 !important;
height: 1px !important;
padding: 0 !important;
overflow: hidden !important;
clip: rect(0, 0, 0, 0) !important;
left: -2px !important;
top: auto !important;
}
Ne garder que des emojis (ou des images au sens où l’entend HTML) peut s’avérer abscons, et ce pour tout le monde j’ai l’impression. À moins d’être devin
nul ne peut deviner du premier coup la signification d’un menu un peu complexe de façon purement graphique. Il me semble que Google l’avait appris à ses dépens sur je ne sais plus quel produit (était-ce GMail ?).
Ah, c’est bon à savoir ça. Il ne faudrait donc pas négliger le texte, et pas uniquement pour les lecteurs d’écran.
Je me demande du coup comment ils font pour aligner 5 ou 6 boutons / éléments de menu / onglets horizontalement sur mobile sans que ce soit complètement illisible.
Par ailleurs je viens de découvrir que la place disponible en pixels était plus grande sur mon iPhone que sur PC, et pourtant c’est la même taille de police qui est utilisée par défaut.
Mon petit test révèle que sans rien préciser nulle part, dans les deux cas 1em = 16px. Sur PC, la fenêtre de Chrome s’est dimensionnée d’elle-même à quelque chose comme 1025x800, contre 960x1600 sur iPhone. Un petit calcul rapide m’indique donc que je pourrais théoriquement afficher 100 lignes de 60 caractères. Ca me parait assez inconcevable.
Désolé d’avoir un peu dérivé, mais tout ça pour dire que comme quoi, ces emojis sont bien moins universels qu’on ne le pense
C’est pas grave, moi aussi je dérive, comme tu peux le constater. Ces explications et exemples restent bien utiles. Merci.
Je ne connais pas d’usage d’UTF-16. Pour les boîtes de dialogue, le menus, les messages, Windows 95 utilise en interne un codage sur 16bits mais ce n’est pas de l’UTF-16, car rien n’est prévu pour les points de code à partir de 216.
Ca ne doit plus être tout à fait vrai sous windows 10 et 11. En interne, c’est toujours un codage sur 16 bits qui est utilisé, mais il y a forcément quelque chose de prévu, car on peut très facilement taper des émojis. Il y a un raccourci Windows+point qui ouvre une boîte de sélection.
Je ne sais pas s’ils s’affichent toujours correctement, mais en tout cas même dans notepad, ils s’ajoutent et s’enregistrent bien.
D’ailleurs, depuis quelques versions de Windows 10 et sous Windows 11, l’encodage par défaut de notepad est UTF-8 ! (et plus ANSI alias CP1252).
A mon sens, pour du contenu web, il faut utiliser UTF-8. J’ai cru comprendre que certains langages utilisaient UTF-32 en interne : Python et Java par exemple.
C’est sans doute utilisé aussi dans gestionnaires de bases de données.
UTF-16 (ou en tout cas un codage sur 16 bits très proche) est utilisé pour les chaînes de caractère dans certains langages, comme Java ou JavaScript.
Si le langage connaît la notation \uXXXX, mais pas \UXXXXXXXX, alors à mon avis il y a de fortes chances pour qu’il travaille en interne sur des caractères sur 16 bits.
C’est le cas de Java et surtout de JavaScript, et donc par extension en JSON.
Sauf erreur, Python est un peu plus malin, et choisit UTF-8, UTF-16 ou UTF-32 au cas par cas en essayant d’être économe.
En base de donnée ils font des trucs plus bizarres, sans doute pour palier aux potentielles lenteurs qu’implique les recherches dans les chaînes encodées avec des encodages à longueur variable. Par exemple, avec MariaDB/MySQL, on peut choisir entre deux familles: utf8 et utf8mb4.
Le second peut enregistrer n’importe quelle chaîne en UTF-8 mais pas le premier, qui est limité aux caractères stockables sur 3 octets. N’utilisant que rarement les émojis moi-même, j’ai d’ailleurs mis du temps à piger pourquoi certains posts provoquaient des erreurs.
Je n’ai pas tout compris, mais ce n’est pas grave.
Java travaille nativement en UTF-16. L’encodeur ne traite pas les paires surrogate spécialement comme il devrait, ce qui fait qu’au lieu d’encoder une paire correctement en un seul caractère UTF-8 sur 4 octets, il encode comme deux caractères ordinaires.
Or les caractères U+D800 à U+DFFF sont explicitement interdits en UTF-8 pour éviter toute confusion.
Le problème est résolu automatiquement si on demande à l’encodeur d’échapper tous les caractères hors ASCII imprimable (U+0020 à U+007E) et non pas uniquement ceux qu’on est strictement obligé d’'échapper, car on encodera alors la paire via deux \uXXXX.
C’est en fait la seule façon d’échapper un caractère >=U+10000, car JSON ne connaît pas de notation \UXXXXXXXX.
Je comprends pleinement ton problème. As-tu essayé les short codes des caractères unicode ? Ou le “CLDR Short Name” ? Pour trouver un emoji, personnellement,
je me base sur les codes courts de gemoji, mais il en existe d’autres !
Ah non, je ne connais pas du tout, et ça m’a l’air intéressant comme classement. Je vais télécharger leur liste et voir ce que je peux faire avec.
Merci !
U+1F600 GRINNING FACE 
» (