Выпуск 6

Собеседование на специалиста по веб-доступности

Темы

События

Расшифровка

Таня Фокина: всем привет! С вами «Инклюзивный ананас» — первый русскоязычный подкаст о доступных интерфейсах. Здесь мы обсуждаем всё, что связано с цифровой доступностью и делимся свежими новостями и событиями. Подпишись, чтобы не пропустить новые выпуски.
С вами ведущие подкаста Глаша Жур, фронтенд-тимлид и преподаватель на курсах по веб-доступности, а также Таня Фокина, редактор раздела доступности в Доке, дружелюбном справочнике по фронтенду, и большая любительница поговорить о доступности.

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

Новости

Глафира Жур: WCAG 2.2, наконец-то, стали официальными рекомендациями, ура! В новой версии появилось девять новых критериев успеха, которые касаются барьеров для людей с визуальными, моторными и когнитивными особенностями

Таня: а Злые марсиане выкатили четвёртую версию
плагина Polychrome для Figma, которая проверяет
контрастность на основе нового алгоритма проверки APCA.

Глаша: Google рассказали о новых доступных фичах своих продуктов, которые готовятся к релизу. Например, на Google Fonts уже появились удобные для чтения шрифты Andika, Readex Pro и Shantell Sans. На Android 14 улучшили функциональность экранной лупы, добавили быстрый доступ к настройкам размера шрифта, новый вид оповещений и Flash Notification для людей с глухотой и слабослышащих. Поработали над дизайном интерфейса и новыми функциями для приложения для сканирования предметов Lookout 4. В Chrome добавили новую функцию распознавания текста недоступных PDF-документов. А в Google Meet расширили поддержку языков для автоматических субтитров в режиме реального времени, в том числе и русский язык.

Таня: И последняя на сегодня новость — список кандидатов в Interop 2024, проекта по улучшению совместимости в вебе. Попали баги и фичи, связанные с доступностью. Из фич предлагают разобраться с Popover API, медиафичами inverted- colors для инвертированных цветов и prefers-reduce-transparency для поддержки отключения прозрачности в системе, а также имплементировать в браузер новый атрибут focusgroup для работы над фокусом элементов, которыми можно управлять клавишами со стрелками. Из багов планируют исправить странное поведение display со значением contents, из-за которого элементы теряют свою семантику, улучшить поддержку и работу <details>/<summary>, а также исправить баги, связанные с вычислением ролей и имён элементов в дереве доступности.

Что делает специалист по доступности

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

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

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

Это могут быть задачи для дизайнеров, для разработчиков, может быть задачи какие-то на ресёрч [исследования], возможно, что-то нужно в помощь ему оттестировать, и тогда подключаются тестировщики в работу. Ну, в общем, по аудиту в итоге нужно составить набор, пачку задач, и дальше эти задачи нужно приоритизировать, учитывая текущий приоритет разработки.

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

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

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

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

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

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

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

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

Типы вопросов и примеры вопросов про опыт кандидата.

Таня: давай, наверное, перейдём к вопросам, какие могут быть заданы такому человеку. Начнём с того, что могут из такого суперобщего задать по поводу твоего опыта, твоей карьеры и почему ты вообще решил заниматься доступностью. К такому разряду вопросов, более таких, наверное, эйчарских, я бы сказала, можно отнести то, как долго ты работаешь с доступностью, какой у тебя вообще есть опыт в этом направлении, какие проекты ты вёл или над какими работал, и о том, какие у этих проектов были особенности, с какими трудностями ты столкнулся, как их решал, или о каких-то интересных кейсах [примерах] могут попросить рассказать.

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

Глаша: у меня, кстати, с этим сейчас проблема. Застопоривается обучение. Когда ты очень много работаешь над одним и тем же, то вопрос, как обучаешься, может тебя реально в ступор ввести, потому что ты уже давно ничему не обучался, ты просто пашешь по заведённой схеме бесконечно, не успевая почитать, ни что WCAG 2.2 вышел, ни что ARIA обновляется до 1.3 [версии]. Вот это всё у тебя только каким-то урывками в моменте проскакивает, но ты не успеваешь уделить этому внимание, поэтому вопрос классный, и на нём очень часто валятся ребята на собесе, они вообще не понимают, зачем мы его задаём, как ты обучаешься, как находишь новую информацию, но мне кажется, это такой важный классный вопрос.

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

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

Глаша: наш любимый вопрос, да, мы на него часто ищем ответ, вот у нас целый выпуск на эту тему был. Можно ещё даже сделать несколько. И кто должен инициировать процесс работы над доступностью, её внедрение, в общем, такого, менеджерского плана.

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

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

Общие вопросы про доступность в целом

Глаша: ну что, с группами определились, давай пробежимся по вопросам самой общей группы. Будем делать ужасные вещи, я буду задавать тебе вопросы, а ты будешь на них отвечать, а потом мы с тобой поменяемся и посмотрим, насколько мы хороши как эксперты по веб-доступности.

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

Расскажи, пожалуйста, что такое доступность и в чём разница между доступностью и, например, очень часто спрашивают, в чём разница между доступностью и инклюзией. Но это может звучать, этот вопрос может по-разному звучать, там может втесаться туда user experience [пользовательский опыт], какой-нибудь дизайн инклюзивный и так далее. Ну вот с этими понятиями лучше разобраться, но мы спрашиваем у Тани, в чём разница между доступностью и инклюзией. Нас как раз недавно об этом спросили в комментариях к подкасту.

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

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

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

