アクセシビリティ対応にするために避ける事項Accessibility practices to avoid

アクセシビリティ対応のユニバーサル Windows プラットフォーム (UWP) アプリを作成する際は、こちらの避ける事項の一覧をご覧ください。If you want to create an accessible Universal Windows Platform (UWP) app, see this list of practices to avoid:

  • 既定の Windows コントロールか、Microsoft UI オートメーション サポートを既に実装しているコントロールを使うことができる場合には、カスタム UI 要素を作成しないようにします。Avoid building custom UI elements if you can use the default Windows controls or controls that have already implemented Microsoft UI Automation support. Windows の標準コントロールは、既定でアクセシビリティに対応しており、追加する必要があるのは、通常、アプリ固有のわずかなアクセシビリティ属性のみです。Standard Windows controls are accessible by default and usually require adding only a few accessibility attributes that are app-specific. それに対し、純粋なカスタム コントロールに AutomationPeer サポートを実装するのは、これより複雑です (「カスタム オートメーション ピア」をご覧ください)。In contrast, implementing the AutomationPeer support for a true custom control is somewhat more involved (see Custom automation peers).

  • 静的テキストなどの非対話型の要素をタブ オーダーに含めないようにします (たとえば、対話的に操作できない要素にTabIndex プロパティを設定することは避けます)。Don't put static text or other non-interactive elements into the tab order (for example, by setting the TabIndex property for an element that is not interactive). 非対話型の要素をタブ オーダーに含めると、キーボード ナビゲーションの効率が下がるため、キーボードのアクセシビリティ ガイドラインで推奨されていません。If non-interactive elements are in the tab order, that is against keyboard accessibility guidelines because it decreases efficiency of keyboard navigation for users. 多くの支援技術では、支援技術のユーザーにアプリのインターフェイスを表示する方法に関するロジックの一部として、要素をフォーカスする機能とタブ オーダーが使われています。Many assistive technologies use tab order and the ability to focus an element as part of their logic for how to present an app's interface to the assistive technology user. タブ オーダーにテキスト専用要素が含まれると、タブ オーダーに対話型の要素 (ボタン、チェック ボックス、テキスト入力フィールド、コンボ ボックス、リストなど) しか含まれていないと想定しているユーザーを混乱させる可能性があります。Text-only elements in the tab order can confuse users who expect only interactive elements in the tab order (buttons, check boxes, text input fields, combo boxes, lists, and so on).

  • UI 要素の絶対配置 (Canvas 要素内など) は、しばしば表示の順序が (事実上の論理的な順序である) 子要素の宣言の順序と異なるため、使用を避けます。Avoid using absolute positioning of UI elements (such as in a Canvas element) because the presentation order often differs from the child element declaration order (which is the de facto logical order). スクリーン リーダーが UI 要素を正しい順序で読み取ることができるように、これらの要素をできるだけドキュメントの順序または論理的な順序に並べます。Whenever possible, arrange UI elements in document or logical order to ensure that screen readers can read those elements in the correct order. UI 要素の視覚的な順序がドキュメントの順序または論理的な順序とは異なる可能性がある場合は、正しい読み取り順序を定義するために明示的なタブ インデックス値 (TabIndex に設定) を使います。If the visible order of UI elements can diverge from the document or logical order, use explicit tab index values (set TabIndex) to define the correct reading order.

  • 情報を伝達する唯一の方法としては、色を使用しないでください。Don’t use color as the only way to convey information. 色覚に障碍があるユーザーは、色によるステータス インジケーターのような色を通じてのみ伝えられる情報は受け取ることができません。Users who are color blind cannot receive information that is conveyed only through color, such as in a color status indicator. 他の視覚的な合図 (テキストが望ましい) を含めるようにして、情報にアクセスできるようにします。Include other visual cues, preferably text, to ensure that information is accessible.

  • アプリの機能に本当に必要でない限り、アプリのキャンバス全体を自動的に更新しないようにします。Don’t automatically refresh an entire app canvas unless it is really necessary for app functionality. ページの内容を自動的に更新する必要がある場合には、ページの一部の領域だけを更新するようにします。If you need to automatically refresh page content, update only certain areas of the page. 支援技術では通常、更新されたアプリのキャンバスは、実質的な変更がわずかな場合でも、完全に新しい構造であると見なす必要があります。Assistive technologies generally must assume that a refreshed app canvas is a totally new structure, even if the effective changes were minimal. このため、更新されたアプリのドキュメント ビューや説明を再作成し、支援技術を使うユーザーに再提示する必要があります。The cost of this to the assistive technology user is that any document view or description of the refreshed app now must be recreated and presented to the user again.

    ユーザーが開始する意図的なページのナビゲーションによってアプリの構造が更新されることは、問題ありません。A deliberate page navigation that is initiated by the user is a legitimate case for refreshing the app's structure. ただし、ナビゲーションを開始する UI 項目に適切な ID または名前を設定し、呼び出すとコンテキストが変更されてページが再読み込みされることがわかるようにしてください。But make sure that the UI item that initiates the navigation is correctly identified or named to give some indication that invoking it will result in a context change and page reload.

    注意

    領域内のコンテンツを更新する場合は、要素上の AccessibilityProperties.LiveSetting アクセシビリティ プロパティを既定以外の設定である Polite または Assertive に設定することをお勧めします。If you do refresh content within a region, consider setting the AccessibilityProperties.LiveSetting accessibility property on that element to one of the non-default settings Polite or Assertive. 支援技術の中には、ライブ領域の Accessible Rich Internet Applications (ARIA) 概念にこの設定をマップして、コンテンツの領域が変更されたことをユーザーに通知できるものもあります。Some assistive technologies can map this setting to the Accessible Rich Internet Applications (ARIA) concept of live regions and can thus inform the user that a region of content has changed.

  • 1 秒あたり UI 要素をフラッシュ 3 倍以上が使わない。Don’t use UI elements that flash more than three times per second. 明滅する要素は一部の人にとって発作を起こす原因になります。Flashing elements can cause some people to have seizures. 明滅する UI 要素の使用は避けた方が良いでしょう。It is best to avoid using UI elements that flash.

  • ユーザー コンテキストを変更したり、機能を自動的にアクティブ化しないでください。Don’t change user context or activate functionality automatically. コンテキストやアクティブ化の変更は、フォーカスのある UI 要素上でユーザーが直接操作したときにだけ行うようにします。Context or activation changes should occur only when the user takes a direct action on a UI element that has focus. ユーザー コンテキストの変更には、フォーカスの変更、新しいコンテンツの表示、別のページへの移動が含まれます。Changes in user context include changing focus, displaying new content, and navigating to a different page. ユーザーと無関係に行われるコンテキストの変更は、障碍のあるユーザーを混乱させる可能性があります。Making context changes without involving the user can be disorienting for users who have disabilities. この要件の例外としては、サブメニューの表示、フォームの検証、別のコントロールでのヘルプ テキストの表示、非同期イベントへの応答によるコンテキストの変更などがあります。The exceptions to this requirement include displaying submenus, validating forms, displaying help text in another control, and changing context in response to an asynchronous event.