Доступность приложений Windows: UI Automation и разумное приспособление

«Сотрудник с нарушением зрения не может пользоваться нашей основной системой ввода заказов с программой чтения с экрана. Браузером и почтой пользуется без проблем, а в нашем бизнес-приложении объявления не работают.» Такие вопросы от ИТ-служб заказчиков слышим всё чаще.

Исходная точка решения — смотреть не на то, как выглядит экран, а на что вы сообщаете вспомогательным технологиям. В Windows есть UI Automation (UIA) — механизм, через который программы чтения с экрана читают сведения приложения. Когда понятно, как он работает, и закрыты основы имён, клавиатуры и цвета, пользоваться бизнес-приложением становится заметно проще.¹

И юридически внутренние приложения Windows не исключение. Поправка 2021 года к Закону об устранении дискриминации в отношении инвалидов вступила в силу 1 апреля 2024 года: организации тоже обязаны предоставлять разумное приспособление. Сфера занятости, как в примере из начала, регулируется Законом о содействии трудоустройству инвалидов и является обязанностью работодателя с апреля 2016 года. Глава 2 разбирает это различие.²³

По доступности настольных приложений Windows материалов меньше, чем по вебу, и волшебного решения «потом навесить» нет. Но большая часть нужных правок повышает производительность всех пользователей, с инвалидностью или без.

Статья рассчитана на разработчиков японских бизнес-приложений и сотрудников ИТ-служб. Она покрывает законодательную рамку и стандарты и устройство UIA, затем переходит к реализации в WinForms/WPF, работе с клавиатуры, цвету и контрасту, проверке и тому, как расставлять приоритеты исправлений.

flowchart TB
    accTitle: Ход этой статьи
    accDescr: Структура статьи, которая по порядку связывает законодательную рамку и стандарты, устройство UI Automation, реализацию в WinForms и WPF, работу с клавиатуры, цвет и контраст, инструменты проверки и то, как расставлять приоритеты
    law["Законодательная рамка и стандарты"] --> uia["Устройство UI Automation"]
    uia --> impl["Реализация в WinForms/WPF"]
    impl --> kb["Работа с клавиатуры"]
    kb --> color["Цвет и контраст"]
    color --> verify["Инструменты проверки"]
    verify --> prio["Как расставлять приоритеты"]

Рис. 1: Статья связывает законодательную рамку, механизм, реализацию, проверку и приоритеты в одну линию.

1. Сначала выводы

Три пункта, которые взять в первую очередь.

1. Отделяйте индивидуальное разумное приспособление от предварительного обустройства среды. Разумное приспособление — процесс ответа на обращение через конструктивный диалог в пределах, не составляющих чрезмерное бремя. Для организаций это обязанность с апреля 2024 года, для работодателей в сфере занятости — с апреля 2016 года. Заранее доработать приложение относится к «обустройству среды» (обязанность прилагать усилия), что отличается от требования сделать каждый экран идеальным с самого начала.²³
2. Технический фундамент — публикация сведений в UIA плюс основы имён, клавиатуры и цвета. Name и ControlType дерева UIA и шаблоны вроде Invoke, Value и SelectionItem — материал для объявления и действий. Имена — в первую очередь. В WinForms это AccessibleName и связь Label с порядком табуляции, в WPF — AutomationProperties.Name/LabeledBy; плюс работа с клавиатуры, цветовая схема с ориентиром на коэффициент контрастности 4,5:1 и отображение, которое не опирается только на цвет.¹⁴⁵⁶
3. Проверяйте и чините, начиная с реальной работы. Совмещайте FastPass в Accessibility Insights с практическими проверками программой чтения с экрана и идите по экранам, на которые опирается пользователь, затем новым экранам, затем общим элементам управления — в этом порядке. Те же правки помогают и автоматическим UI-тестам вроде FlaUI, которые используют тот же фундамент UIA.⁷

Технические критерии можно организовать вокруг WCAG. JIS X 8341-3:2016 — идентичный стандарт с тем же содержанием, что WCAG 2.0, а WCAG2ICT даёт указания, как применять его к не-веб-ПО. Раздел 2.2 идёт в подробности.⁸⁹

Если читать по цели, начинайте с главы ниже.

Одной фразой: поддержка доступности значит «публиковать правильные имена и операции в дереве UIA и держаться основ клавиатуры и цвета».

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 16, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

2. Законодательная рамка и стандарты — что изменила «обязанность»

2.1. Закон об устранении дискриминации в отношении инвалидов — с апреля 2024 года организации тоже обязаны предоставлять разумное приспособление

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

Разумное приспособление организациями сменилось с обязанности прилагать усилия на обязанность

Закон об устранении дискриминации в отношении инвалидов запрещает административным органам и организациям «несправедливое дискриминационное обращение» с инвалидами и требует «предоставлять разумное приспособление». Поправкой 2021 года (Рэйва 3) предоставление разумного приспособления организациями, до того обязанность прилагать усилия, стало обязанностью, и поправка вступила в силу 1 апреля 2024 года (Рэйва 6).²

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

Считайте предварительные правки приложения «обустройством среды»

Иметь всё готовым заранее — не то, что стало обязанностью. Меры, принятые заранее для неопределённого круга инвалидов, например пересмотр руководств, обучение и безбарьерность помещений, называют «обустройством среды» и позиционируют как обязанность прилагать усилия.²