Глаша: отлично! Следующий вопрос. Кто основная целевая группа доступных интерфейсов?

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

Вторая группа — это, соответственно, люди с аудиальными особенностями, то есть слабослышащие, люди с глухотой, люди с разными другими состояниями, влияющими на их слух.

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

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

Есть ещё другая группа, мне кажется, что это не совсем про когнитивные, хотя встречала включение этих пользователей в эту группу когнитивных особенностей, но особенности связанны с неврологией, то есть тем, как работает твоя, в том числе, нервная система. Например, здесь можно назвать то же, как работает мозг, но уже в таком более, что ли, физиологическом ключе, например, например эпилепсия или Паркинсон. Это тоже, с одной стороны, когнитивная [особенность], с другой, Паркинсон — это, всё-таки, неврологическое заболевание, синдром, который влияет и на то, как работает твой мозг, и на то, как работает твоё тело. Так что вот эта группа неврологических особенностей, её можно отдельно тоже выделить.

Глаша: а какие основные проблемы возникают у пользователей в современном веб-интерфейсе? Например, мы тебя на веб собесим, поэтому нам интересен веб. Какие основные проблемы бывают у пользователей?

Таня: это могут быть проблемы, связанные с навигацией, это могут быть проблемы связанные с контентом, дизайном отдельно: визуальным, UX. Также это могут быть проблемы связанные с… с чем они ещё могут быть-то связаны? Ну с тем, что сайт вообще не открывается.

Глаша: кажется, мы это тут не рассматриваем, потому что ты сама сказала, что доступность — это, всё-таки, для людей с инвалидностью. Если не можешь открыть сайт, это, конечно, возможно, значит, что разработчик, который написал этот скрипт, он немножко того…

Таня: ну смотри, получается, что да, это какая-то мета-недоступность, как это назвать? Мета-недоступность.

Глаша: а конкретный пример можешь привести? Какого-нибудь самого распространённого бага, который ты встречаешь в своей практике на сайтах?

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

Диватоз в любом виде, потому что он тоже влияет, например, на общую структуру документа, когда у тебя вместо хедера class="header" и class="footer", и, соответственно, код влияет на структуру этого документа, на то, как легко по нему пользователям скринридеров, например, перемещаться.

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

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

Глаша: отлично. Слушай, а чем регулируется всё это? Какие-то документы, руководства, требования к обеспечению доступности? Как вообще с этим обстоят дела в доступности? Чем руководствуются?

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

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

Глаша: а можешь поподробнее про WCAG рассказать? Как он вообще выглядит? Что там требуют от нас? Вот какая у него структура?

Таня: WCAG, в общем, имеет несколько уровней устройства. Самая базовая вещь — это принципы, принципы доступности, которых всего четыре. Воспринимаемость, управляемость, понятность и устойчивость. Каждый принцип образует собой отдельное руководство, поэтому они, собственно, называются руководствами. И внутри каждого руководства уже есть конкретные критерии, например, критерии, связанные с управляемостью, с фокусом, порядком фокуса или с воспринимаемостью, понятная навигация, насколько я помню, или подписи к полям, чему угодно, каким-то интерактивным элементам. И каждый критерий, он бывает трёх уровней. Во WCAG 2.Х (то есть дальше будет немножко по-другому, третья версия) есть три уровня соответствия: А, АА и ААА.

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

Глаша: отлично! Очень хорошо всё описала. Расскажи, как бы ты тестировала доступность, если бы попала вот в продукт, и тебе нужно было прям с нуля всё протестировать, какие способы ты бы выбрала, какими чаще всего пользуешься?

Таня: начать проще всего с автоматического, потому что оно поможет найти самые базовые, простые, очевидные проблемы с твоим кодом, с разметкой, с атрибутами, если вы их используете. Контрастность тоже может какую-то почекать [проверить]. Тексты и фоны, ну вот, с картинками уже тут как раз ручное пригодится.

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

Так что, резюмируя, я бы начала с каких-то основных проблем, связанных с кодом и дизайном автоматическим способом, и дальше уже углублялась в навигацию, какую-то информационную архитектуру и как вспомогательные технологии, в конце концов, взаимодействуют с какими-то особенно сложными и важными компонентами, которые входят в юзерфлоу [пользовательский путь].

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

Глаша: а ты упомянула вспомогательные технологии. Можешь поподробнее рассказать, что это, какие бывают, в чём разница между скринридерами и программами, которые зачитывают текст тебе со страницы?

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

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

Глаша: а в чём разница со скринридерами и такими читалками?

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

Глаша: а вот мы насобирали кучу проблем с твоей помощью на своём сайте, и дальше нам нужно будет их как-то приоритизировать. Можешь ли прикинуть, как бы ты расставляла приоритеты при обеспечении доступности?

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

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

И можно в этом [приоритизации] полагаться, в том числе и на WCAG, на уровне, например, контрастность. У неё довольно высокий приоритет, потому что это базовый принцип контрастности, критерий минимального уровня, хотя там есть продвинутые. Или, например, критерии, связанные с валидной разметкой. Это вот, конечно, его больше не существует, но в том или ином виде он разбросан по всем другим критериям. Например, что ссылка не должна быть вложена в ссылку, alt у картинок — это тоже минимального приоритета вещь.

Здесь можно поэтому как бы жонглировать, с одной стороны, какой контент преобладает на сайте или какие пользовательские флоу [пути] у вас главные. С другой стороны, уже в рамках этого, исходя из контента, расставлять приоритеты на основе классификации, уровней доступности, которую предлагает WCAG.

