アクセシビリティに対応したテキストの要件Accessible text requirements

このトピックでは、色と背景のコントラスト比を適切な値にすることで、アプリのテキストをアクセシビリティ対応にするためのベスト プラクティスについて説明します。This topic describes best practices for accessibility of text in an app, by assuring that colors and backgrounds satisfy the necessary contrast ratio. また、ユニバーサル Windows プラットフォーム (UWP) アプリ内のテキスト要素に設定できる Microsoft UI オートメーションの役割と、グラフィックス内のテキストに関するベスト プラクティスについても説明します。This topic also discusses the Microsoft UI Automation roles that text elements in a Universal Windows Platform (UWP) app can have, and best practices for text in graphics.

コントラスト比Contrast ratios

ユーザーはハイ コントラスト モードにいつでも切り替えることができますが、テキスト用のアプリ設計ではこのオプションを最後の手段にする必要があります。Although users always have the option to switch to a high-contrast mode, your app design for text should regard that option as a last resort. これよりも、アプリのテキストが、テキストと背景とのコントラストのレベルに関して確立されているガイドラインに準拠するようにすることをお勧めします。A much better practice is to make sure that your app text meets certain established guidelines for the level of contrast between text and its background. コントラストのレベルは、色合いを考慮しない確定的な方法に基づいて評価されます。Evaluation of the level of contrast is based on deterministic techniques that do not consider color hue. たとえば、緑の背景の上に赤のテキストを配置すると、色覚に障碍があるユーザーはそのテキストを読み取ることができない場合があります。For example, if you have red text on a green background, that text might not be readable to someone with a color blindness impairment. コントラスト比を確認して修正することで、このようなアクセシビリティの問題を防ぐことができます。Checking and correcting the contrast ratio can prevent these types of accessibility issues.

Standard、web アクセシビリティのテキストのコントラストがここに記載の推奨事項はG18:確認する、コントラスト比を少なくとも 4.5: 1 がテキスト (とテキストのイメージ) の間に存在して、テキストの背景します。The recommendations for text contrast documented here are based on a web accessibility standard, G18: Ensuring that a contrast ratio of at least 4.5:1 exists between text (and images of text) and background behind the text. このガイドラインは、W3C Techniques for WCAG 2.0 仕様に含まれています。This guidance exists in the W3C Techniques for WCAG 2.0 specification.

表示テキストがアクセシビリティに対応していると見なされるためには、背景に対する明暗のコントラスト比が最低でも 4.5:1 以上であることが必要です。To be considered accessible, visible text must have a minimum luminosity contrast ratio of 4.5:1 against the background. ただし、ロゴや、非アクティブな UI コンポーネントの一部のテキストなどの付随テキストは、例外です。Exceptions include logos and incidental text, such as text that is part of an inactive UI component.

装飾テキストや、伝える情報がないテキストも例外になります。Text that is decorative and conveys no information is excluded. たとえば、ランダムな文字を使って背景を作成し、意味を変えることなくその文字を再配置したり置換したりできる場合、文字は装飾と見なされ、この基準を満たす必要がありません。For example, if random words are used to create a background, and the words can be rearranged or substituted without changing meaning, the words are considered to be decorative and do not need to meet this criterion.

色コントラスト ツールを使って、表示テキストのコントラスト比が適切であることを検証します。Use color contrast tools to verify that the visible text contrast ratio is acceptable. コントラスト比をテストできるツールについては、Techniques for WCAG 2.0 の G18 (リソース セクション) をご覧ください。See Techniques for WCAG 2.0 G18 (Resources section) for tools that can test contrast ratios.

注意

Techniques for WCAG 2.0 の G18 にリストされたツールのいくつかは、UWP アプリで対話的に使うことができません。Some of the tools listed by Techniques for WCAG 2.0 G18 can't be used interactively with a UWP app. 場合によっては、前景と背景の色の値を手動でツールに入力する必要があります。またアプリ UI の画面をキャプチャした後、そのキャプチャ画像に対してコントラスト比ツールを実行することが必要になる場合もあります。You may need to enter foreground and background color values manually in the tool, or make screen captures of app UI and then run the contrast ratio tool over the screen capture image.

テキスト要素の役割Text element roles

UWP アプリでは、次の既定の要素 (一般にテキスト要素またはテキスト編集コントロールと呼ばれる) を使うことができます。A UWP app can use these default elements (commonly called text elements or textedit controls):

