こんにちは！Development事業部フロントエンドエンジニアのレイです。

Webアクセシビリティという言葉を聞くと、「特別な対応が必要」「難しそう」という印象をもつかもしれません。しかし実際には、多くのユーザーがOSやブラウザに備わった支援技術を使って、日常的にWebを利用しています。

文字を拡大して閲覧する、スクリーンリーダーで画面を読み上げる、キーボードだけで操作する。これらの支援技術が正しく機能するかどうかは、私のような実装者が書くHTML・CSS・JavaScriptの質に大きく依存しています。

本記事では、支援技術がどのようにWebを読み取り、それを生かすためにどんな実装が求められるのかを実装者の視点から整理していきます。アクセシビリティを「特別な取り組み」ではなく、正しい実装の延長として捉えるきっかけになれば幸いです。

レイ：Development事業部フロントエンドエンジニア。東北大学文学部で心理学を学びながらカナダ・モントリオールに3年間居住。帰国後コーディングを独学し、GIGにジョイン。現在はサイト制作のフロント実装や自社サービスLeadGridの開発を行う。最近はAIやインフラに興味がある。

支援技術とWebアクセシビリティの関係

Webアクセシビリティという言葉を聞くと、「特別なUIを用意すること」や「高度で大変な対応が必要」というイメージをもたれがちです。

しかし、じつは多くのユーザーがすでにOSやブラウザに備わった支援技術を使ってWebを閲覧しています。

代表的な支援技術として、以下のようなものがあります。

・表示拡大・ディスプレイ解像度の変更
ブラウザのズーム機能やOSレベルの拡大表示によって、文字やUIを見やすくする手段。

・スクリーンリーダー（画面読み上げ機能）
画面上のテキストや構造を音声として読み上げる支援技術。

・キーボードによる操作
マウスを使わず、TabキーやEnterキーなどで操作する方法。

これらは一部のユーザーだけのものではありません。視覚や運動に制約がある場合だけでなく、一時的な状況や環境の制約（片手が塞がっている、画面が見づらい、マウスが使えないなど）でも、多くの人が自然に利用しています。

重要なのは、これらの支援技術が見た目を解釈しているわけではないという点です。支援技術は、HTMLが持つ構造や意味をもとに情報を解釈し、ユーザーに伝えています。

たとえばスクリーンリーダーは、

・見出し構造をもとにページ全体の構成を把握し
・ランドマーク要素を使って主要な領域へ移動し
・リンクやボタンの種類を区別して操作可能な要素として提示します

つまり、HTMLが正しく意味づけされていなければ、支援技術も正しく情報を伝えることができません。見た目が整っていても、意味のないHTMLは「読めないページ」になってしまいます。

関連記事：ウェブアクセシビリティの義務化とは？対象範囲と2024年の対応策

WCAGが定める支援技術の前提

Webアクセシビリティの国際的なガイドラインとして、WCAG（Web Content Accessibility Guidelines）があります。

公式によると、

“このガイドラインに従うことで、全盲又はロービジョン、ろう又は難聴、運動制限、発話困難、光感受性発作及びこれらの組合せ、並びに学習障害及び認知限界への一部の適応を含んだ、様々な障害のある人に対して、コンテンツをアクセシブルにする”

ことができます。

WCAGは、次の4つの原則を軸に構成されています。

またWCAGでは、達成基準の重要度や、満たさなかった場合にページの機能がどの程度制限されるかといった観点から、3段階の適合レベルが定められています。

・レベルA：最低限満たすべき達成基準
・レベルAA：実用上、広く推奨される達成基準
・レベルAAA：より高いアクセシビリティを目指す達成基準

このうち、レベルAAAはすべてのコンテンツで達成することが現実的でない場合もあるため、サイト全体の一般的な方針としてAAAへの適合を要件とすることは推奨されていません。

