Как сделать весь Linux доступным незрячим?

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

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

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

Нынешний инструмент, который предназначен для решения этих задач — это 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 следующим образом:

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

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