Web制作のa11y対応は「着工前」で決まる｜職種別ルールと失敗しない合意形成

納品の直前に「コントラストが足りない」「キーボードでメニューが閉じられない」「alt が空」と指摘が入る。デザインは確定済み、コーディングも終盤、公開日は動かない。直せる箇所と、作り直しになる箇所が混ざり、現場の温度だけが上がります。

アクセシビリティ（a11y）の手戻りは、実装スキル不足だけで起きません。着工前に、どこまでを対象にし、誰が何を担保するかを決めていないときに起きます。ルールが無いと、デザイナーは見た目、エンジニアは動くこと、ディレクターは納期を優先し、検証は最後に回ります。最後に回した検証は、ほぼ修正指示になります。

この記事では、フリーランスのWebディレクター兼エンジニアとして、企画から HTML / CSS / JavaScript、Next.js、WordPress、microCMS まで見てきた立場から、作業に入る前に決めておく職種別ルールと、クライアントとの合意の取り方を整理します。「着工前の決め方が、あとの手戻りの大半を決める」という前提です。数値の調査結果ではなく、制作工程で何度も同じ失敗を見たうえでの実務の感覚です。

読み終えるころには、キックオフで渡せるチェック項目と、職種ごとの最低ラインが手元に残るようにします。

なぜ「作業に入る前」の共通言語化が必要なのか

アクセシビリティ対応は、仕上げの装飾ではありません。情報設計、色、コンポーネント、HTML の役割、CMS の入力欄まで、工程を横断します。共通言語が無いと、同じ「対応する」でも中身がずれます。

WCAG 2.2 と JIS X 8341-3 を混同しない

現場でよく出る言葉を、先に分けます。

• WCAG 2.2: W3C のウェブコンテンツ・アクセシビリティ・ガイドラインです。2023年10月5日に勧告されています。達成基準にはレベル A / AA / AAA があります。民間の制作では レベル AA を目標にすることが多いです。
• JIS X 8341-3:2016: 日本産業規格です。内容は WCAG 2.0 を基にしています。官公庁や公共性の高い案件では、この規格のレベル AA 準拠を仕様書に書かれることがあります。

つまり、「JIS 準拠」と書いただけでは、WCAG 2.2 の新しい達成基準（ターゲットサイズ、ドラッグ操作の代替、フォーカスが隠れない、など）まで含むとは限りません。逆に、WCAG 2.2 AA で作っておけば、JIS X 8341-3:2016 AA の要求はカバーしやすい、という関係です。

着工前に決めるべきなのは、次の一文です。

このサイトは、どの文書の、どのレベルまでを対象にするか。検証の範囲に、外部埋め込み（地図、動画、チャット、同意バナー）を含めるか。

これを曖昧にしたまま「アクセシビリティ対応」と見積もると、終盤で対象が膨らみます。

共通言語が無いと、職種ごとに別の正解が走る

• ディレクター: 仕様書の「準拠」という言葉を、検査証明書まで含むと読むことがある
• デザイナー: ブランドカラーを守ることが先で、コントラストは後回しになりやすい
• エンジニア: 見た目が再現できればよく、見出し階層やボタンの要素は後で直すつもりになる

後で直すつもりが、デザインデータの再書き出しと、コンポーネント全置換になります。着工前に「AA のどの項目を必須にするか」を共有する方が、総工数は小さくなります。

失敗事例と成功事例：同じ「a11y対応」でも工程が違う

固有の企業名や架空の案件は出しません。制作現場で繰り返し見る型です。

失敗：デザイン確定後・納品直前に検証する

あるコーポレートサイトでは、メインカラーをブランド指定のまま全面に使い、ボタン文字が薄いグレーでした。コーディング完了後にコントラストを測ると、通常テキストの 4.5:1 に届かない。差し替えは「色を変える」だけでは済みません。ホバー、無効時、見出し、図中の文字まで再計算が入ります。

同じ案件で、メガメニューが div と mouseenter だけで組まれていました。キーボードでは開けず、Esc でも閉じられません。納品1週間前の指摘は、コンポーネントの作り直しです。見た目の確認用に outline: none; を当てていたため、フォーカス位置も分かりませんでした。

