screen-readers

8 개의 포스트

figma

Canvas 기반 제품에 접근성 구축하기 | Figma 블로그 (새 탭에서 열림)

Figma는 캔버스 렌더링으로 무한 줌과 실시간 협업 같은 성능을 얻었지만, 브라우저의 기본 접근성 기능을 사용할 수 없게 되었다. 이를 해결하기 위해 디자인의 scenegraph를 기반으로 접근성 정보를 담은 내부 트리와 이를 반영하는 Mirror DOM을 구축했다. 그 결과 스크린 리더 사용자는 Figma 파일을 탐색·편집하고, 캔버스 선택 상태와 키보드 탐색을 연동하며, 비시각적 변경 사항도 안내받을 수 있다. ## 캔버스 기반 제품의 접근성 문제 - Figma 캔버스는 일반 HTML/DOM 대신 자체 렌더링 시스템을 사용한다. - 이 방식은 전통적인 웹 앱보다 높은 성능을 제공한다. - 무한 줌 - 실시간 멀티플레이어 협업 - 게임과 유사한 고성능 그래픽 처리 - 반면 브라우저가 자동으로 생성하는 접근성 트리를 활용할 수 없다. - 실제 캔버스에는 여러 디자인 레이어가 있어도 포커스를 유지하는 `<input>` 요소 하나만 존재하므로, 스크린 리더가 인식할 구조가 거의 없었다. ## 접근성 트리 합성 - 브라우저의 접근성 트리는 DOM, 시맨틱 HTML, ARIA 속성, 계산된 상태를 바탕으로 생성된다. - Figma는 이 기능을 되살리기 위해 실제 캔버스와 별도로 접근성용 DOM 요소를 합성했다. - 이 구조를 통해 스크린 리더가 Figma 파일의 레이어를 탐색하고 편집할 수 있게 했다. - 시각적 렌더링과 접근성 정보를 분리해, 캔버스의 성능을 유지하면서 브라우저의 보조 기술과 연동한다. ## 네 가지 핵심 시스템 Figma의 접근성 구현은 다음 시스템들이 협력하는 구조다. - **내부 접근성 트리** - 각 디자인 레이어의 접근성 정보를 캐시한다. - 변경이 발생할 때 전체를 다시 만들지 않고 필요한 부분만 갱신한다. - **Mirror DOM React 컴포넌트** - 내부 접근성 트리를 참조해 실제 DOM 요소를 생성한다. - 각 레이어에 대응하는 접근성 요소를 재귀적으로 렌더링한다. - **양방향 선택 동기화** - 캔버스에서 노드를 선택하면 대응하는 DOM 요소에 포커스를 이동한다. - 스크린 리더나 키보드로 DOM 요소를 탐색하면 캔버스 선택 상태도 갱신한다. - **공지 시스템** - 탐색 외의 변경 사항을 사용자에게 알린다. - 예를 들어 객체 이동, 도구 전환 등 시각 사용자에게는 명확하지만 스크린 리더 사용자는 놓칠 수 있는 변화를 안내한다. ## 문맥에 따른 접근성 요약 - 각 디자인 레이어마다 스크린 리더가 읽을 수 있는 **접근성 요약(accessible summary)** 을 생성한다. - 같은 디자인이라도 사용 중인 애플리케이션 문맥에 따라 요약 방식이 달라진다. - 프로토타입을 보는 상황에서는: - 편집 관련 기능을 대부분 제외한다. - 텍스트 필드의 내용이나 클릭 동작이 있는 요소의 버튼 역할처럼 최종 사용자에게 필요한 정보만 제공한다. - 문서를 편집하는 상황에서는: - 오토레이아웃 프레임처럼 편집에 필요한 구조도 접근성 트리에 포함한다. - 레이어별 요약을 만든 뒤 트리를 위에서 아래로 순회하며, 접근성에서 제외된 노드는 제거하고 하위 노드를 상위 구조에 병합한다. - 문서 최초 로딩 시에는 전체 접근성 트리를 구성하지만, 이후에는 편집된 부분만 수술적으로 갱신해 비용을 줄인다. ## Mirror DOM의 재귀적 렌더링 - React 기반 `Mirror DOM` 컴포넌트가 접근성 트리의 각 레이어를 DOM으로 변환한다. - 각 컴포넌트는 특정 레이어의 접근성 요약을 구독한다. - 요약에서 다음 정보를 가져와 DOM 요소를 생성한다. - `label`: 스크린 리더가 읽을 이름 - `role`: 버튼, 입력 필드 등 요소의 의미 - `children`: 하위 레이어 - 하위 레이어는 같은 컴포넌트를 재귀적으로 호출해 DOM 트리를 구성한다. - 내부 접근성 트리를 최소 단위로 갱신하면 React가 실제 DOM 변경도 최소화할 수 있다. ## 시각적 콘텐츠와 접근성 콘텐츠의 분리 - Mirror DOM은 화면에 보이지 않지만 보조 기술이 해석할 수 있는 구조를 제공한다. - 일반적인 visually hidden 스타일을 사용하지 않는 점이 특징이다. - 캔버스 기반 제품에서는 접근성용 DOM이 페이지 레이아웃이나 캔버스 렌더링에 영향을 주지 않도록 별도의 방식으로 관리해야 한다. - 핵심은 시각적 UI를 억지로 HTML로 대체하는 것이 아니라, 보조 기술이 필요로 하는 의미 구조를 별도로 합성하는 것이다. 캔버스 기반 제품에 접근성을 추가할 때는 브라우저가 자동으로 제공하던 기능을 직접 재구축해야 한다. 특히 내부 접근성 트리, 점진적 갱신, 시각 UI와 DOM의 양방향 상태 동기화를 함께 설계하는 것이 중요하다.

