---
schema_version: "1"
id: 3212879026fb26177e564260d28de65488059968d8c0afddcdf74ee8d6da6064
title: アクセシビリティとインクルーシブデザイン - パターン
collection: architect
version: current
locale: ja-jp
portal_url: https://docs.salesforce.com/architect/current/ja-jp/well-architected/guides/fairness-accessibility-patterns.md
canonical_url: https://architect.salesforce.com/docs/architect/ja-jp/well-architected/guide/fairness-accessibility-patterns.html
source_site: architect.salesforce.com
content_type: documentation
content_hash: 4c45c410460c81ff71b4969243128a6a94820e06f3f5653ade1d8bb9857117d7
products:
  - 適切に設計されたフレームワーク
  - Architect Site Content Repo
---
# アクセシビリティとインクルーシブデザイン - パターン

<br>

適切に設計され[た公平性](/docs/architect/ja-jp/well-architected/guide/fairness.html)についての詳細 → [LightningとExperience Cloud](/docs/architect/ja-jp/well-architected/guide/fairness.html#accessibility-with-lightning-and-experience-cloud)によるアクセシビリティ

## WCAG 2.2 AA 準拠

**パターン**

| 参照すべき場所 | 外観 |
| --- | --- |
| プラットフォーム \| 設計標準               | ✅ WCAG 2.2 レベル AA は、カスタムビルド作業 (Experience Cloud、LWC、カスタムテーマ) の最小アクセシビリティバーであり、ビルディングチームによって検証されています。                                                |
| プラットフォーム \| 設計標準               | ✅ 認識可能な原則: 画像とアイコンにはテキストの代替手段があり、キャプションは動画に添付される   |
| プラットフォーム \| 設計標準               | ✅ 操作原理: すべての機能は、マウスやタッチを必要とせず、キーボードのみで操作できます。音声制御とスイッチアクセス支援技術は同じキーボード/フォーカスモデルを使用します。             |
| プラットフォーム \| LWC                            | ✅ 標準Lightning Webコンポーネントが設計どおりに使用され、ベースラインへのアクセスが自動的に提供される                                         |
| プラットフォーム \| LWC                            | ✅ カスタムコンポーネントは、スクリーンリーダーを使用したテストで検証された明示的なアクセシビリティを実装します。                                               |
| プラットフォーム \| テスト計画                     | ✅ アクセシビリティテストはすべてのテストフェーズに含まれます (臨時または省略可能ではありません)。                                                               |

**アンチパターン**

| 参照すべき場所 | どんな悪い感じか |
| --- | --- |
| プラットフォーム \| 設計標準               | ⚠️ WCAG 2.2 レベル AA は、最小要件ではなく省略可能または「あれば良い」として扱われます。                           |
| プラットフォーム \| 設計標準               | ⚠️ 画像とアイコンには代替テキストがなく、動画にはキャプションがない                                                        |
| プラットフォーム \| 設計標準               | ⚠️ 機能にはキーボードの代わりにマウスまたはタッチ操作が必要                              |
| プラットフォーム \| LWC                            | ⚠️ カスタムコンポーネントはアクセシビリティの実装や検証なしで構築されます。                                       |
| プラットフォーム \| LWC                            | ⚠️ カスタム入力コンポーネントで div 要素と CSS スタイルが使用されているが、セマンティックな意味やキーボードアクセシビリティがない          |
| プラットフォーム \| テスト計画                     | ⚠️ アクセシビリティテストは、アドホック、省略可能、または稼働開始前にのみ実施 (開発全体では実施しない)              |

## スクリーンリーダーのアーキテクチャ

**パターン**

| 参照すべき場所 | 外観 |
| --- | --- |
| プラットフォーム \| LWC                            | ✅ セマンティックHTML要素(ヘッダー、ナビゲーション、メイン、わき、フッター、記事、セクション)をカスタムLightning Webコンポーネントで使用                      |
| プラットフォーム \| LWC                            | ✅ セマンティック HTML だけではインターフェースの動作を伝達できない場所に ARIA のランドマーク、ロール、プロパティが適用される                                 |
| プラットフォーム \| LWC                            | ✅動的コンテンツ更新では、スクリーンリーダーユーザーへの変更を発表する aria-live リージョンを使用します。                                                      |
| プラットフォーム \| LWC                            | ✅ カスタムインタラクティブコンポーネントの動作に一致する明示的なロール定義がある                                                         |
| プラットフォーム \| LWC                            | ✅ フォームの表示ラベルは、適切な表示ラベル要素または aria-labelledby 属性を使用して、すべてのフォーム入力に明示的に関連付けられます。                         |
| プラットフォーム \| LWC                            | ✅ Lightning入力コンポーネントは、組み込みの表示ラベルの関連付けを提供する必須の表示ラベル属性で構成                                |
| プラットフォーム \| テスト計画                     | ✅ 実際のスクリーンリーダーでテストを実施: Windows では JAWS と NVDA、macOS と iOS では VoiceOver、Android では TalkBack                   |
| プラットフォーム \| テスト計画                     | ✅ 実際の支援技術を使用した手動テストは、スクリーンリーダーユーザーのナビゲーションを理解した担当者が実施                         |
| プラットフォーム \| 設計標準               | ✅ プレースホルダーはフォーカスで表示され、スクリーンリーダーに不十分なコンテキストを提供するため、プレースホルダーテキストが唯一の表示ラベルとして使用されることはありません。 |

**アンチパターン**

| 参照すべき場所 | どんな悪い感じか |
| --- | --- |
| プラットフォーム \| LWC                            | ⚠️ 分割の多いマークアップでは、コンテンツ階層から意味が削除されるため、スクリーンリーダーのユーザーはリニアなナビゲーションが必要になります。 |
| プラットフォーム \| LWC                            | ⚠️ セマンティック HTML のみでインターフェースの動作を伝えることができない場合、ARIA は使用されません。                             |
| プラットフォーム \| LWC                            | ⚠️ 動的コンテンツ更新では aria-live リージョンが使用されないため、スクリーンリーダーユーザーが重要な変更を見逃す        |
| プラットフォーム \| LWC                            | ⚠️ カスタムインタラクティブコンポーネントには明示的なロール定義がなく、スクリーンリーダーで誤ってアナウンスされる  |
| プラットフォーム \| LWC                            | ⚠️ フォーム入力に明示的な表示ラベルの関連付けがなく、プレースホルダーテキストが単独の表示ラベルとして使用される                     |
| プラットフォーム \| テスト計画                     | ⚠️ 自動アクセシビリティツールは排他的に使用され、手動スクリーンリーダーテストは実行されません。       |
| プラットフォーム \| テスト計画                     | ⚠️ テストは、スクリーンリーダーユーザーが実際に操作する方法に慣れていない視覚のあるユーザーによって実施されます。         |

## キーボードナビゲーション

**パターン**

| 参照すべき場所 | 外観 |
| --- | --- |
| プラットフォーム \| 設計標準               | ✅ ユーザージャーニーの任意の時点でマウスやタッチ操作を必要とせず、キーボードから完全な機能にアクセスできます。                       |
| プラットフォーム \| LWC                            | ✅ ビジュアルレイアウトとインタラクションフローに従った論理的なフォーカス順序                                                                                     |
| プラットフォーム \| LWC                            | ✅ 動的コンテンツが読み込まれたり、モーダルが開いたりすると、フォーカスがプログラムで管理され、キーボードユーザーが新しいコンテンツに移動できます。                                |
| プラットフォーム \| LWC                            | ✅ モーダルコンポーネントとポップオーバーコンポーネントは、開いたときにモーダルタイトルまたは最初のインタラクティブ要素にフォーカスを移動し、閉じたときにトリガーボタンにフォーカスを戻す               |
| プラットフォーム \| 設計標準               | ✅ 可視フォーカスインジケーターにより、キーボードフォーカスが常にある要素を明確に表示                                                                |
| プラットフォーム \| 設計標準               | ✅ フォーカスインジケーターは、周囲のコンテンツとの 3:1 のコントラスト要件を満たします。                            |
| プラットフォーム \| LWC                            | ✅ ユーザーはキーボードのみですべてのコンポーネントにナビゲートでき、窮屈になることはありません。                                                    |
| プラットフォーム \| LWC                            | ✅ モーダルダイアログは、開いている間はモーダル内のフォーカスを捕捉し (非表示のコンテンツへのアクセスを防止)、閉じるとフォーカスを解除します。                            |
| プラットフォーム \| 設計標準               | ✅ 頻繁にアクションを実行するキーボードショートカットにより、スクリーンリーダーのショートカットやブラウザーのショートカットとの競合を回避                                         |
| プラットフォーム \| 設計標準               | ✅ 1 文字のショートカットは、スクリーンリーダーのナビゲーションコマンドとの競合を回避するために、特定のコンポーネントにフォーカスがある (グローバルではない) 場合にのみ有効化されます。 |
| プラットフォーム \| ドキュメント                  | ✅ すべてのカスタムキーボードショートカットは、アクセス可能なヘルプコンテンツに記載されています。                                                                            |
| プラットフォーム \| テスト計画                     | ✅ テストステップには、マウスやタッチを使用せずにすべてのユーザージャーニーをキーボードのみで操作できるナビゲーションが含まれます。                                                 |

**アンチパターン**

| 参照すべき場所 | どんな悪い感じか |
| --- | --- |
| プラットフォーム \| 設計標準               | ⚠️ 機能にはマウスまたはタッチ操作が必要です。キーボードのみのユーザーは主要なタスクを実行できません。           |
| プラットフォーム \| LWC                            | ⚠️ フォーカス順序が論理的なビジュアルレイアウトに従っていない。ユーザータブで予期しない順序で要素を移動する       |
| プラットフォーム \| LWC                            | ⚠️ フォーカス管理なしでモーダルが開き、キーボードユーザーが非表示になったトリガーボタンに足止めされる             |
| プラットフォーム \| LWC                            | ⚠️ モーダルクローズではトリガーボタンにフォーカスが返されないため、ユーザーはページ内の自分の位置を探す必要がある           |
| プラットフォーム \| 設計標準               | ⚠️ 外観上の理由でフォーカスインジケーターが非表示になり、ユーザーがどの要素にフォーカスがあるかを確認できない            |
| プラットフォーム \| 設計標準               | ⚠️ フォーカスインジケーターのコントラストが不十分 (<3:1)                            |
| プラットフォーム \| LWC                            | ⚠️ ユーザーがエスケープメカニズムのないインターフェース領域に閉じ込められる (キーボードトラップ)                        |
| プラットフォーム \| LWC                            | ⚠️ 埋め込みコンテンツ (iframe、サードパーティウィジェット) でキーボードのフォーカスを完全に取得                        |
| プラットフォーム \| 設計標準               | ⚠️ 1 文字のショートカットは、スクリーンリーダーの 1 文字のナビゲーションコマンドとグローバルに競合する有効化 |
| プラットフォーム \| ドキュメント                  | ⚠️ カスタムキーボードショートカットは文書化されていないため、ユーザーが見つけることができません。                                     |

## ビジュアルデザインとコントラスト

**パターン**

| 参照すべき場所 | 外観 |
| --- | --- |
| プラットフォーム \| 設計標準               | ✅ 18 pt または 14 pt 太字以下の通常のテキストの場合、4.5:1 以上のコントラスト比                                                                |
| プラットフォーム \| 設計標準               | ✅ 大きなテキストと意味のある UI コンポーネントおよびグラフィック (フォームの境界線、情報アイコン) では 3:1 以上のコントラスト比。純粋に装飾的な要素や無効な要素は除外されます。                      |
| プラットフォーム \| Experience Cloud               | ✅ カスタムテーマとブランド設定された Experience Cloud サイトには、ブラウザー開発ツールまたは自動チェッカーを使用した明示的なコントラスト検証が含まれます。 |
| プラットフォーム \| 設計標準               | ✅ 200% へのテキストサイズ変更は、コンテンツや機能を損なうことなくサポートされます (WCAG 要件)                                        |

**アンチパターン**

| 参照すべき場所 | どんな悪い感じか |
| --- | --- |
| プラットフォーム \| 設計標準               | ⚠️ テキストコントラスト比が 4.5:1 (通常のテキスト) または 3:1 (大きなテキストと UI コンポーネント) を下回る    |
| プラットフォーム \| Experience Cloud               | ⚠️ コントラスト検証なしでカスタムテーマがリリースされ、弱視ユーザーはコンテンツを参照できない |
| プラットフォーム \| 設計標準               | ⚠️ 200% を超えるテキストサイズ変更でレイアウトが破損し、コンテンツや機能が失われる                       |

## アクセシビリティテストと検証

**パターン**

| 参照すべき場所 | 外観 |
| --- | --- |
| プラットフォーム \| CI/CD                          | ✅ Axe-core または Lighthouse アクセシビリティスキャンは CI/CD パイプラインに統合されており、すべてのリリースで構造的な問題をキャッチします。       |
| プラットフォーム \| CI/CD                          | ✅ アクセシビリティの重大な問題が検出されるとビルドに失敗する                                                                           |
| プラットフォーム \| テスト計画                     | ✅ スクリーンリーダー、キーボードのみのナビゲーション、ブラウザーの 200% へのズームを使用した手動テストは開発全体で定期的に実施  |
| プラットフォーム \| テスト計画                     | ✅ テストにより、混乱するお知らせ順序、フォーカス管理の失敗、キーボードトラップなどのインタラクションの問題が明らかになります。            |
| プラットフォーム \| ビジネス                       | ✅ 設計プロセス全体でのユーザビリティテストに障害者ユーザーが含まれている                                                   |
| プラットフォーム \| ビジネス                       | ✅ ユーザビリティテストにより、自動および手動のエキスパートテストで見逃される実用的な障壁が明らかに                                            |
| プラットフォーム \| テスト計画                     | ✅ 自動テスト (量による問題の 57% 以下)、手動テスト (インタラクションの問題)、ユーザーテスト (実際の障壁) をすべて実行 |

**アンチパターン**

| 参照すべき場所 | どんな悪い感じか |
| --- | --- |
| プラットフォーム \| CI/CD                          | ⚠️ アクセシビリティスキャンは CI/CD パイプラインに統合されていません                                          |
| プラットフォーム \| CI/CD                          | ⚠️ アクセシビリティに重大な問題があってもビルドは続行されます。                                                   |
| プラットフォーム \| テスト計画                     | ⚠️ 支援技術を使用した手動テストは実行されず、自動スキャンのみが使用されます。             |
| プラットフォーム \| ビジネス                       | ⚠️ 障害者はユーザビリティテストに含まれません                                          |
| プラットフォーム \| テスト計画                     | ⚠️ 稼働開始前に自動化されたアクセシビリティスキャナーが 1 回実行され、アクセシビリティテストが完了したとみなされる |