웹 접근성과 에디터에서의 적용

#에디터#웹접근성#HTML

웹 접근성이란 무엇일까

웹 접근성은 장애 여부나 사용하는 기기와 관계없이 누구나 웹의 정보와 기능을 이용할 수 있도록 만드는 것입니다.
흔히 스크린 리더 지원부터 떠올리지만 접근성이 다루는 범위는 더 넓습니다.
키보드만으로 기능을 조작할 수 있는지, 현재 포커스가 어디에 있는지 알 수 있는지, 화면의 상태 변화가 스크린 리더에도 전달되는지, HTML 요소가 의미에 맞게 사용되는지를 모두 포함합니다.

참고: 스크린 리더는 화면의 텍스트와 요소의 역할·이름·상태를 음성이나 점자로 전달하는 소프트웨어입니다.
화면의 모양을 그대로 읽는 것이 아니라 브라우저가 HTML과 ARIA를 바탕으로 만든 접근성 트리를 해석하기 때문에, 시각적으로 같은 UI라도 마크업에 따라 전달되는 정보가 달라질 수 있습니다.

WCAG(Web Content Accessibility Guidelines)는 W3C가 만든 웹 콘텐츠 접근성 지침입니다.
WCAG는 웹 접근성을 다음 네 가지 원칙으로 설명합니다.

  • 인식 가능: 화면의 정보와 상태를 다양한 방법으로 인식할 수 있어야 합니다.
  • 운용 가능: 마우스뿐 아니라 키보드 같은 다른 입력 방식으로도 조작할 수 있어야 합니다.
  • 이해 가능: 인터페이스의 내용과 동작을 사용자가 이해할 수 있어야 합니다.
  • 견고함: 다양한 브라우저와 스크린 리더가 콘텐츠를 해석할 수 있어야 합니다.

ARIA란?

ARIA(Accessible Rich Internet Applications)는 HTML만으로 충분히 표현하기 어려운 UI의 역할과 상태, 관계를 스크린 리더에 전달하기 위한 속성 모음입니다.

  • role은 요소가 버튼이나 다이얼로그, 상태 영역 중 무엇인지 알려줍니다.
  • aria-label은 화면의 텍스트만으로 알기 어려운 요소에 이름을 제공합니다.
  • aria-expanded와 aria-disabled는 펼침 여부나 비활성 상태를 전달합니다.
  • aria-live는 화면에서 동적으로 바뀐 내용을 스크린 리더에 알립니다.

ARIA는 요소의 역할과 이름을 스크린 리더에 전달할 뿐입니다.
div에 role="button"을 붙인다고 해서 Enter와 Space를 이용한 실행이나 비활성 상태가 자동으로 구현되지는 않습니다.
요소의 의미와 동작은 네이티브 HTML로 부여하고 HTML만으로 표현하기 어려운 정보는 ARIA로 보완합니다.

일반적인 웹 서비스에는 버튼이나 입력 폼처럼 네이티브 HTML만으로 기본적인 역할과 키보드 동작이 갖춰지는 요소가 많습니다.
하지만 Word 에디터에서는 현재 단락, 표의 행·열 위치, 그림의 대체 텍스트처럼 화면에 보이는 문서 구조와 정보를 스크린 리더에서도 읽을 수 있게 해야 합니다.
또한 도형 선택과 순서 변경처럼 마우스를 중심으로 설계된 기능은 키보드로 실행하는 방법도 따로 있어야 합니다.

Word 에디터에 웹 접근성을 적용하면서 키보드와 스크린 리더를 중심으로 고민한 내용을 정리해 보았습니다.

문서 에디터의 접근성

일반적인 웹사이트에서 사용자는 정보를 탐색하고 입력 폼을 제출합니다.
반면 에디터는 사용자가 직접 결과물을 만들어내는 저작 도구입니다.
특히 Word 에디터는 문단을 이동하고 텍스트를 선택하고 표와 그림을 편집하며 도형의 위치와 순서를 바꾸는 상호작용이 계속 발생합니다.

