Выпуск 1

The WebAIM Million 2023, нативный .visually-hidden, тег search, ChatGPT и доступная кнопка

Темы

События

Расшифровка

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

Глаша Жур: Таня, привет!

Таня: да, Глаша, привет.

Глаша: я вот до сих пор в вебе не встречала, ладно в вебе, но на подкастовых всяких платформах я раньше не встречала подкастов русскоязычных о доступности, а ты?

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

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

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

Значит, если коротко, то для этого отчёта они анализируют самые популярные сайты и главные страницы. Делают они это автоматической своей тулзой, WAVE API, и проверяют, проводят этот аудит на основе WCAG 2. Благодаря этому вот уже пятый год подряд можно как-то анализировать, что, собственно, происходит с доступностью, вот так вот, по верхам. И что в этом году интересного? Например, интересно то, что 96% от всех страниц не соответствуют WCAG, и на самом деле за четыре года это не то, чтобы стало суперплохо, но вот есть такой прирост в отрицательную сторону на 1,5%. То есть, веб не то, чтобы стал супернедоступным, но куда-то туда он стремится, похоже. Среднее количество ошибок на страницах — это где-то 50, и их количество уменьшилось за эти четыре года. Всё-таки что-то хорошее происходит.

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

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

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

Дальше там у них есть отдельная рубрика про ARIA. И мне кажется, что в целом, если вы анализировали эти отчёты, там ничего такого нового для себя не обнаружите. Но если вы слышите об этом отчёте впервые, то, что интересно, чем больше используете ARIA, тем больше у вас проблем с доступностью. В этом году в среднем около 77 атрибутов и ролей встречаются на одной странице. Их количество увеличилось на 29%. То есть, больше людей открыли ARIA, и я не знаю, хорошо это или плохо. Возможно, не всегда хорошо. Чаще всего встречаются aria-label наш любимый, aria-labelledby, aria-describedby. И, видимо, так люди пытаются исправить проблемы с отсутствием текста в ссылках, например. И также в топе aria-hidden со значением true и role="button". Незавидная судьба у button, я скажу. Да, и интересно, что в среднем на странице, где встречается ARIA, на 69%, то есть, почти на 70% больше проблем с доступностью, чем если бы не было этих атрибутов вообще никаких на странице.

Ещё вот что я для себя отметила. Две вещи. Во-первых, на довольно большом количестве страниц пропущены уровни заголовков, и это где-то 42%. То есть, довольно часто. Но там был сделан вывод, что всё-таки на сайтах чаще стали использовать заголовки, и даже почти везде встречается <h1>, что не может не радовать. Что интересно, и здесь у меня есть теория, что это за сайт, кто виновник торжества. Самое большое количество ошибок, которое встречалось на одной странице, на отдельно взятой главной странице, это 106 245. То есть, представьте себе, кто, как вообще, в принципе, даже это API смогло добраться до этой страницы. Но у меня есть теория, что это тот самый легендарный, самый недоступный сайт. Есть такая вероятность. Я не помню точно, кто именно делал эту страницу, но она такая чисто для образовательных целей, на которой собраны все возможные ошибки с доступностью.

Глаша: на самом деле, по итогам этого отчёта было написано, я думаю, ни одна, ни две, ни три результирующих статьи, где собираются выводы из этого отчёта и формируются в какие-то action points, я бы так сказала. И как раз мы прочитали с тобой две интересных. Одна из них называется «Мы нуждаемся в аксесебилити экшн», «We need accessibility action», и вот прямо сейчас нужно. Под авторством Эрика Эггерта. И там он, с одной стороны, рассматривает репорт и сокрушается как же так, почему до сих пор уже существуют стандарты много лет, ситуация с ошибками вот в этом миллионе сайтов, она уже около пяти лет, генерируется этот отчёт уже около пяти лет. И почему до сих пор у нас не происходит никаких улучшений, хотя бы видимых, значимых, именно хотя бы в распространённых самых ошибках? То есть, он прям переживает за это и предлагает такие решения.

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

