問題1:ヘッダーナビゲーションの不具合 / DOM操作

問題:返信投稿要素が初期ページ読み込み時にドキュメントオブジェクトモデル(DOM)に表示されず、スクリーンリーダーが通過した後にDOMから削除されるため、Windowsスクリーンリーダーはコンテンツへのアクセスを失い、VoiceOverはページにアクセスするために使用できるツールが制限されます。

具体的な動作:

●メイン投稿から返信投稿に移動しようとすると、返信投稿で使用される要素はまだDOMにレンダリングされていないため、ユーザーはクイックナビゲーションを使用して返信投稿内の任意の要素に移動できません。

●個々の返信投稿は、スクリーンリーダーがそれらにフォーカスを当てたときにのみDOMでレベル2の見出しとしてマークされるため、ユーザーは返信投稿に到達するためにページ上のすべての要素をナビゲートする必要があります。

●ANDIアクセシビリティツールは、要素の操作後に常に変化するヘッダー構造を示します。

●要素にアクセスしようとすると、「DOMから削除されました」というエラーが表示されます。

●スクリーンリーダーはページ構造の一貫した表示を失います。

プラットフォームの詳細:

●JAWS/NVDA:完全な障害 - 返信ヘッダーにまったくアクセスできません。

●VoiceOver:クイックナビゲーション経由でアクセスできますが、ローターアクセスはありません。VoiceOverは直接ページを読み取ることで機能するため、ユーザーはクイックナビゲーションキーを使用して返信ヘッダーをナビゲートできます。ただし、スクリーンリーダーがフォーカスしている要素のみがローター内でアクセス可能です。

なぜ重要なのか:スクリーンリーダーユーザーは、ディスカッションの返信を読むという主要なタスクを完了できません。これは、ディスカッションへの参加に対する完全な障壁です。

「いいね!」 2

これらの問題は、Screen Reader Accessibility issues で最初に報告されました。解決にご協力ください。当社のコミュニティには、ディスカッションボードで基本的な機能を実行できない、視覚障がいのあるユーザーがいます。

「いいね!」 2

ご報告ありがとうございます!

具体的にどのトピックでテストされたかご存知ですか? これにより、同じ問題を確認できるよう、共通の参照点を持つことが役立ちます。投稿には多くのバリエーションがあるため、正しい場所に労力を集中させたいと考えています。

try.discourse.org を使用することもできますし、必要であれば Meta の投稿を参考にすることもできます。

「クイックナビゲーション」とは、具体的に要素リストのことを報告されていますか? NVDA と VoiceOver の両方で、要素リストでアクセスできるのは現在 DOM に存在するコンテンツのみであることを確認しました。これは、視覚ユーザーにとっても同様であり、Discourse の基本的な仕組みです。手動ページネーションの代わりに、ユーザーがページをスクロールダウン/アップするにつれてコンテンツをロード/アンロードします。

これは通常、「クイックナビゲーション」という言葉を聞いたときに期待することですが、アプリケーション間で常に一貫した用語があるわけではないことを理解しています。

NVDA と VoiceOver で要素から要素へのナビゲーションが機能することを確認しましたが、「小さな投稿」に関する問題がナビゲーションを妨げる可能性があることを特定しました。修正を適用します。

「小さな投稿」とは、ピン留め、クローズ/オープン、アクティブなどのトピックステータス更新です。これらの問題は、通常の投稿のような内部ヘッダーがないため、投稿がロードされる前のしきい値に配置されると、ユーザーは停止し、「次のヘッダーがありません」としか聞こえない場合があります。

ANDI のような自動ツールは、Discourse のような Web アプリケーションでの DOM の変更を認識できないことがよくあります。これらは一般的に静的ページのような単純なシナリオ向けに構築されています。そのため、これらのツールを使用して問題を特定することもありますが、より複雑なシナリオ(ナビゲーションなど)では、手動テストで再現できることに焦点を当てる必要があります。

これも要素リストに関するものだと推測しますか? これは予想される動作ですが、Discourse で要素リストが機能するように改善できる点があるかもしれません。エンジニアに相談して意見を聞きます。

これも要素リストに限定した問題ですか? 上記で述べたように、NVDA と VoiceOver の要素から要素へのナビゲーションをテストし、これが機能することを確認しました。ただし、機能しない特定のコンテキストがある場合は、詳しく調査できます。

「いいね!」 3

最新拡張コアカリキュラム/マスター・ザ・モナークのトピック - APH Hive ディスカッションボード

エクスプレスアクティビティがテストされました。

「いいね!」 1

これについての簡単なアップデートです。要素リストをより良くナビゲートできる方法で、ランドマークの改善に取り組んでいます。

要素リスト内の見出しのナビゲーションは変更されませんが、これは妥当な代替手段となることを願っています。変更点はここに概説されています: A11Y: improve landmark navigation and add aria-labels to post controls by awesomerobot · Pull Request #34421 · discourse/discourse · GitHub

要するに、これは次のことを行います:

  • DOM内のすべての投稿にランドマーク領域を提供する
  • 上/下により多くの投稿があることを明確にするランドマーク領域を追加します — 投稿をロード/アンロードするため、手動のページネーションを使用する必要はありません。トピックに一度に数百の投稿がDOMにロードされると、パフォーマンスの問題が発生する可能性があります。

