요약

  • W3C가 2026년 8월 27일 새 SVG Accessibility API Mappings Working Draft를 공개했다. 초안 자체가 이전 Working Draft를 2018년 5월 10일판으로 명시하며, 그 간격은 3,031일이고 실질적 기술 변경을 기록하고 있다.
  • 제안된 SVG Working Group 헌장의 공개 정제 과정에서 7월 4일 의견이 SVG AAM에 대한 구체적 마일스톤과 테스트 약속을 요청했다. 반영 패치는 “undetermined(미정)”를 “aiming at progressing on testing(테스트 진행을 목표로 함)”으로 바꿨다.
  • 이 표현은 방향에 대한 솔직한 신호이지만 감사 가능한 마일스톤은 아니다. 통제 개정판, 기능 목록, 테스트 스위트 커밋, 커버리지 상태, 구현 쌍, 책임 주체나 검토 시점을 어느 것도 특정하지 않는다.
  • 제안된 헌장에는 이미 타당한 일반 기준이 담겨 있다. 공개 테스트, 초기 단계부터의 테스트 계획, Candidate Recommendation 이후 단계로 진전하기 전 독립적이고 상호운용 가능한 구현 두 개가 그것이다. 빠진 단계는 이 기준을 이 산출물에 묶는 일이다.
  • W3C Process는 “이용 가능한 경우에 한해” 예상 마일스톤 날짜를 요구한다. 따라서 날짜의 부재는 그 자체로 절차 위반, 방임 또는 불성실의 증거가 아니다.
  • 얇은 테스트 마일스톤 영수증이 있으면 독자가 새 공개물과 테스트 커버리지, 구현 경험, 성숙도 결정을 구분할 수 있으며, 새로운 승인 게이트를 만들 필요는 없다.

바뀐 숫자는 헌장에 없었다

8년 3개월 17일 동안, SVG Accessibility API Mappings의 날짜가 찍힌 W3C 공개 기록은 같은 Working Draft를 가리켰다.2018년 5월 10일판은 W3C가2026년 8월 27일판을 발행할 때까지 마지막 공개 초안이었다. 새 문서는 이 역사를 담백하게 밝힌다. 간격은 3,031일이다.

이 수치를 활동 부재의 동의어로 쓰면 안 된다./TR스냅샷이 오래된 동안 공개 저장소는 움직일 수 있고, 편집자는 새 날짜 공개 없이 텍스트를 고칠 수 있다. 2026년 초안은 2018년 이후 접근 가능 이름(accessible name) 계산, SVG 역할, 요소·속성 매핑, 숨김·표현용 콘텐츠 처리 등의 실질적 변경을 나열한다. 이 공개는 구현자와 검토자에게 새 고정 참조점을 제공한다. 그것은 진전이다.

동시에 이는 Working Draft다. 문서 자체의 상태 섹션은 공개가 W3C나 회원의 승인을 의미하지 않으며 문서는 갱신·대체·폐기될 수 있다고 경고한다. Working Draft는 특정 텍스트가 검토용으로 공개됐음을 증명할 수 있다. 그러나 그 사실만으로 규범적 기능에 테스트가 존재하는지, 테스트가 그 기능을 커버하는지, 독립 제품이 통과하는지, 문서가 더 높은 성숙도 단계에 준비됐는지 증명할 수는 없다.

공개 9일 전, 다른 공개 기록이 바뀌었다. 제안된 SVG Working Group 헌장은W3C Strategy issue 559에서 정제를 거쳤다. 7월 4일공개 의견은 SVG AAM의 2018년 Working Draft와 “undetermined” 예상 완료를 지적하며 구체적 마일스톤과 테스트 약속을 요청했다. 8월 18일 SVG 팀 연락 담당자는정제가 끝났고제안이 반영됐다고 밝혔다.

불변의반영 커밋은 이례적으로 판독이 쉽다. 세 줄을 바꿨다. 하나는 헌장 링크를 고쳤고, 하나는 WHATWG 협의에 관한 문장을 확장했고, 하나는 SVG AAM의 예상 완료를 “undetermined”에서 “aiming at progressing on testing”으로 바꿨다.해당 커밋 시점의 헌장은 여전히 2018년 초안을 채택 초안으로 명명한다. 이후의 Working Draft가 이 참조를 낡게 만들었지만, 더 중요한 문제는 의미론적이다. 방향이 미지 상태를 대체했다. 측정 가능한 상태는 아무것도 대체하지 못했다.

