Zenn
🔭

<dialog>内でautofocus属性がほぼ必須になる話

2023/02/13に公開
1件
HTML
アクセシビリティ
idea

HTML Standardの更新でdialog要素に関する変更があったので、自分の理解の整理のためにもまとめてみます。

Scott O'Hara氏によるdialog initial focus, a proposalという提案の一部が反映された変更で、#8199でマージされました。主な変更差分を見るとわりと大きめの追記がされていることがわかります。

提案されていることがすべて採用されていたり、提案で言及されている問題がすべて解決しているわけではなく、議論が続いているものも多いので、今後dialog要素がどういった方向に変更され、進化していくのかを見守る補助的な記事になればいいなと思います。

autofocus属性ほぼ必須

結論から言うと、autofocus属性がほぼ必須となります。そのautofocus属性はdialog要素自体とは限らず、内包している子孫要素に適切な場合もあります。

<dialog autofocus>...ダイアログの内容...</dialog>

<dialog>
  ...ダイアログの内容...
  <input type="text" autofocus />
</dialog>

<dialog>
	<div autofocus>...長いテキスト...</div>
	<button>送信<button>
</dialog>

初期フォーカス位置の理解

順を追って説明すると、まずはdialog要素を開いた際のフォーカスの位置がどうなるのかを理解する必要があります。

今回の仕様変更で想定されるフォーカスのロジックは次のようになります。

  • <dialog>内のautofocus属性を持つシーケンシャルフォーカス可能な要素（<dialog>自身を含む）があれば、それにフォーカスする
  • <dialog>内にシーケンシャルフォーカス可能な要素がない場合、ダイアログ自体にフォーカスする
  • 少なくとも何かにフォーカスされるようになる

モードレスダイアログの場合

モードレスダイアログについては議論中で、まだ仕様としてマージはされていません。

蛇足: 提案のポイント
dialog.show({ preventInitialFocus: true });

上記のようにpreventInitialFocusオプションを渡して、フォーカスの移動を開発者が任意に止めることができることが提案のポイントになるようです。

追記されたautofocusについての言及

autofocus属性について以下のような言及が加筆されました。

An important part of user-facing dialog behavior is the placement of initial focus. The dialog focusing steps attempt to pick a good candidate for initial focus when a dialog is shown, but might not be a substitute for authors carefully thinking through the correct choice to match user expectations for a specific dialog. As such, authors should use the autofocus attribute on the descendant element of the dialog that the user is expected to immediately interact with after the dialog opens. If there is no such element, then authors should use the autofocus attribute on the dialog element itself.

以下、引用はDeepLによる翻訳と著者による意訳

ユーザーと接するダイアログの動作の重要な部分は、初期フォーカスの配置です。「ダイアログフォーカスステップ」は、ダイアログが表示されたときに初期フォーカスの最適な候補を選ぶことを試みますが、特定のダイアログに対するユーザーの期待に応えるために、作者が慎重に正しい選択を考えることの代わりにはならないかもしれません。そのため、作者はダイアログが開いた後、ユーザーがすぐに対話することが予想されるダイアログの子孫要素にautofocus属性を使用する必要があります。そのような要素がない場合、作者はdialog要素自体にautofocus属性を使用する必要があります。

作者（Authors）とは、開発者、マークアップをする人のことを指している言葉なので、

作者が慎重に正しい選択を考えることの代わりにはならないかもしれません

とはつまり、

「開発者のおまえがちゃんと考えろよ」

と受け止めることができますね。ブラウザの任せにせず、ユーザーの利便性を考えた上で期待するであろう位置でautofocus属性を使ってねということです。

今回の変更のプルリクエストである#8199の元となるIssue#7709では、

This would mean conformance checkers will warn authors if a dialog element doesn't have autofocus specified somewhere in the dialog.

といったように適合性チェッカー（HTMLバリデーターのこと）がチェックすることについても言及されています。

