HIFDocs
HIF / Документация / Клиентская практика

Методика веб-аудита HIF

Статус: операционная методика, версия 0.1

Назначение: независимая доказательная проверка клиентских сайтов и веб-приложений

Методика переводит Конституцию HIF и оценку HIF в воспроизводимую коммерческую услугу. Она применима для первичного аудита, проверки перед релизом, базовой оценки перед редизайном и проверки исправлений.

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

1. Основные принципы

Аудит ОБЯЗАН:

  1. проверять значимые задачи, а не только экраны;
  2. определять область, выборку, среду и ограничения до формулирования выводов;
  3. различать наблюдение, интерпретацию, гипотезу и подтверждённый дефект;
  4. сохранять цепочку «требование → доказательство → результат проверки»;
  5. сочетать методы: один инструмент или эксперт не покрывает всю систему;
  6. минимизировать сбор персональных, конфиденциальных и чувствительных данных;
  7. считать исключение людей и потерю контроля риском, а не косметикой;
  8. оставлять клиенту право выбрать любого исполнителя исправлений;
  9. раскрывать неопределённость и конфликт интересов;
  10. не давать юридических гарантий, а также гарантий безопасности или доступности.

HIF остаётся главным критерием продукта. Внешние стандарты задают специальные критерии. Конфликты фиксируются и разрешаются по иерархии HIF.

2. Заказ и разрешение

До начала работ ОБЯЗАТЕЛЬНО зафиксировать:

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

По умолчанию применяется неразрушающее наблюдение с синтетическими данными и специальными тестовыми аккаунтами. Нагрузочные воздействия, эксплуатация уязвимостей, социальная инженерия, изменение production-данных и обход контролей требуют отдельной области, письменного разрешения и специалистов.

Новый хост или процесс не становится частью аудита автоматически. Его регистрируют и добавляют только после подтверждения области.

Проверку ПРЕКРАЩАЮТ и связываются с ответственным, если возможен вред людям, данным или доступности сервиса; открылись неожиданные чувствительные данные; продолжение может усилить уязвимость; среда не соответствует разрешённой; изменение сайта обесценивает доказательства; полномочия стали неясны.

3. Вопросы аудита

  • Выполняет ли каждая приоритетная аудитория свои приоритетные задачи?
  • Понятны ли объект, состояние, последствия и следующее действие?
  • Можно ли предотвратить, распознать и исправить ошибку?
  • Доступны ли основные задачи при требуемых способах ввода, размерах окна и браузерах?
  • Сохраняются ли доступность, приватность, безопасность, доверие и контроль?
  • Приемлема ли производительность в реальном использовании и тестовой среде?
  • Помогают ли контент и информационная архитектура найти, понять и применить нужную информацию?
  • Какие изменения снимают наибольший подтверждённый риск?

Вопрос определяет метод и доказательство, а не наличие кнопки в инструменте.

3.1. Базовая трассировка HIF

Матрица покрытия как минимум сопоставляет:

Область аудитаКонституция
цель, границы, рискHIF-CTX-001..003
объекты, identity, provenanceHIF-OBJ-001..004
смысл, полномочия и повтор командHIF-CMD-001..005
state, persistence, concurrencyHIF-STA-001..005
acknowledgement, progress, completionHIF-FBK-001..005
prevention, errors, recoveryHIF-ERR-001..005
orientation, focus, escapeHIF-NAV-001..005
независимость и эквивалентность вводаHIF-INP-001..004
доступность и адаптацияHIF-A11Y-001..004
содержание и локализацияHIF-CNT-001..004
конфиденциальность, безопасность, выбор и довериеHIF-TRU-001..005
автоматизация и ИИHIF-AUT-001..006
производительность и устойчивостьHIF-PERF-001..004
визуальная иерархия и семантикаHIF-VIS-001..005

Диапазон — только индекс, а не утверждение применимости всех требований. Применимость и исключения определяются отдельно.

4. Инвентаризация и задачи

Создаётся датированный реестр:

  • хостов, приложений, локалей и границ авторизации;
  • шаблонов, типов страниц, важных путей и транзакций;
  • ролей, прав и состояний аккаунта;
  • форм, поиска, навигации и интерактивных компонентов;
  • документов, медиа и стороннего содержимого;
  • адаптивных режимов, тем и персонализации;
  • ошибок, пустых состояний, загрузки, offline, timeout и завершения;
  • поддерживаемых браузеров, устройств и assistive technologies;
  • предоставленных клиентом сигналов аналитики и поддержки;
  • релизов, экспериментов и feature flags.