Про ссылки и кнопки, которые не имеют текста он как раз говорит, что это должны быть ошибки в консоли браузерной. Почему мы ошибки JavaScript имеем в консоли, а вот эти ошибки HTML прям серьёзные, которые влияют на доступность, почему мы их не можем в консоль вводить? Хотя, казалось бы, то же самое. Но опять же он говорит, что какие-то ARIA-атрибуты должны быть внедрены в нативный HTML. И, кстати, мы сегодня ещё упомянем новый тег <search>, который и является результатом этого утверждения. То есть, у нас была роль search, а стал теперь тег <search>. То есть, нативный HTML умеет без ARIA сделать какие-то доступные элементы, компоненты со своим поведением и так далее, что тоже, в целом, справедливо. Не создавать там кастомный комбобокс, а прямо использовать нативные HTML-элементы.

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

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

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

У меня есть маленькая сайд стори. Я выступала на митапе по JS, и там я рассказывала про доступность в Angular. То есть, я им говорила, какие есть возможности в Angular прямо из коробки настроить доступность. После митапа ребята в Твиттере через пару дней написали пост, тегнули там меня. Они написали, что они так вдохновились моим рассказом, что пошли и прочекали свой сайт на доступность с помощью Lighthouse и исправили все ошибки, которые нашёл Lighthouse буквально за пару дней в формате, возможно, тоже какого-нибудь внутрикорпоративного хакатона это может быть сделано. Это был очень классный экспириенс. И ты такой, типа, господи, слава богу, я как эксперт по доступности несу какое-то вдохновение людям. Это было очень классно и приятно получить такой фидбэк от ребят. И заодно и действие было выполнено.

Глаша: следующая интересная тема, которую бы мы хотели обсудить, это небезызвестный класс .visually-hidden, очень популярный в доступности. Я первый раз в жизни с ним столкнулась, когда начала верстать на Bootstrap. Там был такой класс, раньше назывался .sr-only, то есть, только для скринридеров. Со временем он не очень, кстати, давно в свежем Bootstrap превратился всё-таки в класс, который называется .visually-hidden, что, по идее, звучит более логично, потому что это какой-то элемент, скрытый визуально. Дело в том, что он остаётся доступен не только для скринридеров, но ещё, возможно, для других каких-то ассистивных технологий, для поисковых систем, для поиска по странице и так далее.

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

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

Иногда тоже этим элементом, этим классом скрывают элементы формы, которые были как-то стилизованы, чтобы эти элементы всё ещё остались доступны для клавиатуры. Например, чекбоксы. Мы любим очень стилизовать чекбоксы. И обычно это происходит накруткой какого-нибудь псевдоэлемента сверху на чекбокс со стилями либо с какой-то бэкграундной картиночкой. И получается, что как только мы псевдоэлемент добавляем, мы сразу хотим скрыть настоящий элемент. И вот правильнее будет его скрыть с помощью этого .visually-hidden класса, потому что этот класс не удаляет элемент из DOM, не делает его недоступным. Этот элемент всё ещё будет доступен с клавиатуры, он всё ещё будет зачитан правильно скринридером, его состояние можно будет менять, но при этом он будет абсолютно невидимым и, то есть, это будет элемент, который, грубо говоря, opacity: 0 и размером один на один пиксель и так далее. То есть, там прям целая портянка таких свойств.

И до чего дошли мозги наших accessibility экспертов. Они дошли до того, что хотелось бы перенести этот набор свойств, чтобы каждый раз его не копировать из проекта в проект, хотелось бы перенести его в CSS в формате display двоеточие visually-hidden.

Мы тут, опять же, почитали статейку про это, называется «Веб нуждается в нативном visually hidden» от Бена Майерса. И он рассказывает, во-первых, почему веб нуждается, то есть в каких случаях используется всё это, .visually-hidden, и почему было бы удобнее использовать такое вот свойство в CSS display: visually hidden. И, опять же, поясняет, рассказывает некоторую историю о том, как дошли именно до display: visually hidden, не создали. То есть, это не должен быть HTML-атрибут какой-то новый, потому что, типа там hidden, например, или как значение свойства hidden, атрибута hidden. hidden равно visually hidden. Плохая идея, потому что во многих проектах в CSS есть прям инструкция всем элементам hidden сделать display: none как фоллбэк такой, на случай чего-то там не работает атрибут hidden. И получается, что важно, какое значение будет у атрибута hidden. У всех элементов с ним будет display: none, чего мы не хотим. Нам нужно, чтобы они стали visually hidden.

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

