Таблица характеристик на телефоне: сравнить товар без потери условий

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

Таблица характеристик на телефоне сохраняет смысл, если у каждой ячейки остаются программно связанные заголовки строки и столбца, единица стоит рядом с числом, пустота помечена как «нет данных» или «неприменимо», а условие видно у цены. Прокручивается контейнер таблицы, а не страница; закрепление осей помогает, но не заменяет корректную разметку.

Сравнение товаров на телефоне ломается не в момент, когда человек листает карточки, а когда он пытается удержать в голове два-три условия одновременно. Условный пример: покупатель выбирает аккумулятор для инструмента, открывает таблицу характеристик на смартфоне и видит три колонки, из которых на экране помещается одна с половиной. Он листает вправо, теряет строку «ёмкость», возвращается, а потом всё равно не понимает, к какой модели относится цифра 4,0. Задача этой статьи — не переделать сайт целиком, а сделать так, чтобы таблица сравнения на узком экране сохраняла смысл: параметр, единицу измерения и привязку к товару.

Механизм здесь простой и потому коварный. Таблица — это двумерная структура, где смысл ячейки задаётся пересечением строки и столбца. На широком экране оба заголовка видны одновременно, и глаз связывает их автоматически. На телефоне горизонтальная прокрутка разрывает эту связь: уезжает заголовок столбца, и ячейка повисает без контекста. Дальше начинается цепочка мелких потерь — единицы измерения отрываются от чисел, пустые ячейки читаются как «ноль», а скрытое условие (например, «цена при самовывозе») исчезает из поля зрения вместе с шапкой. Ниже — методика, как это удержать, с двумя разными разборами, формой рабочего объекта и проверками.

Почему одна и та же цифра читается по-разному в зависимости от того, что уехало за край

Начнём с того, что происходит с человеком, когда он теряет заголовок. Возьмём условную таблицу из четырёх моделей и шести параметров: напряжение, ёмкость, вес, гарантия, цена, наличие. На десктопе это сетка, где шапка закреплена сверху и всё читается построчно. На телефоне ширина экрана — примерно 360–400 CSS-пикселей, а таблица требует условно 700–900. Значит, одновременно видно меньше половины.

Теперь представьте, что человек смотрит на ячейку «4,0» и не помнит, это ампер-часы или килограммы. Формально информация на экране есть, фактически — её нет. Это и есть узкий интент статьи: не «сделать красиво», а не дать параметру потерять адрес. Проблема не в дизайне как таковом, а в разрыве между значением и его заголовком.

Есть соблазн решить это «резиновой» вёрсткой: сжать шрифт, уменьшить отступы, впихнуть всё в экран. На практике это обменивает одну проблему на другую — читаемость. Мелкий шрифт и слипшиеся колонки не помогают, а маскируют потерю контекста. Поэтому дальше речь о структурных приёмах, а не о косметике.

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

Горизонтальный скролл внутри таблицы — это не то же самое, что скролл всей страницы

Ключевое различие, которое часто упускают: если таблица шире экрана и вы даёте ей прокручиваться, важно, чтобы прокручивался именно контейнер таблицы, а не вся страница целиком. Иначе человек, пытаясь сдвинуть колонки, случайно уводит вбок весь макет, и навигация начинает «ездить». По документации MDN по свойству overflow горизонтальная прокрутка задаётся на конкретном контейнере, и это осознанное решение, а не побочный эффект (MDN: CSS overflow).

Практический вывод: таблицу оборачивают в блок с собственной горизонтальной прокруткой, а саму страницу держат в вертикальном потоке. Тогда жест «сдвинуть таблицу» не конфликтует с жестом «пролистать страницу». Это первый технический слой, но он не решает главную проблему — потерю заголовков.

Второй слой — закрепление. Если шапка таблицы остаётся на месте при горизонтальном сдвиге, а первый столбец (названия параметров) закреплён при вертикальном, человек хотя бы не теряет оси координат. Это не отменяет прокрутку, но возвращает ячейке адрес: видно и строку, и столбец. Здесь важно не переусердствовать — закреплённые области не должны занимать половину и без того узкого экрана.

