Разработка государственного портала под ключ: ЕСИА, WCAG, безопасность

Разработка портала для государственной организации

Госорганы часто сталкиваются с проблемой: сайт не проходит проверку доступности, данные граждан хранятся с нарушениями, а поиск по документам не находит нужных постановлений. Мы специализируемся на таких проектах и знаем, как избежать этих ошибок. Наш опыт — более десяти лет и десятки реализованных порталов для госорганизаций России и Беларуси. Разбираем нормативную базу, требования WCAG, интеграцию с ЕСИА и защиту персональных данных.

Законодательная база

В Беларуси требования определяет Закон «Об электронном документе и электронной цифровой подписи», постановления о государственных информационных ресурсах. В России — ФЗ-149 «Об информации», ФЗ-152 «О персональных данных», постановление №477 (действующая редакция). Перечень обязательных разделов для официальных сайтов органов власти: сведения об органе, нормативные документы, госуслуги, результаты проверок, антикоррупционные материалы. Учитываем все нормы на этапе проектирования, чтобы избежать переделок после аудита.

Почему WCAG 2.1 AA обязателен для госсайтов?

Это не рекомендация, а закон. ГОСТ Р 52872 ссылается на WCAG 2.1. Проверка проводится автоматически (axe-core, Lighthouse) и вручную. Типичные проблемы — отсутствие меток у форм и неверная структура таблиц. Пример правильной формы поиска:

<!-- Неправильно: форма поиска без label -->
<input type="search" placeholder="Поиск по сайту">

<!-- Правильно -->
<label for="site-search" class="sr-only">Поиск по сайту</label>
<input id="site-search" type="search" placeholder="Поиск по сайту"
       role="searchbox" aria-label="Поиск по сайту">

<!-- Правильная таблица с заголовками -->
<table>
  <caption>Контакты руководства</caption>
  <thead>
    <tr>
      <th scope="col">ФИО</th>
      <th scope="col">Должность</th>
      <th scope="col">Телефон</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Иванов Иван Иванович</td>
      <td>Начальник отдела</td>
      <td><a href="tel:+375170000000">+375 17 000-00-00</a></td>
    </tr>
  </tbody>
</table>

Все PDF-документы должны быть tagged PDF с логической структурой и alt-текстами. Проверяем каждый элемент на соответствие WCAG. Получите консультацию по вашему проекту, чтобы избежать этих ошибок.

Как интеграция с ЕСИА улучшает пользовательский опыт?

Для личных кабинетов граждан обязательна интеграция с государственной системой идентификации. В Беларуси — ЕСИА или ID-карта, в России — портал Госуслуг через SAML 2.0 или OpenID Connect. Пример подключения ЕСИА через OAuth 2.0 (Laravel):

// Laravel: редирект на авторизацию через ЕСИА
public function redirectToEsia()
{
    $params = [
        'client_id'     => config('esia.client_id'),
        'response_type' => 'code',
        'scope'         => 'openid fullname email mobile snils',
        'redirect_uri'  => route('esia.callback'),
        'state'         => csrf_token(),
        'timestamp'     => now()->format('Y.m.d H:i:s O'),
        'access_type'   => 'online',
    ];

    // Подпись запроса через PKCS#7 (обязательно для ЕСИА)
    $params['client_secret'] = $this->signRequest($params);

    return redirect(config('esia.auth_url') . '?' . http_build_query($params));
}

Запросы подписываются квалифицированным сертификатом — его нужно получать в удостоверяющем центре. Интеграция повышает безопасность входа и позволяет выгружать данные из госсистем.

Защита персональных данных и выбор хостинга

ФЗ-152 требует хранить персональные данные граждан на серверах в РФ. Аналогичные законы действуют в Беларуси. Выбираем хостинг только из локальных дата-центров. Обязательные заголовки безопасности:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'nonce-{NONCE}'; style-src 'self' 'unsafe-inline'" always;
add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always;

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

Поиск по документам: Elasticsearch vs PostgreSQL

Госорганы накапливают тысячи документов. Простой SQL-поиск плохо справляется с русской морфологией. Мы используем два подхода. Для архивов от 100k документов Elasticsearch быстрее PostgreSQL в 4 раза по скорости поиска.

Пример полнотекстового индекса в PostgreSQL:

CREATE INDEX docs_fts_idx ON documents
  USING GIN (to_tsvector('russian', title || ' ' || content));

SELECT id, title,
  ts_rank(to_tsvector('russian', title || ' ' || content), query) AS rank