以下では、実装者が日常的な開発で対応しやすい内容を中心に、4つの原則（POUR）を実現するためのレベルA〜AAの具体的な実装例を紹介します。

関連記事：
アプリ・ウェブのアクセシビリティ向上に重要な3要素
アクセシビリティの「AA」とは？Webサイト制作における達成基準を解説

WCAGの4つの原則を実現する具体的な実装例

原則1：知覚可能（Perceivable）

① 達成基準 1.3.2 意味のあるシーケンス（レベルA）
表示順が意味に影響する場合、支援技術が解釈できる「正しい読み順（DOM順）」を提供する必要があります。

【よくある問題】
・デザイン通りにDOMを組んだ結果、スクリーンリーダーの読み順が崩れる（例：画像→見出し→説明文）

【実装方針】
・意味のある順序でDOMを書く
・見た目の順序はCSSで制御する

【実装例：カードUI】
・DOMは「見出し→画像→説明文」の順
・見た目はCSSで「画像→見出し→説明文」に並べる

② 達成基準 1.3.4 表示の向き（レベルAA）
コンテンツの表示や操作を特定の画面の向き（縦/横）に制限してはいけません。

【よくある問題】
・横向きにすると固定ヘッダーが大きすぎて本文が実質見えない／スクロールできない
・向き変更でUIが崩れて操作不能になる

【実装方針】
・横画面で高さが不足する場合は固定要素を解除する

【実装例：ヘッダー】

原則2：操作可能（Operable）

① 達成基準 2.4.1 ブロックスキップ（レベルA）
複数ページで繰り返されるブロック（ヘッダー・グロナビ等）をスキップできる仕組みを提供する必要があります。

【よくある問題】
・スキップリンクが存在しない
・スキップリンクがあってもフォーカスできない

【実装方針】
・本文へのスキップリンクを用意し、フォーカスもうつす

【実装例：スキップリンク】
・mainをtab移動ではフォーカス対象にならないが、アンカー移動ではフォーカス可能になるようにする

② 達成基準 2.4.7 フォーカスの可視化（レベルAA）
キーボード操作可能な要素は、フォーカス位置が視認できる必要があります。

【よくある問題】
・デフォルトのフォーカススタイルを消してしまう

【実装方針】
・:focus-visible でキーボード時だけフォーカス位置を明確に表示

【実装例】

原則3：理解可能（Understandable）

① 達成基準 3.3.1 エラーの特定（レベルA）
入力エラーが自動検出された場合、どこがエラーかを特定し、テキストで説明する必要があります。

【よくある問題】
・「入力内容が不正です」だけで、どの項目がなぜダメか分からない
・エラーメッセージはあるが入力欄と紐づいていない（支援技術が関連を理解できない）

【実装方針】
・エラー内容を明示する
・エラーメッセージと入力欄を紐付ける

【実装例】

② 達成基準 3.2.3 一貫したナビゲーション（レベルAA）
繰り返されるナビゲーションは、ページ間で相対的に同じ順序で表示させる必要があります。

【よくある問題】
・あるページでは「料金→事例→問い合わせ」、別ページでは「問い合わせ→料金→事例」のように順序が変わる
・ページによってナビ項目が追加・削除されている

【実装方針】
・ナビゲーションを共通コンポーネントにして順序を固定
・見た目の順序を変更する場合はCSSで対応する

【実装例】

原則4：堅牢（Robust）

① 達成基準 4.1.2 名前・役割・値（レベルA）
UIコンポーネントは、支援技術が解釈できる 名前／役割／状態（値） をもつ必要があります。

【よくある問題】
・div をボタンとして使い、キーボード操作や role が欠落
・見た目はチェックボックスだが、スクリーンリーダーには「テキスト」として読まれる

【実装方針】
・まずは ネイティブ要素を使う（button / a / input / select）
・どうしてもカスタムなら、role + state + name + キーボード操作までセットで実装する

【実装例】

