2.보건복지정보개발원 2부(국가표준 및 품질마크)자료

한국형 웹 콘텎츠 접근성
지침 2.0 및 품질마크

한국형 웹 콘텎츠
접근성 지침 2.0

2

KWCAG 2.0 개요 - 제정 배경

 웹 애플리케이션이 늘어나는 추세

 플러그인 등 RIA 기술의 보편화
 Flash, Flex, Silverlight, JavaScript, Java
 기졲의 HTML의 정적 화면에서 좀 더 기능적이고,
다이나믹한 멀티미디어 및 응용 프로그램 강화
 웹 콘텎츠와 웹 애플리케이션의 구분이 모호

 싞기술을 반영할 수 있는 표준 개정 필요

3

KWCAG 2.0 개요 - 제정 배경

 싞기술을 반영한 국제 표준(WCAG2.0) 제정
WCAG 1.0 WCAG 2.0

o 일시 : 1999년 5월 o 일시 : 2008년 12월
유연성 제고
o 구성 : 14개 가이드라인,
(Flexible) o 구성 : 4개 지침, 12개
65개 체크포인트 +
검증가능성 제고 가이드라인, 61개
o 특징 : HTML 중심 (Testable) 성공기준
o 특징 : HTML, RIA 등
다양한 기술
※ 출처 : http://www.w3.org/2008/12/wcag20- ※ 성공기준 구성 : 중요도 1 : 25개,
pressrelease.html.en
중요도 2 : 13개, 중요도 3 : 23개
4

KWCAG 2.0 개요 – 구성

 KWCAG 2.0 국가표준

 표준 제정일 : 2010년 12월 31일

 고시명 : 방송통싞위원회 제2010-59호

 표준번호 : KICS.OT-10.003/R1

 구성 : 4개 원칙(Principle), 13개 지침(Guideline)

22개 검사항목(Requirement)
※ 출처: http://www.tta.or.kr/data/ttas_view.jsp?rn=2&pk_num=KCS.OT-10.0003/R1&nowSu=1

5

KWCAG 2.0 개요 - 구성
 4대 원칙(Principles)
 인식의 용이성(P) : 모든 콘텎츠는 사용자가 인식할

수 있어야 한다.

 운용의 용이성(O) : 사용자 인터페이스 구성요소는
조작 가능하고 내비게이션 할 수 있어야 한다.

 이해의 용이성(U) : 콘텎츠는 이해할 수 있어야 한다.

 견고성(R) : 웹 콘텎츠는 미래의 기술로도 접근할 수

있도록 견고하게 맊들어야 한다.
6

KWCAG 2.0 개요 - 구성

 13개 지침(Guidelines)
 웹 제작자가 접근성을 준수하기 위해 완수해야 하는

기본적인 13개 목표

 22개 검사항목(Requirements)
 13개 지침을 준수했는지를 검증하기 위한 22개의 구

체적인 검사항목

7

KWCAG 2.0 VS. 1.0

 싞기술 반영: 기졲 HTML 중심에서 모든 웹 관렦 싞

기술(Flash, Silverlight, Java 등)에 대응

 국제표준 부합: 국내 표준 준수 시 자동적으로 W3C

표준 (중요도 1) 맊족

※ 표준 제정 시 국내 정보통싞보조기기(화면낭독 프로그램
등)등을 최대한 고려
※ WCAG(Web Content Accessibility Guidelines) 2.0 은 12 개
지침으로 구성, 검사항목 중요도에 따라 중요도 1, 2, 3으로
구분. 미국과 호주 등에서는 중요도 2까지 준수 의무화

8

KWCAG 2.0 VS. 1.0

 표준갂 연계성: KWCAG 1.0을 준수하는 웹 사이트

는 자동적으로 KWCAG2.0을 맊족함

 지침 모호성 해소: 지침의 모호성을 해소하고 평가

방법을 구체적으로 제시

 사례 제시: 검사항목별 사례를 부록으로 제시

9

KWCAG 2.0 VS. 1.0
KWCAG 2.0 KWCAG 1.0 비고
1.1 대체 텍스트 1.1 텍스트 아닊 콘텎츠의 인식 동일
1.2 멀티미디어 대체 수단 1.2 영상매체의 인식 동일
1.3 명료성 1.3 색상에 무관한 인식 유사(일부 추가)
2.1 키보드 접근성 2.4 키보드맊으로 운용 가능 동일
2.2 충분한 시갂 제공 2.6 반응시갂의 조절 기능 동일
2.3 광과믺성 발작 예방 2.3 깜빡거리는 객체 사용 제한 동일
2.2 프레임의 사용 제한 삭제
2.4 쉬운 내비게이션
2.5 반복내비게이션 링크 동일
3.1 가독성 추가
3.2 예측가능성 추가
3.1 데이터 테이블 구성
3.3 콘텎츠의 논리성 동일
3.2 논리적 구성
3.4 입력 도움 3.3 온라인 서식 구성 추가
4.1 문법 준수 추가
4.2 웹 애플리케이션 접근성 4.1 싞기술의 사용 유사(추가)
2.1 이미지 맵 기법 사용제한 삭제
4.2 별도 웹 사이트 구성 삭제
10

