World Wide Web Consortium の作業グループによって作成された Web Content Accessibility Guideline(WCAG)2.1 は、障碍のあるユーザーが Web コンテンツにアクセスして利用できるように、一連の技術に依存しないガイドラインと達成基準で構成されています。
手順の説明に、コンソーシアムは一連のセクションとサポートドキュメントを提供しています。
さらに、詳細は次を参照してください。
ガイドラインは 3 つの適合レベル(レベル A(最低)、レベル AA、レベル AAA(最高))に分けられます。各レベルの簡単な定義を次に示します。
サイトを作成する際は、サイトの全体的なレベルを特定する必要があります。
次の節では、WCAG 2.1 ガイドラインのレイヤーおよび適合レベル A と AA の関連する達成基準を示します。
このドキュメントでは、次の表記を使用しています。
原則 1:知覚可能 - 情報およびユーザーインターフェイスコンポーネントは、ユーザーが知覚できる方法でユーザーに提示可能でなければならない。
ガイドライン 1.1 代替テキスト:すべてのテキスト以外のコンテンツには、拡大印刷、点字、音声、シンボル、平易な言葉などのユーザーが必要とする形式に変換できるように、代替テキストを提供すること。
Web ページ上の情報はテキスト以外の様々な形式(写真、ビデオ、アニメーション、チャート、グラフなど)で指定できます。視覚に障碍のあるユーザーは、テキスト以外のコンテンツを見ることができませんが、スクリーンリーダーによる読み上げや、触覚で感知可能な点字表示デバイスを使用すれば、テキストコンテンツにアクセスできます。そのため、グラフィカルな形式にコンテンツの代替テキストを指定することにより、グラフィカルなコンテンツを見ることができないユーザーも、そのコンテンツが提供するものと同等の情報にアクセスできます。
もう 1 つのメリットとして、代替テキストを使用すると、検索エンジンのテクノロジーによってテキスト以外のコンテンツのインデックスを作成できます。
静的なグラフィックの場合、そのグラフィックと同等の代替テキストを指定することが基本的な要件です。それには、「代替テキスト」フィールドを使用します。例えば、画像コアコンポーネントを参照してください。
標準搭載のコアコンポーネントには、個々の画像に代替テキスト記述を追加するための「代替テキスト」フィールドが用意されていないもの(カルーセルなど)もありますが、「ラベル」フィールド(「アクセシビリティ」タブ)は全コンポーネントにあります。
AEM インスタンスにこれらのバージョンを実装する場合は、作成者がコンテンツに追加できるように、開発チームは alt
属性をサポートするようにこれらのコンポーネントを設定する必要があります(追加の HTML 要素および属性のサポートの追加を参照)。
AEM では、デフォルトで入力される「代替テキスト」フィールドが必要です。画像が単なる装飾用で代替テキストが不要な場合は、「画像は装飾画像」オプションをチェックできます。
テキスト以外のコンテンツには様々な形式があるので、代替テキストの値は、Web ページにおけるグラフィックの役割に応じて異なります。従う必要のある一般的な手法を次に示します。
代替テキストを必要とするテキスト以外のコンテンツには、以下のようなタイプがあります。
graphic
や image
など)を知らせる際には、通常、画像コンテンツについて説明することをお勧めします。代替テキストの説明で screenshot
や illustration
を使用すると、より明確な説明になることがありますが、それは状況によります。一貫性は大きな要因です。オーサリングチーム全体で共有される決定を行い、その決定をユーザーエクスペリエンス全体に適用する必要があります。背景と手前のテキストの間には適度なコントラストが必要です。これについて詳しくは、コントラスト(最低限)(1.4.3)を参照してください。
ガイドライン 1.2 時間依存メディア:時間依存メディアには代替コンテンツを提供すること。
ここでは、時間依存の Web コンテンツについて扱います。これには、ユーザーが再生可能なコンテンツ(映像、音声、アニメーションなど)や、収録済みのコンテンツ、ライブストリームなどが含まれます。
次のようなユーザーに、アクセシビリティの問題が発生します。
映像または音声は、Adobe Flash など特定のメディア形式のコンテンツ再生をサポートしていないブラウザーやデバイスを使用しているユーザーも使用できない場合があります。
この情報を別の形式(テキストや、音声なしの映像に音声を付けるなど)で提供すると、元のコンテンツにアクセスできないユーザーがアクセス可能になります。
同じ Web ページ上に既に別の形式で存在するコンテンツの代替としてオーディオまたはビデオコンテンツを提供する場合は、代替情報をさらに追加する必要がない可能性があります。
詳しくは、WCAG 1.2.1 の理解をガイドラインとして参照してください。
マルチメディアを AEM Web ページに挿入することは、画像の挿入と似ています。ただし、マルチメディアコンテンツには静止画像より多くの機能が含まれているので、マルチメディアの再生方法を制御するために、様々な設定やオプションがあります。
情報提供のためのコンテンツでマルチメディアを使用する場合は、代替のリンクも作成する必要があります。例えば、字幕を含めるには、字幕を表示するための HTML ページを作成してから、音声コンテンツの横または下にリンクを追加します。
聴覚障碍のあるユーザーは、音声コンテンツにアクセスできないか、アクセスが非常に困難になります。キャプションは、音声で話されている内容と話されていない内容に相当するテキストであり、映像再生中に適時画面に表示されます。これにより、音声を聞くことのできないユーザーが内容を理解できます。
キャプションは、次のいずれかの状態に設定できます。
可能な場合は、クローズドキャプションを使用して、キャプションの表示、非表示をユーザーが選択できるようにしてください。
クローズドキャプションの場合は、適切な形式(SMIL など)の同期キャプションファイルを映像ファイルと共に作成して提供する必要があります(この方法の詳細は、このガイドの範囲外ですが、詳細情報 - キャプション(収録済み)(1.2.2)に、いくつかのチュートリアルへのリンクを提示しています)。映像でキャプションを利用できることをユーザーに知らせるために、注意書きを表示するか、ビデオプレーヤーのキャプション機能を有効にしてください。
オープンキャプションを使用する必要がある場合は、映像トラック内にテキストを埋め込みます。これを行うには、映像にタイトルをオーバーレイできるビデオ編集アプリケーションを使用します。
映像やアニメーションの情報が視覚的にのみ提供されている場合や、内容を視覚的に理解するのに十分な情報が音声で提供されていない場合は、視覚障碍のあるユーザーにアクセシビリティの問題が発生します。
この達成基準を満たすために採用できる方法は 2 つあり、どちらを使用してもかまいません。
音声解説付きの映像の詳細な作成方法は、このガイドの範囲外です。映像および音声解説の作成には長時間を要する可能性がありますが、他のアドビ製品が役に立つ場合があります。
この達成基準は、聴覚障碍のあるユーザーのアクセシビリティに関する問題に対応する点で、キャプション(収録済み)と同じです。ただし、この達成基準では Web キャストなどライブのプレゼンテーションを扱う点が異なります。
上記のキャプション(収録済み)のガイダンスに従ってください。ただし、メディアがライブなので、キャプションは可能な限り短時間で、起こっていることに応じて作成する必要があります。したがって、リアルタイムキャプションツールや音声テキスト変換ツールの使用を検討してください。
詳細な手順説明はこのドキュメントの範囲外ですが、次のリソースで役に立つ情報が提供されています。
この達成基準は、音声解説または代替メディア(収録済み)と同じです。ただし作成者は、レベル AA に準拠するために、より詳細な音声解説を提供する必要があります。
音声解説または代替メディア(収録済み)のガイダンスに従ってください。
ガイドライン 1.3 適応可能:情報および構造を損なうことなく、様々な方法(例えば、よりシンプルなレイアウト)で提供できるようにコンテンツを制作している。
このガイドラインは、次のようなユーザーのサポートに必要な要件に対応しています。
そのコンテンツのデフォルト表示(複数列のレイアウトや、色や画像を多用したページなど)では、作成者が提示した情報にアクセスできない場合があるユーザー
音声のみ、または大きいテキストや高いコントラストなど、代替の視覚表示を使用する可能性のあるユーザー
障碍のあるユーザーが使用する多くの支援テクノロジーでは、コンテンツを効果的に表示または理解するために構造情報に基づいています。この構造情報は、ページ見出し、テーブルの行見出しおよび列見出し、リストタイプの形式を取ることができます。例えば、スクリーンリーダーを使用すれば、ページ内を見出しから見出しへと移動できます。ただし、ページコンテンツの構造が基になる HTML ではなく、視覚的なスタイルでのみ設定されているように見える場合、支援テクノロジーでは構造情報を利用できず、ブラウジングの操作性の向上を十分サポートできなくなります。
この達成基準の目的は、ブラウザーおよび支援テクノロジーが構造情報にアクセスし情報を利用できるように、構造情報が HTML やその他のコーディング手法を使用してプログラムで確実に提供されるようにすることです。
AEM では、適切な HTML 要素を使用することにより、意味のある Web コンテンツを簡単に構築できます。RTE(テキストコンポーネント)でページコンテンツを開き、段落書式メニュー(段落記号)を使用して、適切な構造要素(段落、見出しなど)を指定します。
次の要素を適宜使用して、Web ページに適切な構造を確実に指定できます。
見出し:RTE のアクセシビリティ機能を有効にしている場合、AEM では 3 つのレベルのページ見出しが提供されます。これらを使用して、コンテンツのセクションおよびサブセクションを識別できます。「見出し 1」は最上位の見出し、「見出し 3」は最下位の見出しです。システム管理者の設定により、使用可能な見出しレベルを増やすこともできます。
リスト:HTML を使用して、3 つの異なるタイプのリストを指定できます。
<ul>
要素は、順序なし(箇条書き)リストに使用します。個々のリスト項目は、<li>
要素を使用して識別されます。RTE では、箇条書きアイコンを使用します。<ol>
要素は、番号付きリストに使用します。個々のリスト項目は、<li>
要素を使用して識別されます。RTE では、「番号付きリスト」アイコンを使用します。既存のコンテンツを特定のリストタイプに変更する場合は、該当するテキストをハイライト表示して、適切なリストタイプを選択します。前述した段落テキストの入力方法を示す例と同様に、適切なリスト要素が HTML に自動的に追加されます。
全画面表示モードでは、個別の箇条書きリストおよび番号付きリストアイコンが表示されます。全画面表示モード以外の場合、1 つのリストアイコンから 2 つのオプションを使用できます。
テーブル:データのテーブルは、HTML のテーブル要素を使用して識別する必要があります。
<table>
要素<tr>
要素<th>
要素<td>
要素さらに、アクセス可能なテーブルでは、次の要素および属性も使用します。
<caption>
要素は、テーブルの表示可能なキャプションを提供する際に使用します。キャプションは、デフォルトではテーブルの上に中央配置で表示されますが、CSS を使用して適切に配置できます。キャプションはプログラムによってテーブルに関連付けられるので、コンテンツを紹介する際に役立ちます。<summary>
要素は、目の見えるユーザーに見えているものの概要を提示することで、視覚障碍のあるユーザーがテーブル内の情報をより簡単に理解できるように支援します。これは、複雑な、型どおりでないテーブルレイアウトが使用されている場合に特に便利です(この属性はブラウザーには表示されません。支援テクノロジーに読み上げられるだけです)。<th>
要素の scope
属性は、セルが特定の行のヘッダーを表すか、特定の列のヘッダーを表すかを示すために使用します。同様の方法として、データセルが 1 つ以上のヘッダーに関連付けられている複雑なテーブルで、header 属性と id 属性を使用することがあります。デフォルトでは、これらの要素や属性を直接使用することはできませんが、システム管理者が、「テーブルのプロパティ」ダイアログボックスでこれらの値のサポートを追加することは可能です(追加の HTML 要素および属性のサポートの追加を参照してください)。
「テーブルのプロパティ」タブを選択できるテーブルダイアログを開くには、次のようにします。
次に、セルのプロパティを使用して、セルがデータセルかヘッダーセルかを選択できます。
強調:<strong>
または <em>
要素を使用して強調を指定します。段落内のテキストをハイライト表示するために見出しを使用しないでください。
強調するテキストをハイライト表示します。
「B」アイコン(<strong>
に対応)または「I」アイコン(<em>
に対応)を、プロパティパネルでクリックします(HTML が選択されていることを確認してください)。
AEM の標準的なインストールに含まれる RTE は、次のように設定されています。
<b>
の代わりに <strong>
を使用<i>
の代わりに <em>
を使用それぞれ実質的には同じですが、好ましいのは、意味的に正しい HTML である <strong>
と <em>
です。開発チームがプロジェクトインスタンスを作成する際に、<strong>
と <em>
ではなく <b>
と <i>
を使用するように RTE を設定できます。
複雑なデータテーブル:レベルが 2 つ以上あるヘッダーを含む複雑なテーブルがある場合など、場合によっては、基本的なテーブルのプロパティでは必要な構造情報を十分に指定できないことがあります。このような複雑なテーブルでは、header 属性と id 属性を使用して、ヘッダーとその関連セルの間に直接の関係を作成する必要があります。
id 属性は、標準のインストールでは使用できません。RTE で HTML ルールとシリアライザーを設定することによって有効にできます。
例えば、以下に示すテーブルでは、支援テクノロジーユーザーのためのプログラムによる関連付けを作成するために、header と id が照合されています。
<table>
<tr>
<th rowspan="2" id="h">Homework</th>
<th colspan="3" id="e">Exams</th>
<th colspan="3" id="p">Projects</th>
</tr>
<tr>
<th id="e1" headers="e">1</th>
<th id="e2" headers="e">2</th>
<th id="ef" headers="e">Final</th>
<th id="p1" headers="p">1</th>
<th id="p2" headers="p">2</th>
<th id="pf" headers="p">Final</th>
</tr>
<tr>
<td headers="h">15%</td>
<td headers="e e1">15%</td>
<td headers="e e2">15%</td>
<td headers="e ef">20%</td>
<td headers="p p1">10%</td>
<td headers="p p2">10%</td>
<td headers="p pf">15%</td>
</tr>
</table>
AEM でこれを実現するには、ソース編集モードを使用してマークアップを直接追加する必要があります。
この機能は、標準インストールでは、すぐには使用できません。RTE、HTML ルールおよびシリアライザーを設定する必要があります。
この達成基準の目的は、ユーザーエージェントが意味を理解するために必要な読み取り順序を維持しながら、コンテンツの代替表示を可能にすることです。意味を持つコンテンツの少なくとも 1 つのシーケンスをプログラムで判断できることが重要です。この達成基準を満たさないコンテンツは、支援テクノロジーがコンテンツを誤った順序で読み取った場合や、代替スタイルシートやその他の書式変更が適用された場合、ユーザーを混乱させたり、方向を狂わせたりする可能性があります。
達成基準 1.3.2 の達成方法のガイドラインに従います。
デザイナーは多くの場合、情報を提示する際に、色、形状、テキストスタイル、コンテンツの絶対位置または相対位置など、視覚的なデザイン特性に注目します。これらは、情報を伝えるうえで非常に強力なデザイン手法になります(また、目の見えるユーザーでも認知的なアクセシビリティが必要な場合にはアクセシビリティ全体を向上させることができます)。ただし、視覚障碍のあるユーザーは、位置や色、形状などの属性を視覚的に識別する必要のある情報にはアクセスできない場合があります。
同様に、話し手が男性か女性かなど、異なる音声を区別する必要のある情報を音声コンテンツの代替テキストに反映しないと、聴覚障碍のあるユーザーにアクセシビリティの問題が発生します。
色の代替に関連する要件について詳しくは、色の使用を参照してください。
ページコンテンツの視覚的な特徴に依存する情報が、代替形式でも提示されていることを確認してください。
視覚的でないコンテキストで意味を持つことが理解される場合は、説明的な用語を使用してかまいません。例えば、「上記」や「下記」という表現を使用することは、通常は許容されます*。それぞれ、コンテンツの特定の項目の前後にあるコンテンツを示すからです。これは、コンテンツを声に出して読み上げる場合でも意味をなします。*
ガイドライン 1.4 判別可能:コンテンツを、利用者にとって見やすく、聞きやすいものにします。これには、前景と背景を区別することも含む。
この達成基準では、色覚を具体的に扱います。その他の知覚については、適応可能(1.3)で、色やその他の視覚的表現のコーディングを含めて説明しています。
色は、Web ページの美しさを強調するうえで間違いなく効果的な方法であり、情報を伝達するうえでも便利です。ただし、全盲から色覚異常まで、様々な視覚障碍があり、特定の色を区別できない人もいます。このため、情報を提供するうえで、色分けは信頼性の低い方法となります。
例えば、赤と緑の色覚異常のある人は、緑の影と赤の影を区別できません。両方の色が第三の色(茶色など)に見える場合があり、その場合は赤、緑、茶色を区別できません。
また、テキストのみのブラウザーやモノクロの表示デバイスを使用している場合や、ページの白黒印刷を見る場合も、色を知覚できません。
さらに考慮する必要があるのは、インターフェイス要素(タブ、トグルボタンなど)の選択状態です。この状態は、色などの視覚的な提示以外の方法で伝える必要があります。このような要素については、特定の感覚に依存しない包括的なユーザーエクスペリエンスを作成する場合、さらにパターン、図形、プログラム情報を使用すると役に立ちます。
色を使用して情報を伝達する場合は、色を見なくても情報を利用できるようにしてください。
例えば、色によって提供されている情報を、テキストでも明示的に提供します。
色を情報提供のキューとして使用する場合は、スタイル(太字、斜体など)やフォントの変更など、追加の視覚的キューを指定する必要があります。これは、視覚障碍を持つ人や色覚障碍を持つ人が情報を特定するのに役立ちます。ただし、ページをまったく見ることのできない人には役に立たないので、全面的に依存することはできません。したがって、視覚障碍のあるユーザーにこのような情報を伝えるには、隠しテキストを提供したり、ARIA(アクセシブルリッチインターネットアプリケーション)Web 標準規格などのプログラマティックソリューションを使用したりすると、役に立つ場合があります。
画面読み上げソフトウェアを使用している個人は、同時に他の音声が再生されている場合、音声出力を聞き取るのが難しい場合があります。この問題は、画面読み上げの音声出力が(現在のほとんどの場合と同様に)ソフトウェアベースで、サウンドとして同じ音量コントロールを介して制御される場合に悪化します。さらに、認知障碍や神経多様性のあるユーザーの中は、音に対する感受性が強い人がいる場合があります。このような人にとっては、オーディオコンテンツの音量レベルを変更できないと大きな問題になります。
したがって、ユーザーがバックグラウンドサウンドをオフにできることが重要です。
音量の調節には、音量をゼロにできることを含みます。
達成基準 1.4.2 の達成方法のガイドラインに従います。
達成基準 1.4.3
レベル AA
コントラスト(最低限):テキストおよびテキストの画像を視覚的に表現したものが、4.5:1 以上のコントラスト比を持つ。ただし、次の場合を除く。
詳しくは、Understanding Success Criterion 1.4.11: Non-text Contrast を参照して、コンテンツ作成者がテキスト以外の要素(アイコン、インターフェイス要素など)に関する追加要件を確認してください。
特定の視覚障碍のあるユーザーは、特定の低コントラストの色のペアを区別できない場合があります。次のいずれかの場合に、このようなユーザーにアクセシビリティの問題が発生することがあります。
純粋に装飾目的で使用されるテキストは、この達成基準から除外されます。
テキストと背景色のコントラストが十分であることを確認します。コントラスト比は、問題のテキストのサイズとスタイルによって異なります。
フォントは PT/PX/EM サイズ設定が同等でもレンダリング方法が異なる場合があることに注意してください。
Web コンテンツに適したフォントとサイズ設定を選択する際には、読みやすさと使いやすさを慎重すぎるぐらい慎重に考慮して、的確に判断することをお勧めします。
コントラスト比を確認するには、Paciello Group の Color Contrast Analyser や WebAIM の Color Contrast Checker などの色コントラストツールを使用してください。これらのツールを使用すると、色のペアを確認し、コントラストの問題を報告できます。
また、ページの外観の指定にそれほど関心がない場合は、背景や前面のテキストの色を指定しないことを選択できます。その場合、テキストや背景の色はユーザーのブラウザーによって決まるので、コントラストの確認は不要です。
推奨されるコントラストレベルを満たすことができない場合は、代替の、同等のページ(色のコントラストに関する問題がないページ)へのリンクを提供するか、ユーザーが自身の要件に合わせてページの配色のコントラストを調整できるようにする必要があります。
この達成基準の目的は、テキストベースの制御(見えるように表示されたテキスト文字 [対 ASCII などのデータ形式にあるテキスト文字])を含む、視覚的にレンダリングされたテキストを、拡大鏡などの支援テクノロジーを使用せずに、正常に拡大・縮小できるようにすることです。ユーザーが Web ページのすべてのコンテンツを拡大・縮小するメリットを受ける場合もありますが、テキストは最も重要です。
達成基準 1.4.4 の達成方法のガイドラインに従うだけでなく、読者がテキストのサイズを変更できるように、ページデザインやフォントサイズで流動的で柔軟な幅と高さ(レスポンシブ Web デザインなど)を使用するよう、コンテンツ作成者を促すことができます。
ロゴタイプ(ロゴまたはブランド名の一部であるテキスト)は必須と見なされます。
文字画像は、多くの場合、ロゴタイプなど特定のスタイルのテキストが好まれる場合や、テキストが別のソース(紙のドキュメントのスキャンなど)から生成された場合に使用されます。ただし、HTML で表現され、CSS を使用してスタイル設定されているテキストと比較して、文字画像は柔軟性に欠けており、視覚障碍のあるユーザーや読解が困難なユーザーにとって必要となるサイズや外観の変更ができません。
文字画像を使用する必要がある場合は、CSS を使用して、文字画像を同等の HTML テキストに置き換え、テキストをカスタマイズ可能にします。これを行う方法の例は、C30:CSS を用いて、テキストを画像化された文字に置き換え、変換するユーザーインターフェイスコントロールを提供するを参照してください。
原則 2:操作可能 - ユーザーインターフェイスコンポーネントおよびナビゲーションは操作可能でなければならない。
ガイドライン 2.1 キーボード操作可能:すべての機能をキーボードから使用できること。
これは、キーボードを使用してすべての機能のアクセスを確保することを目的としています。
この達成基準の目的は、可能な限りコンテンツをキーボード(または代替キーボード利用できるような)キーボードインターフェイスで操作ができるようにすることです。コンテンツをキーボードや代替キーボードで操作できる場合は、(目と手の協調運動を必要とするマウスのようなデバイスを使用できない)全盲の人や、代替キーボードやキーボードエミュレーターの役割をする入力デバイスを使用する必要がある人でも操作できます。キーボードエミュレーターには、音声入力ソフトウェア、息操作ソフトウェア、画面キーボード、スキャンソフトウェアなど、様々な支援テクノロジーや代替キーボードが含まれます。視覚障碍を持つ人は、ポインターを目で追うのが困難な場合があり、キーボードから制御できれば、ソフトウェアの使用が容易になる(あるいは可能になる)かもしれません。
達成基準 2.1.1 の達成方法のガイドラインに従います。
この達成基準の目的は、コンテンツが Web ページ上のコンテンツのサブセクション内にキーボードフォーカスをトラップしないようにすることです。これは、複数の形式がページ内で組み合わされ、プラグインや埋め込みアプリケーションを使用してレンダリングされる場合に発生する一般的な問題です。
Web ページの機能によって、フォーカスがコンテンツのサブセクション(モーダルダイアログなど)に制限される場合があります。そのような場合は、コンテンツのサブセクションからユーザーが移動できる方法を用意しておく必要があります(例えば、ESC キーや「閉じる」ボタンでモーダルダイアログを閉じるなど)。
達成基準 2.1.2 の達成方法のガイドラインに従います。
ガイドライン 2.2 十分な時間:ユーザーがコンテンツを読み、使用するのに十分な時間を提供します。
これは、ユーザーがコンテンツを読んで行動を起こすのに十分な時間を確保することを目的としています。
この達成基準の目的は、可能な限り常に、障碍のあるユーザーが Web コンテンツを利用するのに十分な時間を提供することです。全盲、視覚障碍、手指の障碍、認知機能の制限など、障碍のあるユーザーは、コンテンツを読むのに時間がかかる場合や、オンラインフォームの入力などの機能を実行するのに時間がかかる場合があります。Web 機能が時間に依存する場合は、制限時間より前に必要な操作を行うのが難しい場合があります。これにより、サービスにアクセスできなくなる場合があります。時間に依存しない機能をデザインすることで、障碍のある人がこうした機能を完了するのに役立ちます。時間制限の無効化、時間制限のカスタマイズ、時間制限になる前に延長リクエストを行うオプションを提供することで、タスクの完了に予想以上の時間を要するユーザーの役に立ちます。これらのオプションは、ユーザーにとって最も役に立つ順に表示されます。時間制限を無効にする方が、時間制限の長さをカスタマイズするよりも効果的で、時間制限の長さをカスタマイズする方が、時間制限前の延長リクエストよりも効果的です。
達成基準 2.2.1 の達成方法のガイドラインに従います。
注意点は次のとおりです。
ユーザーによっては、動くコンテンツが気が散る、さらには肉体的に苦痛とまで感じられて、ページの他の部分に集中することが難しくなる場合があります。さらに、動くテキストを目で追うのに苦労するユーザーには、そのようなコンテンツは読みにくいことがわかる場合もあります。
移動、閃光、点滅の性質を持つコンテンツを含む Web ページを作成する際には、コンテンツの性質に応じて、次のうち 1 つ以上の提案事項を適用できます。
ガイドライン 2.3 発作の防止:発作や身体的反応を引き起こすようなコンテンツを設計しないこと。
この達成基準を満たさないコンテンツがある場合は、ユーザーがページ全体を使用できない場合があるので、Web ページ上のすべてのコンテンツ(他の達成基準を満たすために使用されているかどうかにかかわらず)が、この達成基準を満たす必要があります。適合要件の「5. 非干渉」を参照してください。
場合によっては、コンテンツが放つ閃光によって光過敏性発作が発生する可能性があります。この達成基準を満たすと、そのようなユーザーが閃光を放つコンテンツの心配をせずにすべてのコンテンツにアクセスし、体験できます。
次の技法が適用されていることを確認する必要があります。
ガイドライン 2.4 ナビゲーション可能:ユーザーのナビゲーション、コンテンツの検索、位置の特定に役立つ方法を提供します。
これは、ユーザーがコンテンツを簡単かつ明白にナビゲートできることを目的としています。
この達成基準の目的は、コンテンツ間を順番に移動する訪問者が、Web ページの主要なコンテンツにより直接敵にアクセスできるようにすることです。Web ページやアプリケーションには、他のページや画面に表示されるコンテンツが含まれる場合が多くあります。コンテンツの繰り返しブロックの例としては、ナビゲーションリンク、ヘッダーグラフィック、メニュー、広告フレームなどがありますが、これらに限定されません。個々の単語、フレーズ、単一のリンクなどの小さな繰り返しセクションは、この規定の目的ではブロックとは見なされません。
達成基準 2.4.1 の達成方法のガイドラインに従います。
この達成基準を満たすと、特定の障碍があるかどうかにかかわらず誰でも、ページ全体を読まずに Web ページの内容を短時間で識別できます。これは、ブラウザーのタブで複数の Web ページを開いている場合に特に便利です。ページタイトルがタブに表示されるので、簡単に見つけることができるからです。
AEM で新しい HTML ページを作成する際には、ページタイトルを指定できます。コンテンツが自分のニーズに実際に関係があるかどうかを訪問者がすばやく特定できるように、ページのコンテンツや目的、特に独自の観点を十分に反映したタイトルにしてください。
ページを編集する際に、ページタイトルを編集することもできます(ページ情報/プロパティからアクセス可能)。
この達成基準の目的は、ユーザーがコンテンツを順番に移動する際に、コンテンツの意味に合った順序で情報が表示され、キーボードから操作できるようにすることです。これにより、ユーザーがコンテンツの一貫したメンタルモデルを作成できるので、混乱が軽減されます。コンテンツ内の論理的な関係を反映した異なる順序が存在する場合があります。例えば、複数のフィールドやステップで構成されるオンラインフォームでのコンポーネント間の移動は、コンテンツ内の論理的な関係を反映しています。
達成基準 2.4.3 の達成方法のガイドラインに従います。
障碍に関係なく、すべてのユーザーにとって、適切なリンクテキストによってリンクの目的を明確に示すことは重要です。これによってユーザーは、実際にリンクをたどるかどうかを判断できます。目の見えるユーザーにとって、ページ上に複数のリンクがある場合(特に、テキストが多いページの場合)、意味のあるリンクテキストは、ターゲットページの機能をより明確に示すので、非常に有用です。支援テクノロジーのユーザーは、1 つのページにすべてのリンクのリストを生成できるので、リンクテキストが独特でしかも情報量が多ければ、コンテキストからリンクテキストをより簡単に理解できます。ただし、目の見えるユーザーでも認知機能に障碍がある場合は、リンク先を正確に説明する十分な情報をリンクが提供しないと、当惑する可能性があります。
何よりも、リンクの目的がリンクのテキスト内で明確に説明されていることを確認してください。
リンクは複数ページにわたって一貫した表現にする必要があります。ナビゲーションバーの場合は特にそうです。例えば、特定のページへのリンクの名前を、あるページで「パブリケーション」とする場合は、一貫性を保つために、他のページでもそのテキストを使用します。
本ドキュメントの執筆時点では、ページに表示される類似リンクがリンク先に関する一意の情報を提供するようにタイトル属性を使用するには、問題がいくつかあります(例えば、「続きを読む」は多くの場合、様々なリンク先を指します)。
タイトル属性を使用してリンクにコンテキストを追加することはできますが、制限事項に注意し、また、適切なリンクテキストの代替としては使用しないでください。
リンクが画像で構成されている場合は、画像の代替テキストでリンク先を説明してください。例えば、本棚の画像をある人物のパブリケーションへのリンクとして設定している場合は、代替テキストを「John Smith のパブリケーション」のようにします。「本棚」とはしないでください。
また、画像要素に加えて、リンクの目的を説明するテキストがリンクアンカーに含まれている(画像と並んでテキストが表示されている)場合は、空の alt 属性を使用して画像を表します。
<a href="publications.html">
<img src = "bookshelf.jpg" alt = "" />
John Smith’s publications
</a>
上記のスニペットは図です。画像コンポーネントを使用することをお勧めします。
追加のコンテキストを必要とせずにリンクの目的を識別するリンクテキストを提供することが望ましいものの、これが常に可能とは限らないことがわかっています。コンテキストのないリンクは、次の場合に使用できます。HTML の例は、達成基準 2.4.4 の達成方法を参照してください。
1 つのページ上に複数のリンクがある場合(各リンクで提供される指示が複雑だが必要な詳細である場合)は、代替バージョンの Web ページを提供することが妥当と言えます。代替バージョンは、まったく同じコンテンツを表示する一方で、リンクテキストはそれほど詳細ではないものを用意します。
また、スクリプトを使用して、リンク自体では最低限のテキストを使用し、ページの上部に向かって配置されている適切なコントロールをアクティベートするとリンクテキストが展開され、詳細が表示されるように指定することもできます。同様に、CSS を使用して、目の見えるユーザーに対しては完全なリンクを非表示にし、スクリーンリーダーユーザーに対しては引き続き完全に画面に出力する方法があります。これはこのドキュメントの範囲外ですが、これを行う方法について詳しくは、詳細情報 - リンクの目的(コンテキスト内)(2.4.4)を参照してください。
この達成基準の目的は、ユーザーがニーズに最も合った方法でコンテンツを見つけられるようにすることです。ユーザーは、複数の手段のなかから、より使いやすい、または分かりやすい手段を見つけられます。
小規模サイトでも、何らかの形で方向付けの手段を提供する必要があります。3 ~ 4 ページのサイトで、すべてのページがホームページからリンクされている場合、ホームページ上のリンクがサイトマップとしても機能するため、ホームページと各ページ間で相互にリンクを提供するだけで十分です。
達成基準 2.4.5 の達成方法のガイドラインに従います。
この達成基準の目的は、ユーザーが Web ページに含まれる情報と、その情報の編成方法を理解できるようにすることです。見出しが明確で説明的な場合、ユーザーは探している情報が見つけやすくなり、コンテンツの異なる部分との関係を理解しやくなります。説明的なラベルは、コンテンツ内の特定のコンポーネントの識別に役立ちます。
達成基準 2.4.6 の達成方法のガイドラインに従います。
この達成基準の目的は、キーボードのフォーカスがある要素を知るのに役立ちます。
複数の要素の中で、キーボードフォーカスがある要素を知ることが可能である必要があります。画面に操作可能なキーボードコントロールが 1 つしかない場合、視覚的なデザインは操作可能なキーボードアイテムを 1 つだけ表示するので、達成基準は満たされます。
達成基準で「操作モード」と表されている場合、これは、フォーカスインジケーターが常に表示されるとは限らないプラットフォームを考慮するためです。 ほとんどの場合、操作モードは 1 つだけなので、この達成基準が適用されます。
達成基準 2.4.7 の達成方法のガイドラインに従います。
原則 3:理解可能 - 情報およびユーザーインターフェイスの操作は理解可能でなければならない。
ガイドライン 3.1 読みやすさ:テキストのコンテンツを読みやすく理解可能にすること。
この達成基準の目的は、テキストおよびその他の言語コンテンツが正確にレンダリングされることを確認することです。スクリーンリーダーユーザーにとっては、これによってコンテンツが正しく発音され、一方で視覚的なブラウザーでは特定の言語セットが正確に表示されます。
この達成基準を満たすために、ページ上部の lang
要素内で <html>
属性を使用して、Web ページのデフォルト言語を識別できます。次に例を示します。
英語で書かれているページの場合、<html>
要素は次のようになります。
<html lang = "en">
一方、スペイン語でレンダリングされるページの場合は、次の標準規格を採用します。
<html lang = "es">
AEM では、ページのデフォルト言語はページ作成時に設定されますが、ページプロパティの編集時に変更することもできます。
AEM では、ルート言語のバリエーションに応じてさらに微調整を行うことができます。例えば、アメリカ英語の場合は en-us、イギリス英語の場合は en-gb、カナダ英語の場合は en-ca などと指定します。この詳細レベルは支援テクノロジーにとっては不必要な場合が多いですが、ページコンテンツの地域的なバリエーションに使用することができます。
この達成基準の目的は、ページの言語の達成基準と類似していますが、単一のページに複数言語のコンテンツ(引用や一般的でない外来語)が含まれる Web ページに適用される点が異なります。
この達成基準を適用するページでは、以下のことが可能です。
lang
属性を使用して、コンテンツの言語の変更を識別できます。例えば、ドイツ語(ISO 639-1 コード"de")の引用は、次のように表示されます。
<blockquote cite = "John F. Kennedy" lang = "de">
<p>Ich bin ein Berliner</p>
</blockquote>
blockquote は、標準のインスタンスではサポートされていません。この機能をサポートするためのカスタムコンポーネントを開発できます。
同様に、span
要素を次のように使用した場合は、一般的でない外来語やフレーズをブラウザーで正しくレンダリングできます。
<p>The only French phrase I know is <span lang = "fr">je ne sais quoi</code>.</p>
様々な言語の名前や都市名を含める場合や、デフォルトの言語で一般的になった外来語やフレーズ(英語の schadenfreude など)を使用する場合は、この達成基準に従う必要はありません。
span 要素を適切な言語で追加するには、RTE のソース編集モードで、上記の内容になるように HTML マークアップを手動で編集します。または、システム管理者が lang
属性を RTE に含めることもできます(追加の HTML 要素および属性のサポートの追加を参照)。
ガイドライン 3.2 予測可能:Web ページを予測可能な方法で表示および操作できるようにします。
これは、Web ページの外観と動作の一貫性を確保することを目的としています。
この達成基準の目的は、訪問者がドキュメント内を移動する際に、機能が予測可能であることを保証することです。フォーカスを受け取ったときにイベントをトリガーできるコンポーネントは、コンテキストを変更してはなりません。コンポーネントがフォーカスを受け取った場合のコンテキストの変更例を次に示しますが、これらに限定されません。
フォーカスは、キーボード(例:タブキーからコントロールに移動)またはマウス(例:テキストフィールドをクリック)を介してコントロールに移動する場合もあります。コントロールの上にマウスを移動しても、スクリプティングによってこの動作が実装されていない限り、フォーカスは移動しません。一部の種類のコントロールでは、コントロールをクリックすると、そのコントロール(ボタンなど)もアクティブになり、コンテキストの変更が開始される場合があります。
達成基準 3.2.1 の達成方法のガイドラインに従います。
この達成基準の目的は、データの入力やフォームコントロールの選択を確実に予測可能な結果にすることです。ユーザインターフェイスコンポーネントの設定を変更すると、コントロールの一部の側面が変更され、ユーザーが操作しなくなったときに保存されます。したがって、チェックボックスをオンにしたり、テキストフィールドにテキストを入力したり、リストコントロールで選択したオプションを変更したりすると、設定は変わりますが、リンクやボタンはアクティブになりません。コンテキストの変更は、変更を容易に認識できないユーザーや、変更によって注意力が散漫になりやすいユーザーを混乱させる可能性があります。コンテキストの変更は、ユーザーのアクションに応じてそのような変更が行われることが明らかな場合にのみ適切です。
達成基準 3.2.2 の達成方法のガイドラインに従います。
この達成基準の目的は、一連の Web ページ内で繰り返されるコンテンツを操作し、特定の情報や機能を複数回見つけ出す必要があるユーザーに対して、一貫した表示とレイアウトの使用を促すことです。視覚障碍を持つ人が画面の表示比率を使用して一度に画面の一部のみを表示する場合は、繰り返されるコンテンツをすばやく見つけ出すために、よく視覚的なキューやページの境界を使用します。繰り返されるコンテンツを同じ順序で表示することは、デザイン内の空間記憶や視覚的キューを使用して繰り返されるコンテンツを見つけ出す視覚的ユーザーにとっても重要です。
この節で使用される「同じ順序」というフレーズは、サブナビゲーションメニューを使用できないとか、またはセカンダリナビゲーションやページ構造のブロックを使用できないという意味ではありません。この達成基準は、Web ページ上で繰り返し使用されるコンテンツを操作するユーザーの支援として、探しているコンテンツの場所を予測し、再度目に触れたときにその場所をより迅速に見つけ出せることを目的としています。
ユーザーは、アダプティブユーザーエージェントを使用するか、環境設定を設定して、ユーザーにとって最も役立つ方法で情報が表示されるように、順序を変更することもできます。
達成基準 3.2.3 の達成方法のガイドラインに従います。
この達成基準の目的は、一連の Web ページ内で繰り返し表示される機能コンポーネントを一貫して識別することです。Web サイトの操作時にスクリーンリーダーを使用するユーザーが取る戦略は、異なる Web ページに表示される機能になじみがあるかどうかに大きく依存しています。違う Web ページで、同じ機能に異なるラベルが付いている(または、より一般的には、アクセシブルな名前が異なる)場合、そのサイトは非常に使いにくくなります。また、認知機能に障碍を持つ人にとっては、混乱を招き、認知負荷が高まる可能性があります。したがって、一貫したラベル付けが役立ちます。
この一貫性は、代替テキストにも及びます。アイコンやその他のテキスト以外の項目が同じ機能を持つ場合は、代替テキストも一貫性を保つ必要があります。
Web ページ上に 2 つのコンポーネントがあり、両方のコンポーネントが、一連の Web ページ内の別のページ上にあるコンポーネントと同じ機能を持つ場合は、3 つすべてのコンポーネントの一貫性が維持される必要があります。したがって、同じページ上の 2 つは一貫性を持つことになります。
1 つの Web ページ内で一貫性を保つことは望ましく、ベストプラクティスでもありますが、3.2.4 では、複数ページにわたって何かが繰り返される、一連の Web ページ内の一貫性のみに対応します。
達成基準 3.2.4 の達成方法のガイドラインに従います。
ガイドライン 3.3 入力支援:利用者の間違いを防ぎ、修正を支援すること。
この達成基準の目的は、エラーが発生したことをユーザーが確実に認識し、何が間違っているかを判断できるようにすることです。エラーメッセージは、できる限り具体的に記述する必要があります。フォームの送信に失敗した場合に、フォームを再表示してエラーのあるフィールドを示すことは、一部のユーザーにとって、エラーの発生を認識するのに十分ではありません。例えば、スクリーンリーダーを使用するユーザーは、インジケーターのひとつに遭遇するまでエラーがあったことに気づきません。エラーインジケーターに遭遇する前に、ページが単に機能していないと考えて、フォームを完全に破棄する可能性があります。WCAG の定義によると、入力エラーは、ユーザーから提供される受け入れられない情報です。これには以下が含まれます。
Web ページで必要とされるが、ユーザーによって省略された情報、またはユーザーが提供するが、必要なデータ形式または許可されている値に該当しない情報。次に例を示します。
達成基準 3.3.1 の達成方法のガイドラインに従います。
フォームへの入力を支援する説明を提供することは、インターフェイスを使いやすくするための基本です。このような説明は、視覚や認知機能に障害のあるユーザーがフォームのレイアウトや、フォームの特定のフィールドで提供されているデータの種類を理解する特に役立ちます。
AEM WKND デモプロジェクトでは、テキストフィールドなどのフォームコンポーネントをページに追加すると、デフォルトのラベルが追加されます。このデフォルトのタイトルはコンポーネントのタイプによって異なります。そのフィールドの編集ダイアログの「タイトルとテキスト」タブに、独自のタイトルを追加できます。各フォームコンポーネントに関連付けられているデータをユーザーが理解できるようなラベルを指定することが重要です。
この「タイトル」フィールドは、支援テクノロジーで使用できるラベルを提供するので、フィールド要素用に使用する必要があります。フィールドの横のテキストにラベルを書き込むだけでは不十分です。
一部のフォームコンポーネントでは、「タイトルを非表示にする」チェックボックスを使用してラベルを非表示にすることもできます。この方法で非表示にしたラベルは、支援テクノロジーでは引き続き使用できますが、画面には表示されません。状況によっては、この方法で十分ですが、通常は、可能な限り目に見えるラベルを含めることをお勧めします。画面の非常に狭い部分(フィールド 1 つずつ)を見ていて、ラベルによってフィールドを正確に識別できることを必要としているユーザーがいる可能性もあるからです。
画像ボタンが使用されている場合(WKND プロジェクトの画像ボタンコンポーネントなど)、編集ダイアログの「タイトルとテキスト」タブの「タイトル」フィールドには、ラベルではなく、画像の代替テキストが実際に表示されます。以下の例では、Submit
というテキストを持つ画像に、Submit
という代替テキストが、編集ダイアログの「タイトル」フィールドを使用して追加されています。
ラジオグループなど、関連するコントロールのグループがある WKND プロジェクトでは、個々のコントロールだけでなく、グループにタイトルが必要になる場合があります。AEM でラジオボタンのセットを追加する場合、「タイトル」フィールドにはこのグループタイトルが表示されますが、個々のタイトルはラジオボタン(項目)の作成時に指定されます。
ただし、グループタイトルとラジオボタン自体との間には、プログラム的な関連付けはありません。テンプレートエディターでは、必要な fieldset
タグと legend
タグでタイトルを囲んで、この関連付けを作成する必要があります。この処理は、ページのソースコードを編集することによってのみ可能です。また、システム管理者がこれらの要素のサポートを追加して、フィールドのプロパティダイアログに表示させることもできます(追加の HTML 要素および属性のサポートの追加を参照)。
データを特定の形式で入力する必要がある場合は、ラベルテキストでそのことを明確に示します。例えば、日付を DD-MM-YYYY
という形式で入力する場合は、ラベルの一部としてこのことを具体的に示します。つまり、スクリーンリーダーユーザーがフィールドに遭遇したとき、形式に関する追加情報も含めて、ラベルが自動的に読み上げられるということです。
入力が必須のフォームフィールドがある場合は、「必須」という単語をラベルの一部として使用して、このことを明確に示します。AEM では、必須のフィールドにはアスタリスクが追加されますが、「required
」(必須)という単語をラベル自体に含めることが理想的です(編集ダイアログの「タイトル」フィールドを使用)。
ラベルの配置も、適切なフィールドを見つけるうえで役立つので重要です。このことは、複雑なフォームの場合に特に重要です。次の規則に従います。
機能がごく限られている簡単なフォームでは、「Submit
」ボタンに適切にラベルを付けると、隣のフィールド(「Search
」など)のラベルとしての役割を果たすことができます。これは、ラベルテキストのスペースを見つけることが困難な可能性のある場合に便利です。
この達成基準の目的は、入力エラーの修正に必要な適切な提案がユーザーに確実に届くようにすることです。WCAG の入力エラーの定義は、「ユーザーが提供する情報で、受け入れられないもの」というものです。受け入れられない情報の例としては、必要であるがユーザーによって省略された情報や、ユーザーが提供するが、必要なデータ形式または許容される値に該当しない情報などがあります。
達成基準 3.3.1 はエラーの通知を提供します。しかし、認知機能に障碍を持つユーザーは、エラーの修正方法を理解するのが難しい場合があります。視覚に障碍を持つユーザーは、エラーの修正方法を正確に理解できない場合があります。フォームの送信に失敗した場合、エラーの発生を認識しているにもかかわらず、エラーの修正方法が不明なことから、ユーザーはフォームを放棄する可能性があります。
コンテンツ作成者によるエラーの説明の提供や、ユーザーエージェントによる、テクノロジーに特化した、プログラム的に決定された情報に基づく、エラーの説明の提供が可能です。
達成基準 3.3.3 の達成方法のガイドラインに従います。
達成基準 3.3.4
レベル AA
エラー回避(法務、金融、データ):ユーザーに関する法的コミットメントや金融トランザクションの発生、データストレージシステム内にある、ユーザーが自分で制御可能なデータ変更や削除、またはユーザーテストの応答を送信する Web ページでは、次のうち少なくとも 1 つを満たしている。
この達成基準の目的は、障碍を持つユーザーが、元に戻せない操作を実行する際に、誤りが原因で重大な結果が生じるのを回避できるよう支援することです。例えば、返金不能な航空券を購入したり、証券会社の口座で株式購入注文を送信したりすると、深刻な結果をもたらす金融取引となります。航空便の日付を誤った場合、交換できない間違った日付のチケットを購入することになります。購入する株式の数を間違えた場合は、意図した数よりも多くの株式を購入する可能性があります。どちらのエラーも、すぐに実行され、後で変更することができないトランザクションを伴うので、大きな犠牲を払うことになりかねません。同様に、データベースに保存された、後でアクセスする必要があるデータ(例えば旅行サービスの Web サイトに保存されている旅行プロファイル全体など)を誤って変更または削除してしまうと、回復不能なエラーとなる可能性があります。「ユーザーが自分で制御可能」なデータの変更または削除を参照する場合、この達成基準の意図は、ファイルやレコードの削除など、大量のデータの損失を防ぐことです。保存コマンド、またはドキュメント、レコード、その他のデータの単純な作成や編集を実行するたびに、確認を要求するものではありません。
障碍を持つユーザーは、間違える可能性が高くなる場合があります。読字障碍を持つユーザーは数字や文字の位置を間違えることがあり、運動障碍を持つ利用者は誤ってキーを押してしまう可能性があります。アクションを取り消す機能を提供すると、ユーザーは重大な結果を招く可能性のある誤りを修正できます。また、入力内容を確認して修正できるようにすることで、重大な結果につながる行動を取ってしてしまう前に、ユーザーがミスに気づくことができるようになります。
ユーザーが自分で制御可能なデータとは、ユーザーが意図した行動によって変更および/または削除できる、ユーザーが閲覧可能なデータのことです。ユーザーがこれらのデータを制御するケースの例としては、ユーザーアカウントの電話番号と住所の更新や、Web サイトから過去の請求書レコードの削除などがあります。インターネットログや検索エンジンの監視データなど、ユーザーが直接表示又は情報交換できないデータは指しません。
達成基準 3.3.4 の達成方法のガイドラインに従います。
原則 4:堅牢 - コンテンツは、支援テクノロジーを含む様々なユーザーエージェントが確実に解釈できるように十分に堅牢でなければならない。
ガイドライン 4.1 互換性:支援テクノロジーを含む、現在および将来のユーザーエージェントとの互換性を最大化します。
支援テクノロジーを含む、現在および将来のユーザーエージェントとの互換性を最大化します。
この達成基準の目的は、支援テクノロジーを含むユーザーエージェントがコンテンツを正確に解釈および解析できるようにすることです。コンテンツをデータ構造に解析できない場合、異なるユーザーエージェントがそのコンテンツを異なる方法で表示する、または完全に解析できない可能性があります。一部のユーザーエージェントは、コード化が不完全なコンテンツをレンダリングする際に、「修復テクニック」を使用します。
修復技術はユーザーエージェントによって異なるので、ユーザーエージェントの正式な文法で定義された規則に従ってコンテンツが作成されない限り、コンテンツが正確にデータ構造に解析される、または支援テクノロジーなどの特殊なユーザーエージェントが正しくレンダリングされることを、作成者は前提にすることはできません。マークアップ言語では、要素と属性の構文のエラーと、正しくネストされた開始および終了タグの提供に失敗すると、エラーが発生し、ユーザーエージェントがコンテンツを確実に解析できなくなります。したがって、達成基準では、正式な文法規則の規則のみを使用して内容を解析できる必要があります。
達成基準 4.1.1 の達成方法のガイドラインに従います。
この達成基準の目的は、支援テクノロジー(AT)がコンテンツ内のユーザーインターフェイスコントロールのステータスに関する情報を収集、アクティブ化(設定)し、最新の状態に保つことです。
アクセシブルなテクノロジーの標準的なコントロールを使用する場合、このプロセスは簡単です。仕様に従ってユーザーインターフェイス要素を使用することで、この規定の条件が満たされます。(以下の達成基準 4.1.2 の例を参照)。
ただし、カスタムコントロールを作成した場合、または(コードまたはスクリプト内の)インターフェイス要素が通常とは異なる役割および/または機能を持つようにプログラムされている場合は、支援テクノロジーに重要な情報を提供し、支援テクノロジーで制御できるように、追加の対策を講じる必要があります。
ユーザインターフェイスコントロールの特に重要な状態は、フォーカスがあるかどうかです。コントロールのフォーカス状態はプログラムで判定でき、フォーカスの変更に関する通知はユーザーエージェントや支援テクノロジーに送られます。ユーザーインターフェイスコントロールの状態のその他の例としては、チェックボックスやラジオボタンが選択されているかどうか、または折りたたみ可能なツリーやリストノードが展開されているか折りたたまれているかなどがあります。
達成基準 4.1.2 の達成方法のガイドラインに従います。