Инструменты проверки HIF и контракт доказательств

Статус: прикладная архитектура, рабочая версия 0.2

Документ определяет, как программно проверять интерфейс по HIF, не выдавая частичную автоматизацию за полное соответствие. Он охватывает реестр правил, адаптеры, доказательства, результаты проверки, покрытие, безопасность, отчёты и передачу работы экспертам и разработчикам.

1. Назначение

Инструменты проверки нужны, чтобы:

• рано находить воспроизводимые дефекты;
• связывать доказательства со стабильными правилами HIF;
• объяснять последствия для человека и системы;
• выдавать реализуемые рекомендации;
• фиксировать, что именно инструмент наблюдал и чего не наблюдал;
• передавать неопределённые и субъективные вопросы квалифицированным людям;
• сравнивать состояние до и после исправления, не сводя качество к одному баллу.

Инструмент не заменяет исследования с участниками, проверку ассистивными технологиями, юридическое заключение, тестирование безопасности и решение о выпуске.

2. Политика заявлений

Автоматическая проверка НЕ ДОЛЖНА заявлять о соответствии всей страницы, продукта, WCAG, законодательству или HIF, если все требования такого заявления не оценены подходящим методом и в заявленных границах.

Пройденная проверка означает только:

наблюдаемый объект выполнил данное правило при зафиксированных входных данных, среде, допущениях и версии движка.

Она не означает, что:

• требование выполнено во всех состояниях;
• эквивалентный контент в другом месте не содержит дефекта;
• ненаблюдаемый пользовательский сценарий работает;
• реализация понятна людям;
• юридическая обязанность исполнена.

Совокупную величину ОБЯЗАТЕЛЬНО следует обозначать как риск, покрытие или инструмент приоритизации, но не как балл соответствия.

3. Уровни доказательств

Каждый результат имеет ровно один основной уровень доказательства.

Инструмент НЕ ДОЛЖЕН повышать inferred до detected или объявлять ручное требование пройденным только потому, что дефект не наблюдался.

Уверенность и серьёзность независимы:

• уверенность описывает силу вывода;
• серьёзность описывает последствия, если вывод верен.

4. Модель адаптеров

Адаптер наблюдает одно ограниченное представление.

4.1. Адаптер URL

Начальный адаптер получает публичный HTML-ответ и выбранные HTTP-заголовки. Он может проверить язык документа, viewport, структуру заголовков, основные области, решения о текстовых альтернативах, обнаруживаемые доступные имена, подписи полей, отдельные риски фокуса, транспорт, политики ответа, объём данных и время ответа.

Он не подтверждает:

• состояния после выполнения JavaScript;
• поведение фокуса и завершение задач;
• CSS-геометрию, области нажатия и reflow;
• состояния после входа или согласия;
• движение, звук и временные характеристики;
• вывод ассистивных технологий;
• ошибки, прерывание и восстановление.

4.2. Адаптер изображения

Адаптер изображения локально декодирует файл и может измерять размеры, объём, распределение яркости и структуру квантованной палитры. Он отмечает визуальные риски для последующей проверки.

Он не восстанавливает семантику DOM, исходные токены, размер текста, надёжные пары переднего плана и фона, порядок фокуса, области нажатия, скрытые состояния и движение. Пиксельную статистику НЕЛЬЗЯ выдавать за результат измерения контраста по WCAG.

4.3. Браузерный worker

Браузерный worker — следующий уровень адаптера. Ему СЛЕДУЕТ воспроизводить именованные состояния в контролируемых мобильных и десктопных профилях, собирать дерево доступности, вычисленные стили, геометрию, снимки, консоль, сетевые записи и трассировки производительности. Он ОБЯЗАН фиксировать браузер, движок, viewport, способы ввода, локаль, пользовательские предпочтения и границу аутентификации.

4.4. Сценарии и участие людей

Критические сценарии требуют проходов с клавиатурой, программой экранного доступа, масштабированием/reflow, разными способами ввода, ошибками и восстановлением. Восприятие, понимание, доверие, уместность и успешность задачи требуют экспертных данных или участия пользователей согласно методике HIF.

5. Контракт правила

Каждое машиночитаемое правило ОБЯЗАНО определять:

• стабильный идентификатор и версию;
• название, категорию и границы;
• применимость;
• входные аспекты;
• процедуру проверки;
• ожидаемый и неприменимый исход;
• допущения и известные ограничения;
• серьёзность последствий по умолчанию;
• уровень доказательства;
• обоснование и исправление;
• связь с HIF и внешними требованиями;
• фикстуры для пройденного, проваленного и неприменимого исхода;
• историю изменений и согласованность реализаций.

Правила доступности СЛЕДУЕТ согласовывать с W3C ACT Rules Format там, где он применим. Связь с внешним стандартом не делает само правило HIF нормативным правилом этого внешнего стандарта.

6. Контракт результата

Результат проверки ОБЯЗАН содержать:

• идентификатор правила;
• исход: fail, warning или review;
• фактическую серьёзность;
• уровень доказательства;
• объект и время;
• версии движка и схемы;
• краткое доказательство;
• последствия для человека или системы;
• реализуемое исправление;
• связанные требования.

