Мобильная версия длинной статьи: как сохранить структуру и читаемость

Мобильная версия — это не уменьшенный desktop

На широком экране дизайнер может одновременно показать основной текст, содержание, справочный блок и дополнительные элементы. На телефоне они физически не помещаются рядом.

Есть два пути.

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

Второй — перестроить блоки под доступную ширину:

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

W3C в разборе требования Reflow прямо отмечает, что responsive web design может изменять расположение секций и переносить их в другое место, если содержание и функциональность остаются доступными.

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

WCAG 2.2 требует, чтобы вертикально прокручиваемый контент мог быть представлен при ширине, эквивалентной 320 CSS px, без потери информации или функций и без обязательной прокрутки сразу в двух направлениях. Исключения предусмотрены для элементов, которым двумерная компоновка необходима по смыслу.

Для длинной статьи это даёт практическую модель:

основной текст → одна доступная ширина → вертикальная прокрутка.

Пользователь не должен читать каждую строку так:

вправо → обратно влево → вниз
вправо → обратно влево → вниз

Такой режим быстро сбивает место чтения.

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

Сначала нужно проверить порядок блоков после перестройки

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

Например:

┌──────────────────────┬────────────────────┐
│ Основной текст       │ Справочный блок    │
│                      │                    │
│ Продолжение текста   │ Ссылки             │
└──────────────────────┴────────────────────┘

После перехода к одной колонке нужно решить, где окажется правая часть:

Основной текст
↓
Справочный блок
↓
Продолжение текста
↓
Ссылки

или:

Основной текст
↓
Продолжение текста
↓
Справочный блок
↓
Ссылки

Это не только вопрос внешнего вида. От позиции зависит смысл.

W3C отдельно требует сохранять meaningful sequence, если последовательность влияет на понимание. Поэтому перестановка через CSS не должна создавать ситуацию, когда визуальный порядок и логика чтения расходятся. При использовании Flexbox W3C также предупреждает, что свойства переупорядочивания могут разорвать связь между визуальным порядком и клавиатурным или DOM-порядком.

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

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

Чтобы структура сохранялась, на мобильном продолжают работать:

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

То есть responsive layout не отменяет визуальную иерархию текстовой страницы. Он заставляет проверить, работает ли она без преимущества большого экрана.

Важная информация не должна уходить слишком далеко вниз

На телефоне один крупный hero-блок способен занять почти весь первый экран. Если после него идут изображение, служебная информация и длинное вступление, основной ответ появляется значительно позже, чем на desktop.

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

Для длинной статьи стоит проверить:

• видно ли из начала страницы, о чём материал;
• не вытесняет ли декоративное изображение основной ответ;
• не занимает ли метаинформация непропорционально много места;
• не превратился ли desktop-первый экран в три мобильных экрана до первого содержательного блока.

Мобильный дизайн часто требует не уменьшить hero, а пересмотреть его информационную плотность.

Типографика должна адаптироваться без потери структуры

Большой desktop-H1 нельзя просто оставить прежнего размера, если на узком экране каждое слово занимает отдельную строку. Но уменьшать все заголовки до почти одинакового размера тоже не стоит.

Задача — сохранить отношения:

Responsive typography поэтому лучше строить как систему относительных уровней, а не как набор отдельных мобильных размеров.

Длинные строки и неразрывный контент могут сломать всю страницу

Даже если layout построен правильно, горизонтальный overflow иногда создаёт один элемент:

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

В результате горизонтальная прокрутка появляется уже у всей страницы.

Поэтому мобильную проверку стоит проводить не только по общему контейнеру, но и по самым сложным элементам внутри статьи.

Обычный текст должен переноситься. Изображения должны вписываться в доступную ширину. Для code block может быть оправдан собственный горизонтальный scroll, если перенос разрушает содержимое. Главное, чтобы такой компонент не заставлял прокручивать по горизонтали весь документ.

Изображение должно уменьшаться вместе с контейнером

Большая иллюстрация, которая на desktop занимает 900 px, на мобильном обычно должна вписываться в ширину статьи.

