현대의 웹 플랫폼은 단순한 하이퍼텍스트 문서를 소비하는 공간에서 벗어나, 데스크톱 네이티브 애플리케이션에 필적하는 고성능 연산과 복잡한 그래픽 렌더링을 수행하는 거대한 플랫폼으로 진화했습니다. 중심에는 자바스크립트 엔진을 우회하여 네이티브에 가까운 속도로 코드를 실행하는 **WebAssembly(Wasm)**와 화면 픽셀을 직접 조작하는 Canvas API가 있습니다. 하지만 이러한 렌더링 방식 이면에는 '웹 접근성의 완전한 차단'이라는 치명적인 기술적 부채가 존재합니다. ¹

DOM 파이프라인 우회와 접근성 트리의 단절

기존의 브라우저 렌더링은 HTML DOM을 구성할 때 보조 기기(Screen Reader 등)가 읽을 수 있도록 접근성 트리(Accessibility Tree)를 별도로 구축합니다. 그러나 Wasm과 Canvas 기반의 독자적인 UI 렌더링 엔진들은 브라우저가 제공하는 시맨틱 파이프라인과 inert 속성 같은 네이티브 포커스 관리 기능의 혜택을 받을 수 없습니다. 브라우저 입장에서 <canvas> 내부는 어떤 텍스트나 버튼이 있는지 전혀 알 수 없는 '블랙박스'이기 때문입니다. ²

투명 DOM(Fallback DOM) 기법의 한계와 안티패턴

접근성 트리의 단절을 우회하기 위해 산업계에서는 Canvas와 동일하게 겹치는 **거대한 투명 병렬 DOM 트리(Parallel DOM Tree)**를 구축하는 기법을 사용합니다. 이를 통해 각 위젯의 위치 데이터를 투명 DOM 노드 좌표와 실시간 동기화하여 보조 기기에 노출시킵니다. ³

그러나 물리적인 텍스트 노드 대신 시각적 은닉을 위해 aria-label 속성을 남용하는 등 치명적 안티패턴이 종종 발생합니다. 구글 번역 등 기계 번역기는 속성(Attribute) 값을 번역 대상에서 제외하므로, 다국어 사용자들에게 심각한 정보 차단 장벽을 형성하게 됩니다. ⁴

주요 WebAssembly UI 프레임워크의 딜레마

• Flutter Web: 자체적인 Semantics Tree를 직렬화하여 DOM으로 번역하지만, 거대한 투명 DOM 노드의 실시간 동기화가 일으키는 무거운 성능 저하 때문에 접근성 모드를 기본적으로 활성화하지 않는 옵트인(Opt-in) 방식을 사용합니다. ⁵
• egui와 AccessKit: Rust 진영에서는 DOM 생성을 건너뛰고 크로스 플랫폼 스키마 통신을 담당하는 AccessKit을 기반으로 플랫폼의 접근성 모델과 연결을 시도하고 있습니다. ⁶
• Slint: 초경량 성능을 자랑하지만 WebGL을 통한 독자적 화면 텍스트 렌더링 위주이기 때문에 웹 플랫폼에서의 스크린 리더 지원과 내비게이션 등 필수 접근성을 포기하고 있는 실정입니다. ⁷

AOM(접근성 객체 모델)과 WasmGC의 미래

기형적인 DOM 강제 생성 구조를 극복할 근본적인 방향은 차세대 웹 표준인 **Accessibility Object Model(AOM)**입니다. AOM이 성숙하면 개발자가 자바스크립트로 운영체제의 접근성 트리에 직접 시맨틱스를 주입할 수 있습니다. ⁸ 여기에 브라우저 네이티브 객체를 직접 참조할 수 있는 WasmGC가 전면 도입된다면 직렬화의 한계를 벗어나 초고속으로 접근성 트리를 갱신함으로써 진정한 차세대 고성능 웹을 실현할 길이 열립니다. ⁹

결론

성능 때문에 접근성을 무시하는 아키텍처는 더 이상 시대적으로 용인받기 힘듭니다. 2026년 대폭 확장된 WCAG 3.0은 보조 기기 호환성 및 명확한 컴플라이언스를 요구하며 공공 조달 등 글로벌 법적 기준치도 올랐습니다. WebAssembly/Canvas 환경의 프론트엔드 개발 시, 개발팀은 표준의 최전선 기술을 빠르게 차용해야 접근성 부채에서 해방될 수 있을 것입니다. ¹⁰