Endge

Тема

Доступность (a11y) ​

Одна потребность: приложение должно быть доступно людям с ограниченными возможностями (зрение, моторика, слух, когнитивные особенности). Это этическая и юридическая необходимость, а также требование госзаказа и крупных тендеров (WCAG 2.1, ГОСТ).

Что такое доступность (теория) ​

Доступность (accessibility, a11y) — практика проектирования и разработки так, чтобы продуктом могли пользоваться люди с разными возможностями, в том числе:

  • Слабовидящие и незрячие: скринридеры (NVDA, JAWS, VoiceOver) зачитывают структуру и текст; навигация с клавиатуры; достаточный контраст и масштабирование без потери функциональности.
  • С ограниченной моторикой: управление без мыши — клавиатура, переключатели; большие зоны нажатия; без жёстких таймаутов на действие.
  • С нарушением слуха: субтитры/транскрипты для аудио и видео; важная информация не только звуком.
  • Когнитивные особенности: простой язык, предсказуемая навигация, возможность отменить действие, отсутствие мигания и отвлекающих эффектов.

Без учёта a11y часть пользователей не сможет работать с системой; в ряде юрисдикций это дискриминация и основа для исков. Стандарт WCAG 2.1 (Web Content Accessibility Guidelines) задаёт уровни A, AA, AAA; для госсектора и крупных заказчиков обычно требуют уровень AA.

Как это реализуется в мире ​

Стандарты и законы ​

  • WCAG 2.1: воспринимаемость (текст, контраст, альтернативы медиа), управляемость (клавиатура, время, судороги/мигание), понятность (язык, предсказуемость, подсказки), устойчивость (совместимость со вспомогательными технологиями).
  • ARIA (Accessible Rich Internet Applications): атрибуты для разметки ролей, состояний и свойств элементов, когда нативного HTML недостаточно (например, кастомные виджеты, живые регионы).
  • Секция 508 (США), EAA (ЕС), ГОСТ Р 52872 (РФ): юридические требования к доступности; часто отсылают к WCAG.

Технические основы ​

  1. Семантическая разметка: заголовки (h1–h6), списки (ul/ol), кнопки (button), ссылки (a), формы (label, input, связка по id/for). Скринридер и клавиатура опираются на семантику.
  2. Фокус и порядок табуляции: логичный порядок перехода по Tab; видимая обводка фокуса (focus visible); не скрывать фокус через outline: none без замены на другой индикатор.
  3. Контраст: соотношение текста и фона не ниже 4.5:1 (обычный текст), 3:1 — крупный; проверка по WCAG.
  4. Клавиатурная навигация: все интерактивные элементы и сложные виджеты (табы, модалы, выпадающие списки) управляются с клавиатуры (Tab, Enter, Space, стрелки, Escape).
  5. ARIA: для кастомных компонентов — роли (role="button", role="dialog"), состояния (aria-expanded, aria-selected, aria-live), имена (aria-label, aria-labelledby). Живые регионы (aria-live) для динамических сообщений (тосты, ошибки).
  6. Тестирование: автоматические проверки (axe-core, Lighthouse, pa11y), ручная проверка с клавиатуры и со скринридером; включение a11y в Definition of Done.

Отраслевая практика ​

  • Vue: официальный гайд по a11y; библиотеки (Vue A11y, Headless UI, Radix Vue) поставляют доступные компоненты. В вашем стеке уже используется reka-ui (Radix-подобный) и shadcn-vue — они закладывают семантику и ARIA; важно использовать их правильно и не ломать поведение.
  • Low-Code платформы: доступность обеспечивается как на уровне компонентов платформы (кнопки, формы, таблицы), так и на уровне сгенерированного контента (заголовки страниц, подписи полей, сообщения об ошибках).

Как это вписать в нашу архитектуру ​

Уровни ответственности ​

  1. Дизайн-система и базовые компоненты (@endge/ui-vue, UI-компоненты приложений, reka-ui) Кнопки, поля ввода, модалы, табы, выпадающие списки должны быть доступными «из коробки»: семантика, фокус, ARIA. При кастомизации не убирать обводку фокуса и не ломать связки label–input. Документировать a11y-требования для каждого компонента.

  2. Слой рендеринга (@endge/ui-vue, JSX-компоненты) Рендер доменных сущностей (таблицы, формы, карточки) должен выдавать разметку с заголовками, регионами, подписями. Например: у таблицы — caption или aria-label; у формы — у каждого поля label и связь с полем; у динамических сообщений — aria-live (или обёртка тостов с live region).

  3. Страницы и layout Один заголовок первого уровня на страницу; логичная структура заголовков (h1 - h2 - h3). Области приложения (header, main, nav) — семантические или с role и aria-label. Пропуск к основному контенту (skip link) в начале страницы для пользователей клавиатуры.

  4. Маршрутизация и фокус При смене маршрута фокус переносится в начало основного контента новой страницы (или в заголовок страницы), чтобы скринридер и клавиатурный пользователь не оставались в старом контексте.

  5. Диагностика и тосты Сообщения об ошибках и уведомления должны объявляться скринридеру: через aria-live="polite" или aria-live="assertive" в контейнере тостов и в блоке ошибок форм.

  6. Домен и конфигурация Там, где конфигурируются подписи полей, заголовки, тексты кнопок — эти же тексты используются для доступности (aria-label, подписи). Избегать пустых кнопок/иконок без текстовой альтернативы (aria-label или видимый текст).

