Accessibility

웹 접근성 체크

1. 색상 관련 접근성 체크

1.1 전경색과 배경색 간의 색상 대비 체크

• 전경색과 배경색의 칼라 코드를 Contrast checker에 입력하고 접근성 룰을 다 통과하는지 확인합니다.

웹 접근성 정책

이 위키 문서는 "한국형 웹 콘텐츠 접근성 지침 2.2"를 기반으로 Daleui 디자인 시스템을 설계하고 검토할 때 사용해야 하는 접근성 체크리스트입니다. 모든 UI 컴포넌트, 콘텐츠, 상호작용 요소가 장애인 및 비장애인 모두에게 동등한 접근성을 제공하도록 보장하는 것을 목표로 합니다.

1. 인식의 용이성 (Perceivable)

사용자가 콘텐츠를 인지할 수 있도록 시각, 청각, 촉각 등 다양한 감각을 고려한 설계.

1.1 텍스트 대체 제공

• 모든 비텍스트 콘텐츠(이미지, 아이콘 등)에 적절한 대체 텍스트(alt text)를 제공했는가? 1.1.1 Non-text Content (A)
• 대체 텍스트는 콘텐츠의 목적과 기능을 명확히 설명하는가?

1.2 적응 가능성

• 콘텐츠가 선형 구조로 제공되어 스크린 리더로 이해 가능하도록 설계되었는가? 1.3.1 Info and Relationships (A)
  • Do: HTML 마크업 순서를 논리적 흐름(제목 → 본문 → 관련 링크 등)에 맞게 작성합니다. <h1>~<h6>, <p>, <ul>, <ol>, <nav>, <main> 등 시맨틱 태그를 적절히 사용합니다.
  • Don't: 시각적인 배치만을 위해 CSS position: absolute;나 float를 남용하여 DOM 순서와 시각적 순서가 완전히 다르게 만듭니다. (예: 시각적으로는 오른쪽에 있는 사이드바가 DOM에서는 메인 콘텐츠보다 먼저 나오는 경우)
• 시각적 순서와 논리적 순서가 일치하는가? 1.3.2 Meaningful Sequence (A)
  • Do: 되도록 콘텐츠의 논리적 순서(DOM 순서)가 시각적 읽기 순서와 일치하도록 마크업합니다. Flexbox나 Grid의 order 속성을 사용할 경우, 키보드 탐색 순서(Tab 키)가 여전히 논리적인지 반드시 확인합니다.
  • Don't: CSS Grid나 Flexbox의 order 속성을 사용하여 항목들의 시각적 순서를 변경했으나, 키보드로 탐색할 때는 원래 DOM 순서대로 이동하여 사용자가 혼란을 겪게 만듭니다. (예: 시각적으로 1, 2, 3 버튼이 있지만 Tab 키로는 3, 1, 2 순서로 포커스가 이동하는 경우)
• 반응형 디자인에서 콘텐츠가 손실 없이 모든 디바이스에서 표시되는가? 1.3.4 Orientation (AA)
• 입력 필드의 목적을 명시했는가? 1.3.5 Identify Input Purpose (AA)
  • Do: 사용자 정보를 요구하는 입력 필드(이름, 이메일, 주소, 전화번호 등)에 autocomplete 속성을 적절한 값과 함께 사용합니다. (예: <input type="email" autocomplete="email" name="user_email">)
  • Don't: 이름, 이메일, 주소 등 자동 완성 기능이 유용할 수 있는 필드에 autocomplete 속성을 제공하지 않거나 autocomplete="off"를 불필요하게 사용합니다.

1.3 구별 가능성