URL не является единственной единицей: состояние SPA, модальное окно, ветка валидации или представление роли могут быть отдельными единицами.

Для каждой задачи:

TASK-ID
аудитория и контекст
цель
начальное состояние
роль и полномочия
предусловия и данные
критерий успеха
критические ошибки
ветки и прерывания
применимые требования HIF
нужный уровень доказательств

Где применимо, включаются ориентация, поиск, сравнение, создание, изменение, отправка, оплата, сохранение, удаление, восстановление, отказ, выход, аутентификация и помощь.

5. Выборка

Небольшая область проверяется целиком. Иначе применяется документированная выборка. По структуре WCAG-EM она ДОЛЖНА сочетать:

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

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

Реестр выборки хранит причину включения, варианты, состояние, результат и доказательство. Нельзя переносить результат проверки выборки на весь сайт без доказательства. Охват отмечается как измеренный, выведенный или неизвестный.

Выборка расширяется при признаке системной ошибки, новом варианте шаблона или новой технологии. Причина расширения фиксируется.

6. Набор методов

6.1. Модель

Проверяются предложение продукта, исследования аудитории, IA, контент-модель, дизайн-система, среды, аналитика и ограничения. Объекты, команды, состояния, права и сохранение сопоставляются с HIF.

6.2. Функциональный тест-дизайн

Применяются техники из тест-дизайна HIF: классы эквивалентности, граничные значения, таблицы решений, переходы состояний, комбинаторное/pairwise-покрытие, сценарии, error guessing и исследовательские сессии. Проверяются не только позитивные пути, но и пустые, неверные, повторные, прерванные, устаревшие, запрещённые и восстановленные состояния.

6.3. Эвристическая оценка

Критерии — Конституция HIF, профиль и десять эвристик Якоба Нильсена. Эвристика показывает вероятную проблему, но сама не доказывает срыв задачи, распространённость или влияние.

Для значимых проверок желательно несколько экспертов. После сверки сохраняют:

  • нарушение критерия с прямым доказательством;
  • экспертную оценку удобства;
  • гипотезу для пользовательского исследования или operational data.

6.4. Когнитивное пошаговое исследование

Для каждого шага первого использования выясняют: поставит ли человек нужную подцель; заметит ли действие; свяжет ли его с результатом; покажет ли обратная связь прогресс. Предполагаемые знания фиксируются. Метод прогнозирует трудность, но не заменяет наблюдение за представителями аудитории.

6.5. Проверка с участниками

Заранее задаются вопросы исследования, профиль и набор участников, доступность участия, задачи, согласие, модерация, запись, анализ и stop rules. Задачи должны быть правдоподобными, целевыми и нейтральными.

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

6.6. Доступность

Нормативный критерий — WCAG 2.2, структура оценки — WCAG-EM. Сочетаются автоматические тесты, инспекция семантики, клавиатура, фокус, масштабирование, перекомпоновка и интервалы текста, цвет и принудительные системные цвета, уменьшение движения, имена, роли, состояния и сообщения, выполнение задач с программой экранного доступа, сенсорным и альтернативным вводом и, при нужном уровне утверждения, исследование с людьми с инвалидностью.

Предпочтительны нативные элементы HTML. При ARIA применимы требования WAI-ARIA. ARIA APG — полезное, но ненормативное руководство; его примеры не являются готовой дизайн-системой.

Автоматизация не устанавливает соответствие WCAG. Выборочный аудит не имеет права объявлять весь сайт соответствующим WCAG без полной области и методики.

Если заказ включает оценку соответствия требованиям доступности, публичное заявление, закупочные доказательства или передачу правового риска, заполните Реестр обеспечения доступности и соответствия.

6.6.1. Протокол для сайта государственного сектора Великобритании

