mcpField
P
progressive-enhancement

progressive-enhancement

github.com/mgifford開発57136 回インストール6 週間前に更新
リポジトリ

progressive-enhancement について

Web機能の開発や設計レビューに使うアクセシビリティスキルです。セマンティックHTMLで中核の内容と操作を成立させ、CSS、JavaScript、オフライン機能を段階的に追加する方法を扱います。

主な機能

  1. 01セマンティックHTMLで中核の内容と操作を確保
  2. 02CSSの表示とJavaScriptの操作を段階的に追加
  3. 03CSSのユーザー設定を尊重
  4. 04スクリプト失敗や動的コンテンツへの代替手段
  5. 05機能検出とサービスワーカーによるオフライン対応

活用シーン

  1. 01JavaScript無効時のページの利用可能性を確認
  2. 02JavaScriptなしで使えるフォームやナビゲーションを設計
  3. 03Webフレームワークのサーバーサイドレンダリングや静的生成を計画
  4. 04サービスワーカーのキャッシュとオフライン代替を設計

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/mgifford/accessibility-skills --skill progressive-enhancement

インストール後、Claude Code で/progressive-enhancementを入力して読み込まれたか確認します。

同梱ファイルSYNC.md

詳細

プログレッシブエンハンスメントのアクセシビリティスキル

正規の参照元:mgifford/ACCESSIBILITY.md の examples/PROGRESSIVE_ENHANCEMENT_BEST_PRACTICES.md このスキルはそのファイルを基にしています。判断に迷った場合は、例を正としてください。

Web 機能を構築する場合や、アーキテクチャの決定をレビューする場合は、以下のルールを適用してください。


基本方針

すべてのユーザーが使える確かな基盤から始め、そこに拡張機能を重ねていきます。 ブラウザーの機能、ネットワーク速度、支援技術、JavaScript の利用可否にかかわらず、 すべてのユーザーがコアコンテンツにアクセスし、主要なタスクを完了できなければ なりません。

プログレッシブエンハンスメントは、サステナビリティの実践でもあります。JavaScript なしで動作するページは大幅に軽量です。転送するバイト数が少なく、スクリプトの 解析や実行に使う CPU の負荷が低く、ページビューあたりのエネルギー消費も 少なくなります。SUSTAINABILITY.md と Web Sustainability Guidelines を 参照してください。


重大度の尺度(このスキル)

レベル意味
重大JS/CSS がないとコアコンテンツまたはタスクにアクセスできない
深刻コアコンテンツにはアクセスできるが、JS/CSS がないと大幅に機能が損なわれる
中程度拡張機能は適切に機能低下するが、操作に手間がかかる
軽微ベストプラクティスからの逸脱。影響はわずか

3 つのレイヤー

レイヤー 1 — セマンティック HTML(常に必須)

このレイヤーで問題が起きた場合は重大です。

  • コアコンテンツはすべてプレーン HTML で読み取れること — CSS や JS は不要
  • フォームはブラウザー標準の動作で送信できること
  • ナビゲーションは標準のリンクとして機能すること
  • 見出し、リスト、表、ランドマークが文書の構造を正確に反映していること
レイヤー 2 — CSS(表示を拡張)

このレイヤーで問題が起きた場合は中程度から深刻です。

  • コンテンツを失わずに無効化できる外部スタイルシートを使用すること
  • ユーザー設定を尊重すること:prefers-reduced-motion、prefers-color-scheme、 prefers-contrast、forced-colors
  • スタイルシートの読み込みに失敗してもページが使えること
レイヤー 3 — JavaScript(インタラクティビティを拡張)

コアコンテンツやタスクへのアクセスを制限する JS は重大です。

  • JS は機能を拡張するものであり、コアコンテンツやタスクへのアクセスを制限してはなりません
  • JS に依存するクラスや動作は、静的なマークアップではなくスクリプトで適用すること
  • スクリプトの読み込みに失敗しても適切に動作するようにすること — HTML レイヤーは引き続き機能しなければなりません
  • ブラウザー判定ではなく、機能検出を使用すること:
if ('fetch' in window && 'querySelector' in document) {
  // apply enhanced experience
}
レイヤー 3 の拡張 — Service Workers(オフライン機能)

Service Workers はレイヤー 3 の拡張機能です。JavaScript を必要とし、スクリプトによって 登録されるため、利用できない場合(プライベートブラウジング、未対応のブラウザー、 HTTPS が利用できない場合)にも適切に機能低下しなければなりません。

実装すると、アクセシビリティとサステナビリティの両方を向上させます。

  • アクセシビリティ:不安定な接続を利用するユーザー(農村部、低所得世帯、 発展途上地域に多く見られます)が、以前に読み込んだコンテンツにオフラインでも 引き続きアクセスできます
  • サステナビリティ:レスポンスをキャッシュすることでネットワークリクエストの 繰り返しをなくし、ページビューあたりのデータ転送量とサーバーのエネルギー消費を 削減できます
// Register Service Worker only if supported — classic PE feature detection
if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/sw.js').catch((err) => {
    // Registration failure: page continues to work normally without it
    console.warn('Service Worker registration failed:', err);
  });
}

オフライン時のフォールバックパターン:

// sw.js — cache-first with network fallback
const CACHE_NAME = 'v1';
const OFFLINE_URL = '/offline.html';

self.addEventListener('install', (event) => {
  event.waitUntil(
    caches.open(CACHE_NAME).then((cache) =>
      cache.addAll([OFFLINE_URL, '/', '/styles.css'])
    )
  );
});