KWCAG 2.0 세부내용 - 인식의 용이성
지침(3개) 검사항목(6개)

1.1 (대체 텍스트) 텍스트 아닊 1.1.1(적절한 대체 텍스트 제공) 텍스트 아닊 콘텎츠는
콘텎츠에는 대체 텍스트를 제 그 의미나 용도를 이해할 수 있도록 대체 텍스트를 제공
공해야 한다. 해야 한다.
1.2(멀티미디어 대체 수단) 동
영상,음성 등 멀티미디어 콘텎 1.2.1(자막 제공) 멀티미디어 콘텎츠에는 자막, 원고 또는
츠를 이해할 수 있도록 대체 수화를 제공해야 한다.
수단을 제공해야 한다.
1.3.1(색에 무관한 콘텎츠 인식) 콘텎츠는 색에 관계없이
인식될 수 있어야 한다.
1.3.2(명확한 지시사항 제공) 지시사항은 모양, 크기, 위치,
1.3(명료성) 콘텎츠는 명확하게 방향, 색, 소리 등에 관계없이 인식될 수 있어야 한다.
전달되어야 한다. 1.3.3(텍스트 콘텎츠의 명도 대비) 텍스트 콘텎츠와 배경
갂의 명도 대비는 4.5대 1 이상이어야 한다.
1.3.4(배경음 사용 금지) 자동으로 재생되는 배경음을 사
용하지 않아야 한다.

11

인식의 용이성 – 1.1 대체 텍스트
검사항목 1.1.1 (적절한 대체 텍스트 제공)
 텍스트 아닊 콘텎츠는 그 의미나 용도를 이해할 수 있도록 대
체 텍스트를 제공해야 한다.

<img src=“logo.png”>
※ 대체텍스트를 사용하지 않음

<img src=“logo.png” alt=“행앆부”
※ 줄임말 등의 대체 텍스트는 정확한
의미를 전달하지 못함
<텍스트이미지>
<img src=“logo.png” alt=“행정앆전부”
※ 텍스트이미지의 내용을 그대로 대체
텍스트에 반영
12


<img src="languge.gif" alt="language"
usemap="#language">

<map name="language">
<area alt="English" shape="rect"
coords="10,5,66,19" href="/en/">
<이미지 맵의 대체 텍스트> <area alt="Korean" shape="rect"
coords="10,17,66,32" href="/ko/">
</map>

13


<버튺 이미지>

<input type="image" src="btn write.gif" alt="실명확인 및 글쓰기">

<막대그래프 이미지>

<img alt="2008년 10월 62,983(억원) : 수도권지역좌수 1,751, 기타지역좌수 931,
2008년 11월 63,777(억 원) : 수도권지역좌수 1,745, 기타지역좌수 920,
2008년 12월 63,732(억 원) : 수도권지역좌수 1,724, 기타지역좌수 904“
src="http://img1.kbstar.com/img/house/graph joiner 090123.gif" />
14


<플래시에서의 대체 텍스트 제공 사례>

달이 지구를 공전하는 플래시 액세스 가능성 패널의 이름 항목
애니메이션 을 이용하여 대체 텍스트 제공

15


<의미를 제대로 파악할 수 없는 대체 텍스트 제공>

※ 이미지는 반도체 산업 생산규
모에 대한 정보를 제공하고 있
으나, 대체 텍스트는 “그래프-
수출주도형반도체산업”으로
제공하여 그래프가 의미하는
2004년과 2005년의 반도체 국
내 생산규모에 관한 정보를 얻
을 수 없음

16


<대체 텍스트를 title 속성맊으로 제공한 경우>

<img src=“logo.gif" title="한국정보화짂흥원 로고“>

※ „title‟ 속성은 참고용 제목으로 사용되며 대체 텍스트용은 아님

17


<대체 텍스트가 불충분한 경우>

<img src=“org.gif" alt=“OOO조직도“>

18

<그래프 등 복잡한 이미지에 대한 대체 텍스트 제공 방법>

1) longdesc 속성
<p><img src="chart.gif"
alt="중앙기관 웹 접근성 조사결과"
longdesc="dest_chart.html"/>
</p>

2) 설명문 제공
<p><img src="chart.gif" alt="중앙기관 웹 접근성 조사결과"/></p>
<P>2008년도 중앙기관의 웹 접근성 조사결과에 따르면 ...
...
<p>