Для простых изображений это означает:

ширина не больше доступного контейнера + сохранение пропорций.

Но после уменьшения появляется другой вопрос: остаётся ли картинка читаемой.

Схема с двадцатью подписями может технически поместиться в 320–360 px и при этом перестать выполнять свою функцию. Тогда нужны другие решения:

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

Responsive image — это не только отсутствие overflow. Пользователь должен ещё суметь прочитать содержание изображения.

Не каждый desktop-блок нужно сохранять в прежней форме

На широком экране хорошо работают:

• карточки в несколько колонок;
• сравнения side-by-side;
• боковые примечания;
• параллельные колонки «до / после»;
• галереи;
• широкие схемы.

На мобильном важнее сохранить отношение между элементами, чем их прежнее расположение.

Например, три карточки:

[ A ] [ B ] [ C ]

могут стать:

[ A ]
  ↓
[ B ]
  ↓
[ C ]

Если порядок A → B → C имеет смысл, он должен быть определён заранее. Если все три карточки равнозначны, можно выбрать порядок по пользовательскому приоритету.

Оглавление на мобильном требует отдельного сценария

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

Desktop-sidebar часто превращают в:

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

Здесь важно не сохранить внешний вид navigation, а сохранить возможность быстро выбрать раздел.

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

Sticky-элементы особенно опасны на маленькой высоте viewport

На desktop фиксированный header высотой 64 px может почти не мешать. На телефоне к нему иногда добавляются:

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

Вместе они уменьшают реальную область чтения.

W3C в рекомендациях к Reflow отдельно упоминает возможность отключать fixed или sticky headers и footers при узком представлении как полезную технику.

Поэтому мобильный вариант стоит проверять по фактически оставшейся высоте контента, а не только по ширине устройства.

Интерактивные элементы нужно проверять пальцем, а не курсором

Курсор позволяет точно попасть в маленькую иконку. Палец работает иначе.

WCAG 2.2 в критерии Target Size (Minimum) устанавливает для pointer target базовый минимум 24 × 24 CSS px, если не действует исключение. Для enhanced-уровня используется более крупная цель 44 × 44 CSS px.

Для длинной статьи это особенно относится к:

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

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

Ссылка внутри абзаца и отдельная кнопка — разные случаи

Требование к target size содержит исключения, в том числе для inline-ссылок внутри предложений и блоков текста. Это важно не перепутать с отдельными интерфейсными контролами.

Обычная ссылка в абзаце:

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

и отдельная кнопка:

Открыть содержание

выполняют разные роли.

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

Таблицы нельзя просто уменьшить до ширины экрана

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

На мобильном стоит определить:

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

Это самостоятельная UX-задача. Её подробно разберём в статье о проектировании таблиц для мобильных экранов.

Карточки вместо таблицы подходят не всегда

На мобильном часто предлагают универсальное решение:

«Превратите каждую строку таблицы в карточку».

Иногда это удобно. Но при таком преобразовании пользователь может потерять возможность быстро сравнивать одинаковые поля нескольких объектов.

Например, таблица:

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

Поэтому responsive transformation оценивают не по принципу «всё помещается», а по тому, сохранилась ли исходная задача пользователя.

Скрытие второстепенного контента требует осторожности

Ещё один популярный способ адаптации — убрать часть элементов на маленьком экране.

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

WCAG Reflow прямо требует отсутствия потери информации и функциональности при изменении представления.

Поэтому перед display: none полезно определить роль элемента:

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

Сворачиваемые блоки подходят для подробностей, но не для всего подряд

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

Сворачивание хорошо работает для:

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

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

Экономия вертикального пространства не должна увеличивать стоимость доступа к каждой мысли.

Ориентация экрана не должна быть обязательной без необходимости

Если статья читается только после поворота телефона в landscape, адаптация решена слабо.

WCAG 2.2 требует не ограничивать представление одной ориентацией, если конкретная ориентация не является существенной для содержания или функции.

