チームはこれまで以上に迅速にUIを生成できますが、出荷するものが使用可能で、安全で、メンテナンス可能であることを保証する必要があります。アクセシビリティをコンプライアンスチェックリストやプロジェクト終了時の監査ではなく、運用上の能力として捉えること、そしてそれが実際にどのようなものかを解説します。

今この瞬間、あるシニアエンジニアが「午後のうちに」構築したチェックアウトフローを出荷しているかもしれません。AIアシスタントが重労働をこなし、ハッピーパスはスムーズに動作し、注文サマリーには回転するシェブロンが表示されています。2週間後、エンジニアリングチームはカスタマーサポートから通知を受け取ります。スクリーンリーダーを使用する視覚障害のある顧客が、「今すぐ支払う」コントロールがクリックハンドラ付きの <div> であるため、購入を完了できないというのです。roleがなく、フォーカス可能ではなく、動作しません。

コードが動作することと、人々が実際に使用できる製品との間のギャップは、AI時代のエンジニアリングにおける決定的な課題の一つになりつつあります。チームはこれまで以上に迅速にUIを生成できますが、出荷するものが使用可能で、安全で、メンテナンス可能であることを保証する必要があります。

アクセシビリティは、まさにこの問題の中心に位置しています。

これは、コンプライアンスチェックリストやプロジェクト終了時の監査に関する記事ではありません。エンジニアリングシステムに関する記事です。具体的には、アクセシビリティをプライバシー、セキュリティ、信頼性、観測可能性と並ぶ運用上の能力として扱うべき理由と、それが実際にどのようなものかを解説します。

監査の罠

長年、アクセシビリティを「行う」ためのデフォルトの方法は、一度限りの監査のみのアプローチでした。企業を雇い、200件の指摘事項のリストを受け取り、その一部を修正し、レポートを提出するものです。多くのチームが今、このモデルから脱却しています。その理由は注目に値します。

監査は重要です。営業、調達、ガバナンスにおいては必須です。バイヤーが VPATやACR を求めるときには必要です。法務が要件を満たしているかを確認するときには、ドキュメントが必要です。監査はこれらの目的を十分に果たします。

しかし、監査はスプリント計画中にアクセシブルな機能を構築する助けにはなりません。監査はスプリント中にポイントを消費する可能性があります。マージリクエスト前に問題をキャッチしません。デプロイの速度にスケールしません。 本質的な誤りは、アクセシビリティをスナップショットとして扱うことであり、本当に必要なのは継続的な監視です。監査から6ヶ月後、製品は数十回のリリース、複数の新機能、ナビゲーションの再設計を経ています。レポートは今やフィクションです。コンプライアンスは到達する状態ではなく、維持する状態であり、複雑さは常にそれを阻害します。

WebAIM Millionレポート は、毎年トップ100万のホームページをスキャンしていますが、2026年の実行では95.9%のページに検出可能なWCAG違反があり、1ページあたりの平均エラー数は56.1件でした。ページ要素の数は1年で20%以上増加しており、これはAI支援開発と「バイブコーディング」による影響が大きいと考えられます。要素が増えれば、破綻する箇所も増えます。アクセシビリティ債務は技術的債務と全く同じように振る舞います。アクセシブルでないコンポーネントを出荷するたびに、将来の修正プロジェクトとなり、利息は複利で増加します。

アクセシビリティを定期的なイベントとして扱い、システムの継続的な特性として扱わない戦略は、必ず失敗します。

誰も名前を付けたがらないAIの問題

チームが現在UIを生成する規模では、このギャップは存続するだけでなく、増幅されます。

まず、この状況がどれだけ急速に到来したかを見てみましょう。2025年2月、Andrej Karpathyが「バイブコーディング」という用語を提唱しました。これは「完全にバイブに身を委ね」「コードが存在することを忘れる」作業方法です。意図を記述し、モデルが生成し、差分を確認せずに受け入れる。これは週末のプロジェクトを想定したものでしたが、そこに留まりませんでした。Y Combinatorの報告 によると、2025年冬のバッチの25%が、コードベースの95%がAI生成でした。