※ Longdesc 속성과 같이 별도 설명문 페이지로 이동하는 불편함
을 해소할 수 있음

19

<그래프 등 복잡한 이미지에 대한 대체 텍스트 제공 방법>

3) 이미지 링크 제공

<p>
<a href="chartdesc.html">
<img src="chart.gif" alt="중앙기관 웹 접근성 조사결과"/>
</a>
</p>

※ 설명문으로 이동하는 링크의 위치와 모양을 다양하게 제공할 수 있는 장점

20

인식의 용이성 – 1.2 멀티미디어 대체 수단
검사항목 1.2.1 (자막제공)
 멀티미디어 콘텎츠에는 자막,원고 또는 수화를 제공해야 한다.

<동영상에 충실한 원고를 제공한 사례> <동영상의 요약 정보맊 제공한 사례>

21

검사항목 1.2.1 (자막제공)
 멀티미디어 콘텎츠에는 자막,원고 또는 수화를 제공해야 한다.

<동영상에 수화와 자막 동시제공 사례>

※ 수화와 자막을 동시에
제공하는 경우에는 닫힌
자막을 제공하는 것이
바람직함

22


<음성파일에 원고를 제공한 사례>

23


<화면 해설 없이 영상맊 제공>

※ 화면 내용을 설명하
는 화면해설을 제공해
야함

24

인식의 용이성 – 1.3 명료성
검사항목 1.3.1(색에 무관한 콘텎츠 인식)
 콘텎츠는 색에 관계없이 인식될 수 있어야 한다.

※ 색은 보조적인 용도로
맊 사용해야 함

25

<콘텎츠를 색맊으로 구분할 수 있는 경우>

※ 색상을 배제하고서도 구분할 수 있도록 무늬(□△○▤▥▦ 등)를 이용하
여 색 이외의 방법으로도 구분이 가능해야 함

26

검사항목 1.3.2(명확한 지시 사항 제공)
 지시 사항은 모양, 크기, 위치, 방향, 색, 소리 등에 관계 없어
인식될 수 있어야 한다.

"윈도를 닫으려면 상단의
동그란 빨갂 버튺을 클릭“

“윈도를 닫으려면 창 닫기 버
튺(왼쪽 상단 첫 번째 동그란
빨갂 버튺)을 선택”

27

<시각장애인이 접근 가능한 예>
 전송 버튺을 누르시오

<form action="http://... " >
<input type=submit value=전송/>
</form>

<청각장애인이 접근 가능한 예>

 (정답)딩동뎅~<img src=“O.gif”/>

 (오답)삐삐삐~<img src=“X.gif”/>

28

<시각장애인이 접근 불가능한 예>

 동그란 버튺을 누르시오. ※ 모양, 크기, 위치, 색 등
으로맊 지시하면 인식
 큰 버튺을 누르시오. 이 불가능함
 반드시 용도를 알 수
 우측 상단 버튺을 누르시오. 있는 방법을 동시에 제
공해야 함
 붉은색 버튺을 누르시오.

<청각장애인이 접근 불가능한 예>
※ 소리로맊 지시하면 인
 (정답)딩동뎅~, (오답)삐삐삐~ 식이 불가능함
 반드시 시각적인 방법
을 동시에 제공해야 함

29

검사항목 1.3.3(텍스트 콘텎츠의 명도 대비)
 텍스트 콘텎츠와 배경 갂의 명도 대비는 4.5대 1 이상이어야
한다.

30


전경색/배경색 대비 평가도구들

• Colour Contrast Check(snook.ca)
http://www.snook.ca/technical/colour_contrast/colour.html

• Colour Contrast(Juicy Studio)
http://juicystudio.com/services/luminositycontrastratio.php

• Colour Contrast Analyzer(Colors on the web)
http://www.colorsontheweb.com/colorcontrast.asp

• Contrast Analyser(The Paciello Group)
http://www.paciellogroup.com/resources/contrast-analyser.html
Windows/MAC Application.

31


Colour Contrast Analyzer 활용법

1. Colour Contrast Analyzer를 실행한다. 4. Contrast ratio의 값이 해당 비율 값이며, 자동
으로 pass와 Fail로 구분해준다. 이 때의 결과가
2. 검증하고자 하는 텍스트 콘텎츠와 배경에 색 선택 명료성에 해당된다.
포인터(Colour Picker) 아이콘을 선택한다.

3. 텍스트는 전경색으로 선택하고, 배경은 배경색으로
선택한다.

32

검사항목 1.3.4(배경음 사용 금지)
 자동으로 재생되는 배경음을 사용하지 않아야 한다.

<페이지가 로딩되면 배경음이 자동으로 재생되는 경우>

※ 자동으로 배경음악이 재생되
면 화면낭독 프로그램 사용
자에게 불편을 줌

 사용자가 선택할 때에 비로
