Accessibility & Inclusive Design

1. Overview

접근성 및 포용적 설계(Accessibility & Inclusive Design, AID)는 인종, 나이, 신체적·인지적 한계와 상관없이 지구상의 모든 사용자가 디지털 시스템의 정보를 수리적으로 공평하게 수용할 수 있도록 보장하는 '인터페이스 윤리이자 법적 컴플라이언스 물리학'입니다.

"정상인"이라는 가상의 평균값에 맞춰 시스템을 설계하는 것은 폭력적일 뿐만 아니라 기업의 잠재 고객을 절반으로 잘라내는 행위입니다. 학습자는 시각 장애인이 화면을 귀로 듣게 해주는 스크린 리더(Screen Reader)의 수리적 렌더링 트리(DOM/AOM)를 뜯어보고, 마우스를 쥘 수 없는 사용자를 위한 완벽한 키보드 내비게이션의 물리적 논리를 배웁니다. 더불어 국제 표준 규격인 WCAG 2.2를 수치 단위로 준수하고, 다크 모드(Dark Mode)와 에르고노믹스를 통해 망막의 피로와 인지 하중을 제어하는 하이엔드 포용 거버넌스의 세계를 마스터합니다.

2. Scope & Boundaries

In-Scope

• 보편적 설계와 기계 번역 (Universal Design): 스크린 리더(Screen Reader) 작동 물리, 시맨틱 태그 구조(Semantic HTML), 접근성 트리(Accessibility Tree), WAI-ARIA 속성.
• WCAG 표준과 검수 (WCAG Audit): W3C WCAG 2.2 표준(인지성, 조작성, 이해성, 견고성), 포커스 관리(Focus Management), 명도 대비 수치 검수.
• 인지 다양성 설계 (Cognitive Accessibility): 자폐 스펙트럼, 난독증, ADHD를 고려한 인지적 배려 레이아웃 및 텍스트 구조 설계.
• 시각 에르고노믹스 (Visual Ergonomics): 다크 모드 물리, 글꼴 가독성 수치, 모션 감도 조절(Prefers-Reduced-Motion).

Out-of-Scope

• 보조 공학 하드웨어 제조 기술: 점자 디스플레이나 안구 마우스 칩셋의 물리적 회로 설계 $\rightarrow$ 기계공학 및 하드웨어 제조 영역.
• 순수 사회 복지 정책: 장애인 차별 금지법 제정 과정과 정치적 옹호 $\rightarrow$ 법학 및 행정학 영역 (단, 기술 규제로서의 컴플라이언스는 다룸).

Boundaries

• AID vs. VGD (12-02): VGD(12-02)가 브랜드의 정체성을 보여주기 위해 "연한 회색 바탕에 하얀색 글씨"의 아름다움을 추구한다면, AID는 그 디자인이 색각 이상자나 저시력자에게 읽히지 않음을 수리적으로 증명하여 명도 대비(Contrast Ratio) 4.5<1> 이상으로 강제 수정시키는 상위 컴플라이언스 체계입니다.

3. Counterexample

• 아리아(ARIA) 떡칠의 재앙 (No ARIA is better than bad ARIA Fallacy): 웹 접근성을 맞춘답시고 시맨틱 태그(<button>, <nav>)를 쓰지 않고 평범한 <div> 태그에 role="button" aria-pressed="true" 등 온갖 ARIA 속성을 덕지덕지 발라놓는 행위. 스크린 리더 기계가 이 어설픈 코드 뭉치를 읽다 발작을 일으킵니다. 최적의 접근성은 억지스러운 속성 주입이 아니라, 기본 시스템 태그 구조 자체를 브라우저 렌더링 엔진이 날것 그대로 수리적으로 잘 읽어낼 수 있게 뼈대(DOM)를 제대로 세우는 것입니다.
• 색상에만 의존하는 정보 전달 (Color-only Fallacy): 폼 입력에서 에러가 났을 때 입력칸 테두리를 '빨간색'으로만 바꾸어 알려주는 행위. 적록 색맹 사용자의 눈에 그 테두리는 짙은 회색으로 보이며, 시스템이 에러 났다는 사실을 인지할 수 없는 미아 상태에 빠집니다. 에러를 전달할 때는 물리적인 '색상'의 파장에만 의존할 것이 아니라, X 형태의 아이콘과 "비밀번호가 틀렸습니다"라는 명시적인 텍스트(형태적/의미론적 수치)를 반드시 동반해야만 합니다.