モデルが非セマンティックなマークアップに着地するのは偶然ではありません。3つの力がそれを後押ししています。GitHub上のほとんどのReactコードは非セマンティックな「スープ」を使用しているため、モデルはそれを学習します。人間のレビュアーと評価者は出力を視覚的に判断するため、フィードバックループはセマンティクスではなく見た目を報酬とします。そして <div onClick> は <button aria-expanded="true" ...> よりもトークン数が少なく、制約がなければモデルは安価な道を選びます。

AI生成UIについて重要な点があります。デフォルトでアクセシブルではありません。時折ではなく、デフォルトでアクセシブルではありません。Frontend Mastersで執筆する開発者が 複数のツールでAI生成のReactコンポーネントをテストし、パターンを記録しました。典型的なAI生成のサイドバーには、29行の中に10個の異なるアクセシビリティの失敗がありました。ランドマークがなく、見出しがなく、リスト構造がなく、ボタンではなくクリックハンドラを持つ要素があり、aria-expandedがなく、キーボード処理がなく、ラベル付けされていないアイコンがありました。スクリーンリーダーが実際に読み取るアクセシビリティツリーは、平坦で構造化されていないテキストとして返されました。著者が述べたように「同じピクセル」です。「一方はドア。もう一方はドアの絵」です。

ここでセキュリティと結びつけてみましょう。なぜなら、2つの失敗は同じ根源から来ているからです。Veracodeの 2025 GenAI Code Security Report は、数十のコーディングタスクにわたって大規模言語モデルをテストし、AI生成コードの大部分がセキュリティ脆弱性（OWASP Top 10の欠陥を含む）を導入することを発見しました。クロスサイトスクリプティングの失敗が特に一般的で、セキュリティパフォーマンスは新しい、より大きなモデルでも意味のある改善を示しませんでした。問題はモデルの知能ではありませんでした。プロセスでした。セキュリティ制約を指定せずにコードを生成し、体系的な検証なしに出力を受け入れる開発者です。

セキュリティレビューをスキップする同じショートカットが、アクセシビリティレビューをスキップします。規模が拡大するにつれ、AIはアクセシビリティギャップを埋めることはなく、むしろそれを生み出すものを産業化したのです。

解決策はAIを禁止することではありません。開発者はすでにそれを使用しています。解決策はそれを制約し、検証することです。AIを、常にガードレールを必要とする非常に高速なチームメイトとして扱うことです。

速度とアクセシビリティは敵ではない

ここで通常、誰かがこう言うでしょう。「ガードレール？いいように聞こえるけど、速度を落とすだろうね」

実際には、その逆が真実である傾向があります。

シフトレフト はDevOpsの全体的なテーゼであり、ここにもきれいに適用できます。設計レビュー中に発見されたアクセシビリティの問題はコメントです。同じ問題が本番環境で発見された場合は修正プロジェクトです。

コンポーネントが構築される時点でアクセシビリティの問題をキャッチするには数分かかります。後から修正する——監査で発見し、根本原因を診断し、マークアップを再構築し、必要な修正を適用し、テストを書く——には簡単に数時間かかることがあります。後期の監査から得られる数百の指摘事項にそれを掛け合わせると、設計レビュー、開発ワークフロー、CIでの早期の自動チェックで防げたはずの数週間の計画外の作業が発生します。

アクセシビリティを日常のワークフローに統合するチームは、高額なサプライズ——緊急監査、修正スプリント、調達のブロック、コアユーザージャーニーを静かに破壊する再設計——を避けます。アクセシビリティは速度を低下させません。予期しない作業が速度を低下させます。フロー内のアクセシビリティは、予期しない作業を排除する一つの方法です。

エンタープライズ対応とは実際どのようなものか

アクセシビリティを成功裏にスケールさせる組織は、ヒーローに依存しません。システムに依存します。