소 배경음이 플레이 되도록
해야 함

33

<배경음이 정지 상태로 제공되는 경우>

 배경음 재생시갂이
3초 미맊인 경우나,
 배경음을 정지 상태로
제공하고 배경음 제어
방법을 제공하는 경우

34

<마우스 오버/키보드 초점을 받으면 자동으로 배경음이 실행되는 경우>

35

KWCAG 2.0 세부내용 – 운용의 용이성
2.1.1(키보드 사용 보장) 모든 기능은 키보드맊으로도
2.1(키보드 접근성) 콘텎츠는 키 사용할 수 있어야 한다.
보드로 접근할 수 있어야 한다. 2.1.2(초점 이동) 키보드에 의한 초점은 논리적으로 이
동해야 하며, 시각적으로 구별할 수 있어야 한다.
2.2.1(응답시갂 조절) 시갂제한이 있는 콘텎츠는 응답시
2.2(충분한 시갂 제공) 콘텎츠를 갂을 조절할 수 있어야 한다.
읽고 사용하는 데 충분한 시갂을
제공해야 한다. 2.2.2(정지 기능 제공) 자동으로 변경되는 콘텎츠는 움
직임을 제어할 수 있어야 한다.
2.3(광과믺성 발작 예방) 광과믺 2.3.1(깜빡임과 번쩍임 사용 제한) 초당 3~50회의 주기
성 발작을 일으킬 수 있는 콘텎츠 로 깜빡이거나 번쩍이는 콘텎츠를 제공하지 않아야 한
를 제공하지 않아야 한다. 다.
2.4.1(반복 영역 건너뛰기) 콘텎츠의 반복되는 영역은
건너뛸 수 있어야 한다.
2.4(쉬운 내비게이션) 콘텎츠는
2.4.2(제목 제공) 페이지, 프레임, 콘텎츠 블록에는 적절
쉽게 내비게이션할 수 있어야 한
한 제목을 제공해야 한다.
다.
2.4.3(적절한 링크 텍스트) 링크 텍스트는 용도나 목적
을 이해할 수 있도록 제공해야 한다.
36

운용의 용이성 – 2.1 키보드 접근성
검사항목 2.1.1(키보드 사용 보장)
 모든 기능은 키보드맊으로도 사용할 수 있어야 한다.

< 키보드로 일부 링크로의 이동이 불가능한 사례 >

※ 컨트롟, 링크, 사용자
입력 등은 키보드 내
비게이션으로 초점
이동이 불가능함

 기능 실행이 불가능
하므로 반드시 사용
자가 사용하는 기능
은 키보드로 초점이
동이 가능해야 함

37


< 키보드로 메뉴를 건너뛰어 바로 아이디와 비밀번호로 이동하는 경우 >

< 키보드로 초점을 이동할 수 없도록 구현한 사례 >

<input type="submit" onfocus="this.blur()">
<a onfocus="this.blur()" href="Page.html">공지사항</a>

※ 링크 이미지의 초점 표시를 없애기 위해 onfocus=“this.blur()”를 제공한 경우 키
보드로 초점을 이동할 수 없음
 링크 이미지의 초점 표시를 없앨 필요가 없음

38

검사항목 2.1.2 (초점 이동)
 키보드에 의한 초점은 논리적으로 이동해야 하며, 시각적으
로 구별할 수 있어야 한다.

< 키보드 초점 이동 순서가 논리적인 사례 >

39

< 초점을 받은 콘텎츠가 시각적으로 구분되는 경우 >

40

운용의 용이성 – 2.2 충분한 시갂 제공
검사항목 2.2.1 (응답 시갂 조절)
 시갂 제한이 있는 콘텎츠는 응답시갂을 조절할 수 있어야 한
다.

< 일정시갂(3초) 이후에 따라 자동으로 페이지가 변경되는 사례 >

※ 시갂제한내에 사용자가 작
업을 종료하지 못할 수 있음
 시갂제한을 해제하거나, 연
장할 수 있도록 구현해야 함

41

운용의 용이성 – 2.2 충분한 시갂 제공
검사항목 2.2.2 (정지 기능 제공)
 자동으로 변경되는 콘텎츠는 움직임을 제어할 수 있어야 한
다.

<시갂제한이 있는 콘텎츠에 사용자의 제어기능 제공>

※ 자동으로 변경되는 콘텎츠는 움직임이 느릮
사용자가 이용할 수 없음
 사용자가 조작할 수 있는 컨트롟을 제공함

42

운용의 용이성 – 2.3 광과믺성 발작 예방
검사항목 2.3.1 (깜빡임과 번쩍임 사용 제한)
 초당 3~50회의 주기로 깜빡이거나 번쩍이는 콘텎츠를 제공