Что говорит доступность: заголовки ячеек — это не украшение, а смысл таблицы

Есть более фундаментальный слой, чем визуальный. Таблица характеристик — это таблица данных, и у неё должны быть программно связанные заголовки строк и столбцов. Об этом подробно в руководстве W3C по таблицам (W3C: Tables Tutorial). Смысл в том, что связь «ячейка — её заголовок» должна существовать не только для глаза, но и для вспомогательных технологий.

Почему это важно именно для мобильного сравнения? Потому что экранный диктор читает не картинку, а структуру. Если ячейка не связана с заголовком, пользователь скринридера слышит «4,0» без пояснения — ровно та же потеря контекста, что и у зрячего человека, только без возможности вернуться взглядом. При корректной разметке экранный диктор связывает ячейку с заголовками строки и столбца и может озвучить параметр и товар вместе со значением.

Отсюда практическое правило: прежде чем думать о том, как таблица выглядит на телефоне, стоит убедиться, что она корректно размечена как таблица данных с заголовками. Визуальные приёмы (закрепление, прокрутка) — это надстройка над корректной структурой, а не замена ей. Если структура сломана, никакая вёрстка не вернёт смысл.

Единицы измерения нельзя отрывать от чисел — и это отдельная ловушка

Теперь про длинные единицы. «4,0 А·ч» на широком экране читается целиком. На узком колонка сжимается, и единица либо переносится на новую строку, либо обрезается, либо уезжает за край вместе с числом. В результате человек видит «4,0» и отдельно где-то «А·ч», и связь между ними держится только на догадке.

Рекомендация здесь такая: единицу измерения держат в той же ячейке, что и число, и не позволяют ей отрываться при сжатии. Если места совсем мало, лучше перенести «число + единица» на две строки внутри одной ячейки, чем разнести их по разным местам. Это мелочь, которая на практике решает половину путаницы.

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

Когда в ячейке нет данных: пустота не должна читаться как ноль

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

Решение — явная пометка «нет данных» вместо пустоты, причём в той же ячейке, где ожидалось значение. Это не украшательство: пометка отличает «мы не знаем» от «значение равно нулю». На узком экране такая пометка должна быть короткой, но однозначной, и не должна выглядеть как обычное значение параметра.

Есть и второй подвид пустоты — «неприменимо». Условно, у механического инструмента нет параметра «ёмкость аккумулятора», потому что аккумулятора нет. Это не «нет данных» и не «ноль», это «не относится к товару». Смешивать эти три состояния в одной пустой ячейке — верный способ запутать сравнение. Различать их стоит на уровне данных, а не на уровне вёрстки.

Скрытое условие: цена, наличие и оговорки, которые уезжают вместе с шапкой

Самая коварная потеря — не параметр, а условие. Условно: в шапке таблицы или над ней стоит пометка «цены указаны при самовывозе» или «наличие на складе в Москве». На десктопе эта оговорка видна вместе с таблицей. На телефоне человек прокручивает вниз к цифрам, оговорка остаётся наверху, и цена читается как безусловная.

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

Здесь стоит быть аккуратным: не всякое условие нужно дублировать. Речь о тех, что меняют смысл числа — цена, срок, регион, комплектация. Если оговорка не влияет на сравнение, её можно оставить в общем тексте. Но если без неё цифра вводит в заблуждение, она обязана быть рядом.

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

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

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

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

Сравнение характеристик на телефоне: что именно описываем, прежде чем верстать

Чтобы не спорить о вёрстке на уровне вкуса, полезно зафиксировать рабочий объект — описание таблицы, с которым можно работать. Ниже условная форма; значения в ней — пример заполнения, а не реальные данные.

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

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

Разбор первый: четыре модели, шесть параметров и потерянная шапка

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

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

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

Дополнительно стоит ограничить число параметров, показываемых сразу. Условно: три ключевых параметра видны без сдвига, остальные — по кнопке «показать все». Это не прячет информацию, а снижает нагрузку: человек сначала сравнивает главное, потом углубляется. Приоритет берётся из формы рабочего объекта, а не назначается на глаз.