일부 에디터 기능을 사용할 수 없다면 단순히 정보를 놓치는 것을 넘어 문서 작성 자체가 어려워질 수 있습니다.
그래서 문서 에디터에서는 키보드와 스크린 리더를 사용하는 사용자도 같은 작업을 수행할 수 있는지 더 자세히 검토해야 했습니다.

Word 에디터의 구조도 일반적인 웹 페이지보다 복잡했습니다.
한 화면 안에 편집 영역과 도구 모음, 메뉴, 다이얼로그가 함께 있고 UI의 포커스와 문서에서 선택한 개체가 별개의 상태로 관리됩니다.
페이지 단위로 문서를 보여주기 때문에 페이지 경계에서 문단이나 표가 여러 조각으로 나뉘기도 합니다.
텍스트를 입력받는 요소와 입력한 텍스트가 표시되는 문서 영역도 분리되어 있습니다.

ARIA 속성을 몇 개 추가하는 것만으로는 충분하지 않았습니다.
사용자가 편집 영역을 찾는 일부터 문서 구조를 이해하고 이동 결과를 확인하고 마우스로 하던 기능을 키보드로 실행하는 과정까지 함께 살펴야 했습니다.

이번 작업은 문서 에디터의 접근성을 한 번에 완성하려는 시도는 아니었습니다.
우선 키보드와 스크린 리더로 수행해야 할 핵심 작업을 정리하고 기존 편집 구조를 해치지 않는 범위에서 단계적으로 적용했습니다.

필요한 접근성 기능

먼저 에디터의 문서 구조와 키보드 입력이 어떻게 처리되는지 조사하고 이를 바탕으로 키보드와 스크린 리더를 사용하는 사용자에게 제공해야 할 정보와 동작을 정리했습니다.

스크린 리더에 제공할 정보

  • 문서를 편집하는 영역의 역할과 이름
  • 키보드로 이동한 위치와 현재 문단의 내용
  • 표의 전체 행·열 수와 현재 셀의 위치
  • 그림의 대체 텍스트
  • 클릭 가능한 UI의 버튼 역할
  • 다이얼로그와 진행 상태
  • 의미 있는 이미지와 장식용 아이콘의 구분

제공할 키보드 조작

  • 도형 이동·크기 조절·앞뒤 순서 변경
  • 클릭 가능한 UI의 키보드 동작과 포커스 표시

이 기능들은 서로 맞물려 있었습니다.
요소의 종류와 용도를 스크린 리더에 알려도 키보드로 조작할 수 없다면 실제로 그 기능을 사용할 수 없습니다.
반대로 키보드로 조작할 수 있더라도 스크린 리더가 이동한 위치를 읽어 주지 않으면 사용자는 현재 어느 내용을 편집하고 있는지 알기 어렵습니다.
접근성 정보와 실제 동작은 함께 구현해야 했습니다.

편집 영역에 역할과 이름 적용

기존 편집 영역은 레이아웃을 위한 div였습니다.
시각적으로는 문서가 표시되는 핵심 영역이 분명했지만 스크린 리더의 landmark 탐색에서는 이 영역의 목적을 바로 파악하기 어려웠습니다.

참고: landmark는 웹페이지의 머리말, 내비게이션, 주요 콘텐츠처럼 큰 영역을 구분하는 접근성 구조입니다.
스크린 리더 사용자는 landmark 목록을 확인하고 원하는 영역으로 바로 이동할 수 있습니다.
에디터에서는 문서 편집 영역을 주요 콘텐츠로 구분하고 도구 모음과 다이얼로그에는 각각의 용도에 맞는 역할을 제공할 수 있습니다.
이번 작업에서는 문서 편집 영역을 main landmark로 지정했습니다.

공통 콘텐츠 컴포넌트가 선택적으로 role과 aria-label을 받을 수 있게 확장한 뒤 다음과 같이 편집 영역의 역할과 이름을 지정했습니다.

<Content role="main" aria-label="문서 편집 영역">
  <WordDocument />
</Content>

