HTMLを直接読み書きせず、スクリーンリーダーも使わずに、アクセシビリティを向上させられないだろうか（と思ってブラウザ拡張を作ってる）

これまでの何年間か、Webアクセシビリティまわりのことをやってきた中で、「Webアクセシビリティに取り組む」上でいろいろな障壁を感じてきました。

• 「なぜWebアクセシビリティをやるのか」の理解を得る・得てもらうまでの障壁
• イノベーター層・アーリーアダプター層な開発者（エンジニアやデザイナー）が取り組みを始める上での障壁
• マジョリティ層が取り組みを始める上での障壁

今回はこの3つめの「マジョリティ層が取り組みを始める上での障壁」の話です。

残りの2つについては、私が執筆に参加したWebアプリケーションアクセシビリティが網羅的なガイドになってくれるはずです。しかしコイツは内容的にも物理的にもゴツすぎる問題があると思っていて、導入編としては見えにくい、読みにくい、「困った！」を解決するデザインや、デジタル庁のウェブアクセシビリティ導入ガイドブックあたりが使い勝手が良いでしょう。

今回の話はWebアクセシビリティをやり始めてみるより少し先、ほかの人にWebアクセシビリティに関係するアクションを取っていってもらう上での悩みの話です。

HTML怖い

Webアクセシビリティをやる上で、「正しいHTMLをちゃんと書く」は、基本中の基本です。もちろんそれだけではなくて、わかりやすい情報設計であったり、見やすく理解しやすいビジュアルデザインであったり、ユーザーの操作に適切にフィードバックを与えることであったりも大切なのですが、どんなに頑張っていたとしても、最終的にユーザーに提示されるHTMLがきちんとしていなければ、キーボードでの操作やスクリーンリーダーでは使えないものになってしまいます。

正しいHTMLといっても、やることはこんな感じです。

• 見出しを <h1> 要素から <h6> 要素で表現する
• 画像の <img> 要素には alt 属性で代替テキストをつける
• ボタンやリンクは<div> 要素や <span> 要素ではなく、ボタンは <button> 要素で、リンクは <a href="..."> 要素で実装する
• フォームの要素は適切に <label> 要素でラベリングし、 name 属性なども正しくセットする

これらはどれも、どんなHTMLの入門書にも書いてあるであろう内容です。しかし、これらをきちんとやるとどんな良いことがあるのか、あるいはちゃんとやらないことでどんな悪いことがあるのか、それがどれくらい悪いことなのかはあまりイメージできないという人が多いんじゃないかと思います。その状態では、積極的にこのあたりを確認しない習慣が生まれてしまうのは明らかです。

これらを守るためには、人の目によるHTMLの確認か、lintなどのツールに頼ることになります。

もちろん、人の目による確認が、そもそもモチベーションの低い状態では期待できないことはここまで説明した通りです。さらに、Reactなどフレームワークを通して生成されるHTML（DOM）を、開発者がデベロッパーツール等で確認していないことも、実体験としてしばしばあります。みんなフレームワークの使い方を憶えようとしても、HTMLは憶えようとしてくれないのです。

見出し構造や画像の代替テキストなどは、デザイナーなどコードを書くのが役割ではない職種の人にも責任を持ってもらいたいところでもあります。ところがその確認を、HTMLを読んでやってくださいというのも難しいでしょう。HTMLを書いたことがないという人はもちろん、大学の授業などで多少HTMLをかじったことがあるという人であっても、いきなりプロダクションで使われているHTMLから目的の部分を探すというのは、「右クリックして『検証』をクリックすればそのあたりのDOMが見られるよ」だけでそうそうできるものではありません。

ツールに頼るのも限界があります。Reactなどのコンポーネント指向のフレームワークで開発されている現代のWebでは、いろいろなものが別々のファイルに分かれて存在しています。入力欄とラベルとか、見出しが順番に使われているかどうかとか、そういうところまでは個別のファイルに対するlintでは確認することができません。

なので、axe-coreやLighthouseで、ある程度の大きさのコンポーネントや、出来上がったページに対する検査をするのは必要不可欠であるというのが持論なのですが、これだけに頼るのも大きな問題です。これらのツールが alt 属性なしの <img> 要素を指摘するからと、すべての <img> 要素に alt="" を付けてしまっているページを実際に見たことがあります（すべての画像がスクリーンリーダーからは知覚できなくなり、全く意味の通らないページになってしまいます）。 alt 属性や aria-label 属性に、明らかに人間向けではない意味のない文字列を入れても、これらのテストはパスしてしまいます。

スクリーンリーダー怖い