Глаша: я бы взяла тебя на работу. У тебя очень глубокий, структурированный подход к получению и выдаче информации. Мы собеседуемся в уже существующий продукт, но если вдруг ты бы попала в идеальный мир, где тебе пришлось бы решать, на каком этапе нужно внедрять доступность, то что бы ты посоветовала в этом случае? Когда начинать работать с доступностью?

Таня: вообще начинать с самого-самого начала. То есть, когда ещё, например, продумывается будущая архитектура фичи, как она будет работать и для чего вообще там нужна. Соответственно, с этапа проектирования бы начинала, когда там только-только разрабатываются первые ошмётки, намётки макета. И дальше, конечно, уже это всё распространяла выше или пусть будет дальше по вот этой вот горизонтали процесса разработки, потому что, раскрою тайну, большинство проблем с доступностью закладывается на этапе дизайна. Какие-то вещи вы просто не можете решить дальше на этапе написания кода. Соответственно, в вас кидают тикетами тестировщики, которые это всё находят, вы такие, ну блин, дизайнер так нарисовал. Что я буду делать? Как вот эту вот фигню, вылетающую слева направо и делающую какое-то спиральное движение посередине я вам сделаю доступно?

Так что с самого-самого начала проектирования, но никогда, никогда её не закончишь, никогда. Все, все обречены на бесконечный вот этот вот цикл. Задизайним доступно, закодим доступно, потестируем, потом дальше пособираем пользовательский фидбэк [отзывы], погрустим, получим судебный иск. И снова начнём. Да, и снова начнём. Но это, если, конечно, вы вообще не думаете о доступности, тогда судебный иск.

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

Технические вопросы

Таня: ну, а теперь переходим к блоку с техническими вопросами для Глаши. Специально для неё готовила.

Глаша: я готова.

Таня: мы искали инициативных, стрессоустойчивых. Вы нам подходите! Но, если серьёзно, то как пользователи и вспомогательные технологии, которыми они пользуются, получают доступ к страницам?

Глаша: здесь, на самом деле, задействовано много элементов схемы. Есть у нас наш прекрасный браузер. Это может быть не обязательно браузер, это может быть любое приложение в операционной системе, поскольку скринридер работает не только с браузером, он работает, то есть какая-либо ассистивная технология, для которой мы должны предоставить доступ, она работает в рамках операционной системы, поэтому она может взаимодействовать со всеми приложениями.

И вот, например, есть браузер, и есть наш веб-сайт. Если очень кратко об этом всём рассказывать, то схема такая: браузер при получении нашего кода… Вот мы накодили что-то как разработчик, и браузер при получении нашего кода строит из него несколько разных деревьев. Самое близкое нам — это DOM-дерево, объектная модель документа. И также браузер на основе этой объектной модели строит ещё дополнительное дерево, так называемое дерево доступности. Туда он включает какие-то элементы DOM-дерева или не включает. То есть не все элементы из DOM-дерева могут попасть в дерево доступности. Они, например, скрыты сейчас на странице как-либо визуально, либо более серьёзным способом скрыты. Но тогда они не попадают в дерево доступности. И вот с этим деревом уже могут работать ассистивные технологии.

Они не напрямую лезут в нашу приложенечку [приложение]. На самом деле, все приложения в операционной системе предоставляют ассистивным технологиям какое-либо дерево доступности, чтобы, например, скринридер смог получить доступ к элементам на нашем сайте и всю необходимую информацию по этим элементам. Для этого у нас в системе есть Accessibility API. Во всех операционных системах эта штука есть. Это как раз-таки механизм, который связывает пользователя ассистивной технологии с нашим деревом доступности. И дёргает дерево доступности всё время. И такой типа, эй, а что это за элемент? Какой у него тип? Что с ним можно делать? Всё это он спрашивает у дерева и передаёт скринридеру.

И скринридер уже пользователям озвучивает, что это кнопка. Неожиданно, уникальный пример! На эту кнопку можно нажать с помощью клавиш Enter, пробела, что у неё есть доступное имя. Да, в общем, и все необходимые ещё дополнительные атрибуты, которые могут быть на этой кнопке. Например, что она открывает меню или что она разворачивает какую-то область. В общем, да, есть у нас дерево доступности в нашем браузере и есть ассистивная технология, которая через API операционной системы это дерево доступности получает.

Таня: круто! Спасибо. Это, на самом деле, довольно сложный технический вопрос, который, кажется, показывает, насколько человек глубоко погружён в эту тему. Ну и следующий вопрос очевиден. Он связан с HTML. Можешь рассказать, как HTML вообще помогает делать более доступные интерфейсы? Зачем он вообще нам нужен?

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

В HTML очень давно существуют все необходимые элементы, которые уже для ассистивной технологии не новость. То есть ассистивная технология знает, что это за элемент. К таким элементам относятся всякие так называемые семантики HTML, то есть не <div> и <span>, о которых неизвестно вообще какого типа элементы, что из них можно бы сделать, а вот именно семантические значимые элементы, например, кнопки, ссылки, разные типы инпутов [полей], формы, заголовки.

Это то, что раньше было, но с приходом нового HTML, который пришёл уже бог знает сколько лет назад, а мы всё ещё на собеседованиях интересуемся, а что же нового принёс HTML5 в семантику HTML? Да, с приходом пятого HTML появилось гораздо больше вот таких вот явных семантических структур, которые разработчику удобно использовать в коде при кодинге, потому что у них появилось имя, например, какие-то секции стали <section>, хедеры-футеры стали <header> и <footer>, а не <div class="header">, <div class="footer"> и так далее. То есть, в HTML появилось много новых семантических структур, и они же прекрасно зачитываются, например, скринридерами или прекрасно предоставляются другим ассистивным технологиям для более быстрой навигации по странице.

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