② 達成基準 4.1.3 ステータスメッセージ（レベルAA）
フォーカス移動なしで表示される「保存しました」「件数が更新されました」などのステータスメッセージは、支援技術が取得できるようにする必要があります。

【よくある問題】
・トーストや完了メッセージなどの状態変化がスクリーンリーダーに伝わらない
・単なる情報通知なのに強制的にフォーカス移動を行い、ユーザーの操作を中断させてしまう

【実装方針】
・フォーカスを奪わずスクリーンリーダーに状態変化を通知する

【実装例】

WAI-ARIA

ここまでは、WCAGの各達成基準を満たすための具体的な実装例を紹介してきました。それらの実装を支える重要な仕組みがWAI-ARIAです。

WAI-ARIAは、HTMLだけでは表現しきれない「役割・状態・関係性」を支援技術に伝える仕組みです。

モダンなWebアプリでは、

・JavaScriptで状態が変わるUI
・モーダルやタブなどのカスタムUI
・非同期で更新されるコンテンツ

が当たり前ですが、見た目の変化は自動では意味として伝わりません。そこで必要になるのがARIAです。

No ARIA is better than bad ARIA

ARIAは「付ければアクセシブルになる魔法」ではありません。間違ったARIAは、支援技術に誤情報を伝える可能性があります。

まずはネイティブHTMLで実現できないか、標準属性で足りないかを考え、それでも足りない部分だけARIAで補います。以下に、ARIAが必要になる代表例を3つ紹介します。

1.JavaScriptで状態が変わるUI
開閉UIなどは、状態を伝えないとスクリーンリーダーに意味が伝わりません。

aria-expanded で現在の状態を伝えます。これは 4.1.2（名前・役割・値）に関係します。

2.アイコンのみのボタン
ボタンタグの中にアイコンのみが存在すると、「ボタン」としか読まれないためなんのボタンなのかが伝わりません。

aria-label で名前を補います。

3.動的に更新されるコンテンツ
保存完了などは、視覚だけでなく意味として伝える必要があります。

これは 4.1.3（ステータスメッセージ）に該当します。

ARIAはHTMLを補強する仕組みです。まずはネイティブ要素で実現できないかを考え、実現できないときにARIAを使いましょう。

おわりに

表示拡大、スクリーンリーダー、キーボード操作。これらの支援技術は、特別な環境の話ではなく、すでに多くのユーザーの手元に存在しています。

本記事で見てきたように、アクセシビリティは「高度なテクニック」を追加することではありません。意味のあるDOM順で構造を組み、状態変化を正しく伝え、ネイティブHTMLを活かし、必要な場面で適切にARIAを補う。その積み重ねが、支援技術に正しく解釈されるWebをつくります。

見た目が整っていることと、意味が伝わることは別の問題です。支援技術はデザインではなく、私たちが書いた構造と意味を読み取っています。アクセシビリティは「特別な配慮」ではなく、「実装の質」の問題です。日々の開発の中で、正しいHTMLを書くことから始めていきましょう。

GIGでは、こうした技術的な課題解決から実装のご相談まで、プロフェッショナルなチームが皆さまのプロジェクトをサポートします。ご興味をお持ちの方は、ぜひお気軽にお声がけください。

◾️参考文献
・Web Content Accessibility Guidelines (WCAG) 2.2 (日本語訳)
・アクセシビリティ | MDN
・JIS X 8341-3:2016 達成基準 早見表（レベルA & AA）

■株式会社GIG
お問い合わせはこちら
採用応募はこちら（GIG採用サイト）
採用応募はこちら（Wantedly）

レイ

Development事業部フロントエンドエンジニア。東北大学文学部で心理学を学びながらカナダ・モントリオールに3年間居住。帰国後コーディングを独学し、GIGにジョイン。現在はサイト制作のフロント実装や自社サービスLeadGridの開発を行う。最近はAIやインフラに興味がある。