Автор:	© Никита Цейковец
Источник:	Accessibility in GTK 4
Дата публикации:	19.12.2020

В декабре 2020 года состоялся релиз кроссплатформенной библиотеки элементов интерфейса GTK 4.0, разрабатываемой под эгидой GNOME Foundation. Помимо прочего, в данном обновлении принципиально пересмотрена модель обеспечения доступности для пользователей с ограниченными возможностями, что является важным событием, так как GTK, наряду с Qt, является одним из двух наиболее распространённых фреймворков для разработки графических приложений и окружений на Unix-подобных системах, главным образом, Linux, да и ряд приложений на GTK представлен на других системах, таких как Windows и macOS.

GTK 4 развивается в рамках нового процесса разработки, который предполагает предоставить разработчикам приложений стабильный и поддерживаемый в течение нескольких лет API. В результате, они смогут использовать GTK 4, не опасаясь, что каждые полгода придётся переделывать приложения из-за изменения API в очередной ветке GTK. Кроме того, в этой ветке удалена старая реализация accessibility API по итогам решений, принятых на GTK Hackfest 2020, вместо которой внедрён новый вариант на базе спецификации ARIA и интерфейса GtkAccessible.

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

Приложения и вспомогательные технологии взаимодействуют друг с другом через шину доступности, которая является отдельным экземпляром сеансовой шины D-Bus, используя интерфейсы, описанные в протоколе AT-SPI. Элементы пользовательского интерфейса приложения представлены в виде объектов на шине, которые реализуют несколько абстрактные интерфейсы, такие как Text или Value. Приложения отправляют сигналы, чтобы сообщить об изменениях в своём пользовательском интерфейсе, а вспомогательные технологии могут вызывать методы объектов для получения информации или внесения изменений.

В GTK 2 и 3 это было реализовано неуклюжим косвенным образом:

1. У виджетов GTK есть вспомогательные доступные объекты, которые являются реализациями интерфейсов ATK (трансляция 1: из GTK в ATK).
2. Затем они превращаются в объекты AT-SPI (трансляция 2: из ATK в AT-SPI), которые представлены на шине доступности кодом адаптера в at-spi2-atk.
3. С другой стороны, вспомогательные технологии затем используют pyatspi для преобразования интерфейсов AT-SPI в объекты Python (трансляция 3: из AT-SPI в Python).

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

В GTK 4 упрощён уровень приложения, где был убран ATK и at-spi2-atk. Теперь виджеты реализуют специальный интерфейс GtkAccessible, который позволяет им устанавливать ряд ролей, состояний, свойств и связей, которые более или менее напрямую взяты из спецификации WAI-ARIA, опубликованной W3C. Затем бэкэнд AT-SPI для API доступности GTK берёт эти вдохновлённые ARIA атрибуты (и знания самих виджетов) и представляет виджеты как объекты на шине доступности, реализуя для них соответствующие интерфейсы AT-SPI.

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

Разработчикам приложений на GTK 4 необходимо знать следующие основные особенности нового accessibility API:

• Во-первых, установку доступной роли. Роль - это описание семантики виджета, и вспомогательные технологии будут использовать её, чтобы решить, какое поведение следует обеспечить для пользователя. Установка роли - это разовая операция, которая должна выполняться во время создания виджета: либо в class_init, либо во время инициализации экземпляра. Например:

  gtk_widget_class_set_accessible_role (widget_class,  
                                        GTK_ACCESSIBLE_ROLE_BUTTON)
  

• Во-вторых, обновление доступного состояния или свойств виджета. Это следует делать всякий раз, когда изменяется доступное представление виджета. Например:

  gtk_accessible_update_property (GTK_ACCESSIBLE (widget),
                         GTK_ACCESSIBLE_PROPERTY_VALUE_MIN, minimum,
                         GTK_ACCESSIBLE_PROPERTY_VALUE_NOW, value,
                         GTK_ACCESSIBLE_PROPERTY_VALUE_MAX, maximum,
                         -1);
  

В справочной документации GTK 4.0 есть обзор accessibility API, который включает руководство для разработчиков приложений и авторов виджетов.

К сожалению, пока всё это касается лишь доступности интерфейсов на открытых Unix-подобных системах, главным образом, Linux, и не распространяется на Windows и macOS. В настоящее время команда GTK сосредоточена на завершении в ветке 4.0 бэкэнда AT-SPI, но с новым API и разделением бэкэнда есть чёткий и понятный путь к созданию бэкэндов доступности для других платформ, что планируется исследовать в будущем.

В Linux разработчики GTK хотят работать с другими заинтересованными сторонами над модернизацией интерфейсов AT-SPI, чтобы окончательно преодолеть наследие CORBA, которое всё ещё заметно в некоторых местах. Часть этого будет переходить от шины доступности к одноранговым соединениям между приложением и вспомогательными технологиями; что повысит безопасность стека специальных возможностей и закроет дыру в песочнице, используемой такими технологиями, как Flatpak.

В будущем команда GTK хочет представить набор специальных инструментов, которые должны помочь разработчикам приложений узнавать об отсутствующих аннотациях доступности, таких как предоставление атрибута label или связи labelled-by с иконками и изображениями, а также убеждаться, что каждый элемент пользовательского интерфейса правильно представлен в дереве доступности. Более того, уже существует тестовый бэкэнд для интерфейса GtkAccessible, который можно использовать для написания модульных тестов и проверки того, что роли и атрибуты обновляются там, где это необходимо.

Не исключено, что в процессе перехода на GTK 4 пользователей вспомогательных технологий немного "потрясёт на ухабах", пока имплементация API и его поддержка будут утрясаться, но в среднесрочной и долгосрочной перспективе эти риски представляются оправданными.

Ветка GTK 4 объявлена стабильной и будет использована в следующем выпуске графического окружения GNOME 40.0. Одновременно объявлено о прекращении поддержки ветки GTK 2, тогда как поддержка ветки GTK 3 в обозримом будущем будет сохранена.

Для следующего выпуска GNOME решено использовать номер 40.0 вместо 3.40 чтобы избавиться от первого числа, которое при текущем процессе разработки потеряло актуальность. Версию 4.0 для GNOME было решено не использовать, чтобы избежать путаницы и пересечений с GTK 4.0. Промежуточные корректирующие выпуски будут поставляться под номерами 40.1, 40.2 и т. д., а каждые шесть месяцев будет формироваться новый значительный релиз, увеличивающий номер на 1, то есть 41.0, 42.0 и т. д. Также будет упразднено использование нечётных номеров для экспериментальных выпусков, вместо них тестовые выпуски будут именоваться как 40.alpha, 40.beta и 40.rc.

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

Получить более подробную информацию о GTK 4 можно в его официальном справочном руководстве.