アクセシビリティは、完成時に一度確認すれば済む「機能」ではなく、継続的に維持すべき「運用能力」である——Smashing Magazineに寄稿された記事は、こうした視点の転換を促している。
筆者のProsmitskiy氏は「コンプライアンスは到達する状態ではなく、維持する状態であり、複雑さは常にそれに抗う」と指摘する。プロジェクト終了時の監査だけでアクセシビリティを担保しようとする方法は、変化し続けるプロダクトには通用しないという主張だ。
この課題は、AIによるコード生成の普及でいっそう深刻になっている。生成モデルは、アクセシブルでないマークアップを出力しがちである。GitHub上の多くのコードが非セマンティックな書き方をしていること、レビューが見た目で判断されがちなこと、そして のような記述が意味的 に正しい代替よりトークン数が少なく済むことが、その背景にあると分析する。
記事はアクセシビリティを開発プロセスに組み込む具体策を挙げる。アクセシブルなコンポーネントをデザインシステムとして共有し（英国政府のGOV.UKが例として挙げられる）、JAWSやNVDA、VoiceOver、TalkBackといった支援技術で検証する。「完了の定義（Definition of Done）」にアクセシビリティを含め、プルリクエストのレビューでも明示的に確認する。eslint-plugin-jsx-a11yやPa11y、Storybookのアドオンを用いた自動チェックも有効だとする。
AIを使う場合も、CursorのルールやCopilotの指示にアクセシビリティ要件を組み込み、複雑なUIは自作せずRadix UIやReact Aria、Headless UIといったライブラリを使うことを勧める。そして何より、実際に障害のある利用者とともに行うユーザーテストの重要性を強調する。「JAWSを使う人の後ろに初めて座ったとき」に視点は大きく変わるという言葉が、その本質を言い表している。
出典: Why Accessibility Is An Operational Capability, Not A Feature