コントロールから Edit の役割があることが報告されると、支援技術では、ユーザーが値を変更できると想定します。When a control reports that is has a role of Edit, assistive technologies assume that there are ways for users to change the values. このため、静的テキストを TextBox に配置すると、役割が誤って報告され、この結果、アクセシビリティ対応を必要とするユーザーにアプリの構造が誤って報告されます。So if you put static text in a TextBox, you are misreporting the role and thus misreporting the structure of your app to the accessibility user.

XAML のテキスト モデルでは、静的なテキスト、TextBlockRichTextBlock で主に使われる 2 つの要素があります。In the text models for XAML, there are two elements that are primarily used for static text, TextBlock and RichTextBlock. これらはいずれも Control サブクラスではないため、キーボード フォーカス可能でなく、またタブ オーダーに含めることはできません。Neither of these are a Control subclass, and as such neither of them are keyboard-focusable or can appear in the tab order. ただし、支援技術でそれらを読み取ることができないか、または読み取られないわけではありません。But that does not mean that assistive technologies can't or won't read them. スクリーン リーダーは一般的に、「仮想カーソル」など、フォーカスとタブ オーダーを超える専用読み取り値モードやナビゲーション パターンを含めて、アプリ内のコンテンツを読み取る複数のモードをサポートするように設計されています。Screen readers are typically designed to support multiple modes of reading the content in an app, including a dedicated reading mode or navigation patterns that go beyond focus and the tab order, like a "virtual cursor". したがって、タブ オーダーによりユーザーが移動できることのみを理由として、フォーカス可能なコンテナーに静的テキストを格納しないでください。So don't put your static text into focusable containers just so that tab order gets the user there. 支援技術ユーザーは、タブ オーダー内では対話的であることを期待しており、そこに静的なテキストが存在するとその有用性にも増して、混乱を招くことになります。Assistive technology users expect that anything in the tab order is interactive, and if they encounter static text there, that is more confusing than helpful. アプリの静的テキストを調べるためにスクリーン リーダーを使う場合に、アプリに対するユーザー エクスペリエンスの感覚を得るために、自身で、ナレーターによりこの出力のテストを行う必要がありますYou should test this out yourself with Narrator to get a sense of the user experience with your app when using a screen reader to examine your app's static text.

自動提案のアクセシビリティAuto-suggest accessibility

ユーザーが入力フィールドに入力すると、潜在的な候補の一覧が表示される場合、この種のシナリオは自動提案と呼ばれます。When a user types into an entry field and a list of potential suggestions appears, this type of scenario is called auto-suggest. これは、メールの宛先: 行フィールド、Windows の Cortana 検索ボックス、Microsoft Edge の URL 入力フィールド、天気予報アプリの場所入力フィールドなどでよく使用されます。This is common in the To: line of a mail field, the Cortana search box in Windows, the URL entry field in Microsoft Edge, the location entry field in the Weather app, and so on. XAML の AutosuggestBox や HTML の組み込みコントロールを使用している場合、このエクスペリエンスは既定で用意されています。If you are using a XAML AutosuggestBox or the HTML intrinsic controls, then this experience is already hooked up for you by default. このエクスペリエンスをアクセシビリティ対応にするには、入力フィールドと一覧を関連付ける必要があります。To make this experience accessible the entry field and the list must be associated. これについては、「自動提案の実装」セクションで説明しています。This is explained in the Implementing auto-suggest section.

ナレーターは、特別な候補の表示モードによって、このタイプのエクスペリエンスをアクセシビリティ対応にするように更新されました。Narrator has been updated to make this type of experience accessible with a special suggestions mode. 大まかに言うと、編集フィールドと一覧が正しく接続されている場合、エンドユーザーには次のようなメリットがあります。At a high level, when the edit field and list are connected properly the end user will:

  • 一覧が存在していることと一覧が閉じるタイミングを把握するKnow the list is present and when the list closes
  • 利用可能な入力候補の数を把握するKnow how many suggestions are available
  • 項目が選択されている場合は、選択項目を把握するKnow the selected item, if any
  • ナレーターのフォーカスを一覧に移動できるBe able to move Narrator focus to the list
  • 他のすべての閲覧モードで候補内を移動できるBe able to navigate through a suggestion with all other reading modes

候補リストSuggestion list
候補リストの例Example of a suggestion list

自動提案の実装Implementing auto-suggest