Для обычной текстовой статьи portrait должен оставаться полноценным режимом.

Отдельный сложный элемент может быть удобнее в landscape, но это не должно превращать поворот устройства в обязательное условие доступа ко всему документу.

Мобильную версию нужно проверять не на одном размере

Название «mobile» объединяет множество viewport. Телефоны отличаются шириной, высотой, плотностью интерфейса браузера и настройками пользователя.

Кроме того, требования Reflow важны не только для смартфонов. Узкое представление возникает и когда пользователь увеличивает страницу на desktop.

Поэтому тестирование лучше строить не вокруг одной модели устройства, а вокруг поведения layout:

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

Breakpoint должен соответствовать потребности композиции, а не только названию конкретного телефона.

Проверка мобильной статьи должна включать увеличение текста

Даже хороший layout может сломаться, если пользователь увеличивает размер текста или меняет text spacing.

Нужно проверить, не происходит ли после этого:

• обрезание строк;
• перекрытие текста и иконок;
• исчезновение кнопок;
• слияние соседних элементов;
• потеря подписей;
• выход фиксированных блоков за viewport.

Responsive design должен выдерживать не только уменьшение экрана, но и изменение условий чтения внутри него.

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

Пройти страницу только вертикальной прокруткой

Основной контент не должен требовать постоянного движения вправо и влево.

Проверить линейный порядок

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

Посмотреть первые экраны

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

Проверить каждый сложный компонент

Таблица, code block, график, изображение, embed и navigation требуют отдельных сценариев.

Пройти интерактивные элементы пальцем

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

Увеличить текст и изменить spacing

Контент не должен обрезаться или становиться недоступным.

Проверить portrait и landscape

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

Проверить статью без части декоративных элементов

Если смысл исчезает вместе с desktop-композицией, структура слишком зависит от визуального расположения.

Типичные ошибки мобильной версии длинного материала

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

1. Определить основной порядок содержания. Он должен сохранять смысл после линейной перестройки.
2. Перевести многоколоночные области в подходящую мобильную структуру. Не обязательно сохранять исходную геометрию.
3. Проверить reflow основного текста. Чтение не должно требовать горизонтального движения всей страницы.
4. Сохранить визуальные уровни. H1, H2, H3, основной и справочный текст должны оставаться различимыми.
5. Пересмотреть начало страницы. Важная информация не должна уходить далеко вниз из-за крупного desktop-декора.
6. Адаптировать navigation. Sidebar, оглавление и sticky-компоненты получают мобильный сценарий.
7. Проверить сложные элементы отдельно. Изображения, code, таблицы, графики и embeds.
8. Проверить touch interaction. Отдельные controls должны иметь удобные области взаимодействия.
9. Не скрывать смысловой контент только ради компактности.
10. Проверить разные ширины, увеличение текста и обе ориентации.

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

Что должна сохранить мобильная версия

Цель адаптации не в том, чтобы мобильная страница выглядела как уменьшенный desktop.

Она должна сохранить:

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

Поэтому полезнее мыслить не формулой:

desktop → уменьшение.

А другой:

смысловая структура → reflow → одноколоночный приоритет → touch interaction → проверка сложных элементов.

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

Источники

Источники проверены 20 августа 2026 года. Использованы актуальные материалы W3C Web Accessibility Initiative.

• W3C — Web Content Accessibility Guidelines (WCAG) 2.2
• W3C WAI — Understanding SC 1.4.10 Reflow
• W3C WAI — G57: Ordering the content in a meaningful sequence
• W3C WAI — C31: Using CSS Flexbox to reflow content
• W3C WAI — Mobile Accessibility: How WCAG and Other W3C/WAI Guidelines Apply to Mobile
• W3C — WCAG 2.2, SC 2.5.8 Target Size (Minimum)
• W3C WAI — Understanding SC 2.5.5 Target Size (Enhanced)
• W3C — WCAG 2.2, SC 1.3.4 Orientation
• W3C WAI — Understanding SC 1.4.12 Text Spacing