Кратко

  • Новый Working Draft SVG Accessibility API Mappings опубликован 27 августа 2026 года. Сам документ называет предыдущей версией проект от 10 мая 2018 года: прошло 3 031 день, и в новом тексте зафиксированы существенные технические изменения.
  • Во время открытого уточнения следующей хартии SVG комментарий от 4 июля потребовал конкретного этапа и обязательства по тестам. Принятый патч заменил «не определено» на «стремимся продвигаться в тестировании».
  • Новая фраза задаёт приоритет, но не называет контрольную редакцию, перечень функций, коммит набора тестов, состояние покрытия, независимые реализации, владельца действий или срок пересмотра. Поэтому завершение этапа по ней проверить нельзя.
  • В проекте хартии уже есть сильные общие критерии: открытые тесты, раннее планирование и две независимые совместимые реализации перед продвижением дальше Candidate Recommendation. Не хватает привязки этих правил к SVG AAM.
  • W3C Process требует ожидаемые даты этапов лишь «когда они доступны». Отсутствие даты само по себе не доказывает нарушения, заброшенности или недобросовестности.
  • Короткая версионируемая квитанция этапа могла бы отделить публикацию от покрытия, опыта реализации и решения о зрелости, не создавая нового органа согласования.

Длинный интервал относится к публикациям, а не ко всей работе

Число 3 031 легко превратить в обвинение: восемь лет ничего не происходило, а затем документ внезапно ожил. Источники не позволяют делать такой вывод. Датированный снимок /TR способен оставаться прежним, пока редакторская версия и репозитории меняются.

Действующая хартия SVG 2024 года началась 27 июня 2024 года и заканчивается 30 сентября 2026 года. Она указывает SVG Accessibility API Mappings как Working Draft, принятый 10 мая 2018 года, а ожидаемое завершение — как неопределённое. Эта строка подтверждает состояние хартии, но не отсутствие редакторской деятельности.

Следующую хартию открыто уточняли в задаче W3C Strategy № 559. В комментарии от 4 июля сопоставили проект 2018 года и неопределённый срок, после чего попросили конкретный этап и обязательство по тестированию. 18 августа контактное лицо сообщило о завершении уточнения и включении предложений.

Неизменяемый коммит 806338 показывает точный масштаб правки. Изменились три строки: одна исправила ссылку, другая расширила формулировку о координации с WHATWG, третья заменила для SVG AAM «undetermined» на «aiming at progressing on testing». Хартия на этом коммите по-прежнему ссылалась на проект 2018 года.

Через девять дней появился Working Draft от 27 августа 2026 года. В нём прямо указано, что прошлой публикацией был Working Draft от 10 мая 2018 года. Между датами — ровно 3 031 день.

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

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

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

Намерение не содержит условия приёмки

Фраза о продвижении тестирования лучше голого «не определено». Она показывает направление и не придумывает дату при неизвестных ресурсах, приоритетах производителей и разделении работ между группами. Такая осторожность может быть честнее календарной точности.

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

Само слово «тестирование» объединяет разные действия. Создать репозиторий — подготовка инфраструктуры. Добавить тест — вклад. Принять план тестирования — решение группы. Связать нормативные требования с проверками — составить карту покрытия. Запустить набор в определённой среде — получить данные об одной реализации. Сопоставить две действительно независимые реализации — подготовить основание для вывода о совместимости. Свести доказательства в отчёт — дать материал для решения о зрелости.

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

Именно поэтому направление работы ещё не является этапом. Оно не устанавливает момент, когда слово «продвигаемся» можно заменить проверяемым «достигли».

Общий критерий успеха уже существует

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

Это существенное возражение против версии, будто тестированием пренебрегают. Требования согласуются с разделом W3C Process об опыте реализации. Там достаточность не сводится к проценту: учитываются реализация каждой функции, взаимная совместимость, независимость разработчиков, использование за пределами эксперимента, охваченные уровни экосистемы и сообщённые проблемы. Раннее планирование тестов часто считается наиболее эффективным.

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

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

Оговорка «когда доступны» не является лазейкой

Правила W3C Process для хартий требуют указать область, критерии успеха, продолжительность, результаты и ожидаемые даты этапов, когда такие даты доступны. Оговорка принципиальна. Зафиксированные источники не дают оснований объявлять отсутствие даты по SVG AAM нарушением процесса.

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

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

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

Между текстом и работающим продуктом несколько отдельных переходов

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

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

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

В случае SVG AAM путь наблюдения может включать браузерный движок, интерфейс доступности операционной системы и вспомогательную технологию. Версии и настройки способны влиять на результат. Здесь не утверждается, какие комбинации обязательны или какие проходят сегодня. Требование скромнее: публичный вывод должен назвать среды, на которых он основан.

SVG и ARIA делают поле ответственности обязательным

Публичные следы распределены между двумя группами и несколькими репозиториями. Страница публикаций ARIA Working Group включает проект от 27 августа и называет ARIA группой-поставщиком. Проект хартии SVG говорит о совместной разработке с ARIA. В 2024 году коммит в прежнем репозитории перенёс спецификацию в монорепозиторий ARIA, оставил старый репозиторий открытым для задач и сохранил адрес Editor’s Draft. Текущий каталог SVG AAM в ARIA показывает место редакционной работы.

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

Достаточно десяти полей

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

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

Далее нужны названия и версии реализаций, значимые параметры среды, воспроизводимый результат совместимости, известные исключения, ошибки и открытые вопросы. Каждое следующее действие связывается с группой или ответственным. Указывается дата пересмотра либо явная причина её отсутствия и событие-триггер. Наконец, квитанция называет решение, которому служат данные: проверка Editor’s Draft, переход зрелости или отчёт о реализациях.

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

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

Источники

  1. Каталог SVG AAM в репозитории ARIA
  2. Проект хартии SVG на коммите 806338
  3. Коммит 806338 с принятыми предложениями
  4. Задача W3C Strategy № 559
  5. Комментарий с требованием этапа тестирования
  6. Комментарий о завершении уточнения
  7. Коммит о переносе SVG AAM в монорепозиторий ARIA
  8. Lu Heng, Running-Code Primacy
  9. Действующая хартия SVG 2024 года
  10. Публикации ARIA Working Group
  11. W3C Process: хартии групп
  12. W3C Process: опыт реализации
  13. SVG Accessibility API Mappings, Working Draft от 10 мая 2018 года
  14. SVG Accessibility API Mappings, Working Draft от 27 августа 2026 года