role="main"은 화면의 핵심 콘텐츠가 어디인지 알려주고 “문서 편집 영역”이라는 이름은 사용자가 landmark 목록에서 목적을 이해하도록 돕습니다.
공통 컴포넌트 자체에 이 역할을 고정하지 않고 선택형 속성으로 만든 이유도 있습니다.
같은 컴포넌트를 사용하는 다른 에디터까지 Word 편집 영역과 같은 의미로 바뀌어서는 안 되기 때문입니다.

Word 에디터의 입력 구조와 기존 단축키 안내

Word 에디터는 페이지 단위로 문서를 보여주기 때문에 텍스트 입력을 받는 HTML 요소와 문서 내 텍스트를 표시하는 HTML 요소가 분리되어 있습니다.
사용자가 텍스트 입력 요소에 내용을 입력하면 문서의 텍스트 모델이 변경되고 그 결과가 페이지에 렌더링됩니다.

텍스트를 입력받는 요소와 표시하는 요소가 분리되어 있어, 키보드 입력이 정상적으로 처리되더라도 스크린 리더는 현재 문서의 위치를 파악하기 어렵습니다.
특히 문단이나 페이지를 이동했을 때 표시 영역의 캐럿만 바뀌면 사용자는 현재 어느 문단이나 페이지로 이동했는지 알 수 없습니다.
키보드로 이동한 결과는 스크린 리더에 별도로 알려야 했습니다.

에디터에는 다음과 같은 탐색·편집 단축키가 이미 구현되어 있었습니다.
기존 단축키를 텍스트 입력 요소의 aria-keyshortcuts에 지정해 접근성 트리에 단축키 정보를 넣었습니다.

  • Ctrl + ↑/↓: 이전·다음 문단으로 이동
  • Ctrl + ←/→: 이전·다음 단어로 이동
  • Ctrl + Home/End: 문서 처음·끝으로 이동
  • Ctrl + PageUp/PageDown: 이전·다음 페이지로 이동
  • Ctrl + F: 검색
  • Ctrl + K: 링크 삽입
  • Ctrl + Alt + M: 댓글 추가

aria-keyshortcuts는 단축키를 구현하지 않고 이미 동작하는 키 조합을 접근성 정보로 알립니다.
스크린 리더의 단축키 안내 방식과 지원 범위는 제품마다 다를 수 있으므로, 주요 단축키는 별도의 사용법 설명에도 적어 두었습니다.
이 설명에는 모든 단축키를 길게 나열하지 않고 문서와 단락 경계를 탐색하는 대표적인 방법만 담았습니다.
지나치게 많은 안내는 실제 편집을 시작하기도 전에 긴 설명을 듣게 만들 수 있기 때문입니다.

이동한 단락을 스크린 리더로 안내하기

키보드로 이동할 수 있다는 사실만으로 접근 가능한 탐색이 완성되지는 않습니다.
이동한 뒤 현재 위치와 내용을 알 수 있어야 다음 행동을 결정할 수 있습니다.

참고: live region은 화면의 변경 내용을 포커스 이동 없이 스크린 리더에 알려주는 영역입니다.
내용이 갱신되면 스크린 리더가 변경된 정보를 읽습니다.

그래서 사용자가 단축키로 문단이나 페이지를 이동하면 에디터가 live region의 내용을 현재 단락으로 갱신하도록 했습니다.

  • Ctrl + ↑/↓: 이동한 단락의 텍스트로 live region 갱신
  • Ctrl + Home/End: 문서의 처음·끝에 도착했다는 정보와 현재 단락의 텍스트로 live region 갱신
  • Ctrl + PageUp/PageDown: 페이지 이동 정보와 현재 단락의 텍스트로 live region 갱신

키 이벤트가 발생한 순간에는 문서의 선택 상태가 아직 이전 위치를 가리킬 수 있었습니다.
편집 동작이 처리되고 선택이 갱신된 뒤의 값을 읽기 위해 다음 requestAnimationFrame 콜백에서 현재 단락을 조회했습니다.

requestAnimationFrame(() => {
  const paragraph = getCurrentParagraph();
  announce(normalizeParagraph(paragraph));
});

live region에 넣을 문단 텍스트는 그대로 사용하지 않았습니다.
연속된 공백을 정리하고 빈 단락은 “빈 단락”이라는 문구로 바꿨습니다.
너무 긴 단락이 탐색을 방해하지 않도록 최대 200자로 제한했습니다.

