義務化後のWebアクセシビリティをどうするかーー実装で押さえる勘所

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

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

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

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

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

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

判断の軸は、法解釈より画面の使いやすさ。

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

だから見積りの段階では、AAをおおむね満たすところまでを標準の作り込みとして含め、そこから先の個別の要望は別の相談として分けておくほうが、双方にとって範囲がはっきりします。

実装で押さえる6項目

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

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

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

逆に、ライブラリ側の部品が独自にフォーカスを制御している場合は、6項目を満たしたつもりでもTabの移動順が崩れることがあるので、そこだけはキーボードで実際に辿って確かめます。

tsudzuri.com での実装例

説明だけでは一方的です。だから、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からのコーディング依頼」も参考になるはずです。

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

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

最初に直すなら、フォーカスの可視化。outlineを消している1行を戻すだけで、キーボード利用者には画面の現在地が戻ってくるからです。

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

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