視覚や聴覚、運動機能などに障害がある人や、高齢者、あるいは一時的に怪我をしているなど、さまざまな事情によってサイトの利用に困難がある人たちがいます。そうした人も含め、誰もがサイトやデジタルサービスを利用しやすい環境を整えることが、いま求められています。

近年、障害者差別解消法により「合理的配慮の提供」が義務化されました。Webアクセシビリティにおいても、「環境の整備」としての配慮がこれまで以上に重要視されています。一方で、「具体的にどのように取り組めばいいのか」「何から手を付ければいいのかわからない」という声も少なくありません。

そこで今回は、2026年6月に出版される『失敗例と成功例から学ぶ Webアクセシビリティの教科書』の著者である伊原力也氏、太田良典氏をお招きし、Webアクセシビリティが後回しにされる理由や、現場で起こりやすい失敗例について伺いました。

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

この10年で日本におけるWebアクセシビリティを取り巻く状況はどう変わったか

まずはじめに、日本におけるWebアクセシビリティを取り巻く状況は、現在どのように変化しているのか。2015年に出版された書籍の改訂版が刊行されるに至った背景から、現場で起きている課題や実態をひも解いていきます。

富本：2015年に出版した『デザイニングWebアクセシビリティ』の増補改訂版として、このたび、『具体例と解決策で学ぶ Webアクセシビリティの教科書』が出ます。改訂版を出そうと思ったきっかけから聞かせてください。

伊原氏：2024年に障害者差別解消法が改正され、「合理的配慮の提供」が民間事業者の義務となりました。これによって、Webアクセシビリティを意識する人たちも増えています。

そうした中で、Webアクセシビリティというものが以前に比べると知られつつある一方、「どのように取り組めばいいのか」を解説している本は、まだまだ少ないのが現状です。
企業のWeb担当者はWCAG（Web Content Accessibility Guidelines）（※1）やJIS X 8341-3（※2）を読むか、デジタル庁が公開しているウェブアクセシビリティ導入ガイドブック（※3）に目を通すことになります。ただ、ガイドラインだけでは実際にどう取り組めばいいのかイメージしづらい部分も多いんです。

そんな状況だからこそ、Webアクセシビリティについての本をあらためて出す意義があるのではないかと思ったのがきっかけです。

Webアクセシビリティの重要性は広まったが、改善はまだ不十分

富本：これはBAの話ですが、最近は大企業だけでなく中小企業からの問い合わせも増えている印象があります。徐々にですが、Webアクセシビリティの重要性の広がりを感じています。しかし、まだまだ「改善したつもりになっているけれど、できていない」というケースも多いのではないか……と思いますが、いかがでしょうか。

伊原氏：そうですね。率直にいえば、「改善したつもりになっているけれど、できていない」というよりも、「なんとなく重要そうな気がするけど、まだ何もしていない」というケースがまだまだ多いのだろうなと思っています。

太田氏：はい。実際に改善に取り組む企業も増えてきているとは思いますが、一方で特に中小企業ではまだ何もできていないという企業のほうが多いだろうというのが実感です。改善できている企業とまったく取り組んでいない企業とで、その差は以前より広がっているようにも思います。

伊原氏：厳しいことをいうと、正解がわからないからガイドラインだけ読んで、とりあえずわかる範囲でやる、というのが「取り組んでいるつもり」なんだと思います。最初の要件定義にアクセシビリティ要件が入っていたとしても、制作側が十分に理解できていないと、「ガイドラインに書かれていることはやったから大丈夫だろう」となってしまう。実際にWebアクセシビリティを必要とする障害者に使ってみてもらうというところまではしていないというケースがほとんどなんです。だから、使えない部分が残っていても気づけない。

太田氏：せめてスクリーンリーダー（※4）を試してみるとか、画面を拡大してみる、キーボードだけで操作してみるなどをやってみればいいのですが……。そうした確認すらしないままでは、Webアクセシビリティとは何かを十分に理解できません。結果として、なんとなく取り組んでいるだけの状態に陥ってしまいます。