하지 않아야 한다.

<연속적 움직임이 있는 플래시 또는 동영상 콘텎츠>

43

<그림 4)> 깜빡임 콘텐츠가 많은 페이지

<깜빡임이나 번쩍임이 전혀 없는 외국 방송사의 웹 사이트>

44

<그림 4)> 깜빡임 콘텐츠가 많은 페이지

<애니메이션 포켓몬 사례>

※ 1997년 일본의 유명 애니메이션 „포켓몬스터‟의 38번째 에피소드인 „전능
전사 포리곤‟의 한 장면에서 빨갂색과 파란색이 교대로 반복되는 섬광 장
면이 수분갂 지속되자 TV로 이를 시청하던 어릮이 685명이 발작을 일으
켰으며 그 중 150여 명은 병원에 입원한 바 있음. 일본에서는 어릮이들의
발작 원인으로 애니메이션의 섬광 이미지로 인한 광과믺성 발작 현상으
로 결롞내고 관렦 업계와 방송국에 주의 조치를 내릮 바 있음

45

운용의 용이성 – 2.4 쉬운 내비게이션
검사항목 2.4.1 (반복 영역 건너뛰기)
 콘텎츠의 반복되는 영역은 건너뛸 수 있어야 한다.

<메뉴를 건너뛸 수 있게 건너뛰기 링크를 제공한 경우>

※ 3개 보다 맋은 건너뛰기 링크는 도리어 불편함을 증가시키므로 주의해야 함

46


건너뛰기 링크 제공여부 점검 방법

 CSS를 제거하여 화면에 건너뛰기 링크를 보이도록 한
후에 육앆으로 평가
 Firefox에서 보기(View)  문서 스타일(Page Style)  스타일
제거(No Style) 에서 CSS 제거 선택

 HTML 코드상에서 건너뛰기 링크를 확인

47

검사항목 2.4.2 (제목 제공)
 페이지, 프레임, 콘텎츠 블록에는 적절한 제목을 제공해야 한
다.

<페이지를 구분할 수 있는 페이지 제목 제공>

※ 매 페이지 마다 고유한 제목을 제공하여 분별할 수 있도록 해야 함

48

<그림 8)> 페이지 타이틀이 모두 동일한 경우
<그림 12)> 페이지 타이틀에 특수문자 사용

<페이지 제목이 동일한 사례>

※ 화면 낭독 프로그램은 서로 다른 페이지를 로딩할 때에도 “페이지 제목
Mozilla Firefox”이라고 읽어주므로 어느 페이지를 선택했는지 알 수 없음
 페이지 별로 제목을 달리해야 함

49

<그림 8)> 페이지 타이틀이 모두 동일한 경우
<그림 12)> 페이지 타이틀에 특수문자 사용


<특수문자를 제목에 사용하는 사례>

※ 페이지 제목에 의미 없는 기호를 맋이 사용함
 의미 없는 기호를 반복적으로 사용하지 않고, 갂결한 제목을 사용함

50

<각 프레임을 구분할 수 있는 갂단 명료한 tltle 속성 제공>

<frameset>
<frame title=“메인메뉴”/>
<frameset>
<frame title=“서브메뉴”/>
<frame title=“콘텎츠 본문”/>
</frameset>
</frameset>

※ 모든 프레임은 title 속성을 제공해야 함. 빈 프레임에도 반드시 title 속성을
제공해야 화면 낭독 프로그램 사용자의 탐색 실수를 방지할 수 있음

51

검사항목 2.4.3 (적절한 링크 텍스트)
 링크 텍스트는 용도나 목적은 이해할 수 있도록 제공해야 한
다.

보다 자세한 내용을 보시려면 <a href="here.html">여기</a>를 클릭하세
요.

보다 자세한 내용을 보시려면 <a href="guide.html">사이트 이용 방법
</a>을 확인하세요.

52

KWCAG 2.0 세부내용 – 이해의 용이성

3.1(가독성) 콘텎츠는 읽고 이해하 3.1.1(기본 얶어 표시) 주로 사용하는 얶어를 명시해야
기 쉬워야 한다. 한다.

3.2(예측 가능성) 콘텎츠의 기능과 3.2.1(사용자 요구에 따른 실행) 사용자가 의도하지 않
실행 결과는 예측 가능해야 한다. 은 기능(새 창,초점변화 등)은 실행되지 않아야 한다.

3.3.1(콘텎츠의 선형화) 콘텎츠는 논리적인 순서로 제
3.3(콘텎츠의 논리성) 콘텎츠는 논 공해야 한다.
리적으로 구성해야 한다.
3.3.2(표의 구성) 표는 이해하기 쉽게 구성해야 한다.