FROM documents, to_tsquery('russian', 'приватизация & жилье') query
WHERE to_tsvector('russian', title || ' ' || content) @@ query
ORDER BY rank DESC
LIMIT 20;

Для архивов от 100k документов ставим Elasticsearch с настройкой русской морфологии. Используем плагин analysis-morphology и задаём анализатор в настройках индекса.

Версионирование и архив нормативных документов

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

CREATE TABLE document_revisions (
  id            BIGSERIAL PRIMARY KEY,
  document_id   BIGINT REFERENCES documents(id),
  content       TEXT NOT NULL,
  revision_note TEXT,
  created_by    BIGINT REFERENCES users(id),
  created_at    TIMESTAMPTZ DEFAULT NOW(),
  effective_from DATE,
  effective_to   DATE
);

Многоязычность и производительность

Для органов, работающих с национальными меньшинствами, портал поддерживает несколько языков. hreflang в head, отдельные URL (/ru/, /be/, /en/), localStorage для сохранения языка. По SLA доступность должна быть 99.5% и выше — резервируем сервера, ставим мониторинг с алертингом.

Что входит в работу?

• Аналитика требований и нормативной базы
• Проектирование архитектуры (БД, инфраструктура, интеграции)
• Дизайн и вёрстка с учётом WCAG 2.1 AA (вёрстка по ГОСТ)
• Разработка бэкенда на Laravel / Django
• Интеграция с ЕСИА / Госуслугами
• Полнотекстовый поиск (Elasticsearch или PostgreSQL)
• Тестирование (a11y, нагрузка, безопасность)
• Развёртывание на серверах заказчика
• Документация и обучение сотрудников
• Гарантийная поддержка 6 месяцев

Сроки

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

Доступность сайтов: WCAG, скринриндеры, клавиатурная навигация

На сайте крупного банка кнопка «Подать заявку» в разметке была <div class="btn" onclick="...">. Скринридер NVDA её не анонсировал, Tab пропускал, Enter не срабатывал. Для тысяч незрячих пользователей этот банк просто не существовал как онлайн-сервис. Мы видим такие проблемы каждый день в десятках проектов — и разработка доступных сайтов по стандарту WCAG 2.2 AA становится единственным способом избежать дискриминации и юридических рисков. Штрафы за недоступность для юрлиц достигают 300 000 ₽, а судебные иски — миллионы.

В этой карточке — как мы делаем веб-доступность a11y работающей, на реальных кейсах, с конкретным стеком и цифрами. Без общих фраз.

Почему семантическая разметка — основа веб-доступности a11y?

Большинство проблем доступности решается правильным HTML, а не дополнительными ARIA-атрибутами. <button> вместо <div onclick>, <nav> вместо <div class="navigation">, <h1>–<h6> в правильной иерархии, <label for="field-id"> вместо <div class="label">. Это базовый уровень, но на практике каждая вторая форма в российских интернет-магазинах не имеет корректных <label>.

ARIA нужна там, где нативный HTML не справляется: кастомные компоненты — выпадающие меню, тултипы, модальные окна, табы, accordion. И вот тут начинается сложность.

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

• role="combobox" на инпуте
• aria-expanded="true/false" при открытии/закрытии
• aria-controls="listbox-id" указывает на список
• aria-activedescendant — ID текущего выбранного элемента
• role="option" и aria-selected на каждом варианте

Это не теория, это то, что тестируется скринридером. NVDA + Chrome или VoiceOver + Safari — обязательная часть QA.

<div role="combobox" aria-expanded="false" aria-controls="listbox-1" aria-activedescendant="" tabindex="0">
  <label for="input-1">Выберите город</label>
  <input id="input-1" type="text" role="combobox" aria-autocomplete="list" />
  <ul id="listbox-1" role="listbox" aria-label="Города">
    <li role="option" aria-selected="false" id="opt-1">Москва</li>
    <li role="option" aria-selected="false" id="opt-2">Санкт-Петербург</li>
  </ul>
</div>

Стоимость исправления одного нарушения уровня A — от 5 000 до 15 000 ₽ в зависимости от сложности. Внедрение a11y с этапа проектирования сокращает бюджет на рефакторинг в 2–3 раза по сравнению с доработкой готового сайта.

Как правильно построить клавиатурную навигацию?

Tab-порядок должен совпадать с визуальным порядком элементов. Если в HTML кнопка «Отмена» стоит перед «Подтвердить», но CSS их меняет местами — пользователь клавиатуры в замешательстве.