アクセシビリティが十分に確保されていないサイトの「使いにくさ・使えなさ」とは

富本：なるほど。世の中の状況はよくわかりました。それでは、アクセシビリティが十分に確保されていないサイトでは、どのような「使いにくい・使えない状態」が起こりやすいのでしょうか？

太田氏：最も多いのは「スクリーンリーダーでアクセスしても何も読み上げられない」ということではないでしょうか。次いで、「見出しがちゃんと付いていないことで、利用者が得たい情報にアクセスしづらい」ケースもよく聞きますね。見出しが適切についていないと、ページの階層構造を理解できず、内容を把握しにくいですし、読み飛ばしができないので、目的の情報を得るために最初から全部聞く必要が出てきます。

他にも「サイト全体が派手に動いているんだけれども、肝心のコンテンツが目立っていなくて、どこを読めばいいのかわからない」なんてこともよく聞きます。サイトの利用者によっては、派手な動きに慣れていない方も多いんです。それを無視してしまうとコンテンツにアクセスすることが困難な場合もあります。そういった失敗例は無数に存在しますよ。

伊原氏：「色が薄くて見えない」「ボタンがあることに気づけない」といったケースも目立ちます。聴覚障害者が困ってしまう例でいうと、「サイト内の動画にキャプションやテロップが付いていない」ということもあります。

太田氏：動画に字幕を付けないと理解できない人がいる、というのは比較的私たちも想像しやすいですよね。しかし、中には想像しにくいものもあるんです。例えば、視覚障害者の中にはサイトの画面を拡大しながら利用している人もいるんですが、そういうことってなかなかイメージしにくいですよね。左が行頭で、左から右へコンテンツをで読む場合に、画面を拡大していると、画面の右側に大事なボタンがあっても気づかずに見落としてしまうことがあります。それによって、先に進めない状況に陥ることがあるんです。

• ※1 WCAG
  主に障害者のためにWebコンテンツのアクセシビリティを向上させるための一連の推奨事項をまとめたもの
• ※2 JIS X 8341-3
  日本産業規格（JIS）のひとつで、Webアクセシビリティに関する日本国内の標準規格であり、WCAGをベースに策定されている
• ※3 ウェブアクセシビリティ導入ガイドブック
  デジタル庁が、ウェブアクセシビリティに初めて取り組む行政官や事業者向けに、ウェブアクセシビリティの考え方、取り組み方のポイントを解説する、ゼロから学ぶ初心者向けのガイドブック
• ※4 スクリーンリーダー
  パソコンやスマホの画面上の文字、情報を音声や点字に変換するソフトウェア

Webアクセシビリティの向上は、ユーザー全員に快適さをもたらす「基本品質」

富本：Webアクセシビリティは障害者向けの特別な機能というイメージと結びつきやすいのも問題だと感じています。追加コストを支払って行う特別対応と捉えられ、後回しにされてしまうことがあります。

太田氏：そういう人たちはつまりWebアクセシビリティを品質の向上とは捉えていないんですよね。もちろん、基本的には何らかの障害がある方が使いやすくするための対応なんですが、それによって障害者だけではなく、障害のない人にも使いやすくなることは事実。

これはWebに限った話ではないと思いますが、障害者が、あるサービスを快適に利用できるとなった時、それを一緒に使う私たちにも快適さがもたらされることがあるし、そうじゃなくても一緒に使えるだけで幸せな気持ちになれたりするじゃないですか。そういった面は無視しないでほしいなと思います。

伊原氏：例えば怪我をして一時的に手を使えないとか、メガネを忘れて見えにくいとか、イヤホンを忘れて音を出せないとか、さまざまな理由でサイトを利用しにくい状況って誰にでも起こることだと思うんです。だからそうやって使いやすくすることは、利用者全員のため。特定の利用者向けでもあり、同時に基本品質でもある。その両方だと私は考えています。