figma

Figma에서 접근성을 개선하는 (새 탭에서 열림)

Figma는 키보드만으로 캔버스와 댓글을 조작하고, 스크린 리더로 파일 내용을 더 정확히 이해할 수 있도록 15가지 이상의 접근성 기능을 출시했다. 제품별 키보드 단축키, 더 논리적인 포커스 이동, 풍부한 객체 설명과 서식 정보, 향상된 색상 대비가 포함된다. 이를 통해 장애가 있는 사용자뿐 아니라 장시간 작업하거나 다양한 환경에서 Figma를 사용하는 모든 사용자의 탐색성과 작업 흐름을 개선하는 것이 목표다. ## 캔버스 조작을 위한 키보드 기능 확대 - 키보드만으로 캔버스 객체를 이동·조정·정렬할 수 있는 기능이 제품 전반으로 확대됐다. - **Figma Slides** - 발표자 노트 크기 조정 - AI를 활용한 글쓰기 톤 변경 - **FigJam** - 표의 행과 열 추가·삭제·순서 변경 - 스탬프, 투표, 와시 테이프 추가 및 조정 - AI 요약, 임베드 링크·동영상 같은 캔버스 객체 탐색 - 마커 선과 형광펜 스트로크 선택 및 조정 - **Figma Design** - 선 추가·선택·조정 - 룰러 가이드 추가·삭제·편집 - 타원에서 호(arc) 생성 및 편집 - **공통 기능** - 편집 모드와 보기 전용 모드에서 링크 열기 - 키보드로 링크 사이를 이동 ## 댓글과 Dev Mode 주석 탐색 - 댓글을 추가하고, 위치를 옮기고, 댓글 간 이동을 키보드 단축키로 처리할 수 있다. - Dev Mode 주석도 키보드로 추가·이동·탐색할 수 있다. - 피드백을 확인하거나 답변할 때 포커스가 흐트러지지 않도록 설계되어 협업과 핸드오프 과정이 개선된다. - 댓글 관련 기능은 베타 제품에서는 제공되지 않을 수 있다. ## 사용자 설정을 통한 조작 방식 개인화 - 입력 중 Figma 전용 단축키가 동작하지 않도록 설정할 수 있다. - 다른 사용자가 스포트라이트를 사용할 때 자동으로 따라가는 기능을 켜거나 끌 수 있다. - 사용자는 작업 방식이나 보조기술 사용 환경에 맞춰 키보드 동작을 조정할 수 있다. ## 스크린 리더 지원 강화 - 버튼, 메뉴, 패널 등 인터랙티브 요소를 Tab 키로 이동할 때 더 논리적인 순서를 따른다. - 메뉴 열기, 버튼 실행, 툴바 옵션 선택 등 특정 동작으로 바로 이동할 수 있다. - 객체를 읽을 때 유형, 이름, 상태 등 더 자세한 정보가 제공된다. - 새 댓글이나 파일 변경 사항 같은 중요한 업데이트가 더 일관되게 안내된다. - 굵게, 기울임, 목록, 링크 등 서식 있는 텍스트 구조를 스크린 리더가 보존해 읽는다. - Buzz와 Slides의 캔버스 객체도 스크린 리더가 인식하고 안내한다. - 이러한 개선은 캔버스의 객체 순서를 파악하고 파일 변경 사항을 놓치지 않도록 돕는다. ## 향상된 색상 대비 - 간단한 토글로 라이트 모드와 다크 모드 모두에서 인터페이스의 색상 대비를 높일 수 있다. - 접근성 설정, Actions 메뉴, General 설정에서 기능을 활성화할 수 있다. - 텍스트와 아이콘의 가독성이 높아지고, 버튼과 외곽선이 더 뚜렷하게 표시된다. - 인터페이스 구조를 파악하고 필요한 요소를 빠르게 찾기 쉬워진다. - 햇빛이나 강한 조명 아래에서도 화면을 보기 쉬우며, 장시간 화면을 사용하는 경우 눈의 부담을 줄일 수 있다. ## 실용적인 활용 키보드 중심으로 작업하는 사용자는 Figma의 전체 키보드 컨트롤 목록을 확인해 자주 쓰는 캔버스·댓글 단축키를 익히는 것이 좋다. 스크린 리더 사용자는 객체 설명과 서식 있는 텍스트 지원을 활용하고, 일반 사용자도 색상 대비 설정을 활성화하면 장시간 작업이나 밝은 환경에서 더 편하게 Figma를 사용할 수 있다.

figma

디자인에 마우스가 필요 (새 탭에서 열림)

Figma는 마우스 없이도 디자인 작업을 수행할 수 있도록 키보드 접근성 기능을 대폭 강화했다. 이제 키보드만으로 캔버스 이동, 객체 삽입, 정밀한 선택이 가능하며, 스크린 리더가 작업 내용을 읽어줘 사용자가 현재 위치와 상태를 파악하기 쉬워졌다. 이는 키보드나 스크린 리더를 주로 사용하는 디자이너도 디자인 프로세스에 온전히 참여할 수 있도록 장벽을 낮추려는 업데이트다. ## 키보드만으로 이어지는 디자인 작업 - 기존에는 키보드만 사용할 경우 프레임 간 이동, 컴포넌트 선택, 새 요소 추가가 어려웠다. - 캔버스 상단에 갇히거나 잘못된 영역으로 확대·축소되는 등 작업 흐름이 끊기는 문제가 있었다. - 이번 업데이트는 기존 단축키에 더해 패닝, 삽입, 선택 기능을 보완해 디자인 스프린트, 공동 작업, 디자인 리뷰까지 마우스 없이 수행할 수 있게 한다. - 기능 개발 과정에서 키보드와 스크린 리더를 사용하는 디자이너 및 알파 사용자들의 피드백을 반영했다. ## 방향키 기반 캔버스 이동 - 방향키로 캔버스를 상하좌우로 이동할 수 있다. - `Shift` 키를 함께 사용하면 더 빠르게 이동하거나 스크롤할 수 있다. - 새 키보드 단축키를 통해 확대·축소를 세밀하게 조정할 수 있다. - 이동 도구와 손 도구에도 키보드로 접근할 수 있어 캔버스 탐색의 유연성이 높아졌다. ## 키보드로 객체 삽입과 배치 - 도형, 텍스트 등 대부분의 객체 유형을 키보드만으로 캔버스에 추가할 수 있다. - 프레임은 키보드 단축키와 십자선 형태의 안내 화면을 이용해 원하는 위치에 삽입할 수 있다. - `Enter` 키를 사용하면 화면 중앙에 텍스트를 배치할 수 있다. - 마우스 포인터 없이도 삽입 위치를 확인하고 객체를 생성할 수 있다. ## 키보드 기반 객체 선택 - 새로운 키보드 박스 선택 도구로 캔버스의 객체를 선택할 수 있다. - 방향키로 분홍색 커서를 이동해 객체 위에 놓은 뒤 `Enter`를 누르면 해당 객체를 선택한다. - 객체를 하나씩 선택하거나 선택 상자를 이용해 여러 객체를 동시에 선택할 수 있다. - 선택한 객체의 위치 조정 역시 키보드 중심으로 처리할 수 있다. ## 스크린 리더와 포용적인 디자인 - 사용자가 수행하는 작업을 스크린 리더가 읽어주므로 현재 상태와 위치를 파악하기 쉬워졌다. - 이번 기능은 단순히 Figma 사용성을 개선하는 것을 넘어, 더 많은 사람이 창작 과정에 참여하도록 하는 데 목적이 있다. - Figma는 색상 선택기의 대비 검사기를 통해 텍스트와 그래픽이 WCAG 기준을 충족하는지 확인할 수 있도록 지원한다. - 디자인에서 의미 있는 HTML 시맨틱 태그를 지정할 수 있어 스크린 리더를 지원하는 제품 설계에도 활용할 수 있다. - 접근성을 일회성 점검 항목이 아니라 지속적으로 개선해야 할 제품 개발 원칙으로 보고 있다. 마우스 사용이 어렵거나 키보드·스크린 리더를 선호하는 사용자는 Figma의 키보드 단축키와 스크린 리더 지원을 활성화해 작업 흐름을 점검해볼 만하다. 팀 차원에서도 이러한 기능을 활용하면 접근성을 고려한 디자인 협업 환경을 더 쉽게 구축할 수 있다.

discord

