Выпуск 2

Графики, размеры элементов, голосовое управление, details/summary, доступность в Ubisoft

Темы

События

Расшифровка

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

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

Глаша Жур: в сегодняшнем выпуске поговорим про важные новости и обсудим интересные статьи про доступную визуализацию данных, про размеры интерактивных элементов, про странности нативных <details>, <summary>, про дизайн и код для голосового управления, а ещё расскажем про увлекательное интервью с директором по доступности Ubisoft.

Никита Дубко: а теперь к новостям.

Глаша: недавно компания The Software House выпустила отчёт о состоянии фронтенда на 22-й год.

Нас, конечно же, заинтересовало, что там с доступностью. Оказывается, что только 17% респондентов всегда включают
доступность в процесс разработки, никогда о ней не думают 9%, редко используют её 20%, иногда используют 26% и очень часто 27%. Цифры, в целом, хорошие.

И радует, что на вопрос о том, будет ли тренд на доступность расти или она умрёт, 63% уверены, что доступность станет только популярнее, в то время как смерть ей предрекает лишь 0,4%.

Таня: WCAG 2.2 опять перенесли, на этот раз на третий квартал 2023. Так что, возможно, мы увидим финальную версию уже этим летом.

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

И ещё одна новость. Deque выпустили axe DevTools Linter. Это облачный линтер, который может проверять ваш React, React Native, Vue, Angular, HTML и маркдаун на разных стадиях проекта. Линтер можно добавить в прикоммит, в GitHub Actions, в Jenkins и SonarQube.

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

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

А в APG, руководстве по авторским ARIA-практикам, появились таблицы с поддержкой паттернов-скринридерами NVDA, JAWS, VoiceOver в Chrome, Firefox и Safari. То есть можно посмотреть, какие атрибуты поддерживаются в каком браузере с каким скринридером. Пока есть не для всех компонентов, но можно посмотреть, например, для кнопки или ссылки. В планах добавить больше браузеров, скринридеров и других вспомогательных технологий, протестировать больше паттернов, потом и автоматизировать создание этих таблиц.

Только учтите, что это не Can I Use для ARIA. Это просто напоминание о том, что какие-то атрибуты хорошо поддерживаются скринридерами в определённых браузерах, какие-то не очень хорошо. Мы тут не выбираем, использовать их или нет.

На этом всё с быстрыми новостями, переходим к интересным статьям из мира доступности дизайна и проектирования.

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

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

И Дерек рассказывает о том, что на самом деле это действительно один из самых сложных элементов в доступности. Его не только нужно сделать визуально доступным, но еще и с клавиатуры, с помощью всяких других ассистивных [вспомогательных] технологий, но в этой статье он только затрагивает моменты дизайна, которые касаются именно дизайна.

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

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

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

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

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

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

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

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

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

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

Таня, я знаю, ты что-то там интересное узнала про размер элементов.

Таня: и следующая интересная статья, она тоже про дизайн. Это статья Виталия Фридмана о доступном размере элементов.
И он рассказывает в ней про то, какими, собственно, эти размеры должны быть, и почему это так.

Представьте себе ситуацию, вы хотите что-то заказать в приложении, и, значит, вы заполнили корзину нужными вам товарами, тапаете на кнопку «Оплатить», и ничего не происходит. И вы тапаете снова, и снова, и снова, и ничего не происходит. И вот это действие, когда вы тапаете очень много раз на какой-то элемент, или кликаете, такое тоже может быть, у него есть название. И это называется «rage tap». И «rage click», соответственно, в веб-интерфейсах. Что можно перевести как «злой тап» и «злой клик», наверное. Мой авторский перевод, ни на что не претендую.

Глаша: яростный.

Таня: яростный. Точно.

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

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

А ещё интересно то, что также очень важно не только сделать элемент достаточно большим для того, чтобы на него можно было легко кликнуть или тапнуть, но и ещё важно то, на каком расстоянии он находится от края экрана. И тут тоже есть совет по тому, на каком расстоянии эти элементы надо располагать. Если это верхняя часть экрана, то это где-то 11 миллиметров должно быть или 42 пикселя. Если это нижняя часть экрана, то это где-то 12 миллиметров или 46 пикселей. А если ваш элемент находится посередине, то расстояние от него до краёв может быть уже поменьше, где-то 7 миллиметров или 27 пикселей.

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

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

Ну и Виталий пишет, что он сам лично предпочитает делать элементы минимальным размером 30 на 30 пикселей и максимально где-то 48 на 48 пикселей. То есть чуть больше, чем нам рекомендуют это делать обычно.

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

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

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

