shortcuts - ウェブアプリマニフェスト

shortcuts
=========

|  |  |
| --- | --- |
| 型 | `Object` |
| 必須 | いいえ |

`shortcuts` メンバーは、ウェブアプリ内の主要なタスクやページへのショートカットやリンクの配列を定義します。ユーザーエージェントはこれらの値を用いて、ユーザーがウェブアプリのアイコンを操作したときにオペレーティングシステムが表示するコンテキストメニューを作成することができます。ユーザーがショートカットを呼び出すと、ユーザーエージェントはショートカットの `url` メンバーで指定されたアドレスに誘導します。

ショートカット項目の値
-----------

ショートカットオブジェクトには、以下の値を指定することができます（`name` と `url` のみ必須）。

| メンバー | 説明 |
| --- | --- |
| `name` | コンテキストメニューでユーザーに表示することができる文字列です。 |
| `short_name` | ショートカットのフルネームを表示するのに十分なスペースがない場合に表示することができる文字列です。 |
| `description` | ショートカットの目的を記述した文字列です。支援技術に公開される可能性があります。 |
| `url` | ショートカットを有効にしたときに開く、アプリケーション内の URL です。 |
| `icons` | ショートカットを表すアイコンのセットです。コンテキストメニューなどで使用することができます。この値を指定する場合、アイコンのセットには 96x96 ピクセルのアイコンを含める必要があります。 |

例
-

カレンダーアプリが持つ可能性があるショートカットのリストです。

```json
"shortcuts" : [
  {
    "name": "Today's agenda",
    "url": "/today",
    "description": "List of events planned for today"
  },
  {
    "name": "New event",
    "url": "/create/event"
  },
  {
    "name": "New reminder",
    "url": "/create/reminder"
  }
]
```

仕様書
---

| Specification |
| --- |
| Web Application Manifest # shortcuts-member |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.


related_applications - ウェブアプリマニフェスト

related\_applications
=====================

|  |  |
| --- | --- |
| 型 | 配列 (`Array`) |
| 必須 | はい |

`related_applications` フィールドはオブジェクトの配列で、基礎となるプラットフォームにインストール可能、またはアクセス可能なネイティブアプリケーション — たとえば、 Google Play ストアで入手可能なネイティブの Android アプリケーションなどを指定します。このようなアプリケーションは、ネイティブアプリの同等品のように、同様または同等の機能を提供するマニフェストのウェブサイトの代替品となることを意図しています。

**メモ:** 開発者は `prefer_related_applications` に `true` を設定することで、ネイティブアプリケーションがウェブアプリケーションよりも推奨されることを示すことができます。

例
-

```json
"related\_applications": [
  {
    "platform": "play",
    "url": "https://play.google.com/store/apps/details?id=com.example.app1",
    "id": "com.example.app1"
  }, {
    "platform": "itunes",
    "url": "https://itunes.apple.com/app/example-app1/id123456789"
  }
]
```

関連アプリケーションの値
------------

アプリケーションオブジェクトには、次の値を入れることができます。

| メンバー | 説明 |
| --- | --- |
| `platform` | アプリケーションを見つけることができるプラットフォームです。利用できる値の一覧 |
| `url` | アプリケーションを見つけることができる URL です。 |
| `id` | 指定されたプラットフォームでアプリケーションを表す ID です。 |

仕様書
---

| Specification |
| --- |
| Web Application Manifest # related\_applications-member |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.


screenshots - ウェブアプリマニフェスト

screenshots
===========

|  |  |
| --- | --- |
| 型 | `Object` |
| 必須 | いいえ |

`screenshots` メンバーはアプリケーションのショーケースに向けたスクリーンショットの配列を定義します。これらの画像はプログレッシブウェブアプリストアで使用することを意図しています。

例
-

```json
"screenshots" : [
  {
    "src": "screenshot1.webp",
    "sizes": "1280x720",
    "type": "image/webp",
    "platform": "wide",
    "label": "Homescreen of Awesome App"
  },
  {
    "src": "screenshot2.webp",
    "sizes": "1280x720",
    "type": "image/webp",
    "platform": "wide",
    "label": "List of Awesome Resources available in Awesome App"
  }
]
```

`label` メンバーは、スクリーンショットのアクセス可能な名前として機能する文字列です。また、スクリーンショットの代替テキストとして使用することもできます。

また、 `platform` メンバーは文字列で、特定のスクリーンショットを適用する配信プラットフォームを定義することができます。定義されていない場合、ユーザーエージェントはスクリーンショットのアスペクト比を使用して表示することができます。

`platform` メンバーには、以下の汎用的な値のいずれかを設定することができます。

* `wide` : ワイドスクリーンにのみ適用されるスクリーンショット用 (例: ステータスボード)。
* `narrow` : 狭いスクリーンショット用 (例: モバイル端末、ウェアラブル)。

また、特定の OS で表示するスクリーンショットには `android`、`chromeos`、`ios`、`kaios`、`macos`、`windows`、`xbox` を、特定のアプリケーション配信プラットフォームで表示するスクリーンショットには `chrome_web_store`、`play`、`iTunes`、`microsoft-inbox`、`microsoft-store` を設定することができます。

仕様書
---

| Specification |
| --- |
| Web App Manifest - Application Information # screenshots-member |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.


share_target - ウェブアプリマニフェスト

share\_target
=============

**Experimental:** **これは実験的な機能です。**
本番で使用する前にブラウザー互換性一覧表をチェックしてください。

|  |  |
| --- | --- |
| 型 | `Object` |
| 必須 | いいえ |

マニフェストの `share_target` メンバーは、プログレッシブウェブアプリ (PWA) をシステムの共有ダイアログの共有先として登録することを可能にします。

登録されインストールされると、Web Share Target API を用いる PWA は電子メール、メッセンジャー、そしてその他の共有されるコンテンツを受け取れるネイティブアプリといったシステム上の通常の共有先とともに、コンテンツの共有先として振る舞います。

**メモ:** Web Share API を用いてデータを共有したい場合、Web Share API および `navigator.share()` を参照してください。

プロパティ
-----

アプリケーションがどのように共有されるデータを受け取るかを定義するため、マニフェスト中の `share_target` オブジェクトは以下のプロパティを持つことができます。(`action` と `params` は必須です)

`action`

ウェブ共有先の URL です。

`enctype` 省略可

`POST` リクエストが用いられる場合の、共有データのエンコーディングです。`GET` リクエストでは無視されます。

`method` 省略可

使用する HTTP リクエストメソッドです。`GET` または `POST` のいずれかを指定します。共有されるデータが画像などのバイナリデータを含むか、対象のアプリケーションに変化を起こす (例えば、ブックマークなどのデータを生成する) 場合、`POST` を指定してください。

`params`

共有のパラメーターを設定するオブジェクトです。このオブジェクトのキーは `navigator.share()` における `data` オブジェクトに対応します。以下の値が指定でき、クエリーパラメーターとして用いられます。

* `title` 省略可: 共有されるドキュメントのタイトル用のクエリーパラメーターの名前です。
* `text` 省略可: 共有されるメッセージのテキスト (本文) 用のクエリーパラメーターの名前です。
* `url` 省略可: 共有されるリソースの URL 用のクエリーパラメーターの名前です。
* `files` 省略可: 共有先が受け入れるファイルの種類を定義するオブジェクト (またはオブジェクトの配列) です。このオブジェクトには以下のプロパティが必要です。
    + `name`: ファイルの共有に用いるフォームフィールドの名前です。
    + `accept`: 受け入れる MIME タイプまたはファイルの拡張子を表す文字列 (または文字列の配列) です。

例
-

### 共有されたデータを GET で受け取る

以下の `share_target` マニフェストメンバーにより、共有先を登録できます。

```json
{
  "share\_target": {
    "action": "/shared-content-receiver/",
    "method": "GET",
    "params": {
      "title": "name",
      "text": "description",
      "url": "link"
    }
  }
}
```

ユーザーがシステムの共有ダイアログでこのアプリケーションを選択すると、この PWA が起動し、指定のクエリーパラメーターが入った指定の URL に HTTP の `GET` リクエストが発生します。これは `/shared-content-receiver/?name=a+shared+name&description=a+shared+description&link=https%3A%2F%2Fexample.com%2F` のような URL になります。

アプリケーションで共有されたデータを処理するには、`URLSearchParams` インターフェイスが便利です。

```js
const sharedName = url.searchParams.get("name");
const sharedDescription = url.searchParams.get("description");
const sharedLink = url.searchParams.get("link");
```

### 共有されたデータを POST で受け取る

共有の要求が一つまたは複数のファイルを含むか、アプリケーションに副作用を及ぼす場合、HTTP の `POST` メソッドを使用するべきです。例えば、アプリケーションが処理対象の画像を受け取ったり、共有されたリンクをブックマークとしてデータベースに保存する場合が該当します。

```json
{
  "share\_target": {
    "action": "/save-bookmark/",
    "method": "POST",
    "enctype": "multipart/form-data",
    "params": {
      "url": "link"
    }
  }
}
```

`POST` により共有されたデータはサーバーサイドのコードで処理することもできますし、オフラインのユーザーによりよい体験を提供するため、サービスワーカー内で `fetch` イベントリスナーを用いて HTTP リクエストに割り込み、データにアクセスすることもできます。

```js
self.addEventListener("fetch", (event) => {
  // Web Share Target には関係ない通常のリクエスト
  if (event.request.method !== "POST") {
    event.respondWith(fetch(event.request));
    return;
  }

  // Web Share Target 関係のリクエスト
  event.respondWith(
    (async () => {
      const formData = await event.request.formData();
      const link = formData.get("link") || "";
      // 元の URL `/save-bookmark/` のかわりに、
      // `saveBookmark()` 関数が返す URL、例えば `/` に
      // ユーザーをリダイレクトします。
      const responseUrl = await saveBookmark(link);
      return Response.redirect(responseUrl, 303);
    })(),
  );
});
```

処理後、ユーザーがページをリロードした場合などに `POST` リクエストが複数回送られるのを防ぐため、この `POST` リクエストには HTTP の 303 See Other リダイレクトで応答するべきです。

### 共有されたファイルを受け取る

共有されたファイルを受け取るには、HTTP メソッドは `POST`、`enctype` は `multipart/form-data` とし、受け入れるファイルの種類を定義する `files` エントリーを用意しなければいけません。

`files` エントリーは `name` プロパティを持っていなければならず、`accept` プロパティは受け入れる MIME タイプまたはファイルの拡張子を指定しなければなりません。オペレーティングシステムがどっちを使いたいかが違うかもしれないので、両方を指定するのがおそらく良いでしょう。

```json
{
  "share\_target": {
    "action": "/file-collector",
    "method": "POST",
    "enctype": "multipart/form-data",
    "params": {
      "title": "name",
      "text": "description",
      "url": "link",
      "files": [
        {
          "name": "lists",
          "accept": ["text/csv", ".csv"]
        },
        {
          "name": "photos",
          "accept": ["image/svg+xml", ".svg"]
        }
      ]
    }
  }
}
```

共有されたファイルのデータを扱うためには、前述の `POST` の例を参照し、ファイルを読むために `FileReader` API を用います。サービスワーカーコンテキストからクライエントコンテキストにファイルを渡すための一つの方法として、ファイルを一時的に `Cache` または IndexedDB に格納し、クライアントに `Client.postMessage()` により通知する方法があります。

セキュリティとプライバシー
-------------

PWA は、インストールされている場合のみウェブ共有先として振る舞うことができます。PWA をインストール可能にするにはも参照してください。

HTML フォームから送信された場合と同様に、共有先としてアプリケーションに送られたデータは注意して扱うべきです。使う前に必ず入力データを検証してください。

仕様書
---

| Specification |
| --- |
| Web Share Target API # share\_target-member |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.


short_name - ウェブアプリマニフェスト

short\_name
===========

|  |  |
| --- | --- |
| 型 | `String` |
| 必須 | はい |

*`short_name`* メンバーは文字列で、 `name` を表示するのに十分なスペースがない場合 (例えば、携帯電話のホーム画面にあるアイコンのラベルなど) に、ユーザーに表示するウェブアプリケーションの名前を表します。 `short_name` は書字方向に対応しており、 `dir` および `lang` の各マニフェストメンバーの値に基づいて左書きで表示されたり右書きで表示されたりします。

例
-

単純な `short_name` を左書き言語で:

```json
"name": "Awesome application",
"short\_name": "Awesome app"
```

アラビア語で右書きの `short_name`:

```json
"dir": "rtl",
"lang": "ar",
"name": "تطبيق رائع",
"short\_name": "رائع"
```

仕様書
---

| Specification |
| --- |
| Web Application Manifest # short\_name-member |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.


icons - ウェブアプリマニフェスト

icons
=====

|  |  |
| --- | --- |
| 型 | 配列 (`Array`) |
| 必須 | はい |

`icons` メンバーは、様々なコンテキストでアプリケーションアイコンとして機能する画像ファイルを表すオブジェクトの配列を指定します。例えば、他のアプリケーションのリストの中でウェブアプリケーションを表現したり、ウェブアプリケーションを OS のタスクマネージャーやシステム環境設定と統合したりするために使用することができます。

例
-

```json
"icons": [
  {
    "src": "icon/lowres.webp",
    "sizes": "48x48",
    "type": "image/webp"
  },
  {
    "src": "icon/lowres",
    "sizes": "48x48"
  },
  {
    "src": "icon/hd\_hi.ico",
    "sizes": "72x72 96x96 128x128 256x256"
  },
  {
    "src": "icon/hd\_hi.svg",
    "sizes": "72x72"
  }
]
```

値
-

画像オブジェクトには、次の値を入れることができます。

| メンバー | 説明 |
| --- | --- |
| `sizes` | 画像の寸法を空白区切りで指定する文字列です。 |
| `src` | 画像ファイルへのパスです。 `src` が相対 URL である場合、基準 URL はマニフェストの URL です。 |
| `type` | 画像のメディア種別のヒントです。このメンバーは、ユーザーエージェントが対応していないメディア種別の画像を素早く無視することができるようにするためのものです。 |
| `purpose` | 画像の目的を定義します。例えば、画像がホスト OS の特定の場面で、特別な目的を果たすことを意図している場合などです (すなわち、よりよく統合するため)。
`purpose` は以下の値を 1 つ以上、空白で区切って指定することができます。* `monochrome`: ユーザーエージェントは、このアイコンを、 塗りつぶしのあるモノクロのアイコンが必要なときに表示することができます。アイコンの色情報は破棄され、アルファデータのみが使用されます。アルファデータのみが使用されます。このアイコンは、ユーザーエージェントが塗りつぶしのマスクのように使うことができます。
* `maskable`: 画像がアイコンのマスクと安全領域に配慮して設計されており、画像の安全領域外の部分をユーザーエージェントが無視したりマスクしたりしても安全になるようになっています。
* `any`: ユーザーエージェントはどのような場合でも、自由にこのアイコンを表示することができます (これが既定値です)。
 |

仕様書
---

| Specification |
| --- |
| Web Application Manifest # icons-member |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.


protocol_handlers - ウェブアプリマニフェスト

protocol\_handlers
==================

**非標準:** この機能は標準ではなく、標準化の予定もありません。公開されているウェブサイトには使用しないでください。ユーザーによっては使用できないことがあります。実装ごとに大きな差があることもあり、将来は振る舞いが変わるかもしれません。

|  |  |
| --- | --- |
| 型 | `Array` |
| 必須 | いいえ |

`protocol_handlers` メンバーは、このウェブアプリが登録・処理することができるプロトコルを表すオブジェクトの配列を指定します。プロトコルハンドラーは、 OS のアプリケーション設定にアプリケーションを登録します。登録は、特定のアプリケーションと与えられたプロトコルスキームを関連付けます。例えば、ウェブページで `mailto://` というプロトコルハンドラーを使用すると、登録されたメールアプリケーションが開きます。

プロトコルハンドラーとしてウェブアプリを登録すると、ユーザーがブラウザーやネイティブアプリから `mailto://` や `web+music://` などの特定のスキームを持つハイパーリンクをクリックすると、登録した PWA が開いてその URL を受信することができるようになります。

例
-

この例では、ウェブアプリのマニフェストで、プロトコルの `web+jngl` と `web+jnglstore` を処理するためにアプリを登録することを宣言しています。

```json
"protocol\_handlers": [
  {
    "protocol": "web+jngl",
    "url": "/lookup?type=%s"
  },
  {
    "protocol": "web+jnglstore",
    "url": "/shop?for=%s"
  }
]
```

開発者は manifest.json にフィールドを追加して、ウェブアプリがどのプロトコルを処理できるかを宣言することができます。上記の例で見られるように、キーは `protocol_handlers` という名前で、プロトコル ハンドラ宣言オブジェクトの配列が含まれています。

URL スキームを処理するためのアプリケーションの登録は、オペレーティングシステムに依存します。この関連付けは通常、アプリケーションのインストール時に行われますが、既にインストールされているアプリケーションから後で行われることもあります。

値
-

プロトコルハンドラーオブジェクトには、以下の値を指定することができます。

| メンバー | 説明 |
| --- | --- |
| `protocol` |
 必須の文字列で、処理するプロトコルを指定します。 例:
 `mailto`, `ms-word`, `web+jngl`.
  |
| `url` | プロトコルを処理するアプリケーションのスコープ (scope) 内の必要な HTTPS URL。 `%s` トークンは、プロトコルハンドラーのスキームで始まる URL に置換されます。 `url` が相対 URL であった場合、ベース URL はマニフェストの URL になります。 |

仕様書
---

この機能はどの仕様書にも含まれていません。 Manifest 仕様書へ追加する提案が行われています。 [1] [2]

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.


description - ウェブアプリマニフェスト

description
===========

|  |  |
| --- | --- |
| 型 | `String` |
| 必須 | いいえ |

`description` メンバーは、何をするアプリケーションなのかを開発者が説明することができる文字列です。 `description` には書字方向を設定することができ、マニフェストメンバーの `dir` と `lang` の値に基づいて左書きまたは右書きで表示することができます。

例
-

左書き言語用の単純な `description` です。

```json
"description": "Awesome application that will help you achieve your dreams."
```

アラビア語の `description` で、右書きで表示されます。

```json
"dir": "rtl",
"lang": "ar",
"description": ".تطبيق رائع سيساعدك على تحقيق أحلامك"
```

仕様書
---

| Specification |
| --- |
| Web App Manifest - Application Information # description-member |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.


theme_color - ウェブアプリマニフェスト

theme\_color
============

|  |  |
| --- | --- |
| 型 | `String` |
| 必須 | いいえ |

`theme_color` メンバーは文字列で、アプリケーションの既定のテーマカラーを定義します。これは OS がどのようにサイトを表示するかに影響することがあります (例えば、 Android のタスクスイッチャーでは、サイトの周りにテーマカラーが表示されます)。

例
-

```json
"theme\_color": "red"
```

仕様書
---

| Specification |
| --- |
| Web Application Manifest # theme\_color-member |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.


background_color - ウェブアプリマニフェスト

background\_color
=================

|  |  |
| --- | --- |
| 型 | `String` |
| 必須 | いいえ |

`background_color` メンバーは、スタイルシートが読み込まれる前に表示するアプリケーションページの背景色を定義します。 この値は、スタイルシートが読み込まれる前にマニフェストが利用可能な場合、ショートカットの背景色を描画するために、ユーザーエージェントが使用します。

したがって、 `background_color` はウェブアプリケーションを起動してからサイトのコンテンツを読み込むまでの間にスムーズに遷移できるよう、 CSS の `background-color` と一致させるべきです。

**メモ:** `background_color` メンバーは、メインスタイルシートがネットワークまたはストレージメディアから読み込まれている間にだけ、ユーザーの操作感を向上させるためだけのものです。プログレッシブウェブアプリのスタイルシートが利用できるようになった後は、ユーザーエージェントが CSS の `background-color` プロパティとして使用されることはありません。

例
-

```json
"background\_color": "red"
```

仕様書
---

| Specification |
| --- |
| Web Application Manifest # background\_color-member |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.


orientation - ウェブアプリマニフェスト

orientation
===========

|  |  |
| --- | --- |
| 型 | `String` |
| 必須 | いいえ |

`orientation` メンバーは、ウェブサイトの最上位の閲覧コンテキストすべてについて、既定の向きを定義します。

**メモ:** ユーザーエージェントの表示モードによっては、 `orientation` やその中の特定の値に対応していないことがあります。これらに対応することが、特定のコンテキストでは意味がないからです。

**メモ:** 実行時に画面の向きを変更するには、 Screen Orientation API を利用して実現することができます。

値
-

`orientation` は以下の値の内の一つを取ることができます。

* `any`
* `natural`
* `landscape`
* `landscape-primary`
* `landscape-secondary`
* `portrait`
* `portrait-primary`
* `portrait-secondary`
例
-

```json
"orientation": "portrait-primary"
```

仕様書
---

| Specification |
| --- |
| Web Application Manifest # orientation-member |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.


categories - ウェブアプリマニフェスト

categories
==========

|  |  |
| --- | --- |
| 型 | `String` の配列 (`Array`) |
| 必須 | いいえ |

`categories` メンバーは、アプリケーションが属すると思われるカテゴリーの名前を定義する文字列の配列です。標準化された値の一覧はありませんが、 W3C は既知のカテゴリーの一覧を保守しています。

**メモ:** `categories` は、ウェブアプリケーションの一覧を収集したり格納したりするヒントとしてのみ使用されます。検索エンジンやメタキーワードと同様に、カタログを無視して収集や格納を行うことができます。

**メモ:** `categories` の値は、格納したり収集したりする処理の前に小文字化されますので、 "News" と "news" は同じ値として扱われます。そもそも、開発者は小文字を使うことが推奨されています。

例
-

```json
"categories": ["books", "education", "medical"]
```

