アクセシビリティを意識したWeb制作

スクリーンリーダー

できること

• 見えている全てのテキストを読む
• 見えていないいくつかのタグを読む(altなど)
• 全てのヘッダとリンクをリストアップする

できないこと

• CSSのレイアウトに応じてテキストを読めない場合がある
• 画像の中の文字は読めない
• ナビゲーションを検出できない

ブラウザの望ましくない挙動

• video要素のcontrolsを表示していても、再生すると自動で隠されるため、スクリーンリーダーのフォーカスが外れてページの先頭に戻ってしまう

気をつけたいこと

• 有償のスクリーンリーダーは高価なので、古い環境を使い続けている場合もある。
• Mac, iOSはVoiceOverが標準で搭載されている。Windowsにもナレーターというのがある。
• 目が見えないからスクリーンリーダーを使うのと、読むのではなく聴くためにスクリーンリーダーを使うのではユースケースが異なる。
  • 原稿の時点で読み上げられることを想定した文章を書く必要がある
    • 記号に頼らない
  • 丸括弧などの補足は、話の流れが分断される
    • 視覚的には飛ばしたり戻ったりが自由だが、読み上げの場合うまくいかない
    • 文章を目で読む行為は2次元的であることがよく分かる
  • 自分たちが普段話している言葉は、どれくらい通じるだろうか？
    • 身近にいないと、その辺りの感覚がわからない
      • 流行語、略語、専門用語、商品名
• 漢字の読み上げがうまくいかない
  • かといって何でもひらがなにすると読み上げの抑揚がおかしくなる
• 障害の程度は人それぞれであり、これをやればOKというものではない
  • 正しい実装に時間が必要ならば、不完全でも良いので早く情報を出して欲しいという人もいる

コーディング

• 標準要素を使う
  • a要素をボタンにしない。button要素を使うなど。
• WAI-ARIAに準拠する
  • 標準的なHTMLを書けばセマンティックになるが、自分でコンポーネントを作る際に必要
  • imgタグのaltのようなもの
• 全ての操作がキーボードで満たせるか確認する
• 文字サイズを変えて崩れないか確認する
• 漢字を正しく読んでくれない場合があるので、スクリーンリーダー向けと画面表示向けでソースを2重で書く必要が生じる
  • sr-onlyクラスとaria-hidden="true"
  • 段落ごとでなく特定の文字のみspan要素で対応しようとしたが、DOMの構造が深くなるのでスムーズに読み上げてくれない