self.addEventListener('fetch', (event) => {
  if (event.request.mode === 'navigate') {
    event.respondWith(
      fetch(event.request).catch(() => caches.match(OFFLINE_URL))
    );
  }
});

オフライン時のフォールバックページ(/offline.html)自体も、レイヤー 1 の要件を 満たす有効な HTML ドキュメントでなければなりません。セマンティックで、CSS や JS が なくても読み取れる必要があります。

Service Worker のキャッシュ戦略(cache-first、network-first、stale-while- revalidate)は、コンテンツの更新頻度に応じて選択してください。キャッシュ無効化の 計画なしに、頻繁に変更されるコンテンツへ古い情報を配信するキャッシュ戦略は 避けてください。


重大:コアコンテンツの表示に JavaScript を必須にしない

ページのコンテンツを JavaScript のみで描画するのは重大です。JS を無効にしているユーザー、互換性の問題に直面している支援技術(AT)のユーザー、低帯域幅のユーザーが完全に取り残されます。

  • サーバーから完全な HTML を配信し、ブラウザーでインタラクティブ機能をハイドレートします
  • コアコンテンツは初回の HTML レスポンスに含めます
  • React/Vue/Angular/Svelte を使用する場合は、SSR または静的生成を設定します
  • 表示可能なコンテンツの描画に JavaScript が必要となる SPA のパターンは避けます

コアコンテンツへのアクセスに不要な JavaScript は、どれも無駄なエネルギー消費です。サーバー側レンダリングを優先してください。HTML は一度転送すれば済みますが、JS バンドルの場合、コードはアクセスのたびに解析、コンパイル、実行する必要があります。


重大:フォームは JavaScript なしで動作させる


<form action="/search" method="get">
  <label for="query">Search</label>
  <input id="query" name="q" type="search">
  <button type="submit">Search</button>
</form>

即時結果、自動補完、インライン検証のために JS で機能を強化しつつ、 サーバーで処理するフォームをフォールバックとして維持します。

JS なしでは送信できないフォームは重大です。


重大:ナビゲーションは JavaScript なしで動作させる


<nav aria-label="Main">
  <ul>
    <li><a href="/about">About</a></li>
    <li><a href="/contact">Contact</a></li>
  </ul>
</nav>

ドロップダウンやアニメーション付きの遷移には JS で機能を強化します。


深刻:動的コンテンツにはフォールバック経路を用意する

if ('fetch' in window) {
  loadContentAsync(url);
} else {
  // Standard link navigation works automatically
}

aria-live 領域は、それなしでも基本コンテンツにアクセスできることを確認してから使用します。


中程度:CSS でユーザー設定を尊重する

prefers-reduced-motion、prefers-color-scheme、prefers-contrast、forced-colors はレイヤー 2 の責務です。これらを無視すると、少なくとも中程度の問題となります。高速または点滅するアニメーションで prefers-reduced-motion を無視すると、深刻な問題に達する可能性があります。


避けるべきこと

  • ページのコンテンツを JavaScript のみで描画する — 重大
  • HTML レイヤーで必要なコンテンツに display:none/visibility:hidden を設定する — 重大
  • サーバー側レンダリングのフォールバックなしで、ページ間の移動に JS を必須にする — 重大
  • user-scalable=no — 深刻(弱視ユーザーのズームを妨げます)
  • スクリプトが実行されると決めつける — 常に失敗時の状態に対応します
  • プログレッシブエンハンスメントの代わりにポリフィルを使う(ポリフィルは機能を補修しますが、PE は機能がない場合を前提に構築します)
  • サーバー側でレンダリングできる機能に大規模な JS バンドルを配信する — これはアクセシビリティ上のリスクであると同時に、持続可能性にもコストがかかります

完了の定義チェックリスト

  • JavaScript を無効にしてもコアコンテンツを読める
  • JavaScript を無効にしてもコアタスクを完了できる
  • フォームがブラウザー標準の動作で送信される
  • ナビゲーションが標準的な HTML リンクとして機能する
  • CSS が prefers-reduced-motion、prefers-color-scheme、prefers-contrast を尊重する
  • スクリプトの失敗に適切に対応する
  • ブラウザー検出ではなく機能検出を使用する
  • JS フレームワークで SSR または静的生成を設定する
  • 機能検出とサイレントな失敗処理を備えた Service Worker を登録する
  • オフライン用フォールバックページが有効なレイヤー 1 HTML である
  • キャッシュ戦略を文書化し、コンテンツの更新頻度に合わせる
  • テスト済み:JS を無効にしてコアコンテンツを確認する。CSS を無効にして論理的な読み上げ順序を確認する

主な WCAG 基準

  • 2.1.1 キーボード(A)— ネイティブ要素にはキーボード操作のサポートが組み込まれています
  • 4.1.2 名前、役割、値(A)

注: WCAG 4.1.1「構文解析」は、2023 年 8 月の WCAG 2.2 で削除されました。 最新のブラウザーは構文解析エラーを一貫して処理します。プログレッシブエンハンスメントの基盤として、有効なセマンティック HTML は引き続き重要ですが、テスト可能な WCAG 基準ではなくなりました。監査やコンプライアンスに関する声明で引用しないでください。


参考資料

標準の動向: WCAG 3.0 は策定中です。プログレッシブエンハンスメントの原則に 破壊的な変更が加えられる予定はありません。 最新情報:https://www.w3.org/TR/wcag-3.0/

コメント