Заранее привести бизнес-приложение в состояние, которым может пользоваться программа чтения с экрана, можно считать усилием на этой стороне обустройства среды. Чем дальше зашло это улучшение, тем легче бремя предоставления индивидуального разумного приспособления.

Где задействованы сотрудники, смотрите Закон о содействии трудоустройству инвалидов

Занятость и работа регулируются Законом о содействии трудоустройству инвалидов, а не Законом об устранении дискриминации в отношении инвалидов. Листовка Канцелярии Кабинета министров тоже отмечает это различие.²

По Закону о содействии трудоустройству инвалидов поправка, вступившая в силу в апреле 2016 года (Хэйсэй 28), обязывает работодателей воздерживаться от дискриминации по инвалидности при трудоустройстве и предоставлять разумное приспособление в пределах, не составляющих чрезмерное бремя. Вопрос из начала, «сотрудник не может пользоваться бизнес-приложением», поэтому давно в зоне обязанности — задолго до 2024 года.³

flowchart TB
    accTitle: Куда относятся разумное приспособление и обустройство среды
    accDescr: Отношения общей организации и человека с инвалидностью регулирует Закон об устранении дискриминации в отношении инвалидов, и предоставление разумного приспособления ответом на индивидуальное обращение через конструктивный диалог — обязанность с апреля 2024 года; сфера занятости — обязанность работодателя с апреля 2016 года по Закону о содействии трудоустройству инвалидов; заранее доработать приложение относится к обустройству среды, обязанности прилагать усилия
    scene{"Какая сцена?"} -->|Организация и человек с инвалидностью| kaisho["Закон об устранении дискриминации в отношении инвалидов"]
    scene -->|Занятость и работа| koyou["Закон о содействии трудоустройству инвалидов"]
    kaisho --> moushide["Отвечать на индивидуальные обращения через конструктивный диалог"]
    moushide --> hairyo["Предоставление разумного приспособления (обязанность с апреля 2024 года)"]
    koyou --> koyougimu["Предоставление разумного приспособления (обязанность с апреля 2016 года)"]
    kaisho -.-> kankyo["Предварительные правки приложения = обустройство среды (обязанность прилагать усилия)"]
    kankyo -.-> moushide

Рис. 2: Применимый закон зависит от сцены; разумное приспособление — обязанность, а предварительные правки относятся к обустройству среды, обязанности прилагать усилия.

Как конкретный случай трактуется в праве, зависит от ситуации. Эта статья не идёт в юридическое толкование; она исходит из того, что может сделать инженер, когда его просят ответить. Первичные источники — материалы Канцелярии Кабинета министров и Министерства здравоохранения, труда и благосостояния.²³

2.2. JIS X 8341-3 и WCAG — «критерии веба» распространяются и на ПО

Когда читаете технические стандарты подробно, организовать их вокруг WCAG даёт самую ясную картину. JIS X 8341-3:2016, WCAG и WCAG2ICT связаны так.⁸⁶⁹

На вопрос «разве WCAG не стандарт для веб-контента?» мост — WCAG2ICT. Полное название — Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies.⁹

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

flowchart TB
    accTitle: Связь JIS X 8341-3 и WCAG
    accDescr: JIS X 8341-3:2016 — идентичный стандарт с тем же содержанием, что WCAG 2.0, а WCAG2ICT показывает, как применять критерии успеха WCAG к не-веб-ПО, поэтому настольное приложение Windows можно проверять в той же рамке
    wcag["WCAG 2.0 (W3C)"] ---|Идентичный стандарт с тем же содержанием| jis["JIS X 8341-3:2016"]
    wcag --> ict["WCAG2ICT"]
    ict --> soft["Применено к не-веб-ПО"]
    soft --> app["Настольные приложения Windows"]

Рис. 3: JIS X 8341-3:2016 — идентичный стандарт WCAG 2.0, а WCAG2ICT распространяет те же критерии на настольные приложения.

3. Как вспомогательные технологии читают приложение — тройка UI Automation

3.1. Дерево UIA, свойства и шаблоны элементов управления

UI Automation (UIA), встроенная в Windows, — платформа доступности, которая посредничает между приложением и вспомогательными технологиями. Приложение публикует сведения UI как «поставщик», а вспомогательная технология вроде программы чтения с экрана получает их как «клиент». Операции UI средствами, отличными от стандартного ввода, тоже возможны благодаря этому механизму.¹

Начните с понимания как тройки: структура экрана, природа каждого элемента и доступные операции.¹

Например, объявление «Подтвердить заказ, кнопка», когда кнопка получает фокус, — примерно сочетание Name и типа элемента управления. Когда пользователь выдаёт команду выполнить, вспомогательная технология нажимает кнопку через шаблон Invoke.

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

flowchart TB
    accTitle: Тройка UI Automation
    accDescr: Приложение как поставщик публикует свойства и шаблоны элементов управления каждого элемента в дереве UIA; программа чтения с экрана как клиент объявляет Name и ControlType и действует через шаблоны вроде Invoke
    app["Приложение (поставщик)"] --> tree["Дерево UIA"]
    tree --> prop["Свойства (Name, ControlType и т. д.)"]
    tree --> pat["Шаблоны (Invoke, Value и т. д.)"]
    sr["Программа чтения с экрана (клиент)"] -->|Объявляет| prop
    sr -->|Действует| pat

