Медиазапросы: уважение пользовательских предпочтений в интерфейсах
Используйте предпочтения по анимации, контрасту, принудительным цветам и цветовой схеме как доступные настройки по умолчанию, сохраняя видимые элементы управления.
Нужна структурированная документация по теме Платформа?
Эта статья относится к редакционной библиотеке. Для пошаговой настройки, справки и постоянных обновлений переходите сразу в соответствующий раздел docs.
Медиавозможности CSS позволяют странице учитывать состояния предпочтений доступности и оформления, предоставляемые браузером или другим пользовательским агентом, включая значения по умолчанию; эти состояния не указывают, выбирал ли их человек. Запросы prefers-reduced-motion, prefers-contrast, forced-colors и prefers-color-scheme помогают сайту изначально выбрать представление с учётом предоставляемых предпочтений. Они должны быть входными данными для удобного дизайна, а не заменой читаемым настройкам по умолчанию, семантическим элементам управления или явному способу выбрать оформление.
Практическое правило просто: учитывайте предпочтение, не мешайте выполнению задачи и делайте настройку сайта, которая его переопределяет, заметной и обратимой. Человек, чувствительный к анимации, должен понимать изменения состояния; пользователь системной цветовой палитры должен различать элементы управления; а предпочитающий тёмный интерфейс не должен получать малоконтрастную тёмную тему для всего сайта. В руководстве по взаимодействию с указателем рассматривается другой аспект адаптации интерфейсов, а проверка взаимодействия в браузере и конфиденциальность при проектировании браузерных процессов описывают более общие принципы проверки и выбора.
Предпочтения помогают проектированию, но не решают все вопросы доступности
Медиазапросы - это условные правила CSS. Запрос проверяет медиавозможность, например предпочитаемую пользователем цветовую схему или применение браузером принудительной цветовой палитры, и позволяет таблице стилей выбрать соответствующие объявления. Это тот же общий механизм, который помогает макету учитывать ширину окна, но условие здесь описывает предпочтение оформления, а не физический размер экрана. Браузер вычисляет запрос и применяет подходящие правила при изменении среды.
Эти возможности сообщают ограниченный набор значений, определённых веб-платформой. Они не объясняют, почему человек выбрал настройку, какими вспомогательными технологиями пользуется и какое представление подойдёт ему в каждом контексте. Приложению не следует пытаться выводить такие личные сведения. Оно может реагировать на предпочтение, которое предоставляет браузер, и поддерживать целостный интерфейс, не присваивая человеку характеристик или возможностей. Предпочтение - полезный сигнал для проектирования, а не профиль пользователя.
Это различие важно, поскольку медиазапрос не исправит все проблемы доступности. Правило уменьшения анимации не добавит отсутствующую подпись к элементу управления. Тёмная цветовая схема сама по себе не гарантирует читаемость текста. Адаптация к принудительным цветам не заменяет осмысленную семантику HTML. При любом оформлении нужны достаточный контраст, видимый фокус, понятные состояния и элементы управления, доступные с поддерживаемыми продуктом способами взаимодействия.
Используйте медиазапросы для постепенной адаптации. Сначала обеспечьте полноценную работу по умолчанию, а затем меняйте только те части интерфейса, которым нужно учитывать предпочтение. Содержание, иерархия и выполнение задачи должны оставаться одинаково понятными в разных темах. Например, если анимация передаёт ход выполнения, её уменьшение не должно скрывать прогресс: ту же информацию может передать статичный индикатор или краткий текст состояния. Если ошибка обозначена цветом, понять её также должны помогать сообщение и значок.
Для визуальных изменений отдавайте предпочтение CSS, поскольку браузер может повторно вычислить стили без ожидания кода приложения. JavaScript уместен, если предпочтение должно влиять на поведение, которым CSS управлять не может, например на решение, запускать ли необязательную анимированную последовательность. Ограничьте такое поведение и предусмотрите возможность остановить или изменить его. Не используйте JavaScript для повторной реализации того, что CSS может обработать напрямую, и не сохраняйте полученный от браузера выбор так, будто это было осознанное решение в настройках сайта.
Уменьшение анимации должно сохранять смысл и контроль
Медиавозможность prefers-reduced-motion может соответствовать запросу пользователя на уменьшение необязательного движения в интерфейсе. Таблица стилей может применять @media (prefers-reduced-motion: reduce), чтобы убрать или сократить переходы, параллакс, анимированную прокрутку, автоматически запускаемое движение и другие эффекты, не нужные для выполнения задачи. Значение no-preference означает, что пользовательский агент не применяет запрос на уменьшение движения; это не разрешение анимировать каждое взаимодействие и не подтверждение, что анимация удобна всем.
Сначала определите, какое движение служит декорацией, а какое передаёт необходимую информацию. Подпрыгивающая карточка, привлекающая внимание, обычно может остаться неподвижной. Вместо циклической анимации загрузки может понадобиться стабильный индикатор выполнения или текстовое сообщение. Переход графика может сразу показывать новое значение, сохраняя подписи и предыдущий контекст. Сворачиваемая панель может открываться без долгого эффекта скольжения, при этом её состояние останется доступно программно. Цель не в том, чтобы скрыть изменение, а в том, чтобы сообщить о нём без лишнего движения.
Глобальное правило может быть полезным исходным решением, но компоненты не должны полагаться только на одну глобальную замену длительности анимации. Движение может появляться из-за переходов CSS, ключевых кадров, библиотек анимации JavaScript, встроенных мультимедиа или автоматически воспроизводимого содержимого. Проверьте весь интерфейс и при необходимости добавьте правила для отдельных компонентов. Правило, почти обнуляющее длительность каждой анимации, всё ещё может оставлять отвлекающие обновления кадров, мигание или движение, создаваемое сценариями. Оно также способно убрать задержку, помогающую заметить взаимодействие. Проверяйте результат, а не только соответствие селектора.
Некоторое движение запускается по прямому запросу пользователя, например кнопкой воспроизведения видео или явным открытием анимации графика. Предпочтение уменьшения движения не должно незаметно делать недоступным необходимый элемент управления. Вместо этого рассмотрите статичное представление, начальное состояние на паузе или явный запуск с видимой кнопкой остановки либо паузы. Критерий успеха WCAG 2.2 2.2.2 относится к движущемуся, мигающему или прокручивающемуся содержимому, которое запускается автоматически, длится более пяти секунд и показывается вместе с другим содержимым: предусмотрите паузу, остановку или скрытие, если движение не является необходимым.
Если в продукте есть собственная настройка движения, назовите варианты понятно, например «Уменьшить анимацию» или «Разрешить анимацию интерфейса». Рядом с настройкой объясните её практический эффект, не используя терминологию реализации. Не заставляйте человека открывать настройки системы, чтобы остановить необязательный эффект на сайте. В то же время настройка сайта не должна незаметно отменять запрос операционной системы. Осторожный порядок таков: по умолчанию учитывать системное уменьшение движения, а явным выбором на сайте управлять только его необязательными эффектами; возврат к системной настройке должен быть простым.
Для предпочтений контраста нужны понятные визуальные варианты
Возможность prefers-contrast позволяет адаптировать стили, когда пользовательский агент сообщает о предпочтении большего или меньшего контраста либо определённого способа его настройки. Поддерживаемые браузером значения зависят от платформы и реализации; перед опорой на конкретное значение проверьте актуальную совместимость. Обязанность разработчика шире одной медиавозможности: обычный текст и элементы управления должны оставаться различимыми в поддерживаемых условиях, а информация не должна зависеть только от едва заметного оттенка.
Для предпочтения more полезны более выраженное различие текста и фона, заметные границы элементов управления, чёткие индикаторы фокуса и лучшее различие соседних состояний. Выбранная вкладка не должна отличаться только небольшим сдвигом оттенка. Сочетайте цвет с подчёркиванием, формой, насыщенностью шрифта или другим видимым признаком. Отключённые элементы управления должны оставаться понятными, а не сливаться с окружающим текстом. В сообщениях об ошибке и успехе используйте подпись или значок вместе с цветом, чтобы смысл был доступен людям с разными особенностями восприятия цвета.
Предпочтение less может быть важно людям, которым мешает слишком интенсивный контраст. Оно не означает, что важный текст должен стать бледным, а элементы управления - сливаться с фоном. Задайте умеренную палитру, в которой остаются читаемый текст, видимые границы и фокус. Отдельно проверьте мелкий текст, тонкие линии, подсказки в полях, выбранные состояния и состояния при наведении. Палитра, хорошо выглядящая в крупном заголовке, может оказаться неудачной в компактной форме или на отключённой кнопке.
Значение custom, если оно поддерживается, может обозначать заданное пользователем предпочтение контраста, которое не подходит к простым категориям more или less. Не воспринимайте его как требование создать универсальный режим «настраиваемого контраста». Браузер может не предоставлять через эту медиавозможность выбранные человеком цвета. Сохраняйте читаемость страницы благодаря тщательно проверенным собственным настройкам по умолчанию и предлагайте выбираемые темы, если приложение может предоставить полезные варианты.
Не полагайтесь на запрос предпочтения для соблюдения базовых требований к контрасту. Человек может не знать, где включить параметр операционной системы; браузер может его не предоставлять; либо среда просмотра может преобразовывать цвета. Проверяйте текст, важные графические объекты, обводки фокуса и границы элементов управления по применимым критериям доступности как в стандартной теме, так и во всех поддерживаемых режимах. Изменение контраста не должно стирать фирменное оформление или создавать вторую палитру, которую никогда не проверяли при реальном размере содержимого.
При принудительных цветах используйте системную палитру и соблюдайте меру
Медиавозможность forced-colors сообщает, что пользовательский агент применяет ограниченную цветовую палитру. Этот режим отличается от предпочтения высокого контраста: браузер может заменить заданные автором цвета цветами пользователя или системы, чтобы согласовать передний и задний планы. Запрос вроде @media (forced-colors: active) позволяет внести точечные изменения, когда принудительная палитра меняет важные визуальные различия обычного представления.
В этом режиме сохраняйте возможность браузера применять палитру. Системные ключевые слова цвета, например Canvas, CanvasText, LinkText, ButtonFace и ButtonText, задают связь с текущими системными цветами вместо жёстко заданных светлых или тёмных значений RGB. По возможности используйте встроенные элементы управления с подходящей семантикой. Для пользовательских элементов управления проверьте видимость границ, фокуса, выбора и состояний после того, как пользовательский агент заменит цвета. Границу, намеренно сделанную прозрачной в обычной теме, может потребоваться показать, чтобы границы элемента управления оставались ясными.
Свойство forced-color-adjust управляет тем, подвергается ли элемент корректировке принудительных цветов. Обычно лучше оставить поведение по умолчанию. Значение forced-color-adjust: none исключает элемент из этой корректировки. Применяйте его только к отдельному элементу, если приложение само адаптирует его цвета к потребностям пользователя в цвете и контрасте, и проверяйте результат в режиме принудительных цветов. Исключение всей страницы может помешать применению выбранной палитры и создать нечитаемые сочетания. Обычно лучше сохранить структуру и использовать системные цвета для элементов, которым нужна адаптация.
Не считайте, что декоративное изображение или фон останутся видимыми в режиме принудительных цветов. Сведения, переданные фоновым изображением CSS, могут пропасть, если фон скрывается или перекрашивается. Для важной информации используйте обычный текст, доступные имена, границы или подходящую встроенную графику с видимым запасным вариантом. Для значков, смысл которых зависит от заливки, убедитесь, что остаётся заметной обводка. Проверяйте фокус клавиатуры и выбранные состояния в реальной среде принудительных цветов: снимки обычной темы не покажут все замены.
Принудительные цвета не означают, что нужно создавать собственную чёрно-белую тему с жёстко заданными цветами, конкурирующую с системными настройками. Системная палитра - это видимый выбор пользователя, и она может включать не только чёрный и белый. Позвольте платформе применить её, а затем добавьте лишь минимальные правила CSS, необходимые для удобной иерархии содержания и элементов управления. Не переопределяйте системные цвета глобально и не используйте forced-color-adjust: none как быстрый способ сохранить внешний вид.
Цветовая схема должна учитывать явный выбор на сайте
Возможность prefers-color-scheme позволяет выбрать стили для светлого или тёмного предпочтения. Страница может сразу использовать палитру, соответствующую выбору браузера или операционной системы, в том числе если человек изменит это предпочтение во время просмотра. Тёмная тема в некоторых условиях уменьшает количество ярких поверхностей на экране, а светлая может лучше подходить для других задач. Ни одна из них не лучше для всех: обе требуют продуманного выбора цветов и проверки.
Свойство CSS color-scheme сообщает, какие цветовые схемы поддерживает элемент или документ. Объявление поддержки светлой и тёмной схем помогает пользовательскому агенту согласовать с ними встроенные элементы управления, поля форм и другие поверхности браузера. Это объявление не гарантирует доступность всей страницы и не заменяет стили для содержимого сайта. Согласуйте свойство с реально доступными палитрами, чтобы встроенные поля не выглядели иначе, чем окружающий интерфейс.
Если на сайте есть переключатель темы, различайте варианты «системная», «светлая» и «тёмная». Начальное значение может следовать системному предпочтению, а осознанный выбор затем может иметь приоритет, пока человек его не изменит. Разместите элемент управления в предсказуемом разделе настроек, подпишите простыми словами и предусмотрите лёгкий возврат к системной схеме. Не переключайте тему автоматически после изменения системного предпочтения, если человек уже явно выбрал другую.
Сохраняйте выбор на сайте, только если это полезно для функции и человеку понятно, что именно запоминается. Храните значение явного выбора, а не снимок предпочтения браузера при первой загрузке. При выборе «системная» продолжайте учитывать текущее системное предпочтение. Тогда тема, которая однажды совпала с системной, не станет устаревшим переопределением после изменения настроек устройства. Так интерфейс также сможет точно объяснить своё поведение.
У элементов управления темой должны быть доступное имя, управление с клавиатуры, видимый фокус и ясное обозначение выбранного варианта. Сегментированный элемент может показывать варианты «Системная», «Светлая» и «Тёмная», не скрывая текущее значение в меню. Если используется компактный переключатель, его подпись должна ясно объяснять результат, а не просто говорить «переключить». Не обозначайте выбор только цветом. Проверьте цвета фокуса, ошибок, ссылок, графиков и диалоговых окон во всех поддерживаемых схемах. Убедитесь также, что смена темы не вызывает краткого показа неправильной палитры до применения сохранённого выбора.
Изменение предпочтения не должно прерывать задачу
Медиазапросы оцениваются для текущей среды, а не только один раз при загрузке страницы. CSS может реагировать, если человек меняет тему операционной системы или параметр доступности, пока сайт остаётся открытым. Если приложению нужно реагировать поведением, JavaScript с помощью matchMedia() может проверить соответствие запроса и слушать событие change. Уведомление об изменении MediaQueryList должно обновлять нужное поведение, а затем обработчик следует удалить, когда компоненту или странице он больше не нужен.
Ограничивайте реакцию JavaScript. При смене темы могут измениться цвета подписей графика, нарисованного на холсте, а не средствами CSS. В ответ на уменьшение анимации компонент может остановить необязательный эффект, которым управляет библиотека компонентов. В каждом случае обновляйте только затронутый внешний вид или поведение. Не перезагружайте страницу, не теряйте несохранённую работу, не закрывайте диалоговое окно и не сбрасывайте приложение из-за изменения предпочтения. Реакции только на CSS обычно проще и с меньшей вероятностью прерывают текущую задачу.
Явный выбор на сайте добавляет второй источник состояния, поэтому определите приоритет заранее и не полагайтесь на порядок событий. Полезная модель такова: явный выбор управляет оформлением сайта; выбор «системная» передаёт управление текущему предпочтению браузера; а режим доступности, например принудительные цвета, продолжает учитываться там, где его применяет пользовательский агент. Для движения настройка сайта может управлять необязательными эффектами, но не должна запускать автоматическую последовательность вопреки запросу на уменьшение движения. Чётко покажите доступные варианты и обеспечьте простой возврат к системному поведению.
Применяйте изменения, не скрывая текущий контекст. Если открыта незавершённая форма, смена темы должна сохранять значения полей, сообщения проверки, фокус и положение прокрутки. Если уменьшение анимации включено во время перехода, приведите компонент к устойчивому состоянию, а не оставляйте между двумя состояниями. Если палитра меняется при открытом всплывающем меню, одновременно обновите меню, затемнение фона и обводку фокуса. Изменение предпочтения должно улучшать текущую работу, а не заставлять человека начинать заново.
Некоторые изменения на уровне платформы применяются немедленно, а изменения поведения приложения могут ждать следующей отрисовки. Не обещайте мгновенное обновление, если асинхронный график или встроенный компонент не может его обеспечить. Сообщайте о задержке или необходимости перезапуска и сохраняйте возможность отменить действие. Для большинства изменений оформления перезагрузка не нужна; если без неё действительно не обойтись, объясните причину до подтверждения.
Проверяйте весь процесс и предотвращайте регрессии
Составляйте матрицу регрессионных проверок вокруг реальных задач, а не только вокруг галереи снимков экрана. Включите оформление по умолчанию, светлое и тёмное предпочтения, уменьшение анимации, актуальные значения контраста для целевых браузеров и принудительные цвета на платформе, где они доступны. Проверяйте сочетающиеся режимы, например тёмное предпочтение с уменьшением анимации или выбранную на сайте тему при включённых принудительных цветах. Конкретная матрица зависит от продукта, но каждый заявленный режим должен давать наблюдаемый результат и иметь воспроизводимую проверку.
Для каждого типичного сценария проверьте начало, активное состояние, завершение и восстановление после сбоя. Откройте и отправьте форму, пройдите по меню, изучите график, закройте диалог и вернитесь после ошибки. Убедитесь, что текущий режим не скрывает индикатор фокуса, не стирает границы кнопок, не делает выбранное состояние неотличимым от остальных и не удаляет сведения, которые раньше передавала анимация. Повторите сценарии, используя только клавиатуру. Если задача зависит от программы чтения с экрана или другой вспомогательной технологии, отдельно проверьте имена, роли, значения и объявления: визуальные медиазапросы не проверяют дерево доступности.
Автоматизированные визуальные проверки могут находить отсутствующие объявления и неожиданные изменения макета, а модульные тесты могут проверять приоритет между системным предпочтением и явным выбором на сайте. Сами по себе они не покажут, хорошо ли виден индикатор фокуса, вызывает ли анимация дискомфорт и удобно ли пользоваться палитрой. Дополняйте автоматизацию ручными проверками с помощью настроек доступности браузера или операционной системы. Записывайте браузер, платформу, режим предпочтений, задачу, ожидаемый и наблюдаемый результат, чтобы можно было воспроизвести регрессию, не собирая личные настройки посетителей.
Проверяйте не только первоначальную загрузку, но и изменения во время работы. Начните с одной схемы и переключитесь на другую при частично заполненной форме. Включите уменьшение анимации во время перехода. Измените контраст, когда элемент управления находится в фокусе. Включите или выключите принудительные цвета, если платформа это позволяет. Убедитесь, что интерфейс обновляется без потери фокуса, введённых данных, выбора и понятного способа вернуться. Эти сценарии проверяют согласование состояния, которое может не выявить снимок после новой загрузки страницы.
Наконец, проверьте содержимое, зависящее от цвета, движения или формы. В сообщениях о состоянии нужно называть результат; у графиков должны быть подписи или альтернативное представление данных; анимация не должна быть единственным способом узнать о завершении; значкам действий нужны доступные имена. Смена темы не должна менять межстрочный интервал или размер текста так, чтобы нарушить предполагаемый порядок чтения. Главная проверка - может ли человек выполнить ту же задачу, понять результат и восстановиться после ошибки при всех поддерживаемых предпочтениях.
Открытые источники
Похожие статьи
Переведите BotBrowser из исследований в продакшн
Используйте эти руководства, чтобы понять модель, а затем перейти к кроссплатформенной валидации, изолированным контекстам и масштабируемому браузерному развертыванию.