Таня: да, не поспоришь. Причём всем, потому что те, кто пишет на JavaScript, Angular, вообще-то, так-то тоже в основном манипулируют DOM. Так, ну и следующий вопрос про WAI-ARIA. Что это такое? Зачем оно вообще нужно?

Глаша: у нас есть нативный HTML. Все теги, которые мы используем, уже скринридер хорошо понимает и знает, что с ними делать. Другие ассистивные технологии тоже этим пользуются. Скринридер привожу везде в пример как самую такую частую, самую масштабную технологию, которая нас прямо везде задевает.

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

То есть можно было написать <div role="main"> и таким образом сообщить скринридеру, что это основной контент страницы, пока не было тега <main>. Сейчас есть тег <main>, в него уже заложено это поведение по дефолту [по умолчанию] браузером. И теперь <main role="main"> писать не нужно, если только вы поддерживаете какой-нибудь старый IE, в котором ещё не работает пятый HTML. В общем, WAI-ARIA — спецификация, которая позволяет нам расширить наш HTML. ARIA, собственно, расшифровывается как Accessible Rich Internet Applications. То есть мы добавляем богатства в наши прекрасные интернет-приложения, таким образом давая ассистивным технологиям дополнительную информацию о наших элементах.

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

Таня: дальше у нас вопрос, вытекающий немножечко из этой спецификации. Что такое accessible name, и как его задать, как узнать, какое сейчас имя у элемента? Кстати, тут можно рассказать о том, как оно вычисляется коротко. То есть типа, что приоритетнее чего.

Глаша: да-да, accessible name, действительно. Все элементы, которые вы хотите, чтобы пользователь вообще понял, что это такое, особенно уникальные элементы на странице, точнее те, которые должны быть уникальными, они все должны иметь так называемое accessible name. То есть это имя, по которому вы этот элемент опознаете, позовёте, скринридер скажет вам, что это за элемент, назовёт его имя. Accessible name, в основном, задают для интерактивных элементов, это обязательно, чтобы у любого интерактивного элемента на странице был уникальный accessible name. Десять кнопок «купить сейчас» — не очень хорошая практика.

Ещё задают accessible name каким-то семантическим структурам типа областей, если этих областей у вас несколько однотипных. Например, несколько <section>, несколько тегов навигации, разного типа навигации. Может быть, списки какие-то, которые вы хотите обозвать именами, чтобы пользователь мог перемещаться по спискам. То есть accessible name нужен элементам, по которым можно перемещаться, скринридер будет называть тип этого элемента, его имя, чтобы прям понять, где мы сейчас находимся. Задать его можно разными-разными способами.

И если присмотреться к порядку, в котором accessible name может быть получен из всех этих способов, составляется такой порядок приоритета: самым низким по приоритету будет title элемента, то есть всем элементам на странице можно задать такой атрибут title и написать туда что-то. Вот информация из title может стать доступным именем для вашего элемента, но это не очень хорошая практика с тайтлами. Отдельно можно долго про это рассказывать.

Следующим по приоритету будет взят контент элемента. То есть у вас есть элементы, которые представляют собой открывающий и закрывающий тег, например, <button> или <a>, и внутри у вас текст. Вот этот текст считается контентом элемента, из которого элемент получает доступное имя. Также в этом же пункте, если у вас есть placeholder, то из placeholder может быть получено это доступное имя. То есть у <input>, например, нет возможности задать контент, но у <input> есть placeholder, и вот из placeholder вместо контента может быть получено accessible name.

Следующим по приоритету будет нативный лейбл [подпись] элемента. Если у вас интерактивный элемент, <input> какой-то, то у него есть возможность задать имя с помощью тега <label>, который связан с этим <input>, и вот это будет тоже такой средний по приоритету пункт.

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

И самый первый по приоритету будет атрибут aria-labelledby. Когда у нас на страничке есть видимый текст, и есть элемент, к которому мы хотим этот текст привязать, мы можем использовать, если других способов нет, атрибут aria-labelledby, чтобы связать видимый элемент с элементом на странице.

Да, то есть в таком порядке. Сначала будет aria-labelledby, потом aria-label, потом нативный <label>, потом контент или placeholder, и потом уже атрибут title.

Таня: и следующий вопрос про role. Что это такое, и когда этот атрибут пригодится?

Глаша: да, это тоже один из основных атрибутов. Вообще, когда говорят про дерево доступности, говорят, что нужно обязательно элементу задать accessible name, обязательно знать его роль, либо задать её, и обязательно там все обязательные атрибуты, ARIA-атрибуты, которые соответствуют этой роли. Роль — это, по сути, тип элемента. Это то, что скринридер скажет. Ссылка, кнопка, навигация, секция, регион точнее, основной контент. То есть, это то, что скринридер озвучивает как тип элемента. В соответствии с этим пользователь знает, как с этим элементом взаимодействовать.

За ролью скрывается много информации, уже вшитой в элемент. Например, у нас есть элемент <button>, опять же. У него есть роль button, то есть это его тип. И, исходя из этого типа, мы знаем, что на <button> можно нажать, что Enter и пробел на нём работают, что он выполняет какую-то функцию, и у него могут быть ещё дополнительные атрибуты. Например, состояние, типа aria-pressed, то есть он нажат сейчас в данном конкретном случае или не нажат. Атрибут disabled, например, может быть на <button>, то есть он доступен сейчас для нажатия или недоступен.

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