Webアクセシビリティを後回しにしないために押さえたい3つのポイント

Webアクセシビリティの向上が後回しにされやすい背景には、実装知識の不足だけでなく、要件定義に含まれていないこと、制作プロセスの後半で改善に取り組もうとすること、そして組織全体で「基本品質」として共有されていないことがあります。

ここからは、アクセシビリティを意識した制作において、どのようなポイントで失敗が起こりやすいのかを聞いていきます。

ポイント①：制作段階でやりがちな実装に関する失敗例

富本：まずは、制作現場でよく起こる実装ミスの例を教えてください。

伊原氏：いちばんよく見られるのは「HTMLをちゃんと書いていない」というケースですね。その中で、「alt属性の設定ミス」もあります。これらは制作段階でやりがちな実装上のミスのひとつで、意味的に正しいHTML（セマンティックHTML）になっていない状態です。

このことがなぜ重要かというと、意味的に正しいHTML（セマンティックHTML）を書くことで、情報の意味や順序をスクリーンリーダーに伝えるからです。よくあるミスの例としては、例えば次のようなものがあります。

• 見出しとして見えるが、見出しタグが使われていない
• 表に見えるが、tableタグが使われていない
• アイコンに適切な代替テキストやラベルが設定されていない

特にアイコンについては、読み上げできない状態になっているケースが多く見られます。これは主に2つのパターンがあります。ひとつは、img要素で実装されているにもかかわらず、alt属性（※5）による代替テキストが設定されていないケース。もうひとつは、divタグなどでアイコンが実装されており、aria-label（※6）などのラベルが付与されていないケースです。

本来であれば、実装方法に応じて適切な代替テキストやラベルが設定されていれば、スクリーンリーダーで判別することができます。しかし、それらが設定されていない場合、スクリーンリーダーからは「そこには何もない」という扱いになってしまいます。その結果、ユーザーはその機能の存在自体に気づくことができません。

太田氏：最近よくあるハンバーガーメニューがそうなっているケースが非常に多いですね。3本線を押すとメニューが出てくる形式のものですが、その3本線にalt属性もaria-labelなどのラベルも付いていないから、スクリーンリーダーを使う方は気づけないんです。

伊原氏：逆に、Webアクセシビリティを意識するあまり、やりすぎてしまっているケースもあります。例えば、「すべての要素にaria-labelを付けてしまう」とか、「tabindex（※7）を付けまくる」とか。

太田氏：そういうのもすべてスクリーンリーダーを使ってテストすれば、おかしいことに気づけるはずなんですが、それをしないままリリースしてしまっているんでしょうね。

ポイント②：プロセスや体制における失敗例

富本：アクセシビリティを向上するうえでの問題は、プロセスや体制において起きることも多いと感じています。

伊原氏：Web制作会社の現場では最近どうなのか、まずは富本さんに聞きたいです（笑）。

富本：最近はクライアント側から「アクセシビリティやらないとダメなんでしょ」と聞かれることは増えたのですが、何をやればいいのか、どのタイミングでやるのかなど、細かいところまではわかっていないケースが多いですね。だからこそ、要件やコストも含めて最初にしっかり説明することが肝心だと考えています。

太田氏：10年前に比べたらずいぶん変わりましたね。クライアントが「アクセシビリティを確保しなければいけない」という前提でいてくれるんですから。

伊原氏：対応プロセスで一番困るのは、最初の要件に入っていなかったのに、最後の最後になってやっぱり必要でしたってなることですよね。

あと、発注側がWebアクセシビリティ適合レベル「A（シングルエー）」の意味を十分に理解しないまま依頼し、制作会社側も「最大限努力します」という形で進めてしまうケースもあります。その結果、ページを開いた瞬間から動き続ける要素が残るなど、実際には適合レベルを満たせていない状態で公開されてしまうこともあるんです（笑）。