見出しコンテンツすべてをパフォーマンスを低下させることなくDOMで利用可能にすることは非常に複雑な変更となるため、これは中間的な解決策です。完璧ではありませんが、「コンテンツをさらに読み込む」領域にナビゲートすると、投稿が正しく読み込まれ、その時点で要素リストを再度開くことができます。

  • 投稿コントロールをナビゲーション領域からツールバー領域に変更しました。これは意味的により正確であり、ランドマーク領域リストを投稿に集中させることができます。

*ついでに投稿コントロールのラベルも改善しました。

そのため、トピック内のかなりまばらなランドマーク要素リストから

トピック構造をより明確に表すものへ

このアップデートは今週中にリリースされる予定です。利用可能になったら、これらの変更に関するフィードバックを聞かせていただけると幸いです @adress

「いいね!」 4

Hi @awesomerobot、APHからこの問題に関するアクセシビリティコンサルティングを依頼されました。このスレッドに関連する主な問題を示すビデオリンクをいくつか以下に示します。最初の録画のタイムスタンプ08:36から始まる最初の録画で問題を確認できます。
Discourse Accessibility Audit JAWS
これは要素リストとは関係ありませんが、クイックキーまたはクイックナビゲーションと呼ばれるもので、次のHTML要素タイプ(この場合は見出し)に移動します。

この問題を新しいランドマークを作成して修正する問題点は、ランドマークは通常、高レベルのセクションのために予約されているため、スクリーンリーダーユーザーにとって、ランドマークを使用してページの小さなセクション間を移動すると、ナビゲーションバナーのようなページの大きな領域へのクイックアクセスが失われることです。これは、WCAG標準レベルAのバイパスブロックの違反でもあります。

「いいね!」 1

素晴らしい、追加情報ありがとうございます!動画があれば大変助かります。動画はパスワードで保護されているようです。解除していただくか、アクセシビリティ@discourse.orgまでコードをお送りいただけますでしょうか。

「いいね!」 1

はい、申し訳ありません。こちらがパスコードが埋め込まれたリンクです。Video Conferencing, Web Conferencing, Webinars, Screen Sharing - Zoom
パスコード: .kBwdK3a

「いいね!」 1

@awesomerobot さん、こんにちは。コーディの同僚で、アクセシビリティエンジニアです。問題を診断するためにリポジトリを確認しました。ご存知かもしれませんが、主な問題は次のとおりです。(1) クロークされた投稿のコンテンツはスクリーンリーダーで表示できず、(2) PostStreamViewportTracker によってユーザーのビュー内にある場合にのみ投稿がクローク解除されます。

修正方法を検討するにあたり、次の 2 つを最適化したいと思います。(1) スクリーンリーダーで各投稿に見出しによるナビゲーションを有効にすること、(2) Discourse リポジトリへの変更とパフォーマンスへの影響を最小限に抑えること。

推奨されるアプローチは、各読み込まれた投稿に軽量なラッパーを維持することです。これには、見出しナビゲーション用のセマンティック H2 が含まれ、本文の大部分はクロークされたままになります。これにより、ページ全体に DOM を膨張させることなく、支援技術の見出しを安定させることができます。ユーザーが見出しナビゲーションを介して投稿の H2 に着地すると、スクリーンリーダーはページスクロールをトリガーし、それによって投稿の本文がその場でクローク解除されます。

このソリューションの実現可能性は、次に読み込まれる投稿のチャンクによって異なります。オプションの改善は、読み込まれた投稿のリストの下部にある「投稿をさらに読み込む」というスクリーンリーダー専用のセンチネル見出しです(PR で提案されている「読み込み領域」と同様)。この見出しが表示されたとき、または見出しローターから選択されたときに、次のチャンクが読み込まれ、aria-live=polite メッセージを介して完了がアナウンスされます。

「いいね!」 3

フィードバックとご提案ありがとうございます。社内で検討し、アップデートをお知らせします!

「いいね!」 1

これは、A11Y: improve heading-to-heading nav, fix infinite scrolling for screenreaders by awesomerobot · Pull Request #34589 · discourse/discourse · GitHub で現在取り組んでいるアプローチです。

提案されたように、すべての投稿(表示されているかどうかにかかわらず)に軽量なスクリーンリーダー専用の見出しを追加しています。また、さらに多くの投稿の読み込みをトリガーする見出しと、読み込みが完了したことを知らせるアナウンスも追加しています。

まだ作業中のため、いくつかの調整が必要ですが、この修正を皆さんがすぐに利用できるようになることを願っています。

「いいね!」 1

タイムラインの予想について簡単なアップデートです。来週あたりまでリリース前の凍結期間に入り、チームの多くは年次ミーティングで不在となりますので、この変更が反映されるまでにはおそらく数週間かかるでしょう。

「いいね!」 2

こんにちは!11月5日より、トピックナビゲーションが見出しによって改善されるアップデートをマージしました。詳細はこちらをご覧ください。

「いいね!」 4