前編では、5月21日にGAAD（Global Accessibility Awareness Day）を迎えることをきっかけに、アクセシビリティ対応がうまくいかない理由や、制作現場における誤解について掘り下げました。

後編ではそこから一歩進んで、アクセシビリティを制作プロセスの中でどう実現し、どう継続していくのかを掘り下げます。前編に引き続き、アクセシビリティスペシャリストとして活躍する伊原 力也氏、太田 良典氏を迎え、Business Architects（ビジネス・アーキテクツ、以下BA）でCDO（Chief Design Officer）を務める森との対談をお届けします。

※本記事でいう「障害者」とは、医学的な診断の有無に関わらず、社会の環境や仕組みによって不便や制約を受けるすべての人を指します（障害の社会モデルの考え方に基づいています）。

より多くの人が利用しやすい状態を目指すには、全体を見て判断できる人が欠かせない

アクセシビリティの向上を実現するためには、設計やデザインを含め、プロジェクト全体でどのようなことを意識すべきでしょうか？

伊原氏：アクセシビリティはコンテンツにも、IA（情報アーキテクチャ）にも、デザインや実装にも関わります。エンジニアやデザイナーといった各プロセスの担当者それぞれが、アクセシビリティについて意識するのは間違いではありません。

ただ、それぞれの持ち場で「自分なりのアクセシビリティ」を持ち寄るだけでは、最終的な解決策にならないと思います。一定以上の品質を担保するなら、アクセシビリティに理解がある人が全体を見ながら方向づけていく必要があるでしょう。

太田氏：たしかに、ユーザビリティやセキュリティといった非機能要件と同じことがいえますね。そうした基本的な品質の部分は、発注側としては、プロに依頼すれば一定のレベルで担保してくれるだろうと期待しているはずです。その期待に応えるには、特定の職種だけでなく、制作プロセス全体を見渡して判断できる人が必要になるのだと思います。

伊原氏：その人がすべてを作るという話ではなく、プロジェクトで何が行われているのかを把握することが重要です。それができれば、筋が悪いプランが検討されていても、未然に防げるようになりますから。

太田氏：そもそも最初からアクセシビリティに反するプロジェクト計画が組まれていると、設計やデザインのレベルでは吸収しきれないことが多いですしね。

森：手戻りの工数を考えると、やはりプロジェクトの計画段階でアクセシビリティの方針を固めるべきだとあらためて思います。その後は、どうしても判断がブレる場面も出てきますので、プロジェクト全体を俯瞰できる人が指針を示し続けることが必要なのでしょうね。

個々人の理解や経験値にブレがあっても品質を担保するには？

アクセシビリティについて、いかにプロジェクト開始時に足固めをするか、そしてその方針をいかに維持していくかが重要だと理解しました。一方で、実際の現場では個々人の理解や経験値にも差があります。そうしたブレがある中で、品質をどう担保していけばよいのでしょうか。

伊原氏：アクセシビリティへの取り組みは、どうしても個々人の理解や経験値によってブレが出ますし、1人が十分に理解していても、組織内のさまざまな力学の中で、結果的に非合理なWebサイトができてしまうこともあります。

本来は、プロジェクトに関わる全員がアクセシビリティを前提に、要件定義やデザイン、実装を考えられるのが理想です。ただ、現実にはそれが難しいからこそ、ガイドラインやチェックリストがあるわけですが、それも十分に機能しているとは言いがたい。前編でもお話ししたように、「誰にとって何が必要なのか」という理解が不足していると、チェックそのものが形骸化してしまうんです。

そう考えると、なるべく個人の理解や判断が介在しないようにすることが現実的な解になるのではと考えています。

森：それはつまりデザインシステムなどを活用して、品質を仕組みとして担保するということでしょうか？

伊原氏：そうです。アクセシブルなコンポーネントを適切に組み合わせてページや画面を作る。もちろん、そこに含まれるコンテンツも大事ですし、ラベルもAltも人間が記載する必要はありますが、アクセシビリティという「制約」がなされたコンポーネントを使うことが、ベストプラクティスであるのは間違いないと思います。