4. Prerequisites

• 프론트엔드 마크업 구조 (Basic): HTML의 시맨틱 태그 구조를 완벽히 숙지해야 스크린 리더기가 화면을 어떻게 파싱(Parsing)하는지 예측할 수 있습니다. (08-04. WAP)
• 인간 인지 반응 법칙 (Recommended): 인지 부하 이론을 이해해야 노인이나 인지 장애를 가진 사용자가 화면에서 겪는 혼란을 막을 수 있습니다. (12-01. HPC)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 보편적 설계와 기계 인지 트리 (Universal Design & AOM)

• Why to Learn: 시각 장애인은 화면을 '보는' 것이 아니라 스크린 리더기가 HTML 코드를 위에서부터 '읽어주는' 소리를 듣기 때문에, 화면의 시각적 위계를 코드의 수리적 위계로 일치시키기 위해서입니다.
• What to Learn:
  • Concepts: 보편적 설계(Universal Design), 대체 텍스트(Alt Text).
  • Skills: 시맨틱 마크업(Semantic Markup), DOM(문서 객체 모델)과 AOM(접근성 객체 모델)의 차이, 랜드마크(Landmark) 설정.
  • Tools: 스크린 리더(VoiceOver, NVDA, JAWS).
  • Trade-offs: 이미지 하나하나에 장황한 대체 텍스트를 달아 정보의 디테일을 살리는 것 vs 시각 장애인이 그 긴 설명을 다 듣느라 정작 중요한 "구매" 버튼으로 넘어가는 시간이 기하급수적으로 길어지는 청각적 피로도 간의 절충.
• How to Learn:
  • 1단계: 모니터를 끄고 오직 VoiceOver(스크린 리더) 소리에만 의존하여 평소 쓰던 쇼핑몰에서 상품을 구매해 보는 눈먼 자들의 테스트를 직접 수행해 봅니다.
  • 2단계: 화면상에서는 굵고 큰 글씨라 당연히 '제목'으로 보이지만, 코드가 <h1>이 아니라 <div style="font-size:30px">로 짜여있을 때 스크린 리더가 이를 제목 계층(Heading Hierarchy)으로 인식하지 못하고 무시해버리는 AOM 파싱의 실패를 수리적으로 추적합니다.
• Implement: 특정 홍보용 이미지 베너 코드에 시각 장애인에게 핵심 정보(예: "50% 할인 쿠폰 다운로드")를 전달할 수 있는 적절한 alt 속성과, 불필요한 장식용 이미지(aria-hidden="true")를 분리해내는 스크립트 재작성.

Recommended

Core Topic 02: WCAG 표준 수치 검수와 포커스 역학 (WCAG & Keyboard Nav)

• Why to Learn: 정부나 글로벌 대기업 납품 시, 인터페이스가 국제 법적 기준(WCAG)의 수치를 통과하지 못하면 소송당하거나 프로젝트가 좌초되는 것을 막기 위함입니다.
• What to Learn:
  • Concepts: WCAG(Web Content Accessibility Guidelines)의 4대 원칙 (POUR: 인지성, 조작성, 이해성, 견고성).
  • Skills: 명도 대비 수치 검증(Contrast Ratio 4.5<1>), 키보드 탭(Tab) 포커스 트래핑(Focus Trapping), 건너뛰기 링크(Skip Navigation).
  • Tools: Lighthouse A11y Audit, WAVE 검사기.
  • Trade-offs: 디자이너가 미학적으로 숨겨놓은 모달(Modal) 창 뒤로 포커스가 도망가서 시각 장애인이 앱을 종료하지도 못하는 재앙을 막기 위해 억지로 강제 포커스 트랩 코드를 짜야 하는 엔지니어링 오버헤드.
