Статический анализ компонентов

Статический анализ компонентов — это метод проверки корректности семантики и доступности интерфейсов на этапе разработки без выполнения кода в браузере. Анализ осуществляется на основе структуры DOM, ролей ARIA и их разрешённых атрибутов.

Библиотека aria-query предоставляет набор структурированных данных о ролях, состояниях и свойствах ARIA, которые могут использоваться инструментами анализа для выявления нарушений стандартов доступности.

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

Роль aria-query в анализе компонентов

Библиотека содержит таблицы соответствий между:

  • HTML-элементами
  • ролями ARIA
  • разрешёнными свойствами и состояниями
  • обязательными атрибутами
  • допустимыми контекстами использования

Эти данные используются инструментами:

  • линтерами
  • анализаторами JSX/HTML
  • системами проверки доступности
  • трансформерами AST

Фактически библиотека представляет собой машиночитаемую базу знаний спецификации ARIA.

Основные экспортируемые структуры:

Экспорт Назначение
roles список всех ролей ARIA
aria список всех ARIA-атрибутов
elementRoles соответствие HTML-элементов ролям
roleElements обратное соответствие ролей элементам

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

Проверка допустимых ролей

Одной из базовых задач статического анализа является проверка корректности назначения ролей.

Каждый HTML-элемент имеет:

  • неявную (implicit) роль
  • список разрешённых явных ролей

Например, элемент <button> уже обладает ролью button. Попытка назначить ему несовместимую роль может нарушить семантику.

Пример извлечения данных о роли:

import { roles } from "aria-query";

const buttonRole = roles.get("button");

console.log(buttonRole);

Объект роли содержит:

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

Такие данные позволяют линтерам выявлять ошибки вроде:

<button role="heading">

Роль heading не предназначена для элемента button, поэтому анализатор может зафиксировать нарушение.

Проверка разрешённых ARIA-атрибутов

Каждая роль ARIA поддерживает строго определённый набор свойств. Использование атрибутов вне допустимого набора является ошибкой.

Пример некорректного кода:

<div role="button" aria-level="2"></div>

Атрибут aria-level используется только для ролей заголовков.

С помощью aria-query можно определить допустимость атрибута.

import { roles } from "aria-query";

const role = roles.get("button");

console.log(role.props);

Поле props содержит список поддерживаемых свойств:

aria-expanded
aria-pressed
aria-disabled
...

Если анализатор обнаруживает атрибут вне этого списка, фиксируется ошибка доступности.

Проверка обязательных атрибутов

Некоторые роли требуют наличия обязательных ARIA-атрибутов.

Например:

  • checkbox требует aria-checked
  • slider требует aria-valuemin, aria-valuemax, aria-valuenow

Информация о таких требованиях содержится в поле requiredProps.

import { roles } from "aria-query";

const checkboxRole = roles.get("checkbox");

console.log(checkboxRole.requiredProps);

Результат:

{
  "aria-checked": null
}

Статический анализ может выявлять ситуации:

<div role="checkbox"></div>

Отсутствие aria-checked означает неполную реализацию роли.

Анализ соответствия HTML-элементов ролям

Библиотека содержит карту elementRoles, описывающую какие роли допустимы для конкретных HTML-элементов.

Пример получения ролей для элемента:

import { elementRoles } from "aria-query";

for (const [element, roles] of elementRoles) {
  console.log(element, roles);
}

Элемент описывается объектом:

{
  name: "button"
}

Связанные роли:

Set { "button" }

Такая информация позволяет проверять:

  • назначение недопустимых ролей
  • переопределение нативной семантики
  • использование ролей там, где они не нужны

Проверка избыточных ролей

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

Пример:

<button role="button">Save</button>

Назначение роли button избыточно, поскольку она уже присутствует по умолчанию.

Использование aria-query позволяет определить, что:

<button> → implicit role: button

Следовательно, линтер может предложить удалить явное указание роли.

Анализ компонентов React и JSX

Статический анализ особенно важен для компонентов React, поскольку JSX скрывает итоговую структуру DOM.

Типичный процесс анализа включает несколько этапов:

  1. Разбор исходного кода в AST
  2. Поиск JSX-элементов
  3. Определение имени HTML-тега
  4. Извлечение ARIA-атрибутов
  5. Сопоставление с данными aria-query

Пример анализа JSX-элемента:

<div role="slider" aria-valuenow="50"></div>

Анализатор выполняет проверки:

  • существует ли роль slider
  • разрешён ли элемент div
  • присутствуют ли обязательные свойства
  • корректны ли значения атрибутов