Рис. 4: Программа чтения с экрана использует свойства и шаблоны, которые приложение опубликовало в дереве UIA, для объявления и действий.

3.2. Программа чтения с экрана — клиент UIA

Основные программы чтения с экрана в Windows — встроенный Экранный диктор (Narrator), свободный с открытым исходным кодом NVDA¹⁰ и PC-Talker, коммерческий продукт, широко используемый в Японии.

У каждой свой стиль объявления, но основной путь чтения UI настольного приложения во всех случаях — UIA. Поэтому работа на стороне приложения сводится к публикации правильных сведений в UIA, а не к поддержке конкретной программы чтения с экрана.

flowchart TB
    accTitle: Общий путь основных программ чтения с экрана
    accDescr: Если приложение публикует правильные сведения в UIA, Экранный диктор, NVDA и PC-Talker все могут читать UI одним путём, поэтому работа на стороне приложения не нацелена на конкретную программу, а сводится к публикации сведений в UIA
    app["Приложение"] -->|Публикует сведения| uia["UI Automation (UIA)"]
    uia --> nar["Экранный диктор"]
    uia --> nvda["NVDA"]
    uia --> pct["PC-Talker"]
    app -.-> goal["Работа сводится к публикации в UIA"]

Рис. 5: Основные программы чтения с экрана все идут через UIA, поэтому работа приложения сводится к публикации сведений в UIA.

3.3. Как объявляется «кнопка с пустым Name»?

Допустим, на панели инструментов есть кнопка «Сохранить», которая показывает только иконку дискеты. Хотя назначение визуально ясно, если Name оставить пустым, программа чтения с экрана объявляет не больше чем «кнопка». Если соседние «Открыть» и «Печать» в том же состоянии, пользователь слышит только «кнопка, кнопка, кнопка» и не может их различить.

Кнопки без Name и изображения, объявляемые только как «Image», перечислены в руководствах Microsoft по исправлениям как типичные проблемы, которые останавливают работу пользователя.⁵

Стандартные элементы WinForms/WPF поддерживают UIA с самого начала, и у большинства Name выводится автоматически из текста или метки. Три типичных способа поломки такие.

Следующие две главы связывают эту сортировку с правками для WinForms и WPF соответственно.

flowchart TB
    accTitle: Три типичных способа, которыми ломается объявление
    accDescr: Объявление ломается, когда нет материала для имени, потому что элемент только с иконкой, когда нет связи с меткой или когда собственная отрисовка не кладёт сведения в дерево UIA, и элемент в итоге объявляется только как кнопка
    c1["Только иконка, нет материала"] --> broken["Name оказывается пустым"]
    c2["Нет связи с меткой"] --> broken
    c3["Собственная отрисовка ничего не публикует"] --> broken
    broken --> result["Объявляется только как кнопка"]

Рис. 6: Сломанные объявления обычно сводятся к трём шаблонам: нет материала для имени, нет связи или собственная отрисовка.

4. Реализация в WinForms — AccessibleName и порядок табуляции

4.1. Элементы, у которых Text становится Name автоматически, и элементы, у которых нет

Сначала проверьте, относится ли элемент к типу, у которого Text используется как имя

В WinForms даже среди элементов, которые показывают текст, одни используют Text как UIA Name, а другие нет.⁴

Используйте отображаемую метку и задавайте AccessibleName там, где метку поставить нельзя

Самый простой в сопровождении подход — поставить описательный Label непосредственно перед целевым элементом в порядке табуляции. Если TabIndex целевого элемента идёт сразу после TabIndex Label, текст Label используется как UIA Name. Отображение и объявление совпадают, и вы избегаете вести формулировку дважды.⁴¹¹

Там, где Label поставить нельзя, задайте AccessibleName явно. Можно также задать AccessibleDescription для дополнительной информации и AccessibleRole, когда роль должна совпадать с тем, что элемент на деле делает.¹²

flowchart TB
    accTitle: Как решается имя элемента WinForms
    accDescr: Для Button и подобных Text становится UIA Name как есть; для элементов вроде TextBox, чей Text не переиспользуется, используется текст Label, поставленного непосредственно перед в порядке табуляции; где Label поставить нельзя, AccessibleName задают явно
    ctrl["Элемент"] --> qtext{"Text становится Name?"}
    qtext -->|Да| usetext["Text используется как Name как есть"]
    qtext -->|Нет| qlabel{"Label непосредственно перед в порядке табуляции?"}
    qlabel -->|Да| uselabel["Текст Label используется как Name"]
    qlabel -->|Нет| explicit["Задать AccessibleName явно"]

Рис. 7: Name в WinForms решается в порядке Text, Label непосредственно перед в порядке табуляции, затем AccessibleName.

// Кнопка панели только с иконкой: задать имя для объявления явно
saveToolStripButton.AccessibleName = "Сохранить";

// Кнопка только с изображением: имя плюс дополнительное описание
btnSearchCustomer.AccessibleName = "Поиск клиентов";
btnSearchCustomer.AccessibleDescription = "Ищет в справочнике клиентов по коду или имени";

// Поле ввода, где Label нельзя поставить непосредственно перед в порядке табуляции: задать напрямую
txtOrderNo.AccessibleName = "Номер заказа";