仕様書
---

| Specification |
| --- |
| Web App Manifest - Application Information # categories-member |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.


ウェブコンテンツ・アクセシビリティガイドラインを理解する - アクセシビリティ

ウェブコンテンツ・アクセシビリティガイドラインを理解する
============================

この一連の記事では、W3C ウェブコンテンツ・アクセシビリティガイドライン 2.0 または 2.1（WCAG、Web Content Accessibility Guidelines）で概説されている推奨事項に準拠するために必要な手順を理解するのに役立つ簡単な説明を提供します。

WCAG 2.0 と 2.1 は、さまざまな障碍を持つ人々にとってウェブコンテンツをよりアクセスしやすくするための詳細なガイドラインを提供しています。 それは包括的ですが信じられないほど詳細であり、そして迅速な理解を得ることは非常に困難です。 このため、さまざまな推奨事項を満たすために必要な実際的な手順をまとめ、必要に応じて詳細へのリンクを追加しました。

4 つの原則
------

WCAG は大きく 4 つの原則に分割されます — ウェブコンテンツがアクセス可能であるように熟慮**しなければならない**主要な事柄（WCAG 定義のためのアクセシビリティの 4 つの原則の理解（英語）を参照してください）。

以下の各リンクはこれらの分野をさらに拡大するページにあなたを連れて行くでしょう。 それらは、WCAG 2.0 および 2.1 の各ガイドラインで概説されている達成基準に準拠するように、ウェブコンテンツの書き方について実際的なアドバイスを与え、各原則をさらに細分化します。

* 知覚可能: ユーザーは、1 つ以上の感覚を使って何らかの方法でそれを知覚できなければなりません。
* 操作可能: ユーザーは、UI 要素を制御できなければなりません（例えば、ボタンは、マウス、キーボード、音声コマンドなど、何らかの方法でクリック可能でなければならない）。
* 理解可能: コンテンツはそのユーザーにとって理解可能でなければなりません。
* 堅牢: コンテンツは、現在および将来にわたって、さまざまなブラウザで機能する、広く採用されているウェブ標準を使用して開発する必要があります。
WCAG 2.0 と 2.1 のどちらを使うべきか？
--------------------------

WCAG 2.1 は最新かつ関連性のあるアクセシビリティ標準です。 WCAG 2.1 を使用して、より多くの障碍者を支援し、ウェブサイト所有者に対する将来の法的リスクを軽減します。 リソースを割り当てるときは、最初に WCAG 2.0 を目標にしてください。 それから WCAG 2.1 にステップアップしてください。

### WCAG 2.1 とは何か？

WCAG 2.1 は、2018 年 6 月 5 日に公式勧告として発行されました。 欧州連合（EU）は、2018 年 9 月にデジタルアクセシビリティ標準として WCAG 2.1 を採用しました。 W3C は、プレスリリース ヨーロッパにおける WCAG 2.1 の採用（英語）を発表しました。

WCAG 2.1 には以下が含まれます。

* WCAG 2.0 の全て（逐語的、一字一句違わないで）
* A / AA / AAA レベルの 17 の新しい達成基準は、主に次の分野におけるユーザーのニーズに対応しています。
    + モバイルアクセシビリティ
    + ロービジョン
    + 認知
* WCAG 2.1 についてもっと読む
    + Deque: WCAG 2.1: アクセシビリティガイドラインの次のステップ（英語）
    + TPG: ウェブコンテンツ・アクセシビリティガイドライン（WCAG）2.1（英語）
法的地位
----

このガイドは、より良く、よりアクセスしやすいウェブサイトを構築するのに役立つ実用的な情報を提供することを目的としています。 しかし、私たちは弁護士ではありません、そしてこれのどれも法的助言を構成しません。 ウェブのアクセシビリティが法的にどのような意味を持つのかを心配している場合は、あなたの国や地域のウェブや公共のリソースに対するアクセシビリティを規定する特定の法律を調べ、有資格の弁護士に相談することをお勧めします。

アクセシビリティとは？と、その中のアクセシビリティのガイドラインと法律のセクションには、より関連性の高い情報が記載されています。


モバイルアクセシビリティのチェックリスト - アクセシビリティ

モバイルアクセシビリティのチェックリスト
====================

このドキュメントは、モバイルアプリ開発者向けのアクセシビリティ要件の簡潔なチェックリストを提供します。 それはより多くのパターンが生じるにつれて絶えず進化することを意図しています。

色
-

* カラーコントラストは、WCAG 2.0（英語）の AA レベルの要件に準拠**しなければならない**。
    + 通常のテキストでは、4.5:1 のコントラスト比（18 ポイント未満または 14 ポイント未満の太字）。
    + 大きなテキストでは、3:1 のコントラスト比（少なくとも 18 ポイントまたは 14 ポイントの太字）。
* 色で伝えられる情報は、他の方法でも利用可能**でなければならない**（リンクのための下線付きテキストなど）。
可視性
---

* `opacity` がゼロ、`z-index` 順、画面外配置のようなコンテンツ非表示テクニックは、可視性を扱うためだけに使用**してはいけない**。
* 現在の表示画面以外のものは、本当に見えないもの**でなければならない**（特に複数のカードを含む単一ページのアプリに関連します）。
    + `hidden` 属性、`visibility` スタイルプロパティ、または `display` スタイルプロパティを**使用します**。
    + 絶対に避けられない場合を除いて、`aria-hidden` 属性は使用**するべきではない**（SHOULD NOT）。
フォーカス
-----

* 全てのアクティブ化可能要素はフォーカス可能**でなければならない**。
    + リンク、ボタン、フォームフィールドのような標準コントロールは、デフォルトでフォーカス可能です。
    + 非標準コントロールには、`button`、`link`、`checkbox` のような適切な ARIA のロール（英語）が割り当てられて**いなければならない**。
* フォーカスは、論理的な順序と一貫した方法で扱われるべきです。
同等のテキスト
-------

* アプリ内の全ての非厳密で提示的な非テキスト要素には、同等のテキストを提供**しなければならない**。
    + 必要に応じて `alt` と `title` を使用してください（良いガイドについては、HTML の title 属性の使用（英語）に関する Steve Faulkner の投稿を参照してください）。
    + 上記の属性が適用できない場合は、`aria-label`、`aria-labelledby`、`aria-describedby` のような適切な ARIA のプロパティ（英語）を使用してください。
* テキストの画像は避け**なければならない**。
* スクリーンリーダーを使用するユーザーのために、全てのフォームコントロールにラベル（`<label>` 要素）を持た**なければならない**。
ステートの取り扱い
---------

* ラジオボタンやチェックボックスのような標準コントロールは、オペレーティングシステムによって処理されます。 ただし、他のカスタムコントロールでは、`aria-checked`、`aria-disabled`、`aria-selected`、`aria-extended`、および `aria-press` のような ARIA のステート（英語）を介してステートの変更を提供する必要があります。
一般的なガイドライン
----------

* アプリのタイトルを提供**しなければならない**。
* 見出しは階層構造を壊**してはならない**。

```html
<h1>最上位の見出し</h1>
<h2>副見出し</h2>
<h2>別の副見出し</h2>
<h3>下位の見出し</h3>
```

* `banner`、`complementary`、`contentinfo`、`main`、`navigation`、`search` のような ARIA のランドマークロール（英語）は、アプリやドキュメントの構造を説明するために使用**するべきです**（SHOULD）。
* タッチイベントハンドラは、`touchend` イベントでのみトリガ**されなければならない**。
* タッチターゲットは、ユーザーが対話するのに十分な大きさ**でなければならない**（有用なタッチターゲットサイズのガイドラインについては、BBC モバイルアクセシビリティ・ガイドライン（英語）を参照してください）。

**メモ:** この文書のオリジナル版（英語）は、Yura Zenevich によって書かれました。


キーボードで操作可能な JavaScript ウィジェット - アクセシビリティ

キーボードで操作可能な JavaScript ウィジェット
=============================

### 概要

ウェブアプリケーションは、メニュー、ツリービュー、リッチテキストフィールド、タブパネルなどのデスクトップウィジェットを模倣するために JavaScript を使用することがよくあります。 これらのウィジェットは通常、 `<div>` 要素や `<span>` 要素で構成されています。これらの要素は本来、デスクトップのものと同じキーボード機能を提供しません。 このドキュメントは JavaScript ウィジェットをキーボードでアクセス可能にするためのテクニックを説明します。

### tabindex を使う

デフォルトでは、人々がウェブページを閲覧するために `Tab` キーを使うとき、（リンクやフォームコントロールのような）インタラクティブ要素だけがフォーカスされます。 `tabindex` グローバル属性を使うと、作成者は他の要素もフォーカス可能にできます。 `0` に設定すると、要素はキーボードとスクリプトによってフォーカス可能になります。 `-1` に設定すると、要素はスクリプトによってフォーカス可能になりますが、キーボードによるフォーカスの順序の一部にはなりません。

キーボードを使用したときに要素がフォーカスを得る順序は、デフォルトではソースの順序です。 例外的な状況では、作成者は順序を再定義したいと思うかもしれません。 これを行うために、作成者は `tabindex` を任意の正数に設定することができます。

**警告:** `tabindex` に正の値を使わないでください。 `tabindex` に正の値を持つ要素は、ページ上のデフォルトのインタラクティブ要素の前に配置されます。 つまり、ページ作成者は、`tabindex` に 1 以上の正の値を使用する時は必ず、ページ上の全てのフォーカス可能要素に対して `tabindex` の値を設定（および維持）する必要があります。

次の表は、最新のブラウザーにおける `tabindex` の動作を説明しています。

| `tabindex` 属性 | JavaScript で `element.focus()` を介してフォーカス可 | タブで移動可 |
| --- | --- | --- |
| 存在しない | 要素のプラットフォームの習慣に従う（フォームコントロールやリンクなどでは可）。 | 要素のプラットフォームの習慣に従う。 |
| 負（すなわち `tabindex="-1"`） | 可 | 不可。矢印キーなどの押下に応答して `focus()` で要素をフォーカスさせる必要があります。 |
| Zero （すなわち `tabindex="0"`) | 可 | 文書内の要素の位置からの相対的なタブ順序（なお、 `<a>` のような操作可能な要素は既定でこの動作をするので、この属性は必要ありません。）。 |
| Positive (e.g. `tabindex="33"`) | 可 | `tabindex` の値は、この要素がタブ順序のどこに位置するかを決定します。小さい値を指定すると、大きい値よりタブ順序の早い位置に要素を配置します（例えば、`tabindex="7"` は `tabindex="11"` より前に配置されます）。 |

#### ネイティブでないコントロール

`<a>`、`<input>`、`<select>` のような操作可能ななネイティブ HTML 要素はすでにキーボードによりアクセス可能であるため、これらのいずれかを使用することが、コンポーネントをキーボードで使えるようにするための最速の方法です。

`<div>` や `<span>` をキーボードでアクセス可能にするには、 `tabindex` を `0` で追加することによって実現できます。これは、 HTML には存在しない操作可能な要素を使用するコンポーネントに特に役立ちます。

#### コントロールのグループ化

メニュー、タブリスト、グリッド、ツリービューなどのウィジェットをグループ化するには、親要素をタブ順序に入れて（`tabindex="0"`）、各子孫の選択項目/タブ/セル/行をタブ順序から除く（`tabindex="-1"`）必要があります。 ユーザーは矢印キーを使って子孫要素に移動できるようにすべきです。 （典型的なウィジェットに通常期待されるキーボードサポートの詳細な説明については、WAI-ARIA のオーサリングプラクティス（英語）を参照してください。）

以下の例は、入れ子になったメニューコントロールで使用されるこのテクニックを示しています。 キーボードフォーカスが含まれている `<ul>` 要素に到達したら、JavaScript 開発者はプログラム的にフォーカスを管理し、矢印キーに応答する必要があります。 ウィジェット内でフォーカスを管理するためのテクニックについては、以下の「グループ内のフォーカス管理」を参照してください。

```html
<ul id="mb1" tabindex="0">
  <li id="mb1\_menu1" tabindex="-1">
    フォント
    <ul id="fontMenu" title="フォント" tabindex="-1">
      <li id="sans-serif" tabindex="-1">サンセリフ</li>
      <li id="serif" tabindex="-1">セリフ</li>
      <li id="monospace" tabindex="-1">モノスペース</li>
      <li id="fantasy" tabindex="-1">ファンタジー</li>
    </ul>
  </li>
  <li id="mb1\_menu2" tabindex="-1">
    スタイル
    <ul id="styleMenu" title="スタイル" tabindex="-1">
      <li id="italic" tabindex="-1">斜体</li>
      <li id="bold" tabindex="-1">太字</li>
      <li id="underline" tabindex="-1">下線</li>
    </ul>
  </li>
  <li id="mb1\_menu3" tabindex="-1">
    位置揃え
    <ul id="justificationMenu" title="位置揃え" tabindex="-1">
      <li id="left" tabindex="-1">左</li>
      <li id="center" tabindex="-1">中央</li>
      <li id="right" tabindex="-1">右</li>
      <li id="justify" tabindex="-1">両端</li>
    </ul>
  </li>
</ul>
```

#### 無効なコントロール

カスタムコントロールが無効になったら、`tabindex="-1"` を設定して、タブ順序から除いてください。 グループ化されたウィジェット内の無効な項目（メニュー内のメニュー項目など）は、矢印キーを使用して移動可能なままにするべきであることに注意してください。

### グループ内のフォーカス管理

ユーザーがウィジェットからタブで離れてから戻ると、フォーカスはフォーカスを持っていた特定の要素、例えば、ツリーアイテムやグリッドセルに戻るべきです。 これを実現するには次の 2 つのテクニックがあります。

1. 動き回る `tabindex`: プログラム的にフォーカスを移動
2. `aria-activedescendant`: 「仮想」フォーカスの管理

#### テクニック 1: 動き回る tabindex

フォーカスされた要素の `tabindex` を `"0"` に設定すると、ユーザーがウィジェットからタブで離れてから戻ってきた場合でも、グループ内の選択された項目にフォーカスが保持されます。 `tabindex` を "0" に更新したら、以前に選択した項目を `tabindex="-1"` に更新する必要もあることに注意してください。 このテクニックでは、キーイベントに応答してプログラムでフォーカスを移動し、現在フォーカスされた項目を反映するように `tabindex` を更新します。 次を行います。

キーダウンハンドラーをグループ内の各要素にバインドし、矢印キーを使用して別の要素に移動した場合、

1. プログラム的に新しい要素にフォーカスを適用します。
2. フォーカスされた要素の `tabindex` を "0" に更新します。
3. 以前にフォーカスされた要素の `tabindex` を "-1" に更新します。

これはこのテクニックを使った WAI-ARIA ツリービューの例です。

### ヒント

#### element.focus() を使ってフォーカスを設定する

要素にフォーカスを移すために `createEvent()`、`initEvent()`、および `dispatchEvent()` を使用しないでください。 DOM フォーカスイベントは情報提供のみを目的としています。 何かがフォーカスされた後にシステムによって生成されますが、実際にはフォーカスの設定には使用されません。 代わりに `element.focus()` を使用してください。

#### onfocus を使って現在のフォーカスを追跡する

全てのフォーカスの変更がキーイベントやマウスイベントを介して行われるとは限りません。 スクリーンリーダーなどの支援技術では、フォーカスを任意のフォーカス可能な要素に設定できます。 代わりに `onfocus` と `onblur` を使ってフォーカスを追跡します。

`onfocus` と `onblur` は全ての要素で使用できるようになりました。 現在のドキュメントのフォーカスを取得するための標準的な DOM インターフェースはありません。 フォーカスの状態を追跡したい場合は、document.activeElement を使ってアクティブな要素を取得できます。 document.hasFocus を使って、現在のドキュメントのフォーカスかどうかを確認することもできます。

### テクニック 2: `aria-activedescendant`

このテクニックでは、単一のイベントハンドラーをコンテナウィジェットにバインドし、`aria-activedescendant` を使用して「仮想」フォーカスを追跡します。 （ARIA に関する詳細は、アクセス可能なウェブアプリケーションとウィジェットの概要を参照してください。）

`aria-activedescendant` プロパティは、現在仮想フォーカスを持っている子孫要素の ID を識別します。 コンテナのイベントハンドラーは、`aria-activedescendant` の値を更新し、（例えば、境界線や背景色で）現在の項目が適切にスタイル設定されていることを確実にすることで、キーイベントおよびマウスイベントに応答する必要があります。

### 一般的なガイドライン

#### onkeypress ではなく onkeydown を使ってキーイベントをトラップする

IE は、英数字以外のキーに対する `keypress` イベントを発生させません。 代わりに `onkeydown` を使用してください。

#### キーボードとマウスが同じ操作を生み出すことを確実にする

ユーザーの操作が入力機器に関係なく一貫していることを保証するために、キーボードとマウスのイベントハンドラーは適切な場所でコードを共有するべきです。 例えば、ユーザーが矢印キーを使用して移動したときに `tabindex` やスタイルを更新するコードは、マウスクリックハンドラーでも同じ変化を生み出すために使用するべきです。

#### キーボードを使用して要素をアクティブにできることを確実にする

キーボードを使用して要素をアクティブにできることを確実にするには、マウスイベントにバインドされているハンドラーもキーボードイベントにバインドするべきです。 例えば、`onclick="doSomething()"` がある場合、`Enter` キーで要素がアクティブにできることを確実にするには、`onkeydown="return event.keyCode !== 13 || doSomething();"` で `doSomething()` をキーダウンイベントにもバインドするべきです。

#### tabindex="-1" の項目およびプログラムでフォーカスを受け取る要素に常にフォーカスを描画する

プログラム的にフォーカスを受け取る項目には、IE は自動的にフォーカスの輪郭を描画しません。 背景色を `this.style.backgroundColor = "gray";` のようなもので変更するか、または `this.style.border = "1px dotted invert"` で点線の境界線を追加することの中から選らんでください。 点線の境界線の場合は、最初から見えない 1px の境界線があるようにして、境界線スタイルを適用しても要素が大きくならないようにする必要があります（境界線はスペースを取り、IE は CSS アウトラインを実装しません）。

#### 使用したキーイベントがブラウザー機能を実行しないようにする

ウィジェットがキーイベントを処理する場合は、イベントハンドラーのリターンコードを使用して、ブラウザーもそれを処理しないようにします（例えば、矢印キーに応答してスクロールするなど）。 イベントハンドラーが `false` を返した場合、そのイベントはハンドラーを超えて伝播しません。

例えば、

```html
<span tabindex="-1" onkeydown="return handleKeyDown();">…</span>
```

`handleKeyDown()` が `false` を返すと、イベントは消費され、ブラウザーはキーストロークに基づいたアクションを実行できなくなります。

#### 現時点では、キーリピートに一貫した動作を当てにしないこと

残念ながら `onkeydown` は、使用しているブラウザーや OS によってはリピートするかもしれないし、しないかもしれません。


アクセシブルなウェブアプリケーションやウィジェットの概要 - アクセシビリティ

アクセシブルなウェブアプリケーションやウィジェットの概要
============================

ほとんどの JavaScript ライブラリーでは、デスクトップで慣れ親しんだインターフェースの動作を模倣した、クライアントサイドウィジェットのライブラリーが提供されています。スライダー、メニューバー、ファイルリストビューなどは、JavaScript、CSS、HTMLの組み合わせで構築することができます。HTML4 の規格では、この種のウィジェットを意味的に記述する組み込みタグが提供されていないため、開発者は一般に `<div>` や `<span>` などの汎用の要素を使用することになります。この結果、デスクトップと同じように見えるウィジェットができますが、通常、マークアップには支援技術で使用するのに十分な意味づけの情報がありません。

問題点
---

ウェブページ上の動的コンテンツは、どのような理由であれ画面を見ることができないユーザーにとって特に問題になる可能性があります。株価表示、Twitter のフィード更新、進捗の表示やそれらに似たコンテンツは、支援技術 (AT) が認識できないかもしれない方法で DOM を変更します。ここが、ARIA が必要になるところです。

*例 1: ARIA でラベルをつけずに作成したタブウィジェットのマークアップ。ウィジェットの外観や機能を示す情報は、マークアップ内にありません。*

```html
<!-- これはタブウィジェットです。マークアップだけを見て、どのようにしてわかるのでしょうか?-->
<ol>
  <li id="ch1Tab">
    <a href="#ch1Panel">Chapter 1</a>
  </li>
  <li id="ch2Tab">
    <a href="#ch2Panel">Chapter 2</a>
  </li>
  <li id="quizTab">
    <a href="#quizPanel">Quiz</a>
  </li>
</ol>

<div>
  <div id="ch1Panel">Chapter 1 content goes here</div>
  <div id="ch2Panel">Chapter 2 content goes here</div>
  <div id="quizPanel">Quiz content goes here</div>
</div>
```

*例 2: タブウィジェットはどのようにして視覚的にスタイルが設定されるのでしょうか。ユーザーはそれを視覚的に認識するでしょう。しかし、支援技術向けに機械が読み取れる意味の情報はありません。*
![タブウィジェットのスクリーンショット](/ja/docs/Web/Accessibility/An_overview_of_accessible_web_applications_and_widgets/tabs_widget.png)

ARIA
----

**ARIA**は、開発者がマークアップに特別な属性を追加することによって、ウィジェットをより詳細に記述することができるようにしています。標準的な HTML タグと、動的なウェブアプリケーションで得られるデスクトップスタイルのコントロールとの間のギャップを埋めるために設計された ARIA は、ほとんどの慣れた UI ウィジェットの挙動を記述する役割と状態を提供します。

**警告:** これらの多くは、ブラウザーが現代の HTML の機能に完全には対応していなかったため、後に追加されたものです。**開発者は常に、ARIA を使用するよりも正しい意味づけの HTML 要素を使用することを優先すべきです**。