Таня: итак, ты уже упоминала регионы. Что такое ориентиры и как они помогают вспомогательным технологиям?

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

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

И вот у пользователей, в частности, скринридеров, как и ассистивных технологий, есть такая возможность быстро перемещаться по этим областям с помощью одной единственной клавиши. Но чтобы у них была такая возможность, их нужно правильно закодить. Поэтому в HTML у нас есть такое понятие, как ориентиры или лэндмарки. Их там не очень много. К лэндмаркам относятся <header>, <footer>, <main>, <form> и <section> в случае, когда им задан accessible name, про которое я уже рассказывала. Есть у нас новый лэндмарк <search>, который со 118-го Chrome будет работать. Пока что никто, скринридер пока не понимает, что это такое. И есть ещё лэндмарк <aside>.

Но вот в ARIA они представлены под другими именами все совершенно. Только main и search совпадают. Ну и form, наверное, да. <section> — это region, <header> — это banner, <footer> — это contentinfo. <aside> есть ещё тег. <aside> — это будет complementary лэндмарк. Раздав вашему коду название, вот эти, точнее, теги, закодив вместо <div>-ов с помощью лэндмарков, вы даёте пользователю возможность быстро по ним перемещаться.

Но главное не забывать, что в секцию по дефолту [по умолчанию] не получится быстро перемещаться. Надо заголовок им обязательно задать. И недостаточно просто <h2> внутрь секции вставить. Нужно его программно связать с тегом <section>, то есть aria-labelledby написать, и туда id-шник заголовка секции. Либо aria-label и туда просто текст.

Вот, то есть быстрая, удобная навигация по контенту, как будто вы глазами быстро нашли нужную вам секцию на странице.

Таня: так, следующий [вопрос]. Легендарный, самый важный, золотой фонд вопросов по доступности.

Глаша: сразу, наверное, после того, как объяснить всем, зачем доступность, следующий вопрос. Мне кажется, у нас в каждом разделе вопросов есть такой золотой вопрос.

Таня: да! Так вот, когда использовать ссылку, когда кнопку?

Глаша: к сожалению, в дизайн-системах очень часто есть элементы, которые называются button-link, или link-button, которые выглядят как кнопка, но являются на самом деле ссылкой. И фронтендер нацелен писать код так, как он видит его. То есть если он видит кнопку, он напишет, что это <button>. Если он видит текст подчёркнутый, он сделает это ссылкой. Но тут немножко другая схема.

Нужно использовать ту семантику, которая отвечает функции элемента. Если ваш элемент участвует в навигации по сайту либо по странице, это будет ссылка. То есть ссылка — это навигация. Причём неважно, вы нажали на ссылку, и вас просто переместило, перекинуло красивым скроллом там каким-нибудь медленным, вас перекинуло вниз страницы. Это всё равно вы навигируетесь по странице. То есть взять как пример аутлайн документа, то есть его содержание, это набор ссылок, которые перекидывают вас в конкретные области якорных ссылок. Это всё ещё тег <a>.

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

Таня: так, теперь, пожалуй, посложнее. Что такое live regions и когда мы должны использовать эту штуку?

Глаша: о, live regions! Я знаю одного человека в нашем русскоязычном пространстве, который долго и много пишет статьи на эту тему. Её зовут Татьяна Фокина. Это великолепный специалист по «живым» регионам. Она недавно в Доке как раз статью про это выложила с песочницей, где можно пощёлкать, пощупать, послушать, как это всё используется.

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

Вот был такой кейс [случай] на одном сайте строительного магазина, где слайдер крутился автоматически и сменялись слайды. И там был навешан атрибут. Это делается целым набором атрибутов, и один из важных, самых главных атрибутов — это атрибут aria-live, который мы задаём, как бы сообщаем ассистивным технологиям, как озвучивать эти изменения. И вот есть несколько вариантов. Это может быть aria-live="assertive", то есть изменения сразу озвучиваются, как только они появились на странице. Это алерты [предупреждения]. Это кричит, мигает красным, сейчас же немедленно прерывает всё чтение скринридера и озвучивается.

А вот на том сайте был aria-live="polite". То есть это нежное уведомление, но всё равно, как только оно появилось, оно подождёт, пока закончится зачитываться предыдущая информация, и зачитается. То есть то, что не зачитается, это, конечно, возможно. К сожалению, в нашей практике это часто происходит, когда скринридер просто не успевает его зачитать и начинает зачитывать что-то новое. То есть можно перебить случайное зачитывание aria-live="polite", но в целом не нужно, кстати, в таком случае делать алерты [срочные оповещения].

Да, в общем, на том сайте был установлен слайдер aria-live="polite", и при каждой смене слайда он зачитывался. И поэтому ты всё время, находясь на странице, всё время слышал слайд шесть, слайд семь, слайд восемь. И ты не мог на это никак вообще повлиять, только из кода выпилить aria-live, но это сильно продвинутые юзеры [пользователи] могут делать.

В общем, live regions — это механизм, который позволяет вам озвучивать какое-либо изменение на вашем сайте. Это может быть очень срочное изменение, это может быть какой-то текущий статус, например, закончилась загрузка документа. Это может быть оповещение о том, что появилась новая информация на странице.

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

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