このエクスペリエンスをアクセシビリティ対応にするには、UIA ツリーで、入力フィールドと一覧が関連付けられている必要があります。To make this experience accessible the entry field and the list must be associated in the UIA tree. この関連付けは、デスクトップ アプリの UIA_ControllerForPropertyId プロパティまたは UWP アプリの ControlledPeers プロパティを使って設定されます。This association is done with the UIA_ControllerForPropertyId property in desktop apps or the ControlledPeers property in UWP apps.

自動提案のエクスペリエンスには、大まかに 2 つの種類があります。At a high level there are 2 types of auto-suggest experiences.

既定の選択Default selection
一覧で既定の選択が行われる場合、ナレーターは、デスクトップ アプリでは UIA_SelectionItem_ElementSelectedEventId イベント、UWP アプリでは AutomationEvents.SelectionItemPatternOnElementSelected イベントの発生を検索します。If a default selection is made in the list, Narrator looks for a UIA_SelectionItem_ElementSelectedEventId event in a desktop app, or the AutomationEvents.SelectionItemPatternOnElementSelected event to be fired in a UWP app. 選択項目が変更されるたび、つまりユーザーが別の文字を入力して候補が更新されたときや、ユーザーが一覧内を移動したときに、ElementSelected イベントが発生する必要があります。Every time the selection changes, when the user types another letter and the suggestions have been updated or when a user navigates through the list, the ElementSelected event should be fired.

既定値を選択した場合、ボックスの一覧します。List with a default selection
例が、既定の選択Example where there is a default selection

既定の選択がありません。No default selection
天気予報アプリの場所のボックスなど、既定の選択がない場合、ナレーターはデスクトップの UIA_LayoutInvalidatedEventId イベントまたは UWP の LayoutInvalidated イベントの発生を検索します。If there is no default selection, such as in the Weather app’s location box, then Narrator looks for the desktop UIA_LayoutInvalidatedEventId event or the UWP LayoutInvalidated event to be fired on the list every time the list is updated.

既定値も選択されていないを一覧表示します。List with no default selection
例を既定の選択が存在しません。Example where there is no default selection

XAML の実装XAML implementation

XAML の既定の AutosuggestBox を使用している場合、既にすべての準備が完了しています。If you are using the default XAML AutosuggestBox, then everything is already hooked up for you. TextBox と一覧を使って独自の自動提案エクスペリエンスを作成している場合は、TextBox で一覧を AutomationProperties.ControlledPeers として設定する必要があります。If you are making your own auto-suggest experience using a TextBox and a list then you will need to set the list as AutomationProperties.ControlledPeers on the TextBox. ControlledPeers プロパティを追加または削除するたびに、このプロパティの AutomationPropertyChanged イベントを発生させる必要があります。また、この記事で既に説明したシナリオのタイプに応じて、独自の SelectionItemPatternOnElementSelected イベントまたは LayoutInvalidated イベントを発生させる必要があります。You must fire the AutomationPropertyChanged event for the ControlledPeers property every time you add or remove this property and also fire your own SelectionItemPatternOnElementSelected events or LayoutInvalidated events depending on your type of scenario, which was explained previously in this article.

HTML の実装HTML implementation

HTML で組み込みのコントロールを使っている場合は、UIA 実装が既にマップされています。If you are using the intrinsic controls in HTML, then the UIA implementation has already been mapped for you. 既に準備されている実装の例を次に示します。Below is an example of an implementation that is already hooked up for you:

<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 コントロールを設定する必要があります。If you are creating your own controls, you must set up your own ARIA controls, which are explained in the W3C standards.

グラフィックス内のテキストText in graphics

可能な限り、テキストをグラフィックスに含めないでください。Whenever possible, avoid including text in a graphic. たとえば、アプリで Image 要素として表示されるイメージ ソース ファイルにテキストを含めると、支援技術ではそのテキストのアクセスや読み取りを自動的に行うことはできません。For example, any text that you include in the image source file that is displayed in the app as an Image element is not automatically accessible or readable by assistive technologies. グラフィックス内でテキストを使う必要がある場合は、"alt テキスト" に相当するものとして指定する AutomationProperties.Name の値に、そのテキストまたはテキストの意味の要約を含めてください。If you must use text in graphics, make sure that the AutomationProperties.Name value that you provide as the equivalent of "alt text" includes that text or a summary of the text's meaning. これは、テキスト文字をベクトルから Path の一部として作成する場合や、Glyphs を使って作成する場合も同様です。Similar considerations apply if you are creating text characters from vectors as part of a Path, or by using Glyphs.

テキストのフォント サイズとスケールText font size and scale

