Oracle® Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド 11gリリース1(11.1.1.9.0) B52029-12 |
|
![]() 前 |
![]() 次 |
この章では、キーボードのショートカット、およびコンポーネント名や状態に関するテキストの説明を含むアクセシビリティ・サポートを、ADF Facesコンポーネントに追加する方法を説明します。部分ページ・レンダリング、スクリプト、スタイル、特定ページおよびナビゲーション構造を使用するADFページのアクセシビリティ・ガイドラインについても説明されています。
この章では、次の項目について説明します。
アクセシビリティとは、弱視や全盲、難聴またはその他の身体的な制限などの障害を持つユーザーが、アプリケーションを使用できるようにすることです。つまり、マウスなし(キーボードのみ)で使用でき、全盲または弱視のユーザーはスクリーン・リーダーを使用でき、音、色またはアニメーションやタイミングに依存せずに使用できるアプリケーションを作成することです。
Oracleソフトウェアには、米国の508条およびWeb Content Accessibility Guidelines (WCAG) 1.0 AA標準が適用されています。これらの標準は、http://www.oracle.com/accessibility/standards.html
で解説されています。
コンポーネントのADF Facesのアクセシビリティ・ガイドライン、ページやナビゲーション構造は便利ですが、アクセシビリティ標準に関する理解を深めることや、支援技術を使用したアクセシビリティのテスト実行のかわりにはなりません。アプリケーションの作成時に、次の基準が満たされていることを確認します。
感覚的な特徴の達成基準
詳細は、http://www.w3.org/TR/UNDERSTANDING-WCAG20/Overview.html#contents
にあるSuccess Criterion 1.3.3 [Sensory Characteristics]の項を参照してください。
画像化されたテキストの達成基準
詳細は、http://www.w3.org/TR/UNDERSTANDING-WCAG20/Overview.html#contents
にあるSuccess Criterion 1.4.5 [Images of Text]の項を参照してください。
視覚的に認識可能なフォーカスの達成基準
詳細は、http://www.w3.org/TR/UNDERSTANDING-WCAG20/Overview.html#contents
にあるSuccess Criterion 2.4.7 [Focus Visible]の項を参照してください。
フォーカスを受け取る要素の達成基準
詳細は、http://www.w3.org/TR/UNDERSTANDING-WCAG20/Overview.html#contents
にあるSuccess Criterion 3.2.1 [On Focus]の項を参照してください。
機能コンポーネントの一貫した識別性の達成基準
詳細は、http://www.w3.org/TR/UNDERSTANDING-WCAG20/Overview.html#contents
にあるSuccess Criterion 3.2.4 [Consistent Identification]の項を参照してください。
クライアント側のスクリプト、特に非同期のJavaScriptおよびXML (AJAX)を使用した場合に生じていたフレームワークとプラットフォームのさらなる問題は、オラクル社のアクセシビリティ戦略で対応しています。
ADF Facesのユーザー・インタフェース・コンポーネントには、視覚的および身体的な障害のあるユーザーのために、組込みのアクセシビリティ・サポートが用意されています。スクリーン・リーダーのような非視覚的なメディアへのレンダリングを行うWebブラウザなどのユーザー・エージェントにより、コンポーネントのテキスト説明が読み上げられ、障害を持つユーザーに有益な情報が提供されます。アクセス・キー・サポートは、キーボードのみを使用してコンポーネントやリンクにアクセスする代替の方法を提供します。ADF Facesのアクセシビリティ監査ルールにより、アクセス可能なHTMLマークアップを使用して、アクセス可能なイメージ、表、フレーム、フォーム、エラー・メッセージおよびポップアップ・ウィンドウの作成が指示されています。
提供されているコンポーネント、ページやナビゲーション構造に対するADF Facesのアクセシビリティ・ガイドラインに従うのは便利ですが、アクセシビリティ標準に関する理解を深めることや、支援技術を使用したアクセシビリティのテスト実行のかわりにはなりません。
ADF Facesには、2つのレベルのアプリケーション・アクセシビリティ・サポートが、<accessibility-mode>
要素を使用してtrinidad-config.xml
ファイルに構成されています。<accessibility-mode>
に使用可能な値は次のとおりです。
default
: デフォルトでは、ADF Facesにより、豊富なユーザー・インタフェース相互作用を持ち、キーボードからもアクセスできるコンポーネントが生成されます。デフォルト・モードでは、スクリーン・リーダーはすべてのADF Facesコンポーネントにアクセスできるとはかぎりません。視覚障害のあるユーザーがスクリーン・リーダーを使用している場合、screenReader
モードの使用をお薦めします。
screenReader
: ADF Facesにより、スクリーン・リーダーと使用するために最適化されるコンポーネントが生成されます。screenReader
モードにより、視覚障害を持つユーザー向けの表示が容易になりますが、目の見える(視覚障害のない)ユーザーにとっては表示の品質が低下します。
ユーザーが目的のタイプのアクセシビリティ・サポートを必要に応じて選択できるように、アプリケーションで前述のアクセシビリティ・サポート間の切り替え機能を提供することをお薦めします。
@accessibility-profile
要素を使用して、スタイルシートでより詳細にアクセシビリティ・プリファレンスを定義することもできます。また、trinidad-config.xml
ファイルで、アクセシビリティ・プロファイル・オプション(high-contrast
とlarge-fonts
のいずれかまたは両方)を指定することもできます。詳細は、ADF Facesスキンに関する項を参照してください。
<accessibility-profile>
に使用可能な値は次のとおりです。
high-contrast
: ADF Facesでは高コントラストに適した視覚的コンテンツを生成できます。高コントラスト・モードは、高コントラスト機能を有効にしているオペレーティング・システムまたはブラウザとの互換性をADF Facesアプリケーションに持たせることを目的としています。たとえば、ADF Facesでは、高コントラスト・モードでの背景イメージおよび背景色の使用を変更し、視覚情報の損失を防ぎます。高コントラスト・モードは、ブラウザまたはオペレーティング・システムの高コントラスト・モードと組み合わせて使用するとより効果的です。また、高コントラスト・モードを大きいフォント・モードと一緒に使用しても効果的な場合があります。
large-fonts
: ADF Facesではブラウザ・ズームに適したコンテンツを生成できます。デフォルト・モードでは、ほとんどのテキストと多数のコンテナのサイズは固定されていて、一貫性のある確定した外観が提供されます。大きいフォント・モードでは、テキストおよびコンテナのサイズは拡大縮小が可能です。これによって、ADF Facesはより大きいフォント・サイズが設定されているブラウザと互換性を持ち、ブラウザのズーム機能に対応できます。大きいフォント・モードまたはブラウザのズーム機能を使用していない場合、大きいフォント・モードを無効にする必要があることに注意してください。また、大きいフォント・モードを高コントラスト・モードと一緒に使用しても効果的な場合があります。
注意: <accessibility-mode> および<accessibility-profile > 要素は、ELにより、ユーザー固有のプリファレンスが含まれるセッション有効範囲のマネージドBeanにバインドされる必要があります。 |
JDeveloperで、ADF FacesコンポーネントをJSFページへ初めて追加すると、trinidad-config.xml
の基礎ファイルが/WEB-INF
ディレクトリに自動的に作成されます。ファイルは、JSF式言語(EL)または静的値を使用して要素プロパティを定義できる単純なXML構造です。ファイル内の要素の順序は関係ありません。XMLファイルを直接編集するか、構造ウィンドウを使用することで、アクセシビリティ・サポートを構成できます。
JDeveloperのtrinidad-config.xmlでアクセシビリティ・サポートを構成する手順:
「アプリケーション・ナビゲータ」で、trinidad.xmlをダブルクリックします。
XMLエディタで、要素名<accessibility-mode>
およびアクセシビリティ・サポートの値(default
、screenReader
またはinaccessible
)を入力します。次に例を示します。
<accessibility-mode>screenReader</accessibility-mode>
このコードでは、アプリケーションのアクセシビリティ・サポートがスクリーン・リーダー・モードに設定されています。
要素名<accessibility-profile>
およびアクセシビリティ・プロファイル値(high-contrast
、large-fonts
)を入力します。次に例を示します。
<!-- Enable both high-contrast and large-fonts content --> <accessibility-profile>high-contrast large-fonts</accessibility-profile>
このコードは、高コントラストおよび大きいフォントを使用するようにアプリケーションのプロファイル・サポートを設定します。
または、構造ウィンドウを使用して値を入力できます。
アプリケーション・ナビゲータで、trinidad-config.xmlファイルを選択します。
構造ウィンドウで、XMLファイルのルート要素を右クリックして「内部に挿入」メニュー項目を選択し、<accessibility-mode>要素をクリックします。
構造ウィンドウで新しく挿入された要素をダブルクリックし、プロパティ・インスペクタを開きます。値を入力するか、ドロップダウン・リストから1つ選択します。
trinidad-config.xml
ファイルの構成後、プログラムから、あるいはJSF EL式を使用してプロパティ値を取得できます。
たとえば、次のコードでは、アクセシビリティ・モードが明示的に設定されていない場合は、何も返されません。
String mode=ADFFacesContext.getCurrentInstance().getAccessibilityMode;
このEL式の例では、アクセシビリティ・モードが明示的に設定されていない場合は、何も返されません。
<af:outputText value="*#{requestContext.accessibilityMode}"/>
コンポーネント固有のアクセシビリティのガイドラインは、22.3.1項「ADF Facesコンポーネントのアクセシビリティ・ガイドライン」に説明されています。ガイドラインには、関連のプロパティの説明が例やヒントとともに含まれています。ADF Facesのアクセシビリティ・ルールに準拠していることを監査する方法の詳細は、22.5項「アクセシビリティ監査ルールの実行」を参照してください。
af:inputText
、af:commandButton
およびaf:goLink
など、ADF Facesの入力、コマンドおよび実行コンポーネントに対するアクセス・キー・サポートには、ラベルの定義およびキーボード・ショートカットの指定が含まれます。[Tab]キーを使用してWebアプリケーションのあるコントロールから次のコントロールへ移動することが可能ですが、キーボード・ショートカットはより便利で効率的です。
コンポーネントのアクセス・キーを指定するには、コンポーネントのaccessKey
属性を、コンポーネントに簡単にアクセスするために使用するキーボード文字(またはニーモニック)に設定します。属性は、プロパティ・インスペクタ、または&
エンコーディングを使用してページ・ソースで設定できます。
同じアクセス・キーを複数のコンポーネントにバインドできます。同じアクセス・キーが同一ページ内の複数の場所に表示される場合、レンダリング・エージェントは同じキーでアクセスできるコンポーネントを巡回します。つまり、アクセス・キーが押されるたびに、フォーカスがコンポーネント間を移動します。最後のコンポーネントに到達すると、フォーカスは最初のコンポーネントに戻ります。
af:goButton
およびaf:goLink
コンポーネントでアクセス・キーを使用すると、一部のブラウザではアクセス・キーがすぐにアクティブ化されます。ブラウザによっては、ページの2つ以上の実行コンポーネントに同じアクセス・キーが割り当てられている場合、同じアクセス・キーでアクセスできるコンポーネントを巡回せずに、最初のコンポーネントがアクティブ化されます。
アクセス可能なページおよびナビゲーション構造を開発するには、アクセス可能なページの作成に関する項で説明されている追加のアクセシビリティ・ガイドラインに従います。
アクセス可能なADF Facesコンポーネントを開発するには、表22-1に説明されているガイドラインに従います。リストされていないコンポーネントには、アクセシビリティ・ガイドラインはありません。
注意: アクセシビリティ・ガイドラインでlabel プロパティが参照される場合、可能な場合はlabelAndAccessKey プロパティが使用され、これが推奨オプションです。
特に記載がないかぎり、次のようにして、ADF Facesの入力および選択のコントロールにもラベルを設定できます。
|
表22-1 ADF Facesコンポーネントのアクセシビリティ・ガイドライン
コンポーネント | ガイドライン |
---|---|
|
すべての |
|
すべての |
|
|
|
|
|
|
|
|
|
|
|
|
|
複雑な説明が必要なイメージには、 |
|
|
|
|
|
|
|
ADF Facesの入力または選択コントロールへのラベル設定にこのコンポーネント使用する場合は、 |
|
アプリケーションにマルチメディア・コンテンツが含まれている場合、そのメディアに対するすべてのアクセシビリティ要件が満たされていることを確認します。 いくつか例を挙げます。
|
|
|
|
ADF Facesの入力または選択コントロールへのラベル設定にこのコンポーネント使用する場合は、 |
|
22.4.4項「ページ構造およびナビゲーションの使用方法」を参照してください。 |
|
|
|
コンテンツを更新するためにポーリングを使用する場合は、エンド・ユーザーが間隔を制御できるようにするか、ポーリングではなく更新を明示的に開始できるようにします。 |
|
次のプロパティを指定します。
|
|
|
a |
|
|
|
|
|
|
|
|
|
|
|
|
マウスでアクセスできるすべてのポップアップに対して、キーボードからもアクセスできることを確認します。たとえば、ノート・ウィンドウを focusまたはblurイベント・タイプでポップアップを表示しないでください。これを行うと、キーボードのみを使用するユーザーによるアプリケーションの使用が困難になりますこれらが使用可能なイベント・タイプである場合、 |
|
すべての表の列に列ヘッダーを作成する必要があります。 |
WebアプリケーションでADF Faces表コンポーネントを使用している場合、1つの列をスクリーン・リーダー・モード用の行ヘッダーとして指定する必要があります。その行ヘッダーは、スクリーン・リーダー・ソフトウェアによって、エンド・ユーザーが選択した行を告げるために使用されます。通常は、複数の選択ができる行ヘッダーとして1つの列が使用されますが、行ヘッダーとして複数の列をマークすることもできます。複数の列を行ヘッダーとしてマークすると、それらは表の初期列として表示され、固定されます。
場合によっては、表示目的で、行ヘッダーを表示しないこともあります。そのような場合には、表の1つの列をrowHeader
属性がunstyled
に設定されているように定義する必要があります。スクリーン・リーダー・モードでは、unstyled
行ヘッダーを持つ表またはツリー表コンポーネントは、displayIndex
が0
に設定された開始位置に移動し、固定されます。デフォルト・モードでは、unstyled
行ヘッダー列を持つ表またはツリー表は、開始位置に移動せず、固定されずに、行ヘッダーのCSSスタイルなしでレンダリングされます。
アクセス可能なADFデータ視覚化コンポーネントを開発するには、表22-2で説明されているアクセシビリティ・ガイドラインに従います。リストされていないコンポーネントには、アクセシビリティ・ガイドラインはありません。
表22-2 ADFデータ視覚化コンポーネントのアクセシビリティ・ガイドライン
コンポーネント | ガイドライン |
---|---|
|
|
|
次のグラフの子コンポーネントをページに追加する際に、グラフは自動的にこれらのコンポーネントの
使用する場合、次のグラフ参照オブジェクトに対して、
|
|
|
|
スクリーン・リーダー・モードの場合、ピボット・テーブルのインスタンスがグラフ・コンポーネントのかわりになるため、エンド・ユーザーは標準カーソル・キーを使用して、データ内を移動できます。 スクリーン・モードでは、グラフ・コンポーネントの次の視覚化機能はサポートされません。
スクリーン・モードでは、グラフ・コンポーネントの次の対話機能はサポートされません。
|
|
サンバーストおよびツリーマップの場合、 スクリーン・リーダー・モードの場合、ツリー表コンポーネントのインスタンスがコンポーネントのかわりになるため、エンド・ユーザーは標準カーソル・キーを使用して、データ内を移動できます。 |
|
スクリーン・リーダー・モードの場合、表コンポーネントのインスタンスがグラフィック・マップ・コンポーネントのかわりになるため、エンド・ユーザーは標準カーソル・キーを使用して、データ内を移動できます。 |
|
スクリーン・リーダー・モードの場合、表コンポーネントのインスタンスが各 テーマ・マップ・インスタンスに複数の |
|
|
|
|
|
|
注意: DVTチャート、サンバーストおよびツリーマップ・コンポーネントはAccessible Rich Internet Applications Suite (WAI-ARIA)技術仕様に準拠します。WAI-ARIAフレームワークでは、ロール、状態およびプロパティを定義し、アクセス可能なウィジェット、ナビゲーションおよび動作を作成します。WAI-ARIAの詳細は、http://www.w3.org/WAI/intro/aria を参照してください。 |
アクセス・キーを定義するコンポーネントのプロパティ・インスペクタで、accessKey
属性フィールドにニーモニック文字を入力します。テキスト、ラベル、値およびニーモニック文字を同時に設定する場合は、関連する属性フィールドのニーモニック文字の前にアンパサンド(&
)文字を使用します。
ADF Facesの入力、コマンドおよび実行コンポーネントにキーボード文字を指定するには、次の4つの属性のいずれか1つを使用します。
accessKey
: コンポーネントへの簡単なアクセスに使用するニーモニック文字の設定に使用します。コマンド・コンポーネントと移動コンポーネントの場合、属性によって指定される文字は、インスタンス・コンポーネントのtext属性の中に存在する必要があり、ない場合は、ADF Facesではコンポーネントにアクセス・キーがないことを視覚的に示す表示は行われません。
例22-1に、af:goLink
コンポーネントのアクセス・キーを文字h
に設定するコードを示します。ユーザーが[Alt]と[H]キーを押すと、コンポーネントのテキスト値がフォーカスされます。
textAndAccessKey
: アンパサンド(&
)文字を使用して、コンポーネントのテキストとニーモニック文字を同時に設定する場合に使用します。JSPXファイルでは、従来のアンパサンド表記は&
です。JSPファイルでは、アンパサンド表記は単純に&
です。プロパティ・インスペクタでは&
のみが必要です。
例22-2に、ボタン・テキストをHome
に指定し、アンパサンド文字の直後の文字であるH
を、af:commandButton
コンポーネントのアクセス・キーに設定するコードを示します。
labelAndAccessKey
: 従来のアンパサンド表記を使用して、入力コンポーネントのlabel
属性およびアクセス・キーを同時に設定する場合に使用します。
例22-3に、ラベルをDate
に指定し、アンパサンド文字の直後の文字であるa
を、af:selectInputDate
コンポーネントのアクセス・キーに設定するコードを示します。
valueAndAccessKey
: 従来のアンパサンド表記を使用して、value
属性およびアクセス・キーを同時に設定する場合に使用します。
例22-4に、ラベルをSelect Date
に指定し、アンパサンド文字の直後の文字であるe
を、af:outputLabel
コンポーネントのアクセス・キーに設定するコードを示します。
アクセス・キー修飾子は、ブラウザおよびプラットフォームによって異なります。すでにブラウザのメニュー・ショートカットとして定義されているアクセス・キーを割り当てると、ADF Facesコンポーネントのアクセス・キーが優先されます。詳細は、特定ブラウザのドキュメントを参照してください。
一部のブラウザでは、空白をアクセス・キーとして使用する場合は、コンポーネントのラベルまたはテキスト・ラベルで空白をビジュアルに表現する方法がないため、[Alt]+[Space]または[Alt]+スペースバーがアクセス・キーであるという情報をユーザーに提供する必要があります。そのようなブラウザの場合は、shortDesc
属性を使用してコンポーネントのツールチップにテキストを指定できます。
異なる言語で表示する必要のあるラベルおよびアクセス・キーは、必要に応じて様々な言語バージョンの表示が可能なリソース・バンドルに格納できます。JSF 1.2で使用可能なJSF構成ファイルに<resource-bundle>
要素を使用すると、各ページにf:loadBundle
タグを使用せずに、アプリケーションのすべてのページに対してリソース・バンドルを使用可能にできます。
ローカライズされたラベルおよびアクセス・キーを定義する手順:
リソース・バンドルをシンプルな.properties
ファイルとして作成し、ラベルおよびアクセス・キーの各言語バージョンを保持します。詳細は、21.3.1項「ベース・リソース・バンドルの定義方法」を参照してください。
faces-config.xml
ファイルに<locale-config>
要素を追加し、アプリケーションのデフォルトおよびサポートされるロケールを定義します。詳細は、21.3.3項「アプリケーションへのロケールおよびリソース・バンドルの登録方法」を参照してください。
各リソース・バンドルの静的テキストの文字列ごとに、キーと値を作成します。キーは、文字列の一意の識別子です。値は、バンドルの言語でのテキスト文字列です。各値で、アクセス・キーとして定義する文字の前にアンパサンド(&
またはamp
)を配置します。
たとえば、次のコードでは、UIStrings.properties
ベース・リソース・バンドルの「Edit」ボタン・フィールドのラベルおよびアクセス・キーが、「Edit」と定義されています。
srlist.buttonbar.edit=&Edit
イタリア語のリソース・バンドルUIStrings_it.properties
では、次のコードにより、変換可能なラベルおよびアクセス・キーが「Aggiorna」と指定されています。
srlist.buttonbar.edit=A&ggiorna
アプリケーションのfaces-config.xml
ファイルに<resource-bundle>
要素を追加します。例22-5に、リソース・バンドルに対するJSF構成ファイルのエントリを示します。
リソース・バンドルを使用するようにアプリケーションを設定すると、リソース・バンドル・キーが式言語(EL)エディタに表示され、宣言的に割り当てられるようになります。
次の例では、UIコンポーネントがリソース・バンドルにアクセスしています。
<af:outputText value="#{res['login.date']}"/
詳細は、第21章「ページの国際化およびローカライズ」を参照してください。
コンポーネント・レベルのアクセシビリティ・ガイドラインに加えて、アプリケーションの設計時には、ページ・レベルのアクセシビリティ・ガイドラインにも従う必要があります。コンポーネント・レベルのガイドラインでコンポーネントの使用方法が決まるのに対して、ページ・レベルのアクセシビリティ・ガイドラインは、全体として、アプリケーションの全体的な設計および機能により関係があります。
ページ・レベルのアクセシビリティ・ガイドラインには次のものがあります。
部分ページ・レンダリングの使用
スクリプトの使用
スタイルの使用
ページ構造およびナビゲーションの使用
WAI-ARIAランドマーク・リージョンの使用
スクリーン・リーダーでは、部分ページ・リクエストで全ページの再読上げは実行されません。部分ページ・レンダリング(PPR)によって、スクリーン・リーダーは、部分アクションを起動したコンポーネントからページの読込みを実行します。したがって、ターゲット・コンポーネントは、部分リクエストを起動するコンポーネントの後に配置します。このようにしないと、更新したターゲットがスクリーン・リーダーに読み込まれません。
たとえば、最も一般的なPPRのユースケースは、マスター/ディテール・ユーザー・インタフェースで、マスター・コンポーネントで値を選択すると、ディテール・コンポーネントのページの一部が置き換えられます。このような場合、ドキュメントの順番において、マスター・コンポーネントが常にディテール・コンポーネントの前にあることが必要です。
スクリーン・リーダーやスクリーン・マグニファイアのユーザーには、部分ページ・レンダリング・アクティビティの結果、どのコンテンツが変更されたかを正確に特定するのが難しい場合があります。ページ内のキー・コンポーネント間の関係を識別するインライン・テキスト説明という形で、説明を用意すると役に立ちます。たとえば、マスター/ディテール・シナリオで、マスター・コンポーネントで行が選択されたため、ディテール・コンポーネントが更新されることを示すテキストがあれば助けになります。または、ページの構造やコンポーネント間の関係を説明するヘルプ・トピックも参考になります。
クライアント側スクリプトは、宣言的ソリューションがあるアプリケーションの問題にはお薦めできないため、最低限にする必要があります。
スクリプトを使用する際には、次のアクセシビリティ・ガイドラインに従ってください。
コンポーネントDOM (Document Object Model)とは直接通信しないでください。
ADF Facesコンポーネントは、DOMが変更されると、スクリーン・リーダーと自動的に同期します。DOMとの直接の通信は許可されていません。
JavaScriptのタイムアウトは使用しないでください。
スクリーン・リーダーは、JavaScriptのsetTimeout()
またはsetInterval()
APIを使用して実装されたタイムアウトへのレスポンスとして行われた変更を確実に追跡するわけではありません。これらのメソッドをコールしないでください。
キーボードに相当するものを用意してください。
マウスを使用できないユーザーもいます。たとえば、キーボードしか使用できないユーザー、または代替の入力デバイスや音声認識ソフトウェアなどのテクノロジを使用するユーザーもいます。クライアント側リスナーを使用して機能を追加する場合、その機能には、デバイスに依存しない方法でアクセスできる必要があります。事実上、これは次のことを意味します。
すべての機能にキーボード・イベントを使用してアクセスできる必要があります。
クリック・イベントは、マウスオーバーやマウスアウトよりも優先される必要があります。
マウスオーバー・イベントまたはマウスアウト・イベントは、クリック・イベントによって使用可能になる必要があります。
フォーカスを変更しないでください。
フォーカスを変更すると、コンテキストが変更されるため、スクリーン・リーダーのユーザーが混乱する可能性があります。アプリケーションではプログラムによるフォーカスの変更を避け、フォーカス・イベントへのレスポンスとしては実行しないでください。また、標準のタブ移動が中断されるため、フォーカス変更へのレスポンスとしてポップアップ・ウィンドウを表示しないでください。
ポップアップ・トリガーを明示的に指定してください。
スクリーン・リーダーは、インライン・ポップアップの起動に自動的には応答しません。スクリーン・リーダー・モードの際に、スクリーン・リーダーがポップアップ・コンテンツを読み上げるよう強制するため、ポップアップ・ウィンドウが開かれた直後に、リッチ・クライアント・フレームワークによりキーボード・フォーカスがそのウィンドウに明示的に移動されます。リンクやボタンなどの明示的なポップアップ・トリガーを用意するか、キーボードやスクリーン・リーダーでアクセスできるその他の方法で同じ情報を使用できる必要があります。
ADF Facesコンポーネントはすでにスタイルが設定されており、変更の必要はありません。Cascading Style Sheet (CSS)を使用して直接デフォルトの外観を変更する場合、次のアクセシビリティ・ガイドラインに従う必要があります。
コンポーネントのデフォルトの外観をオーバーライドする場合、アクセシビリティへの影響を意識してください。
CSSを使用してコンポーネントの外観を変更すると、アクセシビリティに影響する可能性があります。たとえば、色を変更すると色の対比の問題が発生します。
拡大縮小が可能なサイズ単位を使用します。
CSSを使用してサイズを指定する場合は、絶対単位ではなく、フォント・サイズに対して拡大縮小が可能なサイズ単位を使用します。たとえば、px
ではなく、em
、ex
または%
の単位を使用します。弱視のユーザーはフォント・サイズを拡大することがあり、高さが固定または絶対に制限されているコンテンツが欠ける原因になるため、CSSを使用して高さを指定する場合は特に重要です。
CSSの位置設定は使用しないでください。
CSSの位置設定は、拡大されたレイアウト・コンポーネントの位置設定の場合にのみ使用します。それ以外にはCSSの位置設定を使用しないでください。
ページ構造およびナビゲーション・ツールを使用する際には、次のアクセシビリティ・ガイドラインに従ってください。
レイアウトの設定には、af:panelSplitter
コンポーネントを使用します。
ジオメトリ管理レイアウトを実装する際、af:panelSplitter
を使用するとユーザーは次のことができます。
必要に応じて領域を再配分できます。
すぐに使用しないコンテンツを非表示にするか閉じることができます。
af:panelStretchLayout
を使用する場合、必要に応じて、かわりにaf:panelStretchLayout
を使用することを検討する必要があります。
これらのページ構造の特性はすべてのユーザーにとって便利で、特に、弱視のユーザーやスクリーン・リーダーを使用するユーザーの役に立ちます。
たとえば、ページ上部にあるクロム・ナビゲーション・バーは、af:panelStretchLayout
コンポーネントのtop
ファセット内ではなく、垂直のaf:panelSplitter
コンポーネントのfirst
ファセット内に配置する必要があります。これにより、ユーザーは、バーが使用する領域を減らすことや、すべてを非表示にすることができます。同様に、左、中央または右ペインがあるレイアウトでは、水平のスプリッタを使用してペインをレイアウトします。
フロー・レイアウト・コンテンツのスクロールを有効化します。
af:panelSplitter
またはaf:panelStretchLayout
など、ジオメトリ管理される親コンポーネント内のレイアウト・コントロールなどのフロー・レイアウト・コンテンツをネストさせる際には、layout="scroll"
が指定されたaf:panelGroupLayout
をフロー・レイアウト・コンテンツでラップします。これにより、コンテンツが収まらないほどにフォント・サイズが拡大された場合に、スクロールバーが表示されます。これを実行しないと、コンテンツの欠落や切捨ての原因になります。
ページ構造の識別には、ヘッダーベースのコンポーネントを使用します。
HTMLヘッダー要素は、画面の可読性において重要な役割を果します。通常、スクリーン・リーダーを使用すると、HTMLヘッダー全体を調査または移動して、ユーザーはページの全体的な構造を理解できます。次のコンポーネントを含め、HTMLヘッダーのコンテンツをレンダリングするコンポーネントを介して、ページの主要部分を確認します。
af:panelHeader
af:showDetailHeader
af:panelAccordion
のaf:showDetailItem
(ペインの各アコーディオンによりタイトル領域のHTMLヘッダーがレンダリングされます。)
ページ位置の識別には、af:breadCrumbs
コンポーネントを使用します。
アクセシビリティ標準では、ユーザーがWebサイトまたはアプリケーション内での位置を確認できる必要があります。af:breadCrumbs
を使用するとこれを実現できます。
WAI-ARIA標準では、ページの異なるセクションが異なるランドマーク・リージョンとして定義されます。WAI-ARIAロールとともに、それらが高度なページ構造についての情報を伝え、ランドマーク領域全体にわたる移動を容易にします。これは特に、スクリーン・リーダーなどの支援技術のユーザーにとって便利です。
ADF Facesには、表22-3に示すように、いくつかのレイアウト・コンポーネント用のランドマーク属性が含まれています。
表22-3 ランドマーク属性のあるADF Facesコンポーネント
コンポーネント | 属性 |
---|---|
|
|
|
|
|
firstLandmark
|
|
|
これらの属性には、次のようなWAI-ARIAランドマーク・ロールのいずれかを設定できます。
banner
complimentary
contentinfo
main
navigation
search
ランドマーク関連の属性のいずれかが設定されている場合、ADF Facesでは指定された値でロール属性をレンダリングします。
JDeveloperには、ADF Facesのアクセシビリティ監査ルールが用意されており、表22-1に示されている多くの一般的な要件に準拠しているかどうかが調査および報告されます。監査レポートを実行すると、監査プロファイルが作成されて実行されます。
監査プロファイルを作成する手順:
メイン・メニューから、「ツール」→「プリファレンス」を選択します。
「監査」→「プロファイル」を選択します。
「監査: プロファイル」ダイアログで、「ADF Facesアクセス・ルール」を除く、すべてのチェック・ボックスの選択を解除します。
一意の名前でプロファイルを保存して、「OK」をクリックします。
監査レポートを実行する手順:
メイン・メニューから「ビルド」→「監査」ターゲットを選択します。
作成した監査プロファイルをリストから選択します。
「OK」をクリックしてレポートを生成します。
監査レポートの結果は、「ログ」ウィンドウに表示されます。レポートが完了したら、「ログ」ウィンドウのツールバーにある「エクスポート」アイコンをクリックして、結果をHTMLにエクスポートできます。