さらに近年は生成AIで品質維持を図る取り組みも進んでいます。アクセシブルなコンポーネントを、アクセシブルな形で組み合わせる。そして、ルールに基づいてコンポーネントが使われているかを生成AIでチェックするという流れが、現時点で最もモダンなアプローチではないでしょうか。

すでにアクセシビリティを前提に設計されたものを使うことで、個人の理解だけに頼らず、一定の品質を担保しやすくなるわけですね。

伊原氏：そのとおりです。ただし、仕組みを活用するにしても、 最低限「なぜそのように設計されているのか」は理解してもらいたいですね。

太田氏：最近は「とりあえずアクセシビリティオーバーレイ（※）を導入すれば解決するだろう」と考える方がいるのも気になっています。前編からの繰り返しになりますが、ユーザーとなる障害当事者の方への関心は忘れてほしくありません。

森：アクセシビリティを継続的に改善していくためにも、「そもそも」の部分を腹落ちさせることが大事ですね。「ガイドラインに書いてあるから」「オーバーレイを入れておけば大丈夫だから」という姿勢では、改善が一過性のものになりかねませんから。

※アクセシビリティオーバーレイ
サードパーティのスクリプトを読み込むことで、見た目や操作性を調整しアクセシビリティの改善を試みる仕組み。ただし、既存の構造や実装の問題を根本的に解決するものではなく、導入だけで十分なアクセシビリティを実現できるわけではないと指摘されることも多い。

制作プロセスで議論になりがちなポイント

ここで、実際の現場でよく議論になるポイントについて伺えたらと思います。制作していく中で発注側と揉めたり、判断が難しいなと感じたりするポイントには、どんなものがありますか？

ブランドカラーとコントラスト基準の衝突

森：よくあるのは企業のブランドカラーがコントラスト基準と衝突するケースです。ブランドを守ることも、アクセシビリティを優先することも大切ですが、まずは「その情報がユーザーにきちんと伝わるか」という点で判断することが多いです。背景を調整したり、文字のサイズを変えたり、ブランドカラーを使用する場所を限定するなどして、「こうすれば読めるようになりますよね」と体験ベースで提案するようにしています。

太田氏：「文字にブランドカラーを適用しなくていいのでは」という話もありますね。ブランドカラーはあくまでブランド認知のためのものなので、文字まで無理にブランドカラーを使わなくてもいい。それでもブランドカラーにこだわるのであれば、文字専用の「ブランドカラーに近い別のカラー」を定義する、という方法もあります。

伊原氏：リンク色をブランドカラーにする必要もないですよね。「赤はエラー」など特定の意味をもつ色、いわゆるセマンティックカラーがあるのに、ブランドカラーが赤だからと文字もリンクもロゴも赤にすると、何がエラーなのかわからなくなりますね。

太田氏：ブランドカラーにこだわるあまり、ユーザーに「読みにくい」「わかりにくい」という体験をさせることが、ブランドにとってどういうイメージをもたらすのかを考えてほしいですね。

ブランドカラーそのものを少しずつ見直していくアプローチもあります。私が在籍している弁護士ドットコムという会社では、弁護士ドットコムというサービスのロゴをリニューアルする際に、アクセシビリティを考慮して少し濃い色を選択しました（※）。

クラウドサインという電子契約のサービスもあるのですが、こちらもブランドカラーを何度か変えていて、そのたびに少しずつコントラストが強くなっています。ブランドの連続性を損なわない範囲で、少しずつアクセシビリティを高めていくというやり方もあるのです。

※弁護士ドットコム、アクセシビリティ対応でブランドカラーを変更 | 弁護士ドットコムがアクセシビリティに本気で取り組む狙い. Web担当者Forum. (参照 2026-05-08)

色だけで状態を伝えるUIの問題

先ほどセマンティックカラーの話もありましたが、エラー表示や選択状態など、色だけで状態を伝えるUIには、アクセシビリティの観点でどのような問題が起きやすいでしょうか。

伊原氏：フォームのエラーを、入力欄を赤くすることだけで伝えている、といったUIはいまだにありますよね。赤色が認識できない状況ではエラー箇所がわからなくなってしまいます。あとはグラフなどの図版でもよく見かけます。色分けされたグラフに対し、凡例で「赤がA社」と説明しているために、色の違いを認識できない方はどれがA社のデータかわからない、とか。

