Web・アプリ

1. 知覚

1.1 色

避ける色の組み合わせ

必須 次の組み合わせで情報を区別しない。右3列は、左の2色がP型・D型の色覚でどう見えるかを示すシミュレーションである。〔WCAG 1.4.1、川崎市カラーUDガイドライン、国交省バリアフリー整備ガイドライン、伝わるデザイン〕

シミュレーションはMachadoら（2009）の2色覚モデル（強度）で算出した。実際の見え方には個人差がある。

高齢者（白内障）で見分けにくい組み合わせ

文字色と背景色の組み合わせ

必須 明度差のない文字と背景、混同しやすい色同士の文字と背景を使わない。色背景の上に色文字を重ねず、明るい背景には暗い文字、暗い背景には明るい文字を置く。〔WCAG 1.4.3、川崎市カラーUDガイドライン〕

色の選び方

• 赤は濃い赤ではなく、朱色やオレンジ寄りの赤を使う。〔川崎市カラーUDガイドライン〕
• 赤や茶と並べる緑は、青みの強い緑にする。〔川崎市カラーUDガイドライン〕
• 彩度の低いパステル調の色同士を組み合わせない。彩度の高い色同士か、彩度の高い色と低い色を組み合わせる。〔川崎市カラーUDガイドライン〕
• 暖色同士・寒色同士を並べず、暖色と寒色を組み合わせる。〔伝わるデザイン〕
• 3色を使うときは、明るい色・中間の色・暗い色を1つずつ選んで明度差をつける。
• 色数を絞る。多くの色を使うと、どこが重要かが誰にも伝わらなくなる。〔川崎市カラーUDガイドライン〕
• 赤い面を他の色と接するときは、境目に細い白線を入れる。〔国交省バリアフリー整備ガイドライン〕
• 色で区別させたいものは、面積を広く、線を太くする。〔川崎市カラーUDガイドライン〕
• 色名で指示される可能性がある場合は、色名を併記する（例：「ピンク（A票）」）。〔川崎市カラーUDガイドライン〕

色だけに頼らない

必須 色は情報を補強する手段として使う。色が見分けられない人や白黒コピーでも伝わるよう、次のいずれかを併用する。〔川崎市カラーUDガイドライン、WCAG 1.4.1〕

• 形（○△□、ピクトグラム、アイコン）
• 位置（凡例をデータの横に置く、並び順を固定する）
• 線種（実線・破線・点線）と線の太さ
• 塗りのパターン（斜線・ドット・ハッチング）
• 文字（ラベル、「必須」「エラー」などの言葉、太字、下線）
• 境界線（隣り合う面の間の線）

推奨カラーパレット

CUD推奨配色セット ver.4（カラーユニバーサルデザイン機構）は、一般色覚・P型・D型・弱視・白内障の人による評価を経て選ばれた20色である。20色のどの組み合わせでもよいわけではない。組み合わせるときは明度差をつけ、シミュレーションで確認する。

CUD推奨配色セット：アクセントカラー（サイン・グラフ・文字色向け）

CUD推奨配色セット：ベースカラー（地図・背景など広い面積向け）

CUD推奨配色セット：無彩色

印刷用のCMYK値と塗料用のマンセル値は、CUDOのガイドブックに記載されている。

Okabe–Ito パレット（国際的に使われる8色）

必須 どちらのパレットも、白背景の文字色に使うと4.5:1に届かない色が多い。文字色に使う場合は、個別にコントラスト比を確認する。〔WCAG 1.4.3〕

確認方法

• グレースケールに変換し、区別すべき要素が明度差だけで区別できるか確認する。
• 色覚シミュレーション（P型・D型）で確認する。ブラウザの開発者ツール（ChromeのRendering › Emulate vision deficiencies）、Adobe製品の校正設定（P型・D型）、スマートフォンの色覚シミュレーションアプリを使う。

Web・アプリ固有のルール

• 必須 本文中のリンクを、色だけで周囲の文字と区別しない。下線を付けるのが確実である。〔WCAG 1.4.1（A）〕
  ✕ 色だけでリンクを区別

  申し込みの前に、料金表と利用規約を確認してください。

  色の違いがわからないと、どこがリンクか気づけない。

  ◯ 下線を付ける

  申し込みの前に、料金表と利用規約を確認してください。

  下線でリンクであることが伝わる。

