접근성 및 사용자 상호작용 문서화를 위한 디자이너 가이드

안타깝게도 접근성 (Accessibility)은 여전히 많은 프로젝트에서 사후 고려 사항으로 취급됩니다. 사용자 상호작용 (User interaction) 및 접근성 요구사항은 기껏해야 제대로 문서화되지 않거나, 디자인을 개발 팀에 전달할 때 잊혀지곤 합니다. 그리고 나중에 이를 수정하는 데는 처음부터 제대로 구축하는 것보다 훨씬 더 많은 비용이 듭니다. 훌륭한 **문서화 (Documentation)**는 팀이 접근성 요구사항을 올바른 방식으로 구현하도록 돕습니다. 이 글은 강연의 텍스트 버전으로, 디자이너가 처음부터 더 나은 포용적인 (Inclusive) 제품을 만들기 위해 왜, 무엇을, 그리고 어떻게 접근성의 다양한 측면과 사용자 상호작용 요구사항을 문서화할 수 있는지 설명합니다.

강연의 비디오 재생본과 스케치노트 (Sketchnotes)를 다양한 곳에서 확인하실 수 있습니다. 또한 여러분의 시작을 돕기 위해 '접근성 및 상호작용 문서화 키트 (Accessibility & Interactions Documentation Kit)'를 준비했습니다.

최종 업데이트 2025년 2월

처음부터 제대로 할 수 있는데, 왜 나중에 수정하나요?

많은 사이트가 접근성 요구사항을 고려하지 않은 채 디자인되고 개발되었습니다. 디자이너로서 우리 중 많은 이들이 "접근성은 개발 팀의 업무"라고 생각합니다. 이로 인해 많은 프로젝트에서 접근성은 사후 고려 사항이 됩니다. 기업들은 접근성이 떨어지는 도구, 사이트, 서비스를 출시합니다.

결국 누군가는 이에 대해 불만을 제기할 것입니다. 어쩌면 사이트가 소송을 당할 수도 있습니다. 이는 다시 팀으로 되돌아옵니다. 그리고 이제 그들은 접근성 문제를 "수정"해야 합니다. 하지만 이는 종종 너무 늦은 경우가 많습니다. 사이트가 접근성을 고려하여 디자인되고 개발되지 않았다면, 수정하기가 더 어렵습니다. 그리고 훨씬 더 비용이 많이 듭니다. 이 사진과 비슷합니다. 그들은 결국 깨진 안경에 덕테이프를 붙이는 격이 됩니다.

제 질문은 이것입니다: 처음부터 제대로 디자인하고 구축할 수 있는데, 왜 나중에 수정하나요?

이것이 바로 우리가 프로젝트 초기 단계부터 접근성 인식 (accessibility awareness)을 가져와야 하는 이유입니다. 훌륭한 가이드라인과 **문서화 (documentation)**를 통해 이를 달성할 수 있습니다. 이는 프로젝트 초기 단계에서 접근성 문제를 식별하고 수정하는 데 도움을 줄 수 있습니다. 접근성이 "프로젝트의 일반적인 디자인 및 개발 단계"의 일부가 됩니다. 더 이상 사후 고려 사항이 아닙니다.

접근성은 디자이너의 업무이기도 합니다!

많은 접근성 문제들은 디자인 단계에서 이미 예측하고 예방할 수 있습니다. 디자이너로서 우리는 디자인에 접근성 모범 사례 (best practices)를 포함하고 접근성 기능을 옹호함으로써 제품 로드맵을 형성할 수 있는 힘을 가지고 있습니다.

디자이너는 **디자인 문서화 (design documentation)**를 사용하여 프로젝트에 접근성을 더 일찍 포함하고 추진할 수 있습니다.

디자이너는 어디에서 어떻게 접근성에 영향을 미칠 수 있을까요?

