公開前の最終チェック ―
アクセシビリティとパフォーマンス

前回のおさらい

前回は、人の目には見えない「サイトの履歴書」を整える回でした。検索エンジンやSNSに向けて、café SOELが何のサイトかを正しく伝えられるようになったはずです。

そして今回。ここまで積み上げてきたものを、最後にもう一度"全体の品質"という視点から見直します。誰にとっても使いやすいか、表示は軽快か、HTMLに壊れたところはないか。公開前の最終点検です。

今回のゴール

アクセシビリティとは — "すべての人"に届けるための設計

アクセシビリティ（Accessibility、略してa11y）は、直訳すると「到達しやすさ」。Webの文脈では、年齢、視覚、聴覚、運動機能、使っているデバイスや環境にかかわらず、誰もが情報にアクセスできる状態を指します。

たとえば、目の不自由な方はスクリーンリーダーという読み上げソフトでWebを利用します。画像のalt属性がなければ、そこに何が写っているかは誰にも伝わりません。マウスが使えない方はキーボードだけで操作します。<button> ではなく <div> でボタン風に作られていたら、フォーカスも当たらず、押すこともできません。

アクセシビリティ対応は「特別な人のための特別な対策」ではありません。晴れた日に外でスマホを見ている人、片手が塞がっている親御さん、通信環境の悪い場所にいる旅行者――状況によって、誰もが一時的に"何かが不自由な人"になります。アクセシブルなサイトは、結局のところ全員にとって使いやすいサイトなのです。

そして嬉しいことに、私たちはすでに基礎の大半を終えています。第2回でセマンティックHTMLを意識し、第3回でaltを書いた。<button> と <a> を使い分け、見出し階層も守ってきた。今回やるのは、そこに少しだけ仕上げを加える作業です。

alt属性を見直す — "何が写っているか"ではなく"何を伝えているか"

まずは既存のalt属性を見直します。第3回ですべての画像にaltを入れましたが、あのときは「画像の内容をなんとなく説明する」段階でした。ここで一歩進めましょう。

altの書き方には、大事な原則があります。それは 「画像が持っている"役割"に合わせて書く」 ということ。同じ写真でも、文脈が違えばaltも変わるんです。

<img src="img/hero.jpg" alt="画像">
<img src="img/menu-coffee.jpg" alt="コーヒー.jpg">
<img src="img/logo.png" alt="ロゴ">

<!-- ヒーロー画像：サイトの世界観を伝える役割 -->
<img src="img/hero.jpg"
     alt="大きな窓から自然光が差し込むcafé SOELの店内。木のテーブルと観葉植物が並ぶ開放的な空間">

<!-- メニュー画像：商品名とセットなので、写真が何かを補足する役割 -->
<img src="img/menu-coffee.jpg"
     alt="陶器のカップに注がれたハンドドリップコーヒー">

<!-- ロゴ画像：お店の名前を表す役割なので、店名そのものをaltに -->
<img src="img/logo.png" alt="café SOEL">

ポイントは、altを読み上げたときに意味が通じるかを想像してみること。目を閉じて、altだけを耳で聞くと想像してみてください。「画像」「ロゴ」では何も伝わらない。でも「café SOEL」なら、ロゴだとわかる。

café SOELのサイトでは、第3回で書いたaltがすでに丁寧な内容になっています。今回はよりリアルな情景が伝わるように、具体性を少しだけ足す程度の調整で十分です。

ARIA属性でハンバーガーボタンに"意味"を添える

第6回で追加したハンバーガーメニューのボタン。見た目は3本線ですが、スクリーンリーダーにとっては「ただのボタン」です。何をするボタンなのか、今開いているのか閉じているのかが伝わりません。

ここで登場するのが ARIA属性。ARIA は Accessible Rich Internet Applications の略で、HTMLだけでは表現しきれない"状態"や"役割"を支援技術に伝えるための属性群です。

今回使うのは、基本中の基本の2つだけ。

<button class="menu-toggle" type="button"
        aria-label="メニューを開く"
        aria-expanded="false"
        aria-controls="primary-nav">
  <span class="menu-toggle-bar"></span>
  <span class="menu-toggle-bar"></span>
  <span class="menu-toggle-bar"></span>
</button>

おまけで aria-controls="primary-nav" も添えました。「このボタンは id="primary-nav" の要素を操作するよ」という紐付けです。対応するナビ側にも id を足しておきましょう。

<nav class="nav" id="primary-nav" aria-label="メインナビゲーション">
  <ul class="nav-list">
    <!-- 以下は変更なし -->
  </ul>
</nav>

loading="lazy" — 画像の読み込みを賢くする

次は、目に見えないけれど体感速度に効くチューニングです。

