Поделиться через


Предоставить основные сведения о доступности

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

Доступное имя

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

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

Тип элемента Описание
Статический текст Для элементов TextBlock и RichTextBlock доступное имя автоматически определяется из видимого (внутреннего) текста. Весь текст в этом элементе используется в качестве имени. См. название из внутреннего текста.
Изображения Элемент Image в XAML не имеет прямого аналога атрибуту alt в HTML для элементов img и аналогичных. Используйте AutomationProperties.Name для указания имени или воспользуйтесь методом создания подписей. См. доступные имена для изображений.
Элементы формы Доступное имя элемента формы должно совпадать с меткой, отображаемой для этого элемента. См. метки иLabeledBy.
Кнопки и ссылки По умолчанию доступное имя кнопки или ссылки основано на видимом тексте, используя те же правила, что и в разделе "Имя" из внутреннего текста. В случаях, когда кнопка содержит только изображение, используйте AutomationProperties.Name для предоставления текстового эквивалента предполагаемого действия кнопки.

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

Роль и значение

Элементы управления XAML предоставляют роль (и, если применимо, значение) через встроенную поддержку автоматизации пользовательского интерфейса. Проверьте эти свойства с помощью средств автоматизации пользовательского интерфейса или в документации по AutomationPeer каждого элемента управления. Роли сопоставляются с AutomationControlType и предоставляются вспомогательным технологиям через элемент управления AutomationPeer.

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

Замечание

Если вы явно установите AutomationProperties.Name, не повторяйте в имени такие термины роли или типа, как "button" или "list". Роль или тип берется из LocalizedControlType, и многие вспомогательные технологии добавляют этот тип к имени. Повторяющийся текст роли может создавать выходные данные, такие как кнопка "кнопка". Проверьте это поведение с помощью Narrator.

Влияние на представления дерева автоматизации пользовательского интерфейса

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

По умолчанию большинство элементов, производных от элемента управления, отображаются в представлении управления, когда приложение предоставляется с помощью UI Automation. В составных пользовательских интерфейсах это может привести к повторяющимся или незначительным узлам, которые создают помехи для пользователей вспомогательных технологий. Используйте AutomationProperties.AccessibilityView, чтобы управлять тем, как конкретные элементы отображаются в представлениях дерева. Например, размещение элемента в Raw обычно сохраняет его доступным для диагностических и обходных сценариев, исключая его из основных представлений, используемых многими вспомогательными технологиями. Чтобы просмотреть реальные шаблоны, проверьте шаблоны элементов управления в generic.xaml и найдите AutomationProperties.AccessibilityView.

Имя из внутреннего текста

Многие элементы управления XAML могут получить значение по умолчанию из текста, который уже виден в пользовательском интерфейсе. Это поведение снижает необходимость явным образом задавать AutomationProperties.Name для распространенных текстовых шаблонов и помогает обеспечить соответствие между тем, что пользователи слышат, и тем, что они видят.

  • TextBlock, RichTextBlock и TextBox обычно используют их текст как имя по умолчанию для доступа.
  • Подклассы ContentControl оценивают значение содержимого и используют итеративную стратегию "ToString" для извлечения строкового содержимого для доступного имени по умолчанию.

Замечание

Автоматизация UI накладывает ограничение в 2048 символов для доступного имени. Если автоматическое создание имен создает длинную строку, значение усечено.

Доступные имена изображений

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

<Image
    Source="Assets/product.png"
    AutomationProperties.Name="Customer using the product" />

В качестве альтернативы отобразите видимую подпись и свяжите её с изображением через AutomationProperties.LabeledBy. Это помогает синхронизировать звуковую метку с текстом на экране и избежать дублирования строк в разметке. В следующем примере WinUI показан этот шаблон:

<StackPanel Spacing="8">
    <Image
        x:Name="heroImage"
        Width="480"
        Source="Assets/snoqualmie-NF.jpg"
        AutomationProperties.LabeledBy="{Binding ElementName=heroCaption}" />
    <TextBlock x:Name="heroCaption" Text="Mount Snoqualmie Skiing" />
</StackPanel>

Метки и идентифицированный по

Для полей формы предпочтительный шаблон маркировки — определить видимый текст меток в TextBlock и ссылаться на этот элемент из элемента управления входными данными через AutomationProperties.LabeledBy. Это создает связь между меткой пользовательского интерфейса и элементом управления в дереве автоматизации, поэтому вспомогательные технологии могут объявлять имя поля, соответствующее показанному на экране. Как правило, этот шаблон легче поддерживать, чем дублировать текст метки в нескольких свойствах, поскольку одна и та же исходная строка задает и визуальную, и доступную метку.

<StackPanel x:Name="LayoutRoot" Spacing="12">
    <StackPanel Orientation="Horizontal" Spacing="8">
        <TextBlock x:Name="firstNameLabel" Text="First name" />
        <TextBox
            x:Name="firstNameTextBox"
            Width="180"
            AutomationProperties.LabeledBy="{Binding ElementName=firstNameLabel}" />
    </StackPanel>

    <StackPanel Orientation="Horizontal" Spacing="8">
        <TextBlock x:Name="lastNameLabel" Text="Last name" />
        <TextBox
            x:Name="lastNameTextBox"
            Width="180"
            AutomationProperties.LabeledBy="{Binding ElementName=lastNameLabel}" />
    </StackPanel>
</StackPanel>

Доступное описание (необязательно)

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

В экранном дикторе описание обычно читается по запросу, а не как часть стандартного объявления. Пользователи могут запросить эту дополнительную информацию, нажав клавишу CapsLock+F.

Обработайте доступное имя как основной идентификатор элемента управления и оставьте его кратким. Если требуется более подробное описание, укажите дополнительные сведения через AutomationProperties.HelpText в дополнение к AutomationProperties.Name.

Тестирование доступности на ранних этапах и регулярно

Самый надежный способ проверки поддержки средства чтения с экрана заключается в том, чтобы протестировать приложение непосредственно с помощью средства чтения с экрана во время разработки, а не только во время выпуска. Раннее и повторное тестирование помогает выявить отсутствующие или вводящие в заблуждение доступные имена, неправильное представление управления и проблемы навигации, в то время как изменения всё ещё легко исправить. После каждого прохождения уточните структуру пользовательского интерфейса и свойства автоматизации на основе того, как пользователи это слышат и взаимодействуют с интерфейсом. Дополнительные сведения см. в разделе "Тестирование специальных возможностей".

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

Доступные имена из динамических данных

Многие элементы управления Windows отображают содержимое с помощью привязки данных, что означает, что доступные имена часто определяются из данных среды выполнения, а не из статического XAML. Если шаблоны списков или элементов заполняются динамически, убедитесь, что каждый созданный элемент предоставляет понятное понятное имя после завершения привязки. В зависимости от композиции элементов управления и шаблона может потребоваться задать или обновить свойства специальных возможностей программным способом, чтобы дерево автоматизации отражало окончательное состояние отрисовки. Полный пример см. в разделе "Сценарий 4" в примере специальных возможностей XAML (архивированный пример устаревшей версии).

Доступные имена и локализация

Имена доступных элементов должны быть локализованы с той же строгостью, что и видимый текст пользовательского интерфейса. Храните строки меток в ресурсах локализации и подключайте их с помощью сопоставлений директив x:Uid , чтобы выводимые данные соответствовали языку пользователя. Если вы явно задаете AutomationProperties.Name, убедитесь, что значение также поступает из локализованных ресурсов, а не из жестко закодированного текста.

Присоединенные свойства в AutomationProperties используют квалифицированный синтаксис ключа ресурса, чтобы локализация могла нацеливаться на присоединенное свойство определенного элемента. Например, если элемент называется MediumButton, ключ ресурса для AutomationProperties.Name это MediumButton.[using:Microsoft.UI.Xaml.Automation]AutomationProperties.Name.