そういうわけで、HTMLがちゃんと書けているかを確認するには、実際の支援技術を使うのが良いだろうということで、登場するのがスクリーンリーダーです。

スクリーンリーダーを使うのは、もちろん視覚障害者が利用できるようにという意味も大きいですが、「きちんとしてないHTML」の影響を最も大きく受けてしまう環境だから、という意味もあります。スクリーンリーダーで使えるくらいにちゃんとしていれば、マウスポインタを操作せずに使えていて、情報がきちんと機械可読であることがわかります。Webの技術は後方互換性を重視しているので、いま存在している多様な利用状況はもちろん、今後登場するであろう未知の支援技術（たとえばAIを活用した何かとか）にも対応できるはずなのです。

しかし、視覚障害者ではない一般のWeb開発者にとって、スクリーンリーダーを使ってみるというのは非常にたいへんなことであるはずです。なんかずっと喋ってるし操作方法が複雑だし憶えきれないし。macOSのVoiceOverでは読めるのにPC-TalkerやNVDAでは読めないなんてザラにあるし。しかもスクリーンリーダーごとに喋る内容も操作体系も全部違うし。

そしてHTMLのこともよくわからないので、HTMLをどう書き換えた結果、どう操作や読み上げられ方が変わるのかもよくわからない。

これまで延べ数百人の開発者にスクリーンリーダーの使い方を教えてきたはずですが、開発のなかで「スクリーンリーダーで確認する」という選択肢を持てている人の割合はかなり限られてしまっているのが残念ですが現実であろうと思います。

スクリーンリーダーでないと見えなかったものを、見えるようにしたい

そういう状況をもう少しどうにかできないかと、最近開発しているのが Accessibility Visualizer というブラウザ拡張です。これは、見出しレベルや代替テキストのような、普通なら見えないはずの情報を、Webページの上に乗せて見えるようにしてしまおうという拡張機能です。

（画像は「駒瑠市〜アクセシビリティ上の問題の体験サイト〜」 のたいへんな駒瑠市で、Accessibility Visualizerを使った状態）

これを使うことで、スクリーンリーダーを使わなくても、自動チェックでは発見できないような問題をある程度発見できるようになるのではないかと期待しています。画像の代替テキストがおかしいとか、見出しレベルがおかしいみたいなものは、なかなか人の目抜きには発見することはできません。

Accessibility Visualizerを使った簡単な確認フローは、以下のようなものを考えています。

1. axe DevTools や Lighthouse を使い、自動的に発見できる問題に対処する
   • Accessibility Visualizerは画面に要素を被せてしまいコントラスト計算などが上手くいかなくなるので、 axe DevToolsやLighthouseを使うときにはAccessiblity Visualizerの「チップを表示」をオフにしてください
2. 画面をキーボードのみで操作し、マウスポインタに頼らずに使えることを確認する
3. Accessibility Visualizerを使い、人の目による確認が必要な部分を確認する
   • ボタンやリンクの「アクセシブルな名前」が適切なものになっているか
   • 画像の代替テキストが適切なものになっているか
   • 見出しレベルが適切なものになっているか
   • その他もろもろ

この確認フローにはスクリーンリーダーは登場しませんが、よくスクリーンリーダーでの使用を妨げている問題の多くを潰せているのではないかと思います。「Accessibility Visualizerを使っているからスクリーンリーダーで動作確認しなくても大丈夫！」というところまでは到達できないと思いますが（特にWAI-ARIAをバリバリに使っている画面だと）、開発者の負担はかなり減らせているはずです。

加えて、Accessibility Visualizerにはもうすこし期待していることがあって、それは開発者がコーディングしながら動作確認をするときにAccessibility Visualizerを使うことで、そもそもアクセシビリティチェクより早い段階で問題を潰せること、アクセシビリティに最初から意識が向くようになることです。それを見越して、明らかに問題のある実装は、Accessibility Visualizerでも警告表示が出るようになっています。 alt 属性がない <img> 要素やラベル付けのできていない <input> 要素などには、赤い警告表示が出ます。

さらにいえば、普段のWebブラウジングでもAccessibility Visualizerを使うことで、いろんなWebサイトではどんな作り方をしているのかを見ていけるようになることも期待しています。Webのコーディングを経験していないデザイナーで、「画面に見出しを配置しましょう」と言われても「どこまで細かい単位で見出しがついているべきか」「そもそも何が見出しになっているべきなのか」がわからないという人にはこれまで何人も出会ってきました。Accessibility Visualizerを使って、世の中のWebページはこうなっているんだ、という視点から判断軸を獲得していけると良いだろうな、と思っています。