Кажется, хочется использовать какое-то существующее уже свойство и просто добавить ему одно из значений, чтобы оно не имело возможности перезаписываться. В целом, идея классная. Хотелось бы, чтобы было немножко полярное мнение и отношение к visibility: hidden. Таня, а как бы ты использовала visibility: hidden, пользовалась бы таким атрибутом вообще?

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

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

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

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

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

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

Я на самом деле никогда скип линки не делаю .visually-hidden. У меня всегда в CSS на фокусе происходит вылезание этой ссылки откуда-то сверху из-за пределов экрана. То есть, я меняю position, top там задаю положительный вместо отрицательного. .visually-hidden для скип линков никогда не использовала.

Таня: да, я тоже, но кто-то так делает.

Следующая тема, о которой хотела рассказать я, и о которой мы уже упоминали, это пополнение в семействе тегов HTML — <search>, тег <search> появился, что не может не радовать. Мы всё ближе и ближе к моменту, когда нам совсем не нужна будет ARIA.

Что это за тег? На самом деле эта роль search существует в ARIA с первой версии, и это роль ориентира. Это такая область на странице, к которой может быстро переместиться пользователь ассистивной технологии, например, скринридера, как, например, к <header>, <footer>, основной части страницы. Это такой же самый тег, такая же самая роль. Она появилась в спеке, но пока у неё плохая поддержка, поэтому пока мы до конца не отказываемся от роли search.

Если решаем использовать эту область. Исходя из названия, в принципе, всё совпадает с её названием. Это область для всего, что связано с поиском по странице. Это, на самом деле, может не обязательно быть поиск по странице, какой-нибудь глобальный, как в Google тоже. И внутрь этого контейнера <search> вкладывается, соответственно, поле поиска, у которого может быть либо type="search", либо type="text" иногда, и сама кнопка поиска, если она есть, если это не автоматический, динамический поиск, и какие-то фильтры, разнообразные чекбоксы и настройки поиска. В общем, всё, что связано с поиском, мы вкладываем внутрь. И, кстати, также внутрь этого тега мы можем вкладывать другую область ориентира, другой ориентир <form>, если этого требует ситуация. Так что ориентир внутри ориентира — это где-то может быть нормой. Самое главное, что в этот тег не надо вкладывать результаты поиска. Их можно вложить внутрь уже другого ориентира, <main>, например, но никак не в <search>. Это не то, что хочет этот тег от вас.

И, как я уже упомянула пока что, если вы всё-таки, как я, решите потестировать в Chrome и напишите радостно <search> и даже вложите в него правильный тег, вы не увидите ничего. Для дерева доступности это что-то неизвестное, какое-то неизвестное существо. Так что ждём, когда все браузеры это имплементируют и делаем ещё скидку на то, что если эта штука появится в итоге в Chrome, например, или в Firefox, не факт, что у этого атрибута будет роль <search>. Так было с футером. Так было много с кем. Так есть сейчас с рядом других тегов типа <em> и так далее. Так что нужно будет смотреть, насколько хорошо это имплементировано, не забыли ли они вписать роль в <search>, добавить поддержку нативной роли в <search>. А пока что мы добавляем роль в <search>.

Кстати, интересный факт, что этот тег довольно быстро появился в спеке. Первый пропозал появился в 2022. И вот сейчас в марте 2023 собственно он есть в спеке. Так что довольно быстро по меркам спецификации это произошло. Так что так.

И знаешь что, давай пофантазируем, какие было бы ещё клёво увидеть новые теги, чтобы нам не нужна была ARIA?

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

А ещё у нас в табах самая большая проблема — это то, что сам таб является сейчас тегом <button>, но и крестик закрытия внутри таба или удаление этого таба тоже является <button>. А <button> в <button>, как известно, не самая хорошая практика. С точки зрения доступности приходится <button> с крестиком прям скрывать, прятать. И пользователь, даже сейчас, то, что WAI-ARIA предлагает в качестве хорошей практики создания табов на ролях, на ARIA-атрибутах, сейчас очень много вопросов. А как пользователь узнает, что таб может быть закрыт? Потому что визуально крестик есть, но мы его скрываем от скринридера, чтобы он не был доступен. И приходится табу добавлять или вообще всему этому виджету добавлять какое-то описание, мол, чтобы закрыть вкладку нажмите Delete, чтобы перейти к другой вкладке, там, стрелочка влево-вправо, Home, End и так далее. То есть, это компонент, в котором взаимодействие с ним совершенно не очевидно. Скринридер ничего такого тебе не рассказывает как с ним работать. А если появляются какие-нибудь кнопки типа «duplicate tab», то есть, задублировать какую-то вкладку и так далее. Или, например, изменить название вкладки, сразу тоже возникает очень много вопросов.

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

