アクセシビリティは実装だけの話ではない

アクセシビリティは、特定の技術領域に閉じた話ではありません。

• HTML構造
• UI設計
• フォーム設計
• JavaScriptの挙動

これらすべてに関わる、前提条件です。
そのため、「実装で何とかする」では限界があり、設計・デザイン段階での判断が重要になります。

デザイン工程で決まること

アクセシビリティに関わる多くの要素は、デザイン工程でほぼ方向性が決まります。
もちろん、実装段階でしか気づけない部分は、実装時に補います。
しかし、それは微調整であり、根本的な方向転換ではありません。
FHWでは、「実装で詰まらない状態」を作ることを目的に、デザイン段階での確認を重視しています。

コントラストは「あとで測る」ものではない

コントラストは、デザイン完成後にツールで一括チェックするのではなく、配色を決める時点で“通る前提”で考えるというスタンスを取ります。
後から調整が必要になる配色は、デザイン全体の再調整につながることが多く、結果としてコストが増えがちです。

フォーカスは「見えない前提」で考える

フォーカス（キーボード操作時の移動）は、デザインカンプ上では見えません。
しかし、どこにフォーカスが当たるかは、事前に想定しておく必要があります。

• 操作順に無理はないか
• 視覚的な位置と論理的な順序が乖離していないか

これらを、デザイン工程の時点で意識しておくことで、実装時の調整が大幅に減ります。

代替表現は「全部用意しない」

代替表現は、すべての要素に一律で用意するものではありません。

• 本当に必要な箇所はどこか
• 代替が必要なケースは何か

を見極めたうえで、必要なところに、必要な分だけ設計します。
これにより、過剰な実装や形だけの対応を避けることができます。

チェックリストは“判断の補助”

アクセシビリティのチェックリストは、機械的に消化するものではありません。
FHWでは、

• 設計判断を補助するための材料
• 見落としを防ぐための視点整理

として扱います。
チェックリストそのものが目的になることはありません。

法令・ガイドラインとの距離感

JIS X 8341-3 や WCAG は、すべてを満たすことを目的にするものではなく、判断基準として参照するものという距離感で扱います。
プロジェクトの目的や現実的な制約を踏まえ、どこまでを採用するかを判断します。

このページで伝えたいこと

アクセシビリティ対応を楽にする最大のポイントは、「どこで確認するか」を先に決めておくことです。
後付け対応を前提にすると、調整範囲は広がり、ズレも増えます。
FHWでは、デザイン工程にアクセシビリティを埋め込むことで、実装フェーズをシンプルに保ちます。