ARIA 仕様書は 3 種類の属性に分けられています: ロール、ステート、プロパティです。ロールは HTML 4 において他の方法で利用できないウィジェット、例えばスライダー、メニューバー、タブ、ダイアログなどを説明します。プロパティはこれらのウィジェットの特徴、例えばドラッグ可能、必須の要素がある、関連づけられたポップアップがあるなどを説明します。ステートは要素について支援技術に伝える現在の対話状態、例えば動作中、無効、選択中、不可視などの状態を説明します。

ARIA の属性はブラウザーによって自動的に解釈され、オペレーティングシステムのネイティブなアクセシビリティ API に変換されるように設計されています。ARIA が提供されていると、支援技術は独自の JavaScript コントロールについて、デスクトップにおける同等物と同じ方法で、認識および対話をすることができます。

支援技術のユーザーがウェブベースのアプリケーションを使用するときに、デスクトップアプリケーションの動作に関するあらゆる知識を適用できますので、以前のウェブアプリケーションより一貫したユーザーエクスペリエンスをもたらす可能性を秘めています。

*例 3: ARIA の属性を追加したタブウィジェットのマークアップ。*

```html
<!-- \*これら\* はタブです!-->
<!-- タブリストや各タブを表すために、role 属性を追加しました。-->
<ol role="tablist">
  <li id="ch1Tab" role="tab">
    <a href="#ch1Panel">Chapter 1</a>
  </li>
  <li id="ch2Tab" role="tab">
    <a href="#ch2Panel">Chapter 2</a>
  </li>
  <li id="quizTab" role="tab">
    <a href="#quizPanel">Quiz</a>
  </li>
</ol>

<div>
  <!-- タブのパネルを表すために追加した role および aria-labelledby 属性に注目してください。-->
  <div id="ch1Panel" role="tabpanel" aria-labelledby="ch1Tab">
    Chapter 1 content goes here
  </div>
  <div id="ch2Panel" role="tabpanel" aria-labelledby="ch2Tab">
    Chapter 2 content goes here
  </div>
  <div id="quizPanel" role="tabpanel" aria-labelledby="quizTab">
    Quiz content goes here
  </div>
</div>
```

ARIA はすべての主要なブラウザーや多くの支援技術が幅広く対応しています。

### 表現の変化

動的な表現の変化には、コンテンツを表示させたり隠したりすることはもちろん、コンテンツの外見を変える (不正なデータを囲む赤色の境界線、チェックされたチェックボックスの背景色を変えるなど) ために CSS を使用することも含みます。

#### 状態の変化

ARIA に、UI ウィジェットの現在の状態を定義する属性があります。例えば以下のとおりです （これだけではありません）。

`aria-checked`

チェックボックスやラジオボタンの状態を示します。

`aria-disabled`

要素は可視状態ですが、編集や他の操作ができないことを示します。

`aria-grabbed`

ドラッグ & ドロップ操作で、オブジェクトが「つかまれている」状態を示します。

（ARIA のすべてのステートの一覧については、ARIA のステートとプロパティの一覧をご覧ください。）

開発者は UI ウィジェット要素の状態を示すために ARIA のステートを使用して、ステートの変化に基づく視覚的外見の変更に（スクリプトを使用して要素のクラス名を変更するのではなく） CSS の属性セレクターを使用してください。

#### 可視性の変化

コンテンツの可視性を変える（例えば要素を隠したり表示したりする）とき、開発者は **`aria-hidden`** プロパティの値を変更するとよいでしょう。先に説明した手法を、`display:none` を使用して要素を視覚的に隠すという CSS を示すために使用してください。

これは、可視性の制御に **`aria-hidden`** を使用するツールチップの例です。この例では、入力フィールドに関する指示を収めたツールチップを持つシンプルなウェブフォームの例を示しています。例の中で関係する部分を、以下で説明します。

この例でツールチップ用の HTML は、以下に示す形になっています。9 行目で **`aria-hidden`** を `true` に設定しています。

```html
<div class="text">
  <label id="tp1-label" for="first">First Name:</label>
  <input
 type="text"
 id="first"
 name="first"
 size="20"
 aria-labelledby="tp1-label"
 aria-describedby="tp1"
 aria-required="false" />
  <div id="tp1" class="tooltip" role="tooltip" aria-hidden="true">
    Your first name is optional
  </div>
</div>
```

このマークアップ用の CSS を以下に示します。ここでは独自のクラス名を使用せず、1 行目で **`aria-hidden`** 属性の状態のみを使用していることに注意してください。

```css
div.tooltip[aria-hidden="true"] {
  display: none;
}
```

**`aria-hidden`** プロパティを更新するための JavaScript は、以下のコードにある形になります。このスクリプトは **`aria-hidden`** 属性しか更新しないことに注意してください (2 行目)。独自のクラス名の追加や削除は不要です。

```js
function showTip(el) {
  el.setAttribute("aria-hidden", "false");
}
```

### ロールの変化

ARIA では、開発者が要素の意味づけの役割を宣言することができます。要素の **`role`** は変更してはいけません。その代わり、元の要素を削除し、新しい **`role`** を持つ要素に置き換えてください。

例えば「インライン編集」ウィジェットについて考えてみましょう: これはコンテキストを切り替えることなく、ユーザーがその場でひとまとまりのテキストを編集できるコンポーネントです。このコンポーネントは、テキストの編集はできませんがアクティブ化が可能な「閲覧」モードと、テキストの編集が可能な「編集」モードがあります。開発者は、ARIA の **`role`** を `button` に設定した読み取り専用の text 型 `<input>` 要素で「閲覧」モードを実装して、要素を書き換え可能にするとともに「閲覧」モードの **`role`** 属性を削除する (`<input>` は自身のロールを意味として持っているため) ことで「編集」モードに切り替えようと考えるでしょう。

これを行ってはいけません。代わりに **`role`** が `button` である `<div>` や `<span>` といった、まったく別の要素を使用して「閲覧」モードを、また text 型の `<input>` 要素を要して「編集」モードを実装してください。

### 非同期のコンテンツ変更

**メモ:** 作成中です。ライブリージョン もご覧ください。

キーボード操作
-------

開発者は、独自のウィジェットを作成する際にキーボードのサポートを見落とすことがよくあります。さまざまなユーザーにとってアクセシブルにするために、すべてのウェブアプリケーションやウィジェットはマウスを必要とせずにキーボードでも操作できるようにするべきです。実際、通常これはデスクトップにおける同様のウィジェットがサポートする慣習への準拠度を向上させて、Tab、Enter、スペース、矢印キーのあらゆる利点を獲得します。

伝統的に、ウェブにおけるキーボード操作は Tab キーに限定されてきました。ユーザーはページ内の各リンク、ボタン、フォームへ順番にフォーカスを当てるために Tab キーを、逆順に進むために Shift-Tab を押します。これは一次元、つまり一度に 1 つの要素で、進むまたは戻る操作です。かなり分量の多いページでは、キーボードのみ使用するユーザーは必要なセクションへアクセスするまでに何度も Tab キーを押さなければなりません。ウェブにおいてデスクトップスタイルのキーボード操作の慣習を実装すると、多くのユーザーで操作が劇的に高速化する可能性があります。

以下は、ARIA が有効なウェブアプリケーションで、どのようなキーボード操作が動作すべきかの概要です。

* Tab キーで、全体としてウィジェットへフォーカスを当てます。例えばメニューバーで Tab キーを押すと、メニューの最初の項目にフォーカスを当てるべきです。
* 矢印キーで、ウィジェット内での選択や操作をできるようにすべきです。例えば左または右矢印キーを使用すると、前や次のメニュー項目にフォーカスを移動できるようにします。
* フォームの中にないウィジェットは、 Enter やスペースキーでコントロールの選択やアクティブ化を行えるようにすべきです。
* フォーム内で、スペースキーはコントロールの選択やアクティブ化を、Enter キーはフォームの既定のアクションの実行を行えるようにすべきです。
* 迷った場合は作成するコントロールの、デスクトップにおける標準的な動作を模倣しましょう。

従って、前出のタブウィジェットの例では、ユーザーが Tab および Shift+Tab キーを使用してウィジェットのコンテナー（マークアップにおける `<ol>`）に出入りする操作を行えるとよいでしょう。キーボードのフォーカスがコンテナー内に入ったら、矢印キーで各々のタブ（`<li>` 要素）を行き来できるとよいでしょう。ここからは、プラットフォームによって慣習が異なります。 Windows では、ユーザーが矢印キーを押すと自動的に次のタブがアクティブ化されます。 macOS では、ユーザーは次のタブをアクティブ化するために Enter またはスペースキーを押します。キーボードで操作可能な JavaScript ウィジェット作成の包括的なチュートリアルで、このような動作を JavaScript で実装する方法を説明します。

関連情報
----

* ARIA
* キーボードで操作可能な JavaScript ウィジェットを書く
* WAI-ARIA Specification
* WAI-ARIA Authoring Practices


ARIA - アクセシビリティ

ARIA
====

Accessible Rich Internet Applications **(ARIA)** はロールや属性の集合で、ウェブコンテンツやウェブアプリケーション（特に JavaScript で開発するもの）を、ハンディキャップを持つ人々にとってよりアクセシブルにする方法を定義します。

ARIA は、アプリケーションで一般的に使用されている対話操作やウィジェットを、他のメカニズムがない場合に支援技術に渡すことができるように HTML を補完します。例えば ARIA は、アクセシビリティのある JavaScript ウィジェット、フォームのヒント、エラーメッセージ、ライブコンテンツ更新などを可能にします。

**警告:** これらのウィジェットの多くは、代のブラウザーで完全に対応しています。意味的に正しい HTML 要素が存在するのであれば、 **ARIA を使用するよりも、その要素を使用したほうがいいでしょう**。例えば、ネイティブな要素にはキーボードのアクセシビリティやロール、状態が組み込まれています。しかし、 ARIA を使用する場合は、スクリプトで（同等の）ブラウザーの動作を模倣する責任があります。

ARIA の最初のルール は、「要素を再利用し、それをアクセシブルにするために ARIA のロール、状態、プロパティを追加する代わりに、要求される意味づけと動作がすでに組み込まれているネイティブの HTML 要素または属性を使用することができるなら、そうすること」です。

**メモ:** 「ARIA なしは悪い ARIA に勝る」という言葉があります。 100 万以上のホームページを対象とした WebAim の調査では、 ARIA を表示しているホームページは、 ARIA を表示していないホームページに比べて、検出されたエラーが平均 41% 多いことが分かりました。 ARIA はウェブページをよりアクセシビリティの高いものにするために設計されていますが、誤った使用をしてしまうと、良いことより害悪が勝ることがあります。

プログレスバーウィジェットのためのマークアップです。

```html
<div
 id="percent-loaded"
 role="progressbar"
 aria-valuenow="75"
 aria-valuemin="0"
 aria-valuemax="100"></div>
```

このプログレスバーは、意味を持たない `<div>` を使って作られています。 ARIA ロールとプロパティで意味を追加します。この例では、 `role="progressbar"` 属性により、この要素が実際には JavaScript を使用したプログレスバーウィジェットであることをブラウザーに伝えています。 `aria-valuemin` (en-US) および `aria-valuemax` (en-US) 属性はプログレスバーの最小値と最大値を指定し、 `aria-valuenow` (en-US) は現在の状態を表すため、 JavaScript から更新し続けます。

マークアップに直接配置するとともに、 ARIA の属性を要素に追加して、次のような JavaScript コードを使用して動的に更新することができます。

```js
// プログレスバーの <div> を DOM 内で探す。
const progressBar = document.getElementById("percent-loaded");

// ARIA ロールと状態を設定することで、
// 支援技術がウィジェットの種類を知ることができる。
progressBar.setAttribute("role", "progressbar");
progressBar.setAttribute("aria-valuemin", 0);
progressBar.setAttribute("aria-valuemax", 100);

// プログレスバーの値を更新したいときにいつでも呼び出せる
// 関数を作成する。
function updateProgress(percentComplete) {
  progressBar.setAttribute("aria-valuenow", percentComplete);
}
```

支援技術を使用していないユーザーが利用できるコンテンツは、すべて支援技術でも利用できるようにしなければなりません。同様に、支援技術を使用しないユーザーもアクセスできないような、支援技術ユーザーを対象とした機能を記載してはなりません。上記のプログレスバーは、プログレスバーのように見えるようにスタイル設定する必要があります。

代わりにネイティブの `<progress>` 要素を使用した方がずっと簡単でしょう。

```html
<progress id="percent-loaded" value="75" max="100">75 %</progress>
```

**メモ:** `min` 属性は `<progress>` 要素では許可されません。その最小値は常に `0` です。

**メモ:** HTML のランドマーク要素（`<main>`、`<header>`、`<nav>` など）は、組み込みの暗黙の ARIA ロールを持っているので、それらを重複指定する必要はありません。

対応
--

他のウェブ技術と同様に、 ARIA の対応には様々な程度があります。対応の程度は、使用しているオペレーティングシステムとブラウザー、それらと連携している支援技術の種類によって異なります。また、OS、ブラウザー、支援技術のバージョンも要因となります。古いバージョンのソフトウェアは、特定の ARIA ロールを対応していなかったり、部分的にしか対応していなかったり、機能を誤って報告していたりする可能性があります。

また、支援技術に依存している人の中には、コンピューターやブラウザーとのやり取りができなくなることを恐れて、ソフトウェアの更新に消極的な人がいることも認識しておく必要があります。そのため、できるだけ意味を持った HTML 要素を使用することが重要です。意味を持った HTML は、支援技術への対応がはるかに優れているからです。

また、作成した ARIA を実際の支援技術でテストすることも重要です。ブラウザーのエミュレーターやシミュレーターを使っても、完全な対応をテストするために効果的ではないのと同様に、代理の支援技術ソリューションを使用しても、機能性を完全に保証することはできません。

リファレンス
------

ARIA ロール

MDN 上のすべての WAI-ARIA ロールをカバーするリファレンスページです。

ARIA 状態とプロパティ

MDN で説明されているすべての WAI-ARIA の状態とプロパティに応じたリファレンスページです。

標準化の取り組み
--------

WAI-ARIA 仕様書

W3C の仕様書そのものです。

WAI-ARIA authoring practices

一般的なウィジェットや対話操作をどのように ARIA 化するのが最良なのかを記述した、公式のベストプラクティス文書です。優れたリソースです。

スクリプトウィジェット向け ARIA
------------------

キーボードで操作可能な JavaScript ウィジェットを書く

`<input>` や `<button>` などのような組み込み要素は、キーボードのアクセシビリティが組み込まれています。これらを `<div>` と ARIA で「偽装」する場合は、ウィジェットがキーボードでアクセシブルであることを保証する必要があります。

ライブリージョン

ライブリージョンは、ページのコンテンツが変更された場合に、スクリーンリーダーにどのように対処すべきかを提案します。

動画
--

ARIA を理解するには、以下の講演が最適です。

ARIA, Accessibility APIs and coding like you give a damn! – Léonie Watson


ウェブアクセシビリティ: 色と輝度を理解する - アクセシビリティ

ウェブアクセシビリティ: 色と輝度を理解する
======================

色、輝度、彩度を理解することは、視力のあるすべてのユーザーにとってデザインや読み取り可能性を高めるために重要ですが、視力が低下している人や色覚障碍のある人、特定の神経障碍や認知障碍、他にも障碍のある人にとっては不可欠です。

アクセシビリティガイドラインでは、視力が低下したユーザーのために適切な色のコントラスト (en-US)を定義するとともに、一般に「色覚障碍」と呼ばれる色に鈍感なユーザーを支援することを意図したガイドラインも定義しています。色を理解することは、前庭障碍や その他の神経障碍を持つ人の発作やその他の身体的反応 (en-US)を防ぐためにも重要です。

概要
--

色の選択と使用は、アクセシビリティの重要な要素です。表面的には、この問題は単純に見えます。というのも、色を知覚することは、コンピューター画面から発せられる光と同じくらい、目の生理学や人間の脳の処理に関係しているからです。

### 環境と知覚

環境は重要です。同じコンピューター画面上の同じ色でも、暗い部屋で見るのと、明るい部屋で見るのとでは、色の感じ方が異なります。アクセシビリティに関しては、ある特定の色の組み合わせを使用することが、他の組み合わせよりも影響があると言えます。フォントサイズ、フォントスタイル（とても細いフォントやおしゃれなフォントの中には、自分自身でアクセシビリティの問題を説明しているものもあります）、背景色、テキストの周りの背景空間の大きさ、ピクセル密度などすべてが、画面に表示される色に影響します。

画面から視聴者の距離、環境的背景、目の健康状態など、すべてが色が視聴者にどのように受け取られるかに影響します。色が目に届いた後、視聴者がどのように色を認識するかはまた別の問題で、全体的な健康状態にも影響されます。幸い、メディアクエリーがあり、コントラストや配色の環境設定を含め、ユーザーの環境設定に基づいたスタイルを提供することができます。

対応している場合、環境光センサー (Ambient Light Sensor) インターフェイスは、センサーのある端末の周辺の環境光における現在の光量または照度を返しますので、ウェブページが光量の変化を認識し、それに応じてテキストを調整することができます。さらに、上記のメディアクエリーにより、ユーザーの環境設定が好みのコントラストレベルを示している場合、開発者は代替のユーザーインターフェイスを提供することができ、ユーザーの場所や使用する画面に応じてレベルを自動的に調整することができます。

### 輝度と知覚

色、コントラスト、輝度は、色を使ったアクセシビリティの高いウェブコンテンツを作成する上で、最も中心的かつ重要な概念です。しかし、輝度は具体的な重要性を持っています。輝度とは何か、そして輝度をどのように使用するかを理解することで、色を知覚できる人だけでなく、色覚障碍の人にとってもアクセシビリティが有効になるからです。輝度のコントラストをつけることにより、色覚障碍者が明暗を判別することができるようになります。

コントラストを設定する前に、輝度を設定する必要があります。色のコントラストについて話すとき、 W3C の数式は色（「色相」）そのものではなく、輝度を取り入れています。

### 用語

異なる用語が同じことを記述することが多いため、用語は混乱することがあります。特に「輝度」と「彩度」は正しく理解することが重要です。例えば、「彩度」はある業界では「クロマ」と呼ばれている一方、「クロマ」と「彩度」は異なる概念とする業界もあります。 HSL 色空間の "L" は「明度」とされることもありますし、「輝度」と呼ばれる場合もあります。一般的な色の名前のような単純に見えるものでさえ、議論の余地があります。例えば、「深紅の赤」という色は16進数値で記述されるとき、ある人は `#990000` と記述し、他の人は `#DC143C` と記述します。この文書では、 W3C の CSS Color Module Level 4 で定義されている用語を使用します。

色を使って作業する場合、どの「色空間」で作業しているかを知ることが重要です。色空間が異なると、異なる測定システムに割り当てられるからです。

色を印刷する場合、お使いのプリンターにはシアン、マゼンタ、黄、黒 (CMYK) のインクカートリッジがあるでしょう。 CMYK は減法混色モデルで、 4 つのインクが固有の波長の光を除去し、それぞれが関連する狭い範囲のみを反映します。 RGB は加法混色モデルで、赤、緑、青の光をさまざまな割合で追加します。

現在、ウェブ開発者が作業する空間としては RGB 色空間が主流です。 HEX、RGB、HSL 色空間は異なる形で表記されますが、ブラウザーはこれらの色表記間の値を自動的に変換します。 CSS カラーモジュール は追加の色空間を提供します。それでも、色出力を測定する上で RGB 色空間が現在支配的であるため、この文書内のほとんどの計算では RGB 色空間、そしてとても特殊な場合には sRGB 色空間での計算を想定しています。

sRGB 色空間
--------

色には、`<color>` データ型 を入力することで明らかなように、RGB、RGB 10進数、RGB パーセント、HSL、HWB、LCH、CMYK、他にも多くの定義する方法があります。

デジタルに関わる技術の多くは、過去にはRGB色空間を使用していました。 RGB 色モデルは、色の不透明度を指定できるように、「アルファ」を含めるために拡張されています (RGBA)。色を測定するための他のメソッドは、他の色空間を使用して測定し、現代のディスプレイやブラウザーの対応しています。それでも、動画制作を含め、 RGB 色空間での色測定が主流です。

OpenGL や Direct3D などの技術では、 sRGB ガンマ曲線の対応が組み込まれていますが、 OpenGL の記事の中には sRGB ではなく RGBA の使用を参照しているものもあります。 WebGL は通常 RGBA 形式です。「色で消去 (en-US)」に使用する例があります。

### CSS カラー値

RGB 色空間のように、 1 つの色空間の中にも派生形があることを知っておくことは重要です。例えば、 RGB 色空間の派生形には、**RGB**、**sRGB**、**Adobe RGB**、**Adobe Wide Gamut RGB**、**RGBA** などがあります。

この例は、色を定義するために使用する CSS 記法の例です。この例では、例えば完全に不透明なマゼンタ色を使用しています。

```css
/\* 名前付きの色 \*/
color: magenta;

/\* パーセント値による sRGB 値 \*/
color: rgb(100% 0% 100%);
color: rgb(100% 0% 100% / 100%);

/\* 数値による sRGB 値 \*/
color: rgb(255 0 255);
color: rgb(255 0 255 / 1);

/\* 古い rgba 記法 \*/
color: rgba(100%, 0%, 100%, 100%);
color: rgba(255, 0, 255, 1);

/\* 16 進による sRGB 値 \*/
color: #f0f; /\* #rgb、#rrggbb の短縮形 \*/
color: #ff00ff; /\* #rrggbb \*/
color: #f0ff; /\* #rgba \*/
color: #ff00ffff; /\* #rrggbbaa \*/

/\* sRGB 値の HSL 表現 \*/
color: hsl(300 100% 50%);
color: hsl(300deg 100% 50% / 1);

/\* sRGB 値の HWB 表現 \*/
color: hwb(300deg 0% 0%);
color: hwb(300 0% 0% / 1);
```