ユーザーと、このフォントの用途は、単にアプリ内のテキストを読みづらくなってしまうことができますが小さすぎるように、アプリケーションで任意のテキストが妥当なサイズが最初に確認してください。Users can have difficulty reading text in an app when the fonts uses are simply too small, so make sure any text in your application is a reasonable size in the first place.

完了すると、明確な Windows にはさまざまなアクセシビリティ ツールとユーザーが活用し、独自のニーズとテキストを読み取るための基本設定を調整する設定が含まれます。Once you've done the obvious, Windows includes various accessibility tools and settings that users can take advantage of and adjust to their own needs and preferences for reading text. 次のようなクラスがあります。These include:

  • 拡大鏡ツール、UI の選択範囲を拡大します。The Magnifier tool, which enlarges a selected area of the UI. アプリ内のテキストのレイアウトが困難に拡大鏡を使用して、読み取り用に行う必要があります。You should ensure the layout of text in your app doesn't make it difficult to use Magnifier for reading.
  • スケールと解像度の設定をグローバル設定]、[システムの表示]-> [-> スケールとレイアウトします。Global scale and resolution settings in Settings->System->Display->Scale and layout. 正確にサイズ変更オプションが使用可能なディスプレイ デバイスの機能に依存とは異なります。Exactly which sizing options are available can vary as this depends on the capabilities of the display device.
  • テキスト サイズ設定設定、アクセスの容易さの表示-> します。Text size settings in Settings->Ease of access->Display. 調整、テキストを大きくすべてのアプリケーションと画面 (すべての UWP テキスト コントロールは、テキストをカスタマイズまたはテンプレートなしのエクスペリエンスをスケーリングをサポート) 間でのサポート コントロールでテキストのサイズだけを指定する設定。Adjust the Make text bigger setting to specify only the size of text in supporting controls across all applications and screens (all UWP text controls support the text scaling experience without any customization or templating).

注意

すべての大きな設定により、ユーザーのプライマリ画面のみに一般にテキストとアプリの推奨サイズを指定します。The Make everything bigger setting lets a user specify their preferred size for text and apps in general on their primary screen only.

さまざまなテキスト要素とコントロールには IsTextScaleFactorEnabled プロパティがあります。Various text elements and controls have an IsTextScaleFactorEnabled property. このプロパティの既定値は true です。This property has the value true by default. ときにtrue、その要素内のテキストのサイズをスケールできます。When true, the size of text in that element can be scaled. スケーリングが小規模のテキストに影響を与えますFontSizeが大規模なテキストに影響を与えるよりも高いにFontSizeします。The scaling affects text that has a small FontSize to a greater degree than it affects text that has a large FontSize. 要素の設定の自動サイズ変更を無効にしたIsTextScaleFactorEnabledプロパティをfalseします。You can disable automatic resizing by setting an element's IsTextScaleFactorEnabled property to false.

参照してくださいテキスト スケーリングの詳細。See Text scaling for more details.

次のマークアップをアプリに追加し、それを実行します。Add the following markup to an app and run it. 調整、テキスト サイズを設定して、それぞれに何が起こるか見てTextBlockします。Adjust the Text size setting, and see what happens to each TextBlock.

XAMLXAML

<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 テキストがユーザーにとっては重要なユーザー補助のスケーリングを無効にすることをお勧めします。We don't recommend that you disable text scaling as scaling UI text universally across all apps is an important accessibility experience for users.

TextScaleFactorChanged イベントと TextScaleFactor プロパティを使って、電話の [テキスト サイズ] 設定の変更に関する情報を確認することもできます。You can also use the TextScaleFactorChanged event and the TextScaleFactor property to find out about changes to the Text size setting on the phone. 方法は次のとおりです。Here’s how:

C#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]します。The value of TextScaleFactor is a double in the range [1,2.25]. 最も小さい文字がこの大きさまで拡大されます。The smallest text is scaled up by this amount. たとえば、この値を使ってテキストに合わせてグラフィックスを拡大縮小できます。You might be able to use the value to, say, scale graphics to match the text. ただし、すべてのテキストが同じ倍率で拡大縮小されるわけではないことに注意してください。But remember that not all text is scaled by the same factor. 一般に、最初の状態のテキストのサイズが大きいほど、拡大縮小の影響は小さくなります。Generally speaking, the larger text is to begin with, the less it’s affected by scaling.

次の型に IsTextScaleFactorEnabled プロパティがあります。These types have an IsTextScaleFactorEnabled property: