×

Незрячий программист — о разработке «на слух» и доступности интернета

Дмитрий Попов — незрячий веб-разработчик, пользуется программами экранного доступа. Эксперт по доступности сайтов, аналитик доступности многочисленных проектов, в том числе таких крупных, как сайт «УкрЗалiзниця». Веб-технологии изучил самостоятельно. Преподавал математику в Славянской школе-интернате для слепых и слабовидящих детей. С 2013 года живет в Киеве.

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

Дмитрий выступил с докладом «Как незрячие люди видят ваш сайт» на конференции WSD в Киеве

— Дима, как вы заинтересовались ИТ и программированием?

Я по образованию учитель математики и информатики, еще в университете изучил основы HTML, JavaScript. Меня это заинтересовало, и я еще тогда начал пытаться делать свои сайты, сначала как лабораторные для вуза, потом уже как свои проекты. В то время как раз были популярны бесплатные хостинги narod.ru. Со временем понял, что одного HTML мало, начал осваивать PHP. Просто открывал какие-то скрипты, читал код, разбирался.

— Расскажите, как незрячие люди работают с компьютером?

Незрячие пользуются компьютером с помощью специальных программ — скринридеров. Скринридер зачитывает активный текст, то есть тот, который сейчас под курсором. Озвучивание идет сверху вниз, то есть программа просто по порядку считывает HTML разметку.

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

Что касается разработки, то для работы достаточно блокнота, клавиатуры и синтезатора речи. Иногда я работал в паре с другими разработчиками и замечал, что со скринридером иногда процесс идет даже быстрее, чем обычная работа с визуальной доступностью — к примеру, скринридер четко озвучивает все символы и не дает перепутать апостроф с одинарной кавычкой.

— А как, например, происходит отладка, поиск какого-то бага?

Я могу стрелками ходить по строчкам, и при активации начинает зачитываться вся строка. Могу внутри строки двигаться вперед назад, и скринридер будет озвучивать посимвольно.

Все незрячие люди привыкают к озвучке на больших скоростях. Я использую режим, в котором зачитывается 400 слов в минуту — это максимальная скорость из мне известных.

— Для вас программирование — это работа или хобби?

И то, и другое. Я пишу сайты для себя, занимаюсь их продвижением, зарабатываю за счет размещения рекламы. Коммерческие заказы никогда не брал.

Активно занимаюсь волонтерскими проектами, связанными с доступностью сайтов для незрячих. Один из них — #Детектор_Web_доступності, проект организации «Вір в Україну». Меня туда пригласили как эксперта — мы проверяем государственные сайты на предмет доступности и пишем рекомендации по устранению найденных проблем. Уже есть первые результаты и обратная связь от Министерств. В числе тех, кто уже подкорректировал свои сайты, — Минагрополитики и Правительственный портал.

— А можно подробнее о доступности? С какими проблемами сталкиваются незрячие при посещении сайтов? Как их исправить?

Скажу сразу, что доступность — это не какая-то дополнительная надстройка. Если сайт разработан грамотно с точки зрения разработки, HTML, то он уже будет доступным — за исключением, возможно, каких-то особо сложных форм. Проблемы возникают, когда, например, разработчики вместо кнопки делают элемент <span> и через JavaScript навешивают на него какое-то действие. Для скринридера это не кнопка, не ссылка, а просто текст, нейтральный элемент, и он не может на нем сфокусироваться.

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

Возникают проблемы, когда отсутствуют текстовые подписи — например, ссылки на соцсети в виде иконок. Если поверх иконки добавить текст, то это испортит дизайн, но можно добавить подпись в атрибуте aria-label из стандарта WAI-ARIA, разработанного специально для решения вопросов доступности для незрячих. Элемент aria-label не виден визуально, но озвучивается скринридером.

Еще один момент — сложные меню, которые раскрываются при наведении мыши. Но, согласно требований доступности WCAG, все функции сайта должны быть доступны при помощи клавиатуры.

Можно сказать, есть 2 основные проблемы. Во-первых, большинство разработчиков просто не знают, насколько среди пользователей их сайтов велик процент людей с нарушениями зрения. Эта тема не на слуху.

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

Я стараюсь поднимать тему доступности. Пишу в техподдержку сайтов, предлагаю решения. Иногда получаю обратную связь, иногда нет.