디스코드에서 나만의 (새 탭에서 열림)

Discord 스티커는 큰 이모지처럼 메시지에 감정과 강조를 더하는 기능이다. 서버에서 제공하는 스티커를 사용할 수 있으며, 서버 소유자나 `Manage Expressions` 권한이 있는 관리자는 직접 스티커를 업로드할 수 있다. 스티커는 320×320 해상도와 파일 형식·용량 제한을 지켜야 하며, 서버 부스트 수준에 따라 보유 가능한 개수가 달라진다. ## Discord에서 스티커 사용하기 - 채팅 입력창의 스티커 아이콘을 클릭하면 사용할 수 있는 스티커 목록이 열린다. - 참여 중인 서버의 스티커와 Discord가 제공하는 기본 스티커 약 300개를 확인할 수 있다. - 스티커를 클릭하면 즉시 전송된다. - `Shift` 키를 누른 채 클릭하면 현재 작성 중인 메시지에 스티커를 첨부할 수 있다. - 서버 스티커는 해당 서버 안에서 사용할 수 있다. - Nitro 회원은 자신이 속한 서버의 스티커를 다른 서버, DM, 그룹 DM에서도 사용할 수 있다. ## 스티커 업로드 권한과 경로 - 커스텀 스티커는 서버에 저장된다. - 업로드하려면 다음 중 하나가 필요하다. - Discord 서버 소유자 - `Manage Expressions` 권한을 가진 관리자 - 업로드 경로는 `Server Settings > Stickers`이다. - 이 메뉴에서 사용 가능한 슬롯, 등록된 스티커, 업로드한 관리자를 확인할 수 있다. ## 스티커 파일 요구사항 - 이미지 크기: 정확히 `320×320` 픽셀 - 정적 스티커: `PNG` - 애니메이션 스티커: `APNG` 또는 `GIF` - 최대 파일 크기: `512KB` - 관련 이모지: 스티커와 가장 유사한 이모지를 지정해야 한다. - 스티커 추천이나 검색 결과에 노출되는 데 도움을 준다. - 텍스트 설명: 선택 사항이지만 스크린 리더 사용자의 접근성을 높일 수 있다. - 모든 조건을 입력한 뒤 `Upload`를 누르면 서버 구성원이 사용할 수 있다. ## 서버 부스트와 스티커 슬롯 - 기본적으로 서버는 스티커를 최대 5개까지 등록할 수 있다. - 서버 부스트 수준에 따라 총 슬롯이 다음처럼 늘어난다. - 기본: 5개 - 부스트 단계에 따라 15개, 30개, 60개 - Nitro 회원은 서버에 사용할 수 있는 부스트 2개를 제공받는다. - 부스트가 줄어 서버 등급이 낮아지면 새 한도를 초과해 업로드한 스티커는 사용할 수 없게 된다. - 스티커를 다시 사용하려면 서버를 재부스트하거나, 현재 한도에 맞게 일부 스티커를 삭제해야 한다. ## 이미지로 스티커 만들기 - 기존 이미지를 요구사항에 맞게 편집하면 누구나 스티커를 만들 수 있다. - 단순히 이미지를 자르는 작업은 다음과 같은 기본 도구로도 가능하다. - Windows: Microsoft Paint - macOS: Preview - Discord 앱 중에는 이미지 배경을 자동으로 제거해 주는 도구도 있다. - 예시로 Picsart 앱을 이용하면 배경 제거 후 스티커를 만들 수 있다. - 모바일에서는 `320×320`으로 저장할 수 있는 사진 편집 앱이 필요할 수 있다. - 업로드 전 이미지 크기가 정확히 320×320인지 반드시 확인해야 한다. - 제작한 스티커는 Discord 커뮤니티 가이드라인을 준수해야 한다. ## 실용적인 추천 처음에는 투명 배경의 PNG 이미지를 320×320으로 맞추고, 파일 크기를 512KB 이하로 줄이는 방식이 가장 간단하다. 또한 검색과 접근성을 고려해 관련 이모지와 설명을 함께 등록하고, 여러 개를 업로드할 계획이라면 서버 부스트로 확보할 수 있는 슬롯을 먼저 확인하는 것이 좋다.

figma

그잼 스크린 리더 (새 탭에서 열림)

