初めまして、Keiです。３０代です。デフエンジニアアドベントカレンダーに参加しています。
普段はWEB関連の仕事をしています。
デフエンジニアの会にも前から入っていますが、デフエンジニアの会で活発に動く方は皆さんAIやらがっつりエンジニアとかそんな感じで、ちょっとWEBとしては遠慮気味・・・でしたが、最近ではWEBアプリやHP作成などの記事も出てきていてほっとしています・・・笑
WEBも大事なことなので、皆さんにはWEBにも興味を持ってほしいです笑
こちらからは、障害当事者の目から見たアクセシビリティについてつらつらと書いていきたいと思います。
あくまでも個人の視点・感想なので、よろしくお願いします。
HP制作に求められる本当の配慮とは
2025年、アクセシビリティという言葉は企業、行政、教育のあらゆる場面で当たり前のように使われるようになりました。
ガイドライン、合理的配慮、WCAG、アクセシブルデザイン。
これらは表向きの整備が進み、アクセシビリティは「やっている企業が当然」という空気になっています。
しかし、障害当事者の視点で見ると
- ガイドラインに準拠していても実際には使えない
- 配慮しているように見えても情報に到達できない
という問題がまだまだ残っています。
アクセシビリティとは
「親切さ」ではなく「設計」
「特別扱い」ではなく「全員の使いやすさ」
そして何より
「実際に使えるかどうか」
がすべてです。
この記事では、障害者当事者の視点から
（1）2025年のアクセシビリティの実情
（2）障害の種類別に見た、使いやすいHPとは何か
（3）HP制作で起きている典型的な落とし穴
（4）本当にアクセシブルなHPを作るためのポイント
をまとめます。
1. 2025年のアクセシビリティの実情
形だけが進み、中身が追いついていない現場が多い
アクセシビリティへの関心は確かに高まりました。
しかし当事者から見ると、次のような問題が数多く存在します。
● ガイドライン準拠なのに使えない
- リンクにaria-labelが入っているが意味が伝わらない（例：「詳細」だけで何の詳細か分からない、ボタンが複数あるのに全て同じラベルなど）（視覚障害の人が困る）
- フォーカスは移動できるが操作の目的が分からない（視覚障害の人、片手操作の人が困る）
- 字幕はあるが内容が正確ではない、話者の区別ができない、感情やニュアンスが伝わらない（聴覚障害の人が困る）
- 音声読み上げ対応はあるが情報が飛びまくる（視覚障害の人が困る）
● デザインを優先しすぎて、実際には読みづらくなっている
- 文字が薄い（コントラスト比がWCAG 2.1のAA基準である4.5:1を満たしていない）（弱視の人、高齢者、色覚特性のある人が困る）
- 余白が少なく情報が詰まりすぎている（発達特性のある人、知的障害のある人が困る）
- ボタンが小さくタップしづらい（片手不自由の人、手の震えがある人、スマホ利用者が困る）
- 画像に説明がない（視覚障害の人が困る）
● JavaScript中心のサイトで情報更新が伝わらない
- SPAでページ遷移が分からない（視覚障害の人が困る）下記※１参照
- モーダルが閉じられない（視覚障害の人、片手不自由の人が困る）
- エラーが画面の一部に赤字で出るだけで気づけない（視覚障害の人、発達特性のある人が困る）
● 自動字幕だけで済ませるケースが多い
- 自動字幕は誤字が多い（聴覚障害の人が困る）
- 専門用語、固有名詞、数字を誤って表示する（聴覚障害の人が困る）
- 字幕と音声内容が一致しないことがある（聴覚障害の人が困る）
- 手話動画は自動字幕では表現しきれない（聴覚障害の人が困る）
・・・などなど。
こうした問題は、ガイドラインのチェックでは分からず、当事者が初めて気づくものばかりです。
そのために、当事者がどんどん声を上げて、当事者が開発の時点で携わっていく必要がある！
なので、当事者こそWEBエンジニアやHPコーダーなど・・WEBの分野にがっつり入っていくべきです！
2. 障害の種類別に見た「使いやすいHP」とはどのようなものか？
アクセシビリティは一枚岩ではありません。
障害の種類によって必要な配慮は大きく異なります。
● 聴覚障害者にとって良いHPとは？
- 動画には必ず正確な字幕
- 字幕だけでなくテキスト説明も用意
- 自動字幕に頼らず、人がチェックする
- 音声ガイダンス以外の手段がある
- 画像や図解の解説が文章でも分かる
- 問い合わせに電話しかない企業は利用困難なので、メールフォームも設置する
- 字幕が早すぎたり省略されていないか確認 ・・・など。
聴覚障害者にとって理想のHPとは
「音声に頼らず、文章と視覚だけで同じ情報に到達できるサイト」 です。
● 視覚障害者にとって良いHPとは？
- 画像に意味のあるalt
- 見出し構造（h1→h2→h3）を正しくする
- ボタンやリンクに役割（意味）がある
- フォームにlabelがあり読み上げても分かる
- エラー発生時に読み上げがきちんと反応
- コンテンツ更新をaria-liveで通知
- リンクテキストが「こちら」になっていない
- 装飾目的の要素は読み上げ対象から除外
- ページ遷移が分かるようにする ・・・など。
視覚障害者にとって理想のHPとは
「読み上げだけで内容、構造、操作が理解できるサイト」 です。
● 片手不自由の方にとって良いHPとは？
- ボタンが指一本で押せる大きさ
- リンクの間隔が十分にあり誤操作を防げる
- スワイプ操作に依存しない
- フォーム入力が最小限
- 片手でTab移動しやすい構造
- コピー＆ペーストがしやすい
- メニューの開閉が片手でも簡単 ・・・など
片手不自由の方にとって理想のHPとは
「片手でもストレスなく操作できるサイト」 です。
このように、障害ごとに困っていること、求めている配慮は様々ですが、こういったあらゆる要求に応えられるHPをまず第一に考えていくべきだと思います！
難しいことではありません。これらが対応できないものを外していくだけで良いです。
3. HP制作で起こりやすい典型的な落とし穴
意図せず当事者が置き去りになるポイントとは・・・
- デザインを優先しすぎて読みにくくなる
- 自動字幕だけでアクセシブルだと思い込む
- キーボード操作が保証されていない
- aria属性だけ入れて意味が破綻している
- SPAなのに読み上げスムーズに進まない
- モーダルが閉じられない
- エラーメッセージが視覚情報のみ
- フォーカスが迷子になる
どれも制作者には気づきにくいけれど、当事者にとっては致命的です。
4. 本当にアクセシブルなHPを作るために必要なこと
最重要なのは技術よりも「想像力」！
もちろん技術的には
- 正しい見出し構造
- alt、aria属性の適切な指定
- キーボード操作保証
- フォーカス管理
- コントラスト比（WCAG 2.1 AA基準：通常テキストで4.5:1以上、大きなテキストで3:1以上）
- 字幕とテキスト説明
- JS更新時のaria-live
- 分かりやすいエラーメッセージ
などは必須です。
しかし、もっと大切なのは
「このHPを使う人は、どんな状況で、どんな困りごとがあるのか」
を想像することです。
- 音が聞こえない人はどう受け取るか
- 文字が読みにくい人はどう感じるか
- 片手しか使えないとき操作しやすいか
- 読み上げだけで迷わず行けるか
- 情報に確実に辿りつけるか
- 混乱する導線はないか
アクセシビリティとは、特別な支援ではなく 「すべての人が同じゴールに到達できる設計」 です。
まとめ
- 2025年はアクセシビリティが義務に近いレベルで求められている
- ガイドラインだけでは当事者の困難は解決できない
- 障害ごとに必要な配慮は大きく異なる
- 自動字幕は不正確で、聴覚障害者にとってアクセシブルではない
- 視覚障害者には読み上げで理解できる構造が必要
- 片手不自由の人には操作負担の少ないUIが必要
- 本当にアクセシブルなHPとは、誰にとっても迷わず使えるHP
- アクセシビリティは企業姿勢の表れであり、品質そのもの
アクセシビリティは 「誰かのため」ではなく「全員のため」。
HP制作に携わるエンジニアが、使う人の状況を想像し、すべての人に届く情報設計を行うことが、今の時代に求められる本当のアクセシビリティです。
ここからは※１の説明です。
● SPA（Single Page Application）とは
簡単に言うと画面全体を切り替えず、ページの一部だけを書き換えて動くWebアプリのこと。
React、Vue、Svelte、Next.jsなどで作られる、いま主流のタイプです。
● 問題：画面は変わるのに「変わった」ことが伝わらない
SPAはページ全体を読み直さないから、適切に実装しないと
- URLが変わらない（または変わっても通知されない）
- 画面タイトルも変わらない
- ページ読み込みイベントも発生しない
という状態になります。
※最近のSPAフレームワークやルーティングライブラリ（React Router、Vue Router、Next.jsのApp Routerなど）は履歴API（History API）を使ってURLを変更する機能を持っていますが、それだけではスクリーンリーダーに「ページが変わった」ことは伝わりません。
その結果、
→ スクリーンリーダーは「ページが変わった」と認識できない
視覚障害の方は、スクリーンリーダーが
「ページが変わりました」
「新しい見出しがあります」
「ここがメインコンテンツです」
みたいな案内を頼りにしています。
でもSPAはアクセシビリティ対応が不十分だとページ読み込みを伴わないので、
画面が変わったことをそもそも通知しない
という状態になりやすいです。
● 例：ショッピングサイトのSPA
左のメニューで「Tシャツ」を選ぶ
→ SPAの場合、ページ全体の再読み込みなしで商品一覧だけ書き換わる
視覚障害の人からすると
- 画面が更新されたことが分からない
- 何の商品が表示されたのか案内がない
- どこにカーソルが移動したのか不明
- 「いつのまにか別のコンテンツになっていた」状態になる
つまり 実質的なページ遷移があるのに、遷移通知が存在しない。
これが
「SPAでページ遷移がわからない」
という意味。
● さらに言うと
SPAでは、モーダルの開閉やエラー表示、コンテンツの更新など、あらゆる動きが静かに起きてしまいます。
そのため、
- 気づかないまま操作が終わっていた
- 見えていないのに"画面が何か言っている"状態
- 押せるボタンの位置が突然変わる
- フォーカスが迷子になる
みたいなトラブルが起きます。
● 解決するためには？（これがアクセシビリティ実装の肝）
SPAでは以下が必要になる。
- aria-liveでコンテンツ更新を通知
- document.titleを動的に更新してページタイトルを変更
- ルート変更時にフォーカスをメインコンテンツに移動（フォーカス管理）
- role="main"などのランドマークを適切に配置し、ページ遷移時にスクリーンリーダーが認識できるようにする
- 見出し構造を動的に更新
- ランドマーク（main, nav）を切り替える
これらを入れて初めて 「SPAでもページ遷移を認識できる状態」 が作れます。
● まとめ
SPAでページ遷移がわからないとは、
画面は変わっているのに、
ユーザーに変化が伝わらない状態のこと
特にスクリーンリーダー利用者にとっては致命的で、何が起きているのか分からず、操作が破綻する。という意味です。
ただ私は視覚障害当事者でもなく、アクセシビリティ専門家でもないので、もっと良い説明がほかにあるかもしれません。
でも、「視覚障害者はインターネットなんかしないだろう」と思って何もしない人もいるので、 それは違うよ！ ということだけは言いたいですし、
今の令和の時代、 どんな人でもアクセスできること を必須として考えてほしいです。