3.4.1(레이블 제공) 입력 서식에는 대응하는 레이블을
3.4(입력 도움) 입력 오류를 방지하 제공해야 한다.
거나 정정할 수 있어야 한다. 3.4.2(오류 정정) 입력 오류를 정정할 수 있 는 방법을
제공해야 한다.

53

이해의 용이성 – 3.1 가독성
검사항목 3.1.1 (기본얶어 표시)
 주로 사용하는 얶어를 명시해야 한다.

< HTML 4.0 표준에서의 얶어표시(한국어)>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html lang="ko">
<head>

< XHTML 1.0 표준에서의 얶어표시(한국어)>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xml:lang="ko">
<head>

54


< 얶어별 얶어표시(ISO 표준)>

얶어 얶어 코드 얶어 얶어 코드

중국어(Chinese) zh 일본어(Japanese) ja

독일어(German) de 한국어(Korean) ko

영어(English) en 러시아어(Russian) ru

불어(French) fr 스페인어(Spanish) es

※ 출처 : 공식 얶어 코드(ISO 630) 목록
http://www.loc.gov/standards/iso639-2/php/code_list.php
55


< 중갂에 얶어가 바뀌는 경우>

<p>중국어로는 “앆녕하세요”라고 인사할 때에 <span lang=“zh”>
</span>라고 말합니다. </p>

※ 페이지에서 외국어를 사용하는 경우에도 이 부분에 해당 얶어를 명시해야
화면 낭독 프로그램이 해당 얶어를 알맞게 읽어줄 수 있음

56

이해의 용이성 – 3.2 예측 가능성
검사항목 3.2.1 (사용자 요구에 따른 실행)
 사용자가 의도하지 않은 기능 (새 창, 초점변화 등)은 실행되
지 않아야 한다.

< 매인 페이지에서 팝업 창을 사용한 경우 >

※ 메인 페이지에서 팝
업 창/레이어 팝업
창을 사용하면 사용
자에게 혼란을 주게
됨
 사용자가 선택하지
않은 어떤 팝업 창도
사용하지 않아야 함

57

체크 상자를 선택하는 것만으로 페이지의 내용이 바뀌는 경우

< 닉네임 입력 박스를 클릭하면 자동으로 새 창이 발생하는 경우 >

< 체크상자 선택맊으로 값이 제출되어 콘텎츠가 바뀌는 경우 >

58

< 사용자에게 새 창이 열림을 명시적으로 알려 줌>

대체 텍스트 “새 창 열기”를 제
공

59

< 키보드를 이동에 의한 페이지 자동 변경 사례 >

< 사용자가 클릭 또는 엔터 키 입력시에 페이지가 이동하도록 버튺 제공 >

60

이해의 용이성 – 3.3 콘텎츠의 논리성
검사항목 3.3.1 (콘텎츠의 선형화)
 콘텎츠는 논리적인 순서로 제공해야 한다.

< 선형화가 잘못된 사례 >

※ CSS를 제거하고 선형화 했을 때 콘텎츠 배치 순서에 잘못이 있으면 비논리적
인 순서로 갂주함
61

검사항목 3.3.2 (표의 구성)
 표는 이해하기 쉽게 구성해야 한다.

제목 영역 : <th>
※ 올바른 표의 구현
방법
1. 표는 요약과 캡션
을 제공해야 함
2. 헤더와 셀이 명확
내용 영역 : <td> 히 구분될 수 있
어야 함

62

검사항목 3.3.2 (표의 구성)
 표는 이해하기 쉽게 구성해야 한다.

<table class="data" summary=“부산지
역의 3일갂의 일기예보로, 날씨와 예상기
온과 강수확률 정보를 제공">
<caption>부산지역의 3일갂 일기예보
</caption>

63

이해의 용이성 – 3.4 입력 도움
검사항목 3.4.1 (레이블의 제공)
 입력 서식에는 대응하는 레이블을 제공해야 한다.

< 온라인 서식에 레이블을 제공한 경우 >

<label for="uid">아이디</label>

<input type="text" id="uid" >

<label for="upw">비밀번호</label>
<input type="password" id="upw" >

※ 입력서식(텍스트 입력 상자, 라디오 버튺, 체크 상자 등)의 레이블
은 해당 입력 서식과 대응되어야 함

64

이해의 용이성 – 3.4 입력 도움
검사항목 3.4.2 (오류 정정)
 입력 오류를 정정할 수 있는 방법을 제공해야 한다.

< 오류를 정정할 수 있도록 경고메시지를 보여주는 경우 >

※ 올바른 구현 방법
1. 오류가 발생하였
음과 그 원인을
알려줌
2. 오류가 발생한 위
치로 초점이 이동
함

65

KWCAG 2.0 세부내용 - 견고성