의도는 유용하지만 검토를 닫을 수 없다

“aiming at progressing on testing”은 빈 언어가 아니다. 테스트에 주목이 기대된다고 회원에게 알린다. 그룹이 지킬 수 없을 날짜를 발명하지 않는다. 기여자, 구현 약속, 그룹 간 협업이 불확실한 상황에서 얻을 수 있는 가장 솔직한 진술일 수 있다.

그러나 이 문구는 마일스톤이 존재하는 이유가 되는 질문들에 답할 수 없다. 어떤 초안을 테스트하는가? 어떤 규범적 기능이 범위인가? 통제 테스트 스위트는 어디에 있는가? 기능 목록 중 어느 정도가 테스트에 매핑됐는가? 어떤 구현이 독립으로 인정되는가? 어떤 결과가 성숙도 전환을 정당화하는가? 미해결 조치의 소유자는 누구이며, 근거를 언제 다시 검토하는가?

이 구분이 중요한 이유는 “테스팅”이 여러 활동을 지칭할 수 있기 때문이다. 편집자는 회귀 테스트 하나를 추가할 수 있다. 기여자는 테스트 저장소를 열 수 있다. 워킹 그룹은 테스트 계획을 채택할 수 있다. 브라우저는 일련의 어설션을 통과할 수 있다. 두 접근성 스택이 통제된 조건에서 같은 의미를 노출할 수도 있다. 각각은 실제 작업이지만, 서로 교환할 수 있는 근거 상태는 아니다.

2026년 9월 30일까지 운영되는현행 2024 SVG 헌장은 이전 조건을 직접 보여준다. 이 헌장은 SVG AAM을 2018년 5월 10일 Working Draft로, 예상 완료를 미정으로 나열한다. 제안된 후속 헌장은 테스팅을 명명함으로써 신호를 개선한다. 그러나 두 헌장을 비교하는 검토자는 여전히 어떤 관측 가능한 사건이 새 문구를 “달성된 진전”으로 전환할지 알 수 없다.

그것이 거버넌스 공백이다. 빠진 프로그램보다는 작고, 빠진 날짜보다는 크다. 그룹에는 산출물, 공개 초안, 저장소, 일반 성공 기준이 있다. 헌장 대면 기록에 없는 것은 이들을 묶는 계층이다.

일반 성공 기준은 이미 강력하다

제안된 헌장은 테스트를 부수적 사후 처리로 다루지 않는다. 산출물에 테스트 스위트와 구현 보고서를 포함하고, 일반 성공 기준은 모든 기능에 대해 공개 이용 가능한 테스트를 요구하고, 초안 최초 단계부터의 테스트 계획을 장려하며, 사양이 Candidate Recommendation을 넘어 진전하기 전에 각 기능의 독립적이고 상호운용 가능한 구현 최소 두 개를 요구한다.

이 조항들은 테스팅이 무시됐다는 어떤 주장에도 중요한 반증이다. 이는 구현 경험의 적절성을 맥락적 검토로 다루는W3C Process의 구현 경험 논의와도 일치한다. Process는 모든 기능이 구현됐는지, 구현이 상호운용하는지, 구현자가 독립적인지, 작업이 단순 실험 환경을 넘어 배포됐는지, 생태계의 어느 수준이 커버되는지, 어떤 문제가 보고됐는지를 묻는다. 또한 테스트 계획은 일찍 시작할 때 가장 효과적인 경우가 많다고 관찰한다.

약점은 일반 표준의 부재가 아니다. 표준이 아직 SVG AAM에 대해 실체화되지 않았다는 점이다. 헌장 전역의 한 문장은 모든 사양에게 궁극적 성공이 어떤 모습이어야 하는지 말해줄 수 있다. 그러나 현재 SVG AAM의 기능 목록, 그에 대응하는 테스트, 특정 검토 시점에 이용 가능한 구현 근거를 특정하지는 않는다.

