Контентная админка интранета — один раздел вместо трёх и доступность WCAG 2.1 AA

Раньше для рассылки, баннера и статьи у нас было три разные админки с разной логикой. Это была наследственная травма архитектуры. Этой весной мы её закрыли. Заодно прошли WCAG 2.1 AA — не для галочки в тендере, а для команды.

Это короткая практическая статья. Две темы — унификация контентной админки и доступность по стандарту WCAG 2.1 AA. Они объединены не случайно: оба изменения мы делали в одном спринте, и оба важны для команд, которые работают с контентом интранета — internal comms, HR-маркетинг, accessibility-специалисты.

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

Три раздельные админки — почему это болело

Исторически в нашем продукте было три отдельных раздела админки для контента:

• Баннеры — карусель на главной странице портала.
• Страницы — статьи-лонгриды (политики, инструкции, манифесты).
• Новости — лента корпоративных новостей.

Каждая со своей моделью данных, своим редактором, своими полями. На бэкенде — три разных сервиса. На фронте — три разные админ-страницы с разной навигацией. У дизайнера — три разных мокапа.

Что это создавало:

• HR не понимал, где что лежит. «Я хочу опубликовать новость про новый офис — это в Новости или в Страницы? А вот это объявление с картинкой — это Баннер или Страница?» Каждый второй вопрос в саппорт был именно про это.
• Маркетинг дублировал контент. Анонс, который должен был жить и в баннере, и в новостях, нужно было создавать дважды.
• Разработка тратила тройные ресурсы. Каждый раз, когда добавлялась функция — теги, медиа-вложения, версионирование — её нужно было реализовывать в трёх местах.
• Аналитика была фрагментирована. Просмотры, лайки, реакции считались по-разному в трёх системах. Сравнить эффективность форматов было невозможно.

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

Унификация в одной информационной архитектуре

Концепт: «контент» — общая абстракция, у которой есть тип (баннер / страница / новость), но всё остальное — общее.

Что объединили:

• Базовая модель данных. Один объект content_item с обязательными полями (заголовок, тело, обложка, теги, автор, статус публикации) и специализациями для типа (например, у баннера — длительность показа, у страницы — раздел в меню).
• Редактор. Один редактор для всех типов контента. WYSIWYG-блоки, медиа-вложения, ссылки, встраиваемые объекты — всё одинаково. При смене типа контента доступные блоки могут немного отличаться (баннер не нуждается в оглавлении), но базовое ощущение — то же.
• Список и фильтры. Одна страница «Контент» в админке. Фильтры: «Все / Баннеры / Страницы / Новости». Глобальный поиск по всем типам сразу.
• Аналитика. Единая модель: просмотры, реакции, лайки, время чтения. Можно сравнивать эффективность форматов: «новость про релиз vs страница с деталями релиза — что смотрят больше?»
• Теги и медиа-библиотека. Общие на весь портал. Один раз загрузил картинку — используешь в баннере, в странице и в новости.

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

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

Что такое WCAG 2.1 AA на интранете — и почему это не галочка

Параллельно с унификацией мы прошли весь портал по чек-листу WCAG 2.1 уровня AA. Это международный стандарт доступности веб-контента.

Многие вендоры относятся к WCAG как к маркетинговой строчке для тендеров. На самом деле это операционная необходимость. Вот почему.

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

Базовые принципы WCAG 2.1 — четыре столба:

• Воспринимаемость. Контент видим/слышим/читаем для всех. Контраст текста, alt-text для изображений, субтитры для видео.
• Оперируемость. Все элементы можно использовать клавиатурой. Никаких «работает только мышью». Видимая подсветка фокуса, чтобы было понятно, где курсор.
• Понятность. Однозначная навигация, понятные подписи, информативные сообщения об ошибках.
• Надёжность. Совместимость с экранными читалками (NVDA, JAWS, VoiceOver), поддержка стандартных HTML-семантик.

Уровень AA — не самый строгий (есть AAA), но это рабочий минимум для коммерческого продукта в 2026 году. Это и то, что начинают спрашивать в крупных RFI/RFP, и то, что просто корректно с точки зрения доступности.

Что мы конкретно подкрутили:

• Контраст. Все тексты теперь имеют контраст к фону ≥ 4.5:1 (для крупного текста ≥ 3:1).
• Цвет — не единственный сигнал. Если статус помечается красным — рядом есть текст «Ошибка» или иконка. Людям с нарушением цветовосприятия всё равно понятно.
• Подсветка фокуса. Видимая обводка на любом элементе, который можно фокусировать клавиатурой. Не убрана через outline: none.
• Alt-text. Все значимые изображения имеют осмысленный alt-text. Декоративные — пустой alt="".
• Иерархия заголовков. На каждой странице один h1, дальше h2 → h3 без скачков. Экранная читалка навигируется по этой иерархии — без неё страница для незрячего пользователя превращается в кашу.

Иерархия основных (primary) кнопок

Деталь, которая на первый взгляд незначительна, но видится сразу UX-аудитору и сильно влияет на «ощущение продукта».

TOOLBAR h-10 (40 px) Создать Компактная кнопка в верхней панели

EMPTY-STATE h-11 (44 px) Создать первую Крупнее — подталкивает к действию на пустой странице

ONBOARDING SEC. h-10 outline Позже Не забивает primary, но остаётся доступной

Три размера кнопок для трёх разных контекстов:

• Кнопка в верхней панели (toolbar primary) — h-10 (40px). На странице, где уже есть контент. Кнопка «Создать» в правом верхнем углу. Не должна доминировать над данными.
• Кнопка пустого состояния (empty-state primary) — h-11 (44px). На странице, где ничего ещё нет. Кнопка «Создать первый пост» в центре. Чуть крупнее — намеренно подталкивает к действию, чтобы пользователь не залип на пустой странице.
• Вторичная кнопка обучения (onboarding secondary) — h-10, outline. Когда нужно дать опцию «не сейчас», но не закрыть путь окончательно. Кнопка «Позже», «Пропустить шаг».

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

И самое главное — иерархия должна быть последовательной по всему продукту. Если на одной странице кнопка пустого состояния h-11, а на другой h-10 — это уже путаница. У нас зафиксировано это в design system, и code-review не пропускает кнопку, которая не соответствует контексту.

Чек-лист accessibility перед каждым релизом

Это не для тендеров. Это для нашей команды. Каждая функция перед merge проходит 8 пунктов:

1. Контраст текста ≥ 4.5:1 (для обычного текста). Проверяется автоматически линтером.
2. Контраст крупного текста ≥ 3:1 (заголовки и бейджи).
3. Все интерактивные элементы доступны Tab. Нельзя забыть button или забить на навигацию с клавиатуры.
4. Видимое состояние фокуса. Не outline: none без замены. Каждый фокус виден.
5. Alt-text на всех значимых изображениях. Декоративные — пустой alt="".
6. Подписи на всех полях форм. Не только placeholder. <label> или aria-label.
7. Иерархия заголовков. Один h1, дальше без скачков уровней.
8. Тестирование с экранной читалкой. NVDA на Windows, VoiceOver на Mac. Минимум — пройти основной поток.

Это не «галочки на тендер». Это базовая дисциплина продукт-команды. Каждый из этих 8 пунктов экономит десятки часов поддержки в будущем — и делает продукт читаемым для тех людей в компаниях клиентов, кто сейчас (молча) пользуется им через экранную читалку.

Главное

Контентная админка теперь единая: один раздел, фильтр по типу, общий редактор, общая аналитика. Это и для нас сэкономило тройные ресурсы на разработку, и для клиентов сократило вопросы в саппорт на 80%.

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

Иерархия основных кнопок и 8-пунктовый чек-лист accessibility — кажется, мелочи. Но именно эти «мелочи» отличают зрелый продукт от MVP, который выкатили и больше не трогали.

На следующей неделе — про главную страницу портала. Почему мы убрали блок «Требует внимания» и поставили туда AI-чат, и что 6 итераций редизайна нам показали.

Если хотите чек-лист accessibility для интранета на одну страницу — он по ссылке в карточке. Без регистрации.

---

Если у вас в команде есть accessibility-специалист, и он хочет посмотреть, как мы реализуем WCAG в реальном продукте — напишите, проведём 30-минутный технический разговор.