失敗の共通点は明確です。

• 準拠レベルと対象外を、見積もり時点で書いていない
• コントラストとフォーカスの見た目を、デザインカンプの合格条件にしていない
• キーボード操作を、実装の完了条件にしていない
• 代替テキストを、CMS の必須項目にしていない

成功：キックオフで対象・除外・職種別の合格条件を書く

うまくいった現場では、キックオフ資料に次を1枚で載せています。

• 目標: WCAG 2.2 レベル AA（JIS X 8341-3:2016 AA の要求も満たす方針）
• 対象: 制作する全 HTML。PDF は対象外、または主要3点のみ
• 除外: YouTube 埋め込み、Google マップ、第三者の同意管理バナー（代替手段を本文で案内）
• デザイン合格: 通常テキスト 4.5:1、大きなテキストと UI 部品 3:1、フォーカスリングの色と太さをカンプに描く
• 実装合格: キーボードだけで主要導線が完了する。装飾目的の ARIA を増やさない
• 運用: 画像の alt、リンクテキストを CMS で入力しないと公開できない

この1枚があると、終盤の指摘は「仕様の漏れ」ではなく「実装のバグ」になります。バグは直せる。仕様の漏れは、工程を巻き戻します。

【職種別】作業に入る前に最低限決めておくポイント

ディレクター：レベル、対象範囲、検査のゴール

決めることは3つです。

1. 準拠の文書とレベル（例: WCAG 2.2 AA を作業基準とし、発注仕様が JIS X 8341-3:2016 AA なら差分を明示する）
2. 対象と対象外（埋め込み、PDF、過去記事、会員ページ）
3. 検証のゴール（自社チェックでリリースするのか、第三者レビューが必要なのか）

「対応します」だけでは見積もれません。対象外を書かないと、終盤に地図ウィジェットまで修正対象になります。地図を除外するなら、住所と公共交通の案内をテキストで出す、といった代替を先に提案します。

ミニ事例です。公共性の高いサイトで「準拠」とだけ書いて着工し、終盤に試験結果の提出を求められた、という型があります。試験そのものが悪いのではなく、試験の有無を契約前に書いていなかったことが手戻りになります。着工前に「チェックリストによる自己宣言」なのか「試験」なのかを分けてください。

デザイナー：コントラストとフォーカスを、カンプの合格条件にする

色はブランドの話であると同時に、WCAG の達成基準でもあります。

• 通常テキスト: コントラスト比 4.5:1（1.4.3）
• 18pt 相当以上、または太字の 14pt 相当以上: 3:1
• アイコンや入力の枠など、識別に必要な UI: 3:1（1.4.11）

「メインカラーを薄く乗せる」は、見た目では通っても AA では落ちます。着工前に、メイン・サブ・無効・背景の組み合わせを表にし、測った値を残します。測るツールは WebAIM Contrast Checker など、コントラスト比が数値で出るもので十分です。

フォーカスリングもデザインです。outline を消したまま代替が無い状態は、キーボード利用者に現在地を渡しません。カンプに「フォーカス時は 2px の実線、背景とのコントラスト 3:1 以上」と書いておくと、エンジニアが outline: none; だけで済ませられません。

ミニ事例です。ヒーローの上に白い文字を置くために、写真を暗くする処理をデザインで持っておく。実装側で画像が変わり、文字が読めなくなる、という事故は、テキストと画像の関係をデザインルールにしていないときに起きます。

エンジニア：先に HTML の役割を決め、ARIA は足りないときだけ足す

実装前に合意したいのは、次です。

• 見出しは飛ばさない（h1 の次が h3 にならない）
• ボタンは button、リンクは a[href]。クリック用の div を増やさない
• フォームは label と id を組にする
• キーボードだけで、メニュー・モーダル・スライダーが操作できる
• WAI-ARIA は、ネイティブ HTML で足りない状態にだけ使う

悪い例です。見た目はボタンでも、役割がありません。

<div class="btn" onclick="submitForm()">送信</div>

改善例です。名前もキーボード操作も、要素が担います。

<button type="submit">送信</button>

メニューの開閉は、状態を ARIA で補います。見た目のクラスだけにしないのがポイントです。