테스트 수가 두 배가 됐다고 보고하는 그룹을 상상해 보라. 새 테스트가 이미 테스트된 동작 주변에 몰려 있다면 커버리지가 그대로인 채 고무적일 수 있다. 광범위한 기능 커버리지를 보여주는 스위트를 상상하라. 모든 결과가 하나의 엔진에서, 또는 구현을 공유하는 제품들에서 나온다면 그것으로는 상호운용성을 입증하지 못한다. 독립적인 두 제품의 통과를 상상하라. 버전, 운영 환경, 보조 기술 조합, 제외 사항이 기록되지 않으면 그 결과는 재현 불가능할 수 있다.

따라서 기준에는 더 강한 형용사가 아니라 근거 색인이 필요하다. 제안된 헌장은 이미 목적지를 선택했다. 산출물별 마일스톤은 대중에게 SVG AAM이 그 경로에서 어디쯤 있는지 보여주어야 한다.

“이용 가능한 경우”는 허점이 아니라 절제다

W3C Process의 워킹 그룹 헌장 요건은 범위와 성공 기준, 기간, 산출물, 그리고 이용 가능한 경우 예상 마일스톤 날짜를 요구한다. 이 단서가 결정적이다. 공개 기록은 SVG AAM의 날짜 부재 자체가 절차 위반이라는 주장을 뒷받침하지 않는다.

이 절제는 보존되어야 한다. 표준화 작업은 자원봉사 역량, 구현자의 우선순위, 기술적 의존성, 예측을 무의미하게 만들 수 있는 발견에 의존한다. 통제의 외견을 만족시키기 위해 채택된 날짜는 피상적 완성을 유도하고, 불확실성을 숨기고, 설명 없는 또 하나의 놓친 약속으로 늙어갈 수 있다.

그러나 “날짜 불가”와 “마일스톤 불가”는 다른 명제다. 그룹은 독립적인 두 구현이 언제 기능 집합을 통과할지 예측할 수 없으면서도, 어느 개정판이 통제하는지, 기능이 어떻게 목록화되는지, 어떤 스위트가 사용되는지, 오늘 어떤 근거가 존재하는지, 질문이 언제 다시 검토될지를 문서화할 수 있다. 검토 날짜조차 확정할 수 없다면, 그 이유와 재고를 촉발할 사건을 기록할 수 있다.

그래서 해결책은 “헌장에 기한을 넣어라”가 되어서는 안 된다. 기한은 기술 프로그램에 거짓 정밀성을 밀반입한다. 더 유용한 요건은 현재 근거 상태에 대한 영수증이며, 날짜를 정할 수 없을 때마다 명시적 사유를 포함하는 것이다.

공개, 커버리지, 상호운용성은 별개의 게이트다

Lu Heng의Running-Code Primacy는 이 기록을 읽는 좁은 규율을 제공한다. 공개, 권고, 구현, 검증, 실제 사용은 구분 가능하게 유지되어야 한다는 것이다. 이것은 거버넌스 렌즈이며, SVG 또는 ARIA 그룹이 무엇을 했는가에 대한 근거가 아니다.

여기에 적용하면, 이 렌즈는 정반대의 두 오류를 막는다. 첫째는 2026년 Working Draft가 아직 가동 중인 시스템에서 입증되지 않았다는 이유로 일축하는 것이다. 공개는 검토 가능한 기술적 주장을 고정하고 구현을 조율할 수 있다. 그것은 가치 있다. 둘째는 새 공개물을, 그 매핑이 독립적인 접근성 스택 전반에서 일관되게 작동한다는 근거의 대역으로 두는 것이다. 문서는 스스로를 실행하지 않는다.

같은 구분은 테스팅 내부에도 필요하다. 테스트의 존재는 어설션이 부호화됐음을 증명한다. 기능-테스트 매핑은 의도된 커버리지를 보여준다. 기록된 실행은 특정 구현이 명시된 환경에서 어떻게 동작했는지 보여준다. 독립적이고 비교 가능한 실행들은 상호운용성 주장을 뒷받침할 수 있다. 구현 보고서는 그 근거를 성숙도 결정을 위해 집계한다. 이 단계들을 압축하면 가장 눈에 띄는 산출물인 새 Working Draft가 실제로 획득한 것보다 더 큰 권위를 떠안게 된다.

