Розробка державного порталу під ключ: ЄСІА, WCAG, безпека

Розробка порталу для державної організації

Державні органи часто стикаються з проблемою: сайт не проходить перевірку доступності, дані громадян зберігаються з порушеннями, а пошук за документами не знаходить потрібних постанов. Ми спеціалізуємося на таких проєктах і знаємо, як уникнути цих помилок. Наш досвід — понад десять років і десятки реалізованих порталів для державних організацій України. Розбираємо нормативну базу, вимоги WCAG, інтеграцію з державною системою ідентифікації та захист персональних даних.

Законодавча база

В Україні вимоги визначають Закони «Про інформацію», «Про захист персональних даних», постанови Кабінету Міністрів про веб-сайти органів влади. Перелік обов'язкових розділів для офіційних сайтів: відомості про орган, нормативні документи, державні послуги, результати перевірок, антикорупційні матеріали. Враховуємо всі норми на етапі проєктування, щоб уникнути переробок після аудиту.

Чому WCAG 2.1 AA обов'язковий для державних сайтів?

Це не рекомендація, а закон. В Україні вимоги доступності відповідають міжнародному стандарту 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. Отримайте консультацію щодо вашого проєкту, щоб уникнути цих помилок.

Як інтеграція з державною системою ідентифікації покращує користувацький досвід?

Для особистих кабінетів громадян обов'язкова інтеграція з державною системою ідентифікації (Gov.ua, ЄСІА) через SAML 2.0 або OpenID Connect. Приклад підключення через OAuth 2.0 (Laravel):

// Laravel: редирект на авторизацію через держсистему
public function redirectToGov()
{
    $params = [
        'client_id'     => config('gov.client_id'),
        'response_type' => 'code',
        'scope'         => 'openid fullname email mobile',
        'redirect_uri'  => route('gov.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('gov.auth_url') . '?' . http_build_query($params));
}

Запити підписуються кваліфікованим сертифікатом — його потрібно отримати в акредитованому центрі сертифікації. Інтеграція підвищує безпеку входу та дозволяє вивантажувати дані з державних систем.

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

Закон «Про захист персональних даних» вимагає зберігати персональні дані громадян на серверах в Україні. Обираємо хостинг лише з локальних дата-центрів. Обов'язкові заголовки безпеки:

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('ukrainian', title || ' ' || content));

SELECT id, title,
  ts_rank(to_tsvector('ukrainian', title || ' ' || content), query) AS rank
FROM documents, to_tsquery('ukrainian', 'приватизація & житло') query
WHERE to_tsvector('ukrainian', 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 (/uk/, /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 стає єдиним способом уникнути дискримінації та юридичних ризиків. Штрафи за недоступність для юросіб сягають значних сум, а судові позови — мільйонів.

У цій картці — як ми робимо веб-доступність 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 — відповідно до складності (від невеликих до значних сум). Впровадження 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 або на пошту — відповімо протягом години.