Figma 캔버스 접근성 공부 정리 | 보이지 않는 DOM 이야기

Figma 블로그에서 “캔버스 기반 제품에 접근성 구축하기”라는 글을 읽었다. 처음엔 그냥 스크롤할 뻔 했는데, 첫 문단에서 멈췄다.

캔버스로 렌더링하면 브라우저가 HTML에서 기본으로 주는 접근성이 전부 사라진다는 내용이었다. Figma처럼 캔버스 중심으로 만들어진 앱은 DOM 기반 앱이 자동으로 갖는 스크린리더 지원, 키보드 포커스 같은 걸 처음부터 직접 만들어야 한다. 이게 어떻게 가능한지가 궁금해서 글을 다 읽어봤다.

1️⃣ Figma는 어떻게 풀었나

가장 인상 깊었던 건 “Mirror DOM”이라는 개념이었다. 캔버스 렌더링과 별개로, 스크린리더가 읽을 수 있는 React 기반 DOM 트리를 따로 유지한다. 이 두 트리는 항상 동기화된다. 레이어가 이동하면 대응하는 DOM 요소도 따라 이동한다.

위치 계산은 Affine Transform 방식을 썼다고 했다. 오프셋, 스케일, 회전을 하나의 행렬로 결합해서 CSS로 표현하는 방식인데, 덕분에 회전된 요소도 정확히 같은 위치에 DOM 요소를 배치할 수 있다.

👉🏻 흥미로웠던 건 이 DOM 요소들을 단순히 숨기지 않았다는 점이다. Figma 문서의 공간적 배치가 중요하기 때문에, 실제 레이아웃을 유지해서 화면 확대 도구나 음성 제어 도구에서도 쓸 수 있게 했다고 한다.

또 “양방향 선택 동기화”라는 것도 있다. 캔버스에서 레이어를 클릭하면 Mirror DOM의 해당 요소가 포커스를 받고, 반대로 키보드로 DOM을 탐색하면 캔버스 선택이 따라간다. DOM과 캔버스가 같은 상태를 바라보는 두 뷰처럼 설계된 것이다.

이 접근성 시스템이 한 번에 만들어진 건 아니었다. 프로토타입 뷰에서 시작해서 FigJam, 그리고 편집기 순서로 점진적으로 확대됐다. 가장 단순한 맥락에서 먼저 검증하고, 거기서 쌓은 걸 복잡한 편집 환경으로 가져온 방식인 것 같다.

2️⃣ 내가 든 생각

디자이너 관점에서 눈에 들어왔던 건 “맥락별 접근성 요약”이었다. 같은 레이어라도 편집 모드에서는 오토레이아웃 같은 편집 관련 정보까지 포함한 요약을 전달하고, 프로토타입 모드에서는 콘텐츠만 노출한다. 같은 파일인데 사용자 역할에 따라 다른 정보 구조가 나온다는 설계 방식이 흥미로웠다.

💡 여기서 든 질문? 디자이너가 컴포넌트를 설계할 때 접근성 레이블을 함께 생각하는 흐름이 자연스럽게 만들어질 수 있을까? 지금은 개발 단계에서 뒤늦게 붙이는 경우가 많은데, Figma가 그 접점을 앞당길 수 있을 것 같다는 생각이 들었다.

이 글을 통해 처음 정리된 것 중 하나는, 접근성이 나중에 추가할 수 있는 기능이 아니라 아키텍처 차원의 결정이라는 점이었다. 캔버스 기반으로 설계한 뒤 접근성을 붙이려면 Mirror DOM 같은 별도 시스템 전체가 필요하다. 초반에 고려할수록 덜 비싼 일이 된다는 건, 개발을 공부하면서 자꾸 다시 마주치는 이야기인 것 같다.

⭐️ 마지막으로, 디자이너 입장에서 공부하며 느낀 점

공부 끝에 남은 건 “접근성은 기술 선택의 결과물”이라는 한 줄이다. 캔버스를 택하면 성능을 얻고 접근성 기반을 잃는다. Figma는 그걸 직시하고 다시 쌓았다. 어떤 기술이 좋다 나쁘다가 아니라, 선택에서 뭐가 따라오는지를 미리 아는 것 — 프론트엔드를 공부하면서 계속 생각하게 되는 부분인 것 같다.

---

참고 원문: Building accessibility into a canvas-based product