最もレバレッジの高い出発点はデザインシステムです。1つのアクセシブルなコンポーネントは、何千回も再利用できます。GOV.UK Design System は有用な例です。コンポーネントはJAWS、NVDA、VoiceOver、TalkBackなどの支援技術を使用した自動テストと手動テストの両方を受けます。チームは自動化の限界を明確にし、障害を持つ人々を巻き込んだユーザーテストでツールを補完します。また、デザインシステムを使用することがサービスを「魔法のように」アクセシブルにするわけではないことも明確にしています。ただ、より高い出発点を与えるだけです。

アクセシビリティはインフラストラクチャになります。それが教訓です。

そこから、エンジニアリングワークフローに移ります。

  • アクセシビリティ要件はDefinition of Doneに含まれます。
  • プルリクエストレビューには明示的なアクセシビリティチェックが含まれます。
  • インタラクティブコントロールはデフォルトでセマンティック要素（<button>、<a>）を使用します。
  • キーボードナビゲーションとフォーカス管理は、オプションの磨き上げではなく、標準的なエンジニアリングの懸念事項として扱われます。

最後に、アクセシビリティは自動化を通じて強制可能になります。

  • eslint-plugin-jsx-a11y はコードがコミットされる前に一般的な問題をキャッチします。
  • LevelCI、Pa11y などのツールはCI/CDパイプラインで自動テストを提供します。
  • @storybook/addon-a11y はコンポーネント開発中に問題を可視化します。

その時点で、アクセシビリティは記憶に依存しなくなり、プロセスに依存するようになります。プラットフォームの一部になります。

実際にスケールするパターン

これをうまく実践しているチームで一貫して見られる実装パターンがいくつかあります。

生成前にAIを制約する

生成後にアクセシビリティを修正する代わりに、Cursorルール、Copilot指示、リポジトリレベルの標準を通じて要件をツールに直接組み込みます。モデルにセマンティックHTMLを使用するよう指示します。ボタンとリンクの使い分けを指示します。状態とラベルを正しく露出するよう指示します。モデルは、ワンオフのプロンプトよりも永続的な制約に従う方がはるかに信頼性が高くなります。

複雑なウィジェットの手作りは止める

コンボボックス、メニュー、タブ、モーダルなどのコントロールは、定期的にアクセシビリティのホットスポットになります。Radix UI、React Aria、Headless UIなどのライブラリは、すでにこれらの問題の多くを解決しています。スケーラブルなアプローチは、アクセシビリティを正しく実装し続けることではありません。十分にテストされたプリミティブからアクセシブルな動作を継承することです。

デザインの引き渡し時にアクセシビリティをキャプチャする

フォーカス順序、ラベル、見出し階層、インタラクション状態は、実装が始まる前に指定されるべきです。デザイン成果物にアクセシビリティ要件が欠けている場合、最終製品にも欠けていることがよくあります。デザイン引き渡し時のシンプルなメモ——タブオーダーは何か、ラベルは何か、エラー時に何が起こるか——は、後々の推測作業を大幅に削減します。

これらのパターンはどれも特殊なものではありません。ただDevOpsとプラットフォーム思考をアクセシビリティに適用したものです。

より広範なビジネスへの影響

エンジニアリングリーダーがアクセシビリティを優先するのは、規制のためだけではありません。しかし、規制、調達要件、ユーザーの維持、製品品質はすべて同じ方向を指しています。

法的圧力は増加し続けています。米国のデジタルアクセシビリティ訴訟 は毎年数千件で推移しており、大企業に限定されません。欧州アクセシビリティ法 は現在EU全体で施行されており、eコマース、銀行、チケット販売、通信などを対象とし、本社所在地に関係なく適用されます。メッセージは明確です。規制当局の目には、アクセシビリティはもはや「あったらいいね」ではありません。