Таня: всё так. Так, расскажи про способы скрытия контента от вспомогательных технологий буквально по верхам, какие есть и кратко что они делают?

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

Но, скорее всего, из-за того, что оно [окно] красиво выезжает или заезжает обратно, оно неправильно прячется. У нас есть такая проблема в вебе. Мы не можем эти хорошие способы скрытия использовать, чтобы анимацию ещё дополнительно отобразить. В общем, самый лучший способ стопроцентно спрятать какую-то информацию от ассистивных технологий — это задать блоку display: none. Либо есть в HTML атрибут hidden. Прямо на блок можно повесить. Это тот же самый display: none. Это стопроцентно скроет ваш элемент от всего. От ассистивных технологий, от поиска, от клавиатуры, вообще от всего.

И похожий на него есть атрибут, точнее, CSS-свойство visibility: hidden. Это свойство, которое работает так же, как display: none, но оно сохраняет место в разметке под ваш элемент. То есть оно остаётся в потоке как бы визуально. Но при этом никто его не найдёт, ни клавиатура, ни скринридер, ничего.

Если что-то на странице видимое, но мы хотим, чтобы скринридер не зачитывал… И здесь много красных восклициальных знаков «Подумай тысячу раз!» перед тем, как использовать это свойство. В спецификации WAI-ARIA есть свойство aria-hidden со значением true. В чём его прикол — оно полностью выпиливает элемент из дерева доступности. Скринридер не зачитает ни тип элемента, ни весь текст, который в элементе находится. Но если там будет, хоть случайно попадётся какой-нибудь фокусабельный элемент, интерактивный какой-нибудь, например, у вас есть таблица с формой.

Получилось, что вы решили форму стилизовать с помощью таблицы. Такое бывало. И вы таблице этой задали aria-hidden="true". Типа вы сделали форму невидимой и хотите, чтобы скринридер тоже её не нашёл. Вы поставили таблице aria-hidden="true". И все интерактивные элементы останутся доступны с клавиатуры, и поэтому скринридер на них тоже сможет попасть. То есть табом пройдясь по элементам, вы будете слышать «Пустой, пустой, пустой, пустой». Потому что текст-то скрыт aria-hidden, а вот фокусабельность нет. И что это «пустое», вы тоже не будете знать. Просто будете табом идти по куче пустых элементов. Поэтому aria-hidden — такое очень опасное свойство.

Есть ещё способы спрятать от пользователя что-то, но оставить доступным для скринридера. Есть такой у нас CSS-класс, называется .visually-hidden чаще всего. Он ещё иногда называется .sr-only. Разные вариации [названий], в общем. Набор свойств, CSS-свойств, которые схлопывают элемент вообще до полной невидимости. Плюс он там не мешает другим элементам, выбивает его из потока.

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

И есть ещё такие две роли, абсолютно одинаковые роли. Роль presentation и роль none. Они тоже связаны со скрытием информации от ассистивных технологий, но их задача — скрыть семантику, то есть полностью уничтожить семантику вашего элемента. Это очень часто используется в вёрстке HTML-писем, когда письма верстаются таблицами всё ещё. Там вообще мало что меняется в этой вёрстке [писем]. И, чтобы скринридер не говорил каждый раз, что он сейчас находится в таблице, это первая ячейка первой строки таблицы, и в ней такие-то данные, визуально-то никакой таблицы нет, вы можете использовать роль none либо роль presentation только на таблице, и эта роль вырубит семантику этой таблицы у всех её обязательных детей.

Если у вас внутри таблицы есть какие-то семантические элементы, не связанные с таблицей, там, картинки, кнопки, ссылки и так далее, у них всё прекрасно будет, то есть они с таблицей не связаны, их семантика останется. Но у таблицы, у её строк, у её там , у всего вот этого вот, и <td>, и <th>, у них у всех семантика будет уничтожена, и скринридер её не зачитает, и не будет никакого специфического поведения для таблички прилагать.

Таня: кстати, фан факт [забавный факт], с aria-describedby вы можете забыть о том, как работает hidden или display: none, или .visually-hidden. В какой-то момент вы можете обнаружить себя в ситуации, когда вы его [элемент] скрыли вроде бы железобетонно от скринридеров, а они всё равно зачитывают контент.

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

Вопросы про доступный дизайн

Глаша: что ж, с разработкой чуть-чуть разобрались. Давай теперь поговорим про самые частые вопросы, которые могут быть тебе заданы, чтобы обеспечить доступность дизайна.

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

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

Что касается навигации, то же самое. Если у вас кнопка выглядит одинаково на каждой странице, но при этом у неё разная функциональность, соответственно, вы можете, конечно, использовать какой-то компонент, но будет ли это доступным для пользователей с точки зрения какого-то восприятия интерфейса? Нет, не особо. И знаменитые ссылки и кнопки, то есть часто то, что выглядит как… Дизайнеры какие-то не понимают, что такое ссылка, что такое кнопка, смешивают это на уровне визуальном, что вредит юзабилити довольно серьёзно и делает ваш интерфейс непредсказуемым. Вы, конечно, как разработчик, кстати, можете справиться, но пользователям, в общем, как всегда, достанется от вашего дизайна.

Глаша: больно. А ты упоминала контрастность. Коротко, что вообще это такое и для каких элементов нужно её учитывать?

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