FigJam은 스크린 리더와 키보드만으로 캔버스의 콘텐츠를 읽고 만들 수 있도록 지원을 공식 출시했다. 사용자는 캔버스와 메뉴 사이를 이동하며 파일 구조, 텍스트가 포함된 도형, 스티키, 표, 이미지 대체 텍스트를 확인·편집할 수 있다. 다만 커서 채팅, 투표, 위젯, 자유형 벡터 편집 등 일부 기능은 아직 지원되지 않으며, Figma는 실제 사용자 피드백을 바탕으로 접근성을 계속 확장할 계획이다. ## 협업 도구 전체를 위한 접근성 - FigJam은 아이디어를 정리하고 의사결정을 맞추는 협업 중심 도구이므로, 팀 구성원 모두가 참여할 수 있어야 한다는 판단에서 접근성 개선 대상이 됐다. - Figma 프로토타입에 스크린 리더 지원을 도입한 뒤, 다음 단계로 FigJam을 선택했다. - 정밀한 디자인 도구인 Figma보다 FigJam은 기능이 상대적으로 표면에 드러나 있어, 접근 가능한 UI 패턴을 실험하기에 적합했다. ## 스크린 리더로 가능한 작업 - 스크린 리더 및 키보드 사용자는 캔버스의 여러 요소와 메뉴·화면 사이에서 포커스를 이동할 수 있다. - 다음 콘텐츠를 읽고 생성·편집할 수 있다. - FigJam 파일의 구조 - 텍스트가 포함된 도형 - 스티키 노트 - 표 - 이미지의 대체 텍스트 - 캔버스에서는 콘텐츠를 문자 그대로 읽는 것뿐 아니라, 계층 구조와 캔버스 내 위치를 통해 맥락도 파악해야 한다. - 아직 지원되지 않는 기능에는 커서 채팅 탐색, 스탬프 조정, 투표, 이모트 휠, 위젯 상호작용, 선·하이라이트·와시 테이프·마커 같은 자유형 벡터 노드 편집이 포함된다. ## ARIA 표준만으로는 부족했던 캔버스 접근성 - WAI-ARIA는 웹 콘텐츠와 애플리케이션의 접근성과 상호운용성을 높이기 위한 기술 명세다. - 일반적인 웹사이트나 단순한 위젯과 달리, Figma·FigJam 같은 캔버스 기반 도구에는 참고할 만한 접근성 패턴과 모범 사례가 충분하지 않았다. - 따라서 팀은 처음부터 정해진 구현 방식을 따르기보다, 실제로 도구를 사용할 수 있게 만드는 핵심 기능이 무엇인지 먼저 정의했다. - 접근성 테스트 기관 Fable과 협력해 보조공학 사용자들의 테스트와 피드백을 수집했다. - 일부 베타 테스터는 디지털 화이트보드나 실제 화이트보드 경험도 없었기 때문에, 기존 도구의 사용 패턴을 전제로 하지 않고 사용자 여정을 새롭게 설계했다. ## 다양한 키보드와 보조공학 환경 고려 - 스크린 리더 종류, 설정, 보조공학 기술, 국제 키보드 배열에 따라 사용 가능한 조합이 매우 다양하다. - 베타 인터뷰를 통해 팀은 스크린 리더 사용 방식에 대해 지속적으로 새로운 사실을 발견했다. - 이 과정에서 얻은 패턴은 FigJam뿐 아니라 Figma 전반의 접근성 개선에도 활용됐다. - React 컴포넌트에 ARIA 레이블과 태그를 적용하는 등, 코드베이스에 재사용 가능한 접근성 패턴을 구축했다. - 한 번 만들어진 패턴은 다른 엔지니어들도 반복해서 적용할 수 있어 제품 전체의 접근성 향상에 기여한다. ## 단계적 출시와 향후 과제 - 캔버스 기반 협업 도구의 접근성에는 확립된 정답이 부족했기 때문에, 초기 출시 범위를 핵심 사용자 여정 중심으로 정했다. - 제품을 한 번에 완성하기보다 실제 사용과 채택 데이터를 통해 부족한 부분을 확인하고 개선하는 방식을 택했다. - 특히 여러 사용자가 동시에 상호작용하는 커서 채팅 같은 멀티플레이어 기능은 스크린 리더 환경에 적합한 모델을 추가로 연구해야 한다. - 이번 출시는 전체 접근성 작업의 끝이 아니라, 이후 기능 확장을 위한 기반에 가깝다. 실제로 FigJam 파일을 만들 때는 요소에 명확한 텍스트와 이미지 대체 텍스트를 제공하고, 콘텐츠의 계층과 위치를 일관되게 구성하는 것이 좋다.

figma

피그마 접근성 팀과의 대화 | 피그마 블로그 (새 탭에서 열림)