しかし、コンプライアンスは物語の一部に過ぎません。より大きな物語は、取りこぼしている市場です。世界経済フォーラム（2023年12月） は、世界の13億人の障害者と「その友人や家族」を合わせた購買力が「13兆ドル」であると推定しています。障害のある消費者だけで、年間約8兆ドルの可処分所得を管理しています（Valuable 500による）。

英国だけでも、Click-Away Pound Report 2019 によると、「Click-Away Poundは171億ポンド」に達しており、アクセスニーズを持つ490万人以上のユーザーがアクセシブルでないサイトを放棄して他の場所で支出しており、2016年の117.5億ポンドから45%近く増加しています。人々はバグレポートを提出しません。去って競合他社から購入するのです。

また、調達の現実もあり、アクセシビリティをコストから堀に変えます。B2Bや政府向けに販売する場合、アクセシビリティの証明——VPAT/ACRまたは同等のドキュメント——をますます求められるようになります。Level Accessの第7回デジタルアクセシビリティの現状レポート によると、組織の75%がデジタル製品を購入する際に少なくともほとんどの場合アクセシビリティの証明を要求しており、前回のレポートの74%からほぼ変わっていませんが、厳格な執行への顕著なシフトがあり、「常に要求する」組織は27%から31%に増加しています。強力なACRは販売サイクルを加速させます。弱いもの、または全くないものは、停滞や中止を招くレッドラインを生み出します。一部のバイヤーにとっては、製品が評価に入る前のハード要件です。強力なアクセシビリティストーリーは販売サイクルを加速させます。弱いものは停滞や中止を招くレッドラインを生み出します。

一歩引いて、より深いパターンが明確になります。アクセシビリティはエンジニアリングの成熟度の代理指標です。セマンティックHTMLを出荷し、フォーカスを管理し、状態を正しく露出し、CIでテストするチームは、家屋が整っているチームです。アクセシブルなコンポーネントを生み出すのと同じ規律が、メンテナンス可能で、テスト可能で、バグの少ないコンポーネントを生み出します。

開発およびプロダクトリーダーにとって、それが本当のビジネスケースです。アクセシビリティ作業はプラットフォーム作業です。機能がより速く、よりスムーズに出荷され、やり直しが少なくなるたびに、報われます。

スプリントではなくシステム

これから一つだけ取り上げるなら、これにしてください。アクセシビリティは、監査、ヒーロー、またはローンチ前の英雄的な修正スプリントから来るものではありません。システムから来るものです。

コンポーネントが最初から正しくなるアクセシブルなデザインシステム。それらが正しくあり続けるためのDefinition of Done。回帰がビルドを失敗させるための自動テストとCIゲート。それを所有する誰かのためのガバナンス。AI支援開発のためのガードレール——最速のツールが最大の負債になるのを防ぐためのもの。

これらのプラクティスのどれも、特に華々しいものではありません。それこそが、なぜそれらが機能するのかです。セキュリティ、信頼性、パフォーマンスのためにすでに信頼しているのと同じ種類の、退屈で信頼できるシステムです。

しかし、このリストのツールにできないことが一つあります。リンターも、自動スキャナーの実行も、ダッシュボードも、視覚障害者がスクリーンリーダーを使用して製品を使用する実際の体験や、震えでマウスが操作できないためにキーボードでチェックアウトを操作する体験を、決して伝えることはできません。 したがって、システムを構築してください——それらが必要であり、実際のリリーススケジュールとの接触でアクセシビリティが生き残る唯一の方法です。しかし、障害を持つ実際のユーザーとの定期的なテストも行ってください。チームが「完了」したと思っていたフォームを、JAWSを使用して誰かが苦戦しているのを初めて目の当たりにしたとき、何かが変わります。ツールは合格したかどうかを伝えます。実際の人は、それが実際に動作するかどうかを伝えます。

アクセシビリティは機能ではありません。それは運用上の能力です。そのように扱えば、開発およびプロダクトリーダーがすでに気にかけているものを得られます。より速く、より安全で、より信頼性の高いソフトウェアの出荷方法です。

Smashing Editorial (il, yk)