Taille minimum d'un design

salut
- mes grandes images sont en 3 tailles selon l'écran
- je modifie aussi la taille des marges, plus aéré pour les grands écrans
- je vérifie jusqu'a mini 320 x 560 v
- je met en display:none des éléments pas indispensable sur smartphone
- j'avais aussi parfois carrément bloqué tout l'affichage si vertical avec un picto invitant a tourner le smartphone en horizontal ou tout apparait
- j'aggrandi le font-size de 120% pour les grands écrans
- overflow-x:hidden sur tout parce que certaines images sont affichées plus grandes sur les smartphone

a+

Bonjour,

d´un point de vue accessibilité, il est demandé à ce qu´il n´y ait pas d´ascenseur horizontal avec une largeur de 320px (donc je teste en 320×480px), au niveau de la page.
Que l´on puisse consulter le site dans les 2 orientations (un device vissé à un fauteuil, ça ne se tourne pas aisément...). Test : dans Firefox en vue adaptative 320×480, il y a un bouton pour tourner de 90°

Une fois que c´est bon, comme mes interlocuteurs touchent un minimum en CSS, s´arranger pour que les titres et autres mots longs s´affichent dans le viewport (mieux vaut un mot coupé en 2 un peu nimp´ que coupé à droite et illisible !).

Niveau design, ça a intérêt à être parfait en 360, 375 et 414px de large : Android, iPhone...
Mon vieux smartphone en 360px de large (vieille version d´Android aussi) se fait passer pour 320px parce que j´ai agrandi la taille de texte d´un seul cran, enfin c´est ce que https://www.mydevice.io me dit. Ce doit pas être le seul je suppose...

Salut,

je "descend" jusqu'à l'iPhone 5-SE 320x568. C'est ok. En dessous, qui a un appareil, surtout connecté au net ?
Moins efficaces sur un petit écran, je supprime les fontes spéciales en mode mobile, pour alléger le chargement. Je le fais avec les @media pour isoler @font-face et le rendre opérant seulement sur grand écran.
Je ne fais rien que tu ne connaisses pas et je laisse flexbox ou grid se débrouiller avec les dimensions d'écran et toutes les valeurs en em, rem ou vw. Mais un @media landscape peut arranger des situations délicates.
Je dirai de nouveau que mis à part pour regarder des vidéos ou jouer, la majorité des personnes que je vois dans les Métros ou trains ne retourne pas son mobile. Alors, je ne vais pas m'acharner sur le mode paysage d'un iPhone 5-SE. Un mobile en mode paysage, c'est un faux desktop, ridicule.

Avis personnel pouvant être contredit.

Bonjour,

Si j'ai bien compris l'idée de Parsimonhi, l'idée est de savoir comment l'on gère en cas de dépassement quand-même.

Par exemple, toujours selon son idée, si l'on réduit une fenêtre à 500px de large tout en mettant le zoom à 500%.

Moi j'ai répondu ici.

Bonjour,

Merci à tous pour vos réponses. J'en retiens que dans le monde de 2024, tester jusqu'à une largeur de 320px semble faire consensus. Par contre, la taille de la police de caractères utilisée n'a pas l'air de vous préoccuper.

drphilgood a écrit :
overflow-x:hidden sur tout parce que certaines images sont affichées plus grandes sur les smartphone

Ça me parait risqué. Il faut être sacrément sûr qu'il n'y aura pas de dépassement quoi que configure l'utilisateur sur sa machine, sinon ce qui dépasse sera tout simplement inaccessible.

Felipe a écrit :
D´un point de vue accessibilité, il est demandé à ce qu´il n´y ait pas d´ascenseur horizontal avec une largeur de 320px (donc je teste en 320×480px), au niveau de la page.

J'imagine que ça vient de https://www.w3.org/WAI/WCAG21/Understanding/reflow.html ou d'un équivalent.

Excellente règle, mais il semble qu'il faille aussi tester le fait que l'utilisateur puisse changer la taille par défaut de la police de caractères (zoom texte seul sur firefox, ou changement de la taille de la police dans les paramètres du navigateur) jusqu'à 200%. Voir https://www.w3.org/WAI/WCAG21/Understanding/resize-text