太田氏：「A（シングルエー）」の条件を自分なりの解釈で対応してしまっていて、クライアントとの間で噛み合わないということはありますね。

伊原氏：要件定義する人が達成基準のことを理解していないと、こういうことになりますね。

太田氏：もう1つ問題になりやすいのが、かなり最初のほうでビジュアルデザインの方向性だけが決まってしまっているケース。こういう動きをつけたい、みたいなことが最初に決まってしまってそのまま進んでいってどうにもならなくなっていることがある、というのを聞いたことがあります。

ポイント③：「後で取り組めばいいや」が失敗を大きくする例

富本：もうひとつ揉めやすいのが、昔つくったサイトを、あとからアクセシブルにする場合だと思うんですが……。

太田氏：どのサイトもアクセシブルにするためにはコアな部分に手を入れる必要があるということなんですよね。その会社のサービスや製品のコアな部分、お金を生み出している部分だったりすると、止まると問題なので、みんな触りたくないんです。

伊原氏：コアの部分を変えるためには相応の工数がかかるので、ずっとそのままだったりすることがあります。「使えているんだからいいじゃないか」と言われたら、こちらからは強く出られませんし。何かあった時には責任問題にもなりますからね。かなり強い意志がないと変えられないですね。

太田氏：そうなると最初からアクセシブルにつくるしかないんですよ。

伊原氏：でも、これがまた難しいんです。事業会社のサービス開発だと、まずは早く立ち上げて、うまくいかなければやめたり方向転換したりできるように、スピード重視で進めることが多いですよね。そうなると、初期段階ではアクセシビリティへの配慮が後回しになりやすい。ところが、この状態でサービスが成長してしまうと、アクセシビリティを考慮したつくりに後から直すのが難しくなってしまうんです。

太田氏：技術的負債の解消にどこかのタイミングでコストをかける必要があると。サービスの成長痛みたいな話はどこの企業にもありそうですね。

• ※5 alt属性
  主にWebの画像に付ける代替テキスト
• ※6 aria-label
  見た目にはテキストが存在しないアイコンやボタン、リンクなどに対して、スクリーンリーダー等が読み上げるアクセシブルな名前を指定する属性
• ※7 tabindex属性
  タブキーによるフォーカスの移動順序を設定するための属性

Webアクセシビリティ向上に成功するプロジェクトの共通点

富本：Webアクセシビリティ向上に成功しているケースの共通点はあるのでしょうか？

伊原氏：例えば、私が以前在籍していたフリー株式会社が提供するクラウド会計ソフト「freee会計」では、スクリーンリーダーを活用して確定申告している人もいました（※）。また、フリー社には全盲の社員がいて、「freee人事労務」を使って問題なく勤怠打刻ができていると話していました。

フリー社以外でも、成功例に共通するのは、制作チームに障害者が入っていることです。そうしたチームでは、Webアクセシビリティを他人事だと捉えていないんです。何かを開発するとしても、まずは自分たちのチームメンバーが問題なく使えるようにしたいよね、というところからスタートしている。

それから、開発に携わるメンバー全員が最初から最後までWebアクセシビリティを気にしているというのも共通点でしょうね。アクセシビリティはエンジニアの実装で担保されるものだとか、デザイナーの領域だとか、限定するとうまくいかない。

太田氏：その点から考えても、チームメンバーに障害者がいれば当然、全員が困難のある人と会うことになるので、意識も変わるでしょう。それが難しいとしても、ユーザビリティテストを全員で見るだけでも違うはず。実際にWebアクセシビリティを必要とする利用者がいて、どんなことで困っているのかがチーム全体で共有できているかどうかが鍵だと思います。

富本：Webアクセシビリティ向上を成功させるうえで、必ず押さえておきたいポイントがありそうですね。改めて教えてください。

