Меня зовут Алёна, я тестировщица невизуальной доступности в Альфа‑Банке. Моя работа — убедиться, что мобильное приложение одинаково понятно тем, кто видит экран, и тем, кто нет. Это моя первая работа в тестировании, и она сразу началась с accessibility. Удачная случайность, которая задала направление. Я рекомендую каждому QA хотя бы раз попробовать изучить accessibility. Это не просто расширяет технический кругозор, но и меняет само мышление: вы начинаете видеть продукт шире и глубже, а ваша работа обретает новый, по-настоящему человеческий смысл.
В чём состоит моя работа
Невизуальная доступность — это проектирование и вёрстка интерфейса, при которых человек может полноценно управлять устройством и получать информацию, не глядя на экран.
Важный нюанс: невизуальная доступность — это когда экраном можно пользоваться, не глядя на него, но не обязательно «на слух». Если приложение адаптировано, им могут пользоваться и слепоглухие пользователи: например, подключить брайлевский дисплей, и тогда информация будет передаваться брайлевским выводом.
Чтобы ресурс/приложение соответствовало критериям невизуальной доступности, код сайта или приложения должен быть написан так, чтобы передать незрячему пользователю визуальный опыт. На Android для этого, к примеру, используют атрибут contentDescription, на iOS — accessibilityLabel, в вебе — alt‑тексты и семантическую разметку.
Моя работа состоит в проверке экранов — чтобы все элементы на них были доступны для прочтения скринридером (о нем чуть позже). Я работаю в паре с незрячей тестировщицей Надеждой. Она проверяет приложение так, как им пользуется реальный незрячий человек: на слух, последовательно, с опорой на озвучку. А я перепроверяю: совпадает ли текст, который озвучивает скринридер, с тем, что реально на экране; корректно ли работает порядок фокусов; названы ли все элементы по‑русски, а не английскими ключами из кода.
Читайте статью Нади «Пять моих принципов, чтобы жить , строить карьеру и не унывать без зрения» |
Что в основном мы ловим:
У изображения есть alt, но описывает не то, что важно в контексте.
У поля ввода есть подпись, но она не соответствует назначению поля.
У элемента есть роль, но не соответствует поведению: чекбокс объявлен как кнопка, как вариант.
Фокус «проваливается» мимо видимых элементов при навигации.
Элемент доступен, но активация ведёт не туда или никуда не ведёт.
И прочее и прочее.
Работы интересна. И ее много! В теории невизуальная доступность это про «сделай правильную разметку компонентов в XML, расставь корректные contentDescription, придерживаясь требований и стандартов, например, WCAG» (в России также есть ГОСТы на доступность сайтов и приложений). В реальности проект, на котором я работаю, живёт достаточно давно и компонентная база, для которой мы поддерживаем доступность, состоит из:
компонентов android;
компонентов из android material design;
локальных компонентов;
компонентов из старой дизайн системы;
компонентов из новой дизайн системы;
диполей;
виджетов;
и других элементов из компонентной базы веб-разработчиков.
А для сборки экранов используем: натив, виджеты, диполя, SDUI, многошаг и webView.
В основном, мы работаем вручную, так как проверку доступности можно автоматизировать лишь частично. Автоматика хороша в том, что можно проверить по правилам: есть ли у изображения alt‑текст, есть ли у кнопки название, хватает ли контраста, прописан ли язык страницы. Такие инструменты, как Accessibility Scanner на Android, Accessibility Inspector в Xcode на iOS или axe DevTools и WAVE на вебе, пройдут по всем экранам и соберут очевидные нарушения за минуты. Но, по разным оценкам, автоматизация находит лишь около 30–40% проблем доступности — и почти все они формальные.
Остальные 60–70% — логические проблемы, которые скрипт не различит. Логические баги автоматика не поймает, потому что для их поиска нужно понять замысел интерфейса, а не только разметку.
И теперь можно обратиться к такому понятию, как скринридер, более подробно.
Про скринридеры и терминологию
Скринридер это программа экранного доступа: она последовательно озвучивает содержимое интерфейса и позволяет управлять устройством без взгляда на экран. Их несколько, и они привязаны к платформам со своими нюансами.
На всю продукцию Apple из коробки установлен VoiceOver.
На Android основное решение — Google TalkBack, который входит в состав Android Accessibility Suite, и если этот пакет удалён или не обновлён, TalkBack может не появляться в настройках. Тогда скринридер можно установить отдельно — из Google Play или RuStore.
А ещё есть Samsung с собственной разработкой для устройств Galaxy — Voice Assistant. Начиная с оболочки One UI 3.1 Samsung объединила Voice Assistant с Google TalkBack: на современных Galaxy работает TalkBack, но со «самсунговскими» надстройками. На десктопе картина своя: на Windows это NVDA или JAWS, на macOS — встроенный VoiceOver.
Когда 1,5 года назад в Альфа‑Банке появилась вакансия, связанная с невизуальной доступностью, то я сразу поняла, что мне это интересно, хотя на тот момент я не знала про доступность ничего. И скринридер — это первое, с чего я начала изучение темы.
Читайте также статью «Эх, невизуальная доступность, как же тебя наладить». В ней Иван Шуст, техлид андроид-разработки рассказал, как налажвал и внедрял процессы accessibility (начиная ещё до того, как появилась вакансия, на которую я откликнулась) |
Хотя я изучала живые демонстрации: записи людей, работающих с экранными дикторами, первое впечатление от использования скринридера всё равно оказалось неожиданным: будто кто‑то описывает тебе весь экран вслух. Именно поэтому я регулярно показываю скринридер друзьям и родным — и вижу одну и ту же реакцию: удивление и вопросы «а что это вообще такое?».
Я делаю это не ради одного лишь вау-эффекта. Экранный доступ нужен далеко не только незрячим: ещё пожилым людям, людям с травмами, тем, кто работает руками. Мне самой он помогает, когда я лежу с закрытыми глазами на наращивании ресниц: два часа я полноценно пользуюсь телефоном без единого взгляда на экран. Это и есть доступность в действии — не абстрактный стандарт, а привычный инструмент.
После знакомства со скринридерами мне было важно понять, какие элементы существуют, какие у них роли, как должен читаться экран и как должен работать фокус. Если в обычном режиме нажать на кнопку, она срабатывает сразу. Со скринридером иначе: коснувшись экрана, вы не активируете элемент, а переводите на него фокус — программа подсвечивает его визуальной рамкой и озвучивает содержимое: текст, иконку, название кнопки. Активация — отдельное действие, двойной тап.
Ещё изучала терминологию, которой пользуются сами люди со скринридерами. Например, я заметила, что Надя говорит не «свайп», а «взмахивание». Взмахивание (флик) — это движение пальцем с отрывом от экрана в конце. Причём жестов взмахивания много, и они различаются количеством пальцев:
Взмах одним пальцем слева направо переводит фокус на следующий элемент интерфейса.
Взмах двумя пальцами вверх перелистывает список вниз (Android).
«Зигзаг»— двумя пальцами вправо, не отрывая — влево, не отрывая — снова вправо — это аналог кнопки «назад» (iOS).
Также есть «двойной тап» с удержанием, «волшебное касание», «угловой жест» и другие — жестов в скринридерах действительно много, и их тоже хорошо бы знать для качественного тестирования.
На том этапе мне хватало ресурсов из интернета. Сейчас для моих задач этих знаний достаточно, а с чем‑то неизвестным я иду к Наде.
Если вам интересно тестирование невизуальной доступности, то вы тоже пройдете этот путь, так как скринридер — это первое, с чего надо начать тестировщику доступности, и без него никуда.
Вернемся к работе: что дальше после того, как мы определили проблемы?
Что дальше с багом?
Когда Надя отдаёт мне багрепорт, я завожу дефект особого типа — FR, запрос на доработку. Если в ходе ретеста я нахожу новые баги, описываю их и согласую с Надей.
В начале FR я добавляю описание бага и прикладываю наш чек‑лист — это снимает большую часть вопросов уже на старте. Дальше идёт обычный багрепорт: предусловия, шаги воспроизведения, ожидаемый и фактический результат, а в конце — видео. Видео здесь обязательно: скринридер невозможно «увидеть» по текстовому описанию, а записи показывают и жесты, и озвучку, и порядок фокусов. Потом я ищу ответственных и передаю им багрепорт.
Запрос на доработку не влияет на показатели команды — но только в первые три месяца, которые даются на исправление. В течение этого времени ко мне приходят команды с разными вопросами. Могут зайти уточнить, как что‑то воспроизвести со скринридером, или пожаловаться: «Программа читает „один рубля“ вместо „один рубль“». В таких случаях я либо отвечаю и консультирую сама, либо записываю повторное видео и остаюсь на связи. Бывают забавные вопросы: «А как дойти до такого‑то экрана?» — хотя это флоу самой команды. Но я всё равно записываю видео и помогаю разобраться.
В особенно сложных случаях перенаправляю запрос от разработчиков Наде.
Основные вопросы, которые действительно требуют обсуждения, — как исправить проблему. У нас бывают непростые элементы: например, недавно мы разбирали новую карусель, которую планируем внедрить в ближайших обновлениях. Это область постраничной горизонтальной навигации с дополнительными кнопками, которые подвешиваются в зависимости от контекста. Разработчик не мог понять, как грамотно выстроить навигацию при включённом скринридере: чтобы отрабатывалось и переключение между элементами карусели, и перелистывание всего экрана, а выбранный контекст при этом сохранялся. Надя помогла разобраться в проблеме и предложила решение. Разработчик поменял реализацию компонента, и сейчас они совместно её отлаживают.
Если за три месяца команда не выполнила доработку, мы создаём дефекты промышленной среды — и это уже другой уровень серьёзности: такой дефект влияет на метрики команды. Тогда я пишу коллегам, которые помогают с созданием дефектов промо‑среды, описываю проблему — а они переносят её в нужное пространство в Jira. Я слежу, чтобы корректно заполнились все пререквизиты и прикрепилось видео, и в случае вопросов снова остаюсь на связи с командой.
1+1
Наше разделение труда — не случайность, а самый эффективный формат из известных мне. Причин несколько.
Незрячий тестировщик использует продукт так, как это делает реальный незрячий пользователь. Зрячий тестировщик, наоборот, видит расхождение между тем, что показывает экран, и тем, что озвучивает скринридер. По отдельности каждый закрывает «слепую зону» другого.
Классический пример: кнопка без фона или рамки, торчащая за пределы контейнера. Для Нады такого бага не существует, так как скринридер озвучивает её нормально. Но зрячий пользователь с остаточным зрением или пользователь в ярком свете не найдёт эту кнопку на экране. И наоборот: пустая ссылка без текста для меня невидима и на экране всё выглядит нормально, а Надя слышит слово «ссылка» без названия или «пробел заголовок».
Плюс есть ещё один эффект. Незрячий тестировщик живёт с доступностью каждый день: он знает, как устроены жесты, что раздражает пользователей, какие паттерны привычны. Это непередаваемая экспертиза — её нельзя вычитать в статье. Зрячий тестировщик хорошо понимает общий контекст продукта и команды и служит «переводчиком» между миром незрячих пользователей и разработчиками.
И нашей экспертизой мы с удовольствием делимся.
Где команды разработки берут экспертизу по доступности
В большинстве случаев у нас есть заготовленные ответы в чек‑листе, составленном Надей. Там подробно описаны процессы тестирования, чтобы команды могли сами справляться:
Есть памятка по скринридеру и видеоинструкции по TalkBack и VoiceOver:
А также:
терминология, определения и шпаргалка по типам элементов, на что обращать внимание, какие состояния могут быть и примеры, много примеров,
требования к доступности конкретных компонентов — как мы понимаем, что кнопка, изображение или заголовок доступны,
раздел с лучшими практиками, особенно подробно расписанный для Android и с примерами.
В конце — интерактивные примеры в видеоформате, потому что контекст нужно показывать, а не описывать, чтобы было видно, как делать хорошо, а как делать не надо. Всё это живёт в Confluence.
И это не считая того, что Надя проводила воркшопы: показывала, как пользоваться каждым скринридером — отдельный воркшоп для Android, отдельный для iOS, — демонстрировала, как она, будучи незрячим пользователем, работает с программой и какие функции доступны разработчикам. Один воркшоп занимал около часа — и это только по основным настройкам программ экранного доступа.
Эти встречи работали лучше любых рассылок, потому что дефекты доступности становились наглядными: мы демонстрировали скринридер прямо на продуктах Альфы. Интерес к теме возникал не после объяснений, а в первую минуту демонстрации. Это опыт, который я теперь считаю обязательной частью внедрения доступности: сначала дай людям услышать продукт глазами незрячего пользователя — потом разговаривай о требованиях.
А ещё есть публичный чат в корпоративном мессенджере, куда мог прийти абсолютно любой человек и попросить помощи или совета.
Я даже не знаю, что ещё можно придумать, потому что у нас уже всё есть, чтобы разобраться в вопросе) Но если в чек‑листе вдруг нет подсказки или я сама не знаю ответа, выношу вопрос на общее обсуждение с командой или отправляю людей на наш «сезон по понедельникам» — регулярный созвон, где каждый может задать вопрос команде в реальном времени, а лиды объясняют, как с этим работать.
Вместо вывода
Доступность — это не отдельная фича и не разовая проверка перед релизом. Это система: понятная терминология, живая экспертиза незрячих пользователей, связка «зрячий + незрячий тестировщик», формальные стандарты и человеческий взгляд, который автоматика не заменит.
Я работаю в accessibility-тестировании год, и если сжать его до какого-то «урока», то пусть он будет такой: если инструменты ищут формальные нарушения, то смысл интерфейса видит только человек, поэтому самый эффективный шаг для любой команды — не скачать очередной сканер, а один раз посмотреть на свой продукт глазами и ушами незрячего пользователя. После этого спорить о приоритетах доступности уже не приходится: вопрос «Зачем?» исчезает, и остаётся просто «Как?»
Оглядываясь назад, я чувствую искреннее удовлетворение от проделанной работы. Я вижу четкие перспективы в этом направлении: доступность — это не «галочка» в чек-листе, а огромное поле для профессионального роста. Мне интересно разбираться в том, как невидимые для большинства барьеры влияют на реальный опыт людей.
Именно поэтому я рекомендую каждому QA хотя бы попробовать изучить accessibility. Это не просто расширяет технический кругозор, но и меняет само мышление: вы начинаете видеть продукт шире и глубже, а ваша работа обретает новый, по-настоящему человеческий смысл.
