Поддержка государственных сайтов в 2026: доступность, ГОСТ и дизайн
Коротко: Поддержка госресурса в 2026 — это не «правки по заявкам», а регулярная работа по четырём фронтам: доступность по ГОСТ Р 52872-2019 (уровень AA), актуальность обязательных разделов по 8-ФЗ, безопасность и производительность. Если у ведомства есть мобильное приложение, те же требования распространяются и на него: экранный диктор, масштаб шрифта до 200%, контраст 4.5:1, зоны нажатия 44 pt на iOS и 48 dp на Android. Годовой контракт закупается по 44-ФЗ и требует измеримого ТЗ.
Содержание
- Что вообще входит в поддержку госсайта и приложения?
- Что требует ГОСТ Р 52872-2019 и кто это проверяет?
- Как сделать доступным мобильное приложение, а не только сайт?
- React Native или Flutter: на чём делать госприложение?
- Как публиковать приложение органа власти в App Store и Google Play?
- Сколько стоит поддержка и как её правильно закупить?
- Как за 30 дней привести ресурс к доступности: пошаговый план
- Из опыта команды
- Частые вопросы
Что вообще входит в поддержку госсайта и приложения?
Поддержка государственного ресурса складывается из пяти направлений: юридическая актуальность контента, доступность для людей с инвалидностью, информационная безопасность, техническая работоспособность и развитие интерфейса. Убираете любое из них — заметно растёт риск получить представление прокуратуры или замечание от вышестоящего органа.
Разница между коммерческим сайтом и государственным примерно как между магазином и аптекой. В магазине вы решаете, что и как выкладывать. В аптеке за вас уже решили: вот список обязательного, вот правила хранения, вот проверяющий, который придёт без предупреждения.
Мы в DS495 обычно раскладываем годовой контракт так:
- Контент-блок. Обязательные разделы по 8-ФЗ: структура органа, полномочия, нормативные акты, порядок обжалования, контакты, сведения о доходах. Каждая смена регламента — правка на сайте.
- Доступность. Регулярный аудит по ГОСТ, версия для слабовидящих, альтернативные описания, работа с PDF-сканами (главный источник грехов).
- Безопасность. Обновление CMS и зависимостей, TLS-сертификаты, журналирование, реакция на дефейсы и DDoS.
- Интеграции. Платформа обратной связи, формы записи, единая авторизация, выгрузки в реестры.
- Мобильный контур. Если у ведомства есть мобильное приложение — сборки под новые версии iOS и Android, ответы на отзывы, обновление скриншотов, реакция на изменения политик магазинов.
Последний пункт часто забывают вписать в ТЗ, а потом выясняется, что приложение перестало собираться под новую мажорную версию ОС, и никто за это не отвечает. Мобильная часть живёт по своему календарю: осенью выходят новые версии платформ, вслед за ними — требования магазинов к целевому SDK, и сборку нужно обновлять независимо от того, менялся ли функционал.
Госресурс не бывает «доделан». Он бывает актуален на сегодняшнюю дату. Поддержка — это про то, чтобы эта дата всегда была сегодняшней.
Что требует ГОСТ Р 52872-2019 и кто это проверяет?
ГОСТ Р 52872-2019 «Интернет-ресурсы и другие информационные ресурсы. Требования доступности для инвалидов и других лиц с ограничениями жизнедеятельности» гармонизирован с международными рекомендациями WCAG 2.1 и вводит три уровня соответствия — A, AA, AAA. Для государственных ресурсов ориентир — уровень AA. Проверяют прокуратура (по обращениям граждан и в порядке надзора за исполнением законодательства о социальной защите инвалидов), контрольные органы и, что практичнее всего, сами пользователи.
Формально национальный стандарт применяется добровольно. Но как только он попал в техническое задание или в контракт — он стал вашим обязательством. А ссылка на обеспечение доступности объектов и услуг для инвалидов есть в законодательстве о социальной защите, и именно на неё опирается надзор. Практика простая: пришло обращение от незрячего пользователя, что он не может записаться на приём — дальше проверка и представление, которое нужно рассмотреть в установленный законом срок и устранить нарушения.
Что реально проверяется на уровне AA — вот минимум, который мы прогоняем на каждом аудите:
| Требование | Конкретный критерий | Чем ловим |
|---|---|---|
| Контраст основного текста | Не ниже 4.5:1 к фону | Автоаудит + ручная проверка состояний (hover, focus, disabled) |
| Контраст крупного текста | Не ниже 3:1 (от 18 pt или 14 pt полужирный) | То же |
| Контраст элементов управления | Не ниже 3:1 для границ полей, иконок, индикаторов | Ручная проверка макета |
| Масштабирование | 200% без потери контента и функций | Zoom в браузере, Dynamic Type на iOS, font scale на Android |
| Клавиатура | Все действия доступны без мыши, фокус виден | Проход Tab по всей странице |
| Альтернативы | Текстовое описание у каждого информативного изображения | Автоаудит + вычитка |
| Заголовки и структура | Один h1, последовательная иерархия, landmark-разметка | Дерево доступности в devtools |
| Формы | Связанный label, понятная ошибка текстом, а не только цветом | Тест экранным диктором |
Отдельная боль — сканы. Постановление в виде фотографии бумажного листа, вставленной в PDF, для незрячего пользователя не существует вообще. Автоматический аудитор такой файл, как правило, пропускает: формально это просто ссылка на документ. Поэтому в регламент поддержки мы вписываем правило «документ публикуется в текстовом слое», а старый архив разбираем распознаванием партиями.
И ещё один миф, который стоит похоронить. «Версия для слабовидящих» в виде отдельной чёрно-жёлтой копии сайта — это не соответствие ГОСТу. Это костыль двухтысячных, который живёт своей жизнью, отстаёт по контенту от основной версии и сам по себе нередко недоступен с клавиатуры. Правильный путь — доступный основной интерфейс плюс переключатель контрастной темы и размера шрифта внутри него.
Как сделать доступным мобильное приложение, а не только сайт?
Доступность мобильного приложения строится на системных API платформ: VoiceOver и Dynamic Type на iOS, TalkBack и масштаб шрифта на Android. Практический минимум — подпись у каждого интерактивного элемента, зона нажатия от 44×44 pt на iOS и 48×48 dp на Android, поддержка увеличенного шрифта без обрезания текста и отсутствие смысла, переданного только цветом.
Разработчики нередко считают, что доступность — это про веб. Но требования эргономики программного обеспечения распространяются на любой интерфейс, а гражданин с нарушением зрения одинаково имеет право и на сайт ведомства, и на его приложение. Более того: на телефоне у него уже настроен экранный диктор, и именно с ним он придёт в ваше приложение.
Что ломается чаще всего:
- Иконка без подписи. Кнопка «три полоски» диктуется как «кнопка». Пользователь не знает, что это меню.
- Кастомный элемент без роли. Самописный чекбокс — просто «текст», диктор не сообщает состояние «включено/выключено».
- Фиксированная высота карточки. Включаешь крупный шрифт — и подпись обрезается на середине слова.
- Порядок фокуса из макета, а не из логики. Диктор прыгает по экрану так, как элементы легли в вёрстке.
- Тост-уведомление без анонса. Появилась ошибка формы — зрячий видит, незрячий нет.
- Модалка, не забирающая фокус. Диктор продолжает читать содержимое под ней.
В кроссплатформенной разработке всё это решается штатно. В React Native за доступность отвечают свойства accessible, accessibilityLabel, accessibilityRole и accessibilityState, плюс модуль AccessibilityInfo, который подскажет, включён ли экранный диктор прямо сейчас. Во Flutter слой семантики задаётся виджетом Semantics и параметрами semanticLabel, а в тестовом фреймворке есть готовые проверки контраста и размера зон нажатия — их можно повесить в CI и валить сборку, если новый экран не проходит.
Это, кстати, одна из ключевых практик в нашей работе: доступность держится не на энтузиазме конкретного разработчика, а на автотесте. Иначе первый же спринт под дедлайн вымывает все подписи. Мы разбирали смежную дисциплину — регулярный технический контроль сборок — в материале про уязвимости iOS и Android в мобильных приложениях; логика та же, только предмет проверки другой.
Проверка на пять минут, которая ловит значительную часть проблем: включите VoiceOver или TalkBack и попробуйте выполнить главный сценарий приложения с закрытыми глазами. Если не дошли до конца — доступности нет, что бы ни писал автоаудитор.
Нужна помощь с этой задачей? Команда DS495 поможет решить её под ключ. Обсудить проект →
React Native или Flutter: на чём делать госприложение?
Для типового приложения органа власти — списки услуг, формы, статусы обращений, карта объектов, уведомления — подходят обе технологии, и кроссплатформа экономит бюджет относительно двух нативных команд. React Native выигрывает, когда у ведомства уже есть веб-команда на JavaScript и общий с порталом код; Flutter — когда важен единый пиксель-в-пиксель интерфейс на обеих ОС и высокая скорость анимаций.
Спор «что лучше» в госсекторе решается не бенчмарками, а тем, кто будет сопровождать приложение через три года. Контракт на поддержку разыгрывается заново, и подрядчик меняется. Значит, критерий номер один — насколько легко найти на рынке команду, которая подхватит проект.
| Критерий | React Native | Flutter |
|---|---|---|
| Поддержка доступности | Прокидывает нативные accessibility-API, свойства на уровне компонентов | Собственный слой семантики + готовые guideline-тесты в CI |
| Переиспользование с порталом | Высокое: общий JS/TS-код, бизнес-логика, типы | Низкое: отдельный язык Dart |
| Единство интерфейса на iOS и Android | Ближе к нативным контролам платформы | Один рендер, идентичный вид на обеих ОС |
| Найм подрядчика на поддержку | Шире пул: любой React-разработчик частично в теме | Уже пул, но специалисты более взаимозаменяемы |
| Работа с картами и офлайн-режимом | Через нативные модули, зависимость от библиотек | Стабильнее «из коробки», меньше мостов |
| Обновление под новые версии ОС | Требует внимания к нативным зависимостям | Проще: меньше внешних мостов |
Наш практический вывод: если приложение — это по сути мобильная витрина уже существующего портала госуслуг ведомства, берите React Native и переиспользуйте логику. Если это самостоятельный продукт с картой, офлайном и сложной анимацией — Flutter даст более предсказуемое сопровождение. Развёрнутое сравнение по девяти параметрам мы собрали в отдельном разборе — Flutter vs React Native: критерии выбора технологии, там же расчёты по срокам.
Чего точно не стоит делать — заворачивать сайт в WebView и называть это приложением. Такое решение рискует получить отказ на ревью в магазинах как «приложение без самостоятельной ценности», а по доступности наследует все проблемы сайта, добавляя к ним свои: жесты диктора конфликтуют с жестами веб-страницы. Разницу подходов мы подробно разбирали в материале мобильное приложение против мобильной версии сайта.
Как публиковать приложение органа власти в App Store и Google Play?
Главное правило: приложение, представляющее государственный орган, оба магазина требуют публиковать с аккаунта разработчика самого органа, а не подрядчика. Аккаунт заводится на юрлицо ведомства, подрядчик получает доступ как разработчик. Это не бюрократия ради бюрократии — иначе при смене подрядчика приложение уезжает вместе с ним, а вернуть листинг с чужого аккаунта в App Store и Google Play крайне сложно.
Мы видели проекты, где приложение годами висело на личном аккаунте бывшего сотрудника подрядчика. Финал предсказуем: аккаунт не продлили, приложение исчезло из выдачи, а накопленная база установок обнулилась. Восстановить пришлось публикацией заново, с нуля по рейтингу и отзывам.
Пошаговый порядок публикации, который мы закладываем в ТЗ:
- Аккаунты. Организационный аккаунт разработчика на ведомство, юридическая проверка данных, подтверждение полномочий. Срок верификации — от нескольких дней до нескольких недель, закладывайте с запасом.
- Права доступа. Подрядчик добавляется с ограниченной ролью. Ключи подписи и сертификаты хранятся у заказчика.
- Политика приватности. Отдельная страница на домене ведомства, соответствие требованиям о персональных данных, включая локализацию баз на территории РФ.
- Декларации о данных. Форма безопасности данных в Google Play и карточка приватности в App Store заполняются по факту, а не «как обычно». Расхождение декларации с реальным поведением приложения — типовая причина отказа.
- Российский магазин приложений. Для Android-аудитории дистрибуция через отечественный стор — не запасной вариант, а основной канал: он предустановлен на устройствах, продаваемых в России.
- Реестр отечественного ПО. Если приложение закупается за бюджетные деньги, вопрос включения в реестр решается на старте, а не постфактум.
- Карточка и ASO. Название, короткое описание, скриншоты с реальными экранами. Даже у госприложения есть конкуренция за внимание — с фишинговыми клонами, которые копируют название ведомства.
Про последний пункт скажу отдельно, потому что его недооценивают. Пользователь ищет «запись к врачу» или название своего города, и в выдаче магазина видит десяток приложений. Если официальное лежит далеко от верхних позиций, гражданин установит чужое. Работа с карточкой — это не маркетинг, это защита от подделок. Базовая механика описана в разборе мобильного SEO для App Store и Google Play, и для госприложения она применима один в один.
Сколько стоит поддержка и как её правильно закупить?
Стоимость годовой поддержки определяется не «размером сайта», а количеством контуров: только портал, портал плюс приложение под iOS и Android, наличие интеграций и требования по защите информации. Ниже — ориентировочная структура работ, которую мы используем при оценке; конкретная сумма считается по объёму часов и уровню SLA, а не по прайс-листу.
Методология: разбивка ниже отражает состав работ по нашим договорам сопровождения и служит ориентиром для расчёта НМЦК, а не публичным прайсом. Доли приведены как порядок величин и сильно смещаются от проекта к проекту; цифра для конкретного случая выводится из объёма контента, числа интеграций и требуемого времени реакции.
| Блок работ | Что входит | Периодичность | Доля бюджета |
|---|---|---|---|
| Контент и правовая актуальность | Публикация НПА, обновление разделов по 8-ФЗ, вычитка | Постоянно | Примерно четверть |
| Доступность | Квартальный аудит, исправления, разбор PDF, тест диктором | Раз в квартал + правки | Примерно шестая часть |
| Безопасность и обновления | Патчи CMS и зависимостей, сертификаты, мониторинг, резервные копии | Ежемесячно | Примерно пятая часть |
| Мобильный контур | Сборки под новые версии ОС, релизы в магазины, ответы на отзывы | 4–6 релизов в год | Примерно пятая часть |
| Развитие интерфейса | Новые сервисы, доработки форм, аналитика поведения | По плану | Остаток бюджета |
Теперь про закупку, потому что здесь ломается больше проектов, чем в разработке. Три правила, которые экономят год жизни:
- Измеримое ТЗ. Не «обеспечить доступность», а «соответствие уровню AA по ГОСТ Р 52872-2019, подтверждённое отчётом аудита с перечнем критериев». Первую формулировку невозможно принять или отклонить, вторую — можно.
- SLA в часах, а не в словах. Критичный сбой — реакция N часов, восстановление M часов. Обычная заявка — рабочий день. Без цифр приёмка превращается в переписку.
- Передача артефактов. В контракт — обязанность передать исходный код, ключи подписи, доступы к аккаунтам магазинов и документацию по окончании срока. Иначе следующий подрядчик начнёт с археологии.
Если вы только планируете разработку, а не сопровождение существующего, ориентиры по бюджету и этапам мы собрали в материале про цену разработки мобильного приложения — там разложены вилки по типам продуктов.
Как за 30 дней привести ресурс к доступности: пошаговый план
Полный переход к уровню AA на большом портале занимает месяцы, но снять критичные нарушения — те, из-за которых пользователь физически не может получить услугу, — реально за четыре недели. Порядок такой: сначала измеряем, потом чиним сценарии, потом внешний вид, и только в конец ставим архив документов.
- Дни 1–3. Инвентаризация. Список шаблонов страниц и экранов приложения. Обычно это несколько десятков уникальных шаблонов, а не тысячи страниц. Чиним шаблон — чиним всё, что на нём построено.
- Дни 4–6. Базовый замер. Автоаудит по всем шаблонам, ручной проход клавиатурой, прогон главного сценария экранным диктором на iOS и на Android. Фиксируем стартовые цифры — они понадобятся для отчёта.
- Дни 7–14. Блокеры. Всё, что мешает завершить целевое действие: формы без подписей, недостижимые с клавиатуры кнопки, ловушки фокуса, капча без альтернативы, ошибки, обозначенные только красным цветом.
- Дни 15–20. Контраст и типографика. Правим палитру до 4.5:1, проверяем состояния наведения и фокуса, тестируем масштаб 200% и крупный системный шрифт на мобильных.
- Дни 21–25. Семантика. Заголовочная иерархия, landmark-разметка, alt-описания, подписи у иконок в мобильной сборке, корректный порядок обхода.
- Дни 26–28. Документы. Разбираем архив PDF: приоритет — действующим НПА и бланкам заявлений. Сканы отправляем на распознавание, добавляем текстовый слой.
- Дни 29–30. Повторный замер и регламент. Сравниваем с базовым замером, оформляем отчёт, вносим проверки доступности в CI и в чек-лист контент-редактора.
Последний шаг не менее важен, чем все предыдущие. Без регламента через полгода редакторы снова зальют картинки без описаний, а разработчики добавят экран без подписей — и вы вернётесь к нулевой точке, только с потраченным бюджетом.
Из опыта команды
Задача. К нам пришло учреждение с двумя контурами: портал на устаревшей версии CMS и кроссплатформенное приложение для записи на приём, которое собрали несколько лет назад и с тех пор почти не трогали. Триггером стало обращение гражданина: незрячий пользователь не смог записаться ни на сайте, ни в приложении.
Что сделали. Начали с замера, а не с правок. Прошли главный сценарий записи с VoiceOver и TalkBack — обнаружили, что выбор даты в календаре вообще не озвучивается, а кнопка подтверждения не имеет подписи. Дальше по плану: сначала блокеры сценария, потом контраст и масштабирование, потом семантика. В мобильной части добавили accessibility-свойства всем кастомным элементам, переписали календарь на компонент с корректными ролями и состояниями, вынесли проверки контраста и размеров зон нажатия в CI — сборка теперь падает, если новый экран не проходит. Параллельно перенесли приложение на организационный аккаунт заказчика в обоих магазинах и передали ключи подписи.
Результат. Сценарий записи ��роходится экранным диктором от начала до конца на обеих платформах. Точных публичных метрик мы не приводим — вместо них даём чек-лист, который советуем мерить до и после любой такой работы:
- доля шаблонов, проходящих автоаудит без критичных ошибок;
- число шагов целевого сценария, выполнимых только мышью;
- время прохождения сценария экранным диктором;
- доля документов с текстовым слоем в разделе НПА;
- количество обращений граждан по теме недоступности за квартал;
- доля отзывов в магазинах с жалобами на интерфейс;
- число экранов, не проходящих guideline-тесты в CI.
Эти семь чисел — готовый раздел отчётности по контракту. Их можно предъявить и заказчику, и надзорному органу, и они не требуют веры на слово.
Частые вопросы
В: Обязателен ли ГОСТ Р 52872-2019 для сайта муниципалитета?
О: Сам национальный стандарт применяется добровольно, но становится обязательным, как только включён в техническое задание или контракт. Кроме того, требование обеспечивать доступность информации для инвалидов закреплено в законодательстве о социальной защите, и надзорные органы опираются на него. Практический вывод: ориентируйтесь на уровень AA и фиксируйте его в ТЗ формулировкой с проверяемым критерием.
В: Достаточно ли «версии для слабовидящих» вместо доработки сайта?
О: Нет. Отдельная чёрно-жёлтая копия не покрывает требования стандарта: она не решает проблемы навигации с клавиатуры, отсутствия альтернативных описаний, недоступных форм и сканированных PDF. Плюс такая версия отстаёт по контенту от основной. Правильное решение — доступный основной интерфейс с переключателем контрастной темы и размера шрифта внутри него.
В: Распространяются ли требования доступности на мобильное приложение ведомства?
О: Да. Требования эргономики и доступности программного обеспечения не ограничиваются вебом, а гражданин имеет право на равный доступ к услуге в любом канале. Практический минимум для приложения: поддержка VoiceOver и TalkBack, подписи и роли у всех интерактивных элементов, зоны нажатия от 44×44 pt на iOS и 48×48 dp на Android, корректная работа при увеличенном системном шрифте.
В: Что выбрать для госприложения — React Native или Flutter?
О: Если приложение переиспользует логику существующего портала и у ведомства есть JavaScript-команда, берите React Native. Если это самостоятельный продукт с картой, офлайн-режимом и сложной графикой — Flutter даст более предсказуемое сопровождение и штатные тесты доступности в CI. Обе технологии корректно прокидывают accessibility-API платформ, так что по доступности выбор нейтрален.
В: На чей аккаунт публиковать приложение в App Store и Google Play?
О: Только на организационный аккаунт разработчика, оформленный на само ведомство. Подрядчик добавляется с ограниченной ролью, ключи подписи и сертификаты хранятся у заказчика. Если публиковать с аккаунта подрядчика, при смене исполнителя листинг, установки и отзывы, как правило, теряются — восстановить их с чужого аккаунта в магазинах обычно не удаётся.
В: Как прописать доступность в ТЗ, чтобы работу можно было принять?
О: Замените формулировку «обеспечить доступность» на проверяемую: соответствие уровню AA по ГОСТ Р 52872-2019, подтверждённое отчётом аудита с перечнем критериев и результатом по каждому. Добавьте требование ручного прохождения целевых сценариев экранным диктором на iOS и Android, а также передачу исходного кода, ключей подписи и доступов к магазинам по окончании контракта.
В: Как часто нужно выпускать обновления мобильного приложения на поддержке?
О: Ориентир — четыре-шесть релизов в год даже без нового функционала. Осенью выходят мажорные версии платформ, вслед за ними магазины поднимают требования к целевому SDK, обновляются библиотеки и правила деклараций о данных. Если сборку не обновлять, приложение сначала теряет совместимость с новыми устройствами, а затем может быть скрыто из выдачи магазина.
Это часть серии материалов по теме «Дизайн и брендинг». Основная статья серии: Продвижение сайта в топ 2026: как дизайн и UX влияют на позиции.
Читайте также
- Продвижение сайта в топ 2026: как дизайн и UX влияют на позиции — основная статья кластера
- Мобильное SEO 2026: оптимизация App Store и Google Play за 7 шагов
- ASO-оптимизация в 2026: как пройти алгоритмы App Store и Google Play за 30 дней
- React Native парсер магазинов приложений: автосбор ASO-данных
Нужна помощь с этим? Обсудить проект с DS495 →
Материал подготовил Альберт К.
За продуманным интерфейсом — дизайн-услуги DS495.