[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f2vr6kvk6l7ll1":3},{"slug":4,"title":5,"published":6,"publishedAt":7,"createdAt":7,"section":8,"preview":9,"heroImage":8,"previewImage":10,"headMarkup":11,"lifecycleId":42,"bodyMd":43,"bodyHtml":44},"dostupnost-korporativnogo-sayta-chto-zalozhit-v-dizayn-verstku-i-formy","Доступность корпоративного сайта: что заложить в дизайн, верстку и формы",true,"2026-08-12T09:00:00+03:00",null,"Что предусмотреть для доступности корпоративного сайта в дизайне, верстке и формах: контраст, клавиатура, подписи и ошибки.","\u002Fcontent-media\u002Farticles\u002Fdostupnost-korporativnogo-sayta-chto-zalozhit-v-dizayn-verstku-i-formy\u002Fassets\u002F9d9180db92a6.webp",[12],{"tag":13,"type":14,"key":15,"json":16},"script","application\u002Fld+json","dostupnost-korporativnogo-sayta-chto-zalozhit-v-dizayn-verstku-i-formy-faq",{"@context":17,"@type":18,"mainEntity":19},"https:\u002F\u002Fschema.org","FAQPage",[20,26,30,34,38],{"@type":21,"name":22,"acceptedAnswer":23},"Question","Нужно ли переделывать весь старый сайт сразу?",{"@type":24,"text":25},"Answer","Нет. Начните с новых компонентов, форм и ключевых сценариев, затем составьте план исправлений для существующих разделов. Важно не добавлять новые нарушения в процессе развития сайта.",{"@type":21,"name":27,"acceptedAnswer":28},"Как проверить контраст?",{"@type":24,"text":29},"Используйте инструмент расчёта контраста и проверяйте конкретные пары текста и фона во всех состояниях. Сохраните допустимые сочетания в дизайн-системе, чтобы результат можно было повторить.",{"@type":21,"name":31,"acceptedAnswer":32},"Нужны ли alt-тексты каждой картинке?",{"@type":24,"text":33},"Декоративной картинке альтернативный текст может не требоваться. Информационной схеме, изображению товара или функциональной иконке нужно текстовое объяснение, которое передаёт её роль в сценарии.",{"@type":21,"name":35,"acceptedAnswer":36},"Что проверить в форме в первую очередь?",{"@type":24,"text":37},"Видимые подписи, порядок табуляции, текстовые ошибки, сохранение введённых данных, доступное сообщение об успехе и фактическое создание заявки. Проверяйте это на телефоне и с клавиатуры на десктопе.",{"@type":21,"name":39,"acceptedAnswer":40},"Кто отвечает за доступность?",{"@type":24,"text":41},"Она распределена между владельцем продукта, дизайнером, разработчиком, редактором и тестировщиком. В требованиях нужно назначить владельцев компонентов и критериев приёмки, иначе задача останется ничьей.","lc_3734fd9c7af37bfe64ac90919440f609","# Доступность корпоративного сайта: что заложить в дизайн, верстку и формы\n\nНедоступный сайт не всегда выглядит сломанным. Кнопки могут быть аккуратными, но текст на цветной плашке не читается, фокус клавиатуры исчезает, а сообщение об ошибке формы видно только по красной рамке. Для посетителя, который пользуется клавиатурой, экранным диктором, увеличением или телефоном при ярком свете, такой сайт превращается в набор препятствий. Исправлять их после запуска обычно дороже, потому что решение затрагивает дизайн-систему, шаблоны и компоненты форм.\n\nДоступность стоит включать в требования как проверяемые свойства интерфейса. Не нужно обещать абстрактное «удобство для всех». Нужны конкретные правила: контраст текста, видимое состояние фокуса, логическая последовательность табуляции, подписи полей, текстовые ошибки, альтернативы для нетекстового контента и проверка на реальных устройствах.\n\n## Начните с дизайн-системы\n\nЦвет не должен быть единственным носителем смысла. Если обязательное поле отмечено только красным, часть пользователей не поймёт различия; если статус передан только иконкой без подписи, экранный диктор может не сообщить его вовсе. Компоненту нужны текст, форма или иной дополнительный сигнал.\n\n![Доступный корпоративный сайт: Контраст, Клавиатура, Форма](\u002Fcontent-media\u002Farticles\u002Fdostupnost-korporativnogo-sayta-chto-zalozhit-v-dizayn-verstku-i-formy\u002Fassets\u002F942e6863e26a.webp)\n\nВ макетах проверяют контраст обычного текста, ссылок, подписей, кнопок и состояний. Нельзя оценивать его на глаз по одному монитору: оттенок может казаться различимым дизайнеру и исчезать на другом экране. В палитре лучше заранее хранить допустимые пары фона и текста, чтобы редактор или разработчик не подбирал цвет для каждого баннера вручную.\n\n### Состояние важно не меньше обычного вида\n\nКнопка, ссылка и поле существуют не только в состоянии покоя. У них есть hover, focus, active, disabled, ошибка, загрузка и успешное завершение. Если на макете нет этих состояний, разработчик вынужден додумывать логику, а приёмка видит её уже в коде. Для интерактивных элементов отдельно фиксируют, что происходит после действия и как пользователь узнает результат.\n\n## Проверьте сценарий с клавиатуры\n\nЧеловек должен пройти по сайту без мыши: открыть меню, перейти к основному содержимому, открыть диалог, заполнить форму, закрыть модальное окно и вернуться в предсказуемое место. Порядок фокуса должен совпадать с визуальным порядком и смыслом страницы. Нельзя прятать фокус под декоративным слоем или отправлять его в фон за открытым окном.\n\nИнтерактивный элемент должен быть настоящим элементом управления, а не стилизованным контейнером с обработчиком клика. Нативная кнопка и ссылка уже несут большую часть ожидаемого поведения. Если используется нестандартный компонент, для него приходится отдельно реализовать роли, клавиши, состояния и объявления для вспомогательных технологий.\n\n## Формы: подпись, ошибка, подтверждение\n\nУ каждого поля должна быть программно связанная видимая подпись. Placeholder не заменяет её: текст исчезает при вводе, может иметь слабый контраст и не всегда правильно объявляется. Если поле требует формат или пример, подсказку размещают рядом и связывают с элементом формы.\n\nОшибку нужно сформулировать словами: «Введите номер в указанном формате» полезнее, чем красная граница без пояснения. После отправки фокус переводят к сообщению об ошибке или первому проблемному полю, но не теряют введённые данные. При успехе пользователь должен получить подтверждение, которое доступно не только визуально; одновременно проверяют, что заявка действительно создана на стороне сервера.\n\n## Контент и медиа\n\nИзображение с информацией требует осмысленного альтернативного текста. Не нужно дублировать декоративные детали, но нельзя оставлять без объяснения схему, график или кнопку, которая существует только в виде картинки. Видео нуждается в доступной альтернативе для речи и ключевой визуальной информации, если это необходимо для понимания действия.\n\nРедакторам нужны правила, иначе доступность теряется после первой публикации. В шаблоне статьи можно ограничить уровни заголовков, подсказать alt-текст, предупредить о пустой ссылке и не дать вставить таблицу без заголовков. Автоматические проверки полезны, но они не определят, понятен ли смысл изображения и логична ли подпись.\n\n## Ошибки, которые находят на приёмке\n\n### Проверяют только цветовую палитру\n\nКонтраст важен, но доступность не заканчивается на нём. Без клавиатурной навигации, подписей и корректных сообщений об ошибке сайт всё равно недоступен для части посетителей.\n\n### Ставят tabindex как способ исправить порядок\n\nРучная нумерация фокуса быстро ломается после изменения страницы. Сначала выстройте логический DOM-порядок и используйте нативные элементы, а исключения тестируйте отдельно.\n\n### Используют placeholder вместо label\n\nПосле ввода человек теряет подсказку о назначении поля. Видимая подпись остаётся ориентиром и помогает вспомогательным технологиям правильно назвать элемент.\n\n### Считают автопроверку полной приёмкой\n\nИнструмент может найти часть технических нарушений, но не оценит реальный сценарий, текст ошибки и последовательность действий. Нужна ручная проверка клавиатурой и с разными размерами экрана.\n\n## Часто задаваемые вопросы\n\n### Нужно ли переделывать весь старый сайт сразу?\n\nНет. Начните с новых компонентов, форм и ключевых сценариев, затем составьте план исправлений для существующих разделов. Важно не добавлять новые нарушения в процессе развития сайта.\n\n### Как проверить контраст?\n\nИспользуйте инструмент расчёта контраста и проверяйте конкретные пары текста и фона во всех состояниях. Сохраните допустимые сочетания в дизайн-системе, чтобы результат можно было повторить.\n\n### Нужны ли alt-тексты каждой картинке?\n\nДекоративной картинке альтернативный текст может не требоваться. Информационной схеме, изображению товара или функциональной иконке нужно текстовое объяснение, которое передаёт её роль в сценарии.\n\n### Что проверить в форме в первую очередь?\n\nВидимые подписи, порядок табуляции, текстовые ошибки, сохранение введённых данных, доступное сообщение об успехе и фактическое создание заявки. Проверяйте это на телефоне и с клавиатуры на десктопе.\n\n### Кто отвечает за доступность?\n\nОна распределена между владельцем продукта, дизайнером, разработчиком, редактором и тестировщиком. В требованиях нужно назначить владельцев компонентов и критериев приёмки, иначе задача останется ничьей.\n\n## Итог\n\nДоступность — это набор решений в компонентах и сценариях, а не финальный декоративный чек-лист. Когда контраст, фокус, формы и контент проверяют до релиза, сайт становится понятнее всем посетителям и проще в поддержке.\n","\u003Ch1>Доступность корпоративного сайта: что заложить в дизайн, верстку и формы\u003C\u002Fh1>\n\u003Cp>Недоступный сайт не всегда выглядит сломанным. Кнопки могут быть аккуратными, но текст на цветной плашке не читается, фокус клавиатуры исчезает, а сообщение об ошибке формы видно только по красной рамке. Для посетителя, который пользуется клавиатурой, экранным диктором, увеличением или телефоном при ярком свете, такой сайт превращается в набор препятствий. Исправлять их после запуска обычно дороже, потому что решение затрагивает дизайн-систему, шаблоны и компоненты форм.\u003C\u002Fp>\n\u003Cp>Доступность стоит включать в требования как проверяемые свойства интерфейса. Не нужно обещать абстрактное «удобство для всех». Нужны конкретные правила: контраст текста, видимое состояние фокуса, логическая последовательность табуляции, подписи полей, текстовые ошибки, альтернативы для нетекстового контента и проверка на реальных устройствах.\u003C\u002Fp>\n\u003Ch2>Начните с дизайн-системы\u003C\u002Fh2>\n\u003Cp>Цвет не должен быть единственным носителем смысла. Если обязательное поле отмечено только красным, часть пользователей не поймёт различия; если статус передан только иконкой без подписи, экранный диктор может не сообщить его вовсе. Компоненту нужны текст, форма или иной дополнительный сигнал.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fcontent-media\u002Farticles\u002Fdostupnost-korporativnogo-sayta-chto-zalozhit-v-dizayn-verstku-i-formy\u002Fassets\u002F942e6863e26a.webp\" alt=\"Доступный корпоративный сайт: Контраст, Клавиатура, Форма\">\u003C\u002Fp>\n\u003Cp>В макетах проверяют контраст обычного текста, ссылок, подписей, кнопок и состояний. Нельзя оценивать его на глаз по одному монитору: оттенок может казаться различимым дизайнеру и исчезать на другом экране. В палитре лучше заранее хранить допустимые пары фона и текста, чтобы редактор или разработчик не подбирал цвет для каждого баннера вручную.\u003C\u002Fp>\n\u003Ch3>Состояние важно не меньше обычного вида\u003C\u002Fh3>\n\u003Cp>Кнопка, ссылка и поле существуют не только в состоянии покоя. У них есть hover, focus, active, disabled, ошибка, загрузка и успешное завершение. Если на макете нет этих состояний, разработчик вынужден додумывать логику, а приёмка видит её уже в коде. Для интерактивных элементов отдельно фиксируют, что происходит после действия и как пользователь узнает результат.\u003C\u002Fp>\n\u003Ch2>Проверьте сценарий с клавиатуры\u003C\u002Fh2>\n\u003Cp>Человек должен пройти по сайту без мыши: открыть меню, перейти к основному содержимому, открыть диалог, заполнить форму, закрыть модальное окно и вернуться в предсказуемое место. Порядок фокуса должен совпадать с визуальным порядком и смыслом страницы. Нельзя прятать фокус под декоративным слоем или отправлять его в фон за открытым окном.\u003C\u002Fp>\n\u003Cp>Интерактивный элемент должен быть настоящим элементом управления, а не стилизованным контейнером с обработчиком клика. Нативная кнопка и ссылка уже несут большую часть ожидаемого поведения. Если используется нестандартный компонент, для него приходится отдельно реализовать роли, клавиши, состояния и объявления для вспомогательных технологий.\u003C\u002Fp>\n\u003Ch2>Формы: подпись, ошибка, подтверждение\u003C\u002Fh2>\n\u003Cp>У каждого поля должна быть программно связанная видимая подпись. Placeholder не заменяет её: текст исчезает при вводе, может иметь слабый контраст и не всегда правильно объявляется. Если поле требует формат или пример, подсказку размещают рядом и связывают с элементом формы.\u003C\u002Fp>\n\u003Cp>Ошибку нужно сформулировать словами: «Введите номер в указанном формате» полезнее, чем красная граница без пояснения. После отправки фокус переводят к сообщению об ошибке или первому проблемному полю, но не теряют введённые данные. При успехе пользователь должен получить подтверждение, которое доступно не только визуально; одновременно проверяют, что заявка действительно создана на стороне сервера.\u003C\u002Fp>\n\u003Ch2>Контент и медиа\u003C\u002Fh2>\n\u003Cp>Изображение с информацией требует осмысленного альтернативного текста. Не нужно дублировать декоративные детали, но нельзя оставлять без объяснения схему, график или кнопку, которая существует только в виде картинки. Видео нуждается в доступной альтернативе для речи и ключевой визуальной информации, если это необходимо для понимания действия.\u003C\u002Fp>\n\u003Cp>Редакторам нужны правила, иначе доступность теряется после первой публикации. В шаблоне статьи можно ограничить уровни заголовков, подсказать alt-текст, предупредить о пустой ссылке и не дать вставить таблицу без заголовков. Автоматические проверки полезны, но они не определят, понятен ли смысл изображения и логична ли подпись.\u003C\u002Fp>\n\u003Ch2>Ошибки, которые находят на приёмке\u003C\u002Fh2>\n\u003Ch3>Проверяют только цветовую палитру\u003C\u002Fh3>\n\u003Cp>Контраст важен, но доступность не заканчивается на нём. Без клавиатурной навигации, подписей и корректных сообщений об ошибке сайт всё равно недоступен для части посетителей.\u003C\u002Fp>\n\u003Ch3>Ставят tabindex как способ исправить порядок\u003C\u002Fh3>\n\u003Cp>Ручная нумерация фокуса быстро ломается после изменения страницы. Сначала выстройте логический DOM-порядок и используйте нативные элементы, а исключения тестируйте отдельно.\u003C\u002Fp>\n\u003Ch3>Используют placeholder вместо label\u003C\u002Fh3>\n\u003Cp>После ввода человек теряет подсказку о назначении поля. Видимая подпись остаётся ориентиром и помогает вспомогательным технологиям правильно назвать элемент.\u003C\u002Fp>\n\u003Ch3>Считают автопроверку полной приёмкой\u003C\u002Fh3>\n\u003Cp>Инструмент может найти часть технических нарушений, но не оценит реальный сценарий, текст ошибки и последовательность действий. Нужна ручная проверка клавиатурой и с разными размерами экрана.\u003C\u002Fp>\n\u003Ch2>Часто задаваемые вопросы\u003C\u002Fh2>\n\u003Ch3>Нужно ли переделывать весь старый сайт сразу?\u003C\u002Fh3>\n\u003Cp>Нет. Начните с новых компонентов, форм и ключевых сценариев, затем составьте план исправлений для существующих разделов. Важно не добавлять новые нарушения в процессе развития сайта.\u003C\u002Fp>\n\u003Ch3>Как проверить контраст?\u003C\u002Fh3>\n\u003Cp>Используйте инструмент расчёта контраста и проверяйте конкретные пары текста и фона во всех состояниях. Сохраните допустимые сочетания в дизайн-системе, чтобы результат можно было повторить.\u003C\u002Fp>\n\u003Ch3>Нужны ли alt-тексты каждой картинке?\u003C\u002Fh3>\n\u003Cp>Декоративной картинке альтернативный текст может не требоваться. Информационной схеме, изображению товара или функциональной иконке нужно текстовое объяснение, которое передаёт её роль в сценарии.\u003C\u002Fp>\n\u003Ch3>Что проверить в форме в первую очередь?\u003C\u002Fh3>\n\u003Cp>Видимые подписи, порядок табуляции, текстовые ошибки, сохранение введённых данных, доступное сообщение об успехе и фактическое создание заявки. Проверяйте это на телефоне и с клавиатуры на десктопе.\u003C\u002Fp>\n\u003Ch3>Кто отвечает за доступность?\u003C\u002Fh3>\n\u003Cp>Она распределена между владельцем продукта, дизайнером, разработчиком, редактором и тестировщиком. В требованиях нужно назначить владельцев компонентов и критериев приёмки, иначе задача останется ничьей.\u003C\u002Fp>\n\u003Ch2>Итог\u003C\u002Fh2>\n\u003Cp>Доступность — это набор решений в компонентах и сценариях, а не финальный декоративный чек-лист. Когда контраст, фокус, формы и контент проверяют до релиза, сайт становится понятнее всем посетителям и проще в поддержке.\u003C\u002Fp>\n"]