인식의 용이성 | | | 텍스트 아닌 콘텐츠(non-text contents)중에서 글로 표현될 수 있는 모든 콘텐츠는 해당 콘텐츠가 가지는 의미나 기능을 동일하게 갖추고 있는 텍스트로도 표시되어 있어야 한다. |
|
텍스트 아닌 콘텐츠(non-text contents)중에서 글로 표현될 수 있는 모든 콘텐츠는 해당 콘텐츠가 가지는 의미나 기능을 동일하게 갖추고 있는 텍스트로도 표시되어 있어야 한다.
WAI에서 여기에 해당하는 항목은 다음과 같습니다.
1.1 모든 비-텍스트 콘텐츠에 대해서는 대체 텍스트를 제공해야 한다.(예를 들어 "alt", "longdesc" 등 을 쓰거나 또는 요소 내의 콘텐츠에 직접 써야 한다.) 이것은 다음과 같은 요소들을 포함한다: 이미지, (기호를 포함하여) 그래픽으로 나타낸 텍스트, 이미지 맵의 어떤 영역, 애니메이션(예: 애니메이션 GIF), 애플릿, 프로그램 객체, 아스키 아트, 프레임, 스크립트, 리스트 불릿으로 쓰인 이미지, 공간을 확보하기 위해 쓰인 빈 이미지(spacers), 그래픽 버튼, (사용자와의 상호작용에 의해 또는 자동으로 플레이되는) 사운드, 독립적인 오디오 파일, 비디오의 오디오 트랙, 비디오. 이 지침에서 주의해야 할 점은 alt text를 사용할 때 대상의 의미와 목적을 충분히 설명할 수 있어야 한다는 것입니다. 즉 형식적인 삽입을 피해야 한다는 것입니다. 따라서 만약에 긴 설명이 필요하다면 long desc을 사용하고 이조차도 너무 길다고 생각한다면 이 설명이 담겨있는 다른 링크를 longdesc 속성에 포함시키는 것도 한 방법입니다. 대상 장애시각 장애 시력 장애 청각, 청력 장애사용예■ 이미지 링크를 사용하는 경우 <a href="http://www.coolcheck.co.kr/index.asp"> <img src="/image/sub_logo.gif" width=234 height=45 border=0 alt="CoolCheck Logo"></a> 일반적인 스크린 리더나 보이스 리더에서는 위와 같은 경우 "[CoolCheck Logo]", "Link CoolCheck Logo", "Link Graphic CoolCheck Logo" 라고 읽어주게 됩니다. alt 텍스트가 없으면 <a> 태그의 href 속성을 읽거나 <img> 태그의 src 속성을 읽기 때문에 href 또는 src 값이 이미지 링크의 의미를 전달할 수 있다고 볼 수 없습니다. ■ 이미지 버튼을 사용하는 경우  진단 URL : <INPUT id="url" size=55 value="http://" name="URL" alt="주소입력"> <INPUT id="sub" type="image" src="//image/check_bimage.gif" width=68 height=25 value="Check!" name="output" alt="진단시작"> 버튼에 alt 속성이 없을 경우 스크린 리더나 보이스 리더에서는 value 값을 찾게 되고 value 값도 없는 이미지 버튼인 경우 src 값을 읽어주게 되므로 리더중에는 "이미지 버튼 : //image/check_bimage.gif" 이런식으로 읽어지게 됩니다. 이것은 버튼의 의미를 정확히 전달할 수 없으며, value 또는 alt 값을 넣지 않는 경우도 발생하므로 규정을 준수하여 정확한 정보를 제공해야 합니다. ■ 데코레이션 이미지와 포멧팅 이미지를 사용하는 경우 <span class="menu"> <img src="/image/m_dot.gif" width="10" height="10" alt="불릿"> <span id="s_0101" class="menu" style="color:#000000; cursor:auto;">웹 진단 서비스</span> </span><br> <span class="menu"> <img src="/image/sub_dot.gif" width="10" height="10" alt="불릿"> <a class="title" href="/service/service_0102.asp" title="소개"> <span id="m_0102">소개</span> </a> </span><br> <span class="menu"> <img src="/image/sub_dot.gif" width="10" height="10" alt="불릿"> <a class="title" href="/service/service_0103.asp" title="진단 항목"> <span id="m_0103">진단 항목</span> </a> </span><br> 위의 예처럼 이미지를 단순히 데코레이션용으로 사용한다면 alt 값을 짧게 의미를 전달할 정도로 작성해 줘야 합니다. 또 다른 예로 링크로 연결될 페이지에 대한 설명 텍스트가 같은 <a>안에 포함되어 있다면 <a href=".."><img src="..." alt="테스트">테스트</a> 스크린 리더나 보이스 리더가 중복으로 "link 테스트","link 테스트" 읽게 됩니다. alt 값을 null 값(alt="")으로 처리하게 되면 "link","link 테스트" 로 읽어 중복을 피할수 있지만 이용자의 판단을 요구하는 부분이므로 가급적 alt 값은 넣어 주는것이 좋습니다. ■ 이미지 맵을 사용하는 경우 <img src="/image/index_topmenu.gif" width=337 height=24 border=0 alt="상단 검색메뉴" usemap="#topnavi"> <map name="topnavi"> <area href="/index.asp" alt="Cool Check" shape="rect" coords="0,0,41,23"> <area href="/service/service_0101.asp" alt="서비스 종류" shape="rect" coords="41,0,125,23"> <area href="/directory/directory.asp" alt="사이트 평가" shape="rect" coords="125,0,209,23"> <area href="/document/board/board01.asp?code=board01&btitle=웹%20관련%20뉴스" alt="뉴스 및 자료" shape="rect" coords="209,0,275,23"> <area href="/help/faq.asp" alt="도움말" shape="rect" coords="275,0,336,23"> </map> 위와 같은 경우 alt 값은 짧고 간결한 문구로 써야합니다. 예를 들어 "도움말"의 내용을 상세히 알려 주기 위해 "FAQ 및 가이드, 용어집, QA" 이렇게 작성할 수 있으나 스크린 리더나 보이스 리더에서 듣는 시간을 단축시키기 위해 짧은 alt 값을 사용한 것입니다. CoolCheck!™ 사이트의 경우 상단 검색메뉴는 텍스트로만 이루어져 있습니다. 페이지의 사이즈를 줄여주어 저속 모뎀 기준으로 다운로드 시간을 조금 줄여줄 수 있습니다.
■ 차트와 같은 많은 정보를 전달하는 이미지를 사용하는 경우
주간 접속통계
<img src="/image/chart_bar.gif" width=373 height=293 border=0 alt="주간 접속통계" longdesc="week_diagnosis.html"> <a href="javascript:Win_open(\'week_diagnosis.html\');" title="week_diagnosis.html">텍스트 화면</a> 위와 같이 차트로 구성되어 있는 이미지의 경우 포함되어 있는 정보가 alt 텍스트의 짧은 문구로 처리하기에는 많습니다. 이 경우 longdesc(long description) 속성으로 처리되지만 브라우저 종류에 따라 longdesc 속성을 지원하지 않는다면 별도의 텍스트로 이루어진 페이지를 제공해야 합니다. |
인식의 용이성 | | | 시간에 따라 변화하는 영상매체는 해당 콘텐츠와 동기되는 대체 매체를 제공해야 한다. |
|
WAI에서 대응하는 항목은 다음과 같습니다.
1.4 시간을 기반으로 한 멀티미디어 프리젠테이션(예를 들면 동영상이나 애니메이션)과 그에 상응하는 대체물 (예를 들면 시각적인 트랙에 대한 캡션(텍스트 자막)이나 음성 설명)은 동기화시켜야 한다. 이 지침과 관련하여 특기할 만한 점은 인터넷을 통하여 MS사의 파워포인트 프리젠테이션을 제공할 때 음성 설명이 없는 경우 alt text를 제공해야 한다는 것입니다. 파워포인트 2000 이상에서는 alt text를 쉽게 입력할 수 있습니다. 즉 서식 메뉴에서 \'그림\'을 누르고 \'웹\' 탭을 누른 다음 대체 텍스트(alt text)를 입력하면 됩니다.
단순히 페이지의 배경 음악으로 처리되는 오디오인 경우 alt 텍스트를 넣어줄 필요는 없습니다. 하지만 뉴스를 다루는 사이트와 같이 정보 전달을 목적으로 사용된 중요한 오디오, 비디오 컨텐츠는 보완해줄 자막이나 원고 같은 텍스트 링크를 제공하여 액세서빌리티를 향샹시킬 수 있습니다.
또한 중요시 되는 것으로 실시간으로 진행되는 오디오 방송의 경우 방송후에 제공되는 원고 만으로는 접근성을 충족시켰다고 할 수 없으므로 실시간 자막 방송등의 방법을 찾아야 합니다. 현재 이런 부분에 대한 활발한 기술 개발이 이루어지고 있으며 향후 효과적인 컨텐츠 전달이 이루어지리라 판단됩니다. - 대상 장애
- 시각 장애
- 시력 장애
- 청각, 청력 장애
|
인식의 용이성 | | | 콘텐츠가 제공하는 모든 정보는 색상을 배제하더라도 인지할 수 있도록 구성되어야 한다. |
|
콘텐츠가 제공하는 모든 정보는 색상을 배제하더라도 인지할 수 있도록 구성되어야 한다.
이에 대응하는 WAI의 지침은 다음과 같습니다.
2.1 색깔과 함께 전달되는 모든 정보는 색깔이 없더라도 맥락이나 다른 마크업에 의해 구별 가능해야 한다.
이 지침에서 오해하지 말아야 할 것은 동 지침이 색상의 선택을 제한하는 것이 아니라는 점입니다. 동 지침의 구체적인 사례를 들어보자면 예컨데 회원가입 폼 작성시 "빨간색으로 표시된 항목은 필수 기재 사항입니다"라고 적는 경우입니다. 이런 경우엔 <strong>이나 <em> 태그를 사용하는 등의 방법을 쓰는게 좋습니다. 그리고 이미지 안에 색상으로만 액션을 표시하는 것도 피해야 합니다. 불가피한 경우 적당한 alt text 문구를 넣어서 혼란을 방지하도록 하는 것이 좋습니다. 사용예
■ 색상으로 의미를 전달한 잘못된 예 ※ 아래의 입력 사항을 정확히 기재해 주시기 바랍니다. 확인후 빠른 시간내에 연락드리도록 하겠습니다.※ 빨간색으로 표시된 항목은 필수 기재 사항입니다
위와 같은 경우는 일부 보이스 리더는 색상 구분을 하지 못하므로 어떤 항목이 필수 기재 사항인지 알 수가 없습니다. 이런 문제는 특수 문자를 사용하거나 텍스트를 강조(<strong>, <em>)하여 그 의미를 파악할 수 있게 해야 합니다. 아래는 올바른 사용예입니다.
※ 아래의 입력 사항을 정확히 기재해 주시기 바랍니다. 확인후 빠른 시간내에 연락드리도록 하겠습니다. ※ * 표시된 강조된 항목은 필수 기재 사항입니다. |
운용의 용이성 | | | 이미지 맵 기법이 필요할 경우에는 클라이언트측 이미지 맵을 사용하거나 서버측 이미지 맵을 사용할 경우에는 동일한 기능을 하는 텍스트로 구성된 대체 콘텐츠를 제공해야 한다. |
|
이미지 맵 기법이 필요할 경우에는 클라이언트측 이미지 맵을 사용하거나 서버측 이미지 맵을 사용할 경우에는 동일한 기능을 하는 텍스트로 구성된 대체 콘텐츠를 제공해야 한다. WAI에서 여기에 해당하는 항목은 다음과 같습니다.
1.2 서버측 이미지 맵을 사용할 때에는 그림의 각 활성화 영역마다 중복적인 텍스트 링크를 제공해 준다. 9.1 기하학적인 도형으로 정의가 안 되는 영역이 있는 경우를 제외하고는 서버측 이미지 맵 대신에 반드시 클라이언트측 이미지 맵을 사용한다. 이미지 맵이란 한 개의 이미지상에 여러개의 링크를 두는 기법을 말합니다. 용어가 지칭하는 것과는 달리 실제 맵(지도)은 아니지만 예컨데 흔히 볼 수 있는 지도찾기의 그림상에서 특정 지역을 클릭하면 해당 지역의 정보가 있는 곳으로 이동하는 것이 그 사례입니다.
클라이언트와 서버사이드 이미지 맵은 맵상에서 방문객이 클릭했을때 그 해석을 클라이언트에서 하느냐 서버에서 하느냐에 따라 구분됩니다. 클라이언트 이미지 맵은 이미지에 alt text를 제공하는 것과 동일하기 때문에 큰 어려움 없이 스크린 리더가 읽을수 있습니다. 그러나 서버사이드 이미지 맵은 링크 정보가 서버에 있기 때문에 스크린 리더가 읽을 수 없습니다. 그러므로 일차적으로 맵을 쓸려면 클라이언트 사이드 이미지 맵을 쓰는 것을 권장하는 것입니다. 부득이 서버 사이드 이미지 맵을 쓸 경우에는 맵에서 사용될 링크 목록을 alt text 형태로 제공해야만 스크린 리더등으로 접근이 가능합니다. - 대상 장애
- 시력/시각 장애
- 색맹/색약 장애
- 마우스를 사용할 수 없는 경우
사용예
■ 서버측 이미지맵을 사용하는 경우
<a href="#"> <img src="images/index_topmenu.gif" width=337 height=24 border=0 ismap alt="상단 검색메뉴"> <a> 위의 예는 usemap 대신 ismap 속성을 사용하여 클라이언트 브라우저에 좌표값을 전송하고, 이용자가 원하는 페이지로 이동하기 위해서는 이미지맵의 특정 영역을 클릭해야 합니다. 문제는 마우스를 사용할 수 없는 사용자는 이런 서버측 이미지맵을 사용할 수 없습니다. 따라서 서버측 이미지맵을 클라이언트 이미지맵으로 대처하거나, 텍스트 형태의 네비게이션 링크 리스트를 같이 제공해야 합니다. |
운용의 용이성 | | | 콘텐츠를 구성하는 프레임의 수는 최소한으로 하며, 프레임을 사용할 경우에는 프레임별로 제목을 붙여야 한다. |
|
콘텐츠를 구성하는 프레임의 수는 최소한으로 하며, 프레임을 사용할 경우에는 프레임별로 제목을 붙여야 한다. WAI에서 여기에 해당하는 항목은 다음과 같습니다.
12.1 프레임을 구분하고 프레임간의 탐색을 쉽게 하기 위해서 모든 프레임에는 제목(이름)을 붙여야 한다. 프레임 페이지는 프레임셋 파일과 서브 프레임들로 구성됩니다. 이 때 서브 프레임들에 타이틀 속성을 명기하지 않으면 스크린 리더에서 식별을 할 수 없게 됩니다. 여기서 지적할 부분은 설사 서브 프레임에 타이틀 속성을 기재하더라도 서브 프레임의 타이틀이 동일한 경우(게시판등)가 많아 사실상 서브 프레임간 식별이 곤란한 때가 많다는 것입니다. 중요도나 목적에 따라 달라지겠지만 가급적 타이틀을 다르게 해야 접근성 취지에 부합될 것입니다. 사용예
■ 프레임을 사용하는 경우
<frameset ROWS="30%,*,20%" title="frameset"> <frame SRC="frame/frame1.html" NAME="topframe" title="top frame"> <frameset COLS="30%,*"> <frame SRC="frame/frame3.html" NAME="leftframe" title="left frame"> <frame SRC="frame/frame4.html" NAME="rightframe" title="right frame"> </frameset> <frame SRC="frame/frame2.html" NAME="bottomframe" title="bottom frame"> <noframes> 프레임이 제공되지 않는 브라우저는 이 텍스트가 보입니다. </noframes> </frameset> 위의 같이 프레임셋을 사용한 페이지인 경우 lynx과 같은 특수 브라우저는 프레임의 name 속성을 읽고, 스크린 리더나 보이스 리더는 해당 서브 프레임들의 <title> 태그의 값을 읽는 경우가 있습니다. 문제는 일반 브라우저들에서 타겟 프레임 페이지의 타이틀은 브라우저 타이틀바에 보이지 않기 때문에 개발자들이 서브 프레임 페이지의 타이틀의 필요성을 인식하지 못한다는데 있습니다. 이때 리더는 각각의 프레임의 의미를 파악하지 못하게되므로 이용자에게 불편함을 주게 됩니다. 그래서 서브 프레임 페이지을 포함한 모든 웹페이지에는 의미 있는 <title> 태그를 넣어야 합니다.
또한, 프레임의 title 속성을 사용하는 것이 프레임으로 만들어진 사이트의 네비게이션에 보다 적합하기 때문에 프레임의 title 속성을 넣어 사용해야 합니다. |
운용의 용이성 | | | 콘텐츠는 스크린의 깜빡거림을 피할 수 있도록 구성되어야 한다. |
|
콘텐츠는 스크린의 깜빡거림을 피할 수 있도록 구성되어야 한다. WAI에서 여기에 해당하는 항목은 다음과 같습니다.
7.1 웹 표시 장치가 사용자들에게 깜박임을 조절할 수 있게 하기 전까지는 화면에 깜박임을 넣지 않아야 한다. 이 지침은 움직이는 gif나 애플릿 및 스크립트를 대상으로 합니다. 또한 중요도 2에 있는 항목이긴 하지만 blink, marquee 태그의 사용이 오히려 현실에서 더 목격하기 쉬운 사례라고 볼 수 있습니다. 이 두 태그는 사용을 안하는것이 접근가능한 웹사이트를 만들기 위해 중요합니다. 깜빡거림의 주파수 범위가 3hz에서 49hz인 경우 광과민성 발작의 원인이 된다고 합니다. 실천적으로 사이트 첫페이지는 깜빡거리는 요소가 없도록 만들고 다음 페이지에 깜빡거리는 요소가 있을 때에는 경고를 표시하고 깜빡거림이 없는 대체 페이지와 이 페이지로 이동할 수 있는 링크를 제공하는 것이 필요합니다 사용예
■ <blink> 태그를 사용하는 경우
<blink>Netscape 에서만 깜박임 효과를 볼 수 있습니다.</blink> <blink> 태그의 경우 깜박이는 빈도는 0.8Hz로 액세스 보드에서 규정한 위험 수치 범위는 아니지만 ESC키로 컨트롤할 수 없고, IE 5.0 이상, 오페라 브라우저에서는 지원하지 않습니다. ■ <marquee> 태그를 사용하는 경우
<marquee>기본값이 설정된 marquee 태그 입니다.</marquee><br> <marquee scrolldelay="1">scrolldelay 속성 값을 "1" 지정한 marquee 태그 입니다.</marquee> 위에 두가지로 설정한 <marquee> 태그의 예를 들었습니다. 두번째의 경우 움직이는 속도가 빨라서 스크린 확대기나 돋보기를 사용하는 이용자의 경우 큰 불편을 겪게 됩니다.
결론적으로 <blink> 또는 <marquee> 태그는 정식 HTML이 아니고 브라우저에서 ESC키를 통한 컨트롤도 할수 없기 때문에 사용을 자제해야 합니다. 또한, 에니메이션 GIF, 플래시 등에서도 깜박임 효과의 빈도가 너무 크게 만들면 안됩니다. |
운용의 용이성 | | | 키보드 (또는 키보드 인터페이스)만으로도 웹 콘텐츠가 제공하는 모든 기능을 수행할 수 있어야 한다. |
|
키보드 (또는 키보드 인터페이스)만으로도 웹 콘텐츠가 제공하는 모든 기능을 수행할 수 있어야 한다. 이에 대응하는 WAI의 체크포인트는 중요도1의 개별 항목에서는 찾을수 없습니다. 그보다는 지침 9 전체의 명제인 "장치 독립적인 설계를 한다"가 이를 포함하고 있다고 봐야 할 것입니다. WAI의 권장 적합도 A에는 없는 체크포인트이나 실제 필요에 비추어볼때 타당하다고 봅니다. 동 지침의 실천적 목표는 마우스보다는 키보드에 익숙한 시각장애인들과 마우스를 사용하기 힘든 운동장애를 가진 사람들을 고려한 것이라고 보입니다. 특히 마우스를 클릭하는등의 이벤트 발생시 이벤트 핸들러가 스크립트를 불러오게 되는데 이 때 키보드 이벤트 핸들러가 없다면 스크립트에 접근할 수 있는 길이 봉쇄되는 것입니다. 따라서 키보드로도 스크립트가 접근 가능하게 만들려면 대응하는 키보드 이벤트 핸들러를 추가하여야 합니다. 단 현실적으로 사용례는 찾아보기 힘드나 현재 표준을 이루는 W3C HTML4.01 규약에는 마우스의 더블 클릭에 대응하는 키보드의 이벤트가 없으므로 사용을 하지 않는 것이 좋습니다. 대상 장애
- 시각장애
- 마우스를 사용하기 힘든 운동 장애
사용예
■ 마우스 이벤트 핸들러만 사용하는 경우
마우스 포인터를 이곳에 옮기면 내용이 바뀝니다. <p onmouseover="chkMouse(1);" onmouseout="chkMouse(2);"> <span id="chkvalue">마우스 포인터를 이곳에 옮기면 내용이 바뀝니다.</span> </p>
위와 같이 마우스 이벤트 핸들러인 onMouseover() 를 사용할 경우 키보드로는 바뀐 내용을 알 수 없게 됩니다. 이럴 경우 탭 지정이 가능한 태그 나 속성을 지정하고 onFocus, onBlur, onKeydown, onKeyup, onKeypress와 같은 키보드 이벤트 핸들러도 추가하여 접근성을 높일 수 있습니다. 아래는 마우스와 키보드 이벤트 핸들러를 둘다 만족할 수 있는 예입니다.
<a href="javascript:chkMouse(3);" onFocus="chkMouse(5);" onBlur="chkMouse(4);" onmouseover="chkMouse(5);" onmouseout="chkMouse(6);" title=""> <span id="chkvalue1">마우스 포인터를 이곳에 옮기거나 클릭하면 내용이 바뀝니다.</span> </a> |
운용의 용이성 | | | 웹 콘텐츠는 반복적인 네비게이션 링크(repetitive navigation link)를 뛰어넘어 페이지의 핵심부분으로 직접 이동할 수 있도록 구성하여야 한다. |
|
웹 콘텐츠는 반복적인 네비게이션 링크(repetitive navigation link)를 뛰어넘어 페이지의 핵심부분으로 직접 이동할 수 있도록 구성하여야 한다. 이에 대응하는 WAI의 지침은 다음과 같습니다.
13.6 관련된 링크들은 한데 묶어 주고, 웸 표시 장치가 그 모둠을 식별할 수 있도록 한다. 그리고, 웹 표시 장치가 사용자들에게 그런 기능을 제공하기 전까지는 모둠을 건너 뛸 수 있는 방법도 제시해 주어야 한다.(중요도3) 동 항목은 중요도 선별에 있어서 WAI의 지침보다는 미국 섹션 508의 지침을 따른것으로 보입니다. 그러나 현실적인 필요에 비추어볼때 타당하다고 봅니다. 동지침은 예컨데 사이트 구조상 동일한 상단 메뉴나 좌측 메뉴가 페이지마다 되풀이 될 경우 이를 스크린 리더가 읽지 않고서도 건너뛸 수 있도록 페이지를 만들라는 것입니다. 여러가지 방법이 있겠지만 제일 쉬운 방법은 각 페이지의 메뉴 시작 부분에 해당 페이지의 컨텐츠로 바로 이동할 수 있는 링크를 제공하면 메뉴를 안 읽고도 컨텐츠에 직접 접근할 수 있게 됩니다. 대상 장애
- 웹 접근성 지침 제정 목적에 언급된 모든 장애
사용예
■ 검색 메뉴을 건너뛰고 다음 내용으로 이동시키는 경우
<table width="100%" cellspacing="0" cellpadding="0" border="0"> <tr> <td><a href="#Skip" title="검색메뉴 건너뛰기"> <img src="/image/blank.gif" width="1" height="1" alt="" border="0"></a> </td> 검색메뉴 중략.... <a name="Skip"/> 스크린 리더나 보이스 리더에서는 탭키와 방향키로 이동하여 문장들을 읽게 되며 위와 같이 최상단에 메뉴를 건너뛰게 <a> 태그를 사용 하게 되면 "검색메뉴 건너뛰기" 라는 링크를 만났을때 이용자의 선택에 의해 다음 내용으로 이동하게 됩니다. |
운용의 용이성 | | | 실시간 이벤트나 제한된 시간에 수행하여야 하는 활동 등은 사용자가 시간에 구애받지 않고 읽거나, 상호작용을 하거나 응답할 수 있어야 한다. |
|
실시간 이벤트나 제한된 시간에 수행하여야 하는 활동 등은 사용자가 시간에 구애받지 않고 읽거나, 상호작용을 하거나 응답할 수 있어야 한다. 이에 대응하는 WAI의 지침은 개별 체크포인트가 아닌 지침 7 즉 "시간에 따라 변하는 콘텐츠는 사용자가 제어할 수 있게 한다."의 5가지 체크포인트가 될 것입니다. 이 역시 여덟번째 항목과 마찬가지로 미국 섹션 508을 따른 것으로 보입니다. 글의 목적상 세부적인 내용은 생략하도록 하겠습니다. 동 항목은 애매한 부분이 있습니다. 해설을 살펴봐도 실시간 이벤트의 구체적인 사례가 불분명하며 이벤트의 목적상 실시간을 요할 때에는 불가피하다고 보아야 하는 경우(시간내 풀어야 하는 시험,경매등)가 대부분입니다. 동 항목의 목적이 비장애인보다 장애인이 사이트 이용에 있어서 시간이 더 필요할 수 있다는 것을 배려하자는 것이라면 필요없이 남발하는 경우를 제어하는 것이 타당할 것입니다. 그 구체적인 사례는 몇 초 경과후 페이지 이동, 자동 갱신되는 컨텐츠, 잠시 나타났다가 사라지는 대화창, 세션을 너무 짧게 줘서 페이지나 특히 폼의 유효시간이 만료되는 경우등이 있습니다. 이런 경우에 사용자에게 시간 제한을 풀거나 늘릴수 있는 제어장치(선택 버튼등)를 제공하여야 합니다. 대상 장애
- 웹 접근성 지침 제정 목적에 언급된 모든 장애
사용예
■ 시간연장 버튼을 활용하는 경우
* 각 질문의 응답 제한 시간은 5초 입니다. 시간 연장이 필요한 장애인분은 먼저 "시간 연장" 버튼을 클릭하시면 10초로 연장됩니다.
남은 제한 시간이 표시됩니다. 위의 경우 5초의 제한시간에 어떤 응답을 요하는 예제입니다. 제한 시간이 완료된 후 내용이 다음 항목으로 바뀌거나 새로운 창이 뜬다면 천천히 읽어야 하는 사람과 장애인들을 당황스럽게 만들 것입니다. 따라서, 질문 전에 제한 시간을 연장할 수 있는 기능을 제공하던지 질문의 성격에 따라 제한 시간을 여유있게 줘야 합니다. |
이해의 용이성 | | | 데이터 테이블은 테이블을 구성하는 데이터 셀의 내용에 대한 정보가 충분히 전달될 수 있어야 한다. |
|
데이터 테이블은 테이블을 구성하는 데이터 셀의 내용에 대한 정보가 충분히 전달될 수 있어야 한다. WAI에서 여기에 해당하는 항목은 다음과 같습니다.(중요도1)
5.1 데이터가 들어있는 표에는 제목행과 제목열(통칭하여 header)을 명시한다. 5.2 두 개 이상의 논리적인 제목행이나 제목열을 갖는 데이터가 들어있는 표에서는 데이터 칸끼리 또는 제목 칸끼리 관련 짓는 마크업을 사용한다 이 항목은 논란의 소지가 있습니다. 우선 국내 웹사이트의 현실상 테이블이 데이터 전달용으로서의 기능 뿐만 아니라 레이아웃용으로 주로 사용되기 때문에 WAI 지침의 내용중 레이아웃용으로 테이블을 사용하는 것을 피하라는 요구는 기존의 웹사이트에 바로 적용하기에는 매우 힘듭니다. 그러나 스타일시트를 써서 형식을 분리하는 것은 단순히 접근성의 문제만은 아닙니다. 테이블의 본래 목적인 데이터 전달을 위해 사용할 경우 지켜야 할 점은 우선 테이블을 설명하는 캡션태그와 summary 속성을 사용할 것과 그리고 테이블 헤더(TH)를 써야 스크린 리더를 통해 접근할 경우 논리적으로 읽을 수 있다는 것입니다. 또한 테이블의 행이 구조적으로 나눠질 경우 , tfoot, 및 tbody col 및 colgroup, "headers", "scope" 및 "axis" 속성들을 적절하게 사용하여야 합니다. 사용예
■ <th> 태그와 headers, scope 속성을 활용하는 경우
참고. 해당 항목별 페널티 페이지 | 메타데이터가 없는 페이지 | 타이틀(Title)이 누락된 페이지 |
---|
메인 페이지 | -4 | -2 | 허브 페이지 | -2 | -1 |
<span>참고. 해당 항목별 페널티</span> <table class="fixtext" width="80%" border="0" cellpadding="0" cellspacing="1" bgcolor="#A9A9A9" style="text-align:center;"> <tr height=25> <th id="c1" width="20%" bgcolor="#F5F5F5">페이지</th> <th id="c2" width="40%" bgcolor="#F5F5F5">메타데이터가 없는 페이지</th> <th id="c3" width="40%" bgcolor="#F5F5F5">타이틀(Title)이 누락된 페이지h;/td> </tr> <tr height=25> <td id="r2" bgcolor="#FFFFFF">메인 페이지</td> <td headers="r2 c2" bgcolor="#FFFFFF">-4</td> <td headers="r2 c3" bgcolor="#FFFFFF">-2</td> </tr> <tr height=25> <td id="r3" bgcolor="#FFFFFF">허브 페이지</td> <td headers="r3 c2" bgcolor="#FFFFFF">-2</td> <td headers="r3 c3" bgcolor="#FFFFFF">-1</td> </tr> </table> 위의 예제는 CoolCheck 웹 진단 서비스의 평가 기준으로 쓰인 기본 항목인 "나. 검색 및 문서관리의 용이성(기본 점수 20점, 최소점수 5점)" 항목의 페널티의 항목을 보여주기 위해 구성된 데이터 테이블입니다. 우선 각각의 컬럼에 id 속성을 부여하고 각각의 TD 데이터에 headers 속성을 넣어 해당 데이터가 어떤 컬럼의 값인지를 들려주게 됩니다.
예를 들어 메인 페이지이면서 메타데이터가 없는 페이지의 페널티 값은 오류 건수당 -4로 책정되어 있습니다. 이때 headers="r2 c2"로 지정하게 되면 스크린 리더나 보이스 리더에서는 "메인페이지 메타데이터가 없는 페이지 -4" 이렇게 읽어 주게 됩니다. 리더의 종류에 따라 <th>를 인식하는 경우와 scope 속성을 인식하는 경우가 있습니다. 아직 모든 리더들이 이런 부분을 완전히 인식하지는 않으며 각각의 행과 열을 순차적으로 읽어주는 선형화된 구조에 의지하는 수준입니다.
아래 소스 코드는 <th> 태그 대신 scope속성을 사용한 예입니다. <span>참고. 해당 항목별 페널티</span> <table class="fixtext" width="80%" border="0" cellpadding="0" cellspacing="1" bgcolor="#A9A9A9" style="text-align:center;"> <tr height=25> <td width="20%" bgcolor="#F5F5F5">페이지</td> <td scope="col" width="40%" bgcolor="#F5F5F5">메타데이터가 없는 페이지</td> <td scope="col" width="40%" bgcolor="#F5F5F5">타이틀(Title)이 누락된 페이지</td> </tr> <tr height=25> <td scope="row" bgcolor="#FFFFFF">메인 페이지</td> <td bgcolor="#FFFFFF">-4</td> <td bgcolor="#FFFFFF">-2</td> </tr> <tr height=25> <td scope="row" bgcolor="#FFFFFF">허브 페이지</td> <td bgcolor="#FFFFFF">-2</td> <td bgcolor="#FFFFFF">-1</td> </tr> </table> |
이해의 용이성 | | | 콘텐츠의 모양이나 배치는 논리적으로 이해하기 쉽게 구성하여야 한다. |
|
콘텐츠의 모양이나 배치는 논리적으로 이해하기 쉽게 구성하여야 한다. WAI에서 대응하는 항목은 다음과 같습니다.
6.1 스타일 시트가 없더라도 읽을 수 있게 문서를 구조화한다. 예를 들면, HTML 문서가 스타일 시트가 없이 표시되더라도 반드시 그 문서를 읽을 수 있어야 한다. 열한번째 항목(국내)의 해설에서는 스타일시트의 경우뿐만 아니라 레이아웃용 테이블의 사용 불가피성을 고려하여 사용시 주의점을 지적하고 있습니다. 그러나 구조 표시용 마크업을 사용하지 말라는 것은 테이블 헤더(TH)등을 사용하지 말라는 것이지 캡션등을 사용하지 말라는 것은 아닙니다. 오히려 레이아웃용 테이블임을 명시하는 캡션은 유용할 수도 있습니다. 이 부분은 정정이 필요하다고 봅니다. 스타일 시트는 문서의 표현 형식을 위해 사용이 권장됩니다. 그러나 스크린 리더등이 기술적 문제로 인해 아직 스타일 시트를 완벽하게 지원하지 못하기 때문에 스타일 시트를 제거하거나 적용하지 않아도 모든 정보와 의미가 전달될 수 있는지 확인하는 것이 필요합니다. 사용예
■ 레이아웃 스타일시트가 잘못 사용된 경우
<style type="text/css"> <!-- .menu1 { position:absolute; top:1em; left:0em; font-weight:bold;} .menu2 { position:absolute; top:1em; left:15em; font-weight:bold;} .item1 { position:absolute; top:3em; left:0em;} .item2 { position:absolute; top:4.5em; left:0em;} .item3 { position:absolute; top:3em; left:15em;} .item4 { position:absolute; top:4.5em; left:15em;} --> </style> </HEAD> <BODY> <div> <span class="menu1">■사이트 개요</span> <span class="menu2">■문제점(오류)</span> <span class="item1">1.사이트 디렉토리 트리</span> <span class="item2">2.파일 및 페이지 정보</span> <span class="item3">1.전체 깨진 링크수</span> <span class="item4">2.깨진 링크를 포함한 페이지</span> </div> 위의 소스 코드처럼 스타일을 지정할 경우 브라우저에서는 각각 정렬된 순서로 나타나게 됩니다. 하지만 스타일을 제거하고 브라우저로 해당 페이지를 열어보면 다음과 같이 순차적으로 읽기 때문에 스타일에서 적용한 형태대로 나오지 않게 됩니다.
"■사이트 개요 ■문제점(오류) 1.사이트 디렉토리 트리 2.파일 및 페이지 정보 1.전체 깨진 링크수 2.깨진 링크를 포함한 페이지"
이런 문제는 위의 소스중 class="menu2"의 위치를 바꿔주면 쉽게 해결 됩니다. 아래는 수정된 소스 코드와 스타일시트 미적용 상태일때 결과 값입니다. 중략... <span class="menu1">■사이트 개요</span> <span class="item1">1.사이트 디렉토리 트리</span> <span class="item2">2.파일 및 페이지 정보</span> <span class="menu2">■문제점(오류)</span> <span class="item3">1.전체 깨진 링크수</span> <span class="item4">2.깨진 링크를 포함한 페이지</span> </div> "■사이트 개요 1.사이트 디렉토리 트리 2.파일 및 페이지 정보 ■문제점(오류) 1.전체 깨진 링크수 2.깨진 링크를 포함한 페이지" |
이해의 용이성 | | | 온라인 서식을 포함하는 콘텐츠는 서식 작성에 필요한 정보, 서식 구성 요소, 필요한 기능, 작성 후 제출 과정 등, 서식과 관련한 모든 정보를 제공해야 한다. |
|
온라인 서식을 포함하는 콘텐츠는 서식 작성에 필요한 정보, 서식 구성 요소, 필요한 기능, 작성 후 제출 과정 등, 서식과 관련한 모든 정보를 제공해야 한다. 직접적으로 대응하는 WAI의 지침은 지침 10 "잠정적인 접근성 보장 기법을 사용한다"의 체크포인트 10.2, 10.3, 10.4이며 중요도 선별에 있어서 미 섹션 508의 paragraph(n)을 따른 것으로 보입니다. 동 항목은 현실적으로 폼(form)의 처리와 관련되며 스크린 리더등의 처리 능력에 달려 있긴 하나 다음 3가지를 준수하여야 합니다. 첫째, 항목간 탐색이 쉽게 되기 위해 레이블을 붙여주어야 합니다. 둘째, input에는 기본 텍스트를 표시하여야 합니다. 셋째, text area 안에는 미리 정해진 기본값을 넣어두어야 합니다. 현재 많이 사용되는 플래쉬는 아직 접근성 지원이 미흡하며 따라서 선진국 어느 나라도 플래시 메뉴등의 기법은 사용하지 않고 있습니다. 그러나 모범을 보여야 할 정부중앙부처(특히 보건복지부!)까지도 플래시로 메뉴를 구성하는 것이 현실입니다. 애플릿 및 플러그인 종류는 접근성을 저해하는 근본적인 요소이므로 메뉴 및 폼등에서는 사용을 자제하도록 해야 합니다. 대상 장애
- 웹 접근성 지침 제정 목적에 언급된 모든 장애
사용예
■ <label>를 사용하는 경우
<span>전화번호 : <label for="t1"><img src="" width="1" height="1" alt="지역번호"></label> <label for="t2"><img src="" width="1" height="1" alt="국번"></label> <label for="t3"><img src="" width="1" height="1" alt="가입자번호"></label> </span> <span> <input type="text" name="t1" id="t1"> <input type="text" name="t2" id="t2"> <input type="text" name="t3" id="t3"> </span>
예제와 같이 작성된 스크린 리더로 페이지를 읽던중 "전화번호"라는 프롬프트(입력을 요구하는 지시자)를 만나게 되면 첫번째 입력 필드에 전화 번호를 적게 됩니다. 그런데, 두번째 입력 필드를 만나면 그때서야 두자리로 나눠서 써야 한다는것을 인지하게 됩니다. 세번째 입력 필드를 만나면 세자리로 나눠서 써야 한다는것을 깨닫고 다시 고쳐써야 하는 문제가 발생할 수 있습니다. 위의 예제에서는 1x1 픽셀의 이미지를 추가하여 alt 속성에 입력 필드의 설명을 적어주고 <label> 태그를 사용해서 해결해 보려고 한것입니다. 이 처럼 사용하게 되면 최소한 이미지의 alt 값을 읽어 주게되어 입력 필드의 갯수가 3개라는것을 이용자에게 미리 알려주게 되는것입니다.
위와 같은 경우 스크린 리더에 종류에 따라 이미지를 무시할 수도 있습니다.그래서, 다음은 <input> 태그에 title 속성을 넣어 같은 효과를 얻는 소스 코드를 제시 하였습니다. <span>전화번호 : </span> <span> <input type="text" name="t1" title="지역번호"> <input type="text" name="t2" title="국번"> <input type="text" name="t3" title="가입자번호"> </span> |
견고성 | | | 스크립트, 애플릿 또는 플러그 인(plug-in) 등과 같은 프로그래밍 요소들은 현재의 보조기술의 수준에서 이들 프로그래밍 요소들의 내용을 사용자에게 전달해줄 수 있을 경우에만 사용하여야 한다. |
|
스크립트, 애플릿 또는 플러그 인(plug-in) 등과 같은 프로그래밍 요소들은 현재의 보조기술의 수준에서 이들 프로그래밍 요소들의 내용을 사용자에게 전달해줄 수 있을 경우에만 사용하여야 한다. WAI에서 여기에 해당하는 항목은 다음과 같습니다.(중요도1)
6.3 스크립트나 애플릿, 또는 다른 프로그램 객체를 사용하지 않거나 지원하지 않는 경우에도 페이지 내용을 이해할 수 있어야 한다. 그것이 불가능하다면, 대안적으로 접근 가능한 페이지에 그것들을 대체할만한 정보를 제공해야 한다. 이 문제는 국내 지침의 작성자가 오해를 한듯합니다. 기본적으로 접근성 문제는 "기술 억압적"인 것이 아닙니다. 예를 들어 플래쉬로 정보를 제공할 때 현재의 스크린 리더등의 보조 장치가 플래쉬를 지원하지 못할 경우 플래쉬 속에 담겨 있는 컨텐츠를 스크린 리더가 이해할 수 있게끔 대체 링크 즉, 대체 페이지를 지원하기를 요구하는 것이지 지침의 해설처럼 플래쉬를 쓰지 말라는 것은 아닌 것입니다. 다만 공공기관등의 홈페이지에서 쓸데없이 무분별하게 플러그 인등을 남발하는 것은 바람직하지 못합니다. 또한 미국 섹션 508의 경우는 해당 애플릿이나 플러그인들이 접근성에 대한 대책을 가지고 개발되는 것을 예상하기 때문에 그에 대한 링크를 제공할 것을 요구하고 있습니다. 예컨데 흔히 쓰이는 아도비사의 PDF 뷰어나 매크로미디어사의 플래시 플레이어 또한 (최신 제품에서는)접근성을 보장하기 위한 기술적 장치가 되어 있습니다.
플래시 MX의 경우 플래시 컨텐츠에 alt 속성값을 넣을수 있는 Accessibility 패널을 제공하고 있습니다. 패널에는 name 필드와 description 필드가 있으며 이곳에 컨텐츠의 설명을 적어주면 됩니다. 플래시 컨텐츠의 이미지가 바뀔때마다 어떤 의미를 전달하고자 한다면 액션스크립트를 사용하여 바뀔때의 alt 값과 description 값을 변경해주면 됩니다. 때에 따라서 Accessibility 패널과 액션스크립트를 모두 사용하지 못할때도 있으므로 적절한 선택을 해야합니다. 또한 탭 인덱스와 단축키도 중요하므로 스크린 리더에서 충분한 테스트를 해봐야 합니다. - 대상 장애
- 웹 접근성 지침 제정 목적에 언급된 모든 장애
|
견고성 | | | 콘텐츠가 위의 13개 검사 항목을 만족하도록 최대한 노력하였으나 해결되지 않는 부분이 |
|
WAI에서 대응하는 항목은 다음과 같습니다.
11.4 만약 모든 노력을 해보았어도, 접근성이 높은 페이지를 만들 수 없다면, W3C의 기술을 사용하고, 접근 가능하며, 원래의 페이지와 동일한(equivalent) 정보(또는 기능)를 담고 있으며, 원래 페이지만큼 자주 업데이트되는 별도의 대안적인 페이지를 제공해야 한다. 접근가능한 웹사이트를 만드는 것은 관점에 따라 쉽고 간단할 수도 있고 상당히 어렵고 복잡할 수도 있습니다. 여기서 쉽고 간단하다는 것은 WAI의 지침중 중요도 1을 준수하는 경우를 의미합니다. 중요도 2나 3까지 준수하려고 할 경우 당연히 접근성은 높아지게 되나 들어가는 노력 또한 비례해서 커지게 됩니다. 각 국의 접근성 지침은 중요도 1에 초점을 맞춘 것이므로 최소한의 것이라 할 수 있습니다. 그리고 사이트 설계시서부터 접근성을 염두에 두고 사이트를 제작한다면 사실 접근성은 문제가 될 소지가 거의 없다고 봐도 무방합니다. 기존에 존재하는 사이트를 접근성있게 만들려고 할 때 이러저러한 문제가 발생하는 것입니다. |