• 텍스트와 배경 간 명도 대비가 최소 4.5:1(A) 또는 3:1(AA) 이상인가? 1.4.3 Contrast (Minimum) (AA)
• 텍스트 크기를 200%까지 확대해도 콘텐츠가 손실되지 않는가? 1.4.4 Resize Text (AA)
• 이미지로 된 텍스트 대신 실제 텍스트를 사용했는가? 1.4.5 Images of Text (AA)
• 색상만으로 정보를 전달하지 않았는가? 1.4.1 Use of Color (A)
  • Do: 오류가 발생한 입력 필드를 빨간색 테두리로 표시함과 동시에, 오류 아이콘(❗)과 함께 "필수 입력 항목입니다." 같은 텍스트 메시지를 함께 제공합니다. 링크 텍스트에는 색상과 함께 밑줄을 사용합니다.
  • Don't: 필수 입력 필드임을 나타내기 위해 레이블 텍스트 색상만 빨간색으로 변경합니다. 오류 상태를 입력 필드 테두리 색상만 빨간색으로 바꾸어 표시합니다.

2. 운용의 용이성 (Operable)

사용자가 인터페이스를 쉽게 조작할 수 있도록 설계.

2.1 키보드 접근성

• 모든 기능이 키보드로만 조작 가능하도록 설계되었는가? 2.1.1 Keyboard (A)
  • Do: 커스텀 드롭다운 메뉴를 만들 때, 버튼은 Tab으로 포커스 가능하고 Enter나 Space로 열 수 있으며, 메뉴 항목들은 화살표 키(↑, ↓)로 이동하고 Enter로 선택할 수 있도록 구현합니다. 슬라이더는 화살표 키(←, →)로 값을 조절할 수 있게 합니다. 모든 인터랙티브 요소에 tabindex="0" (필요시) 또는 네이티브 요소(<button>, <a>)를 사용합니다.
  • Don't: 마우스 클릭으로만 열고 닫을 수 있는 커스텀 드롭다운 메뉴를 만듭니다. Drag & Drop 인터페이스에 키보드 대체 수단(예: '위로 이동' 버튼)을 제공하지 않습니다.
• 키보드 포커스가 갇히는 상황(Keyboard Trap)이 없는가? 2.1.2 No Keyboard Trap (A)
• 키보드 단축키가 사용자 맞춤형으로 조정 가능하거나 비활성화 가능하도록 했는가? 2.1.4 Character Key Shortcuts (A)

2.2 충분한 시간 제공

• 시간 제한이 있는 콘텐츠에 대해 사용자에게 충분한 시간을 제공했는가? 2.2.1 Timing Adjustable (A)
• 움직이는 콘텐츠를 일시 정지, 중지, 숨길 수 있는 수단을 제공했는가? 2.2.2 Pause, Stop, Hide (A)
• 중단(Interruptions)이 발생하지 않도록 했거나, 사용자 동의 없이 중단되지 않는가? 2.2.4 Interruptions (AAA) (WCAG 2.2)
• 타임아웃으로 데이터 손실이 발생하지 않도록 경고를 제공했는가? 2.2.6 Timeouts (AAA) (WCAG 2.2)

2.3 광과민성 발작 유발 방지

• 1초에 3회 이상 깜빡이는 콘텐츠가 없거나, 임계값 이하로 제한했는가? 2.3.1 Three Flashes or Below Threshold (A)
• 상호작용으로 발생하는 애니메이션을 사용자가 비활성화할 수 있는가? 2.3.3 Animation from Interactions (AAA) (WCAG 2.2)

2.4 탐색 가능성

• 반복 콘텐츠를 건너뛸 수 있는 "Skip Navigation" 링크를 제공했는가? 2.4.1 Bypass Blocks (A)
• 페이지 제목이 고유하고 설명적인가? 2.4.2 Page Titled (A)
  • Do: 페이지의 주요 내용을 명확히 알 수 있는 제목을 제공합니다. (예: <title>장바구니 - Daleui 스토어</title>, <title>웹 접근성 체크리스트 | Daleui 디자인 시스템</title>)
  • Don't: 모든 페이지의 제목을 <title>Daleui</title> 또는 <title>메인 페이지</title>와 같이 동일하거나 모호하게 설정합니다.
