Всем привет! Меня зовут Артем Плаксин, я с рождения практически ничего не вижу.
Незрячему или слабовидящему человеку при освоении компьютера приходится сталкиваться с очевидным барьером: очень многое завязано на визуальные интерфейсы, а без них порой сложно даже просто перейти на следующую страницу по ссылке.
Для своего некоммерческого проекта — экосистемы севисов для незрячих и слабовидящих TifloHost — я использую платформу серверной виртуализации VMmanager. Так я и познакомился с ребятами, которые делают этот продукт.
В этой статья я хочу поделиться с вами своей историей освоения интернета.
Первые шаги
Я начал осваивать компьютер в семь лет: учился печатать в Word. Практически не видел, что именно печатаю, поэтому результаты проверяла мама. Так я изучал десятипальцевый метод печати.
В школе узнал о скринридерах — специальных программах экранного доступа, которые озвучивают незрячему содержимое сайта. Скринридеры позволяют людям с ограниченными возможностями самостоятельно пользоваться компьютером и телефоном: помогают работать с кнопками, ссылками, метками, блоками текста, да и любой текстовой информацией, которую можно как-то интерпретировать.
Скринридер парсит сайт и создает свой виртуальный буфер, в котором незрячий человек может ориентироваться. На тот момент я этих подробностей еще не знал, но начал активно пользоваться подобными программами. Уже в то время — это казалось невероятным.
Путь в тестирование доступности
В конце школы, лет в 13, мне стало интересно самому создавать сайты. Начал учить HTML, CSS, а потом PHP и MySQL. Возможно, я пошел бы по пути разработки сайтов. Но будем откровенны: для работы во фронте все-таки нужно зрение.
Незрячему человеку логично идти в бэкенд. Но мне больше нравилось иметь дело с фронтом и как-то влиять на интерфейс, тем более к этому моменту у меня сформировалась уже определенная «насмотренность»: я проанализировал большое количество сайтов и понимал, какие особенности присущи ретейлу, банкингу и т. п. Поэтому я пошел по пути тестирования цифровой доступности интерфейса.
После школы я не стал поступать в университет, а сразу пошел в социальный инклюзивный предпринимательский проект работать специалистом по цифровой доступности. Меня пригласили, чтобы создать новую команду. Наш отдел разработал методику сертификации и обучения тестировщиков, а впоследствии начал проверять цифровую доступность сервисов крупного бизнеса. Надо отметить, что многие ресурсы стали доступнее после того, как мы с ними поработали. Это приятно.
Сейчас я продолжаю работать в этом направлении, правда, уже в другой компании.
Параллельно мы с командой развиваем экосистему проектов TifloHost для незрячих и слабовидящих, потому что никто другой подобным не занимается. Когда-то все началось с хостинга, но сейчас у нас целая экосистема сервисов, которые упрощают жизнь незрячему пользователю, который не может воспользоваться мышью или визуальными интерфейсами:
TifloHost — хостинг для проектов незрячих и слабовидящих;
«Данные в данные» — портал для «расшифровки» картинок и скриншотов для школьников и студентов;
RHVoice — связка из нескольких сервисов, которые создают голоса для синтезатора речи RHVoice.
Своими проектами мы не адаптируем сайты, а помогаем легче жить с тем, что есть сейчас. Под капотом — сложная инфраструктура на базе микросервисной архитектуры, где с помощью собственных наработок я управляю индустриальными решениями, в частности ispmanager и VMmanager.
Подводные камни работы
В обязанности тестировщика доступности входит проверка сайтов с точки зрения пользователя. Я захожу на ресурсы с программой экранного доступа и, используя стандартные способы навигации, прохожу пользовательские сценарии, выявляя проблемы и сложности. По итогам пишу отчет, который отправляется в бэклог команд разработки.
Казалось бы, есть скринридеры, ну что тут может пойти не так? Но скринридер не всегда справляется: это не волшебная палочка, которая делает озвучку сайта.
Поскольку браузеры по-разному интерпретируют DOM, дерево доступности в скринридер передается не единообразно. Браузеры, базирующиеся на Chromium, отдают элементы в одном виде, основанные на Firefox — в другом. Еще сложнее дело обстоит с картинками и фотографиями. Если кто-то присылает скриншот как пояснение к инструкции («смотрите, что нужно сделать»), скринридер уже не справляется. Моя задача, как тестировщика доступности, — выявлять эти несоответствия и рекомендовать исправления так, чтобы во всех браузерах через все скринридеры сайт отображался единообразно.
Чтобы смотреть на интерфейсы уже со стороны специалиста, надо не просто поставить себе скринридер, а владеть им на уровне продвинутого пользователя. Нужно понимать особенности представления сайтов в разных браузерах, знать спецификации, максимально контролировать, что происходит с окном браузера.
Представьте, что у вас открыто много окон на компьютере. Если вы при этом открываете Chrome, он может запуститься не на весь экран, а в виде окна в пустой области (чтобы не заслонять другие окна). Веб-страница в нем откроется в другом масштабе — сервис вполне может подгрузить планшетную версию вместо обычной и это спутает тестирование.
Или, допустим, вы нажали кнопку, а ничего не произошло. Зрячий бы сразу заметил, что, например открылась модалка, но фокус на нее не переместился автоматически. Незрячему же, чтобы найти такую модалку, нужно обыскать с помощью скринридера всю страницу (изначально догадываться, где она в DOM может скрываться). И это лишь пара нюансов, совершенно неочевидных для человека со зрением.
В этой работе мне очень пригодилось знание HTML и в целом опыт создания сайтов, поскольку я представляю, как устроена страница. В отчете для разработчиков могу не просто советовать сделать какой-то невидимый текст, но и указать, какие свойства класса надо поменять, чтобы скринридер это переварил.
Честно скажу: в интернете не так много сайтов, оптимизированных для работы через скринридер. А еще меньше таких инструментов администратора. По большей части они ориентированы на использование мышки, а незрячий человек ее не применяет совсем. Например, панель администрирования может быть собрана не из кнопок, а из ссылок и тогда просто табом на них не попасть. Приходится включать на клавиатуре эмуляцию мыши.
В целом эти сложности преодолимы. Плюс еще некоторые вещи можно настроить через консоль. Для незрячего своя стихия. Никаких картинок, только текстовый ввод и текстовый вывод — что может быть лучше?
Я вижу эффект от своей работы: многие сайты после аудита становятся доступнее. Проблема в том, что это не разовая акция. Доступность как таковую надо поддерживать, но не все компании тратят на это ресурсы. В частности, после редизайна аудит нужно проводить заново. Базовая доступность сохраняется, но появляются новые компоненты, нормально не адаптированные под скринридер. Параллельно могут отваливаться какие-то мелочи. Все это накапливается, если не проводить аудит регулярно.
Доступность на уровне законодательства
Приятно, что о цифровой доступности все же думают. На государственном уровне есть ГОСТ. Но для рядового бизнеса вся система госстандартов носит рекомендательный характер. Приказ Минцифры делает ГОСТ обязательным для применения только на сайтах государственных структур: министерств, поликлиник и т. п. Но вот, например, для отечественного ПО этот ГОСТ не обязателен. Когда такое ПО применяется для обучения в школах, оно оказывается не приспособленным для незрячих учеников.
В целом культура цифровой доступности с годами развивается. Последние 5—7 лет заметны серьезные продвижения в этом направлении, правда, приходит она в основном в крупный бизнес. В некоторых компаниях уже есть свои команды тестировщиков цифровой доступности с незрячими тестировщиками — они раз в несколько лет проводят аудиты поддерживаемых ресурсов.
Цифровая доступность — не опция, которую «можно добавить потом». Она должна быть встроена в культуру разработки, так же как тестирование, безопасность и производительность. Пока этого нет, но каждый аудит, рекомендация и правка — шаг в сторону мира, где интернет с его визуальными интерфейсами немного доступнее для тех, кто видит плохо или не видит совсем.
