Site search / サイト内検索

必要な情報を探す

ページ内の言葉を探す検索と、意味が近い内容を探す検索を使い分けられます。

「検索する」を実行すると、入力した検索語をCloudflare Workers AIで数値表現に変換し、その数値表現をCloudflare Vectorizeで当サイトの公開情報と照合します。あわせて、Acecore共通検索API(acecore.net)へ送信し、 Acecore関連サイトの公開情報を下部に表示することがあります。個人情報や機密情報は入力しないでください。個人情報の取り扱い

Insights / 技術解説

Astroサイトのアクセシビリティ改善実践ガイド

Astroのアクセシビリティ改善は、問い合わせフォームなど利用者が完了したい操作から始めると優先順位を付けやすくなります。

  • 技術
  • Astro
  • アクセシビリティ
Astroサイトのアクセシビリティ改善実践ガイド
この記事の目次
  1. はじめに
  2. 装飾アイコンのaria-hidden
  3. 対処法
  4. 外部リンクのスクリーンリーダー通知
  5. 対処法
  6. コントラストの確保
  7. よくある問題
  8. 対処法
  9. focus-visibleスタイル
  10. UnoCSS での実装
  11. 忘れがちな要素
  12. インラインリンクの下線
  13. 対処法
  14. フォームのアクセシビリティ
  15. インライン検証
  16. 必須項目のマーク
  17. figure要素のrole属性
  18. リスト要素のrole属性
  19. その他の改善
  20. 画像のwidth/height属性
  21. Heroスライダーのaria-live
  22. dialogのaria-labelledby
  23. ページネーションのaria-current
  24. コピーボタンのaria-label更新
  25. まとめ
  26. この記事が含まれるシリーズ
  27. 補足:Tailwind CSS v4への移行でも操作性を検証する
  28. 2026年10月6日追記:認証ボタンと登録後の案内

Astroのアクセシビリティ改善は、問い合わせフォームなど利用者が完了したい操作から始めると優先順位を付けやすくなります。キーボードで入力、エラー修正、完了まで進み、ラベルと通知をW3C WAI: Forms Tutorialに照らして確認してください。本文の自動検査スコアとは別に、操作を完了できるかを検証します。

2026年9月26日追記: 本文のコードとPageSpeed Accessibility 100点は2026年3月のAstro + UnoCSS構成での記録です。現行の公式サイトの依存宣言はTailwind CSS 4.3.3です。ここに挙げた項目や自動検査の得点だけで、サイト全体のWCAG AA準拠を確認したとは言えません。準拠判定には対象ページと一連の操作を定め、A・AAの達成基準を自動検査と人手による検査の両方で確認する必要があります(W3Cの適合要件)。

はじめに

「アクセシビリティ対応」と聞くと、後回しにしがちな項目かもしれません。しかし実際に取り組んでみると、コントラスト・キーボード操作・フォーカス表示の改善はすべてのユーザーにとっての使いやすさ向上に直結します。

この記事では、Astro + UnoCSS サイトで PageSpeed Accessibility 100点を達成するために行った改善を、カテゴリ別に紹介します。

パフォーマンス・SEO・UX を含む全体像は、Astroサイトの品質改善ガイドでまとめています。


装飾アイコンのaria-hidden

UnoCSS の Iconify アイコン(i-lucide-*)は視覚的な装飾として使われることが多いですが、スクリーンリーダーが読み上げてしまうと「画像」「不明な画像」のように通知され、かえって混乱を招きます。

対処法

装飾目的のアイコンには aria-hidden="true" を付与します。

<span class="i-lucide-mail" aria-hidden="true"></span> お問い合わせ

サイト全体で30か所以上のアイコンにこの対応を実施しました。StatBar・Callout・ServiceCard・ProcessFigure など、コンポーネント内のアイコンも見落としがちなので注意が必要です。


外部リンクのスクリーンリーダー通知

target="_blank" で開く外部リンクは、視覚的には別タブで開くことが分かりますが、スクリーンリーダーのユーザーには伝わりません。

対処法

外部リンクに視覚的には非表示の補足テキストを追加します。

<a href="https://example.com" target="_blank" rel="noopener noreferrer">
  Example
  <span class="sr-only">(新しいタブで開きます)</span>
</a>

