エンジニアだけで完結するWebアクセシビリティ向上！
年末です。
やり残したことはないですか？
........
そうです、アクセシビリティ向上ですね。
「アクセシビリティ向上したいけど、デザインから修正が必要だから大掛かりになるし....なかなか手がつけれないんだよね...」
ありますよね。
そこで、今回は
エンジニアだけで完結する、Webアクセシビリティを向上させるための実装をお伝えします。
また、エンジニアだけで完結するものに絞っても、リストはかなり多いので、その中でも重篤度CRITICALの一番重要なものに絞りました。
※重篤度は、freee株式会社が公開しているアクセシビリティー・ガイドラインに基づいており、「操作不能になる人がいる」レベルを表しています。
年末最後の実装に、2023年からの心機一転の実装に、
「あ、ここ直せるかも！」の視点を付け足していただければ幸いです。
また、この記事を読んでいるのが年末じゃない方も
アクセシビリティの季節は春夏秋冬ですので、ぜひ視点の付け足しにご覧ください。
🍊🍊🍊
なお、この記事はiCARE Dev Advent Calendar 2022 第1レーン の17日目です。
1. UIコンポーネントの役割や状態がわかるようにしよう！
そのUIにたどり着くことができ、それが何のためのものなのか、どんな状態なのかが分かるようにしましょう。
これを実現するために必要なものは主に下記の２つです。
①キーボード操作を可能にする
tabキーを押してフォーカスを当てることはできますか？
なぜ必要？
マウスを使わない/使えない視覚障害者、肢体不自由者は、キーボードで操作ができないとそもそもそのコンテンツにたどり着けません。
すること
aタグやbuttonタグ、inputタグなどユーザーの操作を受ける要素では、特別なものを追加せずとも元からフォーカスが効くようになっています。
しかし、一部の第三ライブラリーを使用した実装や、やむをえずdivタグでボタンを実装しているなどインタラクティブではない要素でインタラクティブなUIを実装している箇所では、フォーカスが効かない場合があります。
その場合はtabIndex属性を使用しフォーカスを持てるようにできます。
②正しいマークアップをする
ボタンをdivタグやspanタグで実装していませんか？
なぜ必要？
1つ目に、上記でも述べたようにdivはデフォルトではフォーカスが当たらないため、思わぬところでキーボード操作ができなくなります。
また２つ目に、例えばbutton要素は「ボタン」と読み上げられるなど、スクリーンリーダーは要素をもとにそのUIが何なのかユーザーに伝えます。なので、マークアップが間違っていると適切にその要素を読み上げてくれず、ユーザーがそのUIを認識できない場合があります。
すること
意味にあったマークアップをしてください。
また、正しいマークアップをすることで、tabIndex属性や下記で説明するrole属性を追加するなどの手間をかける必要もなくなります。
③適切な名前とrole属性を定義する
HTMLだけでなくJavaScriptを使って実装する場合はこれに注意が必要です。
例えば、開閉できるメニューなど、HTMLだけでは実装できないようなコンポーネントについて、スクリーンリーダーがそれはどんなコンポーネントなのか？どのような状態なのか？をユーザーに伝えれる必要があります。
このコンポーネントの情報を伝えるために使われているのが、「名前」「role属性」であり、
まずは「名前」と、roleが定義されていて、支援技術が取得できる状態になっているようにしましょう。
名前
名前を与え、ユーザーにそのUIが「何なのか」伝えてください。
なぜ必要？
「名前」は、(「コンポーネントの名前」「name」「Accessible Name」などとも呼ばれる)は、ブラウザが持つ「アクセシビリティツリー」を介してスクリーンリーダーなどの支援技術に渡され、音声読み上げなど多様な様式に変換され、ユーザーに伝えられます。
例えば、下記のimgタグで、複数の「名前(Accessible Name)」を記述します。
この場合、 Accessible Name and Description Computation の仕様に基づいて、いずれか１つの「名前」が優先されます。
<img src="images.png" alt="注意マーク" aria-label="前にページに戻る" >
この場合、altの「注意マーク」ではなくaria-labelの「前にページに戻る」の方が優先されます。
このように、aria-label aria-labelledbyなどWAI-ARIA の「label」系の属性は、他の「名前」(画像の altや、テキストリンクのラベル、ボタンのラベルなど) を打ち消して、支援技術のユーザーに伝えなくしてしまいます。
※「名前」について詳しく知りたい方は、こちらの記事がとても参考になりましたので是非みてみてください。
すること
この、「名前」が何になっているのかを検証ツールで確認し、
名前はついているか？名前はそれで良いのか？唯一音声読み上げされる言葉はそれで良いのか ？
を考えるようにしてみてください。
検証ツール > Elements > Accesibility
を選択し、該当の要素を選択したら確認できます。
role属性
役を命じ、ユーザーにそのUIが「何の役目」を果たしているのか伝えてください。
なぜ必要？
roleは、その要素やコンポーネントの役割を示すものです。
tab、link、checkboxなど、そのUIが何のためのものなのかを指定でき、スクリーンリーダーなどの支援技術で読み上げ、ユーザーに伝わります。正しいroleを与えていないと、適切な操作ができなくなってしまいます。
すること
HTMLの要素には、元々roleがついているので特別対応は不要です。そのデフォルトのroleとは違う役割を与えたい場合はrole属性を用いてください。
roleの種類はこちらを参考にしてください。
正しいroleがついているのかを確認は検証ツールでできます。
ただし、上で述べたようにHTMLにはデフォルトのroleがついているため、role属性を使いたくなった場合、要素を変えるだけでそのrole属性を与えれないのか？正しいマークアップなのか？をまず確認してください。
2. 内容を理解できるようにしよう！
htmlのlang属性を正しくつけましょう。
なぜ必要？
音声/点字出力などが適切に行われるようになります。
スクリーンリーダーの中には、lang属性の値に応じて音声合成エンジンを切り替えるものがあります。この場合、例えば、html要素にlang="en"が指定されているページにアクセスすると、英語用の音声合成エンジンが利用されます。もし、そのページが実際は日本語で書かれているとしたら、半角の英数のみが読み上げられる状態になり、意味不明なことになります。
すること
html要素のlang属性はページ全体に影響するので、適切な値をlang属性に指定するようにしてください。
リスト表の紹介
以上が、エンジニアだけで完結するWebアクセシビリティ向上のための実装法紹介ですが、
他にも重篤度がMAJORのもの、デザイン視点もの、などたくさんリストがあります。
そのリストについて、なんとfreee株式会社さんが「コード」「デザイン」など項目別にしたチェックリストを一般公開しているので是非これを活用して、次のステップに活かしてみてください。
さいごに
アクセシビリティはやることが山ほどあり、どこから手をつけて良いのかわからなくなります。
また、デザインから修正が必要だったり、なかなか簡単には進められないことが多いので、ここにエンジニアだけで改善できるものをまとめました。
ぜひ、これからの開発の視点に付け足してみてください。
皆さま、良いお年を。🍊⛄️🛌
参考文献
Discussion