То, что у меня и каждого специалиста по веб-доступности есть проблемы с тостовыми уведомлениями — это мягко сказано. Еще в 2020 году я подробно объяснил все многочисленные способы, которыми они подводят пользователей, и как добиться лучшего UX с их помощью.
Похоже, GitHub, а вместе с ним и Microsoft, потребовалось еще 6 лет, чтобы прийти к тому же выводу: тосты как элемент дизайна и UX в рамках современных технологических стандартов проблематичны. Можно было бы подумать, что очевидным следующим шагом компании стоимостью 3,51 триллиона долларов будет закатать рукава и исправить ситуацию. Но нет: GitHub принял трусливое решение — просто запретил тосты полностью.
Краткий обзор тостов и позиции GitHub
Тосты — это небольшие уведомления, которые появляются вверху, внизу или сбоку экрана. Иногда они могут запускаться действием пользователя, иногда — автоматически. Но неважно, почему они появляются. Гораздо важнее — куда и когда они исчезают.
Тосты — это универсальная проблема для всех типов и размеров устройств. Однако они особенно проблематичны в десктопной версии, то есть в браузере.
Подавляющее большинство реализаций тостов в вебе сделаны с помощью кастомных компонентов. Некоторые даже называют их по-другому, просто чтобы казаться круче, например, Snackbar от MUI. Суть в том, что в вебе нет нативного компонента <snackbar> или <toast>. Если посмотреть на исходный код любого из них, вы найдёте несколько элементов div с навешанными на них ARIA-атрибутами, вроде presentation и alert.
Нативный API для уведомлений в браузере имеет невероятно плохую поддержку, и с 2020 года ничего не изменилось. Так что реальной альтернативы нет.
Очень часто тосты исчезают без какого-либо действия пользователя, унося с собой информацию. Есть у пользователя время на ее восприятие или нет — неважно, уведомление исчезнет через заданное количество секунд.
Как правило, историю этих уведомлений нигде нельзя найти, поэтому событие и его содержание теряются навсегда.
На десктопе тосты обычно появляются вне непосредственного фокуса пользователя, возможно, даже вне его поля зрения — например, в нижнем левом углу 32-дюймового сверхширокого монитора или при использовании увеличения экрана.
Этих причин уже достаточно, чтобы серьезно задуматься над любой дизайн-системой и решить, хорошая ли вообще идея — использовать тосты. И то, что GitHub это делает, справедливо и правильно.
Однако вывод о том, что «тосты представляют серьезные проблемы с доступностью, и их использование не рекомендуется» (дизайн-система GitHub Primer) уже за гранью нелепости и откровенной странности по ряду причин. Некоторые из них я сейчас разберу.
А пока давайте просто поймем, что они предлагают взамен, и почему эти идеи не так уж хороши:
1. В случае подтверждения простого действия — не давайте никакой обратной связи, это должно быть очевидно.
Да, конечно, ведь именно так интернет работает в реальной жизни. Нет же! В подавляющем большинстве случаев это «простое действие» в фоновом режиме — один или несколько API-запросов, которые должны успешно выполниться в нужное время. Такие сетевые вызовы могут не удаться по множеству причин.
Даже если речь идет о простом действии, вроде добавления Jira-тикета в бэклог, мне нужно точно знать, что оно произошло, а не гадать, произошло оно или нет.
2. Для подтверждения сложного действия — используйте диалоговые окна, баннеры и многоступенчатый прогрессивный UX.
Получается, создание большего количества трений — это более доступный способ выполнения работы? Конечно, нет. Даже UX-дизайнер, не задумывающийся о доступности, знает, что трение в пользовательском пути — это редкость и, как правило, часть стратегии монетизации.
Сайты бюджетных авиакомпаний вроде Ryanair в этом преуспели — и это не комплимент. Проще говоря, баннеры смещают весь интерфейс; диалоговых окон у нас и так слишком много, а использовать многоступенчатый прогрессивный UX для того, что «могло бы быть просто тостом», — это как сбросить напалмовую бомбу, чтобы убить муравья. Даже слово «избыточность» не способно в полной мере описать эту ситуацию.
И тем не менее, «GitHub рекомендует использовать другие, более устоявшиеся, эффективные и доступные способы взаимодействия с пользователями». Это не имеет никакого смысла, так как фактически является запретом и войной с тостами.
Странный подход, который не сходится с реальностью
Для тех, кто не так хорошо знаком с бизнес-реалиями GitHub, поясню: компания была приобретена несколько лет назад Microsoft, а Microsoft — это компания стоимостью 3,51 триллиона долларов. Чтобы полностью осознать этот масштаб, представьте, что у GitHub есть доступ к сумме денег, которая в 3190 раз превышает количество сайтов во всемирной паутине. Это очень и очень много.
Кроме того, Microsoft является платным членом консорциума W3C. Точная сумма взноса не разглашается, но я знаю другую компанию — с большим влиянием в технологической индустрии, но гораздо меньшую, чем Microsoft — чей годовой членский взнос в W3C в 2018 году составлял около 1 миллиона долларов. Это огромные инвестиции в веб-стандарты, но их смысл станет понятен вам чуть позже.
Веб-стандарты не возникают из ниоткуда. Нет никакого «мудреца в высоком замке», который придумывает, какие новые стандарты нам нужны. Этот процесс требует кооперации и зачастую движим бизнес-потребностями. Именно поэтому существуют рабочие и бизнес-группы W3C — чтобы объединить самых выдающихся и активных специалистов мира и сделать веб-пространство лучше и удобнее для всех пользователей.
У Microsoft — а следовательно, и у GitHub — есть прямой доступ к W3C, и эта компания может оказывать огромное влияние на разработку новых стандартов. Однако они предпочли этого не делать, а вместо этого просто запретили тосты.
Те, кто знаком с историей веб-пространства и, что важнее, историей HTML, знают, что, за исключением чистого текста, ни один компонент никогда не был доступным по умолчанию. Происходило зарождение идеи нового компонента, и иногда к моменту его внедрения в последний стандарт он был доступен, а иногда — нет.
Самым недавним случаем серьезной переработки HTML с точки зрения доступности стал HTML5, который даже ввел такие семантические элементы, как <article>, <aside>, <details>, <figcaption>, <figure>, <footer>, <header>, <main>, <mark>, <nav>, <section>, <summary> и <time>. Почему? Потому что все использовали элемент div для всего подряд.
Но даже этого недостаточно в контексте современного веб-пространства, где мы часто создаем уже не просто веб-сайты, а веб-приложения. На помощь приходит WAI-ARIA.
И хотя первое правило доступности в отношении ARIA — это знаменитое ироничное «не используйте ARIA», в реальности это становится все менее применимо к современному веб-пространству. JavaScript доминирует в вебе, поэтому ARIA, как правило, становится неизбежным.
И это хорошо. Когда речь заходит о доступности, я часто наблюдаю эту редукционистскую тенденцию — вернуться к скучному, статичному вебу, где у вас, по сути, был только текст и картинки, и отвергать все современное и инновационное.
Но веб никогда не был пространством для простых и скучных вещей. Веб никогда не был местом, где мы избавляемся от всего, что не можем сразу понять. Вы думаете, добиться стабильной работы онлайн-платежей в интернете было легко? Вы считаете, что потоковая передача фильмов в вашем браузере появилась не благодаря огромным усилиям таких компаний, как Netflix? Многое из того, что вы можете делать сегодня в сети, стало возможным благодаря дальновидным — и да, даже корыстным — отдельным людям и компаниям.
Что должно было произойти вместо этого
То, что GitHub, а вместе с ним и Microsoft, пошли против течения, откровенно говоря, ошеломляет, ведь у них есть все возможности влиять на стандарты так, как никто никогда раньше не мог. Решение состоит не в том, чтобы запрещать тосты, а в том, чтобы найти способ создать доступный тост и включить его в стандарт HTML. Но GitHub считает, что это плохая идея:
Эта работа была основана на обширных первичных инклюзивных пользовательских исследованиях, проведенных одним из моих коллег. Каждый отдельный сценарий использования тоста был лучше реализован с помощью наших существующих паттернов. Это решение укрепляет единообразие платформы, оказывает лучшие услуги глобальной аудитории с неизвестными устройствами и потребностями в доступности, и в конечном итоге требует меньше усилий, чем попытки исправить каждый отдельный случай использования тостов. — Эрик Б., GitHub
Хотя я приветствую подход, основанный на исследованиях, которым они обосновали свое решение, я категорически осуждаю его неколлаборативную сущность. Будучи лидерами во всех сферах технологий и веба, они могли бы использовать по-настоящему инклюзивную стратегию, то есть представить эти выводы рабочим группам W3C, попросить поддержки в дальнейшем изучении вопроса и предложить компонент тоста, соответствующий стандартам WCAG, для включения в стандарт HTML.
Я абсолютно убежден, что этот путь является непростым и требует времени — гораздо больше времени, чем проведение независимого исследования, последующее разочарованное пожатие плечами и заявление: «Тосты — это плохо, давайте запретим все тосты». Но ведь ни одно великое достижение в технологии никогда не давалось легко.
Представьте, если бы все просто смирились с неудачей Леонардо да Винчи, чей летательный аппарат не поднялся в воздух, и пришли к следующему выводу: «Все самолеты плохи, давайте запретим полеты».
На самом деле, в интернете существует множество проблемных компонентов. И ни один из них не появляется в сети без причины. Как инженер, я встаю на сторону дизайнеров, когда говорю, что все они пытаются творчески решить какую-либо проблему. Заранее продумать каждый сценарий использования сложно, и именно поэтому такие компоненты, как тост или всплывающая подсказка, представляют собой крепкие орешки — их трудно реализовать так, чтобы они идеально работали для всех. Но мы обязаны это сделать.
Представьте себе стандартный HTML-компонент <toast>, который, в первую очередь, понимает контекст, и в зависимости от того, работает ли он на десктопе или мобильном устройстве, адаптирует свое представление и поведение. Поразительно, что адаптивный дизайн до сих пор путают с просто «перетекающим» (reflowable) дизайном, единственное реальное отличие которого в том, что интерфейс помещается на меньший экран. Но адаптивный дизайн задумывался как нечто гораздо большее: он должен использовать все возможности, которые предлагает контекст.
Это тот самый стратегический подход, который нам всем следует применять в отношении веба, доступности и пользовательского опыта (UX). Полумеры не работают, потому что они воспроизводят ту самую проблему, которую изначально должны были решить. Решение не было плохим, оно было просто плохо реализовано — и, как я говорил ещё в 2020 году, — так и не было стандартизировано. И я знаю, что множество профессионалов в нашей индустрии придерживаются того же мнения.
Я говорю это как специалист по веб-доступности, и то, что делает GitHub, — глупо. Так же глупо, как и утверждать, что всплывающие подсказки нужно запретить. Запреты — не решение, решение — в улучшении. Абсолютно реально создать доступные тосты и всплывающие подсказки. Но, конечно, проще сдаться и испортить пользовательский опыт всем, вместо того чтобы выполнить сложную работу по совершенствованию технологий и способа написания кода для приложений и сайтов.
Читайте также:
- Рабочий процесс на GitHub: профессиональный уровень
- Инструменты с открытым исходным кодом, популярные на GitHub
- Способы публикации библиотеки JavaScript: CDN, NPM, GitHub
Читайте нас в Telegram, VK и Дзен
Перевод статьи Attila Vágó: Why GitHub’s War On Toasts Is Bad News For Accessibility
