ウェブアクセシビリティとは、目が見えにくい人、マウスが使えない人、音が聞こえない人など、さまざまな条件の人が同じように使える状態にすることです。

対応項目の一覧はいろいろな所で見られますが、並べただけでは進みません。項目ごとに手を動かす人が違うからです。コントラストはデザインで決める話で、コーディングでは直せません。逆にキーボード操作はコーディングの話で、デザインカンプには現れません。

この記事では、デザインの領域・コーディングの領域・原稿と運用の領域に分けて整理します。発注する側も、どちらに依頼する話なのかが分かります。

法令の位置づけ

2024年4月の改正により、民間事業者にも合理的配慮の提供が義務づけられました。ウェブサイトを特定の基準に準拠させること自体が義務になったわけではありませんが、情報が受け取れないという申し出に対応できる状態にしておく必要があります。

基準としては JIS X 8341-3、その元になっている WCAG が使われます。公共系の案件では、等級AA相当を求められることがあります。

「対応しました」と言うには試験と報告が必要です。そこまで求められていない案件で、言葉だけ先に使わないよう注意してください。

担当の切り分け

主な項目を、どちらの領域の仕事かで並べます。多くの項目は両方にまたがっていて、デザインで決めたことをコーディングで壊さない、という関係になっています。

デザインの領域

ここで決めたことが、後の工程の上限になります。コーディングで取り返せないので、カンプの段階で押さえる価値がいちばん高い部分です。

1. コントラストを確保する

本文は文字色と背景色の比が 4.5対1 以上、大きな文字（およそ24px以上、または太字で19px以上）は 3対1 以上が基準です。薄いグレーの細い文字は、軽く見えますが明るい場所では読めません。

• 本文のグレーは #767676 あたりが白背景での限界
• キーカラーの上に白文字を置く場合も測る（黄色や水色は通らないことが多い）
• プレースホルダー、補足文、日付などの小さい文字こそ測る
• 画像の上に文字を置く場合は、帯や暗さを重ねて確保する

コントラスト比はツールで測れます。デザインツールの拡張機能でも確認できるので、配色を決める時点で測ってください。実装後に指摘されると、配色全体の作り直しになります。

2. 文字の大きさと余白

本文は16px相当を基準にします。また、文字サイズを200%に拡大しても内容が失われない設計が求められます。枠にぴったり収まる文字数で作ると、少し大きくするだけで崩れます。行間と余白に余裕を持たせてください。

3. 色だけで意味を伝えない

必須項目を赤文字だけで示す、グラフを色だけで区別する、エラーを枠線の色だけで示す。こうした作りは、色の見分けがつきにくい人に伝わりません。

• 必須には「必須」の文字を添える
• グラフは凡例だけでなく、線の形や直接のラベルで区別する
• エラーは色に加えてアイコンと文章を出す

4. 押せるものが押せると分かる形にする

ボタンなのか見出しなのか分からない装飾、下線の無いテキストリンクは迷わせます。また、キーボードで操作しているときに「いまどこにいるか」を示す見た目（フォーカスの状態）も、デザインの段階で用意してください。無いと、実装者が勝手に決めるか、消されます。

タップできる領域は 44px 程度を目安にします。アイコンだけのボタンを小さく並べると、指では押せません。

5. 読む順序を決める

左右に要素を散らしたレイアウトは、どの順に読むのかが曖昧になります。スクリーンリーダーは上から順に読み上げるので、見た目の配置と読む順序がずれると意味が通らなくなります。スマホの1列の並びを先に決めておくと、この順序が自然に決まります。

コーディングの領域

デザインで決まったことを、機械にも伝わる形で実装する工程です。ここは見た目に出ないので、指摘されるまで気づかれません。

1. 見出しとランドマークを正しく使う

スクリーンリーダーの利用者は、見出しや領域（header・nav・main・footer）を頼りにページ内を移動します。ここが div のままだと、上から全部を読み上げるしかなくなります。

<header>…</header>
<nav aria-label="サイト内">…</nav>
<main>
  <h1>ページの主題</h1>
  <h2>大きな話題</h2>
  <h3>その中の小さな話題</h3>
</main>
<footer>…</footer>

h1 は1ページに1つ。文字を大きくしたいから h2 にする、という選び方をすると構造が壊れます。大きさはCSSで決めてください。

2. 画像の代替テキスト

意味のある画像には、何を伝えている画像かを短く書きます。装飾のための画像は alt を空にして、読み上げさせません。ファイル名をそのまま入れるのは意味がありません。

<!-- 意味のある画像 -->
<img src="graph.png" alt="2026年の売上は前年比120%">

<!-- 装飾の画像 (読み上げさせない) -->
<img src="deco.svg" alt="">

alt 属性そのものを書かないのと、空で書くのは別の意味になります。書かない場合、読み上げソフトはファイル名を読むことがあります。装飾なら必ず alt="" と書いてください。

3. キーボードで操作できるようにする

Tabキーで順番に移動できるか、いまどこにいるかが見えるか、Enterやスペースで押せるかを確認します。よくある失敗は、フォーカスの枠をデザイン上の理由で消してしまうことです。

/* これは絶対にやらない */
*:focus { outline: none; }

/* キーボード操作のときだけ枠を出す */
:focus-visible {
  outline: 2px solid #1ba66a;
  outline-offset: 2px;
}

もう一つ多いのが、div にクリックイベントを付けてボタンの代わりにすることです。見た目は同じでも、Tabで到達できず、Enterでも反応しません。押すものは button、移動するものは a を使ってください。

4. フォームの項目名を結びつける

label の for と入力欄の id を合わせます。これだけで、読み上げソフトが「お名前の入力欄」と伝えられ、ラベルをクリックしても入力欄が選択されるようになります。

<label for="name">お名前<span aria-hidden="true">*</span><span class="req">必須</span></label>
<input id="name" name="name" type="text" required
       aria-describedby="name-error" aria-invalid="true">
<p id="name-error">お名前を入力してください</p>

プレースホルダーだけで済ませると、入力を始めた時点で何の欄か分からなくなります。ラベルは必ず置いてください。エラーは aria-describedby で入力欄に結びつけると、読み上げでも内容が伝わります。

5. アイコンだけのボタンに名前を付ける

中身がアイコンだけのボタンは、読み上げソフトから見ると名前のないボタンです。何のボタンか分かりません。

<button type="button" aria-label="メニューを開く">
  <i class="fa-solid fa-bars" aria-hidden="true"></i>
</button>

aria-* は足せば良くなるものではありません。正しいタグで済むところに付けると、かえって伝わらなくなります。button があるのに div に role="button" を付ける、といった使い方は避けてください。まず正しいタグ、足りないときだけ aria です。

6. 動きを減らす設定に対応する

動きで体調が悪くなる人がいます。OSの「視差効果を減らす」設定を見て、大きな動きを止めます。

@media (prefers-reduced-motion: reduce) {
  *,
  *::before,
  *::after {
    animation-duration: .01ms !important;
    transition-duration: .01ms !important;
    scroll-behavior: auto !important;
  }
}

7. 細かいが効くもの

• html の lang 属性を ja にする（読み上げの言語が切り替わります）
• ページごとに違う title を付ける
• 本文の先頭へ飛ぶスキップリンクを置く（毎回ナビを読み上げさせない）
• 表は th と scope を使う
• 自動再生する動画や音声を置かない
• 文字を画像にしない（拡大すると荒れ、読み上げもできません）

原稿と運用の領域

デザインもコーディングも正しくても、運用で崩れる部分があります。ここは記事を書く人の仕事です。

• 画像を入れるときに代替テキストを書く（WordPressのメディア画面で入れられます）
• リンクの文字を「こちら」「詳細はこちら」にしない。何のリンクか書く
• 見出しを大きさのために選ばない（エディタの見出し2、見出し3を順に使う）
• PDFだけで情報を配らない。HTMLのページも用意する

納品時に整っていても、記事が増えるうちに崩れます。運用する人に、この4つだけでも共有しておくと保てます。

確認のしかた

1. マウスを使わず、Tabキーだけで全部の操作ができるか試す
2. ブラウザで200%に拡大して、内容が欠けないか見る
3. コントラストをツールで測る
4. ブラウザの検査ツール（Lighthouse など）で自動チェックをかける
5. 読み上げソフトで主要なページを聞く（Macなら VoiceOver、Windowsなら ナレーター）

1番だけでも、かなりの問題が見つかります。自動チェックは機械的に分かる部分しか見ないので、通っていても手で確認してください。

やって損がない

ここに挙げた項目は、どれも検索エンジンへの伝わりやすさや、一般の使いやすさにもそのまま効きます。見出しの構造や alt は構造化データや検索結果の理解に直結し、キーボード操作やタップ領域の確保は、単純に使いやすいサイトの条件です。

特別な作業として切り出すより、普通の制作品質として組み込むほうが無理がありません。

範囲を決めてお見積りします

当社では、構造の通ったHTML・キーボード操作・フォーカスの見た目・フォームのラベルを標準の制作範囲として押さえています。デザインを他社が担当される場合も、配色のコントラストやフォーカスの見た目について、実装前に確認のうえ進めます。

等級AA相当の対応や、試験と報告書が必要な案件についても、範囲を決めたうえでお見積りします。まず現状のサイトで何が足りていないかを調べたい、というご相談も承っています。