最初の例では、定義済みの名前付きの色を使用しています。

sRGB の値を直接パーセントで設定するには、 0% をオフ（黒）、 100% をその色の完全な値にします。値は赤、緑、青の順です。 sRGB 値を 0 から 255 までの数値で直接設定することもできます。

その後に示されているのが 16 進数の色値です。 16 進数とは、 16 を基数とした数値体系で、 0～255 の整数を 0～9、10～15 を a～f を使用して 0～15 の 2 桁で表します。したがって、 `ff` = `255`、`00` = `0`、`d5` = `200`となります。色の前に'#'記号を付けると、値が 16 進数であることを示します。

すべての値が同じ数字のペアである場合、値は単一の数字で表すことができ、ブラウザーはそれを複製します。したがって `f00` は `ff0000` と同じです。もし 4 つ目の数字の集合が存在するならば、その値は RGBA の A であり、アルファチャンネルで色の透過率を定義します。値が大きいほど色は不透明であり、したがって透過率は低くなります。上の例では、アルファ値は `f`、`ff`、`1`、そして完全に不透明な場合は `100%` となります。

この例は古い `rgba()` 構文も示しています。色関数の古い構文はカンマ区切りで、アルファチャンネルを記載するために別個の関数がありました。新しい色関数は、（カンマ区切りではなく）空間区切りの値を持つ 1 つの構文のみで、アルファチャンネルが存在する場合は、その前にスラッシュを記述します。

次の例は "HSL" を示しています。"HSL" は *Hue, Saturation, Lightness* の略です。 HSL の色値は、 RGB 値よりも直感的であると多くの人に考えられています。設定から生成される色はまだ sRGB 色空間ですが、 `hsl()` は多くの人にとって直感的な構文です。色相は角度として調整され、色相を調整するためにノブや円形のコントロールを使用してユーザーインターフェイスを作成するのは簡単です。HSL 色は輝度ではなく明るさであることに注意してください。

最後の例は "HWB" を示しています。"HWB" は *Hue, Whiteness, Blackness* の略です。 `rgba()` や `hsla()` とは異なり、 `hwb()` は古い `a` つきの構文がなく、カンマ区切りの値にも対応していません。 `hsl()` と `hwb()` の両方とも、最初の値は `<number>` または `<angle>` になります。単位がない場合、値は `deg` 度として解釈されます。

### 変換

これまで見てきたように、同じ色空間内の 1 つの色でもさまざまな方法で発生する可能性があります。 RGB 色空間がどのように「マゼンタ」という色を記述するのに使用されているかを見ていくと、同じ色が、 rgb 値に変換される 3 桁の短縮形の 16 進数で表現されたり、同じ rgb 値に変換される 6 桁の 16 進数で表現されたり、パーセントで表現される rgba 値で表現されたりすることがわかります。

RGBはCRTを使用することを反映したハードウェア指向のものです。多くの開発者やデザイナーは、直感的な `hsl()` 記法を推奨しています。 RGB から HSL への変換は単純な式ではできません。幸いなことに、ブラウザーは自動的にそれを行いますし、ブラウザーの開発者ツールでは色をシフトを押しながらクリックすると、変換する機能を提供しています。

開発者ツールに加えて、 RGB を HSL に変換し、 RGB の 16 進数と CSS 関数の構文の両方を提供するツールもたくさんあります。例えば、Tom Jewett 氏の "mini color selector" は、ブラウザーでコントラストを調べるための HSL、RGB、Hex オプションを備えており、色を変換してくれるツールの素晴らしい例です。開発者ツールのカラーピッカーとこのツールは、すべて WCAG の color contrast の値を提供することに注意してください。

![HSL と RGB、色のコントラスト値を持つカラーピッカー。](/ja/docs/Web/Accessibility/Understanding_Colors_and_Luminance/microcolorsc.jpg)

前述のように、 CSS color module には、 `lch()` 色関数記法や、 `lab()` 色座標系を含む色空間を追加することができますが、 sRGB は既定のものであり、アクセビリティのために推奨される色空間です。

しかし、アクセシビリティに関する標準と規格の作成は、特に色のコントラスト比に適用される sRGB 色空間を主に使用しています。

**メモ:** 今日、ウェブコンテンツを表示するために使用されているほとんどすべてのシステムは、 sRGB エンコード方式を想定しています。コンテンツの処理と表示に別の色空間を使用することがわかっていない限り、作成者は sRGB 色空間を使用して評価する必要があります。他にも色空間を用いる場合は、最小コントラスト比の原則を適用してください。

CSS Color Module Level 5 では、 `lch()` 色関数記法と、`lab()` 色座標系が導入され、任意の可視色を指定することができるようになりました。これらは将来的に sRGB 色空間の支配を変えるでしょうが、私たちはまだそこに到達していません。

### 色値の問い合わせ

`Window.getComputedStyle()` メソッドは、 RGB 10 進参照スケールを使用して値を返します。例えば、`background-color: #990000;` を設定した div に対して `Window.getComputedStyle()` を呼び出すと、計算された背景色を `rgb(153 0 0)` — RGB 10 進参照として返します。コンピュータのハードウェアに関連しているため、 `Window.getComputedStyle()` は RGB の観点から色を測定します。

### 赤緑色覚障碍

1 型 2 色覚は、赤錐体を保有しない色覚障碍のことです。 sRGB は、通常の視覚よりも暗いものの、緑色の錐体を介して知覚することができます。 1 型色覚（赤）と 2 型色覚（緑）の両方が欠乏すると、赤と緑を判別することが難しくなります。

開発者ツールは、 ブラウザーで色覚の違いをシミュレーションするのに 役立ちます。例えば、 Firefox のアクセシビリティインスペクターでは、アクセシビリティパネルで 1 型 2 色覚、2 型 2 色覚、3 型 2 色覚、1 色覚、コントラスト低下を正しくシミュレーションできます。

![シミュレーションポップアップを示す Firefox 開発者ツールのスニペット](/ja/docs/Web/Accessibility/Understanding_Colors_and_Luminance/simulate_color_differences.png)

輝度とコントラスト
---------

### コントラスト

色（「色相」）間のコントラストは重要な成分ですが、色（「色相」）を使用するだけではアクセシビリティのあるコンテンツを作成することはできません。前述したように、コントラストを計算するためには輝度を含める必要があります。

さらに、文字そのものの「図形」も重要です。細い文字は太い文字よりも読みにくくなります。どの書体も、人間の知覚のために「呼吸」する空間が必要です。

### コントラストとフォントサイズ

WCAG コントラストガイドラインでは、 `font-weight` が `normal` の場合は `18pt` （約 `24px`）以上、 `bold` の場合は `14pt`（約 `18.7px`）以上のテキストを「大きい」テキストと定義しています。以下のように書いています。

>
> より大きく、より広い文字ストロークを持つテキストは、コントラストが低くても読みやすくなります。したがって、大きなテキストに要求されるコントラストは低くなります。このため、作成者は大きなテキストに幅広い色の選択肢を使用することができます。これはページ、特にタイトルのデザインに有益です。
>
>
>

大きなテキストは小さなテキストほど背景との色のコントラストを要求されませんが、フォントサイズを大きくすることは万能ではありません。

「通常の」印刷は通常 11.5pt から 12pt と考えられており、画面に表示される 16px に相当します。フォントを小さくすれば、ユーザーは 70% 以下の精度で文字を読み取ることができますが、それは読み取り可能なフォントではありません。 16px のフォントサイズは、一般的に正常な視力の人にとって読み取り可能なサイズです。しかし 20/40 の人はその 2 倍、約 31px のフォントが必要です。このため、 WCAG ガイドラインでは、ユーザーが文字を拡大表示できるようにすることを要求されています。

小さすぎる文字も読みにくいですが、大きすぎる文字も読みにくいものです。視力 20/20 のユーザーにとって、文字サイズが約 96px を超えると、読むスピードが低下します。また、ページ上の最小フォントサイズと最大フォントサイズに大きな差がある場合、ほとんどのブラウザーはユーザーがズームするとすべてのテキストが拡大されるため、ページ上の小さなテキストを拡大すると、大きなテキストは読み取り可能なサイズではなくなってしまいます。

一般的に、アクセシビリティのためには、コントラストは高ければ高いほど良いとされています。それがアニメーションでは変わります。「より安全な」アニメーションとは、コントラストが高い画像ではなく、低い画像を意味しています。アニメーションにおける色のコントラストについては、 Three Flashes or Below Threshold Understanding SC 2.3.1 を参照してください。

また、アイコンは知覚のために十分なコントラストが必要であることにも注意してください。 WCAG 2.1 technique G207 を参照してください。

### 輝度

コントラストがわかるのは色の輝度の違いです。 WCAG では相対輝度を「色空間における任意の点の相対的な明るさで、最も暗い黒を 0、最も明るい白を 1 に正規化したもの」と定義しています。

もちろんこの記述は正確なものですが、 0～255 の整数である RGB 色空間を参照して使用すると混乱する可能性があります。白は 100% の相対輝度であり、黒は 0% の相対輝度です（すべての文献ではありませんが）。上記の W3C 標準を解釈すると、1に正規化された白は `rgb(255 255 255)` の RGB 値を持ち、 0 に正規化された黒は `rgb(0 0 0)` の RGB 値を持つことを意味しています。黒と白はそれぞれ `rgb(100% 100% 100%)`, `rgb(0% 0% 0%)` と書くこともできることに注意してください。

では、この 0 から 255 の数値はどこから決まるのでしょうか？過去には、グラフィックエンジンは色のチャンネルを 1 バイト、つまり 0 から 255 までの整数の範囲として格納していました。

原色の輝度は異なります。例えば、黄色は青よりも輝度が高くなります。これは、 NASA の文書 "Luminance Contrast in Color Graphics" によると、「モニターの白の配置を達成するため」という設計上の理由によるものです。

色のコントラスト比は輝度成分がなければ意味がなく、輝度が決まれば色のコントラスト比が決まります。

人間の知覚において、輝度の違いは色の違いよりも重要です。輝度コントラストによって、色覚障碍者でも見ることができるコンテンツを開発することができるからです。このことを理解すれば、輝度が低いために見えにくい色でも、輝度が対照的な別の色と配置することで、より見やすくなるように輝度を操作できるかもしれません。例えば、 NASA による青色に関する興味深い研究では、輝度が低いこの色も、適切な輝度コントラストが得られるように注意を払えば、見やすくすることができると指摘しています（この記事 Designing with blue より）。

相対輝度の計算は簡単ではありません。幸いなことに、オンライン輝度・コントラストチェッカーが利用できますし、相対輝度の計算の方法の説明書もあります。

色の知覚
----

色とは、赤から黄、緑、青に至る可視光の狭い帯域を知覚することです。これらの様々な色に対する感度は同じではありません。私たちの目にある光に敏感な細胞は、錐体と呼ばれ、他にも複数の色を認識するように調整されています。錐体の約 65% は黄色/緑に最も敏感ですが、赤にも反応します（これを「赤」錐体と呼びます）。 30% は緑に敏感で、青に敏感なものはわずか 5% です。青に感応する錐体は他の 2 種類よりはるかに少ないのですが、これらの錐体はとても感度が高いので、数の少なさを部分的に補っています。

青の錐体は輝度に寄与せず、赤や緑に比べて青の錐体の数ははるかに少ないため、深みのある純粋な青は他の色とは異なる形で知覚されます。

![左は標準視の錐体モザイクで、右は赤錐体が欠けている 1 型 2 色覚の人のものです。](/ja/docs/Web/Accessibility/Understanding_Colors_and_Luminance/conemosaics.jpg)

左は標準視の中心錐体モザイク、右は色覚障碍の形成する形で赤錐体が欠損している 1 型 2 色覚の人のモザイク。（イラスト： RIT の Mark Fairchild、Wikimedia Commons）

赤錐体と緑錐体は一緒になって輝度を作成します。輝度とは、色相を考慮しない明暗のことです。赤錐体、緑錐体、青錐体は別個のもので、何百万もの色を認識する標準的な視覚を可能にします。アクセシビリティを考える上で、私たちの脳は輝度を色（色相、カラフルさ）とは別個のものとして処理していることを知っておくことは重要です。

輝度は、輪郭や 文字を区別することを含め、視覚の細部に指定されたものです。色相と彩度は輝度の約 3 分の 1 です。画像データの圧縮は、この事実を利用しています。例えば、 h.264 動画コーデックは、輝度の 4 分の 1 の解像度で色をサンプリングします。

アクセシビリティのためには、テキストでは輝度のコントラストが決定的に重要であるということです。色は、色相やカラフルさのように、地図上の様々な線やグラフの棒のようなアイテムを識別するために重要です。

もうひとつ考慮すべき重要な点は、色を取り囲む色や輝度です。色は、それを取り囲むものによって異なる形で現れます。以下の画像では、黄色の点も灰色の四角も同じ sRGB 色です。色の近くはコンテキストに敏感ので、これらは異なる形に見えます。脳の画像処理は、影があるかないかによって知覚を調整するのです。

![市松模様の画像。同じ色でも影になると違って見えます。](/ja/docs/Web/Accessibility/Understanding_Colors_and_Luminance/yellowdotcheckershadow_dlyon.png)

この画像の黄色い点は、モニター上では同じ色ですが、コンテキストによって異なる形で見えます。（画像: D.Lyon）

私たちのコントラスト、明度、色知覚は、近くの色やデザインや画像の他の機能のコンテキストに影響されます。そのため、コントラストを予測することは難しいのです。それは 2 つの色の間の数学的比率のように単純ではありません。

まとめると、色はコンピューター画面からの光を測定するのと同じくらい、人間の生理学と脳における知覚に関係しているということです。また、周囲の光環境が色やコントラストを知覚する能力に影響を与えることも理解しておく必要があります。光とその測定は直線的ですが、人間の視覚と知覚は直線的ではありません。

順応
--

私たちの目は、明るいところから暗いところへ、あるいはその逆へと、同じように順応するわけではありません。これは、私たちの目が生理学的に作られているためです。このことは、ユーザーが背景に対してテキストを読む能力に影響します。少なくとも2種類の適応が導かれます。局所適応と周囲環境への適応です。

局所適応は、読者が見ている「ページ」上で正しく行われます。例えば、グレーの「強調」領域内に青いテキストがある場合、それが黒い `<div>` の中にある場合と白いものの中にある場合とでは、グレーの強調を持つその正確な青いテキストを、目は異なる形で知覚します。これは局所適応と呼ばれます。このようなテキストを知覚する能力の違いは、たとえ部屋の周囲の照明が変化しなくても影響を受けます。

その意味するところは、背景に対するテキストの読みやすさを改善しようとするウェブ開発者は、暗順応の原理を活用できるということです。

低輝度に対する暗順応は遅くなります。太陽が明るい外から入ってきて暗い部屋に入ると、暗順応が起こります。これに慣れるにはいくらか時間がかかります。

光順応はその逆です。暗い部屋から明るい日差しに入ると順応は速いのですが、痛みも伴います。

つまり、部屋の環境条件が変化したときにテキストの読みやすさを改善しようとするウェブ開発者は、 `AmbientLightSensor` インターフェイスと `prefers-contrast` メディアクエリーを活用できるということです。

彩度
--

 色（「色相」）とアクセシビリティに関する議論において、彩度は特筆に値します。一般的に、テキストとその背景の間の十分なコントラストを確実に保持しようとする場合、または光過敏性発作に敏感な人に発作を誘発する可能性を評価する場合、ほとんどの場合、輝度に焦点が当てられます。色（「色相」）のある側面は、輝度とは関係なく、アクセシビリティに適用されるものとして特別な注意を払う必要があります。これは、色の輝度に関係なく、光過敏性発作に感受性のある人に発作を発生させる可能性があるためです。赤の特例で議論したように、
 Epilepsy Foundation は、*輝度に関係なく、彩度の高い赤からのトランジション、または彩度の高い赤へのトランジションもリスクと考えられる*と注意をしています。

彩度は色の「純度」や「濃さ」と記述されることがあります。これらはアーティストの絵具集合に含まれる「顔料」としては良い定義ですが、コンピューター画面からの色の定義としては正確ではありません。

モニター上の色に関して言えば、彩度の高い色は特定の波長を持っています。色空間ごとに彩度の定義は異なるかもしれませんが、彩度は容易に測定できます。重要なのは、あなたがどの色空間で作業しているかを把握し、必要に応じて変換できるようにしておくことです。

受光感度を議論する際に最も頻繁に考慮される色空間は、RGB、HSL、および HSV （HSB とも呼ばれる）色空間です。 HSV 色空間は *hue*, *saturation*, *value* を表し、同義語の HSB は *hue*, *saturation*, *brightness* を表します。CSSでは *hue*, *whiteness*, *blackness* を `hwb()` として表します。

作業する色空間が何であるかを知っておくことは重要です。例えば、彩度の高い色は HSL では明度が `0.5` ですが、HWB では値が `1` となります。 RGB 色空間における飽和は、通常その色の RGB 値 `255` または `100%` で示されます。例えば、 16 進数値 `#ff0000` の飽和赤は RGB 値 `rgb(255 0 0)` と HSL 値 `hsl(0 100% 50%)` があります。 16 進数値 `#ff3300` の異なる飽和赤は RGB 値が `rgb(255 51 0)`、HSL値が `hsl(12 100% 50%)` です。どちらも「飽和」赤です。これらは異なる「色相」ですが、どちらも飽和色とみなされます。

彩度は明度ではありません。明度とは、色にどれだけ白や黒が混合されているかを参照するものです。色に白、黒、グレーを加えることで彩度を下げることができます。例えば、白を加えることで明度を上げ、彩度を下げることができます。典型的な例は、赤に白を追加してピンクを作成することです。ピンクは彩度を落とした赤とみなされます。

### 彩度と輝度

輝度が両極端で、黒と白が極端な場合、彩度が低下します。NASAの彩度に対する輝度の影響では、低輝度での彩度の損失があることを指摘しています。同様に、「...高輝度での彩度の損失 - 色は白に収束します」。

色の組み合わせ
-------

アクセシビリティを考慮する場合、コントラストだけでは十分ではありません。アニメーションの場合、色の組み合わせによっては、他の色よりも光過敏性発作を発生させる可能性が高くなります。例えば、赤と青を交互に点滅させることは、緑と青を交互に点滅させることよりも問題が生じやすくなります。これは、目の「赤」に感受性のある錐体は窩（中心付近）に集まる傾向がありますが、「青」に感受性のある錐体は窩から離れた縁の方に位置するため、物理的に異なる形で配置されているためだと考えられています。目から脳への電気信号は、脳で情報が処理される際に、両者の間で多くの解決すべき問題があります。

てんかん発作を発生させやすい色もあります。脳のダイナミクスの基盤となる複雑さは、複数の色の組み合わせによって、他にも増して変調をきたすことがあります。例えば、赤と青の明滅による刺激は、赤と緑や青と緑の刺激よりも大きな皮質の興奮を発生させます。

コンピューターモニターやモバイル端末では、特定の色の組み合わせがとても問題になることがあります。また、色の組み合わせによっては、一部の障害を妨げることがあります。赤と青の組み合わせはこの例の一つです。

* 細部の区別を色相だけに頼ってはいけません。十分な輝度コントラストが要求されます。
* モニターの緑は輝度（光）の大部分を占めるため、通常は明るい色の大部分を占めることになります。
### 青での作業

すべての色を区別できない人もいます。純粋な青など、輝度の低い色もあります。輝度の低い色は、対比的な色の中で暗いほうを選ぶべきです。青は分解能もとても低い色です。青の錐体ははるかに少なく、周辺視野に散在し、中心視野には存在しません。人間の目は、緑や赤よりも低い解像度で青を見ているのです。

これは、いくつかの青い色を使用するガイドラインにつながります。

* 純粋な青は通常、 2 色のうち最も濃い色であるべきです。
* 2 色のうち薄い方の青を使用する場合は、緑を追加してコントラストを高め、読み取りやすくしてください。

青色光はその性質上、網膜上の赤色とは異なる形で焦点を結ぶため、純粋な赤色と純粋な青色が隣り合って接していると「ゆらめく」ことがあります。

赤の特例
----

すべての色（「色相」）が脳で同じように処理されるわけではありません。人間の生理学と心理学は、一般的に言って、他の色とは異なる形で赤色に影響を受けます。私たちは、色に対して生理的・心理的に反応します。例えば、ある色は他の色よりもてんかん発作を発生させやすいことが実証されています。端末によっては、アクセシビリティオプションとしての「グレースケール」設定を提供しているものもあり、写真に敏感な人を支援することができます。グレースケール設定を模倣するには、 CSS の `filter` プロパティで `grayscale()` または `saturate()` フィルター関数 (`<filter-function>`) を使用してください。

### 飽和赤

「飽和赤」は特別で危険なケースであり、それに対する特別なテストがあります。

色の飽和の概念は、数字や用語だけを見ていると理解しにくいものなので、色の飽和の概念を示す下記の画像を見て考えてみてください。

![赤の彩度（Wikimedia Commons より）png 属性として保存された SVG: Datumizer [CC0]](/ja/docs/Web/Accessibility/Understanding_Colors_and_Luminance/320px-red_saturations.svg.png)

同じ「色」でも、左側の彩度が低いものから右側の彩度が高いものへと進んでいきます。

複数の「赤」が「飽和」赤とみなされる場合があります。例えば、色 `#990000` (`hsl(0 100% 30%)`) におけるは完全に飽和していますが、記述した色よりも明度が低くなっています。同様に、色 `#8b0000` も 100% の彩度を持ちます。