// PictureBox, переиспользованный как диаграмма: роль должна совпадать с тем, что это на деле
pictureBoxChart.AccessibleRole = AccessibleRole.Chart;
pictureBoxChart.AccessibleName = "Диаграмма числа заказов по месяцам";

Когда вы очистили имя, но объявление по умолчанию не возвращается

Если вы один раз задали AccessibleName в панели свойств Visual Studio, а затем очистили, в файле конструктора может остаться настройка с пустой строкой. Если эта настройка блокирует разрешение имени по умолчанию, удалите строку из файла конструктора.⁴

flowchart TB
    accTitle: Проблема оставшегося AccessibleName с пустой строкой
    accDescr: Если один раз задать AccessibleName в панели свойств, а затем очистить, в файле конструктора остаётся настройка с пустой строкой и блокирует разрешение имени по умолчанию, поэтому исправляют удалением строки из файла конструктора
    set["Задать AccessibleName"] --> erase["Очистить в панели свойств"]
    erase --> remain["Остаётся настройка с пустой строкой"]
    remain --> block["Блокирует разрешение имени по умолчанию"]
    block -.-> fix["Удалить строку из файла конструктора"]

Рис. 8: Очистка значения в панели свойств оставляет пустую строку, поэтому исправляйте удалением строки из файла конструктора.

4.2. Частые правки на экране ввода заказов

Вот чек-лист мест, которые мы чаще всего чиним в бизнес-приложениях.

Каждая — правка на несколько строк, но для пользователя программы чтения с экрана это разница между экраном, которым нельзя пользоваться, и экраном, которым можно.

5. Реализация в WPF — AutomationProperties и AutomationPeer

5.1. AutomationProperties.Name / LabeledBy / HelpText

Дайте кнопке имя через строковый Content или явную настройку

У элемента, чей Content — строка, например у кнопки WPF, это содержимое используется как UIA Name. У кнопки, содержащей только Image или Path, напротив, нет материала для имени. Либо задайте явно через AutomationProperties.Name, либо, если рядом есть отображаемый текст, свяжите через AutomationProperties.LabeledBy.⁵

В TextBox отделяйте «имя» от «введённого значения»

Text у TextBlock переиспользуется как Name, но Text у TextBox публикуется в свойстве UIA Value и не становится Name. Даже когда поле держит значение, одно это не говорит пользователю, для чего поле.¹³

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

<!-- Поле ввода: связать отображаемую метку через LabeledBy -->
<TextBlock x:Name="OrderNoLabel" Text="Номер заказа" />
<TextBox
    AutomationProperties.LabeledBy="{Binding ElementName=OrderNoLabel}"
    AutomationProperties.AutomationId="OrderNoTextBox" />

<!-- Кнопка только с иконкой: задать имя явно и добавить дополнение при необходимости -->
<Button
    AutomationProperties.Name="Подтвердить заказ"
    AutomationProperties.HelpText="Подтверждает вводимый заказ и резервирует запас">
    <Path Data="{StaticResource CheckIconGeometry}" Width="16" Height="16" />
</Button>

flowchart TB
    accTitle: Как решается имя элемента WPF
    accDescr: Элемент, чей Content — строка, использует это содержимое как Name; иначе первый выбор — связать ближайшую отображаемую метку через LabeledBy, а если её нет, AutomationProperties.Name задают явно; Text у TextBox публикуется как Value, не как Name
    ctrl["Элемент"] --> qc{"Content — строка?"}
    qc -->|Да| auto["Содержимое становится Name"]
    qc -->|Нет| ql{"Рядом отображаемая метка?"}
    ql -->|Да| lb["Связать через LabeledBy"]
    ql -->|Нет| nm["Задать Name явно"]
    tbx["Text у TextBox"] -.-> val["Публикуется как Value, не как Name"]

Рис. 9: Name в WPF решается в порядке строковый Content, LabeledBy, затем явная настройка; Text у TextBox не становится Name.

HelpText и AutomationId играют роли, отличные от имени

Дополнительная информация, которая не помещается в Name, публикуется через AutomationProperties.HelpText.⁵ AutomationId — идентификатор, который также используют, чтобы находить элементы в автоматических UI-тестах. Решение о соглашении именования на этапе проектирования экрана окупается в последующих тестах.

Коротко: Name — назначение, HelpText — дополнение, AutomationId — идентификатор. Как они используются в автоматических тестах, подробно разобрано в «UI-автотестах десктопных приложений Windows».

5.2. Собственным элементам нужен AutomationPeer

Элемент с собственной отрисовкой сам по себе не может публиковать осмысленные сведения в дереве UIA. В WPF вы публикуете имя, тип и шаблоны, переопределяя OnCreateAutomationPeer в классе, производном от UIElement, и возвращая класс, производный от AutomationPeer.¹⁴

Если наследуете существующий элемент, наследуйте и соответствующий Peer. Для ButtonBase, например, использование ButtonBaseAutomationPeer позволяет перенести уже реализованное поведение.¹⁴

flowchart TB
    accTitle: Как AutomationPeer публикует сведения
    accDescr: Собственный элемент публикует имя, тип и шаблоны, переопределяя OnCreateAutomationPeer и возвращая класс, производный от AutomationPeer; если наследует существующий элемент, наследует соответствующий Peer и переносит уже реализованное поведение
    custom["Собственный элемент"] --> ov["OnCreateAutomationPeer"]
    ov --> peer["Вернуть класс, производный от Peer"]
    peer --> pub["Опубликовать имя, тип и шаблоны"]
    inherit["Наследует существующий элемент"] -.-> basepeer["Наследовать соответствующий Peer"]
    basepeer -.-> reuse["Перенести реализованное поведение"]