И последнее в этом эпизоде — единицы. Если «4,0 А·ч» и «4,0 кг» стоят в соседних строках и при сдвиге единицы уезжают, числа становятся неразличимы. Поэтому единицу держат в ячейке рядом с числом, даже если из-за этого ячейка станет на строку выше. Лучше две строки в одной ячейке, чем число без единицы.

Разбор второй: длинные единицы, разные величины и «нет данных» в одной таблице

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

На широком экране это выглядит как обычная таблица, и человек сам пытается сообразить, что 20 А·ч и 240 Вт·ч — это про разное. На телефоне, где видно по одной колонке, эта задача становится почти нерешаемой: он видит «20» и «240» и не понимает, сравнимы ли они. Ошибка здесь не в вёрстке, а в том, что таблица смешала несравнимые величины.

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

Теперь про пустоты. У одного накопителя не указан вес — ставим «нет данных», а не оставляем пусто. У другого нет гарантии — тоже «нет данных», если гарантия в принципе применима. А если параметр к товару не относится (условно, «тип разъёма» у модели без разъёма), ставим «неприменимо». Три разных состояния — три разных пометки. На узком экране эти пометки должны быть короткими, но не сливаться с числами.

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

Сравнение характеристик на телефоне на экране сотрудника

Отдельная история — не покупатель, а сотрудник, который эту таблицу наполняет. Если данные вводятся вручную и без правил, таблица быстро рассинхронизируется: где-то ампер-часы, где-то ватт-часы, где-то пусто, где-то «0». Поэтому интерфейс для сотрудника — часть задачи, а не побочная деталь.

Разумный минимум: поле единицы измерения отдельно от поля значения, обязательная пометка состояния (значение / нет данных / неприменимо) и предупреждение, если единица не совпадает с выбранной для параметра. Условно: редактор выбрал для параметра «ёмкость» единицу «А·ч», а вводит значение в «Вт·ч» — интерфейс просит подтвердить или пересчитать. Это не даёт ошибке дойти до покупателя.

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

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

Сравнение характеристик на телефоне: когда таблица не помещается и когда её вообще не стоит делать таблицей

Есть случаи, где стандартные приёмы не работают. Первый — очень много параметров. Условно, двадцать строк и восемь товаров. Даже с закреплением это превращается в лабиринт. Здесь честнее показать не всё сразу, а дать выбрать 2–3 параметра для сравнения. Тогда таблица остаётся обозримой, а остальное доступно по запросу.

Второй случай — параметры, которые не сводятся к числу. Условно, «тип материала» или «способ крепления». Их нельзя сравнивать по величине, только по совпадению. Для таких параметров таблица работает иначе: важно не «больше-меньше», а «совпадает-нет». На узком экране это стоит показывать текстом, а не пытаться втиснуть в узкую колонку.

Третий случай — товары с принципиально разным набором параметров. Условно, сравнение аккумуляторного и сетевого инструмента: у одного есть ёмкость, у другого нет. Если таких различий много, таблица начинает пестреть «неприменимо», и сравнение теряет смысл. Здесь разумнее развести товары по группам и сравнивать внутри группы, а не через силу сводить несводимое.

Четвёртый случай — очень длинные значения. Условно, наименование комплектации на несколько слов. В узкой колонке оно переносится на много строк и растягивает таблицу по вертикали. Решение — сокращать до ключевого слова с раскрытием по нажатию, но так, чтобы сокращение было однозначным. Если сокращение допускает двойное чтение, лучше оставить полное.

Как проверить результат: чек-лист без обещаний

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

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

Отдельно стоит проверить таблицу на медленном соединении. Если закрепление и раскрытие реализованы скриптами, при медленной загрузке таблица может на секунду показаться в «сыром» виде — без закрепления и с пустыми ячейками. Это стоит увидеть заранее, чтобы не ловить жалобы после запуска.

Практикум: собрать одну таблицу сравнения для трёх моделей и проверить её на телефоне

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

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

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

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

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

Смежный вопрос разобран отдельно: Дизайн-система сайта: почему библиотека кнопок ещё не система.