以前は、モバイルのサイズ変更の効果を達成するために、問題なく機能するwidth=device-width, initial-scale=1
を使用したことがありました。
最近、メタビューポートのオプションとしてuser-scalable=no
を発見しました。最初はmaximum-width=1, minimum-width=1
を設定するためのショートカットだと思っていましたが、-私の意見では、 1つの大きな利点 が付いています:
これにより、[Webブラウザー]は、ブラウザーが待機し、シングルタッチがダブルタッチになるかどうかを確認するために必要なタッチイベントの300msの遅延を取り除くことができます。
素晴らしいと思いました。私や一部の同僚の電話でのいくつかの基本的なテストでは、300msの遅延が実際に解消されているように見え、より高速な操作感が得られます。
user-scalable
に読み込むと、いくつかの警報ベルが鳴ります。一般的なコンセンサスは、それがmaximum/minimum-width
とともにアクセシビリティにとって「有害」であるということです。書かれた記事または投稿からの抜粋今年:
"initial-scale = 1はかなり便利ですが、maximum-scaleはアクセシビリティにとって悪いニュースです。"
"ほとんどの場合、これらの有害な宣言はまったく必要ありません:maximum-scale=1, user-scalable=no
"
私が興味を持っているのは、これらの参照が両方ともそれぞれ2歳と3歳で書かれた記事へのリンクであり、それぞれの議論です:
http://a11yproject.com/posts/never-use-maximum-scale/
Maximum-scale = 1.0を設定することで、モバイルデバイスでピンチズームを使用する機能を無効にし、ユーザーに特定の方法でページを表示するように強制します。
http://blog.javierusobiaga.com/stop-using-the-viewport-tag-until-you-know-ho
[...]しかし、ユーザーがズームする必要がある場合が多くあります。小さなボディフォント(少なくともユーザーのニーズに対して)、写真の詳細の確認など
そして
このパラメータは、ズームインまたはズームアウトする機能を削除し、最大スケールよりもさらに悪いものになります。それを使用する本当に特別な理由がある場合(たとえば、Webアプリをコーディングしていて、フォーム入力のズームインを回避する必要がある場合)
提起された懸念のいくつかは理解していますが、議論のいくつかは、問題ではない、または問題であってはならないことに関するものなのでしょうか。
たとえば、入力フィールドを拡大する機能が削除されたとすると、ユーザーがモバイル向けに最適化されたサイトでフォームフィールドを拡大する必要がある場合、ユーザーに最初にズームインします。
私が受け入れることができるフォントサイズは問題ですが、回避策はフォントサイズコントロールを含めることです(それらをよく見るために使用され、おそらくそれほど多くはないでしょう)。
そのことを念頭に置くと、user-scalable=no
(または最大/最小の幅)が思ったほどひどくはない可能性があり、アクセシビリティに関するいくつかの考え/計画があれば、安全に使用でき、利点から利益を得ることができます。それはもたらす?
公正な議論と小さな告白のために、私はおそらくタブレットのサイズよりも携帯電話のサイズについて多くのことを考えています。携帯電話では、十分にズームインされていることが多いようです(ほとんどの場合、幅が100%に設定されているだけです)。これは、許可するタブレットでも常に同じとは言えません。また、自分のアクセシビリティに影響を与えるものは何もないので、おそらく他の人が直面している問題のいくつかは初心者です。
「user-scalable = no」の使用を停止します。限目。過去6年間、私はiPhoneを片付け、デスクトップコンピューターに移動してWebサイト上の何かを調べる必要があった回数を数えることができませんでした。この特定のメタタグの。これは、最も役に立たないタグです。作成されていなかったらよかったのに。
しないでくださいページ全体が独自のズーム機能を備えたインタラクティブアプリでない限り、ユーザーがuser-scalable=no
またはmaximum-width=1, minimum-width=1
を使用してズームできないようにしますGoogleマップのように、デフォルトのピンチズームジェスチャーを無効にするメカニック(ただし、それでも、ズームのみを無効にすることを検討してくださいwithinウィジェットを含むiframe、外側のページヘッダー、フッター、またはナビゲーションはズーム可能なままにします)。
anyの利点はありません。応答時間やその他に触れることはありません。この質問では、このオプションはハッキングとして悪用され、タッチイベントがクリックをトリガーするまでの300ミリ秒の遅延を取り除き、ブラウザがダブルタップで昔ながらの応答のないワイドページにズームインするかどうかを確認していました。ただし、モバイル版のChrome、Firefox、IE/Edge、およびApple iOSを含む)のビューポートよりも幅が広くないすべてのページで 2014年に主要ブラウザーがこれをドロップ 。
300〜350ミリ秒のタップ遅延を削除するには、ページの
<head>
に次のように入力するだけです。<meta name="viewport" content="width=device-width">
絶対に必要でない限り、ユーザーが通常行うことができることを妨げないでください。
ただし、もちろん、ユーザーがズームインしたい理由が1つも考えられなかったとしても、それを無効にすべきではありません。絶対に必要でない限り、ユーザーが通常実行できることを妨げないようにしてください。
私の両親は70歳代で、年齢に合わせて洗練されたユーザーです(ママはビデオゲームをプレイしています!)。
彼らは大型の携帯電話を持っています(母親はiPhone 6プラスを、父親はGalaxy Noteファブレットを持っています)。
それでも、サイトを拡大してテキストを読んだり、詳細を調べたりする必要があることがよくあります。
今、デザイナーとして私は選択肢に直面しています。
私のサイトでは超大型フォントを使用して、高齢者や視覚障害者を含むすべてのユーザーの人口統計を最大限にカバーすることができました。しかしそれは、サイトの美観を損なったり、少数のユーザーに満足してもらうために私ができる情報の量を厳しく制限したりすることを意味するかもしれません。
私は、挑戦された視力を無視して、大多数のケースまたは「パレート」ケースのために設計することができます。
あるいは、圧倒的多数の人々のために設計し、ズームを保持して(ピンチジェスチャーの遅延を犠牲にして)、視覚に障害がある人を助けることができます。
視力に問題のある少数派を無視するか、「最小公分母」の大きなフォントを使用するか、ズームのみを許可するかを選択できます。
非常に多くの場合、サイトは3番目のオプションを妥当なトレードオフとして選択しますが、私はあなたがあなた自身のサイトに最適な教育を受けた決定を行うために使用できる情報を提供しています。
「user-scalable = no」は使いすぎです。不快感から拷問まで、不快なユーザーエクスペリエンスを引き起こしています。それは、すべてのプログラマーからフィールドストリップを必要とする考え方の一部です。ソフトウェアは最もよく知っています。
人間は驚くべき、驚くべき生き物であり、どんなAIよりもはるかに高度で高速なオーディオおよびビデオのリアルタイムパターン認識機能を備え、創造性と感覚があり、コンピュータープログラムでは考えられない方法で環境を認識しますが、どういうわけか、あなたはユーザーがズームインまたはズームアウトする必要がある場合、またはスクロールやスクロールバーを無効にする必要がある場合、プログラムがユーザーよりもよく知っていると考えます。あなたはそこにいません。人間は他のものよりも自分自身に1つのものを引き付けます:例外。この宇宙には毎秒何兆もの可能性があり、あなたのソフトウェアがそれらすべてを説明したと思いますか?シャットダウンを遅らせたいのですが、建物が燃えていることを知りませんか?メールアドレスを拒否したいのは、サブドメインについて知らなかったため、メールアドレスのパターンの理解と一致していないためですか?ウィンドウまたは画面をサイズ変更不可またはズーム不可にしたいですか?はっきりさせておきましょう:あなたはユーザーを拷問しています-ノックオフしてください!ソフトウェアはユーザーにサービスを提供するために存在し、その逆ではありません。
user-scalable=no
の使用に対して非常に強い意見がありますが、サイトは実際にはズームせずに使用できるように設計されている可能性がある特定のユースケースを見落としており、ズームはエクスペリエンスに有害です。それを覚えておきましょう。人々が機能を乱用したり誤って使用したからといって、機能自体が悪いことを意味するわけではありません。