HTML5の "autofocus"属性をページに追加するのが適切なのはいつですか？

Question

使いやすさのために、検索ページの検索入力フォームのようなものに自動焦点を合わせると便利です。

ページの主な目的がコンテンツを検索または追加することである場合、それがあなたがやりたいことであると想定し、できるだけ早くそこに到達するのを助けることが適切である場合があります。

Drupal 8では、ここでこれに苦労しています： https://drupal.org/node/2096347

これは単なるDrupalの問題ではなく、確かに私たちが見ている問題です。

いくつかの素晴らしい説明があります：

残念ながら、HTML5のオートフォーカスを適切に使用するためのガイドラインはありません。

@Jaredが言うように、「ユーザーはフォームのあるページに移動することを知っていますか？フォームに入力する前に読む必要のある説明テキストが必要ですか？私はスクリーンリーダーのユーザーです。ランダムなフィールドにフォーカスを当てます。Googleの検索ボックスにフォーカスが移る理由は明らかです。気にしないでください。Stackoverflowで質問を表示するたびに回答の編集フィールドにフォーカスが自動的に置かれると、イライラします。スクリーンリーダーがフォームフィールドから離れてページの上部に移動するように強制する必要があります。」

しかし、それで十分ですか？

オートフォーカスの使いやすさとアクセシビリティを調べたいと思います。このページは、WCAG 2.0 AA要件を満たす必要があります。

Peter · Answer

私はこれをバックアップする直感しかありませんが、次のヒューリスティックが機能する可能性があります。

あなたのページに明確な注意点がありますか？ページが読み込まれるとすぐにユーザーが見ると確信できる領域はどれですか。その領域のメイン要素は、1つの入力要素または非常に明確なシーケンスのいずれかを備えたフォームですか？

答えがすべて「はい」の場合、フォームの最初の（できれば、唯一の）要素にオートフォーカスできます。そうでない場合は、最小の驚きの原則に違反するリスクがあります。ユーザーが記事を読むためにページにアクセスし、検索ボックスにオートフォーカスしたためにショートカットが機能しない場合、それはUXの失敗です。

問題のフォームは、他のすべてのユースケースがはるかに遅れているため、ページにアクセスする最も一般的な理由である必要があります。

フォームはlocusである必要があるがfocusではない必要があると言うことで、これを少し緩和できます。たとえば、Googleの結果ページでは、主な使用例は検索結果を確認することですが、検索ボックスはまだオートフォーカスされています（カーソルはありません）。入力しても検索ボックスが変化することにユーザーは気付くので、これは大きな問題にはなりません。検索ボックスが小さく、サイドバーにある場合、これが問題になる可能性があります。また、下にスクロールして入力すると、ページが上にスクロールして検索ボックスが表示され、ユーザーのアクションが影響を与えている場所がユーザーに表示されます。

したがって、Googleの結果ページは、オートフォーカスされた要素がページのメインのユースケースを提供しないエッジケースを提供しますが、重要なユースケースを提供し、オートフォーカスは驚きを最小限に抑えるために慎重に実装されます。

DA01 · Answer

アクセシビリティに留意してください。オートフォーカスはアクセシビリティの大きな障害になる可能性がありますが、特定の状況では非常に役立ちます。

これは、スクリーンリーダーを使用している人が現在のビジュアルのポイントに到達するために対処する必要のないものがページ上にたくさんある場合に役立ちます。これの典型的なシナリオはモーダルです。モーダルが表示されたら、そのモーダルにオートフォーカスしたいので、スクリーンリーダーはそのモーダルが現時点で主なフォーカスであることを認識します。

それ以外の場合は、1つのことだけを実行するように設計されたページの短いものは避け、人々はその1つのことだけを実行するようにしてください。 Googleの検索ページは、おそらく私が考えることができる唯一の公開例です。おそらく、クエリページを備えたカスタムエンタープライズデータツールなど、多くのプライベートな例があります。