Frontend-лаборатория «Blind Accessibility» — обсуждали проблемы, с которыми сталкиваются незрячие при посещении сайтов. Дмитрий — справа

— Каких изменений уже удалось добиться?

Один из позитивных примеров, когда получилось — сайт zakaz.ua, сервис доставки продуктов из супермаркетов. Раньше там при заказе доставки надо было выбрать на карте свой район, и это можно было сделать только мышкой. С клавиатуры сервис был недоступен, и незрячему пользователю приходилось каждый раз просить кого-то о помощи. По моей просьбе разработчики сделали так, что теперь достаточно выбрать адрес один раз, и он сохраняется в cookies на долгий срок. А в новой версии сайта планируют и вовсе отказаться от карты — район будет определяться сам при вводе улицы.

Сейчас общаюсь с ПриватБанком — у них в приложении Приват24 для айфонов недоступна услуга заказа билетов для незрячих.

При общении с администрацией я делаю акцент не столько на социальную ответственность, сколько на практическую выгоду — объясняю, что незрячие люди — это достаточно большой процент потенциальных клиентов, они тоже пользуются сервисами, платными услугами, и для бизнеса невыгодно их игнорировать. Небольшие изменения в коде могут привести 3-5% новых потребителей.

— Слышала, что вы также принимали участие в доработке сайта «УкрЗалізниці». Что там надо было улучшить?

История с UZ.gov.ua длится уже более 3 лет. Все началось с того, что юрист Андрей Стегницкий выиграл суд против УЗ, и суд обязал сделать сайт доступным для незрячих, в частности виджет покупки билетов. Однако за 3 года так ничего сделано и не было, и только этим летом организация незрячих ГУД снова подняла этот вопрос. Меня пригласили в качестве эксперта в команду, и буквально за 3 дня исправили все проблемы.

Мы внесли правки в сервис покупки билетов. Изначально в форме выбора места свободные места от занятых отличались только цветом, и с помощью скринридера было невозможно определить их статус. Мы просто добавили элемент aria-label с указанием, свободно данное место или занято. Этот атрибут никак не отображается визуально, но доступен для скринридера.

Несколько строк, которые сделали UZ.gov.ua доступным (из презентации Дмитрия для WSD)

Правда, остались сложности с онлайн-оплатой, но она проходит на странице стороннего сервиса Plategka.com. Там невозможно ввести CCV/CCV2 — на виртуальной клавиатуре у кнопок нет подписей. Мы общаемся с администрацией сервиса, но пока, к сожалению, безуспешно.

Так что, как показывает практика, намного больше времени уходит не на саму доработку программы, а на то, чтобы донести необходимость внести эти изменения.

— А как вы можете оценить большинство сайтов, насколько они доступны? Есть ли разница между украинскими и зарубежными?

За рубежом дела намного лучше. Как раз в рамках «Детектора Web доступності» я недавно проверял государственные сайты Германии, Франции, США — у них минималистично, грамотно написанные странички, очень продуманные в плане логики меню. А у нас перегружены слайдерами, новостями в виде бегущей строки.

Если сравнивать временные изменения, то ситуация сейчас лучше, чем 10 лет назад — тогда в моде был flash, всякие сайдеры, крутилки, карусели. Сейчас в тренде минимализм, и благодаря этому дела с доступностью обстоят гораздо лучше.

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

Я тестирую непосредственно скринридером. Но работа с этим ПО достаточно специфична, и на его освоение может понадобиться какое-то время.

Для поверхностной проверки можно использовать:
— Markup Validation Service — проверка сайта на общую валидность HTML;
— AChecker — валидатор на основе анализа HTML-кода. Не учитывает JavaScript, ошибки выводятся в текстовом виде, не очень удобны для анализа. Выдаёт список потенциальных проблем, большая часть из которых не соответствуют действительности, однако список может использоваться в качестве дополнительного чек-листа;
— Wave web accessibility и расширение для Chrome WAVE Evaluation Tool — находят большое количество ошибок, предоставляют подсказки по исправлению и ссылку на стандарт, предоставляют информацию в удобном виде, подсвечивают синтаксис и aria-атрибуты;
— Tota11y — встраиваемый на страницу с помощью букмарклета визуализатор и валидатор доступности. Поддерживает измерение контрастности. В отличие от Wave Evaluation Tool, не показывает все ошибки сразу и определяет не так много ошибок;
— AInspector Sidebar for Firefox — в отличие от предыдущих валидаторов, позволяет находить ошибки в логике применения aria-атрибутов. Кроме списка ошибок выдает также список проверок, которые рекомендуется сделать вручную.