*먼저 짧은 면책 조항을 말씀드립니다: 이것은 1시간 강연의 녹취록입니다. ** 이미 매우 길지만, 1시간 안에 모든 것을 다룰 수는 없습니다. 저는 이 주제에 대해 8시간 전체 교육 과정을 가지고 있습니다. 따라서 이것은 짧은 버전이라는 점을 유념해 주세요. 또한, 이 내용은 디자이너를 대상으로 합니다. 저는 디자이너가 프로젝트 초기 단계에서 가장 큰 영향을 미칠 수 있는 WCAG 기준(주로 A 및 AA 기준)을 선별했습니다. *

WCAG 2.2 전체 기준을 모두 다루지는 않을 것입니다. 웹사이트를 완전히 준수(compliant)하게 만들려면 이 글 이상의 내용을 살펴봐야 합니다. *

그럼 시작해 보겠습니다. 디자이너가 할 수 있는 일을 파악하는 데 도움을 드리기 위해, 저는 이를 4가지 카테고리로 나누었습니다: 시각 디자인 (Visual design), 상호작용 (Interaction), 길 찾기 (Wayfinding), 그리고 대체 콘텐츠 및 마크업 (Alternative Content and Markup)입니다.

접근성을 위한 시각 디자인 문서화

시각 디자인, 특히 색상은 디자인 문서화를 생각할 때 흔히 가장 먼저 떠오르는 요소입니다.

정보를 전달하기 위해 색상에만 의존하지 마세요

디자이너가 가장 먼저 해야 할 일은 색상이 정보를 전달하는 유일한 시각적 방법이 되지 않도록 보장하는 것입니다.

여기 제 예시를 보면, 요리 사이트의 내비게이션 (navigation)이 있습니다. 첫 번째 예시에서는 "현재 페이지" (categories)를 검은색에서 주황색으로의 색상 변화만으로 표시했습니다. 이것은 문제입니다. 색상을 잘 구별하지 못하는 사용자는 현재 표시 상태를 이해하지 못할 수 있습니다.

해당하는 사용자들은 다음과 같습니다:

• 색맹 (Colorblind)인 사람들.
• 부분적인 시력을 가진 사용자들은 종종 제한된 색각 (color vision)을 경험합니다.
• 일부 고령 사용자는 색상을 잘 보지 못할 수 있습니다.
• 제한된 색상의 단색 (monochrome) 디스플레이를 사용하는 사람들은 색상에 의존하는 정보에 접근하지 못할 수 있습니다.
• 인지 장애 (cognitive disabilities)가 있거나 읽기에 어려움이 있는 사람들.

해결책은 정보를 전달하기 위해 색상에만 의존하지 않는 것입니다. 여기 두 번째 예시에서는 색상은 유지하되, 굵은 테두리 (border)를 추가하여 보완했습니다. 이렇게 하면 색상을 인지하지 못하는 사용자도 정보를 얻을 수 있는 보조적인 방법을 갖게 됩니다.

우리는 무엇을 할 수 있을까요? 디자이너는 목업 (mockups)을 확인하여 색상으로만 전달되는 정보를 식별하고, 해당 색상에만 의존하지 않고 정보를 전달할 수 있는 보조적인 방법을 제공할 수 있습니다. 이는 보통 양식 검증 (form validation) (오류, 성공), 모든 유형의 상태 알림 (status notification), 그리고 차트 (charts), 그래프 (graphs) 등에서도 마찬가지입니다.

충분한 색상 대비비 (color contrast ratios)를 확보하세요

기존 목업을 개발자에게 전달하기 전에, 디자이너는 **텍스트 (texts)**가 배경과 충분한 대비비 (contrast ratio)를 갖추고 있는지 확인해야 합니다:

• 24px 미만 또는 19px 굵은 글씨의 경우, 텍스트와 배경 사이의 대비비 4.5:1
• 24px 초과 또는 19px 굵은 글씨의 경우, 텍스트와 배경 사이의 대비비 3:1