У тебя есть какие-нибудь пожелания на эту тему?

Таня: да. Ну, первое, конечно, да, табы. Это просто, согласна на все 100%. Но я бы еще не отказалась от нативного тултипа. Это, конечно, тоже спорный вопрос. Как бы к самому по себе этому дизайн-паттерну большие вопросы, но, в целом, было бы прикольно, он всё-таки часто встречается. И было бы классно, чтобы появился какой-то нативный, доступный как <dialog> тултип тоже.

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

И я ещё смотрела в черновик ARIA 1.3, и у них там появились новые роли в нём. Это comment и suggestion. И, кстати, было бы тоже прикольно в какой-то момент найти в HTML-спеке нативный комментарий, тег для комментария, и нативную штуку для suggestion — предложения по изменениям, как, например, на GitHub. То есть, в таких сложных интерфейсах, где есть возможность редактировать, комментировать и работать вместе над документом, это бы сделало такие редакторы доступными, конечно. И не надо было городить огороды.

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

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

Сейчас, кстати, прикольную штуку нашли в меню. Когда смотришь на практики WAI-ARIA, там есть менюшки с разделителями внутри. То есть, айтемы делятся на группы, и такая полосочка. У нас в WAI-ARIA есть роль separator. Причём этот сепаратор может быть и интерактивным, и неинтерактивным. И это как альтернатива тегу <hr> в HTML, но ещё и интерактивным может быть. То есть, в HTML, насколько я знаю, интерактивных сепараторов нету нативных. И прикольно, что валидатор сейчас ругается на этот сепаратор, когда его перечисляешь среди меню айтемов, где-то попадается дивчик-сепаратор. С одной стороны, он есть в примерах в best practice WAI-ARIA, а, с другой стороны, axe-core какой-нибудь ругается на этот сепаратор и говорит, что нет, недоступно, плохо, уберите, удалите. Так что, да, прикольно. Даже стандарты сами с собой иногда не дружат, и валидаторы. Хотелось бы, чтобы всё вообще пофиксили.

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

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

Что он сделал? Довольно забавную вещь. Он просто попросил сгенерировать доступный баттон. Причём он немножко обтекаемо задал вопрос, что мне следует сделать, чтобы получилась доступная кнопка на веб-странице. Что ему предложил ChatGPT? Несколько шагов. Он предложил, я бы даже сказала, семь, семь шагов. Казалось бы, мы станем такие, ну в смысле доступный <button>, там один шаг. Один. Но, нет, семь.

Значит, первый шаг: используйте тег <button>. Супер. Ну, вообще, шикарное предложение, очень логичное. На этом, может, можно было бы и закончить, но ChatGPT не остановился. Он говорит, для этого тега <button>, пожалуйста, используйте хорошо описывающие его функцию ARIA-атрибуты aria-label либо aria-labelledby. То есть, речь о том, что у <button> есть нативная возможность как бы иметь лейбл. Это, собственно, текст между открывающим и закрывающим тегом <button>. Это тут не упоминается, скажем так. Немножко проигнорировано. То есть, я как разработчик, который не знает ничего про доступность, пойду по этим шагам и в итоге у меня получится <button> уже с атрибутом aria-label либо aria-labelledby. Мне придётся ещё спросить ChatGPT, что эти атрибуты обозначают. И придётся как-то выбрать один из двух. Я, скорее всего, остановлюсь на aria-label, потому что там сразу нужно вписать текст. Это для меня понятнее, чем добавить какой-то дополнительный элемент в код, которому задать id, связать aria-labelledby с <button> и так далее. В общем, да.

Дальше ChatGPT советует? Убедитесь, что у вас этот <button> доступен с клавиатуры, ему задан tabindex и в JavaScript для него прописаны все необходимые ивенты. В частности, чтобы с клавиатуры работали Enter и пробел. В чём проблема этого пункта? Проблема этого пункта в том, что <button> по дефолту доступен с клавиатуры. Ему не нужно писать никаких дополнительных атрибутов, ни tabindex, ни обработки JavaScript, ничего. Он работает и так. Достаточно обработать вам клик в JavaScript, если вы хотите какое-то у <button> поведение определённое задать, и всё. То есть, пока что, что называется, 2:1 в пользу людей.