Figma의 접근성 팀은 스크린 리더 지원을 개발 초기부터 다양한 사용자와 함께 검증해야 한다고 강조한다. 프로토타입 스크린 리더 베타를 통해 VoiceOver와 JAWS의 차이, 저시력 사용자의 시각·음성 병행 사용, 키보드 포커스의 중요성을 확인했다. Figma는 앞으로도 접근성 파트너와 협력해 지원 범위를 넓히고, 디자이너가 생성 HTML과 접근성 품질을 더 직접적으로 관리할 수 있는 도구를 제공할 계획이다. ## 오픈 베타를 통해 확인한 실제 사용자 요구 - 내부 테스트만으로는 실제 사용 환경과 보조공학 사용자의 요구를 충분히 파악하기 어렵다. - Mac VoiceOver에서는 잘 작동하던 기능도 JAWS 등 다른 스크린 리더에서는 추가 조정이 필요했다. - 스크린 리더 사용자는 시각 정보를 전혀 사용하지 않는 경우만 있는 것이 아니다. - 저시력 사용자는 화면의 시각 정보와 음성 정보를 함께 활용할 수 있다. - 다양한 상호작용 방식을 제공하면 더 넓은 사용자에게 도움이 된다. - 이에 따라 Figma는 주요 스크린 리더 기술을 개발 후반이 아니라 초기 단계부터 테스트하기로 했다. ## 시각 경험과 스크린 리더 경험의 연결 베타 테스트 결과, 스크린 리더 사용 경험은 시각적 UI와 분리된 별도 기능이 아니라 두 경험이 서로 보완되어야 한다는 점이 드러났다. - 접근성 트리에 요소의 위치 정보를 제공해, 시각 정보를 일부 활용하는 사용자가 스크린 리더 커서의 화면상 위치를 파악할 수 있게 했다. - 클릭 가능한 요소에 키보드 포커스가 있을 때도 “On hover” 상호작용을 실행하도록 조정했다. - 스크린 리더 커서가 이동하면 스크롤 영역도 함께 이동하도록 구현했다. - 프로토타입 도구 모음이 자동으로 숨겨질 때 키보드 포커스를 고려했다. - 화면을 탐색할 때 도구 모음이 방해되지 않아야 한다. - 동시에 현재 포커스된 컨트롤은 계속 화면에 보여야 한다. - 개발 과정에서 접근성 사용자를 단순히 “시각 사용자”와 “음성 사용자”로 나누는 기존 가정을 수정하게 됐다. ## 접근 가능한 프로토타입 진입 경로 프로토타입 자체가 스크린 리더로 접근 가능하더라도, Figma 디자인에서 해당 프로토타입으로 이동할 방법이 없으면 전체 경험은 접근 가능하지 않다. - 실제 출시 과정에서 프로토타이핑 모드로 바로 이동하는 단축키를 추가했다. - Mac: `Option + Command + Return` - PC: `Alt + Ctrl + Enter` - 스크린 리더 지원을 지속적으로 켤 수 있는 토글을 제공했다. - Figma Community를 통해 접근성 기능 사용법을 더 적극적으로 안내했다. - 기능 단위가 아니라 사용자가 처음부터 끝까지 수행하는 전체 흐름을 검증해야 한다는 교훈을 얻었다. ## 접근성 파트너와의 공동 테스트 Figma는 보조공학 사용자와 기업을 연결하는 Fable과 협력해 기능을 검증하고 있다. - Fable은 특정 사용자 흐름 테스트부터 심층 사용자 인터뷰까지 지원한다. - 사용자 피드백을 반영해 접근성 관련 컨트롤과 키보드 단축키를 더 쉽게 찾도록 개선하고 있다. - 접근성 탐색용 키보드 단축키를 키보드 단축키 패널에 포함하는 작업을 진행했다. - 키보드 단축키 패널 자체도 스크린 리더와 키보드로 접근 가능하도록 개선 중이다. - FigJam에서는 화면 구성의 정보 계층을 명확히 전달하기 위해 다음 정보를 스크린 리더에 제공한다. - 각 항목의 자식 수 - 형제 항목 수 - 캔버스 내 요소의 맥락을 파악하는 데 필요한 구조 정보 - 다양한 스크린 리더 소프트웨어와 숙련도 차이를 고려하면서 기능을 조정할 수 있었다. ## 앞으로의 접근성 방향 Figma 팀은 현재의 프로토타입 스크린 리더 지원이 완성된 상태가 아니라고 설명한다. - 콘텐츠가 기본적으로 스크린 리더 사용자에게 항상 제공되도록 하는 것을 우선순위로 삼고 있다. - 디자이너가 Figma가 생성하는 HTML을 더 세밀하게 제어할 수 있도록 할 계획이다. - 스크린 리더에 익숙하지 않은 디자이너도 자신의 디자인 접근성을 평가할 수 있는 도구를 개발하려 한다. - 접근성을 출시 직전의 점검 항목이 아니라 제품 설계와 개발 전반에 포함되는 기준으로 정착시키려 한다. 접근성 기능을 만들 때는 특정 스크린 리더 하나만 기준으로 삼지 말고, 실제 보조공학 사용자와 함께 초기 단계부터 테스트하는 것이 중요하다. 또한 개별 기능의 접근성뿐 아니라 사용자가 해당 기능에 도달하고, 탐색하고, 조작하는 전체 경로를 검증해야 한다.