• 必須 入力エラーを赤枠だけで示さない。アイコンとエラー文を併記する。〔WCAG 1.4.1（A）、3.3.1（A）〕
  ✕ 赤い枠だけでエラーを示す

  メールアドレスyamada.example.com

  何が誤りかわからない。赤の枠に気づけない人もいる。

  ◯ アイコンとエラー文を添える

  メールアドレスyamada.example.com⚠ 「@」が含まれていません。例：yamada@example.com

  誤りの内容と直し方が文字で伝わる。

• 必須 選択中のタブ・現在のページ・オンオフの状態を、色の違いだけで示さない。太字・下線・アイコン・チェック記号を併用する。〔WCAG 1.4.1（A）〕
  ✕ 選択中のタブを色だけで示す

  概要料金よくある質問

  どのタブが選ばれているか区別できない。

  ◯ 太字と下線を加える

  概要料金よくある質問

  色が見えなくても、太字と下線で選択中とわかる。

• グラフやゲームの配色を、利用者が変更できるようにする。〔Apple HIG〕
• OSの「コントラストを上げる」設定がオンのとき、よりコントラストの高い配色に切り替える。〔Apple HIG〕
• システム定義の色（iOSのsystemRedなど）を使う。コントラスト設定やダークモードに合わせて自動で調整される。〔Apple HIG〕
• Windowsの強制カラーモード（CSSのforced-colors）で、ボタンの境界やアイコンが消えないようにする。

1.2 コントラスト

コントラスト比はWCAGの相対輝度に基づく値で、1:1（同じ色）から21:1（白と黒）までの値をとる。Webの基準であるが、他の媒体でも判断の目安として使える。

• 必須 写真やグラデーションの上に文字を置くときは、文字の背後に単色の帯や縁取りを入れ、背景の最も明るい部分でも基準を満たす。〔WCAG 1.4.3〕
• 長文の本文は、純黒（#000）より濃いグレー（#1A1A1A〜#333）、背景は純白より淡いグレーやクリームにすると、まぶしさが減る。〔伝わるデザイン〕
• コントラスト比は、WebAIM Contrast Checker、Colour Contrast Analyser（TPGi）などのツールで確認する。

Web・アプリ固有のルール

• 必須 ダークモードなど複数の配色を用意する場合は、どの配色でもコントラストの基準を満たす。〔WCAG 1.4.3（AA）、Apple HIG〕

1.3 文字

文字サイズ

• 必須 ロゴなどを除き、文字を画像にしない。画像の文字は拡大・読み上げ・翻訳ができない。〔WCAG 1.4.5（AA）〕
• 文字サイズは相対単位で指定する（Webはrem・em、Androidはsp）。利用者の設定で拡大できるようになる。

書体と組版の共通ルール

• 小さな文字や遠くから読む文字は、ゴシック体（サンセリフ体）にする。明朝体の細い横線は、視力の低い人には見えにくい。〔伝わるデザイン〕
• UDフォント（BIZ UDゴシック、BIZ UD明朝、イワタUDゴシック、モリサワUD新ゴなど）は、濁点・半濁点や似た字形が判別しやすい。BIZ UDゴシック・BIZ UD明朝は無料で使える。〔伝わるデザイン〕
• 過度な長体（縦長の変形）や極細のウェイトを使わない。細いウェイトを使う場合は、文字を大きくする。〔国交省バリアフリー整備ガイドライン、Apple HIG〕
• 欧文の全大文字・長いイタリック・装飾書体を本文に使わない。〔Microsoft〕
• 行送りは文字サイズの1.5倍以上にする。〔WCAG 1.4.8（AAA）〕 紙やスライドでは、行間を文字サイズの約0.7倍（行送り約1.7倍）にすると読みやすい。〔伝わるデザイン〕
• 左揃えを基本にする。センタリングを混在させず、揃え方を統一する。〔伝わるデザイン〕
• 両端揃えで字間が不均一になる場合は、左揃えにする。〔WCAG 1.4.8（AAA）〕
• 1行の長さは全角40字以内にする。〔WCAG 1.4.8（AAA）〕 1行が10字以下になると読みにくい。〔伝わるデザイン〕
• 強調は太字を使い、下線はリンクや重要箇所に限る。赤文字だけで強調しない。〔川崎市カラーUDガイドライン〕