Дальше. Предлагается использовать CSS, чтобы подсветить состояние кнопки. В целом нормально. То есть, мы действительно очень часто забываем о подсветке <button> во время фокуса, ховера. Эта подсветка часто бывает недоступной. Мы отключаем очень часто такое свойство как outline для фокусабельных элементов. То есть, у нас пропадает нативная рамочка фокуса вокруг элемента, что автоматически делает его сложно находимым среди всех. Ты табаешься по элементам, у них нет рамки, и ты не понимаешь, где фокус сейчас находится. Хорошая рекомендация. Не очень понятно, как это делать и так далее, но это не задача чата нам всё это описывать на данном этапе.

Дальше предлагается протестировать <button> с ассистивными технологиями, естественно, там, со скринридерами, с разными другими технологиями, что тоже хорошая рекомендация на данном этапе. Это, на самом деле, получается единственный способ, который, если бы разработчики делали этот тест, они бы тогда узнавали, что их <button> чего-то не хватает, что он не работает с клавиатуры, либо не работает с включённым скринридером, в то время как прекрасно работает просто с клавиатурой без скринридера. Так что это очень важный шаг, который действительно нужно совершать. Мне очень нравится следующий пункт: если у вас кнопка использует только иконку в качестве контента, то есть у вас кнопка-иконка без видимого текста, то, пожалуйста, тут написано «добавьте описывающую эту кнопку текст, используя атрибуты aria-hidden и aria-labelledby». Всё. То есть, никаких дополнительных рекомендаций по этому поводу нет. Получается, я на <button> пишу атрибут aria-hidden, потом я на <button> пишу атрибут aria-labelledby. Я знаю, что aria-labelledby надо ID'шник туда какой-то вставить. Я вставляю туда какой-нибудь ID спанчика с описательным текстом. В итоге у меня становится вообще недоступная кнопка. Она будет доступна с клавиатуры, ты на неё попадёшь, но aria-hidden удаляет её контент полностью. Ну, то есть, такое.

Я погуглю, что такое aria-hidden, конечно, в какой-то момент, но опять же, там будет написано что-то… да, Скотт, собственно, задал ChatGPT вопрос, что такое aria-hidden, и мне особенно понравилась оттуда фраза, что aria-hidden атрибут используется для того, чтобы улучшить доступность для пользователей слабовидящих. Хотя, на самом деле, он полностью выпиливает элемент из дерева доступности. Этот элемент остаётся только видимым визуально. В общем, довольно интересный ответ. Я бы ничего криминального не увидела в этом атрибуте и добавила бы его на кнопку без проблем. Кажется, что если ты не идёшь глубже, то у тебя получится что-то максимально недоступное.

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

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

Таня, у тебя какие-нибудь в последнее время переживания по поводу ChatGPT в сфере доступности?

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

Таня: и напоследок расскажем о некоторых событиях по доступности.

В ближайшие месяцы, даже месяц, я бы сказала, пройдёт конференция Including Disability Global Summit. Она пройдёт 25–27 апреля. Это полностью онлайн событие, на которое можно зарегистрироваться бесплатно. Она не посвящена чисто доступности, но на ней есть доклады непосредственно про веб-интерфейсы. Но там реально много интересных докладов и по законодательству, защищающему права людей с инвалидностью, и разные темы про инклюзивное образование, и про эйблизм, про активизм. И даже, кстати, закрался один докладик про то, насколько я поняла, как доступно проводить всякие D&D, Dungeons and Dragons, сессии, например, для людей со слепотой. В общем, интересно. Если хотите, можете зарегистрироваться уже прямо сейчас.

И следующая конференция пройдёт в мае, Virtua11y, 16–18 мая. Она тоже онлайн и бесплатная. К сожалению, у них так себе, так себе описано вообще, что будет, но она совершенно точно посвящена веб-доступности и цифровой инклюзии. Так что посмотрите, зарегистрируйтесь, если вам это показалось интересным. Обе конференции приурочены к Global Accessibility Awareness Day, который планируется 18 мая. И я думаю, что к этому дню появится ещё больше событий, разных митапов и конференций, о которых мы обязательно расскажем вам в следующем выпуске.

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