次の方法で共有

アクセシビリティの概要

このトピックでは、アクセシビリティの高い Windows アプリの構築に関連する概念とテクノロジについて説明します。

アクセシビリティの高いWindowsアプリケーションは、障碍のあるユーザー (一時的および永続的) だけでなく、個人の好み、特定の作業スタイル、状況や環境の制約 (共有作業スペース、低帯域幅、明るい日差し、ノイズや静かな環境、調理中など) をサポートします。

このガイダンスは、アクセシビリティをコア品質要件として扱い、自動化されたアクセシビリティ チェックを通常のエンジニアリング ワークフローの一部として使用する開発チーム向けに作成されています。 これらのトピックを使用して、アクセシビリティの期待値を早期に定義し、継続的に検証し、特徴の進化に伴う回帰を防ぎます。

多くの障害、たとえば移動の難しさ、視覚、色覚、聴覚、音声、認知、リテラシーの問題などは、次の機能を提供することで対処できる場合があります。

  • キーボード操作とスクリーン リーダーのサポート。
  • フォント、ズーム設定 (拡大)、色、ハイ コントラスト設定などのユーザーカスタマイズのサポート。
  • 代替 UI または補足 UI。

XAML コントロールは、スクリーン リーダーなどのキーボード アクセスと支援技術に対する組み込みのサポートを提供します。 この組み込みサポートにより、さまざまなプロパティを使用してカスタマイズできる基本的なレベルのアクセシビリティが可能になります。 独自のカスタム XAML コンポーネントとコントロールを作成する場合は、*automation peer- を使用してこれらのコントロールに同様のサポートを追加することもできます (詳細については、 カスタム オートメーション ピアを参照してください)。

さらに、データ バインディング、スタイル、テンプレートの機能を使用すると、代替 UI と表示設定の変更を動的にサポートできます。

UIオートメーション (UI Automation)

アクセシビリティのサポートは、主に Microsoft UI オートメーション フレームワークの統合に由来します。 このサポートは、基底クラスと、コントロール型のクラス実装の組み込み動作と、UI オートメーション プロバイダー API のインターフェイス表現を通じて提供されます。 各コントロール クラスは、オートメーション ピアとオートメーション パターンのUI Automation概念を使用して、コントロールのロールとコンテンツをUI Automationクライアントに報告します。 アプリはUI Automationによって最上位ウィンドウとして扱われ、UI Automation フレームワークを通じて、そのアプリ ウィンドウ内のすべてのアクセシビリティ関連コンテンツをUI Automation クライアントで使用できます。 UI Automationの詳細については、「UI Automation Overview」を参照してください。

支援技術

アクセシビリティのニーズの多くは、ユーザーがインストールした支援技術製品、またはオペレーティング システムによって提供されるツールと設定によって満たされます。 これには、スクリーン リーダー、スクリーン 拡大鏡、ハイ コントラスト設定が含まれます。

支援技術製品には、さまざまなソフトウェアとハードウェアが含まれています。 これらの製品は、UI のコンテンツと構造に関する情報をスクリーン リーダーやその他の支援技術に報告する標準のキーボード インターフェイスとアクセシビリティ フレームワークを通じて動作します。 支援技術製品の例を次に示します。

  • スクリーン キーボード (OSK) またはソフトウェア キーボード。ユーザーは、ハードウェア キーボードの代わりにポインターを使用してテキストを入力できます。
  • 音声の単語を型指定されたテキストに変換する音声認識ソフトウェア。
  • テキストを音声の単語や点字などの形式に変換するスクリーンリーダー。
  • Windows に組み込まれているナレータースクリーン リーダーには、タッチ ジェスチャを使用して画面読み取りタスクを実行できるタッチ モードがあります。
  • ハイ コントラスト テーマ、ドット/インチ (dpi)、拡大鏡ツールなど、表示を調整するプログラムまたは設定。

キーボードとスクリーン リーダーのサポートが良好なアプリは、通常、さまざまな支援技術製品で適切に動作します。 多くの場合、Windows アプリは、情報や構造を追加変更することなく、これらの製品と連携します。 ただし、アクセシビリティエクスペリエンスを最適化するために、または追加のサポートを実装するために、いくつかの設定を変更することが必要な場合があります。

支援技術 を 使用して基本的なアクセシビリティ シナリオをテストする方法については、アクセシビリティ テストを参照してください。