SVG AAM의 경우 환경은 특히 중대하다. 이 사양은 SVG 의미를 접근성 API에 매핑한다. 근거에는 브라우저 엔진, 운영체제 접근성 계층, 보조 기술이 각각의 버전과 구성과 함께 개입할 수 있다. 한 조합의 통과가 다른 조합의 통과로 자동 이어지지는 않는다. 이 글은 어떤 조합이 필요하고 어떤 조합이 현재 작동하는지 주장하지 않는다. 마일스톤이 공개 결론이 의존하는 조합들을 특정해야 한다고만 주장한다.

두 그룹이 기록에 등장한다; 그래서 보관 책임은 필드가 된다

현행 기록은 하나의 조직적 레이블 안에 깔끔히 들어맞지 않는다.ARIA Working Group 공개물 페이지는 8월 27일 SVG AAM 초안을 나열하고 ARIA를 전달 그룹으로 명명한다. 제안된 SVG 헌장은 이 사양이 ARIA와의 협력으로 개발될 것이라고 말한다. 2024년저장소 커밋은 사양 작업을 ARIA 모노레포로 옮기면서 이전 저장소는 이슈 추적용으로 열어 두고 Editor’s Draft 주소를 유지했다. 현재ARIA 저장소 디렉터리는 이 편집 보관 책임을 그대로 드러낸다.

이 어느 것도 논쟁적인 권한 이전의 증거가 아니며, 하나를 만들어 낼 필요도 없다. 협업과 저장소 보관은 정상이다. 그러나 그래서 소유 필드가 더 중요해진다. SVG 헌장만, ARIA 공개물 페이지만, 또는 오래된 이슈 저장소만 보는 사람은 결함을 보고하고, 테스트를 제안하고, 결과를 요청할 곳에 대해 세 가지 다른 인상을 가질 수 있다.

따라서 테스트 마일스톤은 각 다음 조치에 대해 책임 그룹이나 소유자를 명명해야 한다. 한 그룹은 헌장 전달을, 다른 그룹은 편집 변경을, 공동 태스크 포스는 테스트 검토를, 구현자는 자신의 결과 제출을 담당할 수 있다. 영수증은 이 역할들을 평평하게 펴서는 안 된다. 탐색 가능하게 만들어야 한다.

10개 필드 영수증이면 충분하다

빠진 장치는 얇게 유지될 수 있다. 새 데이터베이스, 대시보드, 승인 위원회가 될 필요는 없다. 산출물 행에서 링크된 버전 관리 페이지나 이슈가 10개 필드를 담을 수 있다.

첫째, 통제 사양 URL과 불변 개정판을 특정한다. 날짜가 찍힌/TR공개물도 유용하지만, 테스트는 더 이후의 Editor’s Draft 커밋을 겨냥할 수 있다. 영수증은 어느 쪽이 결과를 지배하는지 밝혀야 한다.

둘째, 규범적 기능 목록과 그 버전을 특정한다. 유한한 목록이 없으면 늘어나는 테스트 수에는 분모가 없다.

셋째, 테스트 스위트 저장소와 통제 커밋을 명명한다. 가변적 기본 브랜치는 개정판이 기록되지 않으면 이전 주장을 재현할 수 없다.

넷째, 기능-테스트 매핑과 커버리지 상태를 공개한다. 매핑은 커버됨, 부분 커버됨, 미테스트, 제외, 차단된 기능을 구분해야 하며, 이들을 백분율로 압축해서는 안 된다.

다섯째, 구현 정체성, 버전, 관련 환경을 기록한다. 두 결과가 같은 엔진을 공유하거나 접근성 경로가 보고되지 않은 방식으로 다르다면 “두 구현”은 무의미하다.

여섯째, 상호운용성 결과를 진술하고 재현 가능한 근거에 링크한다. 이는 불완전할 수 있다. 정직한 부분 결과가 자격 없는 진전 레이블보다 유용하다.

일곱째, 알려진 제외 사항, 실패, 미해결 이슈를 나열한다. 통과하는 표면만 세면 마일스톤은 오도적으로 변한다.

