Автор:	© Михаил Сергеевич Пожидаев
Источник:	Как сделать весь Linux доступным незрячим
Дата публикации:	20.12.2022

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

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

Поскольку отечественные ОС ожидаемо основаны на компонентах с открытым исходным кодом и, в частности, на ядре Linux, нас интересуют особенности доступности прежде всего в GNU / Linux. С технической точки зрения поддержка доступности для GUI приложений в Linux (впрочем, как и в других многозадачных ОС, предоставляющих пользовательский интерфейс) предполагает решение двух традиционных проблем:

• Обеспечение быстрого межпроцессного взаимодействия, необходимость в котором появляется из-за того, что приложения, интерфейс которых нас интересует, и инструмент сбора всей accessibility-информации работают в разных процессах.
• Разработка и поддержка структур данных (интерфейсов), сохраняющих и передающих accessibility-информацию.

Нынешний инструмент, который предназначен для решения этих задач — это AT-SPI. Межпроцессное взаимодействие он осуществляет, используя D-Bus, а интерфейсы берёт в соглашении IAccessible2 (например, вот описание гипертекста, страница обновлялась в 2013 г.). Предполагается, что все библиотеки виджетов (QT, GTK+ и пр.) должны содержать мосты в AT-SPI и передавать туда информацию о всех объектах на экране. Сначала AT-SPI использовал Corba, но затем был перенесён на D-Bus.

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

Системно эту проблему можно решить, затеяв разработку нового брокера accessibility-событий. Apache Kafka, хотя совсем не о нём речь, способен передавать в сервисах под нагрузкой куда больше информации, чем это бывает в accessibility-продуктах, при этом информация в нём обычно не структурируется, а представляется просто парой ключ-значение. При выборе возможной архитектуры нового брокера очень помогли бы исследования, какой из механизмов в Linux способен собирать записи ключ-значение из разных процессов в одном месте. Можно предположить, что через разделяемую память или, может быть, даже обычные трубы это будет работать намного быстрее, чем через UNIX-сокеты в D-Bus. Может быть, очереди сообщений окажутся более удачным решением. Никакого разбора сообщений в брокере проводить не будем, он предоставляет только возможность подписки в том же стиле, как это предлагает Kafka. Любой клиент сам решит, что он хочет видеть в сообщениях.

Некоторая регламентация интерфейсов, конечно, потребуется. Совместимость с IAccessible2 необходима, но свободы должно быть больше — если разработчики хотят передавать больше accessibility-информации путём передачи кастомных сообщений, брокер не должен препятствовать этому. Естественно, возникает вопрос о подписчиках: что это за компоненты, какую роль они играют, и кто их разрабатывает?

Подписчики брокера выполняют разбор собранных сообщений и транслируют результат их обработки в текстовое описание, которое далее предоставляется пользователю в доступной для восприятия форме, например,произносится синтезатором речи или отображается на тактильном дисплее шрифтом Брайля. С IAccessible2 всё достаточно просто — интерфейс стандартизирован, роль подписчика предельно ясна. Остаётся вопрос, кто из подписчиков должен выполнять обработку кастомных сообщений? Очевидно, что такой подписчик должен быть предоставлен автором приложения, отправившего кастомное сообщение. Получается, для полноты архитектуры нам требуется соглашение по функционалу подписчиков и механизму их добавления в подсистему accessibility. Функционал прост — выполняется прослушивание сообщений некоторого нестандартного типа с их преобразованием в реакции для синтезатора речи и брайлевского дисплея. Остаётся решить вопрос, на чём подобные подписчики могут быть написаны и как добавляются в подсистему accessibility. Этот вопрос ради объективности пока решать не будем, оставив только надежду, что желающих делать это на красивых скриптовых языках будет больше, чем желающих всё делать на правильном C++.

Подытоживая, сформулируем предлагаемую архитектуру accessibility следующим образом:

• Центральную роль играет высокопроизводительный броке, получающий от разных процессов accessibility-информацию в виде сообщений и передающий эту информацию без детального разбора подписчикам. Также брокер обеспечивает механизм регистрации подписчиков.
• Используемый в настоящий момент AT-SPI может выступать в качестве одного из клиентов брокера, передавая сообщения, которые собираем сам. Это позволит не потерять поддержку accessibility в тех приложениях, где она уже есть.
• Структура сообщений сохраняет совместимость с IAccessible2, но может быть легко расширена за счёт использования нестандартных типов.
• Предусматривается механизм подписок на сообщения в топиках брокера, который содержит набор стандартных подписчиков и позволяет добавлять кастомные.
• Определяется соглашение по разработке кастомных подписчиков, основной интерфейс которых транслирует сообщения из брокера в текст для чтения и отображения на брайлевском дисплее.
• Все компоненты поддерживают переносимость, насколько это будет возможно.

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

Пишите идеи на @Marigostra!

Ссылки по теме

• Новая реализация инфраструктуры доступности в GTK 4
• Доклад Федерико Мена Кинтеро о работе над инфраструктурой доступности графической среды GNOME на GUADEC 2022
Сообщество KDE собирает силы для достижения новых целей: доступность, энергоэффективность, автоматизация