Требования к специальным возможностям отображения текста

В этой статье приводятся рекомендации относительно специальных возможностей отображения текста в приложении, которые помогают обеспечить необходимый уровень контрастности между цветами текста и фона. Кроме того, в статье описываются роли модели автоматизации пользовательского интерфейса Майкрософт, которые могут быть присущи элементам текста в приложениях универсальной платформы Windows (UWP) на языках программирования C++, C# и Visual Basic, а также рекомендации относительно использования текста в графике.

Коэффициенты контрастности

Хотя у пользователей всегда есть возможность переключиться в режим высокой контрастности, с точки зрения дизайна текста в вашем приложении её стоит рассматривать как крайний шаг. Имеет смысл удостовериться, что текст вашего приложения соответствует рекомендациям по уровню контрастности между текстом и фоном. Оценка уровня контрастности основана на детерминированных методах, которые не учитывают оттенок цвета. Например, если у вас имеется красный текст на зеленом фоне, то этот текст может оказаться нечитабельным для людей, страдающих дальтонизмом. Проверка и исправление коэффициента контрастности поможет избежать подобных проблем.

За основу приведенных здесь рекомендаций по контрастности текста взяты стандарты специальных возможностей в Интернете 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 Методики для WCAG 2.0.

Чтобы видимый текст соответствовал требованиям специальных возможностей, коэффициент его контрастности должен составлять не менее 4,5:1 по отношению к фону. В число исключений входят логотипы и несущественный текст, например текст, являющийся частью неактивного компонента пользовательского интерфейса.

Исключается также декоративный текст и текст, не несущий информации. Например, если для создания фона используются случайные слова, которые можно переставить или заменить без изменения смысла, эти слова считаются декоративными и могут не соответствовать этому критерию.

Проверьте допустимость контрастности видимого текста с помощью средств измерения цветового контраста. Сведения о средствах измерения коэффициента контрастности см. в разделе Методики WCAG 2.0 G18 (Раздел ресурсов).

Примечание

Некоторые средства, перечисленные в методиках для WCAG 2.0 G18, нельзя интерактивно использовать с приложениями UWP. Вам может понадобиться вручную ввести значения цвета фона и переднего плана в средство или же сделать снимки экрана для пользовательского интерфейса вашего приложения и применить к ним средство измерения коэффициента контрастности.

Роли текстового элемента

Приложение UWP может использовать следующие элементы по умолчанию (обычно они называются текстовыми элементами или элементами управления Textedit):

Когда элемент управления сообщает, что имеет роль Правка, специальные возможности предполагают наличие у пользователей способов изменения этих значений. Поэтому если вы поместите статический текст в элемент TextBox, вы неправильно сообщите пользователю специальных возможностей о роли (а значит, и о структуре) вашего приложения.

В текстовых моделях XAML существует два элемента, которые в основном используются для статического текста: TextBlock и RichTextBlock. Ни один из них не относится к подклассу Control, и поэтому они не поддерживают перемещение фокуса с помощью клавиатуры и не могут отображаться в последовательности табуляции. Но это не означает, что специальные возможности не могут их считывать. Средства чтения с экрана обычно рассчитаны на поддержку нескольких режимов чтения содержимого в приложении, включая специальный режим чтения или шаблоны навигации, которые не работают с фокусом и последовательностью табуляции, например "виртуальный курсор". Поэтому не стоит размещать статический текст в контейнерах с поддержкой фокуса только затем, чтобы пользователь мог попадать в них с помощью последовательности табуляции. Пользователи специальных возможностей ожидают, что со всеми элементами в последовательности табуляции можно взаимодействовать, и если они столкнутся со статическим текстом, это скорее запутает их, чем поможет. Вы должны самостоятельно провести тестирование с помощью экранного диктора, чтобы оценить взаимодействие пользователя с приложением при использовании средства чтения с экрана для проверки статического текста приложения.

Доступность автозаполнения

Если пользователь вводит данные в поле и появляется список предложений, это называется автозаполнением. Такая функция используется для поля Кому: сообщения, поля поиска Кортаны в Windows, поля ввода URL-адреса в Microsoft Edge, поля ввода расположения в приложении "Погода" и т. д. Если вы используете XAML-элемент AutosuggestBox или встроенные элементы управления HTML, эта функция уже реализована по умолчанию. Чтобы предоставить доступ к этой функции, необходимо связать поле ввода и список. Это описано в разделе Реализация автозаполнения.

Экранный диктор был обновлен, чтобы использовать эту функцию со специальным режимом предложений. Если поле и список правильно связаны, пользователи:

  • будут знать о наличии списка и его закрытии;
  • будут знать о количестве доступных предложений;
  • будут знать выбранный элемент, если имеется;
  • смогут переместить фокус экранного диктора на список;
  • смогут переходить по вариантам с помощью всех других режимов чтения.