<button
  type="button"
  aria-expanded="false"
  aria-controls="global-menu"
>
  メニュー
</button>
<nav id="global-menu" hidden>
  <ul>
    <li><a href="/about/">私たちについて</a></li>
  </ul>
</nav>

const button = document.querySelector("[aria-controls='global-menu']");
const menu = document.getElementById("global-menu");

button.addEventListener("click", () => {
  const open = button.getAttribute("aria-expanded") === "true";
  button.setAttribute("aria-expanded", String(!open));
  menu.hidden = open;
});

モーダルでは、フォーカスを中に閉じ込め、閉じたら開く前の要素へ戻します。ここを着工前に「コンポーネントの必須仕様」にしておかないと、納品前のチェックで一気に発覚します。

ミニ事例です。スライダーを「自動再生・ドラッグのみ」で作ると、WCAG 2.2 のドラッグ操作の代替（2.5.7）やターゲットサイズ（2.5.8）で詰まります。着工前に「矢印ボタンでも同じ操作ができる」と書いておけば、ライブラリ選定の段階で除外できます。

クライアントは知らない。制作者側が先に提案する

発注者が a11y の用語を知らないことは、責める対象ではありません。知らない前提で、誤解と運用を先に潰します。

「対応するとダサくなる」は、ルール不足のときに起きる

コントラストを後付けで上げると、ブランドから離れた色が増えます。最初から AA で通る色をブランドの正規色にする方が、見た目は安定します。フォーカスリングも、サイトのアクセント色で設計すれば「ブラウザの点線が残った」印象にはなりません。ダサさの原因はアクセシビリティそのものより、終盤の応急処置です。

CMS で alt を空のまま公開できないようにする

WordPress でも microCMS でも、アイキャッチや本文画像の代替テキストは運用者の入力です。実装が正しくても、空の alt が量産されると達成基準を満たしません。着工前に次を提案します。

• 意味のある画像: alt 必須
• 装飾画像: 空の alt を意図して使う（alt 未入力とは分ける）
• 公開フローで未入力をはじく、またはチェックリストに入れる

方針ページを、最初から情報設計に入れる

「アクセシビリティ方針」や対応状況のページは、公共案件で求められることがあります。民間でも、対象範囲と目標レベル、フィードバック窓口を1ページにまとめておくと、問い合わせ対応が楽です。着工後にページを足すと、グローバルナビとフッターの再調整が入ります。トップの情報量が増える前に、置き場所だけ決めておきます。

提案の型は短くて構いません。

• 目標レベル
• 対象範囲と除外
• 検証方法（ブラウザ、スクリーンリーダーの有無は、できる範囲で正直に書く）
• 改善の連絡先

できない検査を「対応済み」と書かないことが、信頼につながります。

現場で使える着工前 a11y チェックシート

キックオフで印刷するか、チケットの説明文に貼って使います。全部を一度に「必須」にしなくて構いません。今回の案件で必須にする行だけ、合意欄を埋めます。

任意を全部必須にすると、見積もりが破綻します。公共案件と、採用サイトでは行の選び方が違ってよいはずです。

まとめ：a11y は、実装の前に合意する

Webサイトのアクセシビリティ対応で高いのは、終盤の指摘そのものより、指摘を受けてから色とコンポーネントを作り直すコストです。着工前に、準拠レベル、対象外、コントラスト、フォーカス、キーボード、CMS の alt を職種ごとに決める。クライアントには「ダサくなる」ではなく「後付けが見た目を崩す」と説明する。これで、制作工程の手戻りはかなり減ります。

• 文書とレベルを、WCAG 2.2 と JIS で混同しない
• 失敗は納品前検証、成功はキックオフの1枚
• デザイナーは数値、エンジニアは要素とキーボード
• 運用の alt と方針ページは、制作者から提案する

既存サイトの改修でも、まずは対象ページと必須行だけ決めてから計測してください。全ページ一括は、合意が無いと止まります。

制作工程への組み込みや、既存サイトの点検方針を整理したい場合は、相談・お問い合わせからどうぞ。デザイン確定後でも、次の改修範囲を切るところから一緒に考えられます。