• 포커스 순서가 논리적이고 직관적인가? 2.4.3 Focus Order (A)
  • Do: Tab 키를 눌렀을 때, 페이지의 시각적 흐름(보통 왼쪽에서 오른쪽, 위에서 아래)을 따라 예측 가능하게 포커스가 이동하도록 합니다. 모달 창을 닫으면, 모달을 열었던 버튼이나 링크로 포커스가 돌아가도록 구현합니다.
  • Don't: Tab 키를 누를 때 포커스가 페이지 상단 헤더 → 본문 중간 → 푸터 → 다시 헤더의 다른 요소 등으로 예측 불가능하게 이동합니다. 모달 창을 닫았는데 포커스가 페이지의 맨 처음으로 이동하거나 사라집니다.
• 링크의 목적이 문맥에서 명확한가? 2.4.4 Link Purpose (In Context) (A)
• 다중 탐색 방법(사이트맵, 검색 등)을 제공했는가? 2.4.5 Multiple Ways (AA)
• 제목과 레이블이 명확하고 일관적인가? 2.4.6 Headings and Labels (AA)
  • Do: 페이지 구조에 맞게 <h1>부터 <h6>까지 제목(Heading) 태그를 논리적으로 사용합니다. 모든 입력 필드에는 명확한 <label>을 제공하고, 버튼에는 "저장", "취소", "다음 단계" 등 동작을 명확히 설명하는 텍스트를 사용합니다. 사이트 전체에서 동일 기능의 버튼은 동일한 레이블을 유지합니다(예: 모든 저장 버튼은 "저장").
  • Don't: 시각적으로 제목처럼 보이게 하기 위해 <div>에 큰 폰트와 굵은 스타일만 적용합니다. 버튼에 "클릭", "여기" 등 모호한 레이블을 사용하거나, 아이콘만 있는 버튼에 스크린 리더가 읽을 수 있는 숨은 텍스트나 aria-label을 제공하지 않습니다.
• 포커스가 시각적으로 보이는가? 2.4.7 Focus Visible (AA)

2.5 입력 방식

• 복잡한 제스처 대신 단일 포인터 동작으로 대체 가능하도록 했는가? 2.5.1 Pointer Gestures (A)
• 포인터 입력이 실수로 실행되지 않도록 취소 가능성을 제공했는가? 2.5.2 Pointer Cancellation (A)
  • Do: 버튼 클릭과 같은 액션은 'down' 이벤트(mousedown, touchstart)가 아닌 'up' 이벤트(mouseup, click, touchend)에서 실행되도록 구현합니다. 사용자가 버튼을 누른 상태에서 포인터를 버튼 밖으로 이동한 후 떼면 아무 동작도 일어나지 않아야 합니다.
  • Don't: 버튼을 누르는 순간(mousedown, touchstart) 바로 동작(예: 삭제, 전송)이 실행되도록 하여, 사용자가 실수로 눌렀다가 떼기 전에 취소할 기회를 주지 않습니다.
• 레이블과 프로그래밍적 이름이 일치하는가? 2.5.3 Label in Name (A)
• 모션 기반 입력(예: 흔들기)이 필수가 아닌 선택 사항인가? 2.5.4 Motion Actuation (A)

3. 이해의 용이성 (Understandable)

사용자가 콘텐츠와 인터페이스를 쉽게 이해할 수 있도록 설계.

3.1 가독성

• 페이지의 기본 언어가 명시되어 있는가? 3.1.1 Language of Page (A)
• 특정 부분의 언어가 변경될 경우 이를 명시했는가? 3.1.2 Language of Parts (AA)

3.2 예측 가능성

• 포커스 변경시 예기치 않은 변화가 발생하지 않는가? 3.2.1 On Focus (A)
  • Do: 사용자가 라디오 버튼 그룹 중 하나를 선택하거나 드롭다운 메뉴에서 옵션을 선택했을 때, 별도의 '적용' 또는 '다음' 버튼을 클릭해야만 내용이 변경되거나 페이지가 이동하도록 합니다. 입력 필드에 포커스가 갔다고 해서 자동으로 팝업 창이 뜨지 않도록 합니다.
  • Don't: 드롭다운 메뉴에서 특정 옵션을 선택하는 즉시 페이지가 새로고침되거나 다른 페이지로 이동합니다. 체크박스를 선택하자마자 동의서가 제출됩니다.
