はじめに

近年、デジタル庁から「ウェブアクセシビリティ導入ガイドブック」が公開されており、公的機関だけでなく民間企業においても対応が求められるようになってきました。

本記事では、社内での勉強会を通して、資料を読むことで、Webアクセシビリティがなぜ必要とされるかを自分なりに考えたものをまとめました。

1. Webアクセシビリティとは

Webアクセシビリティとは、「利用者の障害や年齢、利用環境に関わらず、情報やサービスを利用できること」を指します。（*1）

誰のためのものか？

「障害者のための特別な対応」と捉えられがちですが、その本質は「あらゆる状況下のユーザー」にあります。

多数のユーザー: 視覚・聴覚障害だけでなく、高齢者、色覚多様性のある方など（推定で約428万人が恩恵を受けると言われています）。
一時的な状況: 「怪我でマウスが使えない」「屋外で画面が見えにくい」「電車でイヤホンを忘れてしまい、音が聞けない環境」といった状況的障害も含まれます。

UX向上と技術的メリット

アクセシビリティの向上は、結果としてユーザビリティ（使いやすさ）の向上にも繋がります。
また、機械が読み取りやすい構造にすることで、AIによる解析精度の向上や、SEO（検索エンジン最適化）の観点でも有利に働きます。

2. 基準と目標レベル

日本国内ではJIS X 8341-3という規格が基準となります。これは世界標準であるWCAG (Web Content Accessibility Guidelines) と協調しています。

達成すべきレベル

多くのプロジェクトではレベルAAへの準拠が推奨されます。

レベルA: 最低限満たすべき項目で、満たさないと一部のユーザーがサイトの利用自体をやめる可能性があります。
レベルAA: 多くのユーザーにとって困難なく利用できるレベルです。
レベルAAA: 全ての人が最大限利用できるよう配慮されるレベルです。技術的、コスト的なハードルが高くなっています。

試験と検証

システム開発同様、アクセシビリティ対応は「作って終わり」ではなく、テストが必要です。
自動チェックツールで検知できるのは全体の20〜30%程度と言われています。したがって、人の目による確認や、スクリーンリーダーを用いて人力の操作テストが必要です。主に利用されるスクリーンリーダーはNVDA、PC-Talkerです。
アクセシビリティのテストの工数として、100ページ規模のサイトで試験・改修を含めると数ヶ月単位の期間を要することもあります。設計段階から組み込むことが重要です。

3. 【実践編】よくあるNG例と改善策

具体的な実装ポイントを紹介します。

① 必須項目の明示（フォーム）

NG例：
アスタリスク（*）だけで必須を表している。

See the Pen Untitled (@bslddcns-the-decoder) on CodePen.

視覚障害がある場合、読み上げで「アスタリスク」とだけ言われても、それが必須項目を意味するのか伝わらない可能性があります。

改善策：
テキストで明示し、かつ aria-required 属性を使用する。

See the Pen Untitled (@bslddcns-the-decoder) on CodePen.

② ボタンの実装（セマンティックHTML）

NG例：
div や span に onClick をつけてボタン風に見せている。

<div class="btn" onclick="submit()">送信</div>

これではスクリーンリーダーが「ボタン」として認識せず、キーボード操作（Tabキーでのフォーカス移動など）もできません。

改善策：
適切なタグ（<button>）を使用する。

<button type="button" onclick="submit()">送信</button>

どうしても div を使う必要がある場合は、role="button" や tabindex="0" などを付与して補完する必要がありますが、基本はネイティブのHTMLタグを使うのがベストです。

③ 画像の代替テキスト（alt属性）

NG例：
ファイル名をそのまま alt に設定している、または具体性がない。

<img src="campaign_banner_01.jpg" alt="banner01" width="300">

「banner01」と読み上げられても、ユーザーには画像の内容が伝わりません。

改善策：
画像が伝えている情報を具体的に記述する。

<img src="campaign_banner_01.jpg" alt="秋の新規入会キャンペーン実施中。ポイント10倍" width="300">

④ モーダルダイアログの実装

モーダルはアクセシビリティの落とし穴になりやすい箇所です。フォーカス管理や役割の明示が必要です。

実装のポイント：

role="alertdialog" や role="dialog" を使用する。
aria-modal="true" を付与する。

MDN Web Docs（*2）より引用:
aria-modal="true" は、role="alertdialog" の宣言を持つ要素にフォーカスがある限り、ダイアログの下のコンテンツはインタラクティブではないことを支援技術ユーザーに通知します。

<div role="alertdialog" aria-modal="true" aria-labelledby="dialog_title">
  <h2 id="dialog_title">保存しますか？</h2>
  </div>

⑤ 見出し構造（Heading）

h1、h2 などの見出しタグは、文字を大きくするための装飾用ではありません。**文書の構造（アウトライン）**を機械的に伝えるためのものです。

h1 はページに1つが推奨。
階層構造を守る（h2 の次は h3 を使う。いきなり h4 に飛ばない）。

⑥その他の例

自動再生動画: 音声が勝手に流れると、スクリーンリーダーの音声と被ってしまいます。停止機能を設けるか、デフォルトでオフにします。
色だけの情報伝達: 「赤色の項目がエラーです」だけでは、色覚特性によって判別できない場合があります。アイコンやテキストを併用しましょう。

また、アクセシビリティは「一度対応して完了」ではなく、継続的に、サイト更新時にランダムなページを抽出して再試験を行うなどの運用が必要です。

まとめ

アクセシビリティの確保は、特定の誰かのためではなく、「Webサイトの品質そのもの」を向上させる行為です。
法的な対応（改正障害者差別解消法など）も背景にありますが、まずは「正しくHTMLを書く」という基本から始めるだけでも、アクセシビリティは大きく向上します。

設計段階からアクセシビリティを意識し、より多くの人に情報が届くWebサイトを目指しましょう。

参考リンク