다양한 도구의 선택을 돕기 위해 제 기사인 "색상 접근성: 포용적인 제품 설계를 돕는 도구 및 리소스"를 확인해 보세요. 여러분의 요구 사항에 맞는 도구를 찾을 수 있을 것입니다.

텍스트에서 끝나지 않습니다. 디자이너는 또한 비텍스트 요소 (non-text elements) (UI 컴포넌트, 그래픽 객체 등)에 대한 색상 대비를 확인해야 합니다. 이 요소들은 인접한 색상에 대해 3:1의 대비비가 필요합니다.

비텍스트 요소에는 다음이 포함됩니다:

• 사용자 인터페이스 (UI) 구성 요소를 식별하기 위한 시각적 정보. 예를 들어 텍스트 필드의 테두리, 체크박스, 라디오 버튼 (브라우저 기본 요소를 사용하지 않는 경우).
• 포커스 표시기 (focus indicators)를 식별하기 위한 시각적 정보
• 콘텐츠를 이해하는 데 필요한 그래픽 객체 (예를 들어 텍스트 없이 정보를 전달하는 아이콘이 있는 경우)

이 규칙은 네이티브 HTML 구성 요소와 비활성 구성 요소에는 적용되지 않습니다. 하지만 **포커스 외관 (focus appearance)**에는 적용됩니다. 즉, 포커스 표시 영역의 일부(포커스 표시 영역의 하위 집합)는 포커스가 없는 상태와 포커스가 있는 상태 사이에 3:1의 대비비 (contrast ratio)를 가져야 합니다. 이 주제에 대한 자세한 내용은 Sara의 기사인 '접근 가능하고 WCAG를 준수하는 포커스 표시기를 디자인하기 위한 가이드 (A guide to designing accessible, WCAG-conformant focus indicators)'를 확인하세요.

마지막으로, 이 기준은 기본 버튼 상태가 3:1 비율을 통과하기 위해 배경이나 경계선을 요구하지 않는다는 점에 유의하세요. 버튼 위의 텍스트(또는 아이콘)가 버튼임을 식별하기에 충분하고 (1.4.3 텍스트/배경 기준을 통과한다면) 말입니다. 이는 버튼의 배경이 표시되는 배경과 3:1 비율을 이루지 않더라도 접근성 실패(accessibility failure)가 아님을 의미합니다. 그렇긴 하지만, 대비가 높을수록 언제나 좋으므로, 만약 그 비율을 확보할 수 있다면 반드시 그렇게 하시기 바랍니다.

단락 내 링크를 쉽게 식별할 수 있도록 보장하기

링크는 쉽게 식별 가능해야 하며, 특히 링크가 아닌 텍스트에 둘러싸여 있을 때(예를 들어 단락 내에 있을 때) 더욱 그러합니다. 즉, 사람들이 링크가 아닌 나머지 텍스트로부터 링크를 식별할 수 있어야 한다는 뜻입니다. 어떻게 해야 할까요?

• 텍스트 블록 내에서 색상이 링크를 주변 텍스트와 식별하는 유일한 방법이 아닌지 확인하세요. 가장 쉬운 방법은 텍스트 내의 링크에 밑줄을 긋는 것입니다. - 만약 색상이 링크를 식별하는 유일한 방법이라면, 인접한 비링크 텍스트와 3:1의 대비비를 가져야 하며, 호버 (hover) 시 추가적인 시각적 단서를 제공해야 합니다.

이를 확인하는 데 '대비 삼각형 (The contrast triangle)'을 사용할 수 있습니다. 하지만 진심으로 말씀드리건대, 그냥 링크에 밑줄을 긋고 마무리하세요!

시작부터 접근 가능한 컬러 팔레트 구축하기

