웹 접근성 진단
1. 개요
웹 접근성 진단은 웹 콘텐츠, 웹 애플리케이션, 웹 서비스 등이 신체적 제한 없이 모든 사용자가利用할 수 있도록 적절히 설계·제공되고 있는지를 평가하는 활동이다. 웹 접근성은 시각,听觉, 운동, 인지 등의 장애가 있는 사람들도 웹 콘텐츠를 인식하고, 탐색하며, 이해할 수 있게 하는 것을 목표한다. 장애가 없는 사용자에게는 웹 접근성이产品质量 향상과 동일하지만, 장애가 있는 사용자에게는 웹 접근성 없이는서비스 자체를利用할 수 없게 된다.
웹 접근성 internationally는 W3C(World Wide Web Consortium)에서制定了 WCAG(Web Content Accessibility Guidelines)라는 표준 가이드라인이 있다. 한국에서는「국가정보화기본법」과「장애인차별금지 및 권리救济 등에 관한 법률」에서 웹 접근성의 의무를 규정하고 있다. 공공부문 웹사이트는「웹 접근성 품질인증」을 획득해야 하며, 민간 부문도 권고 사항으로 웹 접근성을 확보하도록 하고 있다. 감리자는 웹 접근성 관련 법령과 표준의 준수 여부를 감리 과정에서 확인해야 한다.
웹 접근성 진단의 핵심 영역은 인식 가능성(Perceivable), 운용 가능성(Operable), 이해 가능성(Understandable), 견고성(Robust)의 4대 원칙으로 구분된다. 이 원칙들은 WCAG 2.1 가이드라인의 기반이 되며, 각 원칙 아래 성공 기준(Success Criteria)이 정의되어 있다.
2. ASCII 다이어그램
WCAG 4대 원칙
[웹 접근성 WCAG 4대 원칙]
┌─────────────────────────────────────────────────────────────────────┐
│ WCAG 4대 접근성 원칙 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 1. 인식 가능성 (Perceivable) │ │
│ │ ○ 대체 텍스트 제공 ○ 멀티미디어 자막 제공 │ │
│ │ ○ 명료한 구분 ○ 명암 대비 충분 │ │
│ ├─────────────────────────────────────────────────────────────┤ │
│ │ 2. 운용 가능성 (Operable) │ │
│ │ ○ 키보드 접근 가능 ○ 충분한 시간 제공 │ │
│ │ ○ 발작 예방 ○ 탐색 가능 │ │
│ ├─────────────────────────────────────────────────────────────┤ │
│ │ 3. 이해 가능성 (Understandable) │ │
│ │ ○ 읽기 수준 적절 ○ 예측 가능 작동 │ │
│ │ ○ 입력 도움 ○ 명확한 안내 │ │
│ ├─────────────────────────────────────────────────────────────┤ │
│ │ 4. 견고성 (Robust) │ │
│ │ ○ 호환성 준수 ○ 유효한 마크업 │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
│ [P.O.U.R 원칙] │
│ P: Perceivable - 인식 가능 │
│ O: Operable - 운용 가능 │
│ U: Understandable - 이해 가능 │
│ R: Robust - 견고 │
│ │
└─────────────────────────────────────────────────────────────────────┘
웹 접근성 진단 절차
[웹 접근성 진단 절차]
┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌�─────────────┐
│ 사전 준비 │───▶│ 자동 검사 │───▶│ 수동 검사 │───▶│ 결과 분석 │
│(Pre-survey) │ │(Auto. Test) │ │(Manual Test)│ │(Analysis) │
└─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘
│ │ │ │
▼ ▼ ▼ ▼
장애 환경 분석 도구 기반 화면 낭독기 기준 충족
준수 기준 확인 스캔 수동 테스트 여부 판정
3. 해석
3.1 인식 가능성 원칙 평가
인식 가능성은 웹 콘텐츠가 다양한 감각으로 인식될 수 있어야 한다는 원칙이다. 시각 장애가 있는 사용자는 화면 낭독기(Screen Reader)를 사용하여 웹 콘텐츠를 청각적으로 인식하므로, 모든 콘텐츠에는 적절한 대체 텍스트가 제공되어야 한다.
대체 텍스트 제공: 이미지, 영상, 오디오 등 비텍스트 콘텐츠에는 대체 텍스트(Alt Text)가 제공되어야 한다. 대체 텍스트는 이미지의 목적과 내용을 명확히 전달해야 하며, 장식용 이미지의 경우에는 空(null) 대체 텍스트를 제공해야 한다. 예를 들어, "제품 사진"보다는 "2024년형 스마트폰 A모델, 6.5인치 디스플레이"가 더 적절한 대체 텍스트이다.
멀티미디어 자막 제공: 동영상에 대해서는 자막(Caption)을 제공해야 하며, 청각 장애가 있는 사용자가 내용을 이해할 수 있게 해야 한다. 단순히 대본을 제공하는 것보다는 영상 내 음성 정보가すべて자막으로 전환되어야 한다.
명암 대비: 텍스트와 배경 간의 명암 대비가 충분해야WCAG 2.1에서는 보통 크기 텍스트는 4.5:1 이상, 큰 텍스트는 3:1 이상의 대비 비율을 요구한다. 불충분한 대비는 시각 장애가 있는 사용자뿐 아니라 밝은 햇살 아래에서 모바일 기기를 사용하는 일반 사용자도 콘텐츠를辨认하기 어렵게 만든다.
3.2 운용 가능성 원칙 평가
운용 가능성은 웹 기능이 다양한 입력 방법을 통해運皆할 수 있어야 한다는 원칙이다. 손 기능 장애가 있는 사용자는 마우스 대신 키보드만 사용하여 웹을 탐색하므로, 모든 기능이 키보드로 접근 가능해야 한다.
키보드 접근성: 모든 기능과 네비게이션이 키보드로 접근可能해야 한다. 마우스에만 의존하는 기능(드래그 앤 드롭, 롤오버 효과 등)은 키보드로도操作 가능해야 한다. 포커스 순서가 논리적이어야 하며, 현재 포커스 위치가 시각적으로 명확히 표시되어야 한다.
충분한 시간 제공: 시간 제한이 있는 콘텐츠의 경우, 사용자가 시간을延하거나 비활성화할 수 있어야 한다. 예를 들어, 10초 만에 세션이 만료되는 것은 운동 장애가 있는 사용자에게 어려울 수 있다.
발작 예방: 광과민성 발작을 유발할 수 있는 플래시나 번쩍이는 콘텐츠는 제공하지 않아야 한다. flashes per second(FPS)가 일정 수준을 超える 콘텐츠는 금지된다.
3.3 이해 가능성 원칙 평가
이해 가능성은 웹 콘텐츠와 네비게이션이 사용자에게 쉽게 이해될 수 있어야 한다는 원칙이다. 인지 장애가 있는 사용자나foreign 언어 사용자를 위해 명확하고 예측 가능한 콘텐츠를 제공해야 한다.
읽기 수준 적절: 콘텐츠의 읽기 수준이 대상 이용자에게 적합해야 한다. 법률 문서나 전문 용어가 아닌 한, 일반적인 웹 콘텐츠는 초등학교 수준 정도의 읽기 난이도가 권장된다.
입력 도움: 사용자 입력 시 오류 메시지가 명확하게 표시되고,修正 방법이 안내되어야 한다. 예를 들어, "입력 오류"보다는 "비밀번호는 8자 이상이며, 특수문자를 포함해야 합니다"가 더 유용하다.
탐색 가능성: 웹사이트의 전체 구조와 현재 위치를 명확히 파악할 수 있어야 한다. 사이트맵, 탐색 메뉴, 현재 위치 표시 등의 장치가 제공되어야 한다.
3.4 견고성 원칙 평가
견고성은 다양한 사용자 에이전트(브라우저, 보조 기술 등)에서 콘텐츠가 제대로 해석되고運皆될 수 있어야 한다는 원칙이다.
호환성 준수: 보조 기술(화면 낭독기, 키보드 등)과의 호환성이 보장되어야 한다. 표준 웹 기술(HTML, CSS, JavaScript)을 사용하여 개발되고, 보조 기술에서도 문제없이 접근 가능해야 한다.
유효한 마크업: HTML 마크업이 웹 표준에 맞게 작성되어야 한다. 의미론적(Semantic) 마크업을使用하고, 헤딩(Heading) 구조가 논리적으로 작성되어야 한다. 예를 들어, <h1> → <h2> → <h3> 순서로 skipping 없이 струк화되어야 한다.
3.5 웹 접근성 진단 방법
감리자는 자동화된 도구와 수동 테스트를 병행하여 웹 접근성을 진단해야 한다.
자동화된 도구: WAVE, aXe, Lighthouse 등의 자동화 도구를 활용하여 기본적인 접근성 문제를スクリーニング할 수 있다. 자동화 도구는 모든 접근성 문제를 다检出하지는 못하지만, 초기 screening으로 효율성을 높일 수 있다.
수동 테스트: 자동화 도구로 발견되지 않는 문제를 수동으로 테스트해야 한다. 키보드만으로 모든 기능에 접근해보는 키보드 탐색 테스트, 화면 낭독기를 利用한 테스트, 실제 장애가 있는 사용자를 대상으로 한 테스트 등이 포함된다.
모바일 접근성: 모바일 기기에서의 접근성도 함께 검토해야 한다. 터치 타겟 크기, 핀치 줌 허용 여부, 터치 제스처 대안 제공 등이 포함된다.
4. 핵심 용어 정리
| 용어 | 영문명 | 설명 |
|---|---|---|
| WCAG | Web Content Accessibility Guidelines | 웹 콘텐츠 접근성 지침 |
| 대체 텍스트 | Alt Text | 이미지에 대한 텍스트 설명 |
| 화면 낭독기 | Screen Reader | 화면의 텍스트를 음성으로 변환하는 보조 기술 |
| 명암 대비 | Color Contrast | 전경색과 배경색 간의 밝기 차이 |
| 포커스 | Focus | 키보드 또는 다른 입력 장치로 선택된 요소 |
| 语义적 마크업 | Semantic Markup | 요소의 의미를 명확히 하는 HTML 마크업 방식 |
5. analogies 📢
웹 접근성 진단은 공공건물 wheelchair 접근성 점검과 같다. wheelchair使用자가 civic building을 방문할 때 입구의 경사로, elevator의 버튼 위치, 문 폭, 장애물 배치 등이 wheelchair 통행에 적합해야 한다. 경사로가 너무 가파르거나, elevator 버튼이 너무 높으면 wheelchair 사용자는 건물 내 部室에 접근할 수 없다. 또한 경사로에 손잡이가 없거나, 바닥이 미끄러우면安全隐患이 된다. 웹 접근성도 마찬가지로 시각,听觉, 운동, 인지 장애가 있는 사용자가 웹 콘텐츠를 인지하고, 탐색하고, 이해할 수 있어야 한다. 이미지에 대체 텍스트가 없으면 시각 장애인이 이미지의 내용을 알 수 없고, 키보드 탐색이 불가능하면 운동 장애인이 마우스 대용으로 웹을利用할 수 없다. 건물의 wheelchair 접근성을 점검할 때 건축 기준을 참고하듯, 웹 접근성 진단에서도 WCAG 기준을 参考하여 문제점을 발견하고 개선을 권고한다.