Но лучшая проверка — живой тест. Можно, например, скачать NVDA (свободно распространяемый скринридер), включить режим «Просмотрщик речи» и зайти на сайт. Или обратиться за помощью к незрячему.

— Расскажите о UAradio — как пришла идея запустить свой радио-сервис?

Это проект для души. Идея родилась в 2014 году — я заметил, что тогда стало появляться много хорошей украинской музыки, но было мало радиостанций, которые бы ее крутили. Это сейчас уже появился закон о квотах.

Кроме меня, в проекте задействована музыкальный редактор Юлия. Она занимается формированием плей-листа.

— Какие у вас дальнейшие планы? Какие активности планируете?

Есть идея развивать «Детектор Web доступності», собрать команду и создать полноценный информационный сервис — чтобы разработчик, узнав, что его сайт недоступен, мог обратиться к нам, получить информацию, заказать тестирование, получить рекомендации. Это все без оплаты со стороны разработчика — проект волонтерский.

— Что можете посоветовать незрячим начинающим программистам?

Сейчас есть огромное количество возможностей для развития — множество онлайн-учебников, открытые онлайн-курсы. Учиться стало намного проще, чем 10-15 лет назад, когда я сам был студентом.

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось3
До обраногоВ обраному4
LinkedIn

Схожі статті




30 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Цікава стаття. Вражає, що така дрібничка як коректна верстка допомагає вирішити таку значну проблему.

Цейтлін Георгій Овсійович — один з наших вчених алгоритмістів, роботами якого я активно користувався, коли займався наукою — теж був з дуже слабким зором, і програмував, викладав студентам кібернетику і створив ПЗ для інших незрячих програмістів. — uk.wikipedia.org/...​Цейтлін_Георгій_Овсійович
Так, що дорогу подолає той, хто йде!

Класс! Пример UZ.gov.ua особенно порадовал.

У нас в офисе тоже есть незрячий программист, на фулл тайме. Пилит API на PHP. Очень веселый и отзывчивый парень, многим интересуется и увлекается. Иногда даже играет DJ сеты в местных клубах и на корпортивных вечеринках компании. То что и как он делает вызывает уважение!

А дисплей с Брайлем здесь достать реально?

Реально. Но цены на них высокие — от $2000. И это за 14 клеток! В этом году должны выйти устройства с адекватными ценами.

Дмитрий, спасибо за новую и важную информацию. Подскажите, а как с мобильными устройствами. У них тоже есть скринридеры?

Да. В iOS — Voice Over. В Android — Talkback. Нетребуют установки. Включить можно в настройках: в iOS — «Основные — универсальный доступ». В Android, если не ошибаюсь, раздел называется «Специальные возможности».

При общении с администрацией я делаю акцент не столько на социальную ответственность, сколько на практическую выгоду — объясняю, что незрячие люди — это достаточно большой процент потенциальных клиентов, они тоже пользуются сервисами, платными услугами, и для бизнеса невыгодно их игнорировать. Небольшие изменения в коде могут привести 3-5% новых потребителей.
Цифра основана на каких-то расчетах, или просто из головы?

Обсуждаем это немного ниже: dou.ua/…​blind-programmer/#1078485 . Как я понимаю — цифры взяты с потолка и актуальны не для всех бизнесов.

той момент, коли так хочеться плюсанути статтю на доу, але нема кнопки..

если не визуальная часть я более-менее понимаю как не глядя программировать, но как «увидеть» скринридером что верстка поплыла? не воображать же в голове как оно бы выглядело, читая вестку?

Естественно, без подтверждения зрячих, что всё ок, в паблик не выкладываю.

Дмитрий молодец! Даже не представляю, как это сложно быть незрячим в Украине. Здесь можно послушать как это в Иране: changelog.com/podcast/206

Вопросы принимаете? Интересно, есть ли инструменты аналитики, которые позволяют оценить аудиторию сайта, использующую различные accessibility инструменты?

Спасибо! Таких инструментов не встречал. Скорее всего, это не возможно отследить. Но на 100% не уверен )

Немного погуглил вопрос. Как я понял, эта проблема упирается не только в техническую невозможность, но также и в этическую. Как обычно, на западе очень обеспокоены приватностью, в данном случае приватностью людей с ограниченными возможностями. И вот проблема: бизнес не будет оптимизировать сайты, пока не поймет экономическую целесообразность, а оценить профит ему не дают нормы приватности. В итоге, как мне видится, проигрывают все.
Я считаю, монополии и государство обязаны оптимизировать. К сожалению, кейс УЗ хорошо демонстрирует наплевательское отношение к людям с ограниченными возможностями в Украине.
Но в случае с бизнесом, все может решить win-win договоренность: accessibility инструменты раскрывают информацию, о том, что они используются; бизнес, который получает значительную долю такого трафика, оптимизирует сайты и получает дополнительную прибыль; незрячие люди получают достойный сервис.
Вас лично сильно беспокоит раскрытие информации об используемых accessibility инструментах?

Меня вопрос приватности не беспокоит. Но если браузер сможет получать доступ к информации о том, что запущен скрин-ридер, то он может иметь доступ и к другим приложениям.

Меня очень радует, что в последнее время все чаще и чаще всплывают темы доступности технологий. А люди, которые этим вопросом занимаются не из праздного интереса, априори у меня вызывают уважение и надежду на светлое будущее. Но такие люди как Дмитрий — по истине герои, о них надо писать, говорить, они дают надежду и показывают примером, что все возможно. Причем не где-то, а в Украине, где людям с ограниченными возможностями приходится весьма непросто.
По поводу самого вопроса — каким образом стоит тестировать свое приложение / сайт, чтобы быть уверенным, что он доступен для всех? Включать скринридер и смотреть, насколько удобно и легко можно пользоваться продуктом?

Спасибо!

Для поверхностной проверки можно использовать сервисы, ссылки на которые есть в статье. Но в идеале проверять скрин-ридером. Например, на iOS и Android есть встроенные функции экранного доступа. Можно включить и протестировать. На Windows проще всего протестировать в NVDA.

Такие люди достойны того, чтобы о них писать. Радует то, что они не опустили руки, а занимаются делом, полезным для общества делом, а не в метро стоят/ходят с протянутой рукой.

Сразу вспоминается Джеф Раскин с его «Интерфесы: новые направления в проектировании компьютерных систем»

Элементы интерфейса часто можно называть привычными в том случае, что они могут легко использоваться «слепым» пользователем. Интерфейсы, построенные на основе принципов, изложенных в этой книге, часто могут использоваться даже слепыми пользователями, — а по отношению к тому, что находится вне нашего локуса внимания, мы все являемся в самом прямом смысле слепыми.

То, насколько чудовищный UX большинства современных систем с этой точки зрения просто позор.

К слову, EMACS Speak вроде бы популярное рабочее окружение для слепых программистов.

У меня нет слов! Восхищаюсь людьми, которые в трудных ситуациях сохраняют силу духа и не отчаиваются, но история Дмитрия просто уникальна в этом смысле. Дмитрий, желаю вам успехов и удачи во всех ваших начинаниях!

Дима, Спасибо Вам!

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

Да, я полез сразу в комменты в ожидании этого. Не сомневаюсь в потенциале аудитории ДОУ. Но, видно, не все еще потеряно. Ну а по поводу Дмитрия — заслуживает уважения.

Я знаком со многими незрячими разработчиками. Я не уникальный и далеко не самый лучший программер ) На роль диковинки соглашаюсь только ради продвижения в массы темы доступности сайтов.

Я бы не выдержал даже эмоциональной нагрузки, когда из тебя делают какую-то диковинку на обозрение публики.
Алексей,когда читаете другие статьи об успехах программистов, то тоже под статьей пишите о них как о «диковинках на обозрение публики»? Это вопрос риторический.
А Дмитрию выражаю свое уважение и восхищение! Плюс это еще и пример, который вдохновляет других ребят.
«незрячий программист»
Незрячий верстальщик.

Чаще пишу на PHP, чем верстаю. Верстка — в основном исправление семантики.

Спасибо за статью — яркий пример трудолюбия и профессионализма, это достойно уважения.

Підписатись на коментарі