언젠가 이 주제에 대해 자세한 글을 쓰겠다고 약속드립니다. 그전까지는 요약 버전으로 말씀드리자면, 새로운 프로젝트를 진행할 때 처음부터 접근 가능한 (accessible) 컬러 팔레트를 구축하고 문서화할 수 있습니다.

저의 단계별 프로세스는 다음과 같습니다:

• 저는 보통 "메인" 컬러부터 시작합니다. 위의 예시에서는 Myriam을 위해 만든 저의 "mermaid palette" 메인 컬러들이 그 예입니다.
• 배경 위의 텍스트로서 함께 작동할 수 있는 컬러 변형 (color variations) (더 어두운 색, 더 밝은 색)을 만듭니다. 저는 모든 "더 어두운 (darker)" 색상들이 "가장 밝은 (lightest)" 색상 위에서 텍스트로 사용될 수 있도록 (그리고 그 반대의 경우도) 4.5의 대비비 (contrast ratio)를 유지하며 구축합니다. 또한 더 어두운 텍스트가 모든 "더 밝은 (lighter)" 색상 위에서도 사용될 수 있도록 합니다.
• 이를 기억하기 위해, 저는 컬러 매트릭스 (color matrix) (Figma 플러그인 또는 온라인 도구)를 사용하여 문서화합니다.
• 마지막으로, 색상들이 어떻게 함께 사용되어야 하는지에 대한 컴포넌트 예시를 스타일 가이드 (styleguide)에 문서화합니다. 여기에는 4가지 컬러 변형(핑크, 퍼플, 블루, 아쿠아마린)이 더 어두운 회색 텍스트와 함께 제목으로 사용된 테마가 있습니다. 그리고 각 버전에 대한 콜 투 액션 (call to action, CTA) 예시도 포함되어 있습니다.

팔레트 제작에 도움이 필요하다면, 'Color accessibility: tools and resources to help you design inclusive products' 및 'Tips to Create an Accessible and Contrasted Color Palette'를 확인해 보세요.

스타일 가이드에 컬러 조합 문서화하기

앞서 언급했듯이, 저는 컬러 매트릭스 (color matrix) 도구를 선호합니다. 명도 대비 (contrast ratios)와 함께 컬러 조합을 문서화할 수 있기 때문입니다. 저는 이와 같은 컬러 매트릭스 도구를 사용합니다. (Figma 플러그인도 있습니다.) 여기서는 가로축과 세로축에 동일한 색상들이 배치되어 있습니다. 두 축의 교차점은 두 색상이 함께 사용되었을 때의 대비비 (color ratio)를 보여줍니다. 이를 통해 해당 두 색상을 다양한 대비비(3:1, 4:5 등)로 함께 사용할 수 있는지를 알 수 있습니다. 예를 들어, 특정 노란색을 어떤 배경 위에서 텍스트로 사용해서는 안 되는지, 혹은 더 어두운 회색 배경 위에서는 텍스트로 사용할 수 있는지 등을 파악할 수 있습니다. 그런 다음 이 매트릭스를 프로젝트에 포함하여, 다른 디자이너들이 사용해도 되는 컬러 조합과 사용해서는 안 되는 조합을 알 수 있도록 합니다.

스타일 가이드에 특정 컬러 조합 문서화하기

디자인 시스템 (design system) 내에서 저는 특정 컬러 조합의 사용 방식, 즉 무엇이 허용되고 무엇이 허용되지 않는지도 문서화하려고 노력합니다.

제 디자인 시스템에 있는 상태 (status) 표시 예시가 있습니다. 각 상태에는 4가지 변형 (variant)이 있습니다.

성공 (success) 상태의 경우, 4가지 명도의 녹색을 사용합니다: dark, main, light, 그리고 contrastText입니다. (이 명칭들은 Material UI에서 가져온 것이니 묻지 마세요.) 저는 인터페이스 전반에 걸쳐 우리 상태 표시를 위해 색상들을 어떻게 조합할 수 있는지(또는 조합할 수 없는지)를 문서화했습니다. 예를 들어, 성공 상태의 dark 변형 위에 contrastText (또는 흰색)를 텍스트 색상으로 사용할 수 있습니다.