Есть разные алгоритмы расчёта контраста. Их, по сути, два. Одна формула, которую предлагают в WCAG 2, и другая новая формула, как раз APCA, которую предлагают в WCAG 3. И, соответственно, если не вдаваясь в детали, то на контрастность влияет начертание и размер шрифта в старом алгоритме расчёта. А вот в APCA уже будет учитываться большее количество переменных. То есть там будет шрифт влиять, насколько я помню. Тип шрифта, начертание, само собой, цвет, размеры. И, по-моему, я ещё что-то забыла. Ну, в общем, там будет гораздо больше всего. Но вопрос был не про это.

Глаша: на вопрос ты в целом ответила. А вот тоже связанный с цветами вопрос. Бывает, когда мы передаём какую-то информацию пользователю только цветом. Например, красный какой-нибудь кружок или красные, зелёные кнопки, поднять трубку, положить трубку, всякие такие вот кейсы. Или когда мы, например, пишем под полем сообщение красное, что там заполните как-нибудь по-другому это поле. Вот в чём проблема передачи информации только цветом?

Таня: проблема заключается в том, что не все люди различают цвета. И не все люди различают их из-за того, что у них, например, цветовая слепота или дальтонизм. На это может влиять уровень освещения в помещении, на солнышке. В общем, сами представляете, как сильно изменяются цвета. Плюс на это влияют мониторы, экраны и так далее. И поэтому, если мы полагаемся на цвета, то большая часть людей отрезается от… Отрезается. К примеру, если вы используете цвета без подписей на маркетплейсах, обозначающие одежду, то человек с цветовой слепотой вряд ли сможет отличить синий от зелёного.

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

Глаша: с графиками классный пример. Это, наверное, одна из основных областей, где очень сложно переделать всё так, чтобы не только цветом обозначать. Мы, кстати, в самом первом, по-моему, выпуске подкаста про графики разговаривали. Там у нас были идеи о том, как улучшить их визуальную доступность. Поэтому можно переслушать. Отлично.

Я сама с этим стала часто сталкиваться почему-то, когда на сайте всё мигает, сияет и куда-то текут и бегают элементы, для меня это становится реально таким отвлекающим фактором. То есть анимация на наших веб-ресурсах и как сделать её более доступной? О чём подумать на этапе дизайна?

Таня: на этапе дизайна в первую очередь надо подумать о том, где она [анимация] уместна, а где нет. Потому что на самом деле не всё нуждается в анимации, не каждый элемент. Потому что это создаёт когнитивную нагрузку на всех пользователей. И не только когнитивную, кстати. На перформанс тоже может влиять, если плохо закожено и если дизайнер хотел анимировать всё.

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

Глаша: тоже частый момент в дизайне. Я суперчасто прошу дизайнера дорисовать состояние всяких кнопочек, ссылочек и прочего. То есть обычно они как нарисованы, так и есть. Но у меня нет под рукой состояний этого элемента, в котором он может находиться. А каких основных состояний чего чаще всего в дизайне не бывает?

Таня: на самом-то деле посещённых ссылок не бывает. И фокуса на втором месте. То есть должно быть состояние фокуса с клавиатуры. Должно быть проработано состояние при наведении обязательно. Это, кстати, тоже не все делают. Вот тут, не знаю, при тапе на мобильном устройстве, ну, просто есть предложение, и я так понимаю… Короче, не всегда нужно сохранять то состояние при клике на мобилках, потому что там есть свои паттерны привычные пользователям при тапе на какой-то элемент. Так что это можно тоже учесть именно на мобилках при тапе. Подумать, например, а не просить своих разработчиков это перезаписывать так. И посещённая ссылка тоже полезна, особенно если у вас много ссылок на странице. И тогда пользователю не придётся париться, вспоминать, что он открывал, а что ещё нет.

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

Также вас, скорее всего, спросят про дизайн форм, что важно учесть при дизайне форм, какие там состояния ошибок и прочие штуки, как появляются ошибки, про рекомендации по заполнению элементов форм и так далее. Вас ещё могут спросить, какие шаги вы предпримите как эксперт по доступности, чтобы объяснить дизайнерам, как передавать их макеты в разработку. То есть что добавить с точки зрения доступности в макеты. Чего чаще не бывает в макетах, это каких-то лейблов [подписей] для элементов, например, для кнопок-иконок. Вот не написал дизайнер лейбл, а он обязателен с точки зрения доступности. Это кнопка, у неё должно быть accessible name. Состояние, кстати, при ховере [наведении] и вот тултипы, которые появляются у нас на ховере, они же должны на фокусе появляться. Вот этого тоже в дизайне часто нет.

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

Вопросы про доступный контент

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

Один из главных вопросов будет — это как сделать доступными картинки для всех пользователей. Это очень частый вопрос про атрибут alt. Так же вас спросят, чем отличается декоративная картинка от контентной, важной для понимания. Тут важно учесть, что если у картинки вообще не указать атрибут alt в коде, то картинка будет зачитана скринридерами, используя её полный путь [к файлу]. То есть, скорее всего, там посимвольно может быть зачитан путь картинки вместо её доступного имени. Но alt может быть пустым для декоративных картинок. Пустота — это не пробел. Пробел не является пустотой. Так как только у декоративный картинки alt пустой, скринридер перестаёт её воспринимать как изображение, не будет типа её зачитывать, ничего. Это удобный способ спрятать картинку.

Для каких типов контента ещё нужны текстовые альтернативы? Это у вас здесь спрашивается про видео, про медиа, всякий разный другой контент, про аудиоконтент. Вот мы делаем подкаст, и мы предоставляем вам текстовую альтернативу в виде расшифровки. Всё, что звучит, всё нуждается в текстовой альтернативе для тех, кто может не слышать ваш контент. Всё, что визуальное, возможно, тоже нуждается в текстовой альтернативе для тех, кто ваш контент не видит.