live region으로 사용하는 HTML 요소에는 role="status"와 aria-atomic="true"를 지정했습니다.
같은 단락을 다시 방문하면 이전과 같은 문자열은 변경으로 감지되지 않을 수 있습니다.
그래서 live region의 내용을 먼저 비운 뒤 다음 animation frame에 다시 설정했습니다.

<p role="status" aria-atomic="true" className="sr-only">
  {announcement}
</p>

모든 키 입력마다 live region을 갱신하지는 않았습니다.
입력할 때마다 상태 메시지를 갱신하면 작성 중인 문서 내용과 이동 정보가 연속해서 읽혀 사용자가 내용을 이해하기 어려울 수 있기 때문입니다.
문단이나 페이지를 이동하는 단축키를 사용했을 때만 현재 문단의 내용과 이동 정보를 live region으로 알렸습니다.

기존 단축키 구조에 도형 순서 변경 연결하기

앞서 살펴본 탐색·편집 단축키 외에도 Word 에디터에는 도형을 조작하는 단축키가 이미 구현되어 있었습니다.

  • 방향키: 도형 이동
  • Shift + 방향키: 도형 크기 조절
  • Alt + ←/→: 도형 회전
  • Tab, Shift + Tab: 이전·다음 도형 선택
  • Delete: 도형 삭제
  • Escape: 도형 선택 해제

이번 작업에서는 새로운 키 입력 체계를 만들지 않고 기존 단축키 구조에 빠져 있던 도형의 앞뒤 순서 변경 동작을 추가했습니다.

문서에서 이미지와 도형, 텍스트 상자는 서로 겹칠 수 있습니다.
마우스나 메뉴로는 선택한 개체를 한 단계 앞으로 가져오거나 뒤로 보내고 맨 앞이나 맨 뒤로 이동할 수 있었습니다.
하지만 같은 동작을 실행하는 키보드 경로는 없었습니다.

순서 변경에 사용할 Ctrl + ↑/↓와 Ctrl + Shift + ↑/↓는 본문에서 이미 문단 이동과 선택 확장에 사용되고 있었습니다.
현재 선택된 요소에 따라 실행할 동작이 달라야 했습니다.
도형만 선택된 상태에서는 도형의 앞뒤 순서를 변경하고 본문에 캐럿이 있거나 텍스트가 선택된 상태에서는 기존처럼 문단을 이동하거나 선택 범위를 확장하도록 했습니다.

const hasOnlyGraphicSelection =
  hasGraphicSelection() && !hasBlockSelection() && !hasCaretSelection();
 
executeCommand(
  hasOnlyGraphicSelection ? BRING_FORWARD : MOVE_TO_PREVIOUS_PARAGRAPH,
);

나머지 키 조합도 같은 기준으로 도형을 한 단계 뒤로 보내거나 맨 앞 또는 맨 뒤로 이동하도록 연결했습니다.
이때 도형의 선택 여부뿐 아니라 본문에 캐럿이나 텍스트 선택이 있는지도 함께 확인했습니다.
이를 구분하지 않으면 도형 조작과 텍스트 편집 동작이 섞일 수 있습니다.

도형의 표시 순서를 키보드 이벤트에서 직접 변경하지 않고 기존 편집 로직을 호출했습니다.
마우스와 키보드가 같은 도메인 동작을 사용하면 입력 방식마다 별도의 로직이 생기지 않습니다.
기존 Undo/Redo와 문서 상태 변경 흐름도 그대로 유지할 수 있습니다.
접근성을 위한 경로를 별도로 만드는 것보다 같은 기능에 도달하는 또 하나의 입력 경로로 연결하는 편이 상태의 일관성을 지키기 쉬웠습니다.

표와 그림의 의미 전달하기

표의 위치 정보

표에서는 현재 셀의 내용뿐 아니라 표 전체의 구조와 현재 위치도 중요합니다.
사용자가 “몇 행 몇 열의 표인지”, “현재 어느 셀에 있는지”를 알 수 있도록 표에 전체 행·열 수를, 각 행과 셀에는 실제 위치를 지정했습니다.

  • 표: aria-rowcount, aria-colcount
  • 행: aria-rowindex
  • 셀: aria-colindex

