NVDAでの見出しの読み上げのアクセシビリティ改善要望#940

chuff-chuff started this conversation in要望・アイデア・不具合

chuff-chuff

Dec 16, 2024

· 3 comments· 5 replies

Return to top

Discussion options

chuff-chuff
Dec 16, 2024

下記はMarkdown記法チートシートの見出しをNVDA+Chromeで読み上げた際のスピーチビューアーのスクリーンショットです。

c686397e4a0f4f11683d…と、人が聞いても意味が取れない読み上げが含まれているのがわかります。
Qiitaの見出しはリンクになるようになっていますが、実装を見ると以下のようになっています。

<h2 data-sourcepos="6:1-6:28"><span></span><a href="#code---%E3%82%B3%E3%83%BC%E3%83%89%E3%81%AE%E6%8C%BF%E5%85%A5"><i></i></a>Code - コードの挿入</h2>

a要素にアクセシブルな名前がないのが理由で、結果としてリンク先のURLが読み上げられてしまっているようです。

実際にNVDA+ChromeでQiitaを閲覧している知人曰く、「いつもイライラする」とのことで、NVDAが無料で広く使われているスクリーンリーダーであること、Chromeのブラウザにおけるシェアを鑑みても修正に値するのではないでしょうか。

なお、WCAG的には

達成基準 2.4.4 リンクの目的 (コンテキスト内)
達成基準 4.1.2 名前 (name)・役割 (role)・値 (value)

の2つの達成基準に引っかかることになるかと思います。

実際にNVDAで読み上げを試して頂き、改善をご検討頂けますと幸いです 🙏

You must be logged in to vote

Replies: 3 comments 5 replies

Comment options

DeguchiHiroki
Dec 19, 2024
Maintainer

ご意見ありがとうございます！

c686397e4a0f4f11683d…と、人が聞いても意味が取れない読み上げが含まれているのがわかります。

おっしゃる通り、この点はアクセシビリティ改善に取り組み始めた際から認識しており、ぜひ対応したいと考えている課題の一つです。
ただ、この部分はMarkdownの処理系に関わる領域であり、対応にも相当の工数が必要となるため、優先順位の兼ね合いから着手できておりません🙇🏻‍♂️

具体的な対応時期をお約束することが難しい状況ではありますが、お待ちいただけると幸いです🙏

You must be logged in to vote

1 reply

Comment options

debiru Apr 23, 2025

対応にも相当の工数が必要となるため

HTML 設計一つ直すだけで相当の工数がかかるのですか？

Comment options

ymrl
Apr 23, 2025

なにやら事情がありそうだなと思って観察してみたんですが、

記事本文をReact DeveloperToolsで観察すると、記事本文が大きなひとつのコンポーネントとして表示されている
- React以外によって書かれたMarkdownレンダラーをwrapするようなReactコンポーネントが実装されている？
- このあたりが「Markdownの処理系に関わる領域」というところでしょうか
<a> 要素内にあるのは<i></i> で、通常時はdisplay: none になっている
- 見出し要素へのマウスオーバーにより、<i> 要素がdisplay: block となり、.fa-linkの::before 疑似要素にcontent: "\f0c1" が出現する
- それにより、見出し左側にアイコンが表示される
アイコンをクリックすると、<a> 要素のhref となっている見出し直前の要素のidが URLのhashに設定され、スクロールが生じる
- アイコンが小さいので、見出しへのマウスオーバー状態を維持したまま、アイコンまでマウスポインタを移動させるのがやや困難。特に見出しが長く2行以上にわたって表示されている場合に難易度が上がる

という状態にあるようでした。

おそらく、Markdownレンダラーに手を入れるのが難しい状況にあるのかと推察しますが、以下のような方法で、比較的簡単にマシな状態にできるのではないかと思います。

マウスオーバーしていないときのdisplay: none のスタイルを、<i> 要素に対してでなく<a> 要素に対して設定する
- display: none にしておけばアクセシビリティツリーから除外されるため、スクリーンリーダーからは不可視になります
  - スクリーンリーダーのカーソル位置にマウスポインタを追従させるような設定を使っている場合、<a> が読めてしまったりはあるかもしれません
- ただし、Tabキーにより、見出し付近にフォーカスを移動させることはできなくなります。
  - とはいえ、現状ではフォーカスが移動しても<a> 要素の中身がすべてdisplay:none になっているため、開発者がTabキーによる見出し付近への移動を意図していたようには見えません。
  - もしこのような見出し付近へのフォーカス移動が欲しいのであれば、見出し自体や周辺の要素にtabindex="0" をつけておくような対応は考えられます。
<a> 要素に、なにか1文字入れておく
- URLエンコードされた見出しが読み上げられるよりは、何かの文字なり記号なりが入っていると多少マシかもしれないと思いました。「🔗」の絵文字とか。
- aria-label でつけるとか、もしかしたらリンクの::before 疑似要素に入れるのでもいいかもしれません。疑似要素ならMarkdownレンダラーをいじらず、CSSだけで完結できるんじゃないでしょうか。
- これは邪魔であることにはかわりないですが、まだマシという話です。

Markdownレンダラーに多少手を入れて良いのなら、以下のようなものが考えられます。

<a> 要素を見出しよりも後ろに移動させる
- Wikipediaの編集リンクなどは、見出しの後ろについています。そこまで読めば見出しは終わりということはわかるので、前にあるより良いはずです
見出しテキスト自体を<a> 要素にしてしまう
- 見出し部分のhashを示すリンクを、見出し自体に設定している例はたまに見かけます
アイコンは常に表示し、見出し要素の外に出す
- そもそもリンクが見出し要素に入っている必要はないはずですし、上で指摘したとおり見出しが2行以上になると、アイコンへマウスオーバー状態を維持したままマウスポインタを移動させるのが難しい問題があります。いっそ外に出して常に表示しておいたほうが、使い勝手が良くなるはずです
- :hover 以外のときは、アイコンの色を目立たないものにしておけば、現状と見比べたときの違和感を小さくできるはずです。