폴리이엔엠 디지털 미디어 연구

WebAssembly 및 Canvas 기반 고성능 UI의 접근성 사각지대 49

현대의 웹 플랫폼은 단순한 하이퍼텍스트 문서를 소비하는 공간에서 벗어나, 데스크톱 네이티브 애플리케이션에 필적하는 고성능 연산과 복잡한 그래픽 렌더링을 수행하는 거대한 플랫폼으로 진화했습니다. 중심에는 자바스크립트 엔진을 우회하여 네이티브에 가까운 속도로 코드를 실행하는 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 환경의 프론트엔드 개발 시, 개발팀은 표준의 최전선 기술을 빠르게 차용해야 접근성 부채에서 해방될 수 있을 것입니다. ¹⁰