기존 셀에는 gridcell 역할이 사용되고 있었지만 실제 구조는 키보드로 탐색하는 ARIA grid가 아니라 네이티브 table이었습니다.
역할이 강하다고 해서 더 접근 가능해지지는 않습니다.
구현된 구조와 동작에 맞춰 cell로 수정했습니다.

그림의 대체 텍스트

그림의 접근 가능한 이름은 문서 파일에 저장된 OOXML 메타데이터에서 가져왔습니다.
작성자가 입력한 description을 우선하고 값이 없으면 title과 name을 차례로 확인했습니다.

모든 그래픽을 무조건 이미지로 노출하지는 않았습니다.
설명이 있는 Word 그림에만 role="img"와 접근 가능한 이름을 붙이고 대체 텍스트가 없는 그림은 임의의 내부 리소스 이름으로 읽히지 않도록 장식 요소로 유지했습니다.

차트와 텍스트 상자, 임의 도형까지 하나의 이미지로 취급하면 내부 텍스트나 표의 의미가 사라질 수 있습니다.
“화면에 그림처럼 보인다”는 이유만으로 동일한 역할을 부여하지 않고 문서 모델에서 어떤 개체인지와 유효한 설명이 있는지를 함께 확인했습니다.

공통 UI 접근성도 함께 개선하기

문서 영역에 접근할 수 있어도 도구 모음과 다이얼로그를 사용할 수 없다면 편집 작업을 끝낼 수 없습니다.
Word 화면에서 함께 사용하는 공통 UI도 명확한 문제부터 수정했습니다.

클릭 요소를 실제 버튼으로 변경하기

일부 클릭 요소는 div에 버튼 역할과 키보드 포커스를 추가한 형태였습니다.
그중에는 aria-hidden="true"가 함께 지정돼 포커스는 이동하지만 스크린 리더에는 인식되지 않는 모순된 상태도 있었습니다.

이를 <button type="button">으로 바꿨습니다.
div는 콘텐츠를 묶는 요소이므로 버튼 역할과 키보드 동작을 직접 구현해야 합니다.
반면 네이티브 button은 Tab 포커스, Enter·Space 실행, disabled 상태를 기본으로 제공합니다.
type="button"은 폼 안에서 의도하지 않게 제출 버튼으로 동작하는 것을 막습니다.

키보드 포커스 표시하기

전역 스타일에서 기본 outline이 제거되어 있어 Tab 키로 이동해도 현재 포커스된 버튼을 확인하기 어려웠습니다.
button:focus-visible에 2px 윤곽선을 추가해 키보드로 포커스한 버튼의 위치를 표시했습니다.
마우스로 버튼을 클릭한 경우에는 윤곽선이 나타나지 않습니다.

button:focus-visible {
  outline: 2px solid #005fcc;
  outline-offset: 2px;
}

다이얼로그와 상태 전달하기

화면 뒤쪽을 가리고 현재 다이얼로그만 조작할 수 있게 하는 경우에는 aria-modal="true"를 지정했습니다.
이 속성은 현재 다이얼로그가 열린 동안 배경 콘텐츠를 사용할 수 없다는 상태를 스크린 리더에 알립니다.
포커스는 기존 로직을 통해 다이얼로그 내부에서만 이동합니다.
Escape로 닫으면 다이얼로그를 열었던 요소로 돌아갑니다.

로딩처럼 화면의 상태가 바뀌는 경우에는 상태 영역에 role="status"와 aria-live="polite"를 적용했습니다.
상태가 변경되면 스크린 리더는 사용자가 듣고 있는 내용을 끊지 않고 이를 읽어 줍니다.
반면 다시 불러오기처럼 사용자가 직접 실행해야 하는 기능은 상태 문구로 두지 않고 버튼으로 만들었습니다.
이 버튼에는 용도를 알 수 있는 이름을 붙였습니다.

장식과 의미를 구분하기