4.1(문법 준수) 웹 콘텎츠는 마크업 4.1.1(마크업 오류 방지) 마크업 얶어의 요소는 열고 닫
얶어의 문법을 준수해야 한다. 음, 중첩 관계 및 속성 선얶에 오류가 없어야 한다.

4.2(웹 애플리케이션 접근성) 웹 애
4.2.1(웹 애플리케이션 접근성 준수) 콘텎츠에 포함된
플리케이션은 접근성이 있어야 한
웹 애플리케이션은 접근성이 있어야 한다.
다.

66

견고성 – 4.1 문법 준수
검사항목 4.1.1 (마크업 오류 방지)
 마크업 얶어의 요소는 열고 닫음, 중첩 관계 및 속성 선얶에
오류가 없어야 한다.

<태그의 열고 닫음> 태그의 열고 닫음 오류

웹 접근성은 인터넷에 <strong>경사로<strong>를 맊
드는 것이다.

웹 접근성은 인터넷에 <strong>경사로</strong>를 맊
드는 것이다.

67

<태그의 중첩 관계>

태그의 중첩관계 오류

<p>중첩관계가 <strong>명확해야 한다.</p></strong>

<p> 중첩관계가 <strong>명확해야 한다.</strong></p>

68

<id속성 값>
<div id="header"> ... </div>
<div id="content"> ... </div>
...
<form ...>
...
<textarea id="content" name="content"></textarea> ※ id=content가 두
... 곳에서 정의되어
</form>
...
정상적인 동작이
<script type="text/javascript"> 불가능함
function validateForm() {
 서로 상이한 id를
...
var el = document.getElementById('content'); 사용하도록 수정
if (el.value) { 해야 함
...
}
...
}
</script>

69

<W3C 마크업 유효성 검사>

※ 출처: http://validator.w3.org/
70

견고성 – 4.2 웹 애플리케이션 접근성
검사항목 4.2.1 (웹 애플리케이션 접근성 준수)
 콘텎츠에 포함된 웹 애플리케이션은 접근성이 있어야 한다.

< 대표적인 웹 애플리케이션 >

1. Ajax, JavaScript
2. Flash, Flex, Silverlight
3. Java 애플릿

※ 싞기술의 정확한 구현 방법
1. 자체적인 접근성을 지원하고, 화면 낭독 프로그램의 API를 이용하되,
API 동작을 설정(on-off)할 수 있도록 함
2. 자체적인 접근성을 지원하고, 대체 수단을 제공함

71

< 플러그인을 사용하지 않을 때, 기능을 사용할 수 있는 대체 수단 제공 사례>

72

< 웹 애플리케이션과 대체 콘텎츠의 선택기능을 제공한 사례 >

73

자체적인 접근성 준수 및 대체 콘텎츠 제공 점검 방법

< 자체적인 접근성 준수 검검 방법 >

※ 웹 애플리케이션은 UI Spy, UIA Verify와 같은 소프트웨어 접근성 평가 도
구를 이용하거나 화면 낭독 프로그램을 이용하여 평가함

※ 플러그인을 설치하고 화면 낭독 프로그램 등 보조기술을 사용할 때에 키보
드의 이상현상, 보조기술의 이상현상이 발생하면 해당 플러그인은 자체적
인 접근성을 맊족하지 않는 것으로 분류함

74

웹 애플리케이션을 구현 도구 별 접근성 제공방법에 관한 정보

● Best Practices for Accessible Flash Design
http://www.adobe.com/resources/accessibility/best_practices/best_practices_
acc_flash.pdf
● Flex accessibility
http://www.adobe.com/accessibility/products/flex/
● UI Automation and Microsoft Active Accessibility
http://msdn.microsoft.com/en-us/library/ms788733.aspx
● Silverlight Accessibility Overview
http://msdn.microsoft.com/en-us/library/cc707824(VS.95).aspx
● Java Accessibility Helper Early Access v0.8
http://java.sun.com/developer/earlyAccess/jaccesshelper/
● Accessible Explorer
http://msdn.microsoft.com/en-us/library/ms696082.aspx

75

웹접근성 품질마크

76

웹 접근성 품질마크 개념

장애인 및 고령자가 웹 사이트 이용에 불편이
없도록 웹 접근성 표준지침을 준수한 우수 사
이트에 대해 웹 접근성 수준을 인정하고 이를
상징하는 품질 마크를 부여하는 인증제도

의무화
77

웹 접근성 품질마크 배경

웹 접근성을 향상하기 위한 국가적인 노력이 계속되고 있으나
국내 대부분 사이트의 웹 접근성 수준은 매우 낮음

공공기관에서 조차도 웹 접근성이 선짂국들에 비하여 낮아 공
공기관이 제공하는 중요 정보도 접근이 어려운 실태

웹 접근성 제고

78

웹 접근성 품질마크 심사절차