И во WCAG 2.2, который мы уже упоминали, и надеемся увидеть его летом, там есть два критерия, связанных с размерами целей. Это самый высший критерий AAA, который как раз говорит о том, что хорошо делать кнопки 44 на 44 пикселя. И минимальный критерий говорит о том, что хорошо делать размер целей 24 на 24 пикселя.

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

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

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

Сейчас в комьюнити прям волнуются по поводу такого элемента, как <details>/<summary>. Напомню всем разработчикам, что это такое. У нас есть тег <details>, в который внутрь вкладывается тег <summary>. В теге <summary> мы пишем какую-то короткую, ёмкую фразочку типа «показать больше», то есть это элемент, который может сам самостоятельно разворачиваться, сворачиваться, по сути просто показывает больше дополнительной информации по какому-то поинту.

И чем он так привлекателен для разработчиков? Да в общем-то тем, что ничего делать не надо. Ты просто заверстал <details>/<summary> и пишешь себе спокойно. Не нужно работать с клавиатурой, оно прекрасно зачитывается скринридерами. Спойлер: нет, не прекрасно. Не нужно писать JavaScript, не нужно задумываться о доступности. Кажется, что всё есть из коробки прямо в HTML.

Да, действительно, очень много чего уже есть из коробки в HTML, но, с точки зрения доступности, всё-таки мы тоже у себя в команде много про <details>/<summary> ресёрчили и разговаривали, потому что наши студенты всегда намерены сделать этот элемент малой кровью, мы дошли своим тестингом до того, что в наших кейсах лучше всё-таки использовать более привычные для пользователя решения. Я потом поподробнее про них расскажу.

Но в целом по поводу <details>/<summary>, Мануэль приводит в пример статью Скотта О'Хары, который очень подробно разобрал этот элемент и протестил его со всех возможных сторон, со скринридерами, браузерами и прочим. Мануэль просто по свежим, скажем так, следам пришёл заново протестить этот элемент в сегодняшнем 23-м году. Это совсем недавняя свежая статья апрельская.

И до чего он дошёл в своём собственном тестировании. У <details>/<summary> есть некоторые проблемы.

Одна из них, самая, кажется, серьёзная для пользователей скринридеров, это то, что этот элемент озвучивается по-разному в разных сочетаниях браузеров и скринридеров. То есть в некоторых браузерах и скринридерах может просто при фокусе на элемент, который ещё в свёрнутом состоянии, оно выглядит нативно как треугольничек, рядом текст, который мы в <summary> положили. Мы нажимаем на этот текст, он разворачивается, и там выпадает всё, что мы положили внутрь <details>. В общем, когда фокус скринридера попадает на этот треугольничек с текстом, например, текстом «Показать больше», то некоторые скринридеры просто зачитывают фразу «показать больше», то есть они не говорят ни что это за элемент, ни какая у него семантика. Просто говорят «показать больше». В частности, так делает VoiceOver на iOS, то есть на мобильных платформах.

Но иногда скринридер даёт даже слишком много информации. Например, в Firefox на macOS скринридер будет говорить, что это стрелка, которая указывает вправо, точнее, треугольничек, который указывает вправо, что там текст «show more», что это скрытый, что это <summary>, что это группа. Очень много информации для пользователя.

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

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

Также Мануэль выяснил, что наиболее хорошее зачитывание будет обеспечено VoiceOver в браузерах Chrome, Edge и Arc. Прикольно, что он тестит Arc. На самом-то деле, я редко встречаю Arc в тестировании доступности. Ещё в VoiceOver на macOS в Safari будет хорошее зачитывание, TalkBack Android в Chrome будет тоже хорошо читать. В Safari, в VoiceOver на мобильных платформах, на iOS, он говорит, что оно читается стабильно, но типа в плохом смысле. [Скринридер] вообще не озвучивает ни роль, ни состояние, ничего. Просто говорит «show more» — «показать больше».

Ещё он подметил, что когда поиск по странице происходит в браузере, то в некоторых браузерах, в некоторых скринридерах будет поиск проходить внутри свёрнутого контента, и, по-моему, даже автоматически будет разворачиваться <detail>/<summary>, но это, опять же, происходит не везде.

И он напоминает, что в Safari, если хотите удалить треугольничек, нельзя просто так взять его и удалить. Нужно через WebKit-овые префиксы удалять этот треугольничек.

Ну и да, и он [Мануэль] спрашивает у нас, а какой же вывод из этого сделать? И приводит цитату Скотта, что, кажется, сейчас всё-таки лучше использовать паттерны из Authoring Practices, которые предполагают использование ARIA-атрибутов.

