Как проектировать таблицы для мобильных экранов: скролл, карточки или упрощение данных

Таблица нужна там, где важны отношения по строкам и столбцам

HTML-таблица предназначена для табличных данных — информации, которая образует логические связи в двумерной сетке. W3C Tables Tutorial подчёркивает, что доступная таблица должна передавать отношения между header cells и data cells, а MDN описывает тот же принцип через строки, столбцы и связанные заголовки.

Например:

Пользователь может читать строку целиком, но может и сравнивать одну колонку между вариантами. Именно второй сценарий отличает таблицу от набора независимых карточек.

Перед мобильной адаптацией поэтому полезно спросить:

пользователь сравнивает объекты между собой или изучает каждый объект отдельно?

Ответ сильно влияет на выбор формата.

Первое решение — действительно ли таблица должна оставаться таблицей

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

W3C рекомендует по возможности упрощать сложные таблицы и разбивать их на несколько отдельных таблиц по подтемам. MDN также отмечает, что сложные структуры с большим количеством объединённых заголовков труднее интерпретировать и иногда лучше представить несколькими более простыми таблицами.

До выбора responsive-паттерна стоит проверить:

• все ли колонки отвечают одной задаче;
• нужно ли сравнивать их одновременно;
• нет ли двух разных сущностей в одной таблице;
• не используется ли таблица вместо обычной структуры карточек или разделов;
• можно ли выделить самостоятельные подтаблицы.

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

Есть три основных стратегии мобильной адаптации

Для большинства информационных таблиц решение находится между тремя подходами:

1. сохранить двумерную таблицу и дать ей локальный горизонтальный скролл;
2. перестроить каждую строку в вертикальный блок или карточку;
3. сократить, разделить или переорганизовать данные.

Ни один вариант не является универсально лучшим.

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

Когда горизонтальный скролл — нормальное решение

WCAG 2.2 делает исключение из требования Reflow для частей контента, которым двумерная компоновка необходима для понимания или использования. Среди примеров прямо названы data tables.

Это означает, что таблица не обязана превращаться в одну вертикальную колонку только ради соответствия узкому viewport.

Горизонтальный скролл оправдан, если:

• сравнение по колонкам является основной задачей;
• пользователю важно одновременно видеть одинаковые атрибуты разных строк;
• перестройка в карточки разрушит сравнительный сценарий;
• часть колонок нельзя удалить без потери информации;
• таблица остаётся понятной как двумерная структура.

CFPB Design System, например, рекомендует horizontal scroll для таблиц, где колонок больше, чем удобно помещается на экране, а исходную табличную структуру важно сохранить. USWDS отдельно предоставляет responsive stacked вариант, показывая, что разные таблицы требуют разных mobile patterns.

Скроллить должна таблица, а не вся страница

Это важная граница.

W3C в разборе Reflow показывает таблицу внутри собственного scrollable container. Таблица сохраняет двумерность, но абзацы до и после неё продолжают нормально перестраиваться в ширину viewport.

Плохой сценарий:

вся статья шириной 1200 px
← горизонтальная прокрутка всей страницы →

Более управляемый:

текст статьи
↓
┌────────────────────────────┐
│ ← прокрутка только таблицы → │
└────────────────────────────┘
↓
текст статьи

Так исключение для двумерной таблицы не распространяется на остальной материал.

Это продолжает общую логику мобильной версии длинной статьи: сложный компонент может иметь собственный сценарий, не ломая reflow всего документа.

Пользователь должен понимать, что таблицу можно прокрутить

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

Интерфейс может подсказать продолжение несколькими способами:

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

Ontario Design System использует overflow indication и горизонтальную прокрутку только области таблицы. Важно, чтобы подсказка не превращалась в самостоятельный декоративный объект сильнее самих данных.

Нельзя полагаться только на едва заметный системный scrollbar: на некоторых мобильных устройствах он показывается непостоянно.

Первая колонка может быть важнее остальных

При горизонтальном движении пользователь способен потерять контекст строки. Особенно если таблица содержит много похожих чисел.

Представим:

Если название показателя уехало за левую границу, значения сложнее соотнести со строкой.

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

Когда строки можно перестроить в карточки

Stacked layout работает лучше, если основная единица информации — отдельная строка.

Desktop:

Mobile:

Заявка: №101
Статус: В работе
Дата: 12 августа
Ответственный: Команда A

Здесь пользователь рассматривает одну запись и её атрибуты. Сравнение «всех дат по вертикали» может быть вторичной задачей.