Специфика платформы ​

  • Динамический контент (Raph, runtime): обновления данных в таблицах и виджетах не должны «оглушать» скринридер; для массовых обновлений использовать aria-live="polite" выборочно (например, итог «Загружено N записей»), а не каждую ячейку.
  • Админка (дерево, инспектор, вкладки): дерево домена — семантическое дерево (role="tree", role="treeitem", aria-expanded); вкладки — паттерн tablist/tab/tabpanel с правильным управлением стрелками и фокусом. Reka UI Tabs и подобные уже дают основу; нужно соблюдать контракт.
  • Таблицы (RevoGrid): проверить, как грид экспортирует роли и заголовки для скринридера; при необходимости обернуть или донастроить (aria-label для таблицы, объявление количества строк/столбцов).
  • Сложная графика: графическая поверхность по умолчанию может быть недоступна для скринридера; нужно давать текстовое описание сцены или ключевых элементов и дублировать критичные действия доступными контролами.

План внедрения по этапам ​

Этап 1: Основа (обязательный минимум) ​

  • Включить автоматические проверки в CI (axe-core или eslint-plugin-vuejs-accessibility); исправить критические нарушения в существующих страницах и компонентах.
  • Зафиксировать правила: контраст текста (WCAG AA), наличие alt у изображений, подписи у полей форм, кнопки и ссылки с понятным текстом или aria-label.
  • Skip link «Перейти к основному контенту» в layout; один h1 на страницу; базовая семантика main/nav/footer.
  • Документ «Требования по доступности» в репозитории: уровень (AA), ссылка на WCAG, чек-лист для новых фич.

Срок: 1–2 спринта.

Этап 2: Клавиатура и фокус ​

  • Полная навигация по основным сценариям только с клавиатуры (Tab, Enter, Space, Escape, стрелки). Исправить «ловушки» фокуса в модалах и выпадающих списках; возврат фокуса при закрытии модала.
  • Видимая обводка фокуса (focus-visible) во всех компонентах; не использовать outline: none без замены.
  • При смене маршрута — перенос фокуса в main или в заголовок страницы.
  • Ручное тестирование с клавиатурой и одним скринридером (например, NVDA или VoiceOver).

Срок: 1–2 спринта.

Этап 3: Компоненты и виджеты ​

  • Проверить и донастроить все компоненты из дизайн-системы (модалы, табы, селекты, дерево): ARIA-роли, состояния, имена. Использовать рекомендации WAI-ARIA Authoring Practices для паттернов (tabs, modal, combobox, tree).
  • Тосты и глобальные сообщения — контейнер с aria-live; ошибки в формах — связь с полем через aria-describedby или объявление через live region.
  • Таблицы данных: caption или aria-label, по возможности объявление структуры для скринридера. RevoGrid — по документации и тестам со скринридером.

Срок: 2–3 спринта.

Этап 4: Контент и конфигурация ​

  • Все тексты интерфейса (в т.ч. из домена и конфигурации), используемые как подписи или названия, учитываются для a11y; пустые кнопки/иконки не допускаются без aria-label.
  • Мультиязычность: переключение языка и объявление языка страницы (lang) для корректного чтения скринридером.
  • Документация для конфигураторов: как задавать доступные подписи и альтернативные тексты.

Срок: параллельно с разработкой новых фич; 1 спринт на формализацию правил.

Этап 5: Сложные сценарии и графика ​

  • Админка: дерево, инспектор, сложные формы — полный проход с клавиатуры и скринридером; исправление оставшихся проблем.
  • Тяжёлая графика: текстовые альтернативы, описание сцены; критичные действия — дублирование доступными контролами.
  • Регулярное ручное тестирование с реальными пользователями вспомогательных технологий (при возможности).

Срок: непрерывно; приоритет по частоте использования сценариев.

Риски и ограничения ​

  • A11y — сквозное требование; ретрофит существующих экранов трудоёмок. Приоритизировать по частоте использования и по законодательным требованиям заказчика. Виртуализированные списки и кастомные гриды (RevoGrid) требуют отдельной проверки со скринридером; модалы и регистр модалов (см. Modal_Registry) — корректного управления фокусом.

Вывод ​

  • Доступность — обязательное требование для enterprise и госзаказа; целевой уровень — WCAG 2.1 AA.
  • Реализация: семантика, фокус и клавиатура, контраст, ARIA для кастомных виджетов, живые регионы для динамических сообщений.
  • В архитектуре Endge: ответственность распределена по дизайн-системе, слою рендеринга, страницам и доменной конфигурации; динамический контент и админка требуют явного внимания к фокусу и ARIA.
  • Внедрение по этапам: автоматические проверки и базовая семантика - клавиатура и фокус - компоненты и виджеты - контент и конфигурация - сложные сценарии и графика; с фиксацией требований и чек-листов в документации.