На самом деле, там ничего сложного. Если вам нужен просто такой дискложер-элемент, то вы можете использовать просто <button>, у которого будет несколько ARIA-атрибутов — aria-controls, таким образом вы показываете, какой элемент будет разворачиваться. Туда вставляется ID-шник текста под <button>. Дальше вы используете aria-expanded и меняете состояние из JavaScript true/false в зависимости от состояния вашего дискложер-элемента, развёрнут он или свёрнут, да и всё. То есть это <button>, и под <button> — <div>. У <button> несколько ARIA-атрибутов. Ничего сложного, всё супер тоже нативно. Единственное, что чуть-чуть JavaScript написать, менять значение атрибута.

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

Мы у себя в команде тестили, пытались <details>/<summary> как-то впихнуть в заголовок. Это максимально не по семантике получалось. <summary>, по сути, для браузера — это <button>. Ты не можешь положить заголовок в <button>, но и обернуть <summary> в <h>-тег ты тоже не можешь, потому что для браузера это нарушение правил, ошибка валидации в <details>. Первый элемент должен быть обязательно <summary>. Поэтому сложности возникают, как только ты пытаешься <details>/<summary> приковырять к какому-то своему способу использования на сайте.

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

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

И Брайан рассказывает о том, с какими проблемами он сталкивается, когда использует Dragon. Это такая очень популярная программа для управления интерфейсами и распознаваниями речи. Она недавно была, кстати, куплена Microsoft. До этого это был, можно сказать, open-source проект. И у этой программы очень много прикольных фич, которые, собственно, и делают её такой популярной.

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

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

И вот каким выводом он [Брайан] приходит.

Во-первых, для голосового управления невероятно важна разметка, ваш код. Он должен быть семантическим. Да-да, так же, как и для скринридеров. Здесь такие программы, эти вспомогательные технологии ничем не отличаются от скринридеров. И, например, он [Брайан] показывает, как сложно взаимодействовать с кнопкой, которая по факту кнопкой не является. То есть это <div> с событием onClick. И если у этой кнопки нет какого-то видимого названия, а это, например,
иконка, то, смотрите, здесь возникают две проблемы.

Во-первых, в Dragon есть команда «клик кнопка», «клик ссылка», и эта команда не сработает, потому что это не кнопка. Потому что у этого элемента нет role="button", и это не <button>. В лучшем случае. И поэтому пользователям голосового управления приходится танцевать с бубном. Там есть два варианта решения этой проблемы. С одной стороны, они могут голосом управлять положением мыши, и очень долго и нудно ждать, когда курсор достигнет своей цели, постоянно меняя его координаты вверх, вниз, вправо, влево.

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

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

Следующая проблема, которая помимо семантики и кнопок без видимых лейблов, она связана с этим. Представьте себе, вы всё-таки продвинутый разработчик, который использует тег <button>. Вы сделали кнопку настоящую, не фейковую, с помощью JavaScript, и всё так же решили, что вы добавите к ней иконку. И дальше вы, ну, вы же продвинутый разработчик, вы добавляете ещё туда aria-label, чтобы пользователи скринридеров знали, как называется эта кнопка. И представим, что это кнопка с домиком, которая означает перейти на главную страницу, но ваш лейбл вы решили сделать необычным. Вы решили назвать эту кнопку «Невероятные приключения на главную страницу». И в таком случае для пользователя голосового управления он, конечно, может сказать «клик кнопка», потому что это настоящая кнопка, но если пользователь не знает об этой команде, например, по какой-то причине, например, он новичок, то ему придётся угадывать, ему придётся
угадывать, как называется ваша чудесная кнопка. И это тоже может занять довольно много времени.

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

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

В общем, это реально крутая статья и очень важная тема, о которой, как я уже сказала, незаслуженно мало говорят.

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

Если вы не знаете, то Ubisoft — это супер известная ААА геймдев-студия, которая, например, разрабатывает ни много ни мало Assassin's Creed. И в этом интервью он рассказывает коротко о своей карьере, как он, собственно, начал заниматься доступностью в игровой индустрии и вообще как там с ней обстоят дела. Такой краткий экскурс, что изменилось за десять лет.

И он [Дэвид] рассказывает о том, как он начинал свою карьеру UX-ресёрчером, UX-исследователем в PlayStation, где он даже пытался в какой-то момент протащить тестирование с пользователями с инвалидностью, но в тот момент, это был 2014 год, его развернули. Сказали, что вы тут придумываете, что это вообще такое, кому нужна доступность, но он не сдавался.

Он не сдавался и в какой-то момент познакомился с очень известным адвокатом доступности, я бы сказала, Йеном Гамильтоном, который является одним из основателей одной из самых крупных конференций по доступности в игровой индустрии, The Gaming Disability Conference, или GAConf, коротко. Наверное, больше людей знает её именно так.

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

