Согласно данным пресс-службы Всероссийского общества слепых, президент данной организации направил обращение в адрес генерального директора Фирмы «1С» — Б. Г. Нургалиева, в котором отметил остроту проблемы трудоустройства и профессиональной реабилитации инвалидов по зрению в контексте недоступности продуктов «1С» для вспомогательного программного обеспечения, использующегося для невизуальной работы с компьютерной техникой.
С полным текстом пресс-релиза можно ознакомиться на сайте ВОС. Здесь же имеет смысл дать несколько технических уточнений по поднятой проблеме, так как ввиду специфичности данной темы есть риск неправильного её понимания со стороны людей, не очень близких к технологиям невизуальной доступности, но являющихся ЛПР — лицами, принимающими решения.
Первоначальный ликбез
Прежде всего, следует отметить тот факт, что работа с компьютером абсолютно без использования зрения возможна и является рядовой практикой, в том числе и в России. При этом, работа тотально слепого пользователя возможна не только в специально созданном рабочем окружении, но и в стандартном интерфейсе операционной системы и в стандартных приложениях, причём зачастую с производительностью, сопоставимой с производительностью среднестатистического зрячего человека (хотя производительность невизуальной работы — это отдельный большой вопрос, выходящий за рамки текущей темы).
Более того, если речь идёт о серьёзной профессиональной деятельности слепого человека, то максимальная эффективность, как правило, достигается именно при условии использования общераспространённых рабочих сред, просто с применением вспомогательного программного обеспечения, работающего в фоновом режиме и предоставляющего экранную информацию в альтернативном виде: речевой поток или вывод текста на тактильный дисплей.
Подробности о принципах невизуальной работы за компьютером можно узнать из соответствующей статьи на Хабрахабре. Здесь же просто подчеркнём, что любые разговоры о разработки альтернативных рабочих сред в контексте профессиональной работы слепых в общем-то несостоятельны, и их несостоятельность доказана историей развития всей индустрии, поэтому данный вопрос можно даже не поднимать.
Актуальность проблемы для всех
Проблема невизуальной доступности программных интерфейсов, и в частности среды 1С, не является надуманной.
К сожалению, число людей с проблемами зрения, несмотря на развитие медицины, наоборот увеличивается, так как в современном мире в разы возросла нагрузка на зрительную функцию организма. Это обуславливает увеличивающееся с каждым годом число людей, нуждающихся в реабилитации по причине снижения или полной утраты зрения. Причём, в том числе и профессиональной реабилитации, а не только бытовой.
На государственном уровне эта проблема осознаётся, и одним из способов её решения является квотирование рабочих мест для инвалидов. То есть государство обязует компании обязательно иметь в своём штате людей с инвалидностью (тип нарушения не дифференцируется, но для справки доля инвалидов по зрению в общей массе примерно 8%). Можно даже утверждать, что до определённой степени на рынке труда имеется неудовлетворённый спрос на инвалидов, способных работать на высоком профессиональном уровне.
Недоступность профессионального программного обеспечения для слепых является одним из факторов, затрудняющих решение обозначенной проблемы к выгоде всех трёх сторон:
- Инвалидов, желающих получить работу;
- Государства, стремящегося выполнить свои социальные функции;
- Организаций, желающих получить грамотного и эффективного сотрудника.
Программный комплекс 1С для России и отдельных стран СНГ во многих областях является практически стандартом де-факто, поэтому вопрос его доступности, в контексте обозначенной проблемы, является крайне острым.
Технические подходы
В упомянутом обращении президента ВОС, есть следующая фраза:
…назрела необходимость решения проблемы обеспечения совместимости программы 1С (версия 8) с программами невизуального экранного доступа (Jaws и NVDA). По предварительным оценкам данная доработка не потребует существенных временных и материальных затрат и мы готовы привлечь незрячих программистов с целью совместного решения данной проблемы».
Следует сделать скидку на то, что это всего лишь пресс-релиз, и не воспринимать эту информацию как руководство к действию.
Во-первых, JAWS и NVDA являются лишь частными случаями вспомогательного программного обеспечения, хотя и самыми распространёнными. Однако кроме них даже сейчас на российском рынке присутствует ещё два решения (COBRA и SuperNova), а в обозримом будущем должно появиться и третье (Window-Eyes).
Во-вторых, доступность приложения корректнее реализовывать на более низком уровне, поднимаясь на уровень вспомогательного ПО лишь в отдельных случаях.
Фактически существует два уровня:
- Уровень API доступности, реализованных в операционной системе;
- Уровень программы экранного доступа (у каждой программы реализация своя).
В свою очередь, уровень программы экранного доступа также можно подразделить на:
- API программы экранного доступа, через которое любое приложение может ограничено с ней взаимодействовать;
- Модуль внутри программы экранного доступа, который представляет собой как бы плагин, который написан специально для реализации специфических вариантов взаимодействия с приложением, доступность которого обеспечивается.
Таким образом, существует три подхода к реализации доступности приложения. Правда они зачастую перетекают друг в друга.
Варианты решения проблемы
Исходя из всего сказанного, можно выделить следующие стратегии по реализации доступности приложения.
I. Адаптация программы под общие системные API доступности
В рамках этого направления, разработчик должен доработать свой графический интерфейс с применением общих технических рекомендаций accessibility и специальных API: для Windows в общем случае это Microsoft Active Accessibility и более современный Microsoft UI Automation.
Если интерфейс приложения разработан с применением какой-то отдельной среды или фреймворка, то, обычно у них есть свои технологии, например, Java Access Bridge для Java или QAccessibleInterface для Qt.
Как правило, проблема возникает тогда, когда разработчик применяет интерфейсные фреймворки или кастомные классы, где по незнанию теряет функциональность accessibility, так как если в среде Windows строить интерфейс из стандартных элементов и по общим правилам, то его доступность обычно не вызывает серьёзных вопросов.
Это хорошая стратегия, так как обеспечивает универсальную доступность, то есть сразу для всех программ экранного доступа.
II. Адаптация приложения под конкретную программу экранного доступа
В рамках этого направления, разработчик сосредотачивается на том, что реализует передачу значимой информации через API конкретной программы экранного доступа. Это может быть либо использование dll, которую предоставляет производитель программы экранного доступа, либо вызов объектов OLE Automation, также принадлежащих программе экранного доступа.
Проблема заключается в том, что API у всех программ экранного доступа разные, поэтому приходится затачивать доступность приложения под каждую из них. Кроме того, и функциональность API также различается, например, где-то он позволяет инициализировать передачу как речевого сообщения, так и вывода данных на тактильный дисплей, а где-то только речевого сообщения.
Более того, при обеспечении доступности насыщенного интерфейса, использование довольно мало функциональных API программ экранного доступа крайне неудобно и низко эффективно. В целом, это довольно плохая практика, оправданная лишь в каких-то отдельных случаях и для решения малых локальных задач.
III. Разработка модуля для программы экранного доступа
В рамках данного подхода, исходное приложение, доступность которого обеспечивается, может вообще не подвергаться модификации. Работа ведётся чисто на уровне программы экранного доступа.
Серьёзные программы экранного доступа имеют функционал кастомизации, что даёт возможность разработать для них некий скрипт или плагин, который будет реализовывать специфическую логику обработки элементов интерфейса определённого приложения. Традиционно это является самым распространённым вариантом решения проблемы, но это ещё не означает, что он наилучший.
Его распространённость объясняется лишь тем, что зачастую проще разработать модуль для отдельной программы экранного доступа, чем убедить разработчика какого-то приложения в необходимости модификации. То есть это единственный вариант, который доступен без необходимости сотрудничества с разработчиком приложения.
Правда решить проблемы доступности абсолютно без содействия со стороны разработчика также не всегда получается. Порой интерфейс в принципе не предоставляет возможности получить какие-либо данные кроме как по визуальному каналу. В частности, этим очень часто грешат разработчики антивирусов, случайно или на всякий случай, убивая API доступности. В таких случаях, от разработчика приложения требуется хотя бы минимальное содействие в виде предоставления по какому-то из API необходимых данных, например, положения системного фокуса или событий окна.
Как правило, модули пишутся либо разработчиками программы экранного доступа, если речь идёт об очень распространённом приложении, доступность которого крайне актуальна, например, Microsoft Office, независимыми программистами, как правило, просто являющимися пользователями той или иной программы экранного доступа и решающих свои собственные задачи, либо программистами-аутсорсерами, нанимаемыми компанией-разработчиком приложения.
Чтобы было понятно, рассмотрим упрощённый пример с реализацией доступности графической кнопки, не имеющей текстовой подписи, по которой её идентифицирует слепой пользователь:
- Стратегия I: Добавляем в интерфейсе приложения к элементу button текстовую метку и обеспечиваем доступность для всех программ экранного доступа.
- Стратегия II: Добавляем в комплект поставки приложения DLL от разработчика программы X, а когда системный фокус попадает на неподписанную кнопку, через DLL даём команду программе экранного доступа произнести текстовую метку. Если в поддержку обратится пользователь программы экранного доступа Y, то либо реализуем аналогичную схему и для этой программы, либо посоветуем ему перейти на программу X, причём он вряд ли будет этому рад.
- Стратегия III: договоримся со специалистом, компетентным в написании модулей для программы экранного доступа X, или сами взрастим такого специалиста, который разработает плагин, произносящий текстовую метку, если в фокус попадает неподписанная кнопка. Если же в поддержку обратится пользователь программы Y, то аналогично стратегии II.
Это три базовые стратегии, хотя могут существовать различные их комбинации, а также некоторые более изощрённые пути.
Вопрос выбора оптимальной стратегии для реализации доступности того или иного приложения зачастую может быть спорным, однако в общем случае можно утверждать, что приоритет имеет смысл отдавать стратегии I, то есть универсальному пути через общесистемные API. Стратегия II вообще в случае крупных проектов неэффективна, а стратегия III, как правило, является неким компромиссом, плюс может быть использована для повышения usability, когда стратегия I полностью реализована.
Автор: Tseikovets
