今さら聞けないアクセシビリティ基礎知識まとめ

アクセシビリティ、特別対応ではなく設計の前提になる時代へ。

Webサイトやアプリのアクセシビリティは、もはや余裕があればやるという施策ではありません。
障害の有無・年齢・利用環境に関係なく、できるだけ多くの人が同じようにサービスを利用できるようにすること——それがアクセシビリティです。

言い換えると、アクセシビリティは特別対応ではなく、UI/UX設計の前提条件。
見た目がきれいでも、操作できない・読めない・伝わらないなら、サービスとしては片輪走行。リスキーと言えるかもしれません。

なぜ今、アクセシビリティが必要なのか?

法改正により「合理的配慮」が民間企業にも義務化

2024年の障害者差別解消法改正により、民間企業にも合理的配慮の提供が義務化されました。
Webサイトやアプリもサービスの一部として対象に含まれます。
「店舗では配慮するけどWebは知らん」は通りにくくなっています。

信頼性の問題になってきている

アクセシビリティ対応は、単なる機能改善ではなく、企業やサービスの信頼性に直結します。

• 配慮が実装されている → 信頼の担保につながる
• 無配慮が放置されている → ブランド毀損につながる

社会の空気は確実にこちらに進んでいます。雑に作ると、機能より先に信用が失墜します。

SEO・品質評価の観点でも重要性が上がっている

2024年以降、Google評価の文脈でも、構造・可読性・操作性の改善はますます重要になっています。
アクセシビリティに取り組むことは、結果としてSEOやUX品質の底上げにもつながります。

法律上の「義務化された配慮」とは何か

法律上は、障害者から「この配慮があれば利用できる」と申し出があった際に、「過度な負担にならない範囲で対応する義務」があります。ここで大事なのは、いきなり完璧な準拠を求められるというよりも、まずは次のような姿勢を明示することです。

• どの準拠レベルを目標にしているか
• 現在の達成状況
• 今後の改善方針
• 問い合わせ窓口（配慮依頼の導線）

つまり、「まだ100点じゃない」ことよりも、配慮していることを説明できる状態が重要です。
黙ってるとやってない側に見えるので、方針公開の持つ意味は大きいと言えるでしょう。

アクセシビリティの指標基準

国際基準

• WCAG 2.0〜2.2（A / AA / AAA）

国内基準

• JIS X 8341-3:2016（WCAG 2.0相当）

実務では、まず WCAG AAレベル を目標にするケースが多いです。

WCAG 2.0（基礎）

Webアクセシビリティの基本版

WCAG 2.0は2008年に公開された、Webアクセシビリティの基本となるガイドラインです。
いわば「最低限ここを外すな」という土台。

4原則（POUR）

WCAGは、次の4原則で構成されています。

• Perceivable（知覚可能）
  情報が見える・聞こえるなど、認識できること
• Operable（操作可能）
  キーボード等で操作できること
• Understandable（理解可能）
  内容や操作方法が理解しやすいこと
• Robust（堅牢）
  さまざまなブラウザ・支援技術で解釈できること

この4つは、実装の枝葉ではなく設計思想そのもの。
デザインレビューでも開発レビューでも、ここに戻れるチームは強いです。

WCAG 2.1（拡張）

PCで崩れてないでは足りない時代へ

WCAG 2.1は、WCAG 2.0を拡張したものです。「PCブラウザで見た目が崩れていない」だけでは不十分という前提で、スマホ・拡大表示・支援技術・認知負荷まで視野に入れています。

主な強化領域

• モバイルアクセシビリティ
• ロービジョン対応
• 認知・学習障害への配慮
• 入力・タッチ操作の改善
• 状態通知や自動入力の意味づけ

主な追加項目（例）

視認性・レイアウト

• Orientation (AA)：縦向き／横向きを強制しない
• Reflow (AA)：拡大時に横スクロール依存になりにくい
• Text Spacing (AA)：文字間・行間を広げても崩れにくい
• Non-text Contrast (AA)：アイコンやUI部品のコントラスト確保

タッチ操作・入力

• Pointer Gestures (A)：複雑なジェスチャ操作を必須にしない
• Pointer Cancellation (A)：誤タップ／誤操作に配慮する
• Label in Name (A)：表示ラベルと読み上げ名を一致させる
• Motion Actuation (A)：端末を振る等の操作に代替手段を用意する

フォーム・状態通知

• Identify Input Purpose (AA)：入力欄の意味をプログラム的に判定可能にする
• Status Messages (AA)：通知や更新を支援技術へ適切に伝える

WCAG 2.2（さらに拡張）

実務寄りの改善

WCAG 2.2は、2.1に対してさらに実務寄りの観点を追加したものです。特に次のような領域が強化されています。

• キーボードフォーカスの見失い防止
• 小さいボタン／タップ領域の改善
• ドラッグ前提UIへの配慮
• ヘルプ導線の一貫性
• 入力・認証の負担軽減

要するに、ユーザーの

• 見失う
• 押し間違える
• わからなくなる
• 覚えられない

を減らす方向で、「ちゃんとしてるUI」って、こういう地味な優しさの積み上げなのだと明示しました。

WCAG 2.0 / 2.1 / 2.2 の項目数比較

バージョン	A	AA	AAA
WCAG 2.0	25	38	61
WCAG 2.1	30	50	78
WCAG 2.2	31	55	86

バージョンが上がるほど、単に「厳しくなる」というより、現実の利用環境に対応していくイメージです。

WAI-ARIAとは何か

支援技術に意味を伝えるための仕組み

WAI-ARIAは、WebコンテンツやWebアプリの情報を、スクリーンリーダーなどの支援技術に正しく伝えるための仕組みです。特に、HTML/JSで作る高度なUIや動的コンテンツで有効です。

WCAGとの違い

• WCAG：何を達成すべきか（要件・ゴール）
• WAI-ARIA：達成を助ける具体的な実装手段の一つ

つまり、WCAGが目的地、ARIAは道具です。
ただし道具は使い方を間違えると問題になるので、雑に実装するのは逆効果です。

ARIAで追加する主な情報

role（役割）

要素の役割を支援技術に伝える

例：

• button
• dialog
• tab
• tablist
• navigation

state（状態）

現在の状態を伝える

例：

• aria-expanded=”true”
• aria-selected=”false”

property（性質・関連）

要素の名前や説明、関係性を伝える

例：

• aria-label
• aria-labelledby
• aria-describedby
• aria-controls

WAI-ARIAが特に必要になる場面

動的UI

• モーダル
• アコーディオン
• タブ
• カスタムドロップダウン
• トースト通知
• ライブ更新（非同期更新）

HTMLネイティブ要素だけでは意味が伝わりにくいとき

例えば：

• JSで作ったタブUIに、支援技術向けの構造を伝えたい
• 非同期更新の成功メッセージを読み上げさせたい（status / live region）

何をチェックするか（実務の入口）

チェック項目の整理には、有限会社時代工房のサマリー資料が実務で使いやすいです。

• WCAG 2.2 A/AA サマリー
• WCAG 2.1 A/AA サマリー

チェック方法

自動チェック + 目視 + 実機テストの三段構え

アクセシビリティ検証は、自動ツールだけでは完結しません。

• 自動ツールで検出できる目安：全体の6〜7割
• 残りの3〜4割：人間の判断が必須

「ツールで0件だからOK！」は早すぎる勝利宣言です。

よく使うチェックツール

miChecker

総務省系のJIS準拠チェックツール。公式系としての安心感はある一方、UIが重めで検出はやや限定的。個人的にはほとんど使えません。

axe DevTools

無料版でもかなり優秀。検出可能な項目はおおむね6割前後、静的自動検出としては強力。有料版はレポーティングもしやすい。

Chrome標準機能（Lighthouse等）

内部的にaxe-coreベース。axe DevToolsのライト版的な立ち位置で、簡易チェックに最適。

WAVE

見出し・ランドマーク・ラベルなど、構造の視覚確認に便利。「見た目では気づかない構造の癖」を炙り出しやすい。

スクリーンリーダー / キーボード操作

最終的には実機・実操作のヒューマンチェックが基本。特にVoiceOverやキーボード操作は、実務レビューで外せません。

ヒューマンチェックのポイント

共通（基本）

• スクリーンリーダーでの読み上げ順は自然か（例：VoiceOver）
• ロール・名前・状態がわかりやすいか
• エラーメッセージや説明文が、人間にとって理解しやすい文章か
• 情報量は適切か（詰め込みすぎ／逆に不足していないか）
• 認知負荷が高すぎないか

Webで特に見るポイント

• alt の内容が適切か（意味が伝わるか）
• 見出し・リンク・テキストが文脈として理解しやすいか
• キーボード操作時のフォーカス順が自然か
• ロービジョンユーザーがフォーカスを見失わないか
• モーダル／ダイアログなど動的UIの挙動が適切か

アプリで特に見るポイント

• タップ可能領域が十分か（最低24×24px目安）
• 可能であれば44×44px程度（Apple推奨）を意識する

まず何から始めるべきか？　実務向けの最小セット

アクセシビリティは範囲が広いので、最初は以下の順で進めると実務で回しやすいです。

1. 方針を決める（目標レベル：まずAA）
2. 対象範囲を決める（主要ページ／主要導線から）
3. 自動チェックを実施する（axe / Lighthouse / WAVE）
4. キーボード操作・スクリーンリーダーで実機確認
5. 修正ルールをチーム化する（再発防止）
6. 達成状況・改善方針・問い合わせ窓口を公開する

いきなり全ページ完全制覇を狙うと、だいたい途中で溶けます。
重要導線から詰めるのが勝ち筋です。

まとめ

アクセシビリティは、法対応のためだけにやるものではありません。
それは、サービスを「誰にでも使えるもの」に近づける設計であり、同時に信頼を積み上げる仕事です。

• 法対応として必要
• UX改善として効く
• SEO・品質にも効く
• ブランド信頼にも効く

つまり、やる理由が多すぎる。
後回しにするほど、未来の自分が泣きながら直すことになります。

まずは、完璧を目指す前に、方針を明示して、主要導線から改善する。
そこからで十分、強い一歩です。