最近の 2.8.0.beta2 へのアップデート以降、管理メニューへのボタンが黄色くハイライト表示されるようになりました。
Discourse が何かを伝えようとしているのかと思ったのですが、Web やこのフォーラムを検索しても、それが何なのか見当が付きません。
どなたか教えていただけないでしょうか？
キーボードのフォーカスがそのアイテムにあることを示しているのだと思います。これは最近の accessibility に関する変更です：
メニューを表示した後、\u003ckbd\u003eTab\u003c/kbd\u003e を押してメニュー内を移動してみてください。
「いいね！」 4
はい、その通りです。@simonk が指摘したように、私たちが誤っていた点の一つは、オーバーレイにフォーカスを移していなかったことです。アプリケーション内を移動する際、フォーカスは適切な場所に置かれている必要があります。
「いいね！」 4
うーん、ちょっとわからないな。そこはホバー状態が必要かな？@awesomerobot？
「いいね！」 1
CSSでは :focus から :focus-visible に切り替えることを検討したほうがよいかもしれません。Safari ではまだサポートされていませんが、その場合は :focus にフォールバックさせるのは簡単です。
仕様より：
アクティブな要素が :focus-visible に一致し、スクリプトによってフォーカスが他の場所へ移動した場合、新たにフォーカスされた要素も
:focus-visibleに一致する必要があります。
つまり、タブキーでハンバーガーメニューに移動して開くと（これにより :focus-visible スタイルが有効になります）、メニューが開いた時点で :focus-visible スタイルが表示されます。一方、ポインタでメニューを開いた場合は :focus-visible スタイルは表示されません。
ただし、1 つの欠点があります。ポインタでハンバーガーメニューを開いた後、タブキーでナビゲーションしようとする混合入力環境では、最初のリンクに :focus-visible スタイルが表示されません（技術的にはフォーカスされているにもかかわらず）。そのため、リンクがスキップされたように見えてしまいます。この問題に対する回避策があるかどうかはわかりません…
「いいね！」 5
私は（主に）マウスユーザーなので、そのように動作することを期待します。
一方、たまにタッチスクリーンのスマートフォンを使うこともあります。そこでも同じ問題が発生し、「Admin」が強調表示されます。これは、管理セクションで何らかの重要な対応が必要なものが含まれている可能性を示しています。
関連するスクリーンリーダーに関するトピックから、何らかの形でフォーカスを設定する必要があるようです。
上記のようなポインタでの動作だけであれば、私はすでに満足です。
「いいね！」 1
私も同じ問題が発生しています。
この要素には、現在、皆様がお考えのUX価値が備わっていないと思います。当社のフォーラムから、これに関するバグ報告が即座に寄せられました。ウィンドウ内の任意の場所を右クリックするとフォーカスが消失し、ボタンにカーソルを合わせると二重フォーカスが発生します。全体として、ユーザーにはバグがあるように見えます。特に、Discourse は他のビューではこの選択を強制していないためです。
キーボードの Tab キーを最初に押したとき、またはキーボード操作でハンバーガーメニューを開くために移動したときのみ、キーボードフォーカスを表示する方が良いでしょう。
「いいね！」 2
そのスクリーンショットを投稿してもらえますか？この件については把握していません。
「いいね！」 1
Safari と Firefox（macOS）でも同じ現象が見られます。これは上記の投稿でも言及されています：
この機能の仕組みを正しく理解している場合、メニューを開くにはクリックするか = キーを押す必要があります。その後、何らかの方法（矢印キーなど）で移動し、何か（Enter キーなど）を押してハイライトされた項目に移動できるはずです。
macOS の Safari と Firefox では、クリックまたは = キーでメニューを開いても、そのメニュー内を移動できません。上下の矢印キーはページ自体をスクロールさせ、左右の矢印キーは視覚的に何も起こりません。
Tab キーはフォーカスを別の要素（投稿の「いいね」ボタンなど）に移動させ、メニューの黄色いハイライトを消してしまいます。Firefox で Tab キーを押すと、この返信を書き始める前はメニュー項目を順に循環していたようですが、現在はそうなりません（その試みの間にプライベートウィンドウを閉じました）。
これらの動作は、meta サイトでも、自身で efbc2481d8 に更新したインスタンスでも確認できます（Firefox で Tab キーが正常に機能するのは、ここではじめて確認しました）。
「いいね！」 1
矢印キーは機能しないはずですが、Tab と Enter は機能するはずです！
つまり、= でメニューを開いて Tab を押しても、メニュー項目を循環していないということでしょうか？私は macOS を使用しており、Safari、Firefox、Chrome すべてで期待通りに動作しているため、少し困惑しています！
ここで全体的に何が起きているか詳しく調べてみたところ、前述の focus-visible を使用するというアイデアは機能しないことがわかりました。
問題は、ハンバーガーメニューが HTML 上でメニューボタンコンテナ（検索、ハンバーガー、ユーザーボタンを含むコンテナ）の外に表示されていることです。つまり、メニューは自然なタブ順序の次の要素ではありません。これを補うために、JavaScript で最初のメニュー項目に focus を設定しています。これには、項目をハイライト表示するという副作用があります（ :focus スタイルも必要だからです）。
スクリーンリーダーが移動に使用するキーは Tab だけではないため、Tab の押下を検出することに依存するのは難しいかもしれません。また、すべてのキー入力をキャプチャすると他のショートカットと干渉してしまいます。
考えられる修正策は以下の 2 つです。
- HTML 内でメニューを移動し、それをトリガーするボタンの直後に配置する。これによりレイアウトに副作用が生じる可能性があります。
- メニューが開いている間はフォーカスをメニュー内に固定するが、特定の項目にフォーカスを設定しない。つまり、メニューが開いている間は、ページ上の他の要素ではなくメニューの内容のみを Tab キーで移動できるようになります。これはおそらく望ましい解決策だと思います。
「いいね！」 2
その通りです。より明確にするために、これは macOS 11.4 と Safari 14.1.1 です。私はメタをプライベートウィンドウで、自分のインスタンスを通常ウィンドウで表示しています。
おそらく初期の Firefox テストで何か間違えたのでしょう。システム設定の「キーボード操作でコントロール間のフォーカスを移動する」が有効になっている場合は、おっしゃる通り動作し、無効になっている場合は、以前説明した通り「いいね」ボタンに Tab で移動します。
Firefox では、そのシステム設定を切り替えるだけで、ページを再読み込みすることなく、確実に動作を切り替えることができます。
Safari では、そのシステム設定の有無に関わらず、ページを再読み込みした後でも「いいね」ボタンに Tab で移動してしまいます。有効にした後に Safari を再起動してテストしたわけではありません。
Chrome も確認しましたが、システム設定の有無に関わらず、おっしゃる通り動作します。
「いいね！」 1
Safari で問題の原因を見つけました。Chrome や Firefox とは異なり、ヘッダーバーのどこかをクリックして Tab キーを押しても、ヘッダー内の要素が選択されないことに気づきました。
これにより、Safari の「詳細設定」にある以下の設定が発見されました：
Big Sur を新規インストールした際のデフォルト設定はこれであることが99%確実です。私が変更したとは思えません。この設定をオンにすると、ご説明いただいた通りに動作するようになります。上記のテキストが示す通り、この設定をオフにしていても Option-Tab を使用すれば同様に動作します。
「いいね！」 2