Список вариантов
Пример списка вариантов

Реализация автозаполнения

Чтобы предоставить доступ к этой функции, необходимо связать поле ввода и список в дереве автоматизации пользовательского интерфейса (UIA). Это происходит с помощью свойства UIA_ControllerForPropertyId для классических приложений или свойства ControlledPeers для приложений UWP.

На высоком уровне существует два типа автозаполнения.

Выбор по умолчанию
Если в списке выбрано значение по умолчанию, экранный диктор ищет событие UIA_SelectionItem_ElementSelectedEventId в классическом приложении или событие AutomationEvents.SelectionItemPatternOnElementSelected для запуска в приложении UWP. Каждый раз, когда меняется выбранный элемент, пользователь вводит другую букву, варианты обновляются или пользователь переходит по списку, срабатывает событие ElementSelected.

Список с выделением по умолчанию
Пример с выделением по умолчанию

Без выделения по умолчанию
Если элемент по умолчанию не выбран, как в поле расположения приложения "Погода", экранный диктор ждет событие UIA_LayoutInvalidatedEventId или LayoutInvalidated для UWP, которое инициируется при каждом обновлении списка.

Список без выделения по умолчанию
Пример без выделения по умолчанию

Реализация XAML

Если вы используете XAML-элемент AutosuggestBox по умолчанию, то все уже реализовано. Если вы реализуете собственную функцию автозаполнения с помощью TextBox и списка, необходимо настроить его как AutomationProperties.ControlledPeers в элементе TextBox. Необходимо вызывать событие AutomationPropertyChanged свойства ControlledPeers при каждом добавлении и удалении этого свойства, а также вызывать собственные события SelectionItemPatternOnElementSelected или LayoutInvalidated в зависимости от типа сценария, описанного ранее.

Реализация HTML

Если вы применяете встроенные элементы управления в HTML, то модель автоматизации пользовательского интерфейса уже реализована. Ниже приведен пример автоматической реализации.

<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>

Если вы создаете собственные элементы управления, вам придется настроить свои управления ARIA, которые описаны в стандартах W3C.

Текст в графике

По возможности избегайте включения текста в графику. Например, любой текст, помещаемый в файл источника изображения, который воспроизводится в приложении в качестве элемента Image, не является автоматически доступным (или доступным для чтения) для специальных возможностей. Если обязательно использовать текст в графике, убедитесь, что значение AutomationProperties.Name, которое вы предоставляете как эквивалент замещающему тексту, содержит нужный текст или краткую сводку о смысле текста. Те же принципы актуальны при создании текстовых символов из векторов как часть пути или с использованием глифов.

Размер и масштаб шрифта текста

Пользователи могут испытывать трудности с чтением текста в приложении, если шрифты слишком малы, поэтому убедитесь, что любой текст в приложении имеет разумный размер.

После того как вы сделали очевидное, Windows включает различные специальные возможности и параметры, которые пользователи могут использовать и настраивать в соответствии со своими потребностями и предпочтениями при чтении текста. К ним относятся следующие объекты.

  • Экранная лупа, которая увеличивает выбранную область пользовательского интерфейса. Убедитесь, что макет текста в приложении не усложняет использование экранной лупы для чтения.
  • Глобальные параметры масштабирования и разрешения в разделе Параметры-Система-Дисплей-Масштаб>>> и макет. Доступные параметры изменения размера зависят от возможностей устройства отображения.
  • Параметры размера текста в разделе Параметры-Специальные> возможности-Дисплей>. Настройте параметр Увеличить текст , чтобы указать только размер текста в вспомогательных элементах управления для всех приложений и экранов (все текстовые элементы управления 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"/>

Не рекомендуется отключать масштабирование текста, так как универсальное масштабирование текста пользовательского интерфейса во всех приложениях — это важный интерфейс специальных возможностей для пользователей.

Можно также воспользоваться событием TextScaleFactorChanged и свойством TextScaleFactor, чтобы узнать об изменениях настройки размер шрифта на телефоне. Этот процесс описывается далее.

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 равно double в диапазоне [1,2,25]. Самый маленький текст масштабируется по этому значению. С помощью этого значения можно, например, масштабировать графику в соответствии с текстом. Однако помните, что не весь текст масштабируется с одинаковым коэффициентом. В целом чем больше текст, тем меньше он подвергается масштабированию.

Данные типы имеют свойство IsTextScaleFactorEnabled:

Примеры

Совет

Приложение коллекции WinUI 3 содержит интерактивные примеры большинства элементов управления, функций и функций WinUI 3. Получение приложения из Microsoft Store или получение исходного кода на GitHub