技術スポンサードリンク前回、Google公式の監査アドオン、SEO対策はlighthouseを使おう!Performance編の記事でlighthouse、そしてパフォーマンス改善について解説をした。今回はその次の項目である、Accessibilityについて解説と改善方法を記載していく。まとめlighthouseとは?使い方は?詳細は、前回の記事Google公式の監査アドオン、SEO対策はlighthouseを使おう!Performance編で書かせてもらったので割愛しますが、ざっくり説明すると、Googleが想定している「ユーザーにとって使いやすいサイト」かどうか自動で判定してスコアを出してくれるツールです。今回はその続きで、Accessibilityについて解説していきます。Appという項目もあるのですが、これはやや特殊なので割愛。(もちろん対応できた方がgoogleの評価は上がりますが、難易度が高くいくつか条件を満たす必要がある。)Accessibilityはどういう項目で、どう改善していくのかザックリいうと、「サイトがアクセスしやすいか」という項目です。lighthouseのドキュメントでは以下のように述べられています。スクリーンを見ることができ、それを使用してページのコンテンツを自分と同じように操作できると考えがちです。その結果、一部のユーザーには快適に動作しても、他のユーザーにとっては、不快に感じたり中断せざるをえなかったり、さまざまな問題が発生します。操作を快適に出来るサイトなのかという項目になります。文字のフォントサイズが小さすぎないか(シニア世代の人や、視覚に障がいを持つ人でも読みやすいサイトか)チェックボックスとそのラベルの距離が離れすぎていないか?(離れていると関連付けが難しい)といった要素になります。ドキュメントの詳細にはこのような項目があります。アクセシビリティの法的要件でこれらのガイドラインの使用を義務付けています。つの原則にそってまとめられています。知覚可能(Perceivable):ユーザーはコンテンツを知覚できますか。つの感覚で認識できるからといって、すべてのユーザーがそれを知覚できるとは限らないことを覚えておくと、役立ちます。コンポーネントを使用したりコンテンツをナビゲートしたりできますか。スクリーンを使用できないユーザーは操作できません。理解可能(Understandable):ユーザーはコンテンツを理解できますか。ユーザーが混乱することのない、分かりやすく一貫性のあるインターフェースになっていますか。エージェント(ブラウザ)で利用できますか。支援技術で使用できますか。これらを守ったサイトを作ることが必要ということをgoogleは言っているようです。いえいきなり難しいこと言われてもという感じなので、改善策を次の項目から上げていきます。改善項目とそれぞれの改善方法lighthoseのいくつかの改善項目と、その改善方法に章だてて解説していきます。Correctlyこれは、「エレメント(HTMLのそれぞれのタグの総称)を正しく扱えているか」ということです。このサイトでも意識していますが、例えばimgタグを使う場合、alt属性を使うといったことです。「通信状況などの関係で画像が読み込めなかったユーザー」にとってAccessibilityの高いサイトと言うことが出来ます。基本的にlighthouseの指摘に従って修正すればここは問題無いでしょう。Namesこれはbuttonタグやaタグ等はそれが何を示すものか、テキストを持っている必要があるということです。以下のような空のボタンタグがあって、cssで装飾されている場合、ある状況で何のボタンかわからなくなるのです。<button></button>ある状況って何?という感じですが、それは「スクリーンリーダー」を使っている場合などです。スクリーンリーダーは、「コンピューター画面読み上げソフト」のことで、視覚障がい者の方などが使うソフトです。いう人にボタンがあった場合に何も読み上げられなくなってしまうので気を付けよう、ということです。ここも基本的にlighthouseが検知して教えてくれるので、それに沿って修正すれば問題ないでしょう。Wellここは、「各タグがその要素について良く説明されているか(よくわかるような表示になっているか)」ということです。inputタグにはラベルがありますが、googleはラベルを利用することを推奨しています。Placeholderに説明を入れてしまう人もいますが、Placeholderはあくまでも入力例を入れるのに留めておくべきという考えのようです。理由があって、これも「スクリーンリーダー」の読み上げ対象にはならないようなのです。フォームには「氏名」「住所」といったラベルを付けてあげるようにすると良いということです。ここも基本的にlighthouseが検知して教えてくれるので、それに沿って修正すれば問題ないです。Satisfactory最後、これは「色のコントラストが最適なものか」ということです。read」つまり、コントラストが低いテキストは読みにくいのでやめた方がいいよ!ということです。灰色等は使いがちですが、PCの発光によっては、視覚の障がいなど関係なく見えなくなることがある色なので気を付けた方が良いでしょう。(とはいえ、全部真っ黒だとそれはそれでアクセントに欠けて読みにくいという問題もあると思うので、工夫が必要そう。)ここも基本的にはlighthouseが指摘してくれている部分の色合いを治すだけで良いのですが、ただ忠実に治すと全部真っ黒になってしまってそれはそれでユーザーも読みにくいと思います。色を戻すだけでなく「フォントサイズを変える」「strongタグで囲む」といった方法で修正するのが良いかと思います。他にも、コントラストが低くない色を使うなどでしょうか。(この辺は専門家が必要そう。)まとめというわけで、今回は「アクセスのしやすさ」の項目であるAccessibilityをまとめてみました。基本的にlighthouseがどこが駄目か具体的に説明してくれるので、非エンジニアでもぐぐりながらで出来る比較的修正しやすい項目だと思います。(ついでにHTMLについての勉強にもなる)パフォーマンスほど難易度が高くないので、最初はこの辺りから修正していくのが良いかもしれません。Practiceについて解説していきます。2018.10.21次の記事ゴブリンスレイヤーのOPを歌うMiliとは?オススメ楽曲まとめ。某配送システム白猫プロジェクトのアイシャが大好きなエンジニアの卵。Java/Shell/C++/HTML/Sass/rustかgoやりたい。コメントをキャンセルメールアドレスが公開されることはありません。コメントデータの処理方法の詳細はこちらをご覧ください。WordPress.。