Si on utilise beaucoup de rem ou em, il me semble que les contraintes seront (plus ou moins) les mêmes qu'en 160px de large avec une taille de police "normale".

Je n'ai jamais su trop me positionner par rapport à ça.

Felipe a écrit :
Mon vieux smartphone en 360px de large (vieille version d´Android aussi) se fait passer pour 320px parce que j´ai agrandi la taille de texte d´un seul cran, enfin c´est ce que https://www.mydevice.io me dit. Ce doit pas être le seul je suppose...

C'est en fait "un peu pareil partout" dès qu'on utilise le zoom (pas le zoom texte seul, mais le zoom qui grossit tous les éléments) sur n'importe quel navigateur. Si par exemple on essaie de récupérer la largeur des éléments via js, ça donnera la taille qu'on voit à l'écran divisée par le zoom. Plus généralement, le zoom change la taille physique du pixel "css", ce qui j'en conviens ne devrait pas être le cas quand on change la taille par défaut de la police , qui elle ne devrait changer que la valeur du rem, et alors que c'est ce qui semble se passer sur ta machine. À éclaircir !

Bongota a écrit :
Je "descend" jusqu'à l'iPhone 5-SE 320x568. C'est ok. En dessous, qui a un appareil, surtout connecté au net ?

Je suis d'accord avec toi sur le fait qu'en pratique, y en a plus beaucoup en 2024 qui ont des écrans de moins de 320px de large. Mais le problème, c'est si l'utilisateur a besoin d'utiliser une police par défaut plus grande que les 16px habituels (ou éventuellement une autre valeur selon la configuration par défaut sortie usine des outils qu'on utilise). Si tu testes ton design pour que rien ne dépasse en 320px de large et que tu as utilisé des rem ou des em comme unités de longueur, et si l'utilisateur passe sa police par défaut à ne serait-ce que 24px, et jusqu'à au moins 32px selon certains standards d'accessibilité (voir les liens plus haut dans cette page), bah, ça peut être panique à bord selon ce que tu as bricolé ici et là, non ?

Amicalement,

Bonjour,

Olivier C a écrit :
Si j'ai bien compris l'idée de Parsimonhi, l'idée est de savoir comment l'on gère en cas de dépassement quand-même.

Par exemple, toujours selon son idée, si l'on réduit une fenêtre à 500px de large tout en mettant le zoom à 500%.

J'espère que je ne t'ai pas trop traumatisé quand même !