rehype-external-links プラグインを使えば、Markdown内の外部リンクにも自動で target="_blank" と rel を付与できます。SR通知テキストの追加はテンプレート側で行います。


コントラストの確保

PageSpeed Insights の指摘で最もよく出るのがコントラスト不足です。

よくある問題

UnoCSS のカラーパレットで text-slate-400 を使うと、白背景に対してコントラスト比が約3:1になり、WCAG AAの4.5:1基準を満たしません。

対処法

text-slate-400 → text-slate-500(コントラスト比4.6:1)に変更することで基準をクリアします。日付やキャプションなどの補助テキストに使いがちなので、サイト全体で確認しましょう。


focus-visibleスタイル

キーボードでサイトを操作するユーザーにとって、フォーカスインジケーターは「今どこにいるか」を知る唯一の手がかりです。WCAG 2.4.7ではフォーカス表示が要求されています。

UnoCSS での実装

ボタンやリンクに共通のフォーカススタイルを設定します。UnoCSS のショートカット機能を使えば、1箇所の定義で全体に適用できます。

shortcuts: {
  'ac-btn': '... focus-visible:ring-2 focus-visible:ring-brand-500 focus-visible:ring-offset-2 focus-visible:outline-none',
}

focus-visible は、マウスクリック時にはリングを表示せず、キーボード操作時のみ表示する疑似クラスです。focus よりもUXが良いため、こちらを使いましょう。

忘れがちな要素

  • コピーボタン
  • スクロールトップボタン
  • アンカー広告のクローズボタン
  • モーダルの閉じるボタン

インラインリンクの下線

PageSpeed には「リンクが色だけで識別可能」という指摘があります。色覚に制約のあるユーザーがリンクを見分けられない問題です。

対処法

ホバー時のみだった下線を常時表示にします。UnoCSS のショートカットで統一するのがおすすめです。

shortcuts: {
  'ac-link': 'underline decoration-brand-300 underline-offset-2 hover:decoration-brand-500 transition-colors',
}

フォームのアクセシビリティ

お問い合わせフォームなど、ユーザーが入力する場面ではアクセシビリティが特に重要になります。

インライン検証

blur / input イベントで即座にエラーメッセージを表示し、以下のaria属性を連携させます。

  • aria-invalid="true" ― 入力が無効であることを通知
  • aria-describedby ― エラーメッセージのIDを参照
<input type="email" aria-invalid="true" aria-describedby="email-error" />
<p id="email-error" role="alert">有効なメールアドレスを入力してください</p>

必須項目のマーク

視覚的な * マークだけでは不十分です。スクリーンリーダー向けの補足テキストを追加します。

<span aria-hidden="true">*</span> <span class="sr-only">(必須)</span>
フォームの表示・操作・通知を結び付ける 2026年3月時点の例に基づく関係図です。自動検査だけでWCAG全体への適合は示せません。
  1. 入力欄とlabel 入力欄には内容が分かるlabelを付け、必須であることも星印だけでなく読み上げ可能な補足で伝える。
  2. キーボード操作 focus-visibleで操作中の入力欄を示し、キーボードで到達して入力・修正できることを確認する。
  3. エラーを関連付けて通知 欄と文言をaria-invalid/aria-describedbyで結び、role=alertで通知する。自動・手動で確認する。

figure要素のrole属性

<figure> 要素に role="img" を設定すると、子要素がスクリーンリーダーから隠されてしまいます。アイコンや説明テキストを含むコンポーネント(InsightGrid・ProcessFigure・Timeline)では role="group" に変更し、内部コンテンツをアクセシブルに保ちます。


リスト要素のrole属性

CSSで list-style: none を設定すると、Safari のスクリーンリーダー(VoiceOver)がリストとして認識しなくなる既知のバグがあります。

パンくずリスト・サイドバー・フッターの <ol> / <ul> に role="list" を追加して対処します。見た目をカスタマイズしたすべてのリストで確認しましょう。


その他の改善

画像のwidth/height属性

width と height を明示していない画像は、読み込み完了時にレイアウトがずれる CLS(Cumulative Layout Shift)の原因になります。アバター画像(32×32、48×48、64×64px)やYouTubeサムネイル(480×360px)など、すべての画像にサイズを指定しましょう。

Heroスライダーのaria-live

