入力時:
達成基準 3.2.2 を理解する
3.2.2 入力時: ユーザインタフェース コンポーネント の設定を変更することが、コンテキストの変化を自動的に引き起こさない。ただし、利用者が使用する前にその挙動を知らせてある場合を除く。 (レベル A)
この達成基準の意図
この達成基準の意図は、データ入力又はフォームコントロールの選択の結果を予測可能にすることである。ユーザインタフェース要素の設定を変更すると、コントロールの状態を変化させ、その状態は利用者がそのユーザインタフェース要素とのやりとりを終了した後も持続する。つまり、チェックボックスを選択する、テキストフィールドにテキストを入力する、又はリストコントロールのオプションを選択すると、コンポーネントの設定を変更するが、リンク又はボタンを動作させるときはそうはならない。コンテキストの変化は、その変化を知覚しづらい利用者、又は変化によって気を取られやすい利用者を混乱させてしまう恐れがある。コンテキストの変化が起こってもよいのは、そのような変化が利用者の操作に反応して起こることが明らかなときだけである。
注記: この達成基準は、コントロールの設定を変更することによるコンテキストの変化をカバーする。リンク又はタブ コントロール内のタブのクリックすると、コントロールの設定を変更せずに、コントロールがアクティブになる。
注記: ここでいう”コンポーネント”及び”ユーザインタフェース コンポーネント”は”ユーザインタフェース要素”とも呼ばれる。
達成基準 3.2.2 の具体的なメリット:
この達成基準は、インタラクティブなコンテンツを、より予測可能にすることによって、障害のある利用者に役立つ。予期しないコンテキストの変化によって、視覚障害又は認知的限界のある利用者はとても混乱してしまう可能性があり、コンテンツを利用できなくなる。
コンテキストの変化に気づくことができない人は、サイトをナビゲートしている間に混乱した状態になりにくい。例えば:
全盲又はロービジョンの人は、新しいウィンドウがポップアップするなど、視覚的なコンテキストの変化が発生したことを知るのが困難なことがある。この場合、事前にコンテキストの変更を利用者に警告しておくと、戻るボタンがもはや予想どおりに動作しないことを発見したときに利用者の混乱を最小限に抑える。
ロービジョン、読字及び知的障害のある人、そして視覚的な手がかりの解釈が困難な人は、コンテキストの変化を知るために、追加の手がかかりから得るだろう。
達成基準 3.2.2 の事例
フォームは、ウェブベースのカレンダー及びスケジュール管理アプリケーションに、カレンダーのエントリーを作成するために提供されている。件名、時刻、場所の標準的なフィールドに加えて、作成するカレンダーのエントリーの種類を選択するラジオボタン一式がある。カレンダーのエントリの種類は、会議、アポイントメント又はリマインダにできる。利用者が会議のラジオボタンを選択すると、会議の参加者を入力する追加のフィールドがページに表示される。リマインダのボタンを選択した場合、異なるフィールドが表示される。エントリーの部分だけが変化し、全体の構造は同じままなので、基本的なコンテキストは利用者のために留まる。
フォームは、米国の電話番号を表すフィールドを含んでいる。すべての電話番号には、3 桁のエリアコード (市外局番) があり、続いて 3 桁の局番、最後に 4 桁の番号があり、それぞれの番号は別々のフィールドに入力される。利用者があるフィールドの入力を完了すると、フォーカスは自動的に電話番号の次のフィールドへ移動する。この電話フィールドのふるまいは、フォームの先頭で利用者に対して説明されている。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
(今のところ、文書化されていない)
達成基準 3.2.2 の達成方法及び失敗例 - 入力時
この節にある番号付きの各項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組み合わせを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。その他の達成方法についての詳細は、WCAG 達成基準の達成方法を理解するの「その他の達成方法」を参照のこと。
十分な達成方法
以下に挙げる技術特有の手法を用いて G80: コンテキストの変化を開始する送信ボタンを提供する
H32: 送信ボタンを提供する (HTML)
FLASH4: Flash で送信ボタンを提供する (Flash)
SL10: Implementing a Submit-Form Pattern in Silverlight (Silverlight)
SCR19: select 要素の onchange イベントは、コンテキストの変化を引き起こすことのないように使用する (Scripting)
注記: コンテンツの変化が常にコンテキストの変化であるとは限らない。コンテンツの変化がコンテキストの変化ではない場合、この達成基準は自動的に満たされていることになる。
3.2.2 でさらに対応が望まれる達成方法 (参考)
適合のために必須ではないが、コンテンツをよりアクセシブルにするために、次の追加の達成方法を検討することが望ましい。ただし、すべての状況において、すべての達成方法が使用可能、又は効果的であるとは限らない。
達成基準 3.2.2 のよくある失敗例
以下に挙げるものは、WCAG ワーキンググループが達成基準 3.2.2 の失敗例とみなした、よくある間違いである。
重要な用語
- コンテキストの変化 (changes of context)
ウェブページのコンテンツにおける大きな変化で、利用者が気づかないと、ウェブページ全体を一度に見ることのできない利用者を混乱させる恐れのあるもの。
コンテキストの変化には次に挙げるものの変化が含まれる:
注記: コンテンツの変化が、必ずコンテキストの変化になるとはかぎらない。アウトラインの展開、動的なメニュー、又はタブの切替などのコンテンツの変化は、それが上記のいずれか (例: フォーカス) を変更しないかぎり、コンテキストを変化させるとは限らない。
事例: 新しいウィンドウを開くこと、フォーカスを異なるコンポーネントへ移動させること、新しいウェブページへ移動すること (新しいウェブページへ移動したかのように思わせてしまうことも含む)、又はウェブページの内容を大きく再配置することなどは、コンテキストの変化の事例である。
- ユーザインタフェース コンポーネント (user interface component)
コンテンツの一部分で、特定の機能を実現するための単一のコントロールとして利用者が知覚するもの。
注記 1: 複数のユーザインタフェース コンポーネントが、単一のプログラム要素で実装されることもある。ここでいうコンポーネントは、プログラムの手法と結びついたものではなく、利用者が別々のコントロールとして知覚するものを指す。
注記 2: ユーザインタフェース コンポーネントには、フォーム要素、リンクだけでなく、スクリプトで生成されるコンポーネントが含まれる。
事例: アプレットには、コンテンツ内を行単位、ページ単位、又はランダムアクセスで移動するために用いられる「コントロール」がある。これらには、いずれも名前 (name) を割り当て、個別に設定できるようにする必要があるため、それぞれが「ユーザインタフェース コンポーネント」となる。