디자인 팀에 AA, AAA 및 대비비에 대해 교육하기

모든 디자이너가 대비비, AA/AAA의 의미, 그리고 작은 텍스트와 큰 텍스트의 개념에 익숙하지 않을 수 있습니다. 따라서 이 내용을 어딘가에는 설명해 두어야 합니다. 또는 외부 자료로 연결되는 링크를 제공할 수도 있습니다. Geri의 '디자이너를 위한 WCAG' 문서나 'accessguide' 페이지의 대비 관련 섹션을 활용할 수 있습니다. 더 많은 도구를 확인하려면 “Color accessibility: tools and resources to help you design inclusive products”를 참조하세요.

텍스트: 200% 크기 조절 및 타이포그래피 팁

텍스트 콘텐츠는 요소를 숨기거나 사이트의 기능을 놓치지 않으면서도(숨겨진 텍스트, 이미지 등이 없이) 200%까지 확대될 수 있어야 합니다.

솔직히 말씀드리면, 저희는 주로 반응형 (Responsive) 환경을 위해 구축하기 때문에 웹사이트에서는 이 부분을 문서화하는 경우가 적은 편입니다. 하지만 개발자들에게 확대 (Zoom) 기능을 차단하지 않도록 확인하고, 200% 확대 시 요소가 숨겨지지 않는지 QA 팀에 테스트를 요청할 것입니다. 여기서 또 다른 부분은 기술적인 부분입니다. 개발자는 사용자가 브라우저의 기본 글꼴을 변경하더라도 그에 맞춰 적응할 수 있도록 유동 단위 (Fluid units, ems, rems)를 사용하여 사이트를 구축해야 합니다. 다시 말씀드리지만, 디자이너가 목업 (Mockup) 단계에서 할 일은 매우 적습니다. 하지만 테스트 중에 무언가 깨진다면, 이것이 어떻게 적응되어야 하는지에 대한 디자인 결정을 내려야 할 수도 있습니다.

하지만 저는 이것이 **네이티브 앱 (Native apps)**에는 정말 유용할 수 있다고 생각합니다. 이것은 Maif의 Goulven Baron이 작성한 예시입니다. 그는 모바일 뷰가 왼쪽의 100% 상태와 200% 확대 상태에서 어떻게 동작하는지를 문서화했습니다.

그럼, 텍스트 크기 조정 및 타이포그래피 (Typography) 디자이너 가이드라인은 다음과 같습니다:

• 고정 높이 버튼 (Fixed height buttons)을 피할 것
• overflow: hidden이 적용된 고정 높이 텍스트 박스를 피할 것
• 필요한 경우 더 큰 글꼴 크기에 맞춰 레이아웃을 조정할 것 (여러 개의 열이 하나로 합쳐지거나, 오른쪽에 있는 보조 텍스트가 다음 줄로 넘어가는 등)
• 더 큰 글꼴에서도 계층 구조 (Hierarchy)를 유지할 것 (H1 제목은 H2보다 커야 하는 등)
• "iIlL10oO"를 사용하여 글꼴의 가독성 (Legibility)을 테스트할 것. 각 문자를 얼마나 쉽게 구별할 수 있습니까?

타이포그래피 모범 사례 (Best practices)에 있어서, 대부분의 WCAG 기준은 기술적인 것들입니다. 예를 들어: 사용자가 읽기 쉽게 텍스트 간격을 조정할 수 있도록 할 것: 줄 높이 (Line-height), 자간 (Letter spacing), 어간 (Word spacing) (WCAG 1.4.12, 기술적 사항)

그럼에도 불구하고, 가독성을 돕기 위해 WCAG를 넘어 적용할 수 있는 몇 가지 실질적인 팁은 다음과 같습니다: