У меня есть хороший знакомый, который в 25 лет полностью потерял зрение. Представляете, все то, что для нас привычно, для него изменилось? Компьютеры и телефоны превратились в кирпичи, и толку от них стало мало. Или нет?

Привет! Меня зовут Андрей Кузнецов. Я frontend lead в «Рунет Бизнес Системы». Мы разрабатываем сервис для интернет-эквайринга банков, и работаем по модели White label, поэтому мне нельзя называть клиентов. Но я хочу рассказать, как у нас в компании появилось accessibility. То есть, доступность — возможность использования интерфейса всеми, независимо от физических или технических ограничений. Это история о том, как мы это нашли, на какие грабли наступали и к чему пришли в данный момент. Я буду считать, что не зря всё это написал, если после моего рассказа, вы захотите сделать шаги в сторону того, чтобы accessibility появилось и в ваших продуктах.

Для начала расскажу, что такое доступность. Например, на улице яркое солнце и экран бликует так, что вы не можете нажать на кнопку, потому что не видите ее. Этот интерфейс в данный момент для вас недоступен. На это есть две причины:

• разработчики телефона сделали плохой экран;

• разработчики фронта сделали недостаточно яркую кнопку. 

Поговорим про физические ограничения. Потому что у людей с ними, больше всего препятствий в пользовании нашими продуктами. Вообще, accessibility — это подтермин известного всем фронденд-разработчикам usability.

Удобство пользования интерфейсом разделяет людей на три основных группы по ограничениям:

Постоянные, это когда человек родился, например, с синдромом ДЦП, и у него тремор рук. Он не может пользоваться мышью, ему приходится пользоваться только клавиатурой. Временные, когда человек покатавшись на лыжах, сломал свою основную руку, и ему надо учиться пользоваться другой (непривычной) рукой. Это может быть очень неудобно, и какие-то вещи становятся недоступными. А ситуационные ограничения, когда покушали арбуз, у вас руки грязные, а вам надо срочно отправить сообщение. Вы локтем пытаетесь нажать enter, если, конечно, разработчик такое предусмотрел. Но помимо трех классических категорий людей, есть еще одна, которой это очень нужно.

У вас есть варианты, кто это? Это профессионалы. Для кого работа с клавиатурой — должна быть максимально эффективной и производительной.

Вспомним эпоху Total Commander, когда вы мгновенно справлялись с копированием файлов с помощью клавиатуры. Это намного быстрее, чем переносить руку на мышку, выделять, перетаскивать. Или вспомним какого-нибудь разработчика, который работает в Vim, вообще не тратя время на перенос руки на мышку.

Коммерческая сторона вопроса

Когда в 2005 году я был маленьким фронтэнд-разработчиком, то еще ничего не знал о доступности. Тогда в моем инфопространстве появился Вадим Макеев и он говорил, что ее надо обязательно делать. Я не понимал, зачем и кому это надо, но Вадиму верил.

Также в то время, если кто помнит, была такая штука:

Этот значок указывали в футере сайта те, кто прошел валидацию от W3C. Он, в принципе, и сейчас работает. Вы можете проверить свою верстку на ошибки: где у вас тег не закрыт, где не правильная вложенность, где Alt не проставлены у изображения. У меня был огромный азарт, я получил этот значок на своем сайте, но еще не понимал, что это, в принципе, уже 50% того, что нужно для доступности.

Я делал это неосознанно, но  в 2016 году попал на проект для крупной российской авиакомпании. Ей было нужно выполнить международные требования доступности для авиакомпаний. Например, к ним относятся пандусы и подъемники в аэропортах. И, в том числе, возможность покупки авиабилета для незрячего.

В тот момент мне посчастливилось работать с Артемом Геллером. Он проводил аудит моей работы и, наподобие валидатора, говорил где, какие теги надо проставить, чтобы комиссия сочла сайт доступным. А когда я начал разбираться, оказалось, что это не просто юридические требования, но еще и большие финансовые возможности.

У 10% людей в мире существуют какие-либо ограничения. 284 000 000 человек имеют нарушения зрения. По неутешительным прогнозам ученых, к 2050 году их количество может увеличиться втрое. В первую очередь, это происходит из-за повышения населения планеты и увеличения продолжительности жизни. За внимание этой огромной аудитории сейчас все сильнее борются большие компании во всем мире. Ведь это увеличение конверсии и прибыли. И, в конце концов, это просто хороший поступок.

Моральная сторона вопроса

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

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

Валерия пригласила на встречу незрячего тестировщика. Он пришел со своим ноутбуком, клавиатурой, открыл нашу страницу и начал ей пользоваться на такой же скорости, как я. Это достигалось за счет специальной программы, которая озвучивала всё на четырехкратной скорости. Слух обычных людей для этого не приспособлен. А тестировщик все успевал и сразу дал нам обратную связь.

Нам казалось, что для незрячих надо озвучивать более подробно и называть какие-то вещи по-другому. В этом и была проблема. Например, незрячий звонит своему другу и говорит: «Зайди на сайт в раздел такой-то, там прикольная акция», а его зрячий друг, не находит там такого раздела, потому что названия не совпадают. Появляется конфликт двух миров — зрячего и незрячего. Поэтому надо делать так, чтобы версия была одна для всех. Чтобы понять, как это работает, давайте разберемся, как незрячие пользуются сайтами.

Сейчас на рынке четыре основные специальные программы:

• NVDA (бесплатная),  JAWS (платная) для Windows;

• VoiceOver для MacOS, iOS;

• TalkBack для Android.

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

Здесь есть такой функционал, как Ротер. Можно мгновенно переключиться между заголовками, блоками или ссылками. За счет этого достигается огромная скорость. Обычному человеку пришлось бы скролить, искать это все, даже визуально. А Ротер сразу понимает, что это активный элемент и проваливается в него. Это очень удобно.

Кстати, есть забавный момент. Когда незрячие люди пользуются телефоном, у них обычно выключен экран. Или он на минимальной яркости. И хочется подойти и сказать: «У тебя телефон не включен». А ему не надо. Он его, итак, «видит».

Еще людям, которые не видят, помогает пользоваться Интернетом дисплей Брайля. Палочки выезжают, составляя текст, который описывает то, что происходит на странице.

Но у этого устройства есть несколько проблем. Во-первых, это его цена. Как говорит мой хороший знакомый, устройство для доступности по недоступной цене. Во-вторых, не все знают шрифт Брайля. Он сложно дается в изучении, особенно людям, которые приобрели какие-то проблемы со зрением в процессе жизни. Его не так много в практике. В основном в аэропортах и на вокзалах. В-третьих, это только устройство вывода. На дисплее Брайля нельзя ничего ввести. 

На что можно ориентироваться в разработке?

Есть спецификация от W3C, но это тонны информации, которые надо переработать и осознать. Она еще и на английском. Не все разработчики его знают. Поэтому хочу дать пару рекомендаций для увеличения уровня доступности вашего продукта.

Первая рекомендация

Первое, что мы сделали в компании, стали просить дизайнеров отрисовывать все состояния элементов.

Это нужно для тех, кто работает с клавиатурой. Когда элемент в фокусе, и человек работает с клавиатурой, ему надо понимать, где он находится на странице в данный момент времени. Если у человека сломалась мышка, у него должна быть возможность купить ее без нее. Дизайнеры очень не любят этим заниматься. Чтобы их не уговаривать, есть волшебный лайфхак, говорите, что конверсия выше. Так им некуда деваться :)

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

<html lang=”ru» class=”focus-disabled»>

.focus-disabled :focus {

  outline: none !impotent;

}

<html lang="ru" class="focus-disabled">

.focus-disabled :focus {

  outline: none !impotent;

}

По умолчанию на html есть класс, который на всем документе отключает outline, отвечающий за рамку активных элементов. Это когда человек начинает работать с клавиатурой, переходит на tab, пробел и стрелки. Если убрать этот класс все автоматически очень эргономично работает. 80% наших клиентов, для которых мы разрабатываем фронт, даже не в курсе, что у них есть доступность клавиатуры (они этим не пользуются). А у нас это идет в коробке как отдельный функционал.

Вторая рекомендация

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

Пример с сайта Frontend Conf. Видно, что не подписан alt декоративного элемента. Это не обязательно, потому что в этом элементе находится заголовок, который дублирует, что это такое. Но разные Screen Reader по-разному зачитывают этот момент. VoiceOver нормально, а те что в Windows будут ругаться, что картинка не подписана. 

Но что делать, когда ваши пользователи сами генерируют контент? Например, вставляют фотографии в социальные сети. Их же не заставишь писать alt для всех картинок.

Тут на помощь приходят нейронные сети. Часто социальные сети используют их, чтобы определить, что находится на фотографии и заполнить alt. Кстати, делают это достаточно точно.

Третья рекомендация

Это известное для фронтэнд-разработчиков понятие семантической верстки.

Ее смысл в использовании только тех тегов, которые нужны для определенных элементов. Если у вас навигация, то элемент навигации, если список — то список. Тогда Screen Reader сможет сказать, что список, например активный или неактивный, и человеку сразу станет все понятно. Я люблю спрашивать на собеседованиях: зачем нужна семантическая верстка? 80% кандидатов отвечают, что это надо для SEO, но в 2021 году это слабый аргумент. Мы в основном делаем внутрикорпоративные системы, либо с авторизацией, куда не заходят роботы. Для остального есть сеошники. 

Если мы будем грамотно использовать семантическую верстку, то это закроет 80% доступности. А для оставшихся 20% есть сложные атрибуты.

Четвертая рекомендация

Поддержите озвучку сложных элементов.

<button aria-pressed=”false»>

Toggle Button

</button>

<div role=”alert”>Error! Try again!</div>

Это aria-аттрибуты, их более 150 штук в спецификации, и атрибут role. В данном примере это кнопка, которая вжимается или отжимается. Атрибут role для того, чтобы на валидации сработала ошибка, и ее озвучило человеку.

Все это понятно, но разработчикам привычнее ориентироваться на готовый сервис, который все это уже сделал. В России можно отметить главную страницу Яндекса. Она хорошо озвучивается, и за ней следят. Еще сайт президента России. Его делал Артем Геллер.

Там все качественно, но есть одна проблема: нет ни одного элемента <button>Кнопка</button>, только <a role=”button”>Кнопка</a>. Это не одно и то же. Если вы используете ссылку с role button, то для ее нажатия, надо нажать enter на клавиатуре. А если надо нажать по кнопке — это пробел. И придется писать кусок кода, который будет обрабатывать эти события. Если вам надо сделать кнопку неактивной, просто ставите атрибут disable. Для ссылки это не работает. Опять придется писать большую пачку кода JavaScript, который будет реализовывать эту логику.

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

Пятая рекомендация

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

Все оказалось просто. Я пришел туда и попросил контакты читателей. Мне с радостью помогли. Если думаете, что у вас такой библиотеки нет, зря. Они есть в каждом городе, районном и региональном центре. Если интересно откуда их так много в нашей стране и по всему СНГ. После Великой Отечественной войны было огромное количество людей, потерявших зрение в ходе боевых действий. А поскольку в то время стоял тренд на образование, массово появились эти библиотеки и до сих пор существуют и работают.

Работа с незрячими — суперклассный опыт, который нам сейчас помогает. У них разные заболевания. Например, вы знаете, зачем некоторые незрячие носят темные очки? Я не знал. Оказывается, некоторые могут видеть только при тусклом свете, тогда они, например, различают силуэты людей. Другие наоборот видят что-то, только при ярком свете. Поэтому одни пользуются только Screen Reader, а другие — контрастной темой, или темной темой. И когда такие люди тестируют страницу, быстро понимаешь, что и где надо доделать.

Трудозатраты

Теперь, давайте прикинем, во что такие доработки могут обойтись. По моим расчетам, обычному разработчику middle-уровня в среднем надо около 15 дней на то, чтобы изучить доступность на хорошем, качественном уровне. Дальше его временные затраты на выполнение задачи возрастают только на 5-7%. Он что-то делает, верстает, а по пути проставляет атрибуты, Arial Label и всё. Это, конечно, может, не относиться к сложным задачам, где у вас какой-нибудь drag and drop в сложной системе, но если покрывать сначала хотя бы самый основной функционал, этого достаточно. 

Что забавно, есть «поезд JavaScript», который куда-то очень быстро мчится, и порой не успеваешь изучить, технологию, а уже поменялась версия, и там несовместимость. Надо опять что-то учить. В Accessibility ничего не меняется годами. Здесь как версталось, так и будет, думаю, еще минимум лет пять.

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

<nav aria-label="Accessibility navigation" class="visually-hidden">

  <ul>

    <li>

      <a href="#content">Skip to content</a>

    </li>

...

    <li>

      <a href="mailto:support@company.com">Support</a>

    </li>

  </ul>

</nav>

Здесь у нас прикольная история о том, что мы сделали меню, которое слышат только незрячие люди. Обычный человек, когда туда попадает, просто проходит мимо табом. Мы оставили ссылку с обратной связью, чтобы незрячие люди могли написать отзыв. Обычно они о том, что когда разработчик что-то делает, у него сильно искажен лингвистический аппарат. Например, у нас в профессиональной среде сохраненная карта называется связкой. Мы так и пишем – «удалить связку». Не задумываясь, потому что для нас это нормально. А обычные люди не понимают, что такое связка. Обратная связь помогает сделать названия понятными для людей. 

Что мы можем как разработчики?

Я бы мог прийти к бизнесу, к своему руководству и сказать: «15 дней мы ничего не делаем, чтобы изучить доступность, а дальше будем снова задачки пилить». Меня бы никто не послушал. Поэтому первое время мы делали это в свободное время. Нам надо было запилить демку, чтобы показать, как это работает. Потому что рассказать суть проблемы очень сложно. А когда мы показали демо, высшее руководство нас поддержало, и мы начали пилить это официально. Выбрали, какие продукты первыми делаем доступными, а какие — следующими.

Кстати, подобные демо или видео о доступности — хороший довод для потенциальных заказчиков. Так, вы сразу показываете, чем ваша компания отличается от других, почему выбрать именно вас, а не конкурента. Надо обсуждать доступность со своей командой, делиться знаниями. Чтобы, например, настроить линтер на заполнение Alt на картинках, если у вас их много.

Очень важный поинт — это проверять функционал на реальных людях. Потому что у каждого человека совершенно разные привычки и особенности в пользовании интерфейсами. 

Бывает, что менеджер не понимает важности таких задач и разработка до них никогда не доходит. Тогда очень помогает встреча (если это возможно). Приведите незрячего или человека с проблемами опорно-двигательного аппарата, который пользуется только клавиатурой, и покажите, как это на самом деле. Тогда эмпатия срабатывает на максималке, и менеджер говорит: «Будем делать!».

Давайте делиться этим опытом! Это относится не только к IT-сфере, а к доступной среде в целом. Это то, чем я сейчас занимаюсь. Если тоже хотите помочь, есть классное приложение Be My Eyes. Через него можно зарегистрироваться как волонтер. Если позвонит незрячий человек, и вы успеете взять трубку, он попросит подсказать, что видит камера его телефона. Потому что он этого не видит. Я, например, помогал выбирать цвет нитки, чтобы незрячий мог заштопать носки. Или помогал проверить уровень сахара в крови. Или заказать что-то через Интернет, потому что доступных сайтов, пока еще очень мало.

Послесловие

До того, как начал заниматься Accessibility, я думал, что незрячие вообще не выходят из дома, а родственники помогают им взаимодействовать с миром. Теперь же могу сказать, что у этих людей, как правило, очень сильный характер. И порой, он помогает им проживать намного более яркую и насыщенную жизнь, чем, условно, здоровым людям. Тот самый мой знакомый парень, который в 25 лет потерял зрение, в прошлом году забрался на Эльбрус. Он полностью не видит. Просто хотел показать, что это возможно, и снял об этом фильм.

Во фронтэнд-сфере про Accessibility знают уже давно. Год назад про это заговорили в продуктовой среде. О доступности узнает все больше и больше людей, но только от нас с вами зависит насколько этот мир будет более дружелюбным для всех категорий людей.

Ближайшая конференция FrontendConf пройдет уже 24 и 25 октября 2022 года в Москве в Старт Хаб (Start Hub). Полную программу, расписание и билеты смотрите на сайте