Селекторы, снимки и значения МОЖНО прикладывать, если они не раскрывают персональные, конфиденциальные или секретные данные.

7. Контракт покрытия

Каждый отчёт ОБЯЗАН указывать:

• наблюдаемые входные данные и конечный объект;
• оценённые и пройденные правила;
• результаты по уровням доказательств;
• использованные адаптеры;
• ненаблюдаемые состояния и требования;
• предупреждения и ошибки запуска;
• допущения о среде;
• обязательные ручные проверки.

Сообщение «проблем не найдено» ОБЯЗАНО сопровождаться границей покрытия. Ошибка получения страницы не является пройденным аудитом. Неприменимое правило не является пройденным.

8. Приоритизация

Приоритет ОБЯЗАН учитывать последствия, охват, частоту, обратимость, правовой или безопасностный риск, уверенность и зависимости исправления. Выручка, должность заинтересованного лица и простота реализации НЕ ДОЛЖНЫ завышать серьёзность.

Совокупный индекс риска МОЖНО использовать для сортировки, если:

• ручные задачи не считаются известными дефектами;
• пройденные наблюдаемые правила входят в знаменатель;
• формула и ограничения видимы;
• первичными остаются отдельные результаты;
• индекс нельзя использовать как освобождение от контрольного этапа выпуска.

9. Отчёт и обмен данными

Канонический формат обмена — схема отчёта HIF, основанная на JSON Schema Draft 2020-12.

Отчёты СЛЕДУЕТ также экспортировать в читаемый Markdown. Экспорт ОБЯЗАН сохранять идентификаторы правил, уровни доказательств, ограничения покрытия и версии движка.

10. Безопасность получения URL

Сервис, принимающий произвольные URL, является границей безопасности. Он ОБЯЗАН:

• разрешать только HTTP и HTTPS;
• по умолчанию отклонять credentials и нестандартные порты;
• разрешать адрес и блокировать private, loopback, link-local, reserved и иные непубличные диапазоны;
• привязывать соединение к проверенному адресу для защиты от DNS rebinding;
• повторять проверку при каждом перенаправлении;
• ограничивать число перенаправлений, время, размер ответа и media type;
• не выполнять активный контент в fetcher;
• разбирать HTML без загрузки внешних сущностей;
• ограничивать частоту запросов недоверенных клиентов;
• не хранить тело страницы без явной необходимости проекта;
• не раскрывать секреты и внутреннюю топологию в ошибках.

До включения анализа отрисованной страницы в production СЛЕДУЕТ добавить сетевую egress-политику и изолированные браузерные workers.

11. Контрольные этапы выпуска

Реализация готова к выпуску, только если:

• каждый выдаваемый идентификатор существует в реестре;
• отчёт проходит валидацию по заявленной схеме;
• покрыты пройденные, проваленные, неприменимые и некорректные фикстуры;
• проходят проверки private network, redirect и oversized response;
• UI и экспорт не содержат неподтверждённых заявлений;
• сам инспектор работает с клавиатурой и в режиме системных цветов;
• английский и русский интерфейсы используют контролируемую терминологию;
• production-проверка подтверждает внешний URL и блокировку SSRF.

12. Текущая прикладная основа

Первая реализация предоставляет:

• ввод публичного URL;
• локальную загрузку изображения;
• 31 проверку URL;
• четыре проверки изображения;
• восемь обязательных ручных проверок;
• фильтры серьёзности и категории;
• экспорт JSON и Markdown;
• английский и русский интерфейсы;
• явные границы покрытия;
• версионированную схему отчёта;
• серверную защиту от SSRF и проверку развёртывания.

Версия 0.2 дополняет URL-адаптер проверками HSTS, прямого перенаправления с HTTP на HTTPS, защиты от определения MIME-типа по содержимому, политики встраивания, CORP, корректности ARIA-имён и ссылок по ID, обозначения разделов, уникальности ID, mixed content, доступности иконки сайта, соответствия SVG-атрибутов и целостности зависимостей с других источников.

Контейнерный браузерный worker реализован и проверен на мобильном и десктопном профилях Chromium. Он собирает результаты axe-core, измерения навигации, отрисовки и долгих задач, покрытие JavaScript и CSS, ошибки консоли и сетевые сбои. Он не входит в публичный адаптер до предоставления изолированного runtime с закрытым аутентифицированным маршрутом и сетевой политикой, запрещающей исходящий доступ по умолчанию. Проверка URL на уровне приложения не заменяет такую сетевую границу.

После развёртывания браузерного worker следующие приоритеты — планы пользовательских сценариев, импорт компонентов и токенов, issue tracking, baseline, сравнение регрессий и профили конкретных организаций.

Источники

• W3C — Accessibility Conformance Testing Rules Format 1.1
• W3C — ACT Rules
• JSON Schema — Draft 2020-12
• OWASP — Server-Side Request Forgery Prevention Cheat Sheet
• Оценка и соответствие HIF
• Методика веб-аудита HIF