Revisiter à l'échelle de l'utilisateur = non
Auparavant, pour obtenir l'effet de redimensionnement pour mobile, je n'ai utilisé que width=device-width, initial-scale=1 qui n'a pas fonctionné.
J'ai récemment découvert user-scalable=no en tant qu'option pour la fenêtre méta. Au début, je pensais que c'était un raccourci pour définir maximum-width=1, minimum-width=1, mais il vient avec, à mon avis, n énorme avantage :
Cela leur permet [au navigateur Web] de se débarrasser du délai redouté de 300 ms sur les événements tactiles que le navigateur met pour attendre et voir si votre simple toucher finira par être un double toucher.
Brillant, je pensais. Certains tests de base sur le mien et sur certains téléphones de collègues semblent en effet supprimer le délai de 300 ms et permettent une sensation beaucoup plus rapide.
Lecture dans user-scalable un peu plus sonne quelques sonnettes d'alarme. Le consensus général semble être que, avec maximum/minimum-width, est "nuisible" à l'accessibilité. Quelques extraits d'articles ou de messages écrits cette année :
Ce qui m'intéresse, c'est à la fois ces références à des articles écrits deux et trois ans respectivement, et les arguments de chacun:
http://a11yproject.com/posts/never-use-maximum-scale/
En définissant maximum-scale = 1.0, vous désactivez la fonctionnalité permettant d'utiliser le zoom pincé sur les appareils mobiles et forcez les utilisateurs à afficher votre page d'une certaine manière.
http://blog.javierusobiaga.com/stop-using-the-viewport-tag-until-you-know-ho
[...] mais il y a beaucoup de cas où l'utilisateur peut avoir besoin de zoomer: police de petit corps (au moins, pour les besoins de l'utilisateur), vérification de certains détails sur une photo, etc.
et
Ce paramètre supprime la possibilité de zoomer ou de dézoomer, et c'est encore pire que l'échelle maximale. S'il y a une raison vraiment spéciale de l'utiliser (par exemple, vous codez une application Web et devez éviter de zoomer sur les entrées du formulaire)
Bien que je comprenne certaines des préoccupations soulevées, je me demande si certains des arguments portent sur des choses qui ne sont pas ou ne devraient pas être des problèmes.
Par exemple, affirmant qu'il supprime la possibilité de zoomer sur les champs de saisie, on pourrait faire valoir que si un utilisateur doit zoomer sur les champs de formulaire sur un site optimisé pour mobile, il existe un problème entièrement différent qui devrait être résolu en n'exigeant pas que les utilisateurs zoom avant en premier lieu.
La taille de police que je peux accepter est un problème, bien qu'une solution de contournement puisse être d'inclure des contrôles de taille de police (utilisés pour les voir beaucoup, peut-être plus maintenant).
Dans cet esprit, il est possible que user-scalable=no (ou largeur max/min) n'est pas aussi horrible que cela puisse paraître, et avec une réflexion/planification en matière d'accessibilité, il pourrait être sûr d'utiliser et de bénéficier des avantages qu'il apporte?
Pour un argument juste et une petite confession, je pense probablement beaucoup plus aux tailles de téléphones mobiles qu'aux tailles de tablettes. Avec les téléphones portables, j'ai l'impression que les choses sont souvent suffisamment zoomées (la plupart des choses sont simplement réglées à 100% de largeur), il n'en va pas toujours de même pour les tablettes, je l'admets. De plus, je ne souffre de rien qui affecte mon accessibilité, donc je suis probablement naïf de certains des problèmes rencontrés par les autres.
Arrêtez d'utiliser "user-scalable = no". Période. Au cours des 6 dernières années, je ne peux pas compter les fois où j'ai dû ranger l'iPhone et aller sur un ordinateur de bureau pour examiner quelque chose sur un site Web, car il n'était tout simplement pas visible et il n'y avait aucun moyen d'augmenter sa taille car de cette méta-balise particulière. C'est de loin la balise la plus inutile. Je souhaite qu'il n'ait jamais été créé.
N'empêchez pas l'utilisateur de zoomer en utilisant user-scalable=no ou maximum-width=1, minimum-width=1, sauf si l'intégralité de votre page est une application interactive avec son propre mécanisme de zoom remplaçant les gestes de pincement par défaut, comme Google Maps (mais même dans ce cas, envisagez de désactiver le zoom uniquement dedans une iframe contenant le widget , en laissant tout en-tête, pied de page ou navigation externe zoomable).
Il n'y a plus tout avantage, pour toucher les temps de réponse ou quoi que ce soit d'autre. La question mentionne que cette option était utilisée comme un piratage pour supprimer le délai de 300 ms avant que les événements tactiles ne déclenchent des clics tandis que le navigateur attendait de voir s'il s'agissait d'un double appui pour zoomer sur une page large à l'ancienne non réactive. Cependant, les principaux navigateurs l'ont supprimé en 2014 sur toutes les pages qui ne sont pas plus larges que la fenêtre d'affichage, y compris les versions mobiles de Chrome, Firefox, IE/Edge et Apple iOS .
Pour supprimer le délai de prise 300-350 ms, tout ce dont vous avez besoin est le suivant dans le
<head>de votre page:<meta name="viewport" content="width=device-width">Vous ne devez jamais empêcher l'utilisateur de faire quelque chose qu'il peut normalement faire à moins que cela ne soit absolument nécessaire.
- Vous devez jamais empêcher l'utilisateur de faire quelque chose qu'il peut normalement faire à moins que cela ne soit absolument nécessaire. Cela vaut la peine de le répéter.
- Il existe de nombreux cas où empêcher le zoom peut causer des problèmes à vos utilisateurs:
- Il empêche les utilisateurs de zoomer sur un détail d'une image. Si vous ne disposez pas d'images que les utilisateurs pourraient vouloir zoomer en ce moment en dehors des widgets de diaporama maladroits, ne supposez pas qu'un site ne le fera pas à l'avenir
- Il empêche un utilisateur ayant une mauvaise vue de zoomer sur un texte qu'il a du mal à lire.
- Il empêche un utilisateur ayant des problèmes de coordination, de l'arthrite, des gros doigts, etc., de zoomer pour lui permettre de toucher plus facilement le lien, le bouton ou la bonne entrée.
- Même les personnes aux doigts fins et à la coordination parfaite veulent souvent zoomer en essayant de sélectionner du texte spécifique à copier ou à rechercher en utilisant le toucher.
- Cela empêche quelqu'un de zoomer, donc quelque chose de spécifique qu'il veut montrer à quelqu'un d'autre, faire référence ou écrire est grand, clair et centré sur l'écran. Par exemple, un numéro de téléphone, un code de référence, le nom d'une personne ou d'une chose ...
- C'est juste inutilement ennuyeux
Mais bien sûr, même si vous ne pouviez pas penser à une seule raison pour laquelle un utilisateur pourrait vouloir zoomer, vous encore ne devriez pas le désactiver, car , vous ne devez jamais empêcher l'utilisateur de faire quelque chose qu'il peut normalement faire à moins que cela ne soit absolument nécessaire.
Pourquoi le zoom peut être important
Mes parents ont 70 ans et sont des utilisateurs avertis pour leur âge (maman joue à des jeux vidéo!).
Ils ont de grands téléphones portables (maman a un iPhone 6 plus et papa a une phablette Galaxy Note).
Même alors, ils ont souvent besoin de zoomer sur des sites pour lire du texte ou examiner des détails.
Maintenant, en tant que designer, je suis confronté à un choix.
Je pourrais utiliser des polices ultra grandes sur mon site pour assurer une couverture maximale pour toutes les données démographiques des utilisateurs, y compris les personnes âgées et les malvoyants. Mais cela peut signifier nuire à l'esthétique du site ou limiter considérablement la quantité d'informations que je peux juste pour plaire à une petite minorité d'utilisateurs en difficulté.
Je pourrais simplement ignorer la vue contestée et juste la conception pour la majorité ou le cas "Pareto".
Ou je pourrais concevoir pour la grande majorité des gens et conserver le zoom (au prix d'un certain délai de pincement) pour aider la vue mise à l'épreuve.
Je peux choisir d'ignorer la minorité ayant une déficience visuelle, d'utiliser la police de grande taille "au plus petit dénominateur commun", ou tout simplement d'autoriser le zoom.
Très souvent, les sites choisissent la 3ème option comme un compromis raisonné, mais je ne fais que fournir des informations que vous pouvez utiliser pour prendre la meilleure décision pour votre propre site.
"user-scalable = no" est surutilisé. Cela provoque une expérience utilisateur désagréable, allant de l'inconfort à la torture. Cela fait partie d'un état d'esprit qui doit être dépouillé de tout programmeur: le logiciel est le meilleur.
Les humains sont des créatures merveilleuses et étonnantes, avec une capacité de reconnaissance de formes en temps réel audio et vidéo beaucoup plus sophistiquée et plus rapide que n'importe quelle IA, capable de créativité et de sensation, conscients de leur environnement d'une manière qu'aucun programme informatique ne pourrait être, mais d'une manière ou d'une autre, vous pensez que votre programme sait mieux que l'utilisateur si l'utilisateur doit effectuer un zoom avant ou arrière, ou si vous pensez que le défilement et/ou les barres de défilement doivent être désactivés. Tu n'es pas là. Les humains s'attirent plus qu'une autre chose: les exceptions. Il y a des milliards de possibilités chaque seconde dans cet univers, et vous pensez que votre logiciel les a toutes prises en compte? Vous souhaitez retarder la fermeture, mais vous ne savez pas que le bâtiment est en feu? Vous souhaitez rejeter une adresse e-mail, car vous ne connaissiez pas les sous-domaines et cela ne correspond pas à votre compréhension d'un modèle d'adresse e-mail? Vous souhaitez rendre une fenêtre ou un écran non redimensionnable ou non zoomable? Soyons clairs: vous torturez des utilisateurs - arrêtez! Le logiciel existe pour servir l'utilisateur, et non l'inverse.
Il existe de très fortes opinions contre l'utilisation de user-scalable=no, mais ceux-ci négligent des cas d'utilisation spécifiques où un site pourrait être conçu pour être utilisable sans avoir besoin de zoomer, et le zoom serait préjudiciable à l'expérience. Gardons cela à l'esprit. Ce n'est pas parce que les gens ont abusé d'une fonctionnalité ou l'ont mal utilisée que la fonctionnalité elle-même est mauvaise.