При отсутствии aria-valuemin или aria-valuemax фиксируется ошибка.

Анализ контекстных ограничений

Некоторые роли допустимы только внутри определённых контейнеров.

Примеры:

  • menuitem должен находиться внутри menu
  • listitem — внутри list
  • option — внутри listbox

Информация о таких ограничениях содержится в свойствах роли:

requiredContextRole
requiredOwnedElements

Пример проверки:

const menuItem = roles.get("menuitem");

console.log(menuItem.requiredContextRole);

Результат:

["menu", "menubar"]

Анализатор может обнаружить ошибку:

<div role="menuitem"></div>

Такой элемент не имеет родительского menu.

Проверка поддерживаемых состояний

ARIA-роли могут поддерживать различные состояния:

  • aria-selected
  • aria-expanded
  • aria-pressed
  • aria-current

Список допустимых состояний также определяется через props.

Например:

const tabRole = roles.get("tab");

console.log(tabRole.props);

Результат включает:

aria-selected
aria-expanded

Если компонент использует неподдерживаемое состояние, это фиксируется как ошибка.

Проверка валидности значений ARIA

Некоторые ARIA-атрибуты принимают ограниченный набор значений.

Например:

aria-checked = true | false | mixed

Информация о типе значения хранится в таблице aria.

Пример:

import { aria } from "aria-query";

const attr = aria.get("aria-checked");

console.log(attr.type);

Тип может быть:

  • boolean
  • tristate
  • token
  • number

Анализатор может обнаружить ошибку:

<div role="checkbox" aria-checked="maybe"></div>

Значение maybe не соответствует допустимому типу.

Интеграция с линтерами

Наиболее распространённый сценарий использования aria-query — создание правил для линтеров.

Например, библиотека eslint-plugin-jsx-a11y использует её для реализации правил:

  • aria-props
  • aria-role
  • aria-proptypes
  • role-has-required-aria-props
  • no-redundant-roles

Каждое правило:

  1. анализирует AST
  2. извлекает роли и атрибуты
  3. сопоставляет их с данными aria-query
  4. генерирует предупреждение или ошибку

Такой подход обеспечивает автоматическую проверку доступности интерфейсов на этапе разработки.

Использование обратных соответствий ролей

Карта roleElements позволяет определить, какие HTML-элементы могут реализовывать конкретную роль.

Пример:

import { roleElements } from "aria-query";

const elements = roleElements.get("checkbox");

console.log(elements);

Результат может включать:

input[type="checkbox"]

Это позволяет выявлять случаи, когда разработчик использует сложную ARIA-реализацию там, где существует нативный HTML-элемент.

Например:

<div role="checkbox" aria-checked="true"></div>

Анализатор может предложить заменить конструкцию на:

<input type="checkbox">

Анализ наследования ролей

В спецификации ARIA роли могут наследовать свойства других ролей.

Например:

switch → checkbox

Это означает, что switch наследует многие свойства checkbox.

Информация о наследовании содержится в поле:

superClass

Пример:

const switchRole = roles.get("switch");

console.log(switchRole.superClass);

Анализатор должен учитывать наследование при проверке допустимых свойств и состояний.

Архитектура статического анализатора

Инструмент анализа доступности на основе aria-query обычно состоит из следующих модулей:

1. Парсер

Преобразует код в AST.

2. Сканер JSX/HTML

Находит элементы и их атрибуты.

3. Семантический анализатор

Использует данные aria-query для проверки:

  • ролей
  • свойств
  • контекстов
  • значений

4. Система отчётов

Формирует:

  • предупреждения
  • ошибки
  • рекомендации

Ограничения статического анализа

Несмотря на широкие возможности, статический анализ имеет ограничения.

Некоторые ошибки невозможно выявить без выполнения кода:

  • динамическое изменение ролей
  • условный рендеринг компонентов
  • манипуляции DOM через JavaScript
  • вычисляемые значения ARIA-атрибутов

Поэтому статический анализ часто комбинируется с:

  • runtime-тестами доступности
  • автоматическими тестами интерфейсов
  • аудитом accessibility-инструментами браузеров

Практическая ценность aria-query

Использование библиотеки позволяет создавать инструменты, которые:

  • автоматически проверяют доступность интерфейсов
  • предотвращают ошибки ARIA ещё на этапе разработки
  • стандартизируют семантику компонентов
  • помогают поддерживать требования WCAG

Статический анализ на основе aria-query стал фундаментом большинства современных инструментов проверки доступности в экосистеме JavaScript.

Оглавление