В 2017 году вышла Assassin's Creed Origins. И эта игра считается первопроходцем в мире доступных игр. Что в этой части Ассасинов было таким уникальным? А то, что они добавили довольно крутые и полные настройки для субтитров. Их можно было менять в плане размера, можно было выбирать более яркий фон для них, чтобы они были более различимыми и контрастными. И это был реально первый ААА-проект с фокусом на доступности.

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

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

И вот с тех пор очень много поменялось, и Дэвид рассказывает о том, что в Ubisoft они начинали свой путь в, собственно, мире доступности с малого. Они сначала пользовались активно разными чек-листами и рекомендациями на основе Game Accessibility Guidelines и Xbox Accessibility Guidelines. Это вот такие WCAG-и в мире геймдева. И сейчас компания вот с тех первых небольших шагов перешла к тому, что они не просто стараются следовать разным руководствам, написанными другими людьми, но и создавать какие-то свои решения, стараются при этом придумывать какие-то инновационные штуки, которых нет у других конкурентов, чтобы к ним приходило больше геймеров со своими деньгами. Ну и также, конечно, это всё очень помогло и репутации Ubisoft.

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

В это время ещё, если вы не знаете, есть такая очень крупная конференция The Game Awards, которая каждый год в разных категориях награждает разные игры, и в 2020 году в ней появилась категория за инновации в доступности. И я так посмотрела на тех, кто эту премию выигрывал. Среди них нет Ubisoft, спойлер, но они были номинированы на неё.

И, если вам интересно, то в 2020 году, когда эта премия появилась, то её в этой категории победила The Last of Us 2. В 2021 это была пятая Форза, и в 2022 God of War Ragnarök. Все эти игры от разных студий, не Ubisoft, но очень круто, что такие большие проекты думают и учитывают потребности разных пользователей, и за эти десять лет доступность перестала быть чем-то странным и маргинальным, и стала базовым требованием не только в Ubisoft, как говорит Дэвид, но и ещё в Xbox и EA, то есть в других двух очень крупных игровых студиях.

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

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

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

Следующее событие, которое мы хотим рассказать, это очень крутой оффлайн и онлайн-ивент, называется CSS Day. Это большая конференция в Амстердаме, туда приезжают все те, чьи статьи мы здесь с вами рассматриваем. Мануэли Матузовичи, Скотты О'Хары и прочие. Нет, кстати, Скотта там не будет. Там 100% будут доклады, связанные именно с доступностью.

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

Так что, да, можно посетить этот ивент оффлайн. Я уверена, что в оффлайне там уже всё распродано. Я знаю точно, что у них есть waiting list [лист ожидания], поэтому можно попробовать попасть через этот лист. Но это мероприятие будет транслироваться в онлайн и трансляция тоже стоит денежек. Так что не только про бесплатный контент мы тут с вами общаемся. Посетите. Я уверена, что будет очень крутая конференция, тем более целый день про CSS.

Кроме того, нас ожидает с вами в далёком сентябре, в конце сентября, 27–28, такая небезызвестная компания WordPress делает классный очень инструмент для создания сайтов, мы все его обожаем со всех сторон, и особенно accessibility, которое нужно настраивать в WordPress, но удивительно, они уже несколько раз сделали этот ивент. Называется WordPress Accessibility Day. Почему мы сегодня про него рассказываем? Потому что сейчас туда открыто CFP, то есть можно податься с докладом. Плюс можно пойти волонтёрить, помогать им с организацией этого ивента, поэтому прочекайте, это всё будет онлайн.

Если вы хотите о чём-то рассказать в мире доступности или помочь создать классный ивент, то приходите к ним.

И, кроме того, совсем недавно, 10 мая прошла конференция Google I/O. Почему мы про неё рассказываем? Потому что все материалы сейчас в доступе, они абсолютно свежие и можно их посмотреть сегодня. На ней было несколько докладов про доступность, связанных именно с доступностью. В частности, там было целых два доклада про то, как сделать доступным приложение Android и что нового в Android Accessibility. Кроме того, там рассказывается о том, как сделать доступные продукты с помощью Material Design. Также освещают доступность Jetpack Compose, что тоже относится к Android, в общем. Есть доклад про инклюзивность и, естественно, про доступность веб-приложений, наших прекрасных веб-сайтов, поэтому, пожалуйста, сходите, посмотрите.

Я не уверена, дадут ли вам лейблу, что вы участвовали в Google I/O, если вы сейчас зарегистрируетесь. Но, может быть, ещё и лейблочку получите.

На этом с событиями всё.

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