森：デザインレビューでも、こうした「見ればわかる前提」のUIが出てくることがありますね。 たまに「他社がやっているからいいじゃないですか」と参考事例を見せられることもあるんです。事例として存在するのはわかりますが、それが使いやすいかは別の問題なんですよね。

太田氏：アクセシビリティの問題というより、ユーザビリティの問題に近いかもしれないですね。どこがボタンとして押せるのかわからないデザインが出てくることも結構ありますから。作っている人は知っているから、「押せる」と思ってしまうんでしょうけど。

伊原氏：アクセシビリティにしろ、ユーザビリティにしろ、「自分を基準にすべきじゃない」ということですよね。自分の見えるもの、感じ取れるものこそが「正」という感覚の人がまだまだ多い。色の差がわかりにくいとか、視力が弱いとか、見えづらい環境にいるとか、そうした状況で本当に使えるのかを試してほしいと思います。

発注側のWeb担当者は何を意識すべきか

発注側のWeb担当者として、制作会社とアクセシビリティに取り組むうえで、特に意識しておくべきことはありますか？

太田氏：発注する際は、アクセシビリティについての要件をしっかり盛り込むべきです。「プロなんだから勝手にいい感じにやってくれるだろう」と思わないほうがいい。

伊原氏：あとは、お互いのケイパビリティ（能力・スキル）を包み隠さず伝えることですね。「やってくれると思ったのにできていなかった」というすれ違いを防ぐ意味でも、アクセシビリティについてお互いどういう認識でいるか、過去にどういった実績があるのか共有したほうがいいでしょう。

太田氏：それと、制作プロセスの中では、1回でもいいので障害当事者の方にWebサイトを見てもらうといいですよね。

伊原氏：まずは自分の会社にアクセシビリティを必要とするユーザーがいるのではと考えて、実際にそういう方がいれば会ってみること。通常のユーザーインタビューと同様の手順で、障害者の方を探すのもいいでしょう。

太田氏：いろいろな方にWebサイトを見せたときに、「これとこれは一緒の色でしょ？」とか「ここに区切りなんてあるの？」と言われると、何がいけないのかを実感できます。

伊原氏：アクセシビリティが考慮されていないと、本当に見分けがつかないということがわかりますよね。制作側は当たり前に見分けられるものとして作っていますから、最初は信じられないでしょうね。

太田氏：スクリーンリーダーに読み上げてもらうのもオススメです。実際に「このページには見出しがありません」と読み上げられる光景を見たら、見出しのマークアップや画像の代替テキストの重要性が実感できるはずです。

伊原氏：ガイドラインに則って制作する企業でも、障害者に使ってもらうところまではできていないことがほとんどです。障害者に会って、ガイドラインや書籍に書かれている状況を実際に目の当たりにする。そこでようやく、アクセシビリティについて考えられるようになるのだと思います。

まとめ：アクセシビリティに継続して取り組むために

今回、GAAD（Global Accessibility Awareness Day）をきっかけに、前後編にわたってWebアクセシビリティについてお話を伺いました。前後編を通して見えてきたのは、アクセシビリティはガイドラインやチェックリストだけで実現できるものではない、ということです。ユーザー理解がないままでは、要件定義や設計、実装、運用のどこかで判断がぶれ、取り組みが形だけのものになってしまいます。

より多くの人が利用しやすい状態を目指すには、プロジェクト全体を俯瞰して判断できる体制を作ること、コンポーネントやデザインシステムなどを活用して仕組みとして支えること、そして制作会社と事業会社が認識をすり合わせながら進めることが欠かせません。

そして何より重要なのは、実際にアクセシビリティを必要とするユーザーの利用状況に触れることです。ガイドラインや書籍を読むだけでは見えてこないことも、障害者の声や利用の様子に触れることで、はじめて実感を伴って理解できるようになります。

GAADは、そのきっかけのひとつにすぎません。日々の制作と運用の中で継続して向き合っていくことが、結果として、より多くの人にとって使いやすい体験につながっていくのではないでしょうか。