figma

접근성 향상을 위한 (새 탭에서 열림)

Figma는 디자인을 모든 사람이 참여할 수 있게 만드는 것을 목표로 하며, 이를 위해 시각장애·저시력 사용자를 위한 프로토타입 스크린 리더 베타를 발표했다. Figma 디자인은 일반 HTML이 아니어서 기존 스크린 리더가 내용을 읽기 어려웠지만, 프로토타입을 스크린 리더 전용 HTML로 변환하는 방식으로 문제를 해결했다. 이는 중요한 진전이지만, ARIA 역할·탭 순서·대체 텍스트 설정 등 접근성 지원을 확대하기 위한 추가 과제가 남아 있다. ## 프로토타입 스크린 리더 베타 - 기존에는 시각장애 사용자가 Figma 프로토타입을 열어도 스크린 리더에 “빈 캔버스” 레이블만 표시됐다. - 텍스트, 이미지, 버튼 등 프로토타입의 핵심 콘텐츠를 스크린 리더가 인식하지 못하는 문제가 있었다. - 베타 기능은 다음을 지원한다. - 텍스트 노트 읽기 - 이미지 대체 텍스트(alt text) 읽기 - 버튼과 키보드 동작을 통한 프로토타입 탐색 - Tab 키 등을 이용한 키보드 내비게이션 - 2022년 8월 업데이트를 통해 이 기능은 모든 사용자가 이용할 수 있는 오픈 베타로 전환됐다. ## Figma 디자인을 HTML로 변환하는 방식 - Figma는 웹 기반 애플리케이션이지만 디자인 결과물이 일반적인 HTML 요소로 그려지지 않는다. - 따라서 대부분의 스크린 리더가 Figma 캔버스의 텍스트와 인터페이스 구조를 직접 해석할 수 없었다. - Figma는 프로토타입을 스크린 리더 전용 HTML 표현으로 변환해 보조공학 기술에 제공하는 구조를 구현했다. - 이 변환 계층을 통해 스크린 리더가 화면에 표시된 콘텐츠와 상호작용 요소를 읽고 탐색할 수 있게 됐다. ## 함께 진행된 접근성 개선 - 다크 모드와 색상 대비 개선을 통해 다양한 시각적 요구를 지원했다. - WCAG 3.0 초안 기준에 부합하도록 색상 대비 준수를 강화했다. - Figma 데스크톱 앱과 Pro·Org·Enterprise 요금제에서 오디오 채팅 실시간 자막 기능을 오픈 베타로 제공했다. - Deque의 플랫폼 전반 접근성 평가를 받아 다음과 같은 개선 영역을 확인했다. - 키보드만으로 기능을 사용할 수 있도록 개선 - ARIA 레이블을 모범 사례에 맞게 적용 - Adee, Deque, Stark 등의 플러그인과 커뮤니티 파일을 통해 색상 대비 검사 등 접근성 도구 생태계도 확대되고 있다. ## 개발 프로세스에 접근성을 내재화 - Figma는 팀이 접근성을 고려하도록 권장하는 수준을 넘어, 제품을 설계·개발할 때 접근성을 필수적으로 반영하도록 하고 있다. - 키보드 전용 사용자와 스크린 리더 사용자를 지원하는 재사용 가능한 UI 컴포넌트를 제작하고 있다. - 새 기능과 코드가 접근성 모범 사례를 따르는지 확인할 수 있는 내부 도구도 개발 중이다. - 알파·베타 테스트에 접근성 사용자를 조기에 참여시켜 실제 사용 경험을 설계 과정에 반영하고 있다. ## 남은 과제 - 사용자가 디자인 요소에 직접 대체 텍스트를 지정할 수 있도록 해야 한다. - 컴포넌트에 ARIA 역할을 설정하는 기능이 필요하다. - 프로토타입 요소의 키보드 탭 순서를 지정할 수 있어야 한다. - 스크린 리더 지원은 시작 단계이며, 커뮤니티와 지속적으로 테스트하고 피드백을 받아 개선해야 한다. 실용적으로는 Figma에서 프로토타입을 제작할 때 이미지에 의미 있는 대체 텍스트를 제공하고, 키보드만으로 탐색 가능한 흐름과 충분한 색상 대비를 함께 검토하는 것이 권장된다.

figma

폰트가 깨질 때 (새 탭에서 열림)

