こんにちは。
後で試してみますが、これはスクリーンリーダーが実際に行う手順を実行していないため、解決策ではありません。特定の投稿に移動した場合、その投稿を読みたいと想定できます。Tabキーは読み取りコマンドではなく、フォーカス可能な次の要素にフォーカスを移動する方法です。読み取りコマンドは、下矢印キーまたはスクリーンリーダー固有のSayAllコマンドを使用することになります。少なくとも、私の好みの読み取りコマンドである下矢印キーが失敗した場合、フォーカスは視覚的な位置には全くなく、通常は投稿リストの前にあります。
もちろん、Tabキーはこのバグを解決するための汚い方法かもしれませんが、バグ自体の解決策ではありません。
@thoeg、@nolan、ありがとうございます。問題点が理解できたと思います。現在、投稿にフォーカスを設定するために空のspan要素を使用しています。この要素は aria-hidden=true と tabindex=-1 の両方を持っており、これがスクリーンリーダーから要素が見えなくなる原因になっていると思われます。
投稿内の最初のフォーカス可能な要素にフォーカスを切り替えるのが最善だと思います。ほとんどの場合、それは投稿作成者のユーザー名リンクになります。
こんにちは。
これは理にかなっています。aria-hidden は要素を非表示にし、-1 はフォーカスを受け取らないようにします。この要素が主題の見出しにフォーカスを取る場合、問題ありません。tabindex=0 のみを設定した場合に何が起こるかを見るのは興味深いかもしれません。
はい、@anni_anni さん、承知いたしました。修正します。先週、最初の試みを行いましたが、望ましくない副作用があったため元に戻さなければなりませんでした。すぐに別の方法で試します。
これについて何かアップデートはありますか？ まだ解決していません！
クラウス
はい、まだ解決していません。ここに暫定的なPRがあります: https://github.com/discourse/discourse/pull/23367、現在、内部からのフィードバックを待っています。
これでようやく修正のための別の試みがマージされました。現在の実装は、投稿内の最初のフォーカス可能な要素にフォーカスを設定することです。これは、ほとんどの場合、投稿作成者のユーザー名になります。投稿に移動してTabキーを押すと、Chromeでは次のようになります。
ここでメタでこれを試してみて、問題があれば教えてください。
Meta および community.fly.io では Chrome で古いバグ動作がまだ見られますが、discourse.team サイトでは修正が機能することを確認しました。これらは Discourse のバージョンが異なりますか？同じ Chrome バージョンとプロファイルを使用しています。
よろしくお願いします。
うーん、3つのサイトすべてがわずかに異なるバージョンのDiscourseである可能性がありますが、それらすべてに上記のリンクされた変更が含まれていると信じています。特にMetaは、常に tests-passed ブランチの最新の変更に更新されているため、ここで機能していないのが少し心配です…
OK、この件についてもう少し情報があります。これは、私がこのバグを報告した discourse.team サイトで確認されました。
初めて読む新しい投稿をクリックしても、音声フィードバックはなく、フォーカスはランダムに、おそらく最初の投稿ページに移動するように見えます。
以前に訪問したトピックをクリックすると、フォーカスは正しく配置され、音声フィードバックが得られます。
この動作は、現在 Firefox と Chrome の両方で一貫しているようです。以前は Firefox が新しいスレッドを表示する際にフォーカスを最初の投稿に正しく配置していたと思いますが、可能であればその動作を元に戻したいです。これにより、初めて読む場合と戻る場合のエクスペリエンスが同じになります。少なくとも Chrome で最後の読み取り位置が復元されるようになったことは嬉しいです。これは仕事で必要だからです。
Firefox と Chrome でこれらの動作がこれほど異なっていたとは驚きです。
この件に関するすべての努力に感謝します。
それは素晴らしいですね！変更は、トピックの最初の投稿ではない投稿へのナビゲーションに限定しました。以前から利用しているユーザーにとっては、新しい返信があったトピックへのナビゲーションであることが多いでしょう。
これは知っておくべき情報です。改善と修正の道筋が見えてきたと思います。もし使用しているコマンドの正確な順序を共有していただければ、それも役立ちます。
通常のChromeブラウザで、まだ読んでいない新しいトピックにアクセスしTabキーを押すと、フォーカスはトピックのタイトルに着地します。これは私にとっては妥当なようですが、あなたのユースケースには十分ではないかもしれません。
引き続きフィードバックをいただき、ありがとうございます。大変感謝しております！
これは、Jaws と Chrome で奇妙な動作です。メタの新しいトピックでテストしたところ、Jaws の新しい動作を確認しました。トピックのタイトルで Enter キーを押すと、読み込まれたばかりのページに関する通常の情報が表示されます。これは Jaws の標準的な動作です。トピック リストに戻り、同じトピックで Enter キーを押しても、フォーカスは最後の投稿に移動します。これにより、少なくとも 2 つの問題が解決されたようです。トピック リストで最後の投稿に移動する機能はテストしていませんが、機能すると思います。
しかし、すべてがうまくいっているわけではありません。これはまったく関係ないかもしれませんが、トピック リストに戻るために戻るボタンを使用すると、フォーカスが失われ、開いて読んでいたトピックに戻されません。これは Jaws/Chrome のバグである可能性がありますが、貴社の側にある可能性もあります。NVDA で確認する必要があります。
nvdaとchromeで試しましたが、ここでは何も機能しません。つまり、テーブルのトピックタイトルのいずれかをEnterキーで押すことができなくなりました。以前は機能していたはずです。もちろん、jawsユーザーなのでこれは気になりませんが、nvdaユーザーにとっては別の話です。
nvdadidは実際には機能しなかったので、トピックリストに戻るときにフォーカスが当たる問題をテストできません。
しかし、jawsはここで信頼性が高く、フォーカスはページの最上部に配置されます。
もう少しです！
当社の discourse.team サイトの最新の Chrome では、以前に訪問したトピックをクリックすると、読み取りを停止した場所に移動し、NVDA はフォーカスのある投稿の見出しを正しくアナウンスします。
残念ながら、新しいトピックをクリックしてもフォーカスが最初の投稿に移動しません。同様に、「h」を使用して最初の投稿にフォーカスを移動しようとしても失敗します。読み取りを開始するには手動で見つける必要があります。
Firefox では、新しい投稿の位置は正しく設定されているようです。なぜか Chrome だけのようです。
すべてが同じであると仮定すると、以前のスレッドで位置が復元されたことは、私にとって最大のペインポイントなので、うれしいです。ただし、両方のユースケースで一貫した正しい動作が得られることを願っています。
ありがとうございます！
それは素晴らしいですね。
これも正しいです。現在の実装では、ターゲット投稿が最初の投稿である場合、フォーカスを設定することは意図的にスキップされています。最初の投稿にも同じことを追加しようとしましたが、トピックURLを読み込む際に不要なスクロールが発生することが多く、すべてのユーザーにとって混乱を招く可能性がありました。
これは機能するはずです。テストを行い、修正できるかどうかを確認します。
フィードバックありがとうございます！
しばらく前から気になっていた別のペーパーカットについてご報告します。
新しいトピックを投稿する際、タグ/カテゴリを追加するためのドロップダウンが少し奇妙です。まず、私にとってのラベルは「Filter by」です。これが視覚的に表示されているかどうかはわかりませんが、Discourseに投稿し始めてから、タグがこのように追加されることに気づくまで文字通り何年もかかりました。「Filter」という言葉は、私には「水から何かを濾過する」ような意味合いであり、新しいものを追加するという意味ではありません。もしこれが視覚的に表示されているのであれば、そのフィードバックを自由に使ってください。しかし、もしこれがARIAのみであれば、調整が必要かもしれません。
次に、タグリストをクリックすると、ラジオボタンのように見えます。これらのボタンでスペースキーを押すと（ARIA radio group patternに従って）、検索がトリガーされるようです。はい、ここでEnterキーを押すこともできますが、親指がすぐそこにあるため、ボタン操作をトリガーするためにスペースキーを押すことに慣れています。
これは決してブロックするものではありませんが、発見するのがはるかに難しく、投稿するたびに、どのように機能するかを思い出す/再確認するために余分な思考を費やす必要があります。以前は個々のカテゴリをクリックしていましたが、それだと複数のタグを使用することが制限されていました。
このインタラクションには、ARIA combobox patternの方が適していると思います。具体的には、editable comboboxは、はるかに混乱の少ない方法で動作します。「A」と入力すると、矢印キーで「Alabama」に移動できます。ラジオボタンとして表示されないため、私の自動的な反応はそこでスペースキーを押すことではありませんが、もし押しても、期待どおりにスペースが挿入されます。ラジオボタンの表示を削除するだけで十分かもしれませんが、結果のカウントに関するチャットも少なくなるかもしれません。
どうもありがとうございました。
ありがとうございます、ノーラン。大変参考になりました。これらのドロップダウンに対処するための内部ToDoがありますので、フィードバックを確実に含めます。
承知しました、もう一つあります。
編集ボックスに絵文字（例：:)）を入力し、編集中にその絵文字にフォーカスが当たると、上下矢印キーで前の行または次の行に移動できなくなります。まず左右矢印キーで絵文字の外に移動する必要があります。
これはオートコンプリートの動作によるものだと思いますか？単一の一致しかない場合や、Enterキーまたは別のキーが押されない限り、この動作を無効にできるのではないでしょうか？初期入力や編集でのオートコンプリートの動作は理解できますが、一部のインスタンスでフォーカスを移動できない理由をデバッグするのが非常に難しく、これが原因のようです。編集のために手動でトリガーされるドロップダウンのようなものが、ここで適切な選択肢のように思えます。
どうもありがとうございました。