• How to Learn:
  • 1단계: 웹페이지에 키보드의 Tab 키만 눌러 이동할 때, 현재 내가 어디를 선택했는지 보여주는 '포커스 링(Focus Ring)' 윤곽선(outline: none 등)을 디자이너가 지워버렸을 때 발생하는 물리적 미아 상태를 경험합니다.
  • 2단계: 배경색(회색)과 글자색(흰색)의 상대 휘도(Relative Luminance)를 수리적 공식으로 계산하여 명도 대비 비율이 4.5<1을> 넘지 못할 때, 저시력자에게 글씨가 아예 물리적으로 투명화되는 광학적 현상을 해부합니다.
• Implement: 마우스를 쓰지 못하는 운동 장애 사용자를 위해, 복잡한 메인 메뉴 20개를 하나씩 다 탭(Tab) 치며 넘어가야 하는 고통을 해결해 주는 "본문으로 바로가기(Skip to Main Content)" 숨김 버튼 구조 설계.

Practical

Core Topic 03: ARIA 속성과 동적 피드백 물리학 (WAI-ARIA Dynamics)

• Why to Learn: 화면이 새로고침되지 않고 자바스크립트로 부분만 바뀌는 최신 웹(React/Vue) 환경에서, 바뀐 정보를 스크린 리더 기계에게 실시간으로 "푸시(Push)" 해주기 위해서입니다.
• What to Learn:
  • Concepts: WAI-ARIA(Web Accessibility Initiative – Accessible Rich Internet Applications).
  • Skills: 역할(Roles), 속성(Properties), 상태(States), 라이브 리전(Aria-live Regions).
  • Tools: Chrome Accessibility Inspector.
  • Trade-offs: 기본 시맨틱 태그(Native HTML)의 강력하고 가벼운 호환성 vs 커스텀 컴포넌트(예: 화려한 스위치 토글)를 만들기 위해 ARIA 속성들을 수동으로 다 엮어주어야 하는 무거운 보완재로서의 ARIA 한계.
• How to Learn:
  • 1단계: 버튼을 눌러 장바구니에 상품을 넣었는데 화면 일부분만 살짝 바뀌었을 때, 모니터를 볼 수 없는 사람은 그 성공 여부를 절대 알 수 없습니다. 이때 aria-live="polite" 구역에 메시지를 쏴주어 기계가 "장바구니에 담겼습니다"라고 은밀하게 읊어주는 동적 피드백 시스템을 짭니다.
  • 2단계: 평범한 <div> 박스를 role="checkbox"로 만들었을 때, aria-checked="true" 상태값을 자바스크립트로 직접 관리해주지 않으면 껍데기만 체크박스일 뿐 기계적 상태는 변하지 않는 수리적 위장을 해체합니다.
• Implement: 커스텀 아코디언(Accordion) 메뉴를 만들 때, aria-expanded 속성과 aria-controls 속성을 묶어 버튼을 누를 때마다 아래 영역이 펼쳐지고 닫힘을 스크린 리더와 동기화하는 상태 관리 컴포넌트 작성.

Advanced

Core Topic 04: 다크 모드 에르고노믹스와 인지 포용 (Visual Ergonomics)