すべての飽和赤が RGB スペクトルやウェブ開発者を使用する他のスペクトルでうまく表されているとは限りません。 Wikipedia の "Shades of Red" のページによると、 "Carmine" という色は飽和赤で、その顔料の形で、波長が 600nm より長い赤色光のほとんどを含みます。この記事では、 "Carmine" は極端なスペクトルに近いと特記されています。「これは標準色域 (RGB と CMYK) をはるかに超えて配置され、指定された RGB 値は貧弱な近似値でしかありません。」

### 飽和赤の点滅

赤い環境が外傷性脳損傷者の認知機能に影響を与えることに加え、赤いスペクトルの波長の色は特別な注意とテストが要求されます。

グレッグ・ヴァンダーハイデンは、てんかん分析ツール「Photosensitive epilepsy」をテストした際、発作率が予想よりもはるかに高かったことをメモしました。彼らは、私たちが飽和赤の点滅に対してはるかに敏感であることを得ました。（動画光刺激性てんかん分析ツールを参照。）

### 点滅と発作

1 秒間に 3 回以上の点滅を続けることで、光発作を誘発する人がいることが示されています。また、白と黒の並列したストライプのような、特定の、とても規則的でコントラストの高いパターンも発作を誘発することが分かっています。

米国てんかん財団は、光・パターン誘発発作を研究しました。この研究の結果、いくつかの基本的なガイドラインが発表されました：

1. 1 秒間に単一の閃光、 2 回の閃光、 3 回の閃光は受け入れられるが、 1 秒間に 3 回以上の閃光が起こるような連続した閃光は推奨されません。
2. 明暗の縞を表示する場合、縞の向きが変わったり、発振したり、点滅したり、コントラストが反転したりする場合は、明暗の縞の組の表示を 5 組までにし、縞の向きが変わらないか、一方向に連続して滑らかに流れる場合は、明暗の縞の組の表示を 8 組までにします。

コンセンサス勧告は、この短い論文 Photic- and Pattern-induced Seizures: Expert Consensus of the Epilepsy Foundation of America にあります。発作を予防するためのガイドラインを論じた英国の論文には、さらにいくつかの知見が利用できます。

色の心理物理学的側面
----------

色相や彩度といった色は、私たちの気分に影響を与え、操作する体験を高めたり、あるいは低下させたりします。

### 視覚以外の色彩効果の例

* **色は文化に左右されることがある:** A Cross-Cultural Study of the Affective Meanings of Color
* **色は感情に影響を与える:** Color and emotion: effects of hue, saturation, and brightness
* **コントラストが高いと、感情にも正の効果がある:** Emotion Variation from Controlling Contrast of Visual Contents through EEG-Based Deep Emotion Recognition
* **色によっては時間の感覚に影響を与えるものがある:** Color and time perception: Evidence for temporal overestimation of blue stimuli
* **青は明るさやまぶしさにも大きな影響を与える:** Blue and glare & brightness
* **赤い色眼鏡は幸福感や喜びを向上させる:** Looking Through "Rose-Tinted" Glasses: The Influence of Tint on Visual Affective Processing
* **赤は私たちの行動に大きな影響を与えることがよく知られている:** How the Color Red Influences Our Behavior, Scientific American, S. Martinez-Conde, Stephen L. Macknik
* **赤の環境:** Studies have shown that for those who suffer Traumatic Brain Injury, cognitive function is reduced in a red environment.
関連情報
----

* アクセシビリティ
* アクセシビリティの学習経路
* CSS の `color` プロパティ
* `<color>` データ型
* 発作と身体反応に関するウェブアクセシビリティ (en-US)
* How the Color Red Influences Our Behavior Scientific American By Susana Martinez-Conde, Stephen L. Macknik on November 1, 2014
* Red Desaturation 人間の目は赤に敏感に反応するため、眼科医は赤を使用する検査を設定し、視神経の健全性を評価している。
* Photic- and pattern-induced seizures: expert consensus of the Epilepsy Foundation of America Working Group


操作可能 - アクセシビリティ

操作可能
====

この記事では、ウェブコンテンツ・アクセシビリティガイドライン（WCAG）2.0 および 2.1 の**操作可能**原則に概説されている達成基準に準拠するようにウェブコンテンツを作成する方法についての実用的なアドバイスを提供します。 操作可能とは、ユーザーインターフェイス・コンポーネントとナビゲーションが操作可能でなければならないということです。

**メモ:** 操作可能の W3C の定義とそのガイドラインおよび達成基準を読むには、原則 2: 操作可能 — ユーザーインターフェース・コンポーネントとナビゲーションが操作可能でなければならない（英語）を参照してください。

ガイドライン 2.1 — キーボードアクセス可能: キーボードから全ての機能を利用可能にする
----------------------------------------------

このガイドラインは、キーボード制御に頼るユーザーがコアウェブサイト機能にアクセスできるように、他の手段（例えば、マウス）に加えてキーボードを介してそれらを利用可能にする必要性をカバーする。

| 達成基準 | 基準への準拠方法 | 実用的なリソース |
| --- | --- | --- |
| 2.1.1 キーボード (A) | キーボードを使用して行えない場合（例えば、フリーハンド描画）を除き、全ての機能はキーボード制御を使用してアクセス可能であるべきです。 可能な場合は組み込みのコントロールを使用するべきで（例えば、フォームコントロール間のタブ移動）、必要な場合にのみカスタム機能を組み込むべきです。 | UI コントロールとキーボードアクセシビリティを呼び戻すように盛り込むを参照してください。 |
| 2.1.2 キーボードを閉じ込めない (A) | キーボードを使用してある機能のセクションに入るときは、キーボード**のみ**を使用してそのセクションから再び出ることができるべきです。 例えば、フォーカスのあるボタンの上で `Enter` / `Return` を押してオプションウィンドウを開いたら、キーボードを使ってそのウィンドウを再び閉じてメインコンテンツに戻ることができるべきです。キーボードユーザーをアプリの特定のセクションに閉じ込めないようにするために、これは非常に重要です。 |  |
| 2.1.3 キーボード — 全機能 (AAA) | これは、基準 2.1.1 を超えるさらなるステップです。 AAA 準拠を達成するために、全ての機能はキーボードコントロールを使用してアクセス可能であるべきです — 例外なく。 | UI コントロールとキーボードアクセシビリティを呼び戻すように盛り込むを参照してください。 |
| 2.1.4 文字キーショートカット (A) 2.1 で追加（英語） | 単一文字キーショートカットが存在する場合は、少なくとも次の 1 つが当てはまります。 単一文字キーショートカットは、オフにする、再マップする、または関連するユーザーインターフェース・コンポーネントにフォーカスがあるときにのみアクティブにすることができます。 | 文字キーショートカットを理解する（英語） |

**メモ:** ガイドライン 2.1: キーボードアクセス可能: キーボードから全ての機能を利用可能にする（英語）に関する WCAG の説明も参照してください。

ガイドライン 2.2 — 十分な時間: コンテンツを読んで使用するのに十分な時間をユーザーに提供する
--------------------------------------------------

このガイドラインでは、機能に制限時間があるかもしれない状況について説明します。 例えば、セキュリティ上の理由から、購入を制限時間内に完了する必要がある場合があります。

| 達成基準 | 基準への準拠方法 | 実用的なリソース |
| --- | --- | --- |
| 2.2.1 タイミングは調整可能 (A) | 制限時間付きの機能の場合（例えば、ホテルやフライトの予約を完了するには制限時間があることが多い）、ユーザーには、制限時間の調整、延長、または無効化を許可するコントロールを与えるべきです。これに対する例外は、20 時間を超える制限時間のある活動、リアルタイムイベント（例えば、ライブマルチプレイヤーゲーム）、および制限時間が必要で、無効にされた場合に無効になるその他の活動です。 |  |
| 2.2.2 一時停止、停止、非表示 (A) | 自動的に開始され、5 秒以上続き、他のコンテンツと一緒に表示されるコンテンツを移動や点滅させるには、一時停止、停止、または非表示にするためのコントロールを提供するべきです。 これは、体験に不可欠なコンテンツの移動や点滅には適用されません。 例としては、テキストのスクロールと動画があります。自動的に開始され、他のコンテンツと一緒に表示される自動更新情報の場合は、一時停止、停止、または非表示にするため、あるいは更新頻度を制御するためのコントロールを提供するべきです。 これは、体験に不可欠なコンテンツの自動更新には当てはまりません。 例としては、回転木馬や回転アナウンスがあります。 |  |
| 2.2.3 制限時間なし (AAA) | これは基準 2.2.1 に基づいており、AAA 適合に合格したいコンテンツには制限時間がないことを述べています。 |  |
| 2.2.4 中断を抑止する (AAA) | アラートやインタースティシャル広告などによる中断には、緊急アラートでない限り、それらを抑制または延期するための機能を用意するべきです。 |  |
| 2.2.5 再認証 (AAA) | ウェブアプリの使用中に認証セッションが期限切れになった場合、ユーザーはデータを失うことなく再認証して使用を続けることができます。 |  |
| 2.2.6 タイムアウト (AAA) 2.1 で追加（英語） | タイムアウトした場合（ユーザーの非活動状態が原因で）、プロセスの開始時にユーザーに警告するので、タイムアウトが存在していても驚くことはありません（または、20 時間の非活動状態の後にのみタイムアウトするようにします）。 | タイムアウトを理解する（英語） |

**メモ:** ガイドライン 2.2: 十分な時間: コンテンツを読んで使用するのに十分な時間をユーザーに提供する（英語）に関する WCAG の説明も参照してください。

ガイドライン 2.3 — 発作と身体的反応: 発作や身体的反応を引き起こすことが知られている方法でコンテンツをデザインしないでください
-------------------------------------------------------------------

これは、変更しないとてんかんなどの症状のあるユーザーに発作を起こす可能性がある、または前庭障碍などの症状のあるユーザーに身体的反応（めまいなど）を引き起こす可能性があるコンテンツを意味します。

| 達成基準 | 基準への準拠方法 | 実用的なリソース |
| --- | --- | --- |
| 2.3.1 3 回の閃光、またはしきい値を下回る (A) | コンテンツに 1 秒間に 3 回以上の閃光を放つアスペクトが含まれていない、または閃光を放つコンテンツが許容できる閃光および赤色閃光のしきい値（英語）を下回っている。 |  |
| 2.3.2 3 回の閃光 (AAA) | コンテンツには、1 秒間に 3 回以上の閃光を放つアスペクトは含まれていません。 |  |
| 2.3.3 インタラクションによるアニメーション (AAA) 2.1 で追加（英語） | ユーザーがインタラクションによるアニメーションを無効にできるようにする（アニメーションが必須でない限り）。 | インタラクションによるアニメーションを理解する（英語） |

**メモ:** ガイドライン 2.3: 発作と身体的反応: 発作や身体的反応を引き起こすことが知られている方法でコンテンツをデザインしないでください（英語）に関する WCAG の説明も参照してください。

ガイドライン 2.4 — ナビゲート可能: ユーザーがナビゲートし、コンテンツを見つけ、どこにいるのかを判断するのに役立つ方法を提供する
--------------------------------------------------------------------

このガイドラインの下での適合基準は、ユーザーが自分自身を指向し、サイトの現在のページや他のページで探しているコンテンツと機能を見つけることが期待できる方法に関連しています。

| 達成基準 | 基準への準拠方法 | 実用的なリソース |
| --- | --- | --- |
| 2.4.1 ブロックのバイパス (A) | 繰り返される機能（会社のロゴやナビゲーションなど）を通り過ぎて、ユーザーがページにあるメインコンテンツや機能に直接スキップできるようにするメカニズムを提供するべきです。 これはしばしば、スキップリンク（"skip links"）を使用して達成されます — メインコンテンツにリンクする CSS によって隠されたリンクはページのソースのトップに置かれます。見出しと意味論のコンテナの適切な構造（例えば、`<section>`、`<aside>` など）がナビゲートするために提供されている場合は、追加のスキップリンクは必要ありません。 | スキップリンクのセクションを追加する必要があります。 |
| 2.4.2 ページタイトルを含める (A) | 各ウェブページには有益な `<title>` を含めるべきです。 そのコンテンツは、ページのコンテンツや目的を説明しています。 | タイトルの追加を参照してください。 |
| 2.4.3 論理的なフォーカスの順序 (A) | フォーカス可能なページ機能（例えば、リンク、ボタン、フォーム入力）の「タブ順序」は論理的に意味があり、そのページはまだ非晴眼者でもキーボードのユーザーでも使用可能であることを意味します。 | コントロールへのタブ移動に関する一般的なアドバイスについては、UI コントロールを参照してください。 要素を独特なレイアウトに配置する必要がある場合は、ソースの順序が適切であることを確認してから、配置などの CSS 機能を使用してレイアウトを扱うことをお勧めします。 |
| 2.4.4 リンクの目的（コンテキストにそった）（A） | リンクの目的や行き先は、リンクテキストから、またはその周囲（例えば、周囲のテキスト）から決定することができます。 例外は、リンクの目的が全てのユーザーにとってあいまいな場合です（これに関する有用な説明については、一般的にユーザーにとってあいまい（英語）を参照してください）。 | 意味の通るテキストラベルを参照してください。 また、同じテキストの複数のコピーが異なる場所にリンクされている場合は最小限に抑えるべきです。 これはスクリーンリーダーのユーザーにとって問題となる可能性があり、リンクの一覧がコンテキストから外れて表示されることがよくあります — 全てが「ここをクリック」、「ここをクリック」、「ここをクリック」とラベル付けされたいくつかのリンクは混乱を招くでしょう。 |
| 2.4.5 複数のナビゲーションメカニズム (AA) | ウェブサイト上のページを見つけるために少なくとも二つの一般的なナビゲーションメカニズム、例えば、ナビゲーションメニュー、パンくずリスト、サイト検索、サイトマップ、関連リンクのリストなどを提供するべきです。これに対する唯一の例外は、ページがプロセスの 1 ステップである場合で、論理的には前後のステップへのリンクのみを持つべきです。 | これらのメカニズムのほとんどは、単純な HTML 機能を使用して作成できます。 例えば、検索フィールド、ナビゲーションメニューの作成、ボタンとしてのリンクのスタイリングを参照してください。 |
| 2.4.6 見出しとラベル (AA) | 見出し（例えば、`<h2>`）および `<label>` 要素は、それらが説明していると思われるコンテンツおよびフォーム要素の目的を明確に説明しています。 | UI コントロール、意味の通るテキストラベル、見出しと段落の基本、<label> 要素を参照してください。構造上、それらを簡単に区別できない場合を除き、見出しやラベルの重複は避けるべきです（例えば、「詳細情報」が複数ある場合）。 |
| 2.4.7 フォーカス可能な要素に対する可視フォーカス (AA) | リンクやフォーム入力などのフォーカス可能な要素間をタブ移動するときは、どの要素に現在フォーカスがあるかを示す視覚的なインジケーターがあるはずです。 これは通常、デフォルトでは点線や青のアウトラインです（ブラウザ、プラットフォームなどによって異なります）が、CSS によって上書きすることができます。 | ネイティブなキーボード・アクセシビリティの使用を参照してください。 |
| 2.4.8 サイト内の場所 (AAA) | 複雑なサイトまたは一連のステップ内のページにいる場合は、パンくずリスト、サイトマップ、「Form page 2 of 10」といったテキストなど、サイト内の場所を示すインジケーターをユーザーに提示するべきです。 |  |
| 2.4.9 リンクの目的（リンクのみ） (AAA) | この基準は 2.4.4 に基づいており、AAA に準拠するためには、コンテキストから外れていてもリンクの目的やリンク先はリンクテキストのみから決定可能であるべきであると述べています。 | 意味の通るテキストラベルを参照してください。 また、同じテキストの複数のコピーが異なる場所にリンクされている場合は最小限に抑えるべきです。 これはスクリーンリーダーのユーザーにとって問題となる可能性があり、リンクの一覧がコンテキストから外れて表示されることがよくあります — 全てが「ここをクリック」、「ここをクリック」、「ここをクリック」とラベル付けされたいくつかのリンクは混乱を招くでしょう。 |
| 2.4.10 セクション見出し (AAA) | 便利な文書構造を作成するだけでなく、見出しも正確に記述し、コンテンツ領域を論理的なセクションに分割するべきです。この基準は、一般的なウェブコンテンツの見出しとタイトルを指すことに注意してください（例えば、テキストコンテンツ内の見出し）。 ユーザーインターフェースの見出しとタイトルは、基準 4.1.2 で扱われる特別なケースです。 | 見出しと段落の基本を参照してください。 |

**メモ:** ガイドライン 2.4: ナビゲート可能：ユーザーがナビゲートし、コンテンツを見つけ、どこにいるのかを判断するのに役立つ方法を提供する（英語）に関する WCAG の説明も参照してください。

ガイドライン 2.5 — 入力様式: キーボードを超えた様々な入力を通して機能をユーザーが操作しやすくする
-----------------------------------------------------

このガイドラインの適合基準は、ユーザーがキーボードやマウス以外のさまざまな入力方法（タッチスクリーン、音声、デバイスの動き、その他の入力デバイスを含む）を使用してデジタルテクノロジーと対話できることを保証します。

| 達成基準 | 基準への準拠方法 | 実用的なリソース |
| --- | --- | --- |
| 2.5.1 ポインタジェスチャー (A) 2.1 で追加（英語） | ポインタで操作できる全ての機能は、シングルポイントのアクションで操作できます。 パスベースやマルチポイントのジェスチャーは、機能を操作するために必要ではありません。 例外があります。 | ポインタジェスチャーを理解する（英語） |
| 2.5.2 ポインタキャンセル (A) 2.1 で追加（英語） | シングルポインタを使用して操作できる機能については、次のうち少なくとも 1 つが当てはまります。 ダウンイベントなし、中止や元に戻す、アップリバーサル、必要不可欠。 | ポインタキャンセルを理解する（英語） |
| 2.5.3 名前のラベル (A) 2.1 で追加（英語） | 表示可能なテキストラベルを含む各ユーザーインターフェイス・コンポーネントについて、アクセス可能な名前がラベルの表示可能なテキストと一致する（または含まれる）ことを確認します。 | 名前のラベルを理解する（英語） |
| 2.5.4 動きによる作動 (A) 2.1 で追加（英語） | a）デバイスの動き（揺れ、傾きのような）、または b）デバイスのセンサー（カメラを含む）によって検出されたユーザーのジェスチャーによって引き起こされる可能性のある機能について、次の両方が当てはまることを確認します。 1) 動きによる作動を無効にすることができ、2) 機能をデバイスの動きやユーザーのジェスチャーを使用せずに動作させることができる。 例外があります。 | 動きによる作動を理解する（英語） |
| 2.5.5 ターゲットサイズ (AAA) 2.1 で追加（英語） | アクション可能アイテムのタッチターゲットのサイズは、幅と高さの両方で少なくとも 44 CSS ピクセルにする必要があります。 例外があります。 | ターゲットサイズを理解する（英語） |
| 2.5.6 同時入力メカニズム (AAA) 2.1 で追加（英語） | タッチスクリーン、キーボード、マウス、音声コマンド、その他の入力デバイスを含むデジタルコンテンツと対話するときに、さまざまな入力モードを使用したり切り替えたりできることを確認します。 本質的な例外があります。 | 同時入力メカニズムを理解する（英語） |

**メモ:** ガイドライン 2.5: 入力様式: キーボードを超えた様々な入力を通して機能をユーザーが操作しやすくする（英語）に関する WCAG の説明も参照してください。

関連情報
----

* WCAG
    1. 知覚可能
    2. 操作可能
    3. 理解可能
    4. 堅牢


堅牢 - アクセシビリティ

堅牢
==

この記事では、ウェブコンテンツ・アクセシビリティガイドライン（WCAG）2.0 および 2.1 の**堅牢**原則に概説されている達成基準に準拠するようにウェブコンテンツを作成する方法についての実用的なアドバイスを提供します。 堅牢とは、支援技術を含む多種多様なユーザーエージェントによって確実に解釈されることができるほど十分に堅牢でなければならないと述べています。 これは通常、ウェブ標準に準拠し、厳密にテストすることによって実現できます。

**メモ:** W3C の堅牢の定義とそのガイドラインおよび達成基準を読むには、原則 4: 堅牢 — コンテンツは、支援技術を含むさまざまなユーザーエージェントによって確実に解釈されるよう十分に堅牢である必要があります（英語）を参照してください。

ガイドライン 4.1 — 互換性: 支援技術を含む現在および将来のユーザーエージェントとの互換性を最大化する
------------------------------------------------------

このガイドラインは、現在のユーザーエージェント（例えば、ブラウザ）だけでなく将来のものともコンテンツをできる限り互換性を持たせることに焦点を当てています。

| 達成基準 | 基準への準拠方法 | 実用的なリソース |
| --- | --- | --- |
| 4.1.1 解析 (A) | コンテンツは、ブラウザやスクリーンリーダーのような他のユーザーエージェントによって正常に解析されるように、整形式（well-formed）にするべきです。この基準に合格するには、HTML ができるだけ妥当（valid）であることを確認してください。 マークアップを検証するために W3C の検証ツール（英語）を使用してください。 | 実用的なガイドについては、HTML のデバッグを参照してください。 |
| 4.1.2 名前、役割、値 (A) | ユーザインターフェース・コンポーネント（例えば、フォーム入力、ボタン、リンクなど）の名前と役割（role、ロール）はプログラム的に決定可能であるべきです。意図された目的のために意味論の要素を正しく使用するとき、この基準に自動的に合格するはずです。 カスタムコンポーネントをスクリプト化するときは、例えば、晴眼でマウスのユーザーだけでなく、スクリーンリーダーのユーザー、キーボードのみのユーザーなども、コントロールが解釈されて意図したとおりに使用できるようにするために、WAI-ARIA のロールおよびその他の機能を使用する必要があります。 | HTML: アクセシビリティの基礎と WAI-ARIA の基本を参照してください。 |
| 4.1.3 ステータスメッセージ (AA) 2.1 で追加（英語） | 支援技術のユーザーは、ページに追加された新しいステータスメッセージを認識します。 | ステータスメッセージを理解する（英語） |