Для сайта государственного сектора Великобритании аудит MUST дополнительно:

  1. определить ответственную государственную организацию и владельца услуги;
  2. сохранить действующее заявление о доступности, его границы, дату, известные ограничения, канал связи и порядок правоприменения;
  3. определить, что именно проверяется: веб-сайт, приложение, документ, интранет, сторонняя услуга или содержание, которое может быть исключено;
  4. использовать текущую техническую основу из официального руководства Великобритании;
  5. отделить результат технической проверки выборки от соответствия всего сайта;
  6. отделить нарушение WCAG от юридического вывода по Public Sector Bodies Accessibility Regulations, Equality Act или иному праву;
  7. записать заявленное исключение или оценку несоразмерного бремени, не принимая и не отвергая его юридическую силу;
  8. сообщить о барьере по доступному каналу, приложить доказательства и сохранить ответ и историю повторных проверок.

Официальное руководство Великобритании сейчас указывает уровень AA WCAG 2.2 и заявление о доступности как техническую основу, а также описывает границы, исключения, мониторинг и правоприменение. Технический аудитор MAY сообщать наблюдаемые факты и результаты проверки стандартов. Аудитор MUST NOT утверждать, что автоматический результат сам по себе доказывает нарушение закона, решение регулятора, небрежность, право на возмещение ущерба или оплату.

Коммерческое исправление MAY предлагаться отдельно и прозрачно. Угрозы, раздутые заявления об ответственности, искусственная срочность или требования оплаты на основании нерассмотренного обвинения запрещены.

6.7. Производительность и устойчивость

Раздельно используются field data и лабораторная диагностика. Условия устройства, сети, cache и запусков записываются; анализируется распределение, а не лучший запуск. Проверяются важные задачи, медленная/прерванная связь, сохранение фокуса, layout, ввода и подтверждённых результатов.

Core Web Vitals: LCP, INP, CLS. Текущие Google-пороги «good» на 75-м процентиле: LCP ≤ 2,5 с, INP ≤ 200 мс, CLS ≤ 0,1. Указываются источник, дата, группа страниц, класс устройства и покрытие. Lab-замер не является полевым Core Web Vital.

6.8. Адаптивность и браузеры

Матрица выводится из аудитории, support policy и риска. Она охватывает узкие, широкие и промежуточные размеры; ориентации; zoom и увеличение текста; mouse, keyboard, touch и alternative input; поддерживаемые движки; плотность пикселей; no-hover/coarse pointer/preferences; virtual keyboard, safe areas и viewport; печать/PWA, если это часть задачи.

Цель — эквивалентный доступ и последствия, а не пиксельное равенство. Неподдерживаемые комбинации перечисляются явно.

6.9. Контент и информационная архитектура

Проверяются язык аудитории и задач, иерархия/заголовки/landmarks/reading order, путь к цели и выход из ошибочного маршрута, поиск/zero results/filters, актуальность и дубли, предварительное раскрытие условий/цены/времени, понятность, постоянство терминов, локализация смысла и поведения, title и metadata. Для вопросов findability отдельно заказываются card sorting, tree testing, анализ поисковых логов или content testing.

6.10. Формы и транзакции

Для каждого поля устанавливаются необходимость, назначение и получатель данных, способ проверки, хранения, защиты и обновления. Проверяются eligibility, порядок и группировка, постоянные labels/instructions, обязательность и формат, autofill, paste, password managers, международный ввод, client/server validation, связь ошибки с полем и сводным сообщением, сохранение работы, проверка перед значимым действием, повторная отправка, честный progress/receipt и пути исправления/отмены.

6.11. Приватность и безопасность на границе UI

Это не аудит всей безопасности. Проверяются видимые элементы контроля и наблюдаемое браузером поведение:

  • раскрытие использования и передачи данных до действия;
  • симметрия принятия и отказа;
  • контекст и минимальность permissions;
  • понятность authentication/recovery/session expiry;
  • отсутствие ненужных запретов password manager, paste и autofill;
  • чувствительные значения в URL, исходнике, browser storage, analytics, ошибках и скриншотах;
  • последствия destructive/privileged actions;
  • утечки через ошибки, third-party embeds, logout и device state;
  • concealment, false urgency и asymmetric friction.

Наблюдения классифицируются по OWASP WSTG и передаются на отдельно разрешённую проверку безопасности. Эксплуатировать подозрение ради усиления продажи запрещено.

7. Доказательства

Каждый результат проверки содержит:

ID и заголовок
дата/время UTC
единица области, маршрут и состояние
сборка/выпуск
браузер, ОС, область просмотра/устройство, ввод, ассистивные технологии
роль, полномочия, обезличенное состояние учётной записи
предусловия и синтетические данные
точные шаги
ожидаемый результат и его источник
наблюдаемый результат
последствие для задачи/человека
вложения
критерии HIF и внешних стандартов
частота и знаменатель выборки
ограничения и уверенность

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

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

8. Структура результата проверки

Состояния: Verified, Intermittent, Systemic, Hypothesis, Not reproduced, Resolved, Accepted risk.

Серьёзность HIF:

  • S0 Blocker — задача невозможна, потеря контроля/данных или немедленный критический риск;
  • S1 Critical — высокая вероятность существенного вреда или исключения;
  • S2 Major — задача выполняется с серьёзной трудностью/ненадёжным recovery;
  • S3 Moderate — существенная проблема понимания или эффективности;
  • S4 Minor — локальное трение с малым последствием;
  • Observation — полезный сигнал, ещё не установленный как дефект.

Охват: R1 Isolated, R2 Limited, R3 Broad, R4 Systemic. Частота: F1 Rare, F2 Occasional, F3 Frequent, F4 Inevitable. Уверенность: C1 Low, C2 Medium, C3 High.

Серьёзность описывает последствия, а не стоимость или выгоду аудитора. Параметры не следует превращать в ложную точность. Для сортировки допустимо:

оценка риска = вес серьёзности × охват × частота × коэффициент уверенности
S0=5, S1=4, S2=3, S3=2, S4=1
R/F=1..4
C1=0,5, C2=0,75, C3=1

S0 всегда эскалируется немедленно. Итоговая оценка определяет только очередь, а не меру вреда, нарушения закона или соответствия.

При планировании отдельно добавляются ценность/срок, зависимость, диапазон работ и допущения, уверенность в решении, общая первопричина и цена проверки. Малочисленность затронутой группы не снижает риск для доступности или безопасности.

9. Рекомендация, приёмка и оценка

Рекомендация содержит проблему и задачу, критерий, нужный результат, варианты и компромиссы, затронутые системы, допущения, критерии приёмки, проверки, область регрессионной проверки и доказательство закрытия.

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

10. Ретест и регрессия

Повторяются исходные шаги и критерии приёмки в сопоставимой среде. Фиксируются сборка и дата, случаи, новое доказательство, остаточное ограничение, регрессии и статус. Новый снимок экрана не доказывает исправление. Общий компонент проверяется на представительных экземплярах, а рискованное изменение — на негативных путях, способах ввода и восстановлении.

11. Результаты для клиента

  1. Краткий документ для решений.
  2. Область, полномочия, среда и ограничения.
  3. Инвентаризация и реестр выборки.
  4. Матрица задач и покрытия.
  5. Приоритизированный реестр результатов проверки.
  6. Подробные результаты с воспроизводимыми доказательствами.
  7. План исправлений с допущениями.
  8. Приложения по доступности и производительности.
  9. Индекс доказательств и срок хранения.
  10. План ретеста и регрессии.
  11. Границы любых заявлений о соответствии.

Используются шаблон отчёта и тест-дизайн HIF.

12. Этичная коммерческая модель

Применяйте к заказу правила права, IP и платформенных референсов, а для материалов клиента, снимков экрана, кода, ресурсов и результатов исправлений — реестр очистки прав и выпуска. Письменное полномочие MUST покрывать тестируемые среды и способы сбора доказательств. Если аудитор не привлечён как квалифицированный юрист, наблюдение о правовом риске MUST описываться как ограниченный риск, требующий проверки специалистом, а не как вывод о том, нарушил клиент закон или нет.

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

Коммерческая ценность — достоверный диагноз и проверяемое улучшение, а не зависимость клиента.

13. Границы формулировок

  • «Не наблюдалось в проверенной выборке и среде», не «отсутствует».
  • «Проверенные страницы прошли указанные критерии», не «сайт соответствует WCAG».
  • «Лабораторный результат в данных условиях», не «у пользователей столько».
  • «Экспертная оценка указывает», не «пользователи не могут».
  • «Подозрение на проблему безопасности на границе интерфейса; нужна проверка», не «система небезопасна».
  • «Оценка по перечисленным допущениям», не фиксированная цена при неизвестном объёме.

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

14. Контроль качества

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

15. Официальные англоязычные первоисточники