Focus trap в модальных окнах. Когда модалка открывается, Tab должен циклиться только внутри неё. При закрытии — возврат фокуса на элемент, который открыл модалку. Без этого пользователь после закрытия оказывается в начале страницы.

tabindex="-1" — элемент не попадает в Tab-последовательность, но может получить фокус программно. Используется для элементов, которые получают фокус через JavaScript (заголовки секций после навигации по якорям).

tabindex="1" и выше — почти всегда ошибка. Явный порядок ломает естественный и создаёт непредсказуемое поведение. Управляйте порядком через DOM, не через tabindex.

Skip links — ссылка «Перейти к содержимому», скрытая визуально, видимая при Tab. Позволяет пользователям скринридеров пропустить повторяющуюся навигацию.

Цвет и контраст: требования и частые нарушения

WCAG 2.2 AA требует контраст 4.5:1 для обычного текста, 3:1 для крупного (18px+ или 14px+ bold). AAA требует 7:1 и 4.5:1.

Самые частые нарушения: серый placeholder в инпутах (#999 на белом = 2.9:1), светло-серый secondary текст, белый текст на пастельном фоне.

Цвет не должен быть единственным индикатором: «поля обязательные выделены красным» без звёздочки — нарушение для людей с цветовой слепотой.

Инструменты проверки: axe DevTools, WAVE, Accessibility Inspector в Chrome DevTools. axe-core интегрируется в Playwright-тесты: автоматическая проверка на 80+ правил при каждом деплое. Ручное тестирование находит примерно на 60% больше ошибок, чем автоматическое.

Медиаконтент и динамика: что важно?

Изображения без alt — частый базовый провал. alt должен быть смысловым: не alt="image_123.jpg", а описание содержимого, релевантное контексту. Декоративные изображения — alt="" (пустой, не отсутствующий атрибут).

Видео должно иметь субтитры. YouTube автосубтитры — не стандарт, они ошибаются. WebVTT-файлы с корректными субтитрами для всего образовательного и маркетингового видеоконтента.

Анимации — проблема для пользователей с вестибулярными расстройствами. @media (prefers-reduced-motion: reduce) — медиа-запрос, отключающий или замедляющий анимации для пользователей с такой настройкой в ОС.

Что изменилось в WCAG 2.2?

Версия 2.2 вступила в силу с новыми критериями:

Эти критерии повышают порог входа, но мы уже включаем их в стандартный чек-лист.

Аудит и устранение нарушений

Автоматические инструменты находят около 30–40% нарушений. Остальное — только ручное тестирование. Минимальный сценарий: пройти весь критический user flow (регистрация, покупка, форма) только клавиатурой и со скринридером.

Процесс работы

1. Автоматический аудит — axe-core, Lighthouse, WAVE — выдача 80+ правил.
2. Ручное тестирование — NVDA, VoiceOver, клавиатура — 2–3 дня на типовой сайт.
3. Приоритизация нарушений — P1 (блокирует использование), P2 (создаёт сложности), P3 (улучшения).
4. Исправление — итерациями, встраиваем проверки в CI через Playwright + axe.
5. Повторный аудит — закрытие всех P1/P2 перед релизом.
6. Документация и передача — отчёт с результатами, рекомендации по поддержке, обучение команды.

Результаты и объём работ

• Полный отчёт по аудиту с приоритизацией нарушений (PDF/HTML)
• Исправленный код: семантическая разметка, ARIA, клавиатурная навигация
• Интеграция axe-core в CI/CD для регрессионного контроля
• Обучение разработчиков заказчика по работе с a11y (2-часовая сессия)
• Доступ к репозиторию с примерами корректных компонентов
• Гарантия соответствия WCAG 2.2 AA на момент сдачи

Сроки

Бюджет рассчитывается индивидуально после аудита. Свяжитесь с нами — оценим ваш проект за 1 день. Получите консультацию и чек-лист бесплатно при заказе аудита.

Опыт и гарантии

Мы занимаемся веб-доступностью a11y более 8 лет. Реализовали более 50 проектов для банков, ритейла и госсектора. Сертифицированные специалисты (IAAP CPACC, WAS). Гарантируем прохождение аудита третьей стороной или дорабатываем бесплатно.

Стандарт WCAG 2.2 — официальная рекомендация W3C, определяющая требования к доступности веб-контента.

Wikipedia: Web Content Accessibility Guidelines
Wikipedia: ARIA

— уровни веб-доступности a11y по версии 2.2.

Закажите аудит сейчас — получите чек-лист и предварительную оценку бесплатно. Пишите в Telegram или на почту — ответим в течение часа.