여덟째, 각 다음 조치를 책임 그룹이나 명명된 소유자에 붙인다. 책임은 보이지 않게 되지 않고 분산될 수 있다.

아홉째, 날짜가 찍힌 검토 시점 또는 날짜를 정할 수 없다는 명시적 사유를, 재검토를 촉발할 사건과 함께 제시한다. 이는 Process의 단서를 회피하지 않고 보존한다.

열째, 그 근거가 뒷받침할 수 있는 성숙도 또는 공개 결정을 명명한다. Editor’s Draft 검토, Candidate Recommendation 전환, 구현 보고서를 위해 수집된 테스트는 서로 다른 질문에 답한다.

영수증은 통상적 증거적 의미에서 추가 전용이어야 한다. 이후 상태가 이전 상태를 대체하되 삭제하지 않는다. 실패한 테스트는 통과로 바뀔 수 있다. 기능은 제거될 수 있고, 구현은 철회할 수 있다. 그 순서를 유지하면 결정이 이해 가능해지고, 현재의 녹색 요약이 그것이 어떻게 달성됐는지를 지워버리는 일을 막는다.

2026년 초안은 내일의 증명을 빌리지 않고도 공로를 인정받아야 한다

표준 거버넌스는 양방향의 과장으로 자주 실패한다. 긴 공개 공백은 작업이 존재하더라도 방임의 서사가 된다. 새 초안은 구현 근거가 열려 있음에도 완성의 서사가 된다. SVG AAM은 공개 기록은 극적으로 바뀐 반면 헌장 마일스톤은 문법적으로만 바뀌었기 때문에 두 오류 모두를 초대한다.

공정한 독해는 더 정밀하다. 8월 27일 초안은 의미 있는 공개 산출물이다. 8년 된 검토 스냅샷을 대체하고 기술적 변경을 검토에 노출한다. 정제 패치 역시 하나의 응답이다. “undetermined”는 더 이상 홀로 서 있지 않다. 테스팅이 의도된 방향으로 명명됐다.

그러나 이 문구는 기록된 포부지, 달성이 아니다. 구현자에게 오늘 어떤 테스트가 중요한지, 접근성 전문가에게 어떤 플랫폼 조합이 관측됐는지, 헌장 검토자에게 무엇이 여전히 차단됐는지, 회원에게 다음 성숙도 단계를 뒷받침할 근거가 무엇인지 말해줄 수 없다. 이 질문들에는 완성의 보증이 필요 없다. 공유된 근거 주소가 필요하다.

그 주소를 공개하는 것은 SVG AAM에 새 거부권을 만들지 않는다. 논평자가 그룹의 일정을 명령하게 하지 않는다. 불완전한 테스트를 실패 판정으로 바꾸지 않는다. 단지 공개, 테스팅, 커버리지, 구현, 성숙도가 같은 모호한 상태 단어 안에 함께 머무는 일을 멈춘다.

3,031일 후의 공백은 이제 공개 계층에서 닫혔다. 다음으로 유용한 숫자는 또 하나의 문서 간격이 아니다. 테스트와 독립 구현 근거를 검열할 수 있는 규범적 기능의 버전 관리된 개수, 그리고 아직 주장할 수 없는 기능들의 명시적 목록이다.

출처

  1. ARIA 저장소의 SVG AAM 디렉터리
  2. 반영 커밋 806338 시점의 제안된 SVG Working Group 헌장
  3. 커밋 806338: 정제 제안 반영
  4. W3C Strategy issue 559
  5. 테스트 마일스톤을 요청한 공개 정제 의견
  6. 팀 연락 담당자의 정제 종료 의견
  7. SVG AAM 작업을 ARIA 모노레포로 옮긴 커밋
  8. Lu Heng, Running-Code Primacy
  9. 현행 2024 SVG Working Group 헌장
  10. ARIA Working Group 공개물
  11. W3C Process: 워킹 그룹 및 인터레스트 그룹 헌장
  12. W3C Process: 구현 경험
  13. SVG Accessibility API Mappings Working Draft, 2018년 5월 10일
  14. SVG Accessibility API Mappings Working Draft, 2026년 8월 27일