ブラウザは標準では、ページを開いた瞬間にすべての画像を一気に読み込もうとします。でも、café SOELのサイトはそこそこ長いページ。フッターのそばにある画像まで最初から読み込むのは、ちょっともったいない。

そこで使うのが loading="lazy" 属性。「この画像は、ユーザーが近づいてきてから読み込めばいいよ」とブラウザに伝える、たったひとつの属性です。

<img src="img/menu-coffee.jpg"
     alt="陶器のカップに注がれたハンドドリップコーヒー"
     width="800" height="800"
     loading="lazy">

ここにひとつ、大事なルールがあります。ヒーロー画像には loading="lazy" を付けないということ。

ヒーロー画像はページを開いた瞬間に画面に映る、いわば"第一印象"。この画像だけは最優先で読み込んでほしいので、lazyの対象から外します。ファーストビューに入るか入らないか — これが判断の基準です。

café SOELの場合、lazyを付けるのは以下の画像です：

• img/concept.jpg（コンセプトセクション）
• img/menu-coffee.jpg、menu-latte.jpg、menu-cake.jpg、menu-sandwich.jpg（メニュー4枚）
• img/interior-01.jpg、interior-02.jpg（ギャラリー）
• img/exterior.jpg（ギャラリー・アクセスで2回使用）

img/hero.jpg と、ヘッダー／フッターのロゴ img/logo.png には付けません。ロゴはファーストビューに入っているうえ軽量なので、普通に読み込ませればOKです。

HTMLバリデーション — 壊れたコードは書いていないか

ここまで書いたHTMLに、うっかりタグの閉じ忘れや属性の書き間違いがあるかもしれません。人間の目でチェックするには限界がある。そんなときに頼るのが、W3Cが運営している無料のバリデーターです。

Lighthouseで"サイトの健康診断"を受ける

続いて、Google Chromeに標準搭載されているLighthouseというツールを使います。ページを自動で解析して、「パフォーマンス」「アクセシビリティ」「ベストプラクティス」「SEO」の4つの観点で100点満点のスコアを出してくれる、まさに健康診断のようなツールです。

実際に計測すると、こんな感じのスコアが出るはずです。アクセシビリティ、ベストプラクティス、SEOはほぼ満点。ただしパフォーマンス（ページの表示速度）はこの時点だとオレンジ寄り。理由はシンプルで、画像ファイルが大きすぎるからです。

ここで、次の仕上げに進みます。

JPGをWebPに変換して、ページを軽くする

第1回で配布した画像素材は、あえてJPG形式のままにしてありました。ここで「軽くする」体験を一度、自分の手でするためです。

ここで使うのが WebP（ウェッピー） という画像形式。Googleが開発したWeb向けの画像形式で、JPGと同じ見た目の品質を保ちながら、ファイルサイズを2〜4割ほど小さくできます。

仕組みは少し専門的ですが、ざっくり言えば「JPGより新しく、より賢い圧縮アルゴリズムを使っている」。主要ブラウザはすべてWebPに対応しているので、実務でもほぼデフォルトの選択肢になっています。

同じ画像をWebPに変換するだけで、これくらい軽くなります。画像10枚あれば、ページ全体で数MBの差。モバイル回線で見る読者にとっては、体感速度がまるで違います。

変換の手順

<!-- ↓ 変更前 -->
<img src="img/hero.jpg" alt="..." width="1920" height="1080">

<!-- ↓ 変更後 -->
<img src="img/hero.webp" alt="..." width="1920" height="1080">

OGP画像（img/ogp.jpg）は、WebPに変換しない方が安全です。SNSの中にはまだWebPを確実にサポートしていないものもあるので、OGPはJPGのままにしておきましょう。

書き換えが終わったら、もう一度Lighthouseを走らせてみてください。さっきオレンジだったパフォーマンスのスコアが、ぐっと緑に近づいているはずです。数字が動くのは、素直に気持ちいいですよ。

最終チェックリスト

公開前に、ここまでの作業をもう一度確認しましょう。

全部チェックが付いたら、café SOELのWebサイトは"公開できる品質"に到達したということです。

ここまでの完成形を確認しよう

保存してブラウザをリロードしてみてください。見た目は第8回とほとんど同じ。でもサイトの"中身"は、スクリーンリーダーにも、検索エンジンにも、モバイル回線の読者にも、ちゃんと届くものになっています。

あなたの画面でも、同じように表示されていますか？ Lighthouseのスコアも、手元で走らせて確認してみてくださいね。

ちなみにCSSは第7回から変わっていません。今回修正するのは index.html の画像周りとボタンの属性のみ。変更箇所は少ないですが、サイトの品質は一段と上がっているはずです。