Reste que grâce au présent post, Felipe m'a mis sur la piste des standards d'accessibilité concernant la largeur minimal à tester (voir les liens que j'ai trouvé dans ma réponse plus haut et que je n'avais pas pensé à chercher avant aujourd'hui, mea culpa). Je n'avais qu'une vague idée de ce qu'ils étaient. Et si on combine la règle des 320px avec la règle des caractères à 2 fois la taille normale, on arrive en pratique à devoir tester jusqu'à 10rem de large (10 * 16px * 2 = 320px).

500px à zoom de 500% avec 1rem valant 16px, c'est 100px ou 6.25rem ! Ça semble extravagant, mais en fait, on n'est pas si loin des 10rem que suggèrent les normes une fois qu'on a fait tous les calculs de conversion appropriés (à confirmer, je peux me tromper dans les calculs ou avoir mal compris les standards).

Amicalement,

Bonjour,

Olivier C a écrit :
Sur mobile, si l'on utilise les deux doigts pour agrandir, qu'un overflow soit hidden ou clip sur le document ça ne change rien au fait que l'on va pouvoir scroller la page dans tous les sens sans limitations.

Je ne sais pas (ou plutôt je ne sais plus) ce que c'est qu'un "mobile".

Mais quoi qu'il en soit, raison de plus pour ne pas mettre d'overflow hidden ou clip sur le document puisque "ça sert à rien" (ou presque à rien) !

Olivier C a écrit :
Du coup il reste le cas de l'ordinateur de bureau effectivement... Mais pourquoi quelqu'un irait mettre 500% d'agrandissement pour une page, tout en ramenant sa fenêtre à 500 pixels ?

Oui, c'est un test un peu trop contraignant je l'admets, mais pas tant que ça comme je l'ai expliqué dans ma réponse précédente.

A priori, maintenant que j'ai un peu avancé sur la question, le test à faire a bien l'air d'être fenêtre de 320px, taille de la police 2 fois la normale, et pas de scroll ou de doigts qui trainent sur l'écran pour bouger le contenu horizontalement. Donc si ça dépasse en largeur lors du test, bah, on est recalé. Que ce soit avec un écran tactile ou pas, et si on utilise les doigts, ou une souris, ou un trackpad, c'est pareil.

On peut cependant, si j'ai bien compris, avoir des éléments internes à la page avec un scroll horizontal (par exemple, une "map", voire un tableau).

Olivier C a écrit :
Il y a un choix technique à faire au départ qui influe sur l'expérience utilisateur. Pour moi, prendre comme point de départ une utilisation réaliste est un bon compromis.

Oui, il faut bien sûr être réaliste. Cependant on n'est plus dans un choix technique là (comme je le pensais encore hier), mais dans le respect (ou pas) d'une norme. .

Et quel serait techniquement ce choix ? On ne peut pas juste dire : "il faut que ça soit réaliste" car l'océan des possibles est trop vaste.

Et quelque soit la limite qu'on se fixe, il reste la question des contenus qui dépassent quand on est en dessous de cette limite (c'est surtout à ça que sert mon test de 500px zoomé à 500%, non pas à vérifier que le contenu tient dans cette largeur, mais plutôt que le design n'est pas cassé même à cette largeur). A priori, mieux vaut semble-t-il dans ce cas forcer le scroll horizontal avec une largeur suffisante pour ne pas trop couper les mots (on peut les couper "un peu" mais "pas trop" sinon c'est trop difficile à lire et au final cela nuit à l'accessibilité aussi), ne pas perdre une partie du contenu, et conserver un design en bon état, plutôt que réduire (ou laisser réduire sans le maitriser) la largeur du contenu à tout prix. Je ne retrouve plus où je l'ai lu aujourd'hui, mais ça semble être du bon sens de toute façon. Et techniquement, il me semble que c'est assez facile à réaliser : il suffit d'un min-width sur le body, sans avoir besoin de tenir compte du matériel des utilisateurs (et évidemment, pas d'overflow hidden ou clip).

Bref, en résumé, taille minimum de 10em (320px avec une police de 32px) de large et pas de scroll horizontal de l'ensemble du contenu au dessus de cette largeur, ça me parait pas mal et tenable.

Amicalement,

Du coup, tu peux faire comme Google et Amazon, mes trois exemples plus haut : pages web optimisées pour un affichage d'environ 1200px, pas de points de rupture (ou très peu). On agrémentera avec quelques éléments gérés de manière individuelle, par exemple avec des barres de scroll horizontales au niveau des composants (si si), typiquement une barre de navigation (ex : Google Drive). Comme ça pas de prise de tête pour la version desktop.

Par contre, bien sûr, détection incontournable du matériel + système d'exploitation (au revoir user agent) pour proposer une alternative très spécifique aux mobiles.

parsimonhi a écrit :
Je ne sais pas (ou plutôt je ne sais plus) ce que c'est qu'un "mobile".

Blague mise à part, c'est le type de terminal qu'utilisent 65-75% des utilisateurs d'un site web de nos jours. Pour la nouvelle génération tu peux monter le chiffre à plus de 95%. Juste ça.
Modifié par Olivier C (06 Mar 2024 - 09:52)

parsimonhi a écrit :
Ce qu'il faut faire, c'est fenêtre de 500px de large, zoom de 500% et taille par défaut de la police du navigateur à 72px. Là, on voit vraiment si un code marche ou pas !

Alors, je te concède un truc : je viens de m'apperçevoir, que dans une situation de ce type, mon menu en version mobile n'est plus accessible pour tous ses items car j'utilise `overflow: clip`, alors qu'il faudrait que je me contente de :

:where(html,body).active {
    overflow-x: clip;
}

Merci à toi, cher pointilliste