なので結論として「ほぼ必須」という表現を使わせてもらいました。

まだ各ブラウザでは実装されていない

更新されたautofocus属性の扱いと、初期フォーカス位置のロジックを踏まえた上で、Code Sandboxに簡単な実装をしてみました。

しかし、現状ではいろいろと未解決な部分が散見されます。

  • 仕様のサンプルコードはdialog要素やdiv要素にautofocus属性をつけているだけだけど、それだけでフォーカス可能要素になるのか？
    • 今後仕様として採用されるであろうスクロール可能要素がフォーカス可能になるのを見越している？
    • おそらくそうでないと、dialog要素でtabindexが禁止のままである説明がつかない
  • シーケンシャルフォーカスでない（非tabbable）要素でも初期フォーカスが当たってしまう

上記は、Chrome、Chrome Canary、Safari、Firefoxで確認しましたが、いずれも同様でした。

#8199を見る限り、Chromeは実装済み（？）、Webkitはこれから、Firefoxはマージ済みで実装されていそうですが、要件が複数ある今回の提案のどこからどこまで採用されているのか、更に調査が必要なようです。

その他の変更点

また、dialog要素の概要の部分もが変更・加筆されています。（以下引用はDeepLによる翻訳と著者の意訳）

変更前

dialog要素は、ユーザーがタスクを実行するために対話するアプリケーションの一部を表し、例えばダイアログボックス、インスペクタ、ウィンドウなどがあります。

変更後

dialog要素はアプリケーションの一時的な部分を表し、小さなウィンドウ（「ダイアログボックス」）の形で、ユーザーがタスクの実行や情報収集のために対話するものです。ユーザが作業を終えると、ダイアログはアプリケーションによって自動的に閉じられるか、またはユーザによって手動で閉じられます。

特にモーダルダイアログは、あらゆる種類のアプリケーションでおなじみのパターンなので、ウェブアプリケーションのダイアログが、ウェブ以外のアプリケーションのユーザーになじみのある方法で動作するよう、作者は努力する必要があります。

注意: 全てのHTML要素と同様に、他の種類のコントロールを表現するためにdialog要素を使用することは適しません。例えば、コンテキストメニュー、ツールチップ、ポップアップリストボックスはダイアログボックスではないので、これらのパターンを実装するためにダイアログ要素を乱用することは正しくありません。

ここで抑えておきたいのは、次の一文ではないでしょうか。

ウェブ以外のアプリケーションのユーザーになじみのある方法で動作するよう、作者は努力する必要があります。

一見そっくりでもウェブ独自の振る舞いのUIが氾濫していることを顧みての言及な気がします。

元の提案にもUse case analysisというセクションで、「おなじみのパターン」を列挙しているので参考になります。

まとめ

  • autofocus属性がほぼ必須
  • ブラウザに頼らず目的に沿った初期フォーカス位置を開発者が決めることが推奨される
  • ただしブラウザの実装はまだ
  • スクロール可能要素がシーケンシャルフォーカス可能（tabbable）要素となりそう

すべてのブラウザで動作するようになったdialog要素ですが、このようにまだ未解決で曖昧な定義があったり、機能面での不足があったり、発展途上ということがわかります。積極的に使うことも重要ですが、今後もどのように進化していくのか注目していきましょう。

脚注

  1. 詳しくはフォーカスの分類という記事を参考にしてください ↩︎

  2. whatwg/html Initial focus placement for dialog element: terminology for first-focusable vs first-tabbable #7710 ↩︎

  3. スクロール可能要素がフォーカス可能要素を内包していない場合、スクロール位置の変更をキーボードによって操作できない問題への解決策。 ↩︎

  4. w3c/html-aam Need to expose elements that are "scrollable" #358 ↩︎

GitHubで編集を提案

Discussion

MimikyuMimikyu

少々ニッチだが…これを待っていた！！Safariで必ず現れるフォーカス枠の病気が改善されるのかな