スクリーン リーダーのサポートと基本的なアクセシビリティ情報

スクリーン リーダーは、音声言語や点字出力などの別の形式でレンダリングすることで、アプリ内のテキストにアクセスできるようにします。 スクリーン リーダーの正確な動作は、ユーザーが構成したソフトウェアによって異なります。

たとえば、一部のスクリーン リーダーは、ユーザーがアプリを起動または切り替えたときに UI 全体を読み取ります。これにより、ユーザーは移動を試みる前にすべての情報コンテンツを受信できます。 一部のスクリーン リーダーは、タブ ナビゲーション中にフォーカスを受け取ったときに、個々のコントロールに関連付けられているテキストも読み取ります。 これにより、ユーザーはアプリケーションの入力コントロール間を移動する際に自分の方向を設定できます。 ナレーターは、両方の動作をサポートするスクリーン リーダーの例です。

ユーザーがアプリを理解またはナビゲートするためにスクリーン リーダーまたはその他の支援技術で必要とする最も重要な情報は、アプリ内の各要素の アクセス可能な名前 です。 多くの場合、コントロールまたは要素には、内部テキストをサポートして表示する要素など、他のプロパティ値から派生したアクセス可能な名前が既に含まれています。 他の要素の場合は、要素構造を通じてアクセス可能な名前を指定する必要がある場合があります。 また、アクセス可能な名前を明示的に指定する必要がある場合もあります。 これらの派生値が一般的な UI 要素でどのように機能するかの詳細と、アクセシビリティの高い名前の一般的な詳細については、「アクセシビリティに関する 基本的な情報を公開する」を参照してください。

他にも複数のオートメーション プロパティがあります (次のセクションで説明するキーボード プロパティを含む)。 ただし、すべてのスクリーン リーダーですべてのオートメーション プロパティがサポートされているわけではありません。そのため、さまざまなスクリーン リーダーですべての適切なオートメーション プロパティをテストする必要があります。

キーボードのサポート

(従来の、変更された、またはキーボード エミュレーション ハードウェア用の) キーボード アクセシビリティをアプリに組み込み、視覚障碍のあるユーザー、視覚障碍のあるユーザー、または運動制御の問題があるユーザーが、アプリの全機能をナビゲートして使用するのに役立ちます。 また、障害のないユーザーも、効率や好みのためにナビゲーション用のキーボードを選択することができます。

基本的な XAML コントロール モデルでは、タブ ナビゲーション、テキスト入力、コントロール固有のサポートなど、組み込みのキーボード サポートが提供されます。 レイアウト コンテナー (パネルなど) として機能する要素は、レイアウト順序を使用して既定のタブ オーダーを確立し、UI のアクセシビリティ対応の表現を提供します。 ListBox コントロールと GridView コントロールには、組み込みの矢印キー ナビゲーションが用意されています。 ボタン コントロールは、ボタンのアクティブ化のために Space キーまたは Enter キーを処理します。

タブ オーダーやキーベースのアクティブ化やナビゲーションなど、キーボードサポートのすべての側面の詳細については、「 キーボードのアクセシビリティ」を参照してください。

メディアとキャプション

通常、 MediaPlayerElement オブジェクトを介してオーディオ ビジュアル メディアを表示します。 アクセシビリティの目的で、ユーザーがメディアを再生、一時停止、停止したり、キャプションや代替オーディオ トラックを取り込んだりできるようにするコントロールを提供します。

アクセシビリティ対応のテキスト

アプリでテキストを設計して実装するときは、次の 3 つの主要なアクセシビリティ要件に重点を置きます。

  • 支援技術は、タブ シーケンス ナビゲーション中にテキストを読み取る必要があるか、ドキュメントコンテンツ全体の一部として読む必要があるかを判断できる必要があります。 正しいテキスト要素を選択し、そのプロパティを適切に設定することで、この動作に影響を与えることができます。 各テキスト要素は特定の目的にマップされ、多くの場合、対応する UI オートメーション ロールにマップされるため、間違った要素を使用すると、間違ったロールが公開され、支援技術ユーザーにとって混乱を招く可能性があります。
  • 多くのユーザーは、視覚や色覚の欠陥があり、テキストと背景の間に十分なコントラストがない限り、テキストを確実に読むことができません。 この影響は、設計時に過小評価しやすい場合があります。 確立されたコントラスト ガイダンスに従うと、これらのユーザーが読み取れないテキストを防ぐことができます。 詳細については、「 アクセシビリティ対応テキストの要件」を参照してください。
  • テキストが小さすぎると、多くのユーザーが読みにくくなっています。 適切な既定のテキスト サイズから開始し、システム テキストと表示のスケーリングでアプリが正しく動作することを確認します。 これは、大量のテキストや高密度のビジュアル レイアウトを含む UI で特に重要です。