**メモ:** ガイドライン 4.1: 互換性: 支援技術を含む現在および将来のユーザーエージェントとの互換性を最大化する（英語）に関する WCAG の説明も参照してください。

関連情報
----

* WCAG
    1. 知覚可能
    2. 操作可能
    3. 理解可能
    4. 堅牢


知覚可能 - アクセシビリティ

知覚可能
====

この記事では、ウェブコンテンツアクセシビリティガイドライン (WCAG) 2.0 および 2.1 の**知覚可能**原則に概説されている達成基準に準拠するようにウェブコンテンツを作成する方法についての実用的なアドバイスを提供します。 知覚可能とは、ユーザーが自分の感覚の 1 つ以上を使用して何らかの方法でそれを知覚できなければならないということです。

**メモ:** 知覚可能の W3C 定義とそのガイドラインおよび達成基準を読むには、原則 1: 知覚可能 — 情報とユーザーインターフェイス・コンポーネントが、ユーザーが認識できる方法で提示可能である必要があります（英語）を参照してください。

ガイドライン 1.1 — 非テキストコンテンツのための代替テキストの提供
------------------------------------

ここで重要なのは、テキストならば障碍のある人が使用できる他の形式に変換できることです。 例えば、スクリーンリーダーで話させたり、ズームインしたり、点字ディスプレイに表示したりできます。 非テキストコンテンツとは、画像、音声、動画などのマルチメディアを指します。

| 達成基準 | 基準への準拠方法 | 実用的なリソース |
| --- | --- | --- |
| 1.1.1 同等のテキストを提供する (A) | 意味のある内容を伝える全ての画像は、適切な代替テキストを与えられるべきです。 | 代替テキスト。 |
|
 複雑な画像や図表には、同じページ上またはリンク先のいずれかにアクセス可能な代替手段を用意するべきです。
 `longdesc`
 属性ではなく通常のリンクを使用してください。
  | テキストの説明や、アクセス可能なデータ表がうまくいくかもしれません（HTML 表の高度な機能とアクセシビリティを参照）。 `longdesc` 反対論については、その他の代替テキストの仕組みも参照してください。 |
| マルチメディアコンテンツ（例えば、音声や動画）は、少なくともわかりやすい識別が利用できるべきです（例えば、キャプションまたは同様のもの）。 |
 静的キャプションの選択肢については代替テキストを、その他の選択肢についてはオーディオトランスクリプト、
 ビデオテキストトラック、その他のマルチメディアコンテンツを参照してください。
  |
|
 フォーム要素やボタンのような UI
 コントロールには、その目的を説明するテキストラベルを付けるべきです。
  |
 ボタンは簡単です —
 ボタンのテキストがボタンの機能を説明していることを確認してください（例えば、`<button>画像のアップロード</button>`）。
 他の UI コントロールの詳細については、UI コントロールを参照してください。
  |
| 支援技術には見えない方法で、装飾的な（コンテンツではない）画像、動画などを実装すると、ユーザーを混乱させません。 |
 装飾画像は CSS 背景画像を使用して実装する必要があります（背景を参照）。 `<img>`
 要素を介して画像を含める必要がある場合は、空白の
 alt（`alt=""`）を付けます。
 そうしないと、スクリーンリーダーがファイルパスなどを読み上げようとする可能性があります。

 自動再生する背景の動画や音声を含める場合は、できるだけ目立たないようにします。
 コンテンツのように見せたり鳴らさないでください。
 また、無効にするコントロールを提供してください。
 理想的には、それをまったく含めないでください。
  |

**メモ:** ガイドライン 1.1: 代替テキスト（英語）に関する WCAG の説明も参照してください。

ガイドライン 1.2 — 時間ベースのメディアのための代替テキストの提供
------------------------------------

時間ベースのメディアは、持続期間を有するマルチメディア、すなわち音声および動画を指します。 また、それらの音声や動画が既存のテキストコンテンツの代替を兼ねる場合は、別の代替テキストを提供する必要はありません。

| 達成基準 | 基準への準拠方法 | 実用的なリソース |
| --- | --- | --- |
| 1.2.1 記録済みの音声のみおよび動画のみのコンテンツに代わるものを提供する (A) | トランスクリプトは、録音済みの音声のみのメディアに提供するべきで、トランスクリプトまたは音声解説は、録画済みの動画のみのメディア（すなわち、サイレントビデオ）に提供するべきです。 | トランスクリプト情報については、オーディオトランスクリプトを参照してください。 音声解説のチュートリアルはまだありません。 |
| 1.2.2 ウェブベースの動画にキャプションを付ける (A) | ウェブ上に表示される動画（例えば、HTML 動画）には、キャプションを付けるべきです。 これは、動画の音声部分が聞こえない人々のためのものです。 | HTML 動画のキャプションについてはビデオテキストトラックsを、その他のテクノロジーについてはその他のマルチメディアコンテンツを参照してください。 Add your own subtitles & closed captions（YouTube、英語）も参照してください。 |
| 1.2.3 ウェブベースの動画にテキストトランスクリプトまたは音声解説を提供する (A) | ウェブ上に提示される動画（例えば、HTML 動画）のためのテキストトランスクリプトまたは音声解説を提供するべきです。 これは、動画の視覚的な部分を見ることができず、音声だけではコンテンツ全体を把握できない人々のためのものです。 | トランスクリプト情報については、オーディオトランスクリプト を参照してください。 音声解説のチュートリアルはまだありません。 |
| 1.2.4 生音声にキャプションを付ける (AA) | 音声を含んだすべての生のマルチメディア（ビデオ会議、生音声放送など）には、同期したキャプションを付けるべきです。 |  |
| 1.2.5 録画済み動画の音声解説を提供する (AA) | 音声解説は、録画済み動画に対して提供するべきですが、既存の音声が動画によって表現された完全な意味を伝えない場合に限ります。 |  |
| 1.2.6 録音済み音声と同等の手話を提供する (AAA) | 音声を含んだ記録済みコンテンツには、同等の手話動画を提供するべきです。 |  |
| 1.2.7 音声解説付きの拡張動画を提供する (AAA) | 動画のタイミングの問題で音声解説を提供できない場合（例えば、音声解説を挿入するコンテンツに適切な間がない場合）（1.2.5 を参照）、挿入された間（と音声解説）を含んだ動画の代替バージョンを提供するべきです。 |  |
| 1.2.8 記録済みメディアの代替を提供する (AAA) | 動画を特徴とする全てのコンテンツには、わかりやすいテキストトランスクリプトを提供する必要があります。 例えば、見ている映画のスクリプトなどです。 これは、コンテンツを聴くことができない聴覚障碍者のためのものです。 | トランスクリプト情報については、オーディオトランスクリプト を参照してください。 |
| 1.2.9 生音声用のトランスクリプトを提供する (AAA) | 放送されている生音声のコンテンツのために、例えば、あなたが聞いている演劇やミュージカルのスクリプトのような説明文を提供するべきです。 これは、コンテンツを聴くことができない聴覚障碍者のためのものです。 | トランスクリプト情報については、オーディオトランスクリプト を参照してください。 |

**メモ:** ガイドライン 1.2: タイムベースト・メディア: タイムベースト・メディアに代わるものを提供する（英語）に関する WCAG の説明も参照してください。

ガイドライン 1.3 — さまざまな方法で提示できるコンテンツの作成
----------------------------------

このガイドラインは、異なるニーズに柔軟に対応して、コンテンツがユーザーによってさまざまな方法で消費される能力について言及しています。

| 達成基準 | 基準への準拠方法 | 実用的なリソース |
| --- | --- | --- |
| 1.3.1 情報と関係 (A) |
 いかなるコンテンツ構造 — またはコンテンツ間に作られた視覚的関係 —
 もまた、プログラム的に決定されるか、またはテキストの説明から推論され得ます。
 これが関連する主な状況は次のとおりです。
 * テキストラベルとそれが説明するフォーム要素は、`<label>`
 要素を使用して明確に関連付けられて、スクリーンリーダーなどが拾うことができます。
* 画像の代替テキスト —
 コンテンツ画像には、その画像の内容を明確に説明するテキストが含まれているべきです。
 これは、プログラム的に関連付けることができます（例えば、`alt`
 テキスト）。
 そうでない場合は、関連付けるのは簡単です（例えば、それを説明し、そのすぐ隣に置きます）。
 これは、たとえあなたが画像を見ることができなくても、完全な意味がまだ推測できることを意味するはずです。
* リスト —
 リスト項目の順序が重要で、順序付きリストを使用するべき場合（`<ol>`）。
 | HTML: アクセシビリティの基礎全体には、これに関する情報が満載されていますが、特に良いセマンティクス、UI コントロール、代替テキストを参照するべきです。 |
| 1.3.2 重要なコンテンツの順序 (A) |
 賢明で論理的な読み上げ順序は、たとえそれが独特な方法で視覚的に提示されていても、どんな内容に対しても決定しやすいはずです。
 マークアップに関係なく、CSS
 を使用して独特なレイアウトスタイルを作成することで、正しい意味論的要素（見出し、段落など）を使用して順序を明確にするべきです。
  | 繰り返しますが、HTML: アクセシビリティの基礎を参照してください。 |
| 1.3.3 感覚的性質 (A) |
 コントロールを操作したり、コンテンツを理解したりするための指示は、単一の感覚には依存しません
 —
 これは、その感覚に関連する障碍を持つ人々、またはその感覚をサポートしていないデバイスにとってアクセスできないことを証明するかもしれません。
 だから、例えば、
 * 「続けるために丸いボタンをクリックしてください」それがあなたが押す必要があるボタンであることは明らかであるように、ボタンは明確にラベル付けされるべきです。
 複数のボタンがある場合は、それらの機能を区別するために全てが明確にラベル付けされていることを確認してください。
* 「ガイダンスに関する音声の説明を聞く」これは明らかに問題があります —
 音声は聴覚障碍のある人にはアクセスできないのに対して、テキストは読むことができるだけでなく、必要に応じてスクリーンリーダーによって話させることもできます。
* 「メニューを表示するには、画面の右側からスワイプ」一部のユーザーは、障碍のためや、端末がタッチに対応していないために、画面をスワイプできない可能性があります。
 キーボードショートカットや、キーボードなどの手段でアクティブにできるボタンなどの代替手段を提供する必要があります。

**注:**
 色だけで指示を伝えることは関連していますが、異なるガイドラインでカバーされています
 — 1.4.1。

 |  |
|
 1.3.4 オリエンテーション (AA)
 2.1 で追加（英語）
  | 特定のディスプレイの向きが重要でない限り、コンテンツの表示と操作はポートレートやランドスケープなどの単一のディスプレイの向きに制限されません。 | オリエンテーションを理解する（英語） |
|
 1.3.5 入力の目的の識別 (AA)
 2.1 で追加（英語）
  |
53個の入力フィールド（英語）のリストに従って、プログラム的にフィールドの目的を識別してください。 | 入力の目的の識別を理解する（英語） |
|
 1.3.6 目的の識別 (AAA)
 2.1 で追加（英語）
  | マークアップ言語を使用して実装されたコンテンツでは、ユーザーインターフェイス・コンポーネント、アイコン、およびリージョンの目的はプログラム的に決定できます。 | 目的の識別を理解する（英語） |

**メモ:** ガイドライン 1.3: 適応可能: 情報や構造を失うことなくさまざまな方法で提示できるコンテンツを作成する（英語）に関する WCAG の説明も参照してください。

ガイドライン 1.4: 前景と背景の区別を含め、ユーザーがコンテンツを見たり聞いたりしやすくする
------------------------------------------------

このガイドラインは、コアコンテンツが背景や他の装飾から識別しやすいことを確認することに関するものです。 典型的な例は、色で（色のコントラストと指示を伝えるための色の使い方の両方が）、他の状況でも適用されます。

| 達成基準 | 基準への準拠方法 | 実用的なリソース |
| --- | --- | --- |
| 1.4.1 色の使い方 (A) |
 色だけを頼りにして情報を伝えるべきではありません。例えば、フォームでは、必須フィールドを色（赤など）だけで示す付けることは絶対にしないでください。
 代わりに（または同様に）、「必須」というラベルの付いたアスタリスクのようなものがより適切です。
  | 色とそのコントラストおよび複数のラベルを参照してください。 |
| 1.4.2 音声コントロール (A) | 3 秒以上再生される音声の場合は、音声や動画の再生と一時停止、および音量のミュートや調整を行うためのアクセス可能なコントロールを用意する必要があります。 | ビデオプレーヤーのスタイリングの基本 (en-US)に示すように、ネイティブの
 `<button>`
 を使用してアクセス可能なキーボードコントロールを提供します。
  |
| 1.4.3 最低限のコントラスト (AA) | 背景と前景のコンテンツの間の色のコントラストは、読みやすさを確実なものとするための最低限のレベルであるべきです。* テキストとその背景のコントラスト比は少なくとも 4.5:1 であるべきです。
* 見出し（またはそれよりも大きい）テキストの比は、少なくとも 3:1 であるべきです。 大きいテキストは、少なくとも 18 ポイント、または 14 ポイントの太字として定義されます。
 | 色とそのコントラストを参照してください。 |
| 1.4.4 テキストのサイズ変更 (AA) |
 テキストサイズが倍になったときに、ページが読みやすく使えるべきです。
 つまり、デザインはレスポンシブであるべきで、テキストサイズを大きくしてもコンテンツにアクセス可能であることを意味します。
  |  |
| 1.4.5 テキストの画像 (AA) |
 テキストが仕事をするようなコンテンツを提示するために画像を使用しては**いけません**。
 例えば、画像がほとんどテキスト形式の場合、画像だけでなくテキストも使用して表現できます。
  |  |
| 1.4.6 強化されたコントラスト (AAA) | これは、基準 1.4.3 に従い、その上に構築されます。* テキストとその背景のコントラスト比は少なくとも 7:1 であるべきです。
* 見出し（またはそれよりも大きい）テキストの比は少なくとも 4.5:1 であるべきです。 大きいテキストは、少なくとも 18 ポイント、または 14 ポイントの太字として定義されます。
 |
 See
 色とそのコントラスト.
  |
| 1.4.7 背景音が小さいか無い (AAA) | 話し言葉を主な特徴とする録音済みの音声記録は、背景の雑音を最小限に抑えるようにしてください。そうするとコンテンツが理解しやすくなります。 |  |
| 1.4.8 視覚的表現 (AAA) | テキストコンテンツの表現では、次のことが当てはまります。* 前景色と背景色は、ユーザーが選択できるようにするべきです。
* テキストブロックは、読みやすくするために、80 文字（またはグリフ）以下の幅にしてください。
* テキストは、両端揃えにするべきではありません（例えば、`text-align: justify;`）。
* 行の高さは、段落内ではテキストサイズの 1.5 倍以上（例えば、 `line-height: 1.5;`）、段落間ではテキストサイズの 2.25 倍以上（例えば、 `padding: 2.25rem;`）にするするべきです。
* テキストサイズが2倍になったときに、コンテンツのスクロールが必要になるべきではありません。
 |  |
| 1.4.9 テキストの画像（例外なし） (AAA) | テキストは、純粋に装飾である（すなわち、それがいかなる内容も伝えない）か、または他の方法で提示することができない限り、画像の一部として提示するべきではありません。 |  |
|
 1.4.10 リフロー (AA)
 2.1 で追加（英語）
  | * 左書きの言語（英語など）や右書きの言語（アラビア語など）では、水平スクロールをしないでください。
* 縦書きの言語（日本語など）では、垂直スクロールをしないでください。
* 使用法や意味のために 2 次元レイアウトを必要とするコンテンツの部分を除きます（大きなデータ表など）。
 | リフローを理解する（英語） |
|
 1.4.11 テキスト以外のコントラスト (AA)
 2.1 で追加（英語）
  | ユーザーインターフェイスコンポーネントとグラフィックオブジェクトの最低限のカラーコントラスト比は 3:1 です。 | テキスト以外のコントラストを理解する（英語） |
|
 1.4.12 テキストの間隔 (AA)
 2.1 で追加（英語）
  | 次のスタイルを適用しても、コンテンツや機能が失われることはありません。* 行の高さ（行間）をフォントサイズの 1.5 倍以上にします。
* 後続の段落との間隔をフォントサイズの 2 倍以上にします。
* 文字間隔（トラッキング）をフォントサイズの 0.12 倍以上にします。
* 単語間隔をフォントサイズの 0.16 倍以上にします。
 | テキストの間隔を理解する（英語） |
|
 1.4.13 ホバーまたはフォーカスにおけるコンテンツ (AA)
 2.1 で追加（英語）
  |
 追加のコンテンツがホバーやキーボードフォーカスに連動して現れたり消えたりします。
 この達成基準では、満たす必要がある次の 3 つの条件を指定します。
 * 却下可能（閉じたり取り除くことが可能）。
* ホバーリング可能（追加のコンテンツは、ポインターが上にあるときは消えません）。
* 永続的（追加のコンテンツは、ユーザーの操作なしでは消えません）。
 | ホバーまたはフォーカスにおけるコンテンツを理解する（英語） |

**メモ:** ガイドライン 1.4: 識別可能: 背景から前景を分離するなど、ユーザーがコンテンツを見やすく、聞き取りやすくする（英語）に関する WCAG の説明も参照してください。

関連情報
----

* WCAG
    1. 知覚可能
    2. 操作可能
    3. 理解可能
    4. 堅牢


理解可能 - アクセシビリティ

理解可能
====

この記事では、ウェブコンテンツ・アクセシビリティガイドライン（WCAG）2.0 および 2.1 の**理解可能**原則に概説されている達成基準に準拠するようにウェブコンテンツを作成する方法について実用的なアドバイスを提供します。 理解可能とは、情報とユーザーインターフェースの操作が理解可能でなければならないと述べています。

**メモ:** 理解可能の W3C の定義とそのガイドラインおよび達成基準を読むには、原則 3: 理解可能 — 情報とユーザーインターフェイスの操作が理解可能でなければならない（英語）を参照してください。

ガイドライン 3.1 — 読みやすさ: テキストコンテンツを読みやすく理解しやすいものにする
----------------------------------------------

このガイドラインは、テキストコンテンツをできるだけわかりやすくすることに焦点を当てています。

| 達成基準 | 基準への準拠方法 | 実用的なリソース |
| --- | --- | --- |
| 3.1.1 ページの言語 (A) | 各ウェブページのデフォルトの人間の言語はコードで検出できるべきです。 これは、読者が自分に合った言語で書かれたページにアクセスしたことを確認するなどの目的に不可欠です。 これを実現する最も簡単な方法は、ページの `<html>` 要素に `lang` 属性を設定して、ページが書かれている言語を最もよく表す言語コードをそれに与えることです。 | 文書の第一言語の設定を参照してください。 |
| 3.1.2 パーツの言語 (AA) | ページのコンテンツに第一言語とは異なる言語の単語や語句が含まれている場合は、問題の用語を囲む要素（例えば、意味論の要素が利用できない場合は `<span>`）に `lang` 属性を使用して適切な言語を設定します。言語に関係なく同じである単語や語句に異なる言語を設定する必要はありません（例えば、固有名詞、特定の言語の一部ではない専門用語など）。 |  |
| 3.1.3 珍しい単語 (AAA) | 専門用語、業界用語、または慣用句やスラングが使用されている場合は、そのような語句や単語に対して定義を提供するべきです。 サイトでは、そのような言葉や用語の定義を含む用語集を、それらが現れたときにリンクできるように提供するか、少なくとも周囲のテキストやページ下部の説明リストのどこかに定義を提供するべきです。 |  |
| 3.1.4 略語 (AAA) | 略語が使用されている場合は、それらの展開や、必要に応じて定義を提供するべきです。`<abbr>` 要素は、略語の展開を提供するための推奨される方法と考えられています — 展開を含む `title` 属性を取り、略語をマウスオーバーしたとき、これが表示されます。 ただし、`title` の内容はキーボードからはアクセスできず、スクリーンリーダーによって確実に読み上げられるわけでもありません。 これを扱うためのより良い方法は、この場合も先と同様に略語の展開と説明を含む用語集のページへのリンクを提供するか、少なくともコンテキスト内の周囲のテキストにそれらを含めることです。 | 略語を参照してください。 |
| 3.1.5 読解力 (AAA) | 前期中等教育レベル（通常 11〜14 歳前後の子供）より高い読解力を必要とするテキストが提供される場合は、それを読むことができない人々を支援する補足説明資料を提供するか、あるいは前期中等教育レベルで書かれた代替バージョンを提供します。これは、全ての主題が全ての人に理解されるべきであるという意味ではありませんが、書くスタイルは全ての人にアクセス可能であるべきです。 そうしない正当な理由や（例えば、詩的効果のための代替的なスタイル）、厳密なスタイルで記述する必要（例えば、W3C の仕様）がない限り、プログラミングチュートリアルのような技術文書でさえも、全てのコンテンツを前期中等教育レベルで書くことをお勧めします。 |  |
| 3.1.6 発音 (AAA) | コンテンツを完全に理解するために必要な単語の発音へのアクセスをユーザーに与えるためのメカニズムを提供するべきです。HTML5 の `<audio>` 要素を使用して、正しい発音を含む音声ファイルを読者が再生できるようにするコントロールを作成できます。 そして、辞書のエントリーと同じように難しい言葉の後にテキストの発音ガイドを含めるのも理にかなっています。 | 動画と音声のコンテンツ、および英語辞書の発音ガイド（英語）を参照してください。 |

**メモ:** ガイドライン 3.1: 読みやすさ: テキストコンテンツを読みやすく理解しやすいものにする（英語）に関する WCAG の説明も参照してください。

ガイドライン 3.2 — 予測可能: ウェブページを予測可能な方法で表示して操作させる
-------------------------------------------

このガイドラインは、ユーザーインターフェースを直感的でわかりやすくすることに焦点を当てています。

| 達成基準 | 基準への準拠方法 | 実用的なリソース |
| --- | --- | --- |
| 3.2.1 フォーカス時 (A) | コントロールや他のページ機能がフォーカスを受けたときに、ユーザーが混乱したり迷ったりするような方法でコンテキストを変更するべきではありません。これは賢明なデザインの問題です — 人々はインターフェースによって驚かされることを望みません。 彼らは物事が直感的で期待通りに振る舞うことを望みます。 例えば、ナビゲーションメニューのオプションにフォーカスを置いても、表示されたページは変わりません — 表示が変わる前にアクティブにする必要があります。 | `GlobalEventHandlers.onfocus` には、役に立つ情報がいくつか含まれています。 役に立つ実装のアイデアについては、キーボードアクセシビリティを呼び戻すように盛り込むを参照してください。 |
| 3.2.2 入力時 (A) | データがコントロールに入力されたとき、または設定が変更されたときに、コンテキストが予期せずに変更されるべきではありません。 差し迫った変更が発生する前に、ユーザーに警告や通知をする必要があります。繰り返しますが、賢明なデザインを実装するべきです。 例えば、ボタンを押してアプリケーションが現在のビューを終了すると、ユーザーは必要に応じて作業内容を保存するかなど、この操作の確認を求められるべきです。 | `GlobalEventHandlers.oninput` はここで役に立ちます。 |
| 3.2.3 一貫したナビゲーション (AA) | ナビゲーションのメニューやコントロールのスタイルと配置は、ウェブページの異なるページやビューの間で一貫しているべきで、例えば、新しい項目が追加されたとしても、既存の項目は同じ順序で現れるべきです。 ユーザーが変更を始めた場合、例えば、ナビゲーションのために異なる配色や位置を選択すると、それらの選択は全てのページにわたって尊重されるべきです。繰り返しますが、賢明なデザイン — 全てのページやビューでナビゲーションコントロールを同じにします。 | モダンなレイアウトのマークアップについては、ページレイアウトを参照してください。 便利なアクセス可能なナビゲーションメニューの例については、ボタンとしてのリンクのスタイリングも参照してください。 |
| 3.2.4 一貫した識別 (AA) | 同じ機能を持つコントロールやコンポーネントは、異なるページやビューでも同じように識別されるべきです。 例えば、世界旅行サイトの全てのページに表示される通貨換算機は、意味論的にもラベルの観点からもまったく同じであるべきです。繰り返しますが、賢明なデザイン！ | 「ラベル」とは、テキストコンテンツ内の説明的な情報、または HTML フォームのラベルのことです。 詳細については、意味の通るテキストラベルを参照してください。 |
| 3.2.5 要求に応じた変更 (AAA) | ユーザーを混乱させたり、迷わせたりする可能性があるコンテキストの変更は、ユーザーから要求された場合にのみ行われるべきか、**あるいは**、ユーザーはそれらをオフにできるべきです。現在のビュー（例えば、コンテンツやコントロール）を大幅に変更するものが必要な場合は、変更をいつ実行するかをユーザーに制御させます（例えば、どのページを表示するか、いつギャラリーの次の写真に進むか...）。ページに回転木馬のようなものが必要な場合は、自動的に進まないようにするオプションを提供します。 可能であれば、そのような機能を避ける方が良いでしょう。 |  |

**メモ:** ガイドライン 3.2: 予測可能: ウェブページを予測可能な方法で表示して操作させる（英語）に関する WCAG の説明も参照してください。

ガイドライン 3.3 — 入力支援: ユーザーが間違いを避けて修正できるようにする
-----------------------------------------

このガイドラインは、必要なときにユーザーが正しい情報を間違いを最小限にとどめて入力できるように手助けすることを中心にしています。

| 達成基準 | 基準への準拠方法 | 実用的なリソース |
| --- | --- | --- |
| 3.3.1 エラーの識別 (A) | ユーザーがフォームに入力したりオプションを選択したりするときに検出したエラーは、エラーに関連するフォームコントロールと共に、ユーザーに明確に報告するべきです。

 状況に最適なものであれば、HTML5 フォームの検証機能や JavaScript
 を使用して、クライアント側のエラー検出と処理を実装することをお勧めします。
 エラーを検出したら、ユーザーが入力を修正するのを助けるために、直観的なエラーメッセージをフォーム入力の横に表示するべきです。
 スクリーンリーダーのユーザーの場合は、ARIA
 のライブリージョンを使用して、ページ上の変更についてユーザーに警告することができます。

 サーバー側の検証は、クライアント側の検証と同時に**常に**使用するべきです。
 クライアント側の検証は、無効にしたり回避したりするのが簡単すぎるため、単独では信頼できません。

 |
 包括的な検証情報についてはフォームデータの検証を、ライブリージョンに関する情報については
 WAI-ARIA: 動的コンテンツの更新を参照してください。
  |
| 3.3.2 ラベルや指示 (A) |
 データ入力が必要な場合は、明確な指示を提供するべきです。
 単純な指示やプロンプトが必要な場合は、名前や年齢のような単一入力には
 `<label>`
 要素を使用したり、（生年月日や住所の要素のような）複数を一緒にした入力には
 `<label>` と
 `<fieldset>` /
 `<legend>` を組み合わせて使用できます。

より複雑な説明が必要な場合は、常に説明段落を含めることも、フォームをより直感的にすることを試みる必要があるかもしれません。 | 意味の通るテキストラベルと便利な例については
 HTML フォームの作成方法を参照してください。
  |
| 3.3.3 エラーに対する提案 (AA) | エラーが検出され、修正の提案が判明したら、セキュリティ上の問題（例えば、パスワード入力時）やコンテキスト上の問題（例えば、クイズアプリでの回答時）が発生しない限り、ユーザーにこれらの情報を提供してください（例えば、ユーザーが既に選らんだことがあるユーザー名についての選択肢の提案）。

 このような場合、これが適切であれば、おそらく JavaScript
 とサーバー側の機能の組み合わせを使用して、エントリが正しいかどうかを確認し、正しくない場合は、ユーザーに実行可能な提案を提示できます。
 そのような提案は、エラーメッセージのようなコンテキストの中で有用に表示されるべきです（3.3.1
 を参照）。
  | まだチュートリアルの提案はありません。 |
| 3.3.4 エラー防止（法務、財務、データ） (AA) | 機密データの入力に関わるフォーム（法的契約、電子商取引、個人データなど）の場合は、少なくとも次のいずれかに該当するべきです。* 提出は可逆的です。
* データにエラーがないかチェックされ、ユーザーにはエラーを修正する機会が与えられます。
* 最終提出の前に情報を確認し修正するためのメカニズムが利用可能です。
 |
**可逆的** —
 データを入力できるビューには、必要に応じてエントリを編集または削除することもできる同等のビューを提供します（例えば、Django ウェブフレームワークを参照）。

**データのチェック** — 3.3.1
 で説明したように、クライアント側とサーバー側の検証を組み合わせてエラーを検出し、入力を修正できるようにユーザーに役立つメッセージを表示するべきです。

**確認と修正** —
 必要に応じて、（製品の購入のような）一連のフォームフィールドに入力するタスクを実行した後、ユーザーに確認画面を表示して入力内容を見直し、正しくないものは修正できるようにするべきです。
 このパターンは、Amazon
 のような電子商取引サイトで一般的に使用されています。
  |
| 3.3.5 状況依存ヘルプが利用可能 (AAA) | フォームの完成と提出を助けるために、コンテキストの中で指示と他の適切な合図を提供してください。 |
 これは実際には単に 3.3.1
 や他の同様の基準に基づいていますが、もっと徹底的なコンテキスト上のヘルプ情報とサービスを必要とします。
 例えば、各ページのヘルプページまたはサービスへの専用リンクを提供し、正常に完了したらどのように見えるか示す例を提供します。
  |
| 3.3.6 エラー防止（全て） (AAA) |
 この原則は 3.3.4
 に基づいており、機密データを含むものだけでなく、全てのユーザ入力状況に要件を拡張しています。
  | 繰り返しますが、3.3.4 を参照してください。 |

**メモ:** ガイドライン 3.3: 入力支援: ユーザーが間違いを避けて修正できるようにする（英語）に関する WCAG の説明も参照してください。

関連情報
----

* WCAG
    1. 知覚可能
    2. 操作可能
    3. 理解可能
    4. 堅牢


ARIA の状態とプロパティ - アクセシビリティ

ARIA の状態とプロパティ
==============

このページは、MDN で取り上げられているすべての WAI-ARIA 属性を網羅したリファレンスページを掲載しています。

ARIA 属性は、アクセシビリティツリーで定義された要素の状態やプロパティを変更することが可能です。

**メモ:** ARIA はアクセシビリティツリーを変更するだけで、支援技術がコンテンツをユーザーにどのように表示するかを変更します。ARIA は要素の機能や動作を何らかの形で変更するものではありません。意味づけられた HTML 要素を本来の目的や既定値で使用しない場合は、JavaScript を使って動作やフォーカス、ARIA の状態を管理する必要があります。

ARIA 属性の種類
----------

ARIA の状態とプロパティには、4 つのカテゴリーがあります。

1. ### ウィジェット属性

    * `aria-autocomplete`
    * `aria-checked` (en-US)
    * `aria-disabled`
    * `aria-errormessage`
    * `aria-expanded` (en-US)
    * `aria-haspopup` (en-US)
    * `aria-hidden` (en-US)
    * `aria-invalid` (en-US)
    * `aria-label` (en-US)
    * `aria-level` (en-US)
    * `aria-modal` (en-US)
    * `aria-multiline` (en-US)
    * `aria-multiselectable` (en-US)
    * `aria-orientation` (en-US)
    * `aria-placeholder` (en-US)
    * `aria-pressed` (en-US)
    * `aria-readonly` (en-US)
    * `aria-required` (en-US)
    * `aria-selected` (en-US)
    * `aria-sort` (en-US)
    * `aria-valuemax` (en-US)
    * `aria-valuemin` (en-US)
    * `aria-valuenow` (en-US)
    * `aria-valuetext` (en-US)
2. ### ライブリージョン属性

    * `aria-busy` (en-US)
    * `aria-live` (en-US)
    * `aria-relevant` (en-US)
    * `aria-atomic`
3. ### ドラッグ＆ドロップ属性

    * `aria-dropeffect` (en-US)
    * `aria-grabbed`
4. ### リレーションシップ属性

    * `aria-activedescendant`
    * `aria-colcount` (en-US)
    * `aria-colindex` (en-US)
    * `aria-colspan` (en-US)
    * `aria-controls` (en-US)
    * `aria-describedby`
    * `aria-description` (en-US)
    * `aria-details` (en-US)
    * `aria-errormessage`
    * `aria-flowto` (en-US)
    * `aria-labelledby`
    * `aria-owns` (en-US)
    * `aria-posinset` (en-US)
    * `aria-rowcount` (en-US)
    * `aria-rowindex` (en-US)
    * `aria-rowspan` (en-US)
    * `aria-setsize` (en-US)
グローバル ARIA 属性
-------------

いくつかの状態やプロパティは、ARIA ロールが適用されているかどうかに関係なく、すべての HTML 要素に適用されます。これらは『グローバル』属性として定義されます。グローバル状態やプロパティは、すべてのロールや基本マークアップ要素で対応しています。

上記の属性の多くはグローバルで、特に禁止されていない限り、どの要素にも含めることができます。

* `aria-atomic`
* `aria-busy` (en-US)
* `aria-controls` (en-US)
* `aria-current` (en-US)
* `aria-describedby`
* `aria-description` (en-US)
* `aria-details` (en-US)
* `aria-disabled`
* `aria-dropeffect` (en-US)
* `aria-errormessage`
* `aria-flowto` (en-US)
* `aria-grabbed`
* `aria-haspopup` (en-US)
* `aria-hidden` (en-US)
* `aria-invalid` (en-US)
* `aria-keyshortcuts` (en-US)
* `aria-label` (en-US)
* `aria-labelledby`
* `aria-live` (en-US)
* `aria-owns` (en-US)
* `aria-relevant` (en-US)
* `aria-roledescription` (en-US)

「特に禁止」とは、上記の属性がすべてグローバルであることを意味します。ただし、`aria-label` および `aria-labelledby` プロパティは、ロール `presentation` またはその同義語 `none` (en-US) ロールでは禁止されています。

MDN で定義する状態とプロパティ
-----------------

以下は、MDN で取り上げた WAI-ARIA の状態やプロパティに応じたリファレンスページです。

aria-activedescendant`aria-activedescendant` 属性は、`composite` (en-US) ウィジェット、`combobox` (en-US)、`textbox`、`group`、`application`にフォーカスが当たっている時、現在アクティブな要素を特定します。

aria-atomicARIA ライブリージョンにおいて、グローバルな `aria-atomic` 属性は、`aria-relevant` (en-US) 属性で定義された変更通知に基づいて、スクリーンリーダーなどの支援技術が変更された領域をすべて表示するのか、一部だけを表示するのかを示します。

aria-autocomplete`aria-autocomplete` 属性は、 `combobox` (en-US), `searchbox` (en-US), `textbox` において、テキスト入力がユーザーの意図する値の一つ以上の予測を発生させるかどうかを示し、発生した場合にどのように予測を表示するかを指定します。

aria-describedby`aria-describedby` はグローバル属性で、その属性が設定されている要素を説明する要素（複数可）を特定します。

aria-disabled`aria-disabled` 状態は、要素は知覚可能であるが無効であり、編集やその他の操作をすることができないことを示します。

aria-errormessageオブジェクトの `aria-errormessage` 属性は、そのオブジェクトのエラーメッセージを表示する要素を特定します。

aria-grabbed`aria-grabbed` の状態は、ドラッグ＆ドロップ処理で要素が「つかまれた」状態を示します。

aria-labelledby`aria-labelledby` 属性は、適用される要素のラベル付けを行う要素（複数可）を識別します。

関連情報
----

* ARIA の使用: ロール、ステート、プロパティ


ARIA の使用: ロール、ステート、プロパティ - アクセシビリティ

ARIA の使用: ロール、ステート、プロパティ
========================

ARIA は、要素に適用できる意味づけを定義しており、これらは **ロール** （ユーザーインターフェイス要素の種類を定義する）と、ロールが対応している **ステート** と **プロパティ** に分けられます。オーナーは、要素がすでに適切な ARIA の意味づけが（適切な HTML 要素を使用することによって）ある場合を除いて、そのライフサイクルの間に要素に ARIA の役割と適切な状態およびプロパティを割り当てる必要があります。ARIA の意味づけは、ブラウザーのアクセシビリティ API に余分な情報を公開するだけで、ページの DOM には影響を与えません。

ロール
---

### ウィジェットロール

* `button`
* `checkbox`
* `gridcell`
* `link`
* `menuitem` (en-US)
* `menuitemcheckbox` (en-US)
* `menuitemradio` (en-US)
* `option`
* `progressbar`
* `radio`
* `scrollbar` (en-US)
* `searchbox` (en-US)
* `separator` (en-US) （フォーカス可能な場合）
* `slider`
* `spinbutton` (en-US)
* `switch`
* `tab`
* `tabpanel` (en-US)
* `textbox`
* `treeitem` (en-US)
### 複合ロール

以下のテクニックでは、それぞれの複合ロールとその必須および任意の子ロールについて説明します。

* `combobox` (en-US)
* `grid` （`row`, `gridcell`, `rowheader` (en-US), `columnheader` (en-US) ロールを含む）
* `listbox` （`option` ロールを含む）
* `menu` (en-US)
* `menubar` (en-US)
* `radiogroup` (en-US) （`radio role` を参照）
* `tablist` (en-US) （`tab` および `tabpanel` (en-US) ロールを含む）
* `tree` (en-US)
* `treegrid` (en-US)
### 文書構造ロール

* `application`
* `article`
* `cell`
* `columnheader` (en-US)
* `definition` (en-US)
* `directory` (en-US)
* `document`
* `feed`
* `figure`
* `group`
* `heading`
* `img` (en-US)
* `list`
* `listitem`
* `math` (en-US)
* `none` (en-US)
* `note` (en-US)
* `presentation`
* `row`
* `rowgroup`
* `rowheader` (en-US)
* `separator` (en-US)
* `table`
* `term`
* `toolbar`
* `tooltip` (en-US)
### ランドマークロール

* `banner`
* `complementary`
* `contentinfo`
* `form`
* `main`
* `navigation`
* `region`
* `search`
### ライブリージョンロール

* `alert`
* `log`
* `marquee` (en-US)
* `status`
* `timer` (en-US)
### ウィンドウロール

* `alertdialog`
* `dialog`
ステートとプロパティ
----------

### ウィジェット属性

* `aria-autocomplete`
* `aria-checked` (en-US)
* `aria-current` (en-US)
* `aria-disabled`
* `aria-errormessage`
* `aria-expanded` (en-US)
* `aria-haspopup` (en-US)
* `aria-hidden` (en-US)
* `aria-invalid` (en-US)
* `aria-label` (en-US)
* `aria-level` (en-US)
* `aria-modal` (en-US)
* `aria-multiline` (en-US)
* `aria-multiselectable` (en-US)
* `aria-orientation` (en-US)
* `aria-placeholder` (en-US)
* `aria-pressed` (en-US)
* `aria-readonly` (en-US)
* `aria-required` (en-US)
* `aria-selected` (en-US)
* `aria-sort` (en-US)
* `aria-valuemax` (en-US)
* `aria-valuemin` (en-US)
* `aria-valuenow` (en-US)
* `aria-valuetext` (en-US)
### ライブリージョン属性

* `aria-live` (en-US)
* `aria-relevant` (en-US)
* `aria-atomic`
* `aria-busy` (en-US)
### ドラッグ＆ドロップ属性

* `aria-dropeffect` (en-US)
非推奨
* `aria-grabbed`
非推奨
### 関係属性

* `aria-activedescendant`
* `aria-colcount` (en-US)
* `aria-colindex` (en-US)
* `aria-colspan` (en-US)
* `aria-controls` (en-US)
* `aria-describedby`
* `aria-details` (en-US)
* `aria-errormessage`
* `aria-flowto` (en-US)
* `aria-labelledby`
* `aria-owns` (en-US)
* `aria-posinset` (en-US)
* `aria-rowcount` (en-US)
* `aria-rowindex` (en-US)
* `aria-rowspan` (en-US)
* `aria-setsize` (en-US)
### MicrosoftEdge 固有のプロパティ

* `x-ms-aria-flowfrom` (en-US)
Non-standard


WAI-ARIA ロール - アクセシビリティ

WAI-ARIA ロール
============

このページは、MDN で説明されているすべての WAI-ARIA ロールをカバーするリファレンスページを一覧にしています。ロールの完全なリストについては、ARIA を使用する: ロール、ステート、プロパティをご覧ください。

alertdialog ロールの使用このテクニックは、`alertdialog` ロールの使用方法を示しています。

ARIA: alert ロールアラート (`alert`) ロールは、要素が動的に更新されたことをユーザーに通知するために使用できます。 ロールが追加されると、スクリーンリーダーは更新されたコンテンツの読み上げを即座に開始します。 ユーザーがアラートを閉じることを期待する場合は、代わりにアラートダイアログ (`alertdialog`) ロールを使用するべきです。

ARIA: application ロールアプリケーション (`application`) ロールは、要素とその全ての子要素をデスクトップアプリケーションと同様に扱うべきであり、伝統的な HTML 解釈手法を使用するべきでないと支援技術に指示します。 このロールは、とても動的でデスクトップ的なウェブアプリケーションを定義するためにのみ使用するべきです。

ARIA: article ロール記事 (`article`) ロールは、ページ、文書、またはウェブサイト上で容易に自立することができるページのセクションを示します。 これは、通常、コメント、フォーラム投稿、新聞記事、または 1 ページにまとめられたその他項目などの関連コンテンツの項目に設定します。

ARIA: banner ロールバナー (`banner`) ロールは、ページの先頭に頻繁に配置される一般的で有益なコンテンツを表します。 これには、通常、ロゴ、会社名、検索アイコン、ページに関連する写真、またはスローガンが含まれます。

ARIA: button ロール`button` ロールは、ユーザーによってアクティブ化されたときに反応を引き起こすクリック可能な要素のためのものです。 `role="button"` を追加すると、この要素がボタンであるものの、ボタンの機能を提供していないことをスクリーンリーダーに伝えます。代わりに `button` または `input` に `type="button"` を付けたものを使用してください。

ARIA: cell ロール`cell` は ARIA の *role* 属性の値で、要素を列ヘッダーや行ヘッダーの情報を含まない表形式コンテナー内のセルとして識別します。サポートされるには、セルが行 (`row`) ロールを持つ要素内にネストされている必要があります。

ARIA: checkbox ロールチェックボックス (checkbox) ロールは、チェック可能なインタラクティブなコントロールに使用します。 `role="checkbox"` を含む要素には、チェックボックスの状態を支援技術に公開するための `aria-checked` 属性も含める必要があります。

ARIA: complementary ロール補足 (`complementary`) ランドマークロールは、メインコンテンツに関連する補助セクションを指定するために使用され、しかも分離しても単独で成り立つことができます。 これらのセクションは、サイドバーやコールアウトボックスとして表示されることがよくあります。 可能であれば、代わりに HTML の `aside` 要素を使用してください。

ARIA: contentinfo ロールコンテンツ情報 (`contentinfo`) ランドマークロールは、著作権情報、ナビゲーションリンク、プライバシーステートメントなど、ウェブサイトの各ページの最後に繰り返される情報を識別するために使用します。 このセクションは一般的にフッターと呼ばれます。

ARIA: dialog ロールダイアログ (`dialog`) ロールは、ウェブアプリケーションやウェブページの残りの部分からコンテンツや UI を分離する HTML ベースのアプリケーションのダイアログやウィンドウをマークアップするために使用します。 ダイアログは通常、オーバーレイを使用して残りのページコンテンツの上に配置されます。 ダイアログはノンモーダル (ダイアログ外のコンテンツともやりとり可能) またはモーダル (ダイアログ内のコンテンツのみとやりとり可能) のいずれかになります。

ARIA: document ロール複雑な複合ウィジェット (en-US)やアプリケーションで一般的に使用される文書 (`document`) ロールは、コンテキストを読み取りモードに切り替えることを支援技術を知らせることができます。 文書 (`document`) ロールは、読み取りモードまたは閲覧モードを持つ支援技術に、この要素に含まれるコンテンツを文書モードを使用して読み取るように指示します。

ARIA: feed ロールフィード (`feed`) は動的にスクロール可能な記事 (`article`) のリスト (`list`) で、ユーザーがスクロールすると記事がリストのどちらかの端から追加または削除されます。 フィード (`feed`) により、スクリーンリーダーは閲覧モードの読み取りカーソルを使用して、リッチコンテンツのストリームを読み込みながらスクロールすることを可能にし、ユーザーが読むにつれてコンテンツをさらにロードすることで無限にスクロールし続けることができます。

ARIA: figure ロールARIA の図表 (`figure`) ロールは、適切な意味論がまだ存在しないページコンテンツ内の図表を識別するために使用できます。 図表は一般的に、正規のテキストの流れとは異なる方法で情報を伝える、1 つ以上の画像、コードスニペット、またはその他のコンテンツと見なされます。

ARIA: form ロールフォーム (`form`) ランドマークロールは、HTML のフォームと同等の機能を提供するページ上の要素のグループを識別するために使用できます。

ARIA: grid ロールグリッド (`grid`) ロールは、1 つ以上のセルの行を含むウィジェット用です。 各セルの位置は重要であり、キーボード入力を使用してフォーカスすることができます。

ARIA: gridcell ロールグリッドセル (gridcell) ロールは、グリッド (grid) やツリーグリッド (treegrid (en-US)) にセルを作成するために使用します。 これは、情報を表スタイルでグループ化する HTML の `td` 要素の機能を模倣することを意図しています。

ARIA: heading ロール見出し (`heading`) ロールは、この要素をページやセクションの見出しとして定義します。 ページに構造を与えるために、セクション間の関係を示すレベルも提供するべきです。

ARIA: list ロールARIA のリスト (`list`) ロールは、項目のリストを識別するために使用できます。 これは通常、リスト内に含まれるリスト項目を識別するために使用するリスト項目 (`listitem`) ロールと組み合わせて使用します。

ARIA: listbox ロールリストボックス (`listbox`) ロールは、HTML の `<select>` 要素とは異なり、画像を含むことができる、1 つまたは複数の静的な項目をユーザーが選択できるリストに使用します。

ARIA: listitem ロールARIA のリスト項目 (`listitem`) ロールは、項目のリスト内の項目を識別するために使用できます。 これは、通常、リストコンテナーを識別するために使用するリスト (`list`) ロールと組み合わせて使用します。

ARIA: main ロールメイン (`main`) ランドマークロールは、文書の主要なコンテンツを示すために使用します。 メインコンテンツ領域は、文書の中心的な話題やアプリケーションの中心的な機能と直接関連したり、それらを拡張するコンテンツで構成されます。

ARIA: navigation ロールナビゲーション (`navigation`) ランドマークロールは、ウェブサイトやページコンテンツをナビゲートするために使用される主要なリンクのグループを識別するために使用します。

ARIA: option ロール`option` ロールは `listbox` で選択可能な項目に使用します。

ARIA: region ロールリージョン (`region`) ランドマークロールは、文書内で、著者が重要であると識別した領域を識別するために使用されます。 これは、他のランドマークロールのどれも適切でないときでも、汎用のランドマークを提供することで、人々が容易にナビゲートできるようにするために使用されます。

ARIA: row ロール行ロール (`role="row"`) を持つ要素は、表形式の構造内に並んだセルの一行です。 行には、1 つ以上のセル、グリッドセル、列ヘッダー、場合によっては行ヘッダーが含まれます。 行は、グリッド (`grid`)、表 (`table`)、ツリーグリッド (`treegrid` (en-US)) 内に含まれ、任意で行グループ (`rowgroup`) 内に含まれることもあります。

ARIA: rowgroup ロール行グループロール (`role="rowgroup"`) を持つ要素は、表形式の構造内の行 (`row`) のグループです。 行グループ (`rowgroup`) には、グリッド (`grid`)、表 (`table`)、ツリーグリッド (`treegrid` (en-US)) 内のセル (`cell`)、グリッドセル (`gridcell`)、列ヘッダー (`columnheader` (en-US))、行ヘッダー (`rowheader` (en-US)) の行が 1 つ以上含まれます。

ARIA: search ロール検索 (`search`) ランドマークロールは、ページ、サイト、またはサイトのコレクションの検索に使用されるページのセクションを識別するために使用します。

ARIA: switch ロールARIA のスイッチ (**`switch`**) ロールは、チェックボックス (`checkbox`) ロールと機能的に同じですが、かなり一般的な意味を持つ「チェックされた」状態と「チェックされていない」状態を表す代わりに、スイッチ (`switch`) ロールは「オン」と「オフ」の状態を表す点が異なります。

ARIA: tab ロールARIA のタブ (`tab`) ロールは、タブリスト (`tablist`) 内のインタラクティブな要素を示し、アクティブ化されると、関連するタブパネル (`tabpanel` (en-US)) を表示します。

ARIA: table ロールARIA の role 属性の table 値は、このロールを含む要素を、ネイティブの `table` HTML 要素と同様に、行と列に配置されたデータを含む非インタラクティブな表構造を持つものとして識別します。

ARIA: term ロール`term` ロールは、オプションで対応する `definition` (en-US) を持つ単語やフレーズに使用することができます。

ARIA: textbox ロール`textbox` ロールは、自由形式テキストの入力を可能にする要素を識別するために使用されます。 可能であれば、このロールを使用するのではなく、単一行入力の場合は `type="text"` の `input` 要素を使用し、複数行入力の場合は `textarea` 要素を使用してください。

group ロールの使用このテクニックは、`group` ロールを使用する方法を示し、ブラウザーと支援技術に与える影響について説明します。

link ロールの使用このテクニックは、`link` ロールを使用する方法を示し、ブラウザーと支援技術に与える影響について説明します。

log ロールの使用このテクニックは、`log` ロールを使用する方法を示し、ブラウザーと支援技術に与える影響について説明します。

presentation ロールの使用このテクニックは、`presentation` ロールの使い方を示し、ブラウザーや支援技術への影響について説明します。

progressbar ロールの使用このテクニックは、`progressbar` ロールの使い方を示し、ブラウザーや支援技術への影響について説明します。

radio ロールの使用このテクニックは、`radio` ロールをどのように使用するかを示し、ブラウザーと支援技術に及ぼす影響について説明します。

slider ロールの使用このテクニックは、`slider` ロールの使い方を示し、ブラウザーと支援技術に及ぼす影響について説明します。

status ロールの使用このテクニックは、`status` ロールを使用する方法を示し、ブラウザーと支援技術に及ぼす影響について説明します。

toolbar ロールの使用このテクニックは、`toolbar` ロールを使用する方法を示し、ブラウザーと支援技術に与える影響について説明します。

* alertdialog
* banner
* Combobox (en-US)
* Command (en-US)
* Columnheader (en-US) (Estelle)
* complementary (en-US)
* composite (en-US)
* Definition (en-US)
* Directory (en-US)
* Feed
* Gridcell (Eric E)
* Group
* input (en-US)
* landmark (en-US)
* Link - old page
* listbox
* Log - old page
* Marquee (en-US)
* math (en-US)
* menu (en-US)
* menubar (en-US)
* Menuitem
* Menuitemcheckbox (en-US)
* Menuitemradio (en-US)
* none (en-US)
* note (en-US)
* Option
* presentation
* Progressbar - old page
* Radio - old page
* radiogroup (en-US)
* range (en-US)
* region
* roletype (en-US)
* rowheader (en-US)(Estelle)
* Scrollbar (en-US)
* searchbox (en-US)
* section (en-US)
* sectionhead (en-US)
* select (en-US)
* separator (en-US)
* Slider - old page
* Spinbutton (en-US)
* Status - old page
* structure (en-US)
* tab
* tablist (en-US) (Michiel)
* Tabpanel (en-US) (Michiel)
* term
* Timer
* toolbar
* Tooltip (en-US)
* Tree (en-US)
* treegrid (en-US)
* Treeitem (en-US)
* widget (en-US)
* window (en-US)


ARIA ガイド - アクセシビリティ

ARIA ガイド
========

Accessible Rich Internet Applications (**ARIA**) は障がいのある人にとってウェブをもっとアクセシブルにする方法です。それに従ういくつかのガイドラインは、ウィジェットの配置のためのドラッグアンドドロップのように、よりよいアクセシビリティを保証します。

* フォームのエラー処理
* ウィジェットへのラベルづけ
* 複合ウィジェットや領域のラベルづけ
* 複合ウィジェットのフォーカス管理 (aria-activedescendant vs roving tabindex)
* ランドマークロールを使う
* 動的更新とライブ領域を扱う
* AT 製品の仮想と非仮想モード
* ドラッグアンドドロップを使う
* 非 ARIA なスクリーンリーダーのユーザーへの通知
* プレゼンテーションロールの構造を固定する
* レイアウト表を隠す
* モーダルと非モーダルなダイアログを管理する
* HTML5 で ARIA を使う
* ARIA をテストする方法
* モバイル端末での ARIA


ARIA ライブリージョン - アクセシビリティ

ARIA ライブリージョン
=============

JavaScript を使うと、検索結果のリストを瞬時に更新する、もしくはユーザーの操作を必要としないような控えめなアラートや通知を表示するなど、ページ全体をリロードせずにページの一部を動的に変更することができます。 これらの変更は通常ページを見ることのできるユーザーにとっては視覚的に明らかですが、支援技術ユーザーにとっては明確ではないかもしれません。ARIA ライブリージョンはこのギャップを埋め、動的なコンテンツの変更を支援技術により通知できるやり方で、プログラムによって表出させる方法を提供します。

**メモ:** 支援技術はライブリージョンへのコンテンツの *動的な* 変更を通知します。
 `aria-live` 属性もしくは 特化したライブリージョン `role` （例えば `role="alert"` ）を、変更をアナウンスしたい要素に含めることで有効になりますが、変更が起こる前にこれらの属性が追加されている必要があります。 —　最初からマークアップに含まれていても、 JavaScript で動的に追加しても構いません。

ライブリージョン
--------

ページのリロードなしに更新される動的なコンテンツは、ほとんどの場合領域もしくはウィジェットのどちらかです。 対話的でないシンプルなコンテンツの変更は、ライブリージョンとして記されるべきです。ライブリージョンは `aria-live` 属性を使って明示するべきです。

**`aria-live`**: `aria-live=POLITENESS_SETTING` はスクリーンリーダーがライブリージョンの更新処理の優先度を設定するために使われます。設定は `off`、`polite`、`assertive` で、既定は `off` です。この属性は間違いなく最も重要な属性です。

通常、`aria-live="polite"` のみが使われます。ユーザーにとって重要な更新を受け取るが、うるさくなるほど速くすべきでない領域にはこの属性を設定すべきです。スクリーンリーダーはユーザーがアイドル状態になったときに読み上げを行います。

`aria-live="assertive"` は、即時に伝えてユーザーの注意を引く必要のある、時間にシビアな通知にのみ使用します。 一般的に assertive なライブリージョンへの変更は、スクリーンリーダーがその時に読み上げているものに割り込みます。つまり、うるさかったり、混乱の元になり得るので、控えめに使うべきです。

`aria-live="off"` は要素の既定として扱われるので、明示的に指定する必要はありません。ただし、暗黙のライブリージョンロール（例えば `role="alert"`）を持つ要素からの出力を止めたい場合は話が別です。

### 基本的な例: 有益な画面上の情報を更新するドロップダウンボックス

惑星についての情報を提供することに特化したウェブサイトにドロップダウンボックスがあります。ドロップダウンから惑星が選ばれたとき、選択された惑星の情報でページ上のある領域が更新されます。

```html
<fieldset>
  <legend>Planet information</legend>
  <label for="planetsSelect">Planet:</label>
  <select id="planetsSelect" aria-controls="planetInfo">
    <option value="">Select a planet…</option>
    <option value="mercury">Mercury</option>
    <option value="venus">Venus</option>
    <option value="earth">Earth</option>
    <option value="mars">Mars</option>
  </select>
  <button id="renderPlanetInfoButton">Go</button>
</fieldset>

<div role="region" id="planetInfo" aria-live="polite">
  <h2 id="planetTitle">No planet selected</h2>
  <p id="planetDescription">Select a planet to view its description</p>
</div>

<p>
  <small>
    Information from
    <a href="https://en.wikipedia.org/wiki/Solar\_System">Wikipedia</a>
  </small>
</p>
```

```js
const PLANETS\_INFO = {
  mercury: {
    title: "Mercury",
    description:
      "Mercury is the smallest and innermost planet in the Solar System. It is named after the Roman deity Mercury, the messenger to the gods.",
  },

  venus: {
    title: "Venus",
    description:
      "Venus is the second planet from the Sun. It is named after the Roman goddess of love and beauty.",
  },

  earth: {
    title: "Earth",
    description:
      "Earth is the third planet from the Sun and the only object in the Universe known to harbor life.",
  },

  mars: {
    title: "Mars",
    description:
      'Mars is the fourth planet from the Sun and the second-smallest planet in the Solar System after Mercury. In English, Mars carries a name of the Roman god of war, and is often referred to as the "Red Planet".',
  },
};

function renderPlanetInfo(planet) {
  const planetTitle = document.querySelector("#planetTitle");
  const planetDescription = document.querySelector("#planetDescription");

  if (planet in PLANETS\_INFO) {
    planetTitle.textContent = PLANETS\_INFO[planet].title;
    planetDescription.textContent = PLANETS\_INFO[planet].description;
  } else {
    planetTitle.textContent = "No planet selected";
    planetDescription.textContent = "Select a planet to view its description";
  }
}

const renderPlanetInfoButton = document.querySelector(
  "#renderPlanetInfoButton",
);

renderPlanetInfoButton.addEventListener("click", (event) => {
  const planetsSelect = document.querySelector("#planetsSelect");
  const selectedPlanet =
    planetsSelect.options[planetsSelect.selectedIndex].value;

  renderPlanetInfo(selectedPlanet);
});
```

ユーザーが新しい惑星を選択したとき、ライブリージョンの情報が通知されます。ライブリージョンは `aria-live="polite"` を持っているため、スクリーンリーダーはユーザーが一時停止するまで、更新の通知を待ちます。例えばリストを下りながら他の惑星を選択してもライブリージョンの更新は通知されないでしょう。最終的に選ばれた惑星でのみライブリージョンの更新は通知されます。

こちらはライブリージョンへ（字幕を通して）更新を通知している、Mac に内蔵している VoiceOver のスクリーンショットです。

![Mac の VoiceOver のスクリーンショット。字幕が表示されています。](/ja/docs/Web/Accessibility/ARIA/ARIA_Live_Regions/web_accessibility_aria_aria_live_regions.png)

ライブリージョン属性を含むロール
----------------

次の `role="…"` 値を持つ要素は、既定ではライブリージョンのように振る舞います。

| ロール | 説明 | 互換性に関する注意事項 |
| --- | --- | --- |
| log | チャット、エラー、ゲーム、その他の種類のログ | 互換性を最大限にするために、このロールを使う際には冗長な `aria-live="polite"` を追加してください。 |
| status | ある種の更新された状態を表すステータスバーもしくは画面上の領域。スクリーンリーダーのユーザーには、現在のステータスを読みとるための特別なコマンドがあります。 | 互換性を最大限にするために、このロールを使う際には冗長な `aria-live="polite"` を追加してください。 |
| alert | スクリーン上で点滅するエラーもしくはアラートメッセージ。アラートは特に、クライアントサイドでユーザーの入力を検査する際の通知で重要です。アラートの例。 | 互換性を最大限にするために、このロールを使う際に冗長に `aria-live="assertive"` を追加するよう勧める人もいます。しかし、`aria-live` と `role="alert"` の両方を追加すると iOS の VoiceOver で二重に読み上げられるという問題を引き起こします。 |
| progressbar | ウィジェットとライブリージョンのハイブリッド。`aria-valuemin`、`aria-valuenow`、`aria-valuemax` と共に使います。（TBD: 情報の追加を検討中） |  |
| marquee | 株式相場表示機のようなスクロールするテキストのためのものです。 |  |
| timer | カウントダウンタイマーやストップウォッチなどの、ある種のタイマーや時計の読み上げ。 |  |

ライブリージョン属性についてのさらなる説明
---------------------

ライブリージョンはとてもよくサポートされています。The Paciello Group は、2014年に、ライブリージョンのサポート状況についての情報 (2014) を投稿しました。Paul Jadam は特に `aira-atomic` と `aria-relevant` のサポートについてのリサーチをしました。

1. **`aria-atomic`**: `aria-atomic=BOOLEAN` は領域の一部だけが変更された場合でも、スクリーンリーダーが常にライブリージョン全体を読み上げるかどうかを設定します。可能な設定は `false` または `true` で、既定は `false` です。
2. **`aria-relevant`** (en-US)
 : `aria-relevant=[LIST_OF_CHANGES]` はどういった類の変更がライブリージョンに関連するかを設定します。可能な設定は `additions`、`removals`、`text`、`all` から一つ以上で、 `additions text` が既定です。
### 基本的な例: `aria-atomic`

`aria-atomic` についての説明のために、時間と分を表するシンプルな時計を表示するサイトを考えます。時計は毎分更新され、新しい残り時間でそのときのコンテンツを上書きします。

```html
<div id="clock" role="timer" aria-live="polite">
  <span id="clock-hours"></span>
  <span id="clock-mins"></span>
</div>
```

```js
/\* basic JavaScript to update the clock \*/
function updateClock() {
  const now = new Date();
  document.getElementById("clock-hours").textContent = now.getHours();
  document.getElementById("clock-mins").textContent =
    `0${now.getMinutes()}`.substr(-2);
}

/\* first run \*/
updateClock();

/\* update every minute \*/
setInterval(updateClock, 60000);
```

関数が初めて実行されるとき、追加された文字列のすべてが通知されます。 その後の呼び出しでは、過去のコンテンツと比較して変更されたコンテンツの一部が通知されます。例えば、時計が "17:33" から "17:34" へ変更されたとき、支援技術は "4" のみを通知します。これはユーザーにとってほとんど役に立たないでしょう。

一つの回避策は最初にライブリージョンのコンテンツをクリア（この場合、`<span id="clock-hours">` と `<span id="clock-mins">` の `innerHTML` を空にセット）してから、新しいコンテンツを挿入することです。しかしながら、この方法はこれら2つの更新の正確なタイミングに依存するため、しばしば信頼性にかけることがあります。

`aria-atomic="true"` はライブリージョンが更新されるたびに、コンテンツの全体 (例 "17:34") が通知されることを保証します。

```html
<div id="clock" role="timer" aria-live="polite" aria-atomic="true">…</div>
```

`aria-atomic` のもう一つの例 - ユーザーのアクションによる結果の更新/通知

```html
<div id="date-input">
  <label for="year">Year:</label>
  <input type="text" id="year" value="1990" onblur="change(event)" />
</div>

<div id="date-output" aria-atomic="true" aria-live="polite">
  設定された年:
  <span id="year-output">1990</span>
</div>
```

```js
function change(event) {
  const yearOut = document.getElementById("year-output");

  switch (event.target.id) {
    case "year":
      yearOut.innerHTML = event.target.value;
      break;
    default:
      return;
  }
}
```

`aria-atomic="true"` がないと、スクリーンリーダーは変更された年の値のみを読み上げます。`aria-atomic="true"` があると、スクリーンリーダーは 「設定された年: *変更された値*」 と発音します。

### 基本的な例: `aria-relevant`

`aria-relevant` があると、ライブリージョンに対するどのタイプの変更/更新を通知するのかを指定できます。

一例として、チャットサイトで、現在ログインしているユーザーの一覧を表示することを考えましょう。単に現在ログインしているユーザーを通知するだけではなく、ユーザーがリストから *削除* されたときにも通知を発行したいです。 `aria-relevant="additions removals"` を指定することで、これを実現できます。

```html
<ul id="roster" aria-live="polite" aria-relevant="additions removals">
  <!-- use JavaScript to add and remove users here -->
</ul>
```

ARIA ライブプロパティの内訳:

* `aria-live="polite"` はスクリーンリーダーが更新をユーザーへ通知する前に、ユーザーがアイドル状態になるまで待つべきであることを示しています。"assertive" による中断では、ユーザーのフローを妨げるかもしれないため、これが最も一般的に使用される値です。
* `aria-atomic` は設定されていません（既定値の `false` が入ります）ので、追加または削除されたユーザーのみが読み上げられ、名簿全体が都度読み上げられることはないはずです。
* `aria-relevant="additions removals"` により名簿に追加もしくは削除されたユーザーが読み上げられることを確かにします。
関連情報
----

* ARIA ロール