• ※「freee会計」のスクリーンリーダーを活用して確定申告の事例（参照 2026-05-11）
  • スクリーンリーダーで、すべて読み上げてくれる。すべてのボタンが反応する。freee会計なら、問題なく使えます。 - 導入事例 - freee
  • 「苦痛でしかなかった」 freee会計で変わる、全盲の鍼灸師の確定申告 - 導入事例 - freee

共通点①：アクセシビリティを最初の要件に入れておく

伊原氏：もっとも大切なのは「最初からアクセシビリティを念頭に置いておくこと」です。デザイン修正と一緒で、最初の要件になかったものを後から加えるのはとても難しい。最初から決めておかないと、余計に手間も時間もかかります。また、最後にまとめてチェックすればいいや、という考え方も間違いです。要件定義書に入れておき、設計段階から考えることが重要なんです。

共通点②：発注側が注意すべきは、アクセシビリティを理解している制作会社選び

富本：発注側が意識すべきポイントもありそうですね。

伊原氏：発注側にとって重要なのは制作会社選びです。アクセシビリティへの知見があるということでその会社に決め、Webアクセシビリティガイドラインを渡して、それに基づいたサイトの制作を依頼したはずなのに、最後の最後でコントラストチェックだけをして「アクセシビリティに配慮して制作しました」と納品されてしまうとか。そういう事故が発生しがちなんです。

肝心なのは、過去にどんなWebアクセシビリティ改善をおこなってきたのか、今回の事例には何を取り入れていったほうがいいと考えているのかなど、具体的に確認をしておくべきです。その中で、制作会社の担当者がどれくらいWebアクセシビリティを理解しているのかを見極めるといいでしょう。

太田氏：そもそもちゃんと要件定義書をつくれるか、プロジェクトマネジメントができるか、ということもポイントですね。これはアクセシビリティに限った話ではありませんが。

共通点③：アクセシビリティを継続的に維持・改善していくための取り組み

富本：リニューアルや新規立ち上げを行ったサイトのアクセシビリティを保った状態で維持・運用していくためには、どのような取り組みが必要でしょうか？

伊原氏：つくったコンテンツを後から直していくのは手間がかかるので、コンテンツ制作のテンプレートにWebアクセシビリティを含めてしまうことが肝要だと思います。引き継ぎ資料や運用ガイドラインにも明記しておいて、どんな人が担当者になったとしても最初からWebアクセシビリティを意識するようにしておくと、後手後手になることも防げるでしょうね。

太田氏：細かい話ですが、運用上のよくあるミスとしては、画像を差し替えた際にalt属性を付け忘れてしまうなどが考えられます。そういったことを避けるためにも、運用ガイドラインの整備と徹底が重要です。

まとめ：Webアクセシビリティはみんなのためのもの

ここまで見てきたように、Webアクセシビリティの重要性は広く認識されつつある一方で、改善に向けた取り組みはまだ十分には進んでいないのが現状のようです。

「重要だとはわかっているが、何から手をつければいいのかわからない」
「改善しているつもりでも、実際には不十分になっている」

こういった課題が、多くの現場で見られます。
だからこそ重要なのは、後から改善に取り組むのではなく、要件定義や設計の段階からアクセシビリティを組み込むことです。ガイドラインを読むだけでなく、実際のユーザーに触れながら検証していくことで、はじめて実効性のある改善につながります。

Webアクセシビリティは特定の人のためだけのものではなく、結果としてすべてのユーザーにとって使いやすい体験を生み出します。その価値を実現するためにも、最初から取り組むという視点が欠かせません。

今回紹介したような具体的な考え方や実践のヒントは、書籍『具体例と解決策で学ぶ Webアクセシビリティの教科書』にも詳しくまとめられています。現場での取り組みを進めるうえでの参考として、ぜひ手に取ってみてください。

『具体例と解決策で学ぶ Webアクセシビリティの教科書』

発売日：2026年6月16日
著者：伊原力也、太田良典、秋山豊志、佐野実生、富本弥生、平尾優典、堀口真人
発行：ボーンデジタル
金額：￥3,960（税込）