USWDS на узких экранах поддерживает stacked table, где строка становится вертикальным представлением данных. Некоторые другие дизайн-системы также используют оба режима: cards/panels и horizontal scroll.

Но карточка не является автоматической заменой таблицы. Она меняет способ чтения.

Карточки ухудшают сравнение между строками

В обычной таблице пользователь может быстро двигаться глазами по колонке:

Цена
1 200
1 450
1 180
1 900

В stacked representation значения оказываются внутри отдельных блоков:

Объект A
Цена: 1 200
...

Объект B
Цена: 1 450
...

Объект C
Цена: 1 180

Чтобы сравнить цены, приходится перемещаться между карточками и удерживать предыдущие значения в памяти.

Поэтому правило можно сформулировать так:

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

При stacked view заголовки колонок нельзя просто потерять

В desktop-таблице значение «12 августа» понимается благодаря заголовку «Дата» наверху.

Если строка перестраивается вертикально, это отношение нужно сохранить:

Дата
12 августа

или:

Дата: 12 августа

W3C отдельно подчёркивает: responsive tables могут менять формат, но structural relationships должны оставаться доступными во всех представлениях.

Это касается не только видимой подписи. У исходной HTML-таблицы должны сохраняться корректные отношения header cells и data cells.

Не стоит ломать семантику таблицы только ради карточного вида

Иногда responsive-эффект делают так: настоящую таблицу на мобильном превращают через CSS в набор произвольных блоков.

Здесь нужна осторожность. MDN предупреждает, что изменение display у элемента <table> на block, grid или flex в некоторых браузерах может изменить представление таблицы в accessibility tree и ухудшить её объявление screen reader.

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

Если нужен другой mobile representation, стоит отдельно проверить:

• сохранилась ли таблица как таблица для assistive technologies;
• правильно ли связаны headers и cells;
• читается ли каждая мобильная строка в понятном порядке;
• не дублируется ли одна информация в двух одновременно доступных версиях;
• что происходит при отключённых стилях.

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

Caption помогает понять таблицу до чтения ячеек

W3C рекомендует использовать <caption>, когда таблице нужно короткое название. Caption работает как её идентификатор и помогает пользователю понять, какие данные находятся внутри.

Например:

<table>
  <caption>Сравнение вариантов по сроку и стоимости</caption>
  ...
</table>

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

Для сложной таблицы может понадобиться дополнительное объяснение её организации. W3C отдельно указывает, что summary не должен просто повторять caption.

Заголовки строк и столбцов должны оставаться реальными заголовками

Для простой таблицы используются <th> и <td>. При необходимости направление заголовка можно уточнить через scope="col" или scope="row".

Например:

<th scope="col">Стоимость</th>

или:

<th scope="row">Тариф A</th>

Для сложных многоуровневых таблиц могут понадобиться более явные связи через id и headers.

Это важно независимо от ширины экрана. Responsive design меняет способ отображения, но не отменяет отношения между данными.

Скрывать колонки можно только после проверки их роли

У мобильной таблицы часто пытаются просто убрать часть столбцов.

Это может работать, если колонка действительно вторична и есть другой способ получить её данные. Но автоматическое правило «на телефоне показываем первые три колонки» опасно.

Перед скрытием стоит определить:

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

WCAG Reflow требует сохранять информацию и функциональность при адаптации. Поэтому уменьшение viewport само по себе не является основанием удалить существенные данные.

Иногда лучше дать пользователю выбор колонок

В продуктовых интерфейсах с большим числом атрибутов один из вариантов — позволить выбрать, какие колонки сейчас важны.

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

• полей много;
• разные пользователи сравнивают разные показатели;
• полная таблица нужна профессиональной аудитории;
• фиксированное сокращение не подходит всем сценариям.

Для редакционной статьи такая функциональность чаще избыточна. Здесь разумнее разделить данные на несколько более узких сравнений или вынести подробности в отдельный формат.

Разделение таблицы часто лучше сложной responsive-магии

Представим таблицу из десяти колонок:

объект + цена + срок + тип + статус + регион + формат + гарантия + поддержка + примечание.

Возможно, пользователь на самом деле решает две задачи:

1. сравнивает условия;
2. проверяет дополнительные характеристики.

Тогда две таблицы могут быть понятнее одной:

Таблица 1. Основные условия

Таблица 2. Дополнительные характеристики

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

Сокращение текста в ячейках может дать больше, чем CSS

Ширину таблицы часто увеличивает не число колонок, а содержание внутри них.

Например, в ячейке находится:

Поддержка осуществляется специалистами компании в стандартном режиме в рабочее время.

Если задача таблицы — сравнить режимы поддержки, это можно сократить до:

Стандартная, в рабочее время

Подробное объяснение остаётся в тексте рядом с таблицей.

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

Не нужно переносить в tooltip основную информацию

Ещё один способ «освободить» мобильную таблицу — заменить часть текста иконками с tooltip.

Для важных данных это слабое решение:

• пользователь перестаёт видеть значения одновременно;
• сравнение требует дополнительных действий;
• hover на touch-устройстве не работает как на desktop;
• смысл иконки может быть неочевидным;
• несколько tooltip подряд превращают чтение в серию открытий.

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

Интерактивные элементы внутри ячеек усложняют мобильный сценарий

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

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

Если нужны, стоит проверить:

• порядок focus;
• понятные названия controls;
• размер и расстояние между touch targets;
• не скрываются ли действия за горизонтальной границей без подсказки;
• можно ли выполнить операцию после увеличения текста.

Responsive table с интерактивностью уже ближе к отдельному data-grid-компоненту, чем к обычной редакционной таблице.

Как выбрать между скроллом, карточками и упрощением

Это не жёсткий алгоритм. Он помогает начать с задачи пользователя, а не с заранее выбранного responsive-паттерна.

Как проверить мобильную таблицу

Сформулировать пользовательскую операцию

Что человек делает: сравнивает колонки, ищет одну строку, просматривает запись или проверяет отдельное значение?

Проверить ширину без уменьшения текста до предела

Ячейки должны оставаться читаемыми. Слишком мелкий текст не является responsive-решением.

Прокрутить таблицу отдельно от страницы

Если выбран horizontal scroll, движение должно быть локальным.

Проверить, сохраняются ли headers

При любом visual transformation должно быть понятно, к какому заголовку относится значение.

Проверить screen reader

Особенно важно после CSS-перестройки табличных элементов.

Увеличить текст

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

Проверить карточный вариант на сравнении

Попробуйте сравнить один и тот же показатель у пяти объектов. Если приходится долго перемещаться между блоками, возможно, таблицу стоило сохранить.

Попробовать удалить одну колонку

Если без неё пользовательская задача не меняется, возможно, она не нужна и на desktop.

Типичные ошибки responsive tables

Практическая схема проектирования мобильной таблицы

1. Определить, зачем данные вообще представлены таблицей.
2. Зафиксировать основную операцию. Сравнение колонок или чтение отдельных строк.
3. Упростить исходную структуру. Убрать лишние поля и разделить разные подтемы.
4. Выбрать responsive-паттерн. Scroll, stacked view или несколько более простых таблиц.
5. Сохранить table semantics. Caption, headers и связи между ячейками.
6. Если используется scroll, ограничить его контейнером таблицы.
7. Если используются карточки, повторить labels и проверить сравнительный сценарий.
8. Не скрывать важные колонки только из-за ширины viewport.
9. Проверить touch, keyboard, zoom и screen reader.
10. Повторить тест на реальных данных. Короткий демонстрационный пример часто ведёт себя проще, чем таблица после наполнения.

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

Главное — сохранить не форму таблицы, а способ работы с данными

Responsive table не обязана выглядеть одинаково на desktop и mobile.

Она должна сохранить то, ради чего таблица появилась:

• сравнение;
• связи между строками и столбцами;
• идентификацию полей;
• доступ ко всем существенным данным;
• понятное чтение на доступной ширине.

Поэтому решение можно свести к трём вопросам:

Что сравнивают? Какие отношения нельзя потерять? Какой формат сохраняет их на узком экране с наименьшими усилиями пользователя?

Если ответ — двумерная таблица, горизонтальный скролл не является ошибкой. Если важнее отдельная строка, карточный формат может быть удобнее. Если ни один вариант не работает, вероятно, нужно менять не CSS, а саму структуру данных.

Источники

Источники проверены 20 августа 2026 года. Использованы материалы W3C Web Accessibility Initiative, MDN Web Docs, U.S. Web Design System, CFPB Design System и Ontario Design System.

• W3C WAI — Tables Tutorial
• W3C WAI — Tables: Tips and Tricks
• W3C WAI — Caption & Summary
• W3C WAI — Understanding SC 1.4.10 Reflow
• MDN Web Docs — <table>: The Table element
• MDN Web Docs — HTML table accessibility
• MDN Web Docs — display: accessibility considerations for tables
• U.S. Web Design System — Table
• CFPB Design System — Tables
• Ontario Design System — Tables