• Why to Learn: 단순히 '까만 바탕'을 만드는 유행을 넘어, 백라이트가 망막을 때리는 광학적 피로도를 수치적으로 줄이고 난독증 사용자의 인지 하중을 방어하기 위해서입니다.
• What to Learn:
  • Concepts: 시각적 에르고노믹스(Visual Ergonomics), 신경 다양성(Neurodiversity).
  • Skills: 다크 모드 컬러 시맨틱스(Dark Mode Palettes), 애니메이션 감도 조절(prefers-reduced-motion), 인지 분산(Cognitive De-loading).
  • Tools: OS Accessibility Settings (Reduced Motion).
  • Trade-offs: 완전한 순수 검은색(#000000)에 하얀 글씨(#FFFFFF)를 쓰면 명도 대비가 무한대라 좋을 것 같지만, 오히려 글자 테두리에 빛 번짐(Halation) 현상이 생겨 난독증 사용자의 시신경을 물리적으로 찢어놓는 광학적 역설.
• How to Learn:
  • 1단계: 다크 모드 설계 시 바탕을 완전 검은색이 아닌 짙은 잿빛(#121212)으로 처리하고, 그 위에 얹어지는 카드 뷰의 명도를 높여 '그림자' 대신 '밝기'를 통해 z축 깊이감(Elevation)을 시뮬레이션하는 빛과 그림자의 물리적 반전을 학습합니다.
  • 2단계: 화면 전체가 빙글빙글 도는 화려한 모션 디자인이 전정기관에 장애가 있는 사용자에게 물리적 구토(멀미)를 유발함을 인지하고, 사용자의 OS 설정이 prefers-reduced-motion: reduce일 때 모든 모션을 페이드 인/아웃(Fade)으로 강제 변환하는 미디어 쿼리를 짭니다.
• Implement: OS 환경(Light/Dark/Reduced-Motion)을 자동으로 감지하여 눈부심과 모션 멀미를 수리적으로 차단하는 반응형 CSS 테마 변수 아키텍처 스크립트 작성.

7. Terminology

8. References

Primary References

• [CS2023: HCI/Accessibility] — 인지, 시각, 청각, 운동 장애 모델 및 접근성 엔지니어링 원칙.
• [W3C WCAG 2.1 / 2.2] — 인식의 용이성, 운용의 용이성, 이해의 용이성, 견고성(POUR) 원칙 기반 명세서.

Secondary References

• [WAI-ARIA Authoring Practices] — 모달, 아코디언, 탭 등 복잡한 UI 컴포넌트의 키보드/스크린 리더 구현 패턴.
• [Microsoft Inclusive Design Toolkit] — 상황적(Situational), 일시적(Temporary) 장애를 포괄하는 페르소나 설계법.

Industry References

• [Apple Accessibility Guidelines] — VoiceOver, 스위치 제어, 동적 글자 크기(Dynamic Type) OS 레벨 통합.
• [Google Material Design - Accessibility] — 터치 타겟 크기(최소 48dp), 고대비 모드, 모션 최소화 적용 가이드.

9. Final Checklist

Primary Checklist

• <div>나 <span> 대신 시맨틱 태그(<nav>, <main>, <button>)를 우선 사용하며, 부족한 부분에만 WAI-ARIA 속성을 부여했는가?
• 텍스트와 배경의 명도 대비(Contrast Ratio)가 최소 4.5<1>(일반 텍스트) 이상을 충족하여 저시력자나 야외 환경에서도 가독성을 확보하는가?

Secondary Checklist

• 마우스 클릭 없이 키보드의 Tab, Enter, Space만으로 모든 인터랙티브 요소(모달, 드롭다운)를 탐색하고 조작할 수 있는가?
• 폼(Form) 입력 시 에러가 발생했을 때 색상(예: 빨간색)으로만 경고하지 않고, 스크린 리더가 읽을 수 있는 명확한 텍스트 피드백을 제공하는가?

Industry Checklist

• 모바일 환경에서 터치 타겟의 크기가 최소 44x44pt(또는 48x48dp) 이상 확보되어 운동 조작이 불편한 사용자도 쉽게 누를 수 있는가?
• 운영체제 레벨의 '텍스트 크기 확대' 설정이나 '모션 줄이기(Reduce Motion)' 설정에 앱/웹 UI가 물리적으로 붕괴되지 않고 적응하는가?