화면에 보이는 아이콘과 이미지를 모두 스크린 리더가 읽게 할 필요는 없습니다.
버튼 옆의 화살표나 구분을 위한 아이콘처럼 주변 텍스트와 같은 의미를 반복하는 이미지는 오히려 내용을 이해하는 데 방해가 될 수 있습니다.
이러한 장식용 SVG에는 aria-hidden="true"를, 장식용 PNG에는 빈 alt=""를 적용해 스크린 리더의 탐색 대상에서 제외했습니다.

반대로 경고 아이콘처럼 이미지 자체가 정보를 전달하는 경우에는 용도를 설명하는 이름을 붙일 수 있도록 했습니다.
내부에서 사용하는 파일명이나 리소스 ID가 그대로 읽히지 않게 하고 “경고”처럼 사용자가 이해할 수 있는 이름으로 읽히게 했습니다.

메뉴 항목은 마우스와 키보드에서 같은 상태와 동작을 갖도록 수정했습니다.
비활성 메뉴는 마우스로 클릭하거나 키보드로 실행할 수 없게 했고 활성 메뉴는 Enter뿐 아니라 Space로도 실행할 수 있게 했습니다.
aria-expanded는 하위 메뉴가 실제로 있는 항목에만 넣어 스크린 리더가 해당 메뉴를 펼치거나 접을 수 있는 항목으로 인식하도록 했습니다.
하위 메뉴가 없는 항목에는 이 속성을 넣지 않아 실제 동작과 접근성 정보가 다르게 전달되는 것을 막았습니다.

검증한 범위와 남은 검증

접근성은 코드에 속성이 존재한다는 사실만으로 검증하기 어렵습니다.
이번 작업에서는 자동 테스트로 보장한 범위와 수동으로 확인할 범위, 아직 필요한 검증을 구분했습니다.

추가한 자동 테스트

도형 순서 변경

도형 순서 변경 단축키는 선택 상태에 따른 동작 분기를 테스트했습니다.

  1. 도형만 선택됐을 때 각 단축키의 도형 순서 변경 동작 실행
  2. 도형이 선택되지 않았을 때 기존 문단 이동과 선택 동작 유지

공통 버튼

공통 버튼에는 다음 회귀 테스트를 추가했습니다.

  1. 클릭 가능한 요소의 네이티브 버튼 역할 인식
  2. 스크린 리더에 전달할 버튼 이름 제공
  3. 비활성 상태에서 마우스로 클릭해도 click handler 미실행

수동으로 확인해야 할 항목

구조와 상태 전달은 다음과 같은 사용 흐름을 기준으로 점검할 수 있습니다.

  • 키보드만으로 편집 영역과 공통 버튼에 도달할 수 있는지
  • 브라우저 접근성 트리에서 편집 영역의 역할과 이름이 올바른지
  • 문단과 페이지를 이동한 뒤 live region이 현재 내용을 안내하는지
  • 표의 행·열 수와 셀 위치가 올바른지
  • 설명이 있는 그림과 장식용 그림이 구분되는지
  • 다이얼로그의 포커스 이동과 복귀가 자연스러운지

아직 필요한 스크린 리더 검증

실제 스크린 리더로 경험하는 것은 자동 테스트와 접근성 트리만으로 대신할 수 없습니다.
NVDA와 VoiceOver에서 탐색 순서와 음성 안내 내용을 확인하고 여러 브라우저 조합에서 편집 흐름을 검증하는 작업은 다음 단계로 남겼습니다.
구현 여부와 실제 사용 가능성을 같은 의미로 표현하지 않기 위해 완료한 검증 범위를 분명히 구분했습니다.

Canvas에서의 웹 접근성

이번 Word 에디터 구현과 별개로, Canvas를 사용하는 화면에서는 접근성을 어떻게 구현해야 하는지도 살펴봤습니다.

<canvas> 자체는 하나의 DOM 요소입니다.
하지만 Canvas API로 그린 텍스트와 도형, 표는 각각의 DOM 요소로 생성되지 않습니다.
브라우저는 화면에 그려진 픽셀만으로 어떤 부분이 문단이고 버튼인지, 어떤 순서로 읽어야 하는지 알 수 없습니다.
따라서 Canvas에 aria-label 하나를 붙이는 것만으로는 내부 콘텐츠의 구조와 현재 선택 상태를 스크린 리더에 전달할 수 없습니다.

