Google公式の監査アドオン、SEO対策はlighthouseを使おう!Accessibility編

Google公式の監査アドオン、SEO対策はlighthouseを使おう!Accessibility編

前回、Google公式の監査アドオン、SEO対策はlighthouseを使おう!Performance編の記事でlighthouse、そしてパフォーマンス改善について解説をした。
今回はその次の項目である、Accessibilityについて解説と改善方法を記載していく。

lighthouseとは?使い方は?

詳細は、前回の記事
Google公式の監査アドオン、SEO対策はlighthouseを使おう!Performance編
で書かせてもらったので割愛しますが、
ざっくり説明すると、Googleが想定している「ユーザーにとって使いやすいサイト」かどうか自動で判定してスコアを出してくれるツールです。

前回はこのサイトのページでスコアを出して、それを基にパフォーマンス(ページの速度)について解説しましたが、
今回はその続きで、Accessibilityについて解説していきます。

実はPerformanceAccessibilityの間に、Prograssive Web Appという項目もあるのですが、
これはやや特殊なので割愛。(もちろん対応できた方がgoogleの評価は上がりますが、難易度が高くいくつか条件を満たす必要がある。)

Accessibilityはどういう項目で、どう改善していくのか

accessibility1
ザックリいうと、「サイトがアクセスしやすいか」という項目です。
lighthouseのドキュメントでは以下のように述べられています。

デベロッパーは、すべてのユーザーがキーボード、マウス、またはタッチ スクリーンを見ることができ、それを使用してページのコンテンツを自分と同じように操作できると考えがちです。その結果、一部のユーザーには快適に動作しても、他のユーザーにとっては、不快に感じたり中断せざるをえなかったり、さまざまな問題が発生します。

つまり、なんらかの障害を抱える方や、あまりコンピューター機器に詳しくない方にとってもアクセスし、
操作を快適に出来るサイトなのかという項目になります。
分かりやすいアクセスのしやすさの具体例を挙げると、

  • 文字のフォントサイズが小さすぎないか(シニア世代の人や、視覚に障がいを持つ人でも読みやすいサイトか)
  • チェックボックスとそのラベルの距離が離れすぎていないか?(離れていると関連付けが難しい)

といった要素になります。

更にドキュメントの詳細にはこのような項目があります。

いくつかの国では、ウェブ アクセシビリティの法的要件でこれらのガイドラインの使用を義務付けています。WCAG は、頭字語 POUR と呼ばれる 4 つの原則にそってまとめられています。

知覚可能(Perceivable):
ユーザーはコンテンツを知覚できますか。視覚など、1 つの感覚で認識できるからといって、すべてのユーザーがそれを知覚できるとは限らないことを覚えておくと、役立ちます。
操作可能(Operable):
ユーザーは UI コンポーネントを使用したりコンテンツをナビゲートしたりできますか。たとえば、カーソルを合わせる操作を必要とするものは、マウスやタッチ スクリーンを使用できないユーザーは操作できません。
理解可能(Understandable):
ユーザーはコンテンツを理解できますか。ユーザーが混乱することのない、分かりやすく一貫性のあるインターフェースになっていますか。
堅牢性(Robust):
コンテンツはさまざまなユーザー エージェント(ブラウザ)で利用できますか。 支援技術で使用できますか。

これらを守ったサイトを作ることが必要ということをgoogleは言っているようです。
まぁ、とはいえいきなり難しいこと言われてもという感じなので、改善策を次の項目から上げていきます。

改善項目とそれぞれの改善方法

lighthoseのいくつかの改善項目と、その改善方法に章だてて解説していきます。(全部は膨大過ぎてまとめられなかった・・・)

Elements Use Attributes Correctly

accessibility2

これは、「エレメント(HTMLのそれぞれのタグの総称)を正しく扱えているか」ということです。
このサイトでも意識していますが、例えばimgタグを使う場合、alt属性を使うといったことです。
ちなみに、なぜaltにするかというと、画像が読み込めなかった場合に文字情報でどんな画像かがわかるので、
通信状況などの関係で画像が読み込めなかったユーザー」にとってAccessibilityの高いサイトと言うことが出来ます。

基本的にlighthouseの指摘に従って修正すればここは問題無いでしょう。

Elements Have Discernible Names

accessibility3

これはbuttonタグやaタグ等はそれが何を示すものか、テキストを持っている必要があるということです。
例えば、以下のような空のボタンタグがあって、cssで装飾されている場合、ある状況で何のボタンかわからなくなるのです。

<button></button>

ある状況って何?という感じですが、それは「スクリーンリーダー」を使っている場合などです。
スクリーンリーダーは、「コンピューター画面読み上げソフト」のことで、視覚障がい者の方などが使うソフトです。
そういう人にボタンがあった場合に何も読み上げられなくなってしまうので気を付けよう、ということです。
ここも基本的にlighthouseが検知して教えてくれるので、それに沿って修正すれば問題ないでしょう。

Elements Describe Contents Well

accessibility4
ここは、「各タグがその要素について良く説明されているか(よくわかるような表示になっているか)」ということです。
例えば、inputタグにはラベルがありますが、googleはラベルを利用することを推奨しています。
Placeholderに説明を入れてしまう人もいますが、
Placeholderはあくまでも入力例を入れるのに留めておくべきという考えのようです。

もちろんちゃんと理由があって、これも「スクリーンリーダー」の読み上げ対象にはならないようなのです。
なので、例えばフォームには「氏名」「住所」といったラベルを付けてあげるようにすると良いということです。

ここも基本的にlighthouseが検知して教えてくれるので、それに沿って修正すれば問題ないです。

Color Contrast Is Satisfactory

accessibility5

最後、これは「色のコントラストが最適なものか」ということです。
このブログも指摘されているのですが、
例えば「Low-contrast text is difficult or impossible for many users to read」
つまり、コントラストが低いテキストは読みにくいのでやめた方がいいよ!ということです。
特に灰色等は使いがちですが、PCの発光によっては、視覚の障がいなど関係なく見えなくなることがある色なので気を付けた方が良いでしょう。
(とはいえ、全部真っ黒だとそれはそれでアクセントに欠けて読みにくいという問題もあると思うので、工夫が必要そう。)

ここも基本的にはlighthouseが指摘してくれている部分の色合いを治すだけで良いのですが、
ただ忠実に治すと全部真っ黒になってしまってそれはそれでユーザーも読みにくいと思います。
なので、色を戻すだけでなく「フォントサイズを変える」「strongタグで囲む」といった方法で修正するのが良いかと思います。
他にも、コントラストが低くない色を使うなどでしょうか。(この辺は専門家が必要そう。)

まとめ

というわけで、今回は「アクセスのしやすさ」の項目であるAccessibilityをまとめてみました。
基本的にlighthouseがどこが駄目か具体的に説明してくれるので、非エンジニアでもぐぐりながらで出来る比較的修正しやすい項目だと思います。
(ついでにHTMLについての勉強にもなる)
パフォーマンスほど難易度が高くないので、最初はこの辺りから修正していくのが良いかもしれません。

次回はBest Practiceについて解説していきます。