Рис. 10: Собственный элемент возвращает Peer из OnCreateAutomationPeer, чтобы опубликовать сведения в UIA.

// Пример элемента, который сам рисует состояние линии как цветную лампу
public class StatusLamp : Control
{
    public static readonly DependencyProperty IsOnlineProperty =
        DependencyProperty.Register(nameof(IsOnline), typeof(bool), typeof(StatusLamp),
            new FrameworkPropertyMetadata(false,
                FrameworkPropertyMetadataOptions.AffectsRender, OnIsOnlineChanged));

    public bool IsOnline
    {
        get => (bool)GetValue(IsOnlineProperty);
        set => SetValue(IsOnlineProperty, value);
    }

    internal static string NameFor(bool isOnline)
        => isOnline ? "Состояние линии: онлайн" : "Состояние линии: офлайн";

    private static void OnIsOnlineChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
    {
        // Поднять событие смены свойства UIA в момент смены значения. Без него
        // программа чтения с экрана держит старое имя и никогда не замечает смену состояния
        if (UIElementAutomationPeer.FromElement((UIElement)d) is AutomationPeer peer)
        {
            peer.RaisePropertyChangedEvent(
                AutomationElementIdentifiers.NameProperty,
                NameFor((bool)e.OldValue), NameFor((bool)e.NewValue));
        }
    }

    protected override AutomationPeer OnCreateAutomationPeer()
        => new StatusLampAutomationPeer(this);
}

public class StatusLampAutomationPeer : FrameworkElementAutomationPeer
{
    public StatusLampAutomationPeer(StatusLamp owner) : base(owner) { }

    protected override AutomationControlType GetAutomationControlTypeCore()
        => AutomationControlType.Text; // Text подходит для отображения состояния без операций

    protected override string GetNameCore()
        => StatusLamp.NameFor(((StatusLamp)Owner).IsOnline);
}

Уведомляйте о смене состояния, а не только о текущем имени

Пример выше совмещает две вещи: возврат имени, которое отражает текущее состояние, и подъём события смены свойства Name, когда меняется IsOnline.

Работа Peer — не только вернуть имя, но и сигнализировать о смене событием в тот момент, когда она происходит. У вспомогательной технологии нет собственного момента, чтобы заново запросить значение, поэтому без события реализация «правильна только когда спросят снова», и пользователи программы чтения с экрана никогда не узнают, что состояние изменилось.

sequenceDiagram
    accTitle: Как смена состояния доходит до программы чтения с экрана
    accDescr: В момент смены значения элемента AutomationPeer поднимает событие смены свойства Name; вспомогательная технология не запрашивает заново сама, поэтому без события держит старое имя и никогда не замечает смену
    participant c as Элемент
    participant p as AutomationPeer
    participant s as Программа чтения с экрана
    c->>p: Значение IsOnline меняется
    p->>s: Поднимает событие смены свойства Name
    s->>s: Объявляет новое состояние
    Note over s: Без события остаётся старое имя

Рис. 11: Смена значения доходит до программы чтения с экрана только когда AutomationPeer сигнализирует её событием смены.

Если у элемента есть операции, реализуйте шаблоны и кладите их в общие компоненты

Для собственных элементов, которые можно нажать, у которых есть изменяемое значение или которые можно выбрать, переопределите GetPattern и предоставьте интерфейсы шаблонов вроде IInvokeProvider и IRangeValueProvider.¹⁴

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

6. Можно ли дойти до каждой функции только с клавиатуры?

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

6.1. Проверяйте перемещение, выполнение и текущую позицию

Проверяйте не только порядок табуляции, но и то, что основные операции можно выполнить и что текущий фокус виден.

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

6.2. Работа с клавиатуры повышает эффективность ввода для всех пользователей

Это не просто «дополнительная стоимость поддержки людей с инвалидностью». В штатной работе вроде ввода заказов может ли оператор закончить ввод, не уходя с домашней позиции, решает, сколько операций он проведёт.

Перепутанный порядок табуляции или операция, которая требует мыши, — дефект, который каждый день чуть срезает производительность каждого пользователя. Работа над доступностью и эффективность клавиатуры — два имени одной работы. О приоритетах по среде использования см. также «UX Windows-приложений».

flowchart TB
    accTitle: Двойной эффект работы с клавиатуры
    accDescr: Наведение порядка табуляции, клавиш доступа и индикации фокуса даёт сразу два эффекта: пользователи вспомогательных технологий могут дойти до функций и скорость ввода каждого оператора, а функция, доступная только мышью, — то же, что функция, которой нет
    seibi["Работа с клавиатуры приведена в порядок"] --> a11y["Пользователи вспомогательных технологий могут работать"]
    seibi --> speed["Скорость ввода каждого оператора"]
    mouse["Функции только мышью"] -.-> none["То же, что несуществующие функции"]

Рис. 12: Работа с клавиатуры даёт поддержку вспомогательных технологий и эффективность для всех пользователей сразу; функция только мышью — как несуществующая.

