アクセシビリティに対応したテキストの要件
このトピックでは、色と背景で必要なコントラスト比を確実に満たすことによる、アプリ内のテキストのアクセシビリティに関するベスト プラクティスについて説明します。 このトピックでは、ユニバーサル Windows プラットフォーム (UWP) アプリのテキスト要素に含めることができる Microsoft UI オートメーション ロールと、グラフィックス内のテキストのベスト プラクティスについても説明します。
コントラスト比
ユーザーには常にハイ コントラスト モードに切り替えるオプションがありますが、テキスト用のアプリデザインでは、そのオプションを最後の手段と見なす必要があります。 より良い方法は、アプリのテキストが、テキストとその背景のコントラストレベルに関する特定の確立されたガイドラインを満たしていることを確認することです。 コントラストのレベルの評価は、色の色合いを考慮しない決定論的手法に基づいています。 たとえば、緑色の背景に赤いテキストがある場合、色覚障疸のあるユーザーがそのテキストを読み取れない可能性があります。 コントラスト比を確認して修正すると、このようなアクセシビリティの問題を防ぐことができます。
ここで説明するテキスト コントラストの推奨事項は、Web アクセシビリティ標準の G18: テキスト (およびテキストの画像) とテキストの背景の間に少なくとも 4.5:1 のコントラスト比が存在することを確認に基づいています。 このガイダンスは、
アクセシビリティが高いと見なすには、表示されるテキストの背景に対する最小輝度コントラスト比が 4.5:1 である必要があります。 例外には、非アクティブな UI コンポーネントの一部であるテキストなど、ロゴや付随テキストが含まれます。
装飾され、情報を伝えるテキストは除外されません。 たとえば、ランダムな単語を使用して背景を作成し、その単語を意味を変更せずに再配置または置換できる場合、単語は装飾と見なされ、この条件を満たす必要はありません。
カラー コントラスト ツールを使用して、表示されるテキストのコントラスト比が許容されることを確認します。 コントラスト比をテストできるツールについては、「 WCAG 2.0 G18 のテクニック (リソース)」セクション を参照してください。
Note
WCAG 2.0 G18 の手法で示されている一部のツールは、UWP アプリでは対話形式で使用できません。 ツールで前景色と背景色の値を手動で入力するか、アプリ UI の画面キャプチャを行ってから、画面キャプチャ イメージに対してコントラスト比ツールを実行することが必要になる場合があります。
テキスト要素の役割
UWP アプリでは、次の既定の要素 (一般に text 要素 または textedit コントロールと呼ばれます) を使用できます。
- TextBlock: role is Text
- TextBox: role is Edit
- RichTextBlock (およびオーバーフロー クラス RichTextBlockOverflow): role is Text
- RichEditBox: role is Edit
コントロールが Edit の役割を持つレポートを作成する場合、支援技術は、ユーザーが値を変更する方法があることを前提としています。 そのため、静的テキストを TextBox に配置すると、ロールが誤って報告されるため、アプリの構造がアクセシビリティ ユーザーに誤って報告されます。
XAML のテキスト モデルには、主に静的テキストに使用される 2 つの要素があります。 TextBlock と RichTextBlock。 これらはどちらも Control サブクラスでもありません。そのため、どちらもキーボードフォーカス可能でも、タブ オーダーで表示することもできません。 しかし、それは支援技術が読み取れない、または読まないという意味ではありません。 スクリーン リーダーは通常、アプリ内のコンテンツを読み取る複数のモードをサポートするように設計されています。これには、専用の読み取りモードや、フォーカスを超えるナビゲーション パターンやタブ オーダー ("仮想カーソル" など) が含まれます。 そのため、タブ オーダーがユーザーをそこに取得するように、静的テキストをフォーカス可能なコンテナーに配置しないでください。 支援技術のユーザーは、タブ オーダー内の何かは対話型であると想定しており、そこで静的なテキストが発生した場合は、役に立つよりも混乱が生じます。 スクリーン リーダーを使用してアプリの静的テキストを調べるときに、ナレーターでこれをテストして、アプリのユーザー エクスペリエンスを把握する必要があります。
アクセシビリティの自動提案
ユーザーが入力フィールドに入力し、候補の一覧が表示されると、この種類のシナリオは自動提案と呼ばれます。 これは、メール フィールドの To: 行、Windows の Cortana 検索ボックス、Microsoft Edge の URL 入力フィールド、Weather アプリの場所の入力フィールドなどでよく見られます。 XAML AutosuggestBox または HTML 組み込みコントロールを使用している場合、このエクスペリエンスは既定で既にフックされています。 このエクスペリエンスにアクセスできるようにするには、入力フィールドとリストを関連付ける必要があります。 これについては、「 自動提案の実装 」セクションで説明します。
ナレーターが更新され、特別な提案モードでこの種のエクスペリエンスにアクセスできるようになりました。 大まかに言うと、編集フィールドとリストが正しく接続されると、エンド ユーザーは次の操作を行います。
- リストが存在し、リストが閉じるタイミングを把握する
- 使用可能な提案の数を把握する
- 選択した項目 (存在する場合) を把握する
- ナレーターフォーカスをリストに移動できる
- 他のすべての読み取りモードで提案内を移動できる
候補リストの例
自動提案の実装
このエクスペリエンスにアクセスできるようにするには、入力フィールドとリストを UIA ツリーに関連付ける必要があります。 この関連付けは、デスクトップ アプリの UIA_ControllerForPropertyId プロパティまたは UWP アプリの ControlledPeers プロパティで行われます。
大まかに言えば、2 種類の自動提案エクスペリエンスがあります。
既定の選択
一覧で既定の選択が行われる場合、ナレーターは、デスクトップ アプリでは UIA_SelectionItem_ElementSelectedEventId イベント、UWP アプリでは AutomationEvents.SelectionItemPatternOnElementSelected イベントの発生を検索します。 選択が変更されるたびに、ユーザーが別の文字を入力し、提案が更新されたとき、またはユーザーがリスト内を移動すると、 ElementSelected イベントが発生します。
既定の選択がある例
既定の選択なし
Weather アプリの [場所] ボックスなどの既定の選択がない場合、ナレーターはデスクトップ UIA_LayoutInvalidatedEventId イベントまたは UWP LayoutInvalidated イベントを検索し、リストが更新されるたびにリストで発生します。
既定の選択がない例
XAML の実装
既定の XAML AutosuggestBox を使用している場合、すべてが既にフックされています。 TextBoxとリストを使用して独自の自動提案エクスペリエンスを作成する場合は、TextBoxのAutomationProperties.ControlledPeersとしてリストを設定する必要があります。 このプロパティを追加または削除するたびに、ControlledPeers プロパティの AutomationPropertyChanged イベントを発生させる必要があります。また、この記事で前に説明したシナリオの種類に応じて、独自の SelectionItemPatternOnElementSelected イベントまたは LayoutInvalidated イベントを発生させる必要があります。
HTML の実装
HTML で組み込みコントロールを使用している場合、UIA の実装は既にマップされています。 既にフックされている実装の例を次に示します。
<label>Sites <input id="input1" type="text" list="datalist1" /></label>
<datalist id="datalist1">
<option value="http://www.google.com/" label="Google"></option>
<option value="http://www.reddit.com/" label="Reddit"></option>
</datalist>
独自のコントロールを作成する場合は、W3C 標準で説明されている独自の ARIA コントロールを設定する必要があります。
グラフィックス内のテキスト
可能な限り、グラフィックにテキストを含めないでください。 たとえば、 Image 要素としてアプリに表示されるイメージ ソース ファイルに含めるテキストは、支援技術によって自動的にアクセスまたは読み取り可能になりません。 グラフィックスでテキストを使用する必要がある場合は、"代替テキスト" と同等の AutomationProperties.Name 値に、そのテキストまたはテキストの意味の概要が含まれていることを確認します。 Pathの一部としてベクターからテキスト文字を作成する場合や、Glyphsを使用する場合にも同様の考慮事項が適用されます。
テキストのフォント サイズとスケール
使っているフォントが小さすぎる場合、ユーザーはアプリケーション内のテキストを読みづらくなることがあります。そのため、まずアプリケーション内のテキストが適切なサイズであることを確認してください。
この一目でわかることが完了したら、Windows にはさまざまなユーザー補助ツールと設定が用意されているので、ユーザーはそれらを使って、テキストを読むためのニーズや好みに合わせて調整することができます。 次に例を示します。
- 拡大鏡ツールは UI で選択された領域を拡大できます。 アプリ内のテキストのレイアウトによって、拡大鏡を使用した読み取りが困難にならないようにする必要があります。
- [設定] -> [システム] -> [表示] -> [拡大縮小とレイアウト] のグローバルなスケールと解像度の設定。 ディスプレイ デバイスの機能に左右されるため、実際に使用できるサイズ変更のオプションは異なる場合があります。
- [設定] -> [簡単操作] -> [表示] のテキスト サイズ設定。 [テキストを大きくする] 設定を調整すると、すべてのアプリケーションと画面で、サポートされるコントロール内のテキストのサイズのみが指定されます (すべての UWP テキスト コントロールで、カスタマイズまたはテンプレートを使用しないテキスト スケーリング エクスペリエンスがサポートされています)。
注意
[すべてのものを大きくする] 設定を使用すると、ユーザーは、通常、テキストとアプリのサイズを主要画面のみで指定できます。
さまざまなテキスト要素とコントロールには、 IsTextScaleFactorEnabled プロパティがあります。 このプロパティの値は既定 true 。 true の場合、その要素のテキストのサイズを拡大縮小することができます。 拡大縮小は、FontSize が大きいテキストよりも、FontSize が小さいテキストにより大きな影響を及ぼします。 要素の IsTextScaleFactorEnabled プロパティを false に設定することで自動サイズ変更を無効にすることができます。
詳細については、「テキストの拡大縮小」を参照してください。
次のマークアップをアプリに追加して実行します。 [テキスト サイズ] 設定を調整して、各 TextBlock がどうなるかを確認してください。
XAML
<TextBlock Text="In this case, IsTextScaleFactorEnabled has been left set to its default value of true."
Style="{StaticResource BodyTextBlockStyle}"/>
<TextBlock Text="In this case, IsTextScaleFactorEnabled has been set to false."
Style="{StaticResource BodyTextBlockStyle}" IsTextScaleFactorEnabled="False"/>
すべてのアプリで UI テキストを一様に拡大縮小することは、ユーザーにとって重要なアクセシビリティ エクスペリエンスであるため、テキストの拡大縮小を無効にすることはお勧めしません。
また、 TextScaleFactorChanged イベントと TextScaleFactor プロパティを使用して、電話での Text サイズ 設定の変更を確認することもできます。 その方法を次に紹介します。
C#
{
...
var uiSettings = new Windows.UI.ViewManagement.UISettings();
uiSettings.TextScaleFactorChanged += UISettings_TextScaleFactorChanged;
...
}
private async void UISettings_TextScaleFactorChanged(Windows.UI.ViewManagement.UISettings sender, object args)
{
var messageDialog = new Windows.UI.Popups.MessageDialog(string.Format("It's now {0}", sender.TextScaleFactor), "The text scale factor has changed");
await messageDialog.ShowAsync();
}
TextScaleFactor の値は、範囲 [1,2.25] の倍精度浮動小数点数です。 最小のテキストは、この量でスケールアップされます。 たとえば、テキストに合わせてグラフィックスをスケーリングするために値を使用できる場合があります。 ただし、すべてのテキストが同じ要素によって拡大縮小されるわけではないことに注意してください。 一般に、テキストが大きいほど、スケーリングの影響を受けなくなります。
これらの型には、 IsTextScaleFactorEnabled プロパティがあります。
- ContentPresenter
- コントロール クラスと派生クラス
- FontIcon
- RichTextBlock
- TextBlock
- TextElement および派生クラス
例
ヒント
WinUI 3 ギャラリー アプリには、ほとんどの WinUI 3 コントロールと機能の対話型の例が含まれています。 Microsoft Store からアプリを入手するか、GitHub でソース コードを取得します。
関連トピック
Windows developer