自動切り替えスライダーは、スクリーンリーダーのユーザーには変化が伝わりません。aria-live="polite" 領域を用意し、「スライド 1 / 4: 〇〇」のようにテキストで通知します。

dialogのaria-labelledby

<dialog> 要素にはタイトル要素のIDを aria-labelledby で参照し、モーダルの目的をスクリーンリーダーが読み上げられるようにします。

ページネーションのaria-current

現在のページ番号に aria-current="page" を設定し、スクリーンリーダーで「現在のページ」であることを通知します。

コピーボタンのaria-label更新

クリップボードにコピー成功時、aria-label を「コピーしました」に動的に更新し、状態変化をスクリーンリーダーに通知します。


まとめ

アクセシビリティ改善は、一つひとつは小さな変更ですが、積み重ねることでサイト全体の品質が大きく向上します。特に効果が大きかったのは以下の3つです。

  1. focus-visibleの全体適用:キーボード操作でのナビゲーションが劇的に改善
  2. コントラスト比の修正:当時の白背景と通常テキストの組み合わせで、text-slate-400 → text-slate-500 に変更して4.5:1以上を確保
  3. 外部リンクのSR通知:rehype-external-links と組み合わせて全リンクを自動対応

まずは axe DevTools でサイトをスキャンし、自動検出できる問題から片付けていくのがおすすめです。


この記事が含まれるシリーズ

この記事は「Astroサイトの品質改善ガイド」シリーズの一部です。パフォーマンス・SEO・UXの改善についても個別の記事で紹介しています。

補足:Tailwind CSS v4への移行でも操作性を検証する

2026年9月30日追記。 Tailwind CSS v4へ移す際は、既存CSSリセットとPreflightの関係、CMSのアイコン、フォーカス表示、reduced-motionを移行後の本番でも確認してください。Preflightを無効化するかは既存スタイルに合わせて判断し、全サイト共通の推奨にはしません。

Tailwind v4 / Preflight

2026年10月6日追記:認証ボタンと登録後の案内

匿名化した改修では、認証providerの公式アイコンへの差し替えと、本番の表示を確認しました。読み上げで目的が分かる名前の確認は別の検証項目です。アイコンだけに依存せず、ボタンの名前、キーボードfocus、登録完了後に進める場所を確認します。

画面の案内やfocusの実装確認と、利用者が実際に登録を完了する受入は別です。この記録では実登録の通し検証と読み上げ試験は未確認で、全provider・全支援技術への適合を証明するものではありません。

アクセシビリティ改善の進め方

  1. 自動検査

    axe DevTools・Lighthouse で機械的に検出できる問題を洗い出す。

  2. 手動検査

    キーボード操作・スクリーンリーダーで実際に使ってみる。

  3. 修正

    aria属性の付与・コントラスト修正・フォーカススタイルの追加。

  4. 再検査

    PageSpeed の Accessibility スコアで100点を確認。

当時の改善項目

  • テキストのコントラスト比が4.5:1以上(大文字は3:1以上)
  • すべてのインタラクティブ要素にfocus-visibleスタイルがある
  • 装飾アイコンにaria-hidden="true"が付与されている
  • 外部リンクにスクリーンリーダー向け通知がある
  • フォームにインライン検証とaria-invalid連携がある
  • 画像にwidth/height属性がある(CLS防止)
  • リスト要素にrole="list"がある(list-style:none対策)

よくある質問

axe DevToolsとLighthouseの違いは何ですか?

Lighthouseはパフォーマンス・SEOも含む総合監査ツールで、アクセシビリティは一部の項目のみチェックします。axe DevToolsはアクセシビリティに特化し、より多くのルールで詳細に検査します。両方を併用するのがおすすめです。

aria属性はすべての要素に付けるべきですか?

いいえ。HTMLのセマンティクスが正しければariaは不要です。aria属性は「HTMLだけでは伝わらない情報」を補うためのもので、過剰に付けるとかえってスクリーンリーダーの読み上げが冗長になります。

PageSpeedのAccessibilityが100点ならWCAG準拠ですか?

100点でもWCAG完全準拠とは言い切れません。Lighthouseはチェック項目が限られており、手動でしか確認できない基準(論理的な読み上げ順序、適切なalt文言など)があります。自動テスト+手動テストの両方が必要です。