Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Основы специальных возможностей включают имя, роль и значение. В этом разделе показано, как предоставить эти свойства в приложении, чтобы вспомогательные технологии могли правильно интерпретировать пользовательский интерфейс.
Доступное имя
Доступное имя — это название, которое средство чтения с экрана использует для объявлений элемента пользовательского интерфейса. Задайте его на элементы, которые передают значение или поддержку взаимодействия, включая изображения, поля ввода, кнопки, элементы управления и регионы.
В следующей таблице описывается, как определить или получить доступное имя для различных типов элементов в пользовательском интерфейсе 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.
Связанные темы
Windows developer