ハイ コントラスト テーマのサポート

XAML コントロールは、ハイ コントラストのテーマ リソースを含むテーマ リソース ディクショナリから視覚的な外観を取得します。 ユーザーがハイコントラストモードを有効にすると、コントロールは対応するハイコントラストリソースに自動的に適用されます。 この動作を維持するには、ハードコーディングされた色や明示的なスタイルなど、テーマ リソースの参照をブロックするスタイル方法を避けます。これにより、ハイ コントラストテーマの値によってカスタム値がオーバーライドされなくなります。 詳細については、「 ハイ コントラスト テーマ」を参照してください。

代替 UI の設計

多くの場合、複数のキューを使用して、重要な情報をより効果的に伝えることができます。たとえば、色付きのアイコンを組み合わせて、色覚障碍のあるユーザーをサポートし、視覚アラートをサウンドとペアリングして、聴覚障碍のあるユーザーをサポートします。

必要に応じて、不要なビジュアルとアニメーションを削除し、対話フローを簡略化する、アクセス可能な別の UI を提供します。 次のコード例は、ユーザー設定に基づいて 1 つの UserControl を別の ユーザーコントロール に切り替える方法を示しています。

<StackPanel x:Name="LayoutRoot" Background="White">

  <CheckBox x:Name="ShowAccessibleUICheckBox" Click="ShowAccessibleUICheckBox_Click">
    Show Accessible UI
  </CheckBox>

  <ContentControl x:Name="ContentBlock">
    <local:ContentPage/>
  </ContentControl>

</StackPanel>

private void ShowAccessibleUICheckBox_Click(object sender, RoutedEventArgs e)
{
    if (sender is CheckBox checkBox)
    {
        ContentBlock.Content = checkBox.IsChecked == true
            ? new AccessibleContentPage()
            : new ContentPage();
    }
}

カスタム コントロールでの支援技術のサポート

カスタム コントロールを作成するときは、アクセシビリティサポートを提供するために、1 つ以上の AutomationPeer サブクラスを実装または拡張します。 場合によっては、基本コントロールと同じピア クラスを再利用すると、派生コントロールに対して許容できるベースライン自動化動作が提供される場合があります。 ただし、テストを通じてこれを検証する必要があります。ほとんどの場合、カスタム コントロールの正しいクラス名と動作を報告できるように、専用ピアを実装する必要があります。 実装のガイダンスについては、 カスタム オートメーション ピアを参照してください。

XAML/Microsoft DirectX 相互運用をサポートするアプリでの支援技術のサポート

既定では、XAML UI でホストされている Microsoft DirectX コンテンツ ( SwapChainPanel または SurfaceImageSource を使用) にはアクセスできません。 XAML SwapChainPanel DirectX 相互運用のサンプル (アーカイブされたレガシ サンプル) では、DirectX コンテンツ用の AutomationPeer を作成して、UI オートメーションを介してホストされたコンテンツにアクセスできるようにする方法を示します。 この手法により、ホストされているコンテンツはUI Automationを介してアクセスできるようになります。

検証と発行

アクセシビリティ検証は、最終的な QA パスではなく、進行中のエンジニアリング アクティビティとして扱います。 可能な限りすべてのビルドに対して自動チェックを実行し、重要なユーザー体験のためにターゲットの手動支援技術検証と組み合わせることができます。

アクセシビリティ宣言とアプリの発行の詳細については、「 ストアのアクセシビリティ」を参照してください。

例示

WinUI 3 ギャラリー アプリを開き、次のアクセシビリティの原則を確認します。

WinUI 3 ギャラリー アイコン WinUI 3 ギャラリー アプリには、WinUI コントロールと機能の対話型の例が含まれています。 Microsoft Store からアプリを取得するか、GitHub でソース コードを参照します。
  • Last updated on