アクセシビリティは設計者の責任、A List Apartの提言から考える実務
Webデザインの世界的メディア「A List Apart」に掲載された記事「Good designers, bad websites: a proposal」が、デザイナーとアクセシビリティの関係を問い直しています。著者は「デザイナーは善意の人たちだが、結果的に誰かを排除するデザインが世に出ている」というギャップを指摘し、アクセシビリティ課題を認識するための仕組み（ペルソナの活用など）をデザインプロセスに組み込むべきだと提案しました。本稿ではこの提言を起点に、Webディレクターが現場で何を変えられるかを整理します。
「善意のデザイナー」と「排除するデザイン」のギャップ
記事の出発点はシンプルです。「読めないテキストでいい」「使えない人がいてもいい」と考えるデザイナーは存在しない。にもかかわらず、現実のWebには読みにくいコントラスト、操作しにくいフォーム、意味の通らないラベルが溢れています。著者はこのギャップの原因を、デザイナー個人の問題ではなく覚えるべきことが多すぎる（recallの問題）として捉えています。
アクセシビリティはW3CのWAI（Web Accessibility Initiative）が長年整備してきた領域で、現行の到達基準はWCAG 2.2です。基準は明文化されているのに、なぜ実装が追いつかないのか。著者はJakob Nielsenのユーザビリティ・ヒューリスティック「Recognition rather than Recall（記憶より認識）」を引き、デザイナーがアクセシビリティ課題を“認識できる”状態を作ることが鍵だと述べています。
アクセシビリティは「人の生死」に関わる
記事内で引用されているAral Balkanのエッセイ「This Is All There Is」では、バス時刻表アプリの例が挙げられます。時刻表が使いにくいと、利用者は娘の5歳の誕生日パーティーに間に合わないかもしれない、あるいは亡くなりゆく祖母に別れを告げる機会を逃すかもしれない、というものです。日常的なアプリやサイトも、設計の質次第で「ライフイベント」に直結し得るという視点です。
Webディレクター視点で言い換えれば、これはスコープ判断の問題として捉えられます。「アクセシビリティ対応はオプション扱い」「予算が余れば対応」という進行管理は、結果として誰かを排除する設計を量産するリスクがあります。Appleのアクセシビリティ指針やMicrosoftのアクセシビリティドキュメントでも、アクセシビリティはアプリ品質の中核要件として位置づけられており、Microsoftのドキュメントでは「アクセシビリティを中核品質要件として扱い、自動チェックを通常のエンジニアリングワークフローに組み込む」開発チーム向けのガイダンスであることが明示されています。
ブラウザ側の進化はアクセシビリティを後押ししている
一方で、ブラウザ側の機能はこの1年で前進しています。2026年5月にweb.devが公開した月次レポートによれば、新しいCSS擬似クラス:openがSafari 26.5での対応によりBaseline入りし、<details>や<dialog>、<select>等の「開いている状態」をセマンティックにスタイル制御できるようになりました。
また、<video>や<audio>要素にもloading="lazy"属性がChrome 148で導入され、画面外メディアの遅延読み込みでパフォーマンスを稼ぐことが容易になっています。これらはアクセシビリティそのものではないものの、「読みやすい・使いやすい」を標準機能として実装するハードルを下げる動きとして理解できそうです。
（なお元記事で言及されていたcontrast-color()関数はweb.devの当該月レポートで直接確認できなかったため、本稿では割愛しています。）
ディレクターが進行管理で組み込むべき3つの観点
著者の提言を実務に落とし込むと、Webディレクターが進行管理で組み込めるアクセシビリティの観点は次の3つに整理できそうです。
- 要件定義段階で対象ユーザーの幅を明示する — 色覚特性、スクリーンリーダー、キーボード操作、低速回線などを想定ユーザーに含める（著者はSarah Horton/Whitney Quesenberyらが整備したペルソナの活用を推奨しています）
- デザインレビューにコントラスト・キーボード操作を含める — Figmaのプラグイン等を活用し、デザイン段階で機械的にチェック
- テスト工程でWCAG 2.2のAA水準を最低ラインとする — 公開直前ではなく、実装中の継続チェックに組み込む
大事なのは、これらを「追加タスク」ではなく通常のレビュー項目に組み込むことです。アクセシビリティを別枠の工程にしている限り、予算やスケジュールの圧迫で真っ先に削られるリスクが残ります。
日本のWeb制作現場への示唆
日本のWeb制作現場でも、官公庁・自治体案件を中心にJIS X 8341-3への準拠が求められるケースが増えています。一方、民間サイトでは「対応していると謳いつつ実態が伴わない」状況も少なくありません。今回のA List Apartの提言は、個人の善意に頼らず、認識を助ける仕組みとして実装するという方向性を改めて確認するものとなりそうです。
ブラウザ標準機能の進化も追い風です。:open擬似クラスのようにセマンティックな状態をCSSだけで扱える仕組みが整いつつあり、エンジニアリングコストを抑えながら底上げできる選択肢が増えています。ディレクターとしては、最新のブラウザ機能を把握し、デザイン・実装フェーズの判断材料として提供することが価値になるとみられます。
まとめ
A List Apartの記事は、「デザイナーは善意でも、覚えるべきことが多すぎてアクセシビリティ課題を見落としがちだ」という構造的な問題を提起しています。Webディレクターにできるのは、要件定義・デザインレビュー・テストの各工程にアクセシビリティを正式な評価項目として組み込み、ペルソナ等を使って“認識”を助ける仕組みを用意することです。ブラウザ側の機能進化も活用し、属人的な善意ではなく仕組みでカバーする体制を、自分の関わるプロジェクトから始めてみてください。