폰트 폴백(font fallback)은 현재 글꼴에 필요한 글리프가 없을 때 다른 글꼴이나 대체 표시를 사용하는 컴퓨터 타이포그래피机制이다. 네모 상자, 깨진 이모지, 플랫폼마다 다르게 보이는 특수문자, 이모지 삽입 후 줄이 내려가는 현상 등은 대부분 이 메커니즘과 관련 있다. 이는 단순한 버그라기보다, 서로 다른 글꼴·문자 집합·운영체제가 텍스트를 처리하는 과정에서 발생하는 필연적인 결과다. ## 일상에서 나타나는 폰트 폴백 - 지원되지 않는 문자는 네모 상자, 물음표, 십자가가 들어간 상자 등으로 표시될 수 있다. - 발신자와 수신자의 환경에 설치된 글꼴이나 지원하는 문자 범위가 다르면 같은 이모지가 분해되거나 전혀 다른 모양으로 보인다. - 트위터 등에서 보이는 ‘특수 폰트’는 실제 글꼴을 바꾼 것이 아니라 유니코드의 다른 문자나 기호를 조합한 경우가 많다. - 이런 문자는 화면에서는 장식적으로 보일 수 있지만, 스크린 리더가 부자연스럽게 읽거나 다른 환경에서 빈 상자로 표시될 수 있다. - 이모지를 추가했을 때 줄 높이나 기준선이 변하는 것도 해당 글리프의 크기와 글꼴 메트릭이 기존 텍스트와 다르기 때문이다. - 카오모지나 결합 문자는 플랫폼·폰트별 지원 차이로 정렬과 모양이 달라질 수 있다. ## 글리프와 글꼴의 문자 범위 - 글리프는 글꼴이 실제로 그려내는 문자 모양을 뜻한다. 문자 자체와 글리프는 구분되지만, 글에서는 이해를 돕기 위해 대략적인 의미의 ‘문자’로 설명한다. - 서유럽권 글꼴도 대문자·소문자·숫자·문장 부호·악센트·기호 등을 포함해 수백 개의 글리프가 필요하다. - 중국어·일본어 글꼴은 수천 개의 한자를 포함해야 하므로 필요한 글리프 수가 훨씬 많다. - 합자(ligature), 숫자 스타일, 대체 글자 모양 같은 OpenType 기능을 지원하려면 기본 문자 외의 글리프도 추가해야 한다. - 라틴 문자만 지원하더라도 서유럽, 중부 유럽, 그리스어, 키릴 문자, 베트남어 등으로 범위를 넓히면 글리프 수가 계속 증가한다. - 모든 문자를 하나의 글꼴에 넣는 것은 현실적으로 어렵기 때문에 글꼴 제작자는 지원 범위를 선택해야 한다. ## `.notdef`: 글꼴이 모르는 문자의 표시 - 글꼴이 요청받은 문자를 포함하지 않을 때 사용하는 마지막 대체 글리프의 이름이 `.notdef`다. - 일반적으로 사각형, 십자가가 있는 상자, 물음표가 들어간 상자 등으로 표시된다. - `.notdef`는 특정 유니코드 문자가 아니라, 해당 글꼴 내부에서 “이 문자를 표현할 수 없다”는 사실을 나타내는 글리프다. - 화면에 네모가 표시되어도 내부의 텍스트 데이터가 네모 문자로 바뀌는 것은 아니다. - 따라서 텍스트를 복사하면 원래 문자가 유지되며, 나중에 해당 문자를 지원하는 글꼴로 바꾸면 제대로 표시될 수 있다. - 표시 모양과 크기는 글꼴 디자이너가 정하므로 글꼴마다 빈 사각형, 십자가, 장식된 상자 등 다양한 형태가 나타난다. ## 금속 활자와 디지털 글꼴의 차이 - 금속 활자 시대에는 글자와 글꼴의 활자가 물리적으로 결합되어 있어, 존재하지 않는 문자를 출력하려는 문제가 상대적으로 적었다. - 디지털 환경에서는 텍스트와 글꼴이 분리되어 있다. - 사용자는 다른 사람이 오래전에 작성한 텍스트나, 작성 당시 존재하지도 않았던 글꼴이 필요한 문자를 열 수 있다. - 이 때문에 글꼴은 자신이 표현할 수 없는 문자를 만났을 때 `.notdef` 같은 대체 수단으로 응답해야 한다. - 폰트 폴백은 이러한 디지털 텍스트 환경에서 서로 다른 문자 집합과 글꼴을 연결하는 핵심 장치다. ## 실용적인 결론 특수문자나 이모지를 사용할 때는 상대방의 운영체제와 글꼴 지원 여부가 다를 수 있음을 고려해야 한다. 장식용 유니코드 문자는 접근성과 호환성이 떨어질 수 있으므로 중요한 정보에는 일반 텍스트를 함께 제공하고, 디자인 작업에서는 여러 글꼴과 환경에서 폴백 결과를 확인하는 것이 좋다.