• 입력 시 문맥이 예기치 않게 변경되지 않는가? 3.2.2 On Input (A)
• 내비게이션이 모든 페이지에서 일관적인가? 3.2.3 Consistent Navigation (AA)
  • Do: 메인 메뉴(글로벌 내비게이션 바), 푸터, 검색창 등 반복되는 요소는 모든 페이지에서 동일한 위치와 형태로 제공합니다. '장바구니 담기' 버튼은 사이트 내 모든 상품 페이지에서 동일한 아이콘과 텍스트 레이블을 사용합니다.
  • Don't: 어떤 페이지에서는 상단에 있던 주 메뉴가 다른 페이지에서는 왼쪽에 나타납니다. '편집' 기능을 어떤 곳에서는 연필 아이콘으로, 다른 곳에서는 '수정'이라는 텍스트 버튼으로 표시합니다.
• 동일한 기능의 요소가 일관되게 식별되는가? 3.2.4 Consistent Identification (AA)

3.3 입력 도움

• 오류가 발생하면 이를 명확히 식별할 수 있는 메시지를 제공했는가? 3.3.1 Error Identification (A)
  • Do: 폼 제출 시 오류가 있다면, 어떤 필드에서 오류가 발생했는지 해당 필드 옆이나 아래에 명확한 텍스트(예: "이메일 주소를 입력해주세요.")로 알려주고, 해당 필드로 포커스를 이동시키거나 오류 요약 정보를 상단에 제공합니다. aria-describedby를 사용해 오류 메시지와 입력 필드를 프로그래밍적으로 연결합니다.
  • Don't: 폼 제출 실패 시 페이지 상단에 "입력 오류가 있습니다."라는 메시지만 띄우고 어느 필드가 잘못되었는지 알려주지 않습니다. 오류 필드에 테두리 색상만 변경하고 텍스트 설명을 제공하지 않습니다.
• 입력 필드에 레이블 또는 지시문을 제공했는가? 3.3.2 Labels or Instructions (A)
• 오류 발생 시 수정 제안을 제공했는가? 3.3.3 Error Suggestion (AA)
• 법적/금융/데이터 관련 오류를 방지할 수단(확인 단계 등)을 제공했는가? 3.3.4 Error Prevention (Legal, Financial, Data) (AA)

4. 견고성 (Robust)

다양한 기술과 보조 도구에서 안정적으로 작동하도록 설계.

4.1 호환성

• HTML/CSS가 파싱 오류 없이 올바르게 작성되었는가? 4.1.1 Parsing (A)
• 모든 요소에 이름(Name), 역할(Role), 값(Value)이 프로그래밍적으로 제공되었는가? 4.1.2 Name, Role, Value (A)
  • Do: 커스텀 체크박스를 <div>와 CSS로 만들었다면, <div role="checkbox" aria-checked="true" tabindex="0" aria-labelledby="label-id"> 와 같이 ARIA 속성을 사용하여 역할(checkbox), 상태(checked), 이름(labelledby)을 명시합니다. 표준 HTML 컨트롤(<button>, <input type="checkbox"> 등)을 최대한 사용합니다.
  • Don't: 아이콘 버튼을 <span> 태그와 배경 이미지로만 만들고, 스크린 리더가 읽을 수 있는 aria-label이나 숨은 텍스트를 제공하지 않아 용도를 알 수 없게 만듭니다. 커스텀 컴포넌트에 role이나 상태를 나타내는 aria-* 속성을 누락합니다.
• 상태 메시지가 보조 기술로 전달되도록 설계되었는가? 4.1.3 Status Messages (AA)
  • Do: 항목을 장바구니에 추가했을 때, "상품이 장바구니에 추가되었습니다." 와 같은 메시지가 나타나는 영역을 <div aria-live="polite"> 또는 <div role="status"> 로 감싸서 스크린 리더가 해당 메시지를 사용자에게 자동으로 읽어주도록 합니다.
  • Don't: 검색 결과가 로드되거나, 설정이 저장되었다는 시각적 피드백만 제공하고, 스크린 리더 사용자에게는 아무런 정보 전달 없이 조용히 변경 사항이 적용됩니다.