1.4 図・アイコン・画像

• 必須 意味のある画像に、内容を説明する代替テキストを付ける。〔WCAG 1.1.1（A）〕
• 必須 装飾だけの画像は、支援技術が読み上げないようにする。Webはalt=""、AndroidはcontentDescriptionにnullを渡す。〔WCAG 1.1.1（A）、Android Developers〕
• 必須 アイコンだけのボタンには、機能を表す名前（アクセシブルネーム）を付ける。〔WCAG 4.1.2（A）〕
• 必須 見えるラベルの文字列を、アクセシブルネームに含める。音声操作で「送信」と言えば押せるようにする。〔WCAG 2.5.3（A）〕
• 必須 グラフや図は、代替テキストで要点を伝える。詳細なデータは表やテキストでも提供する。〔WCAG 1.1.1（A）〕
• 必須 画像認証（CAPTCHA）には、音声など別の方式を用意する。〔WCAG 1.1.1（A）〕
• アイコンだけのボタンには、見えるラベルも併記する。
• 説明には見た目ではなく、操作の目的と結果を書く。種類（ボタンなど）はロール属性で伝え、説明文に「ボタン」と書かない。〔Android Developers〕
• リスト内の各項目の説明は、項目ごとに固有にする（例：都市名を含める）。〔Android Developers〕
• OSやデザインシステムの標準アイコンを使い、同じ意味のアイコンを全画面で統一する。

1.5 レイアウト

• 必須 読み上げの順序（DOMの順序）を、見た目の順序と一致させる。〔WCAG 1.3.2（A）〕
• 必須 縦向き・横向きのどちらでも使えるようにする。〔WCAG 1.3.4（AA）〕
• 必須 見出し・リスト・表・フォームのラベルを、HTMLの要素やOSのセマンティクスで正しく表す。見出しは階層を正しく使う。スクリーンリーダーの利用者は見出しで移動する。〔WCAG 1.3.1（A）〕
• 必須 固定ヘッダーやバナーで、フォーカスした要素を完全に隠さない。〔WCAG 2.4.11（AA）〕
• 必須 ホバー・フォーカスで表示される内容（ツールチップなど）は、Escキーで消せる、ポインタを載せても消えない、利用者が閉じるまで残る、の3条件を満たす。〔WCAG 1.4.13（AA）〕
• 関連する要素を近くにまとめ、グループの間に余白をとる。
• 入力欄のラベルは、入力欄の上か左に近接して置く。
• 見出しは左上に置く。〔伝わるデザイン〕
• 認知的な負担を減らす場合は、1画面で1つの操作に絞り、多段階の手続きを画面ごとに分ける。〔Apple HIG〕

1.6 動き・点滅

• 必須 1秒間に3回を超えて閃光を出さない。光過敏性発作を防ぐためである。〔WCAG 2.3.1（A）〕
• 必須 5秒を超えて自動で動く・スクロールする・点滅する内容は、一時停止・停止・非表示にできるようにする。〔WCAG 2.2.2（A）〕
• OSの「視差効果を減らす」設定（CSSのprefers-reduced-motion）がオンのとき、自動・反復のアニメーションを減らす。〔Apple HIG〕
• 動きを減らす具体策として、弾むアニメーションを抑える、奥行き方向の動きをやめる、移動をフェードに置き換える、ぼかしのアニメーションを避ける。〔Apple HIG〕
• 操作をきっかけにしたアニメーションは、無効にできるようにする。〔WCAG 2.3.3（AAA）〕
• 動画や音声を自動再生しない。自動再生する場合は、見つけやすい停止手段を用意する。〔Apple HIG〕
• 動画再生では、iOSの「光の点滅を抑える」設定に対応する。〔Apple HIG〕

1.7 光・照明

• 光に敏感な人のために、ダークモードに対応する。〔Apple HIG〕
• 全面の白や高輝度の色の面を、急に表示しない。

1.8 音

• 必須 操作の説明を、音だけに頼って伝えない（例：「ビープ音が鳴ったら次へ進む」だけの説明）。〔WCAG 1.3.3（A）〕
• 必須 3秒を超えて自動再生される音声は、停止か音量調整ができるようにする。〔WCAG 1.4.2（A）〕
• 必須 収録済みの動画に字幕を付ける。〔WCAG 1.2.2（A）〕
• 必須 音声だけのコンテンツには、書き起こしテキストを付ける。〔WCAG 1.2.1（A）〕
• 必須 映像だけで伝わる情報には、音声解説を付ける。〔WCAG 1.2.5（AA）〕
• 必須 ライブ配信の音声に、リアルタイム字幕を付ける。〔WCAG 1.2.4（AA）〕
• 成功音・エラー音などの効果音には、同じ意味の視覚表示を併用する。〔Apple HIG〕
• 字幕の文字サイズや背景を、利用者が変更できるようにする。〔Apple HIG〕
• 動画・音声コンテンツの詳しいルールは動画・音声を参照する。

1.9 触覚

• 音による合図にハプティクス（振動）を組み合わせる。音を消している人や聞こえない人にも伝わる。〔Apple HIG〕

2. 操作

2.1 操作対象の大きさ・間隔

2.2 入力方法

• 必須 すべての機能をキーボードだけで操作できるようにする。〔WCAG 2.1.1（A）〕
• 必須 キーボードのフォーカスが、ある部品から抜け出せなくならないようにする。〔WCAG 2.1.2（A）〕
• 必須 フォーカスの位置が見えるようにする。〔WCAG 2.4.7（AA）〕
• 必須 フォーカスの移動順序を、意味の通る順にする。〔WCAG 2.4.3（A）〕
• 必須 繰り返し表示されるナビゲーションを飛ばして本文に移動できるようにする。〔WCAG 2.4.1（A）〕
• 必須 1文字だけのキーボードショートカットは、無効化・変更ができるか、フォーカス時だけ有効にする。〔WCAG 2.1.4（A）〕
• 必須 複数の指や軌跡を使うジェスチャー（ピンチ、スワイプの軌跡など）には、1本指のタップで済む代替手段を用意する。〔WCAG 2.5.1（A）〕
• 必須 指を置いた瞬間ではなく、離したときに実行する。押し間違いを指をずらして取り消せるようにする。〔WCAG 2.5.2（A）〕
• 必須 ドラッグでしかできない操作に、クリックやタップでの代替手段を用意する。〔WCAG 2.5.7（AA）〕
• 必須 端末を振る・傾けるなどの動きで動く機能は、画面上の操作でも実行でき、動きへの反応を無効にできるようにする。〔WCAG 2.5.4（A）〕
• スワイプで削除する操作には、ボタンでの削除も用意する。〔Apple HIG〕
• よく使う操作には最も単純なジェスチャーを使い、複数の指や両手を使う独自ジェスチャーを避ける。〔Apple HIG〕
• 音声コントロール、スイッチコントロール、フルキーボードアクセス、AssistiveTouchで操作できるか確認する。〔Apple HIG〕
• OSが定義したキーボードショートカットを上書きしない。〔Apple HIG〕

2.3 身体的負担

• 長押し・連打・素早い操作を必須にしない。
• 片手でも主要な操作ができるようにする。
• 繰り返し行う操作は、ショートカットや自動化（iOSのショートカット、Siri）に対応する。〔Apple HIG〕

2.4 時間

• 必須 制限時間は、解除できる、既定の10倍以上に延長できる、終了の20秒以上前に警告して簡単な操作で延長できる（10回以上）、のいずれかを満たす。リアルタイムの競売などは例外である。〔WCAG 2.2.1（A）〕
• タイマーで自動的に消える表示（トーストなど）を避け、利用者の操作で閉じるようにする。〔Apple HIG〕
• ゲームでは、反応時間や難易度を調整できるようにする。〔Apple HIG〕

2.5 誤操作への対策

• 必須 フォーカスを移しただけで、ページ遷移などの大きな変化を起こさない。〔WCAG 3.2.1（A）〕
• 必須 入力や選択をしただけで、予告なく大きな変化を起こさない。〔WCAG 3.2.2（A）〕
• 必須 入力エラーは、箇所と内容を文字で示す。〔WCAG 3.3.1（A）〕
• 必須 修正方法がわかる場合は、修正案を示す。〔WCAG 3.3.3（AA）〕
• 必須 契約・金銭・データの変更や削除を伴う送信は、取り消せる、送信前に確認できる、入力を検査して修正できる、のいずれかを満たす。〔WCAG 3.3.4（AA）〕
• ファイルの削除など取り返しのつかない操作は、確認を求める。〔Apple HIG〕

3. 理解

3.1 言葉

文の書き方

• 一文を短くし、一文に言いたいことを1つだけ入れる。〔公用文作成の考え方、やさしい日本語ガイドライン〕
• 3つ以上の情報を並べるときは、箇条書きにする。〔公用文作成の考え方、やさしい日本語ガイドライン〕
• 結論を先に示し、続けて理由や詳細を書く。〔公用文作成の考え方〕
• 「いつ」「どこで」「誰が」「何を」「どうした」の語順で書き、主語と述語の関係がわかるようにする。〔公用文作成の考え方〕
• 回りくどい言い方や不要な繰り返しを使わない（例：「調査を実施した」→「調査した」）。〔やさしい日本語ガイドライン〕
• 二重否定を使わない（例：「在留カード以外は必要ありません」→「在留カードを持ってきてください」）。〔やさしい日本語ガイドライン、公用文作成の考え方〕
• 受身形や使役表現をできる限り使わない。行動の主体がわかりにくくなる。〔やさしい日本語ガイドライン〕
• 係る語と受ける語、指示語と指示される語を近くに置く。〔公用文作成の考え方〕

言葉の選び方

• 難しい言葉や専門用語をできる限り使わない。使う場合は説明を添える。〔公用文作成の考え方〕
• 外来語（カタカナ語）は、ほかに適切な言葉がない場合だけ使う（例：スキーム→計画、コンセンサス→合意）。〔やさしい日本語ガイドライン〕
• 略語を使わない（例：「健診」→「健康診断」）。〔やさしい日本語ガイドライン〕
• 「くらい」「ごろ」「なるべく」などの曖昧な表現を使わない。時間や数字は具体的に書く。〔やさしい日本語ガイドライン〕
• 「結構です」のように複数の意味をもつ表現を使わない。〔やさしい日本語ガイドライン〕
• 「おそらく」「ようです」などの推測表現を避ける。断定できない場合は「〜かもしれません」を使う。〔やさしい日本語ガイドライン〕
• 言い換えが難しい重要な言葉はそのまま使い、説明を添える（例：余震＜＝後から来る地震＞）。〔やさしい日本語ガイドライン〕
• 外国人向けの文書では、文末を「です」「ます」にそろえ、尊敬語・謙譲語を使わない。指示は「〜してください」と書く。〔やさしい日本語ガイドライン〕
• 作成後、日本語教師や対象の外国人に、わかりやすいか確認してもらう。〔やさしい日本語ガイドライン〕

Web・アプリ固有のルール

• 必須 各ページに、内容を表すタイトル（<title>）を付ける。〔WCAG 2.4.2（A）〕
• 必須 見出しとラベルは、内容や目的がわかる言葉にする。〔WCAG 2.4.6（AA）〕
• 必須 リンクの文言と文脈で、リンク先がわかるようにする。「こちら」「詳しくはこちら」だけのリンクにしない。〔WCAG 2.4.4（A）〕
  ✕ 「こちら」だけのリンク

  申込書はこちら。
  記入例はこちら。

  リンクだけを読み上げると、行き先がわからない。

  ◯ 行き先がわかる文言

  申込書（PDF、120KB）
  申込書の記入例（PDF、300KB）

  リンクだけを読んでも行き先と形式がわかる。

• 必須 入力欄に、見えるラベルか説明を付ける。〔WCAG 3.3.2（A）〕
  ✕ プレースホルダーだけ

  氏名

  電話番号

  入力を始めると項目名が消える。薄い文字は読みにくい。

  ◯ 見えるラベルと入力例

  氏名例：山田 太郎

  電話番号例：03-1234-5678

  入力中もラベルが残り、形式もわかる。

• 必須 「右の赤いボタンを押す」のように、形・色・位置・音だけで指示しない。〔WCAG 1.3.3（A）〕
• プレースホルダーをラベルの代わりにしない。入力を始めると消えてしまう。
• ボタンの文言は「送信する」「保存する」のように、押した結果がわかる動詞にする。

3.2 情報構造

• 必須 サイト内のページに、2つ以上の到達方法（メニュー、検索、サイトマップなど）を用意する。〔WCAG 2.4.5（AA）〕
• 必須 「送信しました」「3件見つかりました」などの状態メッセージを、フォーカスを移さずに支援技術へ伝える（ARIAのlive領域など）。〔WCAG 4.1.3（AA）〕
• 多段階の手続きでは、全体の段階数と現在の段階を示す。
• 重要な情報を画面の上部に置く。

3.3 一貫性

• 必須 複数のページで繰り返すナビゲーションは、同じ順序で表示する。〔WCAG 3.2.3（AA）〕
• 必須 同じ機能の部品には、全ページで同じ名前・アイコンを使う。〔WCAG 3.2.4（AA）〕
• 必須 ヘルプ（問い合わせ先、チャットなど）は、全ページで同じ相対位置に置く。〔WCAG 3.2.6（A）〕
• OS標準の部品とジェスチャーを使う。利用者が操作を新しく覚えずに済む。〔Apple HIG〕

3.4 記憶への負担

• 必須 同じ手続きの中で一度入力した情報を、再入力させない。自動入力するか、選択肢として示す。〔WCAG 3.3.7（A）〕
• 必須 パズルや記憶力のテストだけに頼る認証にしない。パスワードの貼り付けや、パスワード管理ツールの自動入力を妨げない。〔WCAG 3.3.8（AA）〕
• 必須 氏名・住所・電話番号などの入力欄に、入力目的を機械が判別できる属性（HTMLのautocomplete）を付ける。〔WCAG 1.3.5（AA）〕
• 前の画面で見た情報を覚えておく必要がないように、必要な情報を同じ画面に表示する。

3.5 表記

数字

• 横書きでは算用数字を使う。〔公用文作成の考え方〕
• 大きな数は3桁ごとにコンマで区切る（例：1,254,372人）。兆・億・万の単位は漢字で書く（例：30万円）。〔公用文作成の考え方〕
• 全角・半角の使い分けを文書内で統一する。〔公用文作成の考え方〕
• 概数や「一つ」「一人」などの言葉は漢数字で書く。〔公用文作成の考え方〕

日付・時刻

• 元号だけで書かず、西暦を使う。〔やさしい日本語ガイドライン〕
• 年月日を「/」で区切らず、「2020年6月4日」と書く。〔やさしい日本語ガイドライン〕
• 時刻は午前・午後を明記する（24時間表記でもよい）。〔やさしい日本語ガイドライン〕
• 期間は「〇〇から△△まで」と書く。「〜」は誤解を生むため使わない。〔やさしい日本語ガイドライン〕
• 「年度」は具体的な日付で書き換える。使う場合は最初に説明する。〔やさしい日本語ガイドライン〕

ふりがな・漢字

• 外国人や子どもが読む文書では、漢字の量を抑え、すべての漢字にふりがなをつける。〔やさしい日本語ガイドライン〕
• ふりがなは漢字の上か、漢字の後ろの括弧に入れる。〔やさしい日本語ガイドライン〕
• ふりがなを入れた文書とは別に、ふりがなのない版も用意する。ふりがなは機械翻訳を妨げる。〔やさしい日本語ガイドライン〕
• ローマ字で日本語を書かない。外国人がローマ字を日本語の発音どおりに読めるとは限らない。〔やさしい日本語ガイドライン〕

記号

• 括弧は（ ）と「 」を基本にし、他の括弧は用法を統一して使う。〔公用文作成の考え方〕

Web・アプリ固有のルール

• 日付・電話番号・郵便番号の入力欄には、入力形式の例を示す。
• 全角・半角、ハイフンの有無などの入力形式の違いは、システム側で吸収する。

3.6 多言語

• 必須 ページの主な言語を指定する（HTMLのlang属性）。読み上げソフトが正しい発音で読む。〔WCAG 3.1.1（A）〕
• 必須 一部分だけ別の言語で書く場合は、その部分の言語を指定する。〔WCAG 3.1.2（AA）〕
• 外国人向けの情報は、多言語版に加えて「やさしい日本語」版を用意する。〔やさしい日本語ガイドライン〕

4. 使用環境

• 屋外の明るい場所や画面の明るさを下げた状態でも読めるよう、コントラストに余裕をもたせる。〔Apple HIG〕
• 片手がふさがっている、揺れる乗り物の中にいるなどの状況を想定し、ターゲットを大きくする。

5. 支援技術・代替形式

• 必須 すべてのUI部品の名前・役割・状態（チェック済みなど）を、支援技術が取得できるようにする。独自部品にはARIAやOSのアクセシビリティAPIで設定する。〔WCAG 4.1.2（A）〕
• スクリーンリーダー（iOSのVoiceOver、AndroidのTalkBack、WindowsのNVDA）で、実際に操作して確認する。
• iOSのアクセシビリティインスペクタ、AndroidのLintやユーザー補助検証ツールで問題を検出する。〔Apple HIG、Android Developers〕
• 認知障害のある人向けのiOSのアシスティブアクセスでは、主要な機能に絞り、不要な画面要素を減らす。〔Apple HIG〕
• App Storeのアクセシビリティ栄養ラベルで、対応している支援機能を示す。〔Apple HIG〕
• 文書はPDFよりHTMLで提供する。PDFで提供する場合は、タグ付きPDFにする。

6. 法規・規格

7. チェックリスト

1. グレースケールと色覚シミュレーションで、情報が区別できるか。
2. 文字のコントラストが4.5:1以上（大きな文字は3:1以上）、UI部品が3:1以上あるか。
3. 200%拡大と幅320pxの表示で、内容が欠けず、横スクロールが出ないか。
4. すべての操作をキーボードだけで行え、フォーカスが常に見えるか。
5. ターゲットが24px以上（推奨44px、Androidは48dp）あるか。
6. 画像に代替テキスト、アイコンボタンに名前があるか。
7. 見出し・ラベル・リンクの文言で内容がわかるか。
8. エラーを文字で示し、修正方法を示しているか。
9. 点滅が1秒3回以下で、自動で動く内容を止められるか。
10. 動画に字幕、音声に書き起こしがあるか。
11. スクリーンリーダー（VoiceOver・TalkBack・NVDA）で最後まで操作できるか。
12. OSの文字サイズ・コントラスト・動きを減らす設定に追従するか。

8. 出典

• W3C, Web Content Accessibility Guidelines (WCAG) 2.2↗（新しいタブで開く）
• W3C, WCAG2ICT（Guidance on Applying WCAG 2 to Non-Web ICT）↗（新しいタブで開く）
• Apple, Human Interface Guidelines: Accessibility↗（新しいタブで開く）
• Android Developers「アプリのユーザー補助機能を強化する」↗（新しいタブで開く）

• 川崎市総務局「公文書作成におけるカラーUDガイドライン」↗（新しいタブで開く）
• カラーユニバーサルデザイン機構（CUDO）「カラーユニバーサルデザイン推奨配色セット」↗（新しいタブで開く）
• 高橋佑磨・片山なつ「伝わるデザイン｜研究発表のユニバーサルデザイン」↗（新しいタブで開く）
• 国土交通省「公共交通機関の旅客施設に関する移動等円滑化整備ガイドライン（旅客施設編）」令和7年9月↗（新しいタブで開く）
• 出入国在留管理庁・文化庁「在留支援のためのやさしい日本語ガイドライン」↗（新しいタブで開く）
• 文化審議会「公用文作成の考え方（建議）」2022年↗（新しいタブで開く）
• 字幕付きCM普及推進協議会「字幕付きCMハンドブック」2019年↗（新しいタブで開く）
• JIS S 0013:2022 アクセシブルデザイン－消費生活用製品の報知音↗（新しいタブで開く）
• 岡部正隆・伊藤啓「Color Universal Design」（Okabe–Itoパレット）↗（新しいタブで開く）
• NC State University, The Center for Universal Design（7原則）↗（新しいタブで開く）
• Machado, G. M., Oliveira, M. M., & Fernandes, L. A. F. (2009). A Physiologically-based Model for Simulation of Color Vision Deficiency. IEEE TVCG, 15(6).（色覚シミュレーションの計算方法）

• 内閣府「合理的配慮の提供が義務化されました」↗（新しいタブで開く）
• European Commission, European Accessibility Act↗（新しいタブで開く）