「アクセシビリティが義務化された」という話が、制作会社の現場でも聞こえるようになりました。ただ、ここには誤解が混ざりやすい部分があります。何が義務で、Web制作として実務で何をすればいいのか。この2つを分けて考えないと、対応が空回りします。

先に結論を言うと、押さえるべきは法解釈よりも実装レイヤーです。フォーカスの可視化、色のコントラスト、フォームのlabel、aria-*の使い方、キーボード操作、動画の字幕。この積み重ねが、実際に使える画面をつくります。ここでは制度の区別を正確に押さえたうえで、私（Tsudzuri／藤原）が自分のサイトで実際にやっている実装を開示します。

まず「義務」と「努力義務」を分けて理解する

2024年4月1日に施行された改正障害者差別解消法で、民間事業者にも「合理的配慮の提供」が法的義務となりました。ここは事実です。ただし、Webサイトをアクセシブルに作り込むこと自体が義務化されたわけではありません。

ウェブアクセシビリティへの対応は、法律上は「環境の整備」に位置づけられ、現時点では努力義務とされています。合理的配慮が「個別の求めに応じて対応する」ものであるのに対し、環境の整備は「日頃から使いやすい状態を整えておく」もの、という整理です。両者は地続きで、環境を整えておくほど、個別の配慮も軽くなります。

義務（合理的配慮の提供）と努力義務（環境の整備＝アクセシビリティ準拠）の区別を2列で整理した図

罰則の有無や数値には、ここでは踏み込みません。制作会社として意味があるのは、「準拠対応は努力義務だが、やっておく価値は高い」という現実的な判断だと考えています。

なお国内の基準としてはJIS X 8341-3があり、これは国際的なガイドラインであるWCAG 2.0（ISO/IEC 40500）と一致する内容とされています。実務では「WCAGの適合レベルAAをおおむね満たす」を一つの目安に置くと、判断がぶれにくくなります。

実装で押さえる6項目

制度の話より、手を動かす部分が本題です。私が案件で必ず確認しているのは、次の6つです。

実装で押さえる6項目（フォーカス可視化／色コントラスト／labelと入力補助／ariaの状態／キーボード操作／altと字幕）
  • フォーカスの可視化：outline: noneでフォーカスリングを消したまま放置しない。デザイン上どうしても標準の枠が合わない場合も、代わりに見える輪郭を必ず残します。キーボードだけの利用者には、今どこにいるかが唯一の手がかりです。
  • 色のコントラスト：本文テキストはWCAG AA（4.5:1以上）を目安に確認する。薄いグレー文字や、アクセント色の上に置く白抜き文字は特に落ちやすい部分です。
  • フォームの`label`と入力補助：入力欄には必ずlabelを紐付け、プレースホルダーだけで済ませない。autocomplete属性を適切に付けると、支援技術にも自動入力にも効きます。
  • `aria-*`の状態管理：開閉メニューにはaria-expandedとaria-controlsを付ける。ただし、ネイティブ要素で足りるところにariaを盛るのは逆効果です。付けすぎないのも実装の判断です。
  • キーボード操作：マウスなしでTabキーだけで全機能を操作できるか。フォーカスの移動順が視覚の並びと食い違わないかを確認します。
  • 画像`alt`と動画字幕：意味のある画像には内容が伝わるaltを、装飾画像は空altにする。動画にはキャプション（字幕）を用意します。

この6つは、どれも特別なライブラリを必要としません。素直なマークアップと、少しの気配りで届く範囲です。中身で品質が分かるという話は「コーダーの実力は納品物で見抜ける」でも書きました。

自サイトでどう実装しているか

説明だけでは一方的なので、tsudzuri.com での実装を開示します。

ハンバーガーメニューのボタンには、開閉状態をaria-expandedで持たせ、制御対象をaria-controlsで結んでいます。

<button aria-expanded="false" aria-controls="site-nav" aria-label="メニューを開く">

フォーカスリングは消していません。キーボード操作時にはアクセント色のアウトラインが出るようにし、マウス操作時だけ抑える:focus-visibleで切り分けています。装飾のスクロール演出はprefers-reduced-motion（動きを減らす設定）を尊重し、動きが苦手な方には静止表示します。

お問い合わせフォームは自作で、各入力欄にlabelを紐付け、エラーは色だけでなくテキストでも示すようにしています。色のコントラストはWCAG AA（4.5:1以上）を基準に確認しました。速度と画像設計の考え方は「表示速度とCore Web Vitals」に詳しく書いています。

こうした配慮は、Figmaのデザインをピクセル単位で再現する私の基本姿勢と矛盾しません。見た目の忠実さと、使いやすさの担保は両立できます。デザインデータの受け渡しについては「FigmaやXDからのコーディング依頼」も参考になるはずです。

完璧より、一段ずつの底上げを

アクセシビリティは、一度で満点を取る作業ではありません。フォーカスが見える、コントラストが足りている、キーボードで操作できる。この当たり前を一段ずつ積むだけで、画面は確実に使いやすくなります。義務化を、実装の質を上げるきっかけにするのが現実的だと感じています。

Tsudzuriは、こうしたアクセシビリティ実装を標準の作り込みとして扱っています。既存サイトのコントラストやariaのチェック、フォームの改善など、小さな相談からでも歓迎します。気になる点はお問い合わせからご相談ください。

本記事は2026年7月時点の情報です。制度の解釈や基準は今後変わる場合がありますので、最新の一次情報もあわせてご確認ください。