5. 한국형 특화 요구사항

한국형 웹 콘텐츠 접근성 지침 2.2에서 강조된 한국 특화 요구사항들.

• 반복 입력 정보 최소화: 사용자가 반복적으로 입력해야 하는 정보를 줄였는가? (7.3.4)
  • Do: 회원가입 시 입력한 주소를 주문 시 '기본 배송지로 사용' 옵션으로 불러올 수 있게 하거나, 이전 결제 정보를 안전하게 저장하여 다음 결제 시 재사용할 수 있도록(사용자 동의 하에) 기능을 제공합니다.
  • Don't: 상품 주문 시 매번 이름, 연락처, 주소를 처음부터 새로 입력하도록 요구합니다. 여러 단계로 이루어진 신청서에서 이전 단계에 입력했던 동일한 정보를 다음 단계에서 또 물어봅니다.
• 점근 가능한 인증: 인증 과정에서 보조 기술 사용자가 접근 가능하도록 설계했는가? (7.3.3)
  • Do: 이미지 CAPTCHA 대신 음성 CAPTCHA 옵션을 제공하거나, reCAPTCHA v3와 같이 사용자 인터랙션이 적은 방식을 사용합니다. 공동인증서(구 공인인증서), 금융인증서 등 국내 인증 수단을 사용할 때 필요한 프로그램 설치 및 실행 과정이 키보드로 접근 가능하고 스크린 리더로 안내되도록 합니다. (가능한 경우 대체 인증 수단 제공)
  • Don't: 시각적 이미지 CAPTCHA만 제공하고 대체 수단이 없습니다. 특정 보안 프로그램(ActiveX 또는 실행 파일 형태) 설치가 필수이며, 해당 프로그램이 키보드 조작이나 스크린 리더를 지원하지 않습니다. 시간 제한이 있는 OTP 입력 화면에서 시간 연장 기능을 제공하지 않습니다.
• 국내 법적 준수: 「장애인 차별금지법」 및 「국가정보화기본법」에 따른 의무 사항을 반영했는가?
• 모바일 환경 고려: PC뿐만 아니라 모바일 기기에서의 접근성을 검토했는가? (1 적용 범위)
  • Do: 모바일 화면에서 버튼이나 링크 등 터치 대상의 크기를 최소 44x44 CSS 픽셀 이상으로 충분히 확보하고, 요소 간 간격도 적절히 배치하여 잘못 터치할 가능성을 줄입니다. 핀치 줌(Pinch zoom) 기능을 막지 않아 사용자가 화면을 확대할 수 있도록 합니다. 화면 방향(가로/세로) 전환 시 콘텐츠가 잘리지 않고 자연스럽게 재배치되도록 반응형으로 디자인합니다.
  • Don't: 모바일 화면에서 버튼들이 너무 작고 촘촘하게 붙어 있어 누르기 어렵습니다. <meta name="viewport" content="..., user-scalable=no">를 사용하여 사용자의 확대/축소 기능을 비활성화합니다. 가로 모드에서는 콘텐츠의 일부가 잘려나가 스크롤 없이는 볼 수 없습니다.

사용 방법

• 각 컴포넌트(버튼, 입력 필드, 내비게이션 등)를 설계할 때 이 체크리스트를 참고
• 체크리스트 항목을 하나씩 검토하며 "예/아니오"로 확인하고, 미준수 항목은 개선 계획 수립
• 개발 및 QA 단계에서 스크린 리더(NVDA, VoiceOver 등)와 키보드 테스트 병행

참고 자료

• 한국형 웹 콘텐츠 접근성 지침 2.2
• KRDS(범정부UI/UX 디자인 시스템)
• WCAG 2.1
• WCAG 2.2