Canvas와 별도의 HTML 구조 만들기

스크린 리더가 Canvas로 그린 콘텐츠를 읽게 하려면 같은 데이터를 바탕으로 별도의 HTML 구조를 만들어야 합니다.
화면은 Canvas로 렌더링하더라도 접근성 트리에는 문단과 표, 버튼처럼 의미를 가진 HTML 요소를 두는 방식입니다.

<div>
  <canvas aria-label="문서 화면" />
 
  <section className="sr-only" aria-label="문서 내용">
    <p>회의 결과를 공유합니다.</p>
  </section>
 
  <div aria-label="선택한 도형 조작">
    <button type="button">선택한 도형 삭제</button>
  </div>
</div>

스크린 리더에 문서 내용을 전달하는 HTML은 display: none이나 aria-hidden="true"로 숨기면 접근성 트리에서도 제외됩니다.
화면에서만 보이지 않게 하는 sr-only 스타일을 사용해 접근성 트리에는 남겨둬야 합니다.
하지만 버튼처럼 키보드로 조작하는 요소는 포커스 위치를 확인할 수 있도록 화면에도 표시해야 합니다.

Canvas와 접근성 상태 동기화하기

별도의 HTML을 만든 뒤에도 Canvas에서 선택한 개체나 현재 위치가 바뀔 때마다 접근성 요소의 상태를 함께 갱신해야 합니다.

  • Canvas에서 선택한 문단이나 개체와 접근성 요소의 상태 동기화
  • 현재 페이지와 선택한 개체, 작업 결과를 live region에 전달
  • 드래그로만 실행할 수 있는 기능에 단축키나 속성 입력 화면 제공
  • 장식용 도형과 선택 테두리는 제외하고 필요한 콘텐츠만 접근성 구조에 포함

접근성 구조의 순서는 화면 좌표가 아니라 콘텐츠의 데이터 모델을 기준으로 구성해야 합니다.
화면에서 가까이 배치된 요소라도 내용을 읽는 순서에서는 떨어져 있을 수 있기 때문입니다.

Canvas에 많은 개체가 있더라도 모든 개체를 Tab 순서에 넣는 것은 적절하지 않습니다.
목록이나 탐색 기능으로 개체 사이를 이동하게 하고 현재 선택한 개체의 상태만 갱신하는 방식이 필요합니다.
결국 Canvas 접근성을 갖추려면 픽셀로 그린 화면을 그대로 설명하기보다 같은 데이터를 HTML 구조와 키보드 동작으로 다시 제공하고 두 상태를 계속 일치시켜야 합니다.

웹 접근성을 적용하며 정리한 기준

웹 접근성을 적용하며 다음 기준을 정리했습니다.

  1. ARIA를 추가하기 전에 네이티브 HTML을 우선합니다.
  2. 마우스로 실행하는 기능에는 키보드 대안을 제공합니다.
  3. 화면에 보이는 상태와 스크린 리더에 전달되는 상태를 일치시킵니다.
  4. 입력 방식마다 로직을 새로 만들지 않고 기존 편집 로직을 재사용합니다.
  5. 자동 검사 결과만으로 판단하지 않고 실제 키보드와 스크린 리더로 확인합니다.

웹 접근성은 개발 마지막에 ARIA 속성을 덧붙이는 일로 끝나지 않습니다.
사용자가 기능에 도달하는지, 현재 상태를 이해하는지, 입력 방식이 달라도 같은 결과를 만들 수 있는지를 살피는 일까지 포함합니다.

특히 문서 에디터는 사용자가 정보를 읽는 데 그치지 않고 직접 결과물을 만드는 도구입니다.
접근할 수 없는 기능 하나가 문서 작성의 일부를 막을 수 있습니다.
화면에 보이는 정보와 키보드 동작은 스크린 리더에도 함께 전달하고 실제 사용 흐름에서 계속 검증해야 합니다.