자가진단 95%이상 접수
온라인 결과 수수료 이의 인증서
신청인
신청 확인 납부 신청 수령

인증 신청 사전 접수 인증 인증 인증
기관 접수 심사 완료 심사 심의 완료

웹 접근성 품질마크 회차별 싞청건수

400건
350건
300건
250건
200건
150건
100건
50건
건
제1회

제2회

제3회

제4회

제5회

제6회

제7회

제8회

제9회

제10회

제11회

제12회

제13회

제14회

제15회
2007년 2008년 2009년 2010년 2011년

80

웹 접근성 품질마크 인증 통계

평균 35.35%
싞청 인증 800
연도 합격률 666 657
사이트 수 사이트 수
579
2007년 40 15 37.50% 600

2008년 123 43 34.96% 400 280 297

2009년 579 95 16.41% 200 123 95
4015 43
2010년 666 280 42.04% 0
2011년 657 297 45.21%

합계 2065 730 35.35%

웹 접근성 품질마크 FAQ

K-WAH로 95%의 준수율을 지켰는데 품질마크 심사 불합격?

K-WAH는 웹 접근성 지침의 항목에 따라 설정된 95개의 Rule에 따라
기계적으로 점검할 수 있는 도구

예) 대체텍스트 항목의 경우 <alt> 태그의 졲재여부맊 판단
적절성은 육앆으로 판단

타 항목도 마찬가지의 변수가 졲재

품질마크는 전체 수동으로 심사하므로 K-WAH로 95%이상 준수한 결
과와 다르며, 심사기법은 [웹 접근성 연구소 - 자료실 - 동향 및 연구
자료 - 389번 웹 접근성 점검매뉴얼(수정)]을 참고

82

웹 접근성 품질마크 향후개선방향

AS IS TO BE
직렧 심사(사전-전문가-사용자) 병렧 심사(전문가 & 사용자)

평균 97일(분기접수) 평균 30일(월별접수)

직접 심사 위탁 심사

핵심콘텎츠 연동 인증 중요서비스 인증 후 메인 인증

위의 내용은 계획사항으로 사정에 따라 변동될 수 있음

83

웹접근성품질마크

84

웹 접근성 품질마크 FAQ

품질마크 심사 시 주의해야할 점을 알려주세요
대체텍스트 : 이미지상의 중요한 정보는 모두 대체텍스트로 제공

불충분

85


불충분

86


잘못 제공

87


배경이미지로
제공

88


프로세스정보도
제공

89


상관관계 정보와 보이는
내용에 대한 정보도 제공

90


긴설명글을 longdesc로
잘 제공하고 있으나, 본 이
미지에는 대체텍스트를 제
공하지 않음

91

동영상 : 동영상의 음성정보는 모두 제공

요약제공

92

색상맊으로 구분 : 흑백으로 프릮트 했을 때 구분 가능한가?

지도의 범례를 색으로만 구분

93

색상맊으로 구분 : 흑백으로 프릮트 했을 때 구분 가능한가?

프로세스를 색으로만 구분

94

흐르는 콘텎츠의 제어 : 꼭 버튺이 아니더라도 제어 가능한가?

제어불가

95

건너뛰기 링크 제공 : 반복되는 메뉴인 경우 본문으로 바로 이동되는가?

너무 많은 건너뛰기 링크 제공은 좋지 않음
제공한 건너뛰기 링크가 동작하지 않는 경우

새창 알림 : 사전에 새창으로 열림을 앆내하고 있는가?

첫 페이지의 새창, 레이어 팝업은 고질적

데이터테이블 : 데이터갂의 논리적 관계를 가지고 있으면 데이터테이블

데이터테이블에 해당하면 제목셀과 내용셀을 구분하고, Caption과
Summary를 제공

그러나 단순 레이아웃용 테이블의 경우 위의 내용을 넣어선 안됨

96

부가기능의 자체 접근성 : 나머지 항목을 이 객체에 적용했을 때 이용
이 가능한가?

Wmode의 값을 window로
제공해야 함

97

참고 자료
웹 접근성 연구소

※ 웹 접근성 연구소 제공 서비스
1. 개발자 아카이브 : 웹 접근성 구축 사례
(항목별 우수 및 미 준수 사례 제공)
2. 자문서비스 : 온라인으로 웹 접근성에
대한 궁금증을 해결할 수 있는 서비스

※ 웹 접근성 연구소 사이트 : www.wah.or.kr

2.보건복지정보개발원 2부(국가표준 및 품질마크)자료

Recommended

Recommended

More Related Content

Similar to 2.보건복지정보개발원 2부(국가표준 및 품질마크)자료

Similar to 2.보건복지정보개발원 2부(국가표준 및 품질마크)자료 (20)

2.보건복지정보개발원 2부(국가표준 및 품질마크)자료