7. Цвет и контраст — 4,5:1 и «не только цветом»

7.1. Ориентир коэффициента контрастности — 4,5:1

Критерий успеха WCAG 1.4.3 (Контраст (минимум)) требует коэффициент контрастности не ниже 4,5:1 для текста и изображений текста и не ниже 3:1 для крупного текста.⁶

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

7.2. Не передавайте информацию одним цветом

Критерий успеха 1.4.1 (Использование цвета) говорит, что цвет не должен быть единственным визуальным средством передачи информации.⁶ Типичные случаи в бизнес-приложениях такие.

С учётом разнообразия цветовосприятия это тоже основа проектирования отображения, а не «особая мера».

flowchart TB
    accTitle: Замена информации, переданной только цветом
    accDescr: Отображение, которое показывает ошибки только красным текстом, заменяется иконкой ошибки и столбцом сообщения рядом, отображение обязательных полей только цветом метки получает маркер «Обязательно», а отображение состояния только цветом лампы заменяется формой или текстом рядом с цветом
    err["Ошибки только красным текстом"] --> erra["Добавить иконку и формулировку"]
    req["Обязательность только цветом метки"] --> reqa["Добавить маркер «Обязательно»"]
    lamp["Состояние только цветом лампы"] --> lampa["Совместить цвет с формой или текстом"]

Рис. 13: Замените типичные подсказки только цветом иконкой, маркером или формой и текстом рядом с цветом.

7.3. Следование темам контрастности (высокой контрастности)

Темы контрастности Windows (ранее высокая контрастность) — цветовые схемы, которые сильно разделяют передний план и фон. Встроенные темы рассчитаны на коэффициент контрастности примерно 7:1 и выше, и пользователи могут их выбирать и править.¹⁵

На стороне приложения не задавайте цвета жёстко; уважайте системные цвета. Что делать в каждой платформе — так.

Конкретные настройки WinForms — в пошаговом руководстве Microsoft, цвета тем — в документации тем контрастности.¹¹¹⁵

flowchart TB
    accTitle: Следование темам контрастности
    accDescr: Места, где цвета заданы жёстко, ломаются при переключении на тему контрастности, поэтому переключайтесь на схему на базе SystemColors и следуйте через событие смены настроек; если ссылаетесь на системные цвета, UI следует цветам пользователя автоматически
    theme["Переключиться на тему контрастности"] --> qh{"Как заданы цвета?"}
    qh -->|Жёстко| broken["Цветовая схема ломается"]
    qh -->|Ссылки на системные цвета| ok["Автоматически следует цветам пользователя"]
    broken -.-> fix["Переключиться на SystemColors"]
    fix -.-> ev["Следовать через событие смены настроек"]

Рис. 14: Только жёстко заданные цвета ломаются в теме контрастности; ссылки на системные цвета следуют автоматически.

Включите выживание при высоком DPI в ту же проверку

Пользователи со слабым зрением часто работают с высоким коэффициентом масштаба ОС (масштабирование DPI), поэтому поддержка высокого DPI тоже часть доступности. Приложение, чей макет ломается при 125–200%, в этой среде непригодно.

Конкретику см. в «Поддержке высокого DPI в WinForms» и «Высоком DPI в WPF».

8. Практика проверки — Accessibility Insights и практические проверки программой чтения с экрана

8.1. Accessibility Insights for Windows

Accessibility Insights for Windows от Microsoft предлагает три способа работы в зависимости от цели.⁷

Inspect.exe и AccEvent, входящие в Windows SDK, тоже могут показывать дерево UIA и свойства, но позиционируются как устаревшие инструменты, и сейчас рекомендуется переход на Accessibility Insights.⁷

flowchart TB
    accTitle: Три режима Accessibility Insights
    accDescr: Accessibility Insights for Windows даёт Live Inspect для проверки свойств UIA, FastPass для лёгкой проверки проблем с высоким влиянием и Troubleshooting для помощи в диагностике и правке, и рекомендуется переход с устаревших инструментов вроде Inspect.exe
    ai["Accessibility Insights"] --> live["Live Inspect"]
    ai --> fast["FastPass"]
    ai --> ts["Troubleshooting"]
    live --> livef["Проверить свойства UIA"]
    fast --> fastf["Обнаружить проблемы с высоким влиянием"]
    ts --> tsf["Помочь диагностировать и чинить"]
    legacy["Inspect.exe и другие"] -.->|Рекомендуется переход| ai

Рис. 15: У Accessibility Insights три режима — проверка, обнаружение и диагностика — и это рекомендуемая замена устаревшим инструментам.

8.2. Практические проверки программой чтения с экрана

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

Сначала запустите Экранный диктор сочетанием Ctrl+клавиша Windows+Enter или установите свободный NVDA.¹⁰ Затем выберите представительную задачу вроде «ввести один заказ и подтвердить» и попробуйте закончить её только по объявлениям, не глядя на экран или с выключенным дисплеем.

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

flowchart TB
    accTitle: Совмещение проверки инструментом и практических проверок
    accDescr: Автоматическая проверка вроде FastPass может обнаружить только проблемы, которые можно судить механически; остальное проходите реальными рабочими операциями с программой чтения с экрана и находите проблемы порядка объявлений и фокуса на практике
    tool["Автоматическая проверка инструментом"] --> kikai["Проблемы, которые можно судить механически"]
    tool -.-> nokori["Остаются необнаруживаемые проблемы"]
    nokori --> sr["Практическая проверка программой чтения с экрана"]
    sr --> task["Пройти рабочую операцию"]
    task --> mieru["Проблемы порядка объявлений и фокуса"]

Рис. 16: Автоматической проверкой перечислите механические проблемы, остальное найдите практическими проверками программой чтения с экрана.

8.3. Встраивание в поток разработки и синергия с автоматическими UI-тестами

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

Переиспользуйте работу UIA для автоматических тестов

Автоматические UI-тесты с FlaUI и подобными построены на той же UIA, что и программы чтения с экрана. Name и шаблоны, которые вы готовите ради доступности, становятся строительными блоками тестового кода, а AutomationId, заложенный для тестов, также облегчает отладку в Live Inspect.

Наоборот, UI, который не появляется в дереве UIA, невидим и тестам, и вспомогательным технологиям. Доступность и тестируемость — две стороны одного вложения. Подробности — в «UI-автотестах десктопных приложений Windows».

flowchart TB
    accTitle: Синергия доступности и автоматических UI-тестов
    accDescr: Программы чтения с экрана и автоматические UI-тесты вроде FlaUI построены на той же UIA, поэтому Name и шаблоны, которые вы готовите, можно использовать с обеих сторон, а UI, которого нет в дереве UIA, невидим ни тем ни другим
    uia["Дерево UIA приведено в порядок"] --> sr["Программы чтения с экрана могут читать"]
    uia --> test["Автоматические UI-тесты могут использовать"]
    sr -.-> both["Две стороны одного вложения"]
    test -.-> both
    hidden["UI отсутствует в UIA"] -.-> invisible["Невидим обоим"]

Рис. 17: Поскольку оба сидят на одном фундаменте UIA, наведение порядка в дереве UIA помогает вспомогательным технологиям и автоматическим UI-тестам.

9. Как расставлять приоритеты — не чините все экраны сразу

Перелопатить основную систему с сотнями экранов разом нереально и по стоимости, и по качеству. Рекомендуем идти в три следующих этапа.

9.1. Начните с экранов, на которые этот пользователь опирается в работе

Разумное приспособление — процесс индивидуального ответа на обращение человека.² Сначала пусть человек пройдёт реальную работу с программой чтения с экрана, и вместе найдите, где он застревает.

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

9.2. Делайте новую разработку соответствующей как стандарт

Добавьте чек-лист главы 8 в Definition of Done. Политика — новые экраны сразу строят соответствующими. В отличие от донастройки, закладывание на этапе проектирования добавляет лишь небольшую стоимость.

9.3. Разверните по экранам, чиня общие элементы управления

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

flowchart TB
    accTitle: Три этапа расстановки приоритетов правок
    accDescr: Начните с экранов, на которые пользователь опирается в работе, делайте новую разработку соответствующей как стандарт с чек-листом и разверните на каждый экран, чиня общие элементы управления
    s1["1. Начать с экранов, на которые опирается пользователь"] --> s2["2. Новая разработка соответствующая как стандарт"] --> s3["3. Развернуть через общие элементы"]
    s3 -.-> all["Сразу действует на каждом экране, который ими пользуется"]

Рис. 18: Вместо того чтобы перелопатить все экраны разом, идите в три этапа: экраны в использовании, новая разработка и общие компоненты.

9.4. Записывайте ход диалога, а не только правки

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

Для правок, которые были бы чрезмерным бременем, рассмотрение и согласование с человеком альтернатив вроде выполнения задачи на другом экране, предоставления экспорта CSV или покрытия через операции — законный исход конструктивного диалога.²

Запись что запросили, что сделали и что предложили как альтернативу — то, что демонстрирует добросовестность организации.

flowchart TB
    accTitle: Поток конструктивного диалога и записей
    accDescr: Ответить на обращение человека с инвалидностью через конструктивный диалог, выполнить правки, которые можно сделать, для правок, которые были бы чрезмерным бременем, рассмотреть и согласовать с человеком альтернативу и записать, что запросили, что сделали и что предложили как альтернативу
    req["Обращение"] --> talk["Конструктивный диалог"]
    talk --> q{"Чрезмерное бремя?"}
    q -->|Нет| kaishu["Ответить правкой"]
    q -->|Да| alt["Рассмотреть и согласовать альтернативу"]
    kaishu --> rec["Записать ход событий"]
    alt --> rec

Рис. 19: В конструктивном диалоге согласуйте с человеком правку или альтернативу и ведите запись того, как это шло.

10. Итог

Разделение законодательной рамки, технологии и процесса делает исходную точку видимой.

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

На технической стороне проверяйте настольные приложения вокруг WCAG (JIS X 8341-3:2016) через WCAG2ICT. Фундамент — дерево UIA, его свойства (Name/ControlType/AutomationId) и шаблоны элементов управления. Именование, первый приоритет, в WinForms ведут AccessibleName и Label плюс порядок табуляции, в WPF — AutomationProperties.Name/LabeledBy, для собственных элементов — AutomationPeer.

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

Процесс идёт в порядке экраны, на которые опирается пользователь, новая разработка соответствующая как стандарт и развёртывание через общие элементы. Совмещайте FastPass и Live Inspect в Accessibility Insights с практическими проверками в Экранном дикторе/NVDA и встраивайте их в поток разработки как чек-лист новых экранов.

Как первый шаг рекомендуем взять один из основных экранов, прогнать FastPass в Accessibility Insights for Windows, а затем пройти работу только клавишей Tab. За 30 минут вы увидите на удивление конкретно, где сейчас стоит ваше приложение.

Похожие статьи

• UI-автотесты десктопных приложений Windows — UI Automation и устойчивые тесты на FlaUI
• UX Windows-приложений: приоритеты по среде использования
• Поддержка высокого DPI в WinForms — почему на 4K размывается или ломается макет
• Высокий DPI в WPF — почему «к DPI должен быть готов», а на деле всё размывается
• Почему KomuraSoft создаёт сайты на дизайн-системе Цифрового агентства Японии — цена и качество совместимы
• Японские шрифты в бизнес-приложениях: JIS2004, IVS и пользовательские символы

Смежные области консультирования

KomuraSoft LLC занимается правками доступности бизнес-приложений WinForms/WPF (поддержка программ чтения с экрана, работа с клавиатуры, поддержка тем контрастности), реализацией AutomationPeer для общих элементов управления и диагностикой текущего состояния и расстановкой приоритетов через Accessibility Insights. Можно начать со стадии «хотим проверить, может ли сотрудник пользоваться нашим приложением с программой чтения с экрана».

• Разработка Windows-приложений
• Техническая консультация и ревью проекта
• Связаться с нами

Справочные ссылки

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Обязана ли организация по закону делать бизнес-приложение доступным?

Поправка 2021 года к Закону Японии об устранении дискриминации в отношении инвалидов вступила в силу 1 апреля 2024 года: организации тоже обязаны предоставлять инвалидам разумное приспособление. Разумное приспособление — это ответ на обращение человека с инвалидностью: снять конкретный барьер в пределах, не составляющих чрезмерное бремя. Заранее сделать приложение удобнее относится к обустройству среды — обязанности прилагать усилия, а не к жёсткому требованию. Отношения сотрудника и работодателя регулирует не этот закон, а Закон о содействии трудоустройству инвалидов: там обязанность разумного приспособления лежит на работодателе уже с поправки, вступившей в силу в апреле 2016 года. Иначе говоря, ситуация «сотрудник не может пользоваться бизнес-приложением» давно в зоне обязанности. Насколько далеко идти в конкретном случае, зависит от обстоятельств: сверяйтесь с первичными источниками Канцелярии Кабинета министров и Министерства здравоохранения, труда и благосостояния Японии и решайте в диалоге с человеком, которого это касается.

Как программа чтения с экрана читает настольное приложение Windows?

Программы чтения с экрана вроде Экранного диктора (Narrator) и NVDA читают интерфейс приложения через платформу доступности UI Automation (UIA). Приложение публикует элементы экрана в дереве UIA; у каждого элемента есть свойства вроде Name (назначение) и ControlType (тип) и шаблоны элементов управления вроде Invoke (нажать) и Value (значение). Программа чтения объявляет это как «Подтвердить заказ, кнопка» и действует через шаблоны. Стандартные элементы WinForms и WPF уже умеют это, поэтому основная работа разработчика — не оставлять Name пустым, сделать интерфейс управляемым с клавиатуры и реализовать сведения на собственных элементах.

С чего начать в уже существующем приложении WinForms?

Самый короткий путь — прогнать FastPass в Accessibility Insights for Windows по нужному экрану и собрать элементы с пустым Name и сбои порядка табуляции. Исправления начинают с AccessibleName на кнопках только с иконкой, с привязки Label непосредственно перед полем в порядке табуляции и с TabIndex, совпадающего с визуальным порядком. Затем запустите Экранный диктор или NVDA, пройдите реальную рабочую операцию, не глядя на экран, и посмотрите, где вы застреваете. Не нужно исправлять все экраны сразу: начинайте с тех, которыми кто-то реально пользуется, а новые экраны сразу проводите по чек-листу.

Что делать для тем контрастности (высокой контрастности)?

База — не задавать цвета жёстко и опираться на системные цвета. В WinForms оставляйте ForeColor и BackColor по умолчанию или используйте SystemColors, определяйте состояние через SystemInformation.HighContrast и отслеживайте смену настроек событием UserPreferenceChanged. В WPF и WinUI, если ссылаетесь на ресурсы семейства SystemColors, смена темы подхватывается сама. Одновременно перестаньте передавать информацию одним цветом — например, показывать ошибку только красным — и добавляйте иконку или текст. Даже в обычной теме ориентир WCAG на коэффициент контрастности текста не ниже 4,5:1 делает интерфейс читаемее и в плохо освещённом цехе, и для возрастных пользователей.

Помогает ли доступность ещё и автоматическим UI-тестам?

Да. Инструменты автоматических UI-тестов вроде FlaUI опираются на ту же UI Automation, что и программы чтения с экрана. Name, ControlType и шаблоны элементов управления, которые вы готовите ради доступности, можно брать из тестового кода как есть, а AutomationId, заложенный для тестов, стабилизирует поиск элементов. Наоборот, интерфейс, который вы рисуете сами и который не попадает в дерево UIA, невидим и программе чтения, и тестам. Доступность и автоматические тесты — вложение в один и тот же фундамент: наведя порядок в одном, вы снижаете стоимость другого.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.