Также могут ещё вас спросить про такую вещь, как plain language, простой язык, и для кого это важно. Свой контент можно передать в формате простых инструкций каких-либо. То есть сложные фразы переделать в простые фразы. Так разделить информацию, чтобы она выглядела достаточно простой для понимания. Если что-то было в длинном тексте, вы можете попробовать представить это в формате таблички, где будет расписано, что в каком случае делать. Плюс визуальные будут направляющие.

Тоже частый вопрос про паттерны ссылок из разряда «Тут», «Читать тут», «Смотреть здесь», «Далее», «Купить», «Добавить в корзину». Всякие вот такие вот ссылки, которые по десять раз повторяются на странице, и их текст используется как accessible name. То есть у вас в ассистивной технологии будет список элементов с одинаковым именем, и вы никогда не узнаете, что этот элемент делает. Тут важно добавлять, расширять как-то это имя, чтобы оно давало больше контекста пользователю о том, что будет, если вы нажмёте на этот элемент.

И очень важный такой вопрос про заголовки в документе. Как их использовать? Имеются в виду теги <h>. У них есть строгая иерархия, на каждой странице обязательно должен быть <h1>. Если SEO-шник вам сказал, уберите здесь заголовок, вы можете все ещё ARIA-атрибутами вернуть его. То есть написать не <h2>, а <div role="heading" aria-level="2">. Таким образом, SEO-шник потеряет этот заголовок из своей программулечки [программы]. Google тоже, по-моему, не считает это заголовком. Но зато пользователь скринридера получит его как заголовок в своей заголовочной структуре и сможет по ним быстро перемещаться. Заголовки очень важны для навигации пользователей по документу, причём не обязательно пользователей скринридеров. Есть такое в браузере расширение HeadingsMap, которое вам строит структуру заголовков, и вы можете по ним скакать с клавиатуры просто, легко перемещаясь по разделам вашего сайта.

Ну и дальше вас ещё могут спросить про специфику доступности документов, которые вы прикрепляете к веб-страничке, всяких Word, PDF, Excel, PowerPoint и так далее. Это, в общем-то, все вопросы, которые мы хотим обсудить с вами.

И наверняка ещё будут вам заданы вопросы по конкретным кейсам [примерам]. То есть у компании будет какое-то чёткое представление, что они хотят, чтобы вы пофиксили [исправили]. и они будут вам говорить, Вот у нас есть модальные окна, мы там не знаем вообще, что с ними делать. И вы должны будете рассказать, что бы вы сделали, как бы вы применили какой подход к разработке доступности этих модальных окон. Кейсы ещё могут быть.

Вопросы к компании

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

А почему вам нужен в компании специалист по доступности? Что уже есть в компании? Какие процессы настроены? Какие главные боли текущего решения с точки зрения доступности? Где я пригожусь больше всего как специалист? Если я захочу вписать свои приоритеты в ваши приоритеты, как мы будем разбираться, чьи важнее? То есть ты говоришь, я специалист по доступности, здесь очень важные вещи нужно пофиксить, а у тебя в компании параллельно идёт разработка какой-нибудь важной фичи. Тут нужно соотносить приоритеты свои и их. Далее, какие ресурсы компания готова предоставить тебе в качестве эксперта? Потому что это оборудование, это программы для тестирования, инструменты автоматизированного тестирования, инструменты аудирования. И очень часто они стоят денег.

Также вопрос — какие есть перспективы? Это вы разовую доступность сейчас делаете, или вы хотите дальше над ней работать, активно её развивать? Как вы дальше вообще планируете развивать это направление и обучать сотрудников? Какие будут выделены ресурсы на это всё? Вот такие вопросы вы можете задать в компании, и поверьте мне, вам ответят, но вынужденно.

Почему не надо бояться собеседований

Глаша: что ж, Таня, спасибо за собеседование. С тобой свяжется наша эйчар-специалист, сообщит о результатах. Жди, надейся. Поскольку это мифический единорог, то я уверена, что тебя примут. Со мной было так однажды, когда я прошла свой первый в жизни собес по доступности, меня сразу приняли.

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

Да, и вы просто знайте, что даже если вам не дадут какого-то однозначного, вразумительного фидбэка [обратной связи], насколько вы крутой специалист, вы всё равно крутой специалист, вы в этом разбираетесь, знаете, что это такое. И не бойтесь ходить на такие собеседования, улучшать всю эту экосистему, скажем так. Таня, не бойся ходить на собеседования на эксперта по доступности.

Таня: всё, завтра же побегу куда-нибудь, кому-нибудь писать на LinkedIn.

Глаша: отлично!

Таня: но, да, полностью согласна с твоими выводами. И быстренько про события.

События

Таня: GitHub Universe. Конференция GitHub, пройдёт 8 и 9 ноября, в онлайн и оффлайн формате в Сан-Франциско. Если вы хотите сгонять в Сан-Франциско вдруг, есть для это повод, и она частично платная.

The Design + Accessibility Summit 2023, с 14 по 18 ноября проходит. И конференция онлайн и бесплатная.

Таня: с вами был подкаст «Инклюзивный ананас» и его ведущие Глаша и Таня. Вы можете найти нас на любой подкаст-платформе. До встречи в следующем выпуске!

Вопросы

Про опыт

Общие

Технические

По дизайну и контенту

К компании