Graceful Degradation

Graceful Degradation 은 “우아한 낮춤”, “적절한 퇴보”, “성능 저하” 등 여러가지로 번역되고 있습니다.

의미는, 먼저  최신의 기술 기반 혹은 최신의 기기에서 동작하는 기능을 만들고 나서 오래된 기술 기반 혹은 오래된 기기에서도 유사하게 (성능을 낮춰서라도) 동작하도록 조치하는것을 말합니다. 이런 의미에서 위의 번역들은 모두 틀리지 않다고 할 수 있겠습니다. (광의적으로 “성능 저하”도 틀리지는 않지만 웹 개발의 관점에서 보면 사용자 경험을 낮춰서라도 기능을 지원하는 것이기 때문에 “성능 저하”는 맞지 않을 것 같네요.)

※ 컴퓨터 시스템에서의 허용 오차 시스템(Fault tolerant system) 과 유사하다고 할 수 있습니다. 허용 오차 시스템은 프로그램 구동 환경에 문제가 생겨도 프로그램이 정지하지 않고 성능을 낮추면서 프로그램 구동을 지속하도록 하는 시스템을 말합니다.

우리가 잘 알고 있는 예를 들자면 IMG 태그에 alt 속성을 지정하는걸 들 수 있겠네요. 이미지를 표시하는 브라우저에서는 이쁘게 이미지를 표시하지만 텍스트 브라우저라든지 이미지를 렌더링하지 못하는 브라우저에서는 alt 속성에 부여한 대체 텍스트를 표시하도록 구성 합니다. (이 예에서는 성능을 낮춘다기보다 사용자 경험을 낮춰서라도 … 의 표현이 어울리겠네요. )

javascript 관점에서 Graceful Degradation 을 보자면 NOSCRIPT 라는 태그를 들 수 있습니다. 보통 NOSCRIPT 는 두가지 방식으로 사용됩니다.

NOSCRIPT (대체 콘텐츠 제공)

<script type="text/javascript" src="slide.js"></script>
<noscript>
<ul>
<li><a href="some url"><img src="1.jpg" alt="image 1"/></a></li>
<li><a href="some url"><img src="2.jpg" alt="image 2"/></a></li>
<li><a href="some url"><img src="3.jpg" alt="image 3"/></a></li>
</ul>
</noscript>

위의 예제에서 slide.js 는 서버로부터 이미지 3개를 받아 사용자 경험이 풍부한 스라이드 쇼를 만드는 스크립트입니다. (있다고 칩시다 –;) 바로뒤에 NOSCRIPT 태그를 사용해 스크립트가 동작하지 않는 브라우저에게 대신할 수 있는 콘텐츠를 제공하고 있습니다.

꽤 괜찮은 방법이라고 생각합니다. 자바스크립트가 구동되지 않는 환경에서도 콘텐츠에 접근할 수 있으며 IMG에 alt 를 제공하고 링크까지 걸려 있어 검색엔진도 좋아하는 형태입니다.

이 예에서의 문제는 NOSCRIPT 태그의 근본적인 문제입니다. 브라우저는 자바스크립트를 지원하지만 자바스크립트 파일을 통제하는 네트웍 환경 (보안상의 이유로?)에 있거나 자바스크립트를 다운로드 하지 못한 경우 사용자는 아무것도 볼 수 없게 됩니다.

NOSCRIPT (자바스크립트를 켜세요 ?)

<script type="text/javascript"  src="slide.js"></script>
<noscript>
<p>자바스크립트를 지원하는 브라우저를 사용하거나, 자바스크립트를 활성화 시켜 주세요</p>
</noscript>

우리는 사용자가 왜 자바스크립트가 동작하지 않는 브라우저를 사용하는지, 자바스크립트를 비활성화 시켰는지 알지 못합니다. 그런 상황에 사용자에게 “이래라, 저래라” 하는것은 좋은 방법이 아닙니다. 그리고 위 지시 문은 사용자가 자바스크립트가 뭔지 알고 있고, 자바스크립트를 활성화 시킬 수 있다고 가정하고 있습니다. 하지만, 태반의 사용자가 이런 사항 잘 알지 못합니다. 순전히 개발자의 관점에서 작성된 겁니다.

반성합니다 !! 저도 두번째 예제 코드를 무수히 만들었습니다. 변명을 하자면 KADO-WAH 초기 버전에서 (지금은 안 그렇죠?) SCRIPT 태그 이후에 NOSCRIPT 가 없는 경우 오류 (경고?)로 잡았었습니다. 그래서 기계적으로 SCRIPT 태그가 있는 곳에 NOSCRIPT (자바스크립트를 켜세요) 를 넣었고, 이게 또 HEAD 안에서는 P 태그 등이 올 수 없기 때문에 모든 SCRIPT/NOSCRIPT 태그를 BODY 밑으로 내리는 작업을 했습니다.  반성합니다.

Graceful Degradation 접근 방법

위의 두가지 예제를 보면 구현 모양은 다르지만 동일한  Graceful Degradation 접근 방법을 사용하고 있습니다.

자바스크립트로 slide.js 라는 사용자 경험 풍부한 기능을 먼저 만들고 자바스크립가 지원되지 않는 환경을 위해 NOSCRIPT를 이용해 추가(개선) 작업을 하고 있습니다. 이것이 뒤에서 말하려는 Progressive Enhancement 과 대조되는 부분입니다.

Progressive Enhancement

“점진적 향상” 이라고 번역할 수 있겠습니다.

말 그대로 기능을 점진적으로 향상시키는것을 말합니다. 바로 웹과 결부해서 말하자면

1. HTML 로만 콘텐츠를 구성합니다. (CSS 를 지원하지 않는 브라우저에서도 접근 가능합니다.)
2. CSS 로 시각적인 향상을 꾀합니다. (HTML은 이미 구성되었으므로 외부 CSS파일이 적당하겠네요.)
3. Javascript 를 적용해 사용자 경험을 향상 시킵니다. (역시 외부 js 파일을 두고 이벤트를 가로채는 방법으로 사용해야겠네요)

1.2.3 의 순서로 점차적으로 향상 시키고 있습니다. 이렇게 구현했을 때 나중에 나온 기술(css, javascript)들이 지원되지 않더라도 콘텐츠에 접근하는데 무리가 없습니다. 추가로 얻을 수 있는 장점은 이 방법을 사용하면 밑에 예제를 봐도 알겠지만 구조, 표현, 동작이 자연스럽게 분리된다는 점입니다. 단계적으로 html, css, js 가 추가되기 때문입니다. (솔깃하네요.)

직접 Progressive Enhancement 방법을 사용해 구현을 해 보겟습니다. 예제로는 어느 사이트에나 있는 FAQ를 사용합니다.

1. HTML 구성

<h1>자주답변하는 질문들</h1>
<dl id="faq-list">
<dt>백업파일(*.bak)을 생성하지 않는 방법은?</dt>
<dd>'기본설정'->'파일' 에서 '저장시 백업 파일 생성' 옵션을 제거하시면 됩니다.</dd>
<dt>업그레이드 후 이전 설정이 없어진 경우.</dt>
<dd>이전 버전을 올바르게 설치하지 않은 경우 일어나는 현상입니다. 이런 경우에는 '도구'->'INI 파일 디렉토리' 메뉴 옵션을 실행해서 이전 설정 (*.ini 파일)이 있는 디렉토리를 지정해 주십시오.</dd>
<dt>사용자 정의 stx, acp, ctl 파일을 추가하는 방법은?</dt>
<dd>
<p>*.STX 파일과 *.ACP 파일을 설정하는 방법</p>
<ol>
<li>'기본설정' 대화상자에서 '설정 및 구문강조' 페이지를 선택합니다.</li>
<li>원하는 파일 종류를 선택하거나 원하는 파일 종류가 없는 경우 '추가' 버튼을 누른 후 '파일 확장자' 란에 파일 확장자를 지정합니다.</li>
<li>STX 와 ACP 파일의 완전한 경로를 '구문 파일' 과 '자동 완성' 란에 지정합니다.</li>
</ol>
</dd>
</dl>

위의 FAQ는 에디트플러스 사이트에서 가져왔습니다. FAQ 목록에 DL 을 사용하는게 적절한지는 논외로 하겠습니다. HTML 만 사용했을 때 질문과 답변을 구분할 수 있도록 하는 목록 태그로는 적절하다고 생각해서 사용했습니다.

HTML만 적용된 화면

1단계에서 중용한 건 의미 있는 마크업을 논리적인 순서에 따라 구축하는게 중요하겠습니다. 물론, 이를 만족하기 위해서는 웹 표준을 준수하는게 우선되어야 할거고요.

하지만, 기획팀 으로부터 넘어온 스토리보드, 화면설계와 디자인팀으로 부터 잘려 넘어온 이미지들을 보고 있으면 당최 논리적으로 짜보기가 두려워 집니다. 뭐, 이런걸 잘 하는것도 우리의 능력중의 하나라고 봐야겠습니다. (전 멀었습니다.;;)

2. CSS 적용

body,dl,dt,dd {margin:0; padding:0;}
html {font-size:78%;}
html body {font-size: 1em;}
h1 {border:1px dotted #ccc; background:#eee; margin: 0 0 5px 0; padding:5px; font-size:1.4em;}
dt,dd {border-bottom:1px solid #ccc;line-height:1.5em;}
dt {background:black url(images/q.png) no-repeat left center; color:white; padding:7px 0 7px 25px; cursor:pointer;}
dd {background: #eee; padding:10px;}

CSS 까지 적용된 화면

네, 이쁘지 않은거 압니다. 제 미적감각이 이정도입니다. (사실, 최선을 다하지 않았다고 변명을 … ㅠㅠ)

3. javascript 적용

window.onload = function() {
var selectedQ = 0;
var dts = document.getElementsByTagName('dt');
var dds = document.getElementById('faq-list').getElementsByTagName('dd');
for(var i = 0, n = dts.length; i < n; i++) {
dds[i].style.display = (i == 0) ? 'block' : 'none';
dts[i].idx = i;
dts[i].onclick = function() {
if (selectedQ != this.idx) {
dds[selectedQ].style.display = 'none';
dds[this.idx].style.display = 'block';
selectedQ = this.idx;
}
};
}
};

javascript 까지 적용된 화면

네, 썩 좋지 않은거 압니다. (사실, 돌아가게 만드는게 우선이엇다는 변명을 … ㅠㅠ 정말 오랜만에 mootools 없이 javascript 만들어봤네요;;)

좋지 않은 예이긴 하지만, HTML → CSS → javascript 수순으로 점진적으로 향상시키고 있음을 주목해주세요.

위의 예는 faq.htm 에서 보실 수 있습니다. (ie8, firefox 에서만 테스트 되었습니다.)

정리

구현할 때 “누가 요새 javascript 안되는 브라우저를 쓰겠어?” 라는 생각이 들 정도로 자바스크립트는 대부분의 브라우저에서 지원하고 있는게 사실입니다. 사실, 그냥 막 써도 이로인한 불평(자바스크립트가 안되는 환경에서의 불평)도 들어본적이 없습니다. 아마, 사용자들 스스로가 감내하고 있겠지요. 하지만, 웹 접근성을 생각하고 이를 보장하고자 한다면 자바스크립트에 의존하는 코드를 사용해서는 안되겠습니다. href=”javascript:…” , href=”#” onclick=”" 이러 코드 때문에 얼마나 많은 시간을 웹 접근성 개선을 위해 허비했는지 … Progressive Enhancement  방법을 수행하는게 쉬운것만은 아닙니다. 아마 Graceful Degradation 과 비교해서 시간, 노력 등의 자원을 더 필요로 할겁니다. 기 구축된 사이트를 개선하는 작업에 있어서는 Progressive Enhancement 보다 Graceful Degradation 을 선택하는게 더 현명한 방법일지도 모르겠습니다. 하지만 잊지말아야 할 원칙 하나는 “Web for All”. 팀 버너스 리의

웹의 힘은 그것의 보편성에 있다. 장애에 구애없이 모든 사람이 접근할 수 있는 것이 필수적인 요소이다.
(The power of the Web is in its universality, Access by everyone regardless of disability is an essential aspect.)

라는 것이겠지요.

관련 지침

• 3.3.1 (콘텐츠의 선형화) 콘텐츠는 논리적인순서로 제공해야 한다.
• 4.1.1 (마크업 오류 방지) 마크업 언어의 요소는 열고 닫음, 중첩 관계 및 속성 선언에 오류가 없어야 한다.

Skip Navigation 에 대한 자세한 내용에 대해서는 성민장군님의 “Skip Navigation(건너뛰기 링크, 스킵 네비게이션)은 Quick Link가 아닙니다.” 포스트 하나면 될 것 같습니다. 생소하신 분들에게는 일독을 권합니다. (덧. 성민장군님의 이 포스트는 블로그 디자인 덕도 있겠지만, 쉬원쉬원하고 정성이 가득한 가치있는 포스팅이라고 생각합니다. 부럽습니다. 아흑)

누구를 위한 것인가

KWCAG 1. 0 (한국 웹 콘텐츠 접근성 지침) 에서는 건너뛰기 링크 에 대해서 다음과 같이 말하고 있습니다.

지침 8. 웹 콘텐츠는 반복 네비게이션 링크를 뛰어넘어 페이지의 핵심 부분으로 직접 이동할 수 있도록 구성하여야 한다.

• 웹 콘텐츠 상에 반복 네비게이션 링크 객체가 포함되어 있으며 이 링크 객체가 콘텐츠의 핵심부분보다 먼저 읽어주도록 구성된 경우에 이들 링크들의 읽기를 생략하고 직접 콘텐츠의 핵심 부분으로 이동할 수 있는 링크를 제공하여야 한다.
• 하나의 긴 문장으로 구성된 웹 페이지는 이 페이지의 문장을 여러 개의 논리적인 절로 구분하고 각 절의 색인을 콘텐츠의 첫 부분에 포함시켜 원하는 절의 시작 부분으로 직접 이동할 수 있도록 웹 페이지를 구성한다.
• 모든 웹 사이트는 텍스트 또는 대체 텍스트가 포함된 사이트 맵을 제공해야 한다.

덧붙여 “우수 사례” 로 2가지 모두 “보이지 않는 건너뛰기 링크 제공” 을 들고 있는데, 이는 일반 화면으로 볼 경우에는 보이지 않고 키보드를 사용하는 경우 포커스를 받을 수 있도록 화면에서는 숨겨 놓은 건너뛰기 링크를 말합니다.

하지만, 이렇게 건너뛰기 링크를 화면에서 숨겨 놓은 경우 화면은 인식하지만 키보드만을 사용하는 사용자에게는 무용지물이 됩니다. 키보드로만 서핑하는 사용자들에게도 건너뛰기 링크는 필수적입니다. 그렇지 않으면 본문의 링크를 이용해야 하는경우 TAB키를 무수히 많이 눌러야 합니다. 매 페이지에서 말이죠.

건너뛰기 링크는 스크린 리더를 사용하는 시각 장애인에게도 물론 유용하지만, 키보드로만 서핑하는 환경의 사용자들에게도 반드시 필요한 요소입니다.

KWCAG 2.0 에서는 이러한 부분이 적용되었습니다.

얼마전(2009년 12월 22일)에 KWCAG 2.0 이 제정되었습니다. KWCAG 2.0 에서는 이 부분을 명확하게 다루고 있습니다. 올바른 적용의 예로 아래와 같은 경우들을 들고 있습니다.

• 메뉴를 건너뛸 수 있게 건너뛰기 링크를 제공한 경우
• 화면에 보이지 않지만 키보드로 접근하면 펼쳐지는 메뉴 건너뛰기 링크를 제공한 경우
• 메뉴를 건너뛸 수 있게 건너뛰기 링크를 화면상에 제공한 경우

반복적인 내비게이션 링크(본문 바로가기 등)를 숨기지 않고 화면상에 제공하는 것이 가장 바람직함

개인적으로는 “화면에 보이지 않지만 키보드로 접근하면 펼쳐지는 메뉴 건너뛰기 링크를 제공한 경우” 가 가장 바람직하다고 생각하는데 지침에서는 “건너뛰기 링크를 화면상에 제공한 경우”를 가장 바람직하다고 하네요.

건너뛰기 링크를 화면에 표시하는 건 위에서도 언급했지만 화면은 인식하지만 키보드만으로 서핑하는 환경의 사용자에 대한 배려일겁니다. 그런데, “건너뛰기 링크를 화면상에 제공한 경우” 특히, 이를 이미지로 제공한 경우 포커스가 갔을 때 식별하기가 쉽지 않습니다.

정지화면에서는 식별이 쉽지만, 키보드 이동중에는 주위 깊에 봐야 식별 가능합니다.

거기다가 건너뛰기 링크가 디자인 요소가 되어 버립니다. 마우스를 사용하는 사용자는 사용하지도 않는데 말이죠. 결국, 없어도 되는게 화면에 자리를 차지 하게 됩니다. 그래서 저는 일반적인 화면에서는 보이지 않지만 키보드로 접근했을 때 건너뛰기 링크가 표시되도록 하는 방법이 더욱 바람직하다고 생각합니다. 화면에 표시하는 방법이 틀렸다는게 아니라 굳이 나은걸 따지자면 숨겼다가 표시하는 쪽이 낫다는겁니다. “둘 다 좋지만 후자가 조금 더 좋다… 고 생각한다.” 입니다.

어떻게 구현하나

http://www.webstandards.org/ 사이트에 가셔서 TAB키로 페이지 접근해 보면 “skip to content” 링크가 나타납니다. (신현석님이 댓글로 정보를 주셨습니다.)

그리고, 제 블로그에서도 사용하고 있었(!)습니다. 이 포스트를 작성하기전에 테스트 해보느라 넣어봤습니다.

"양군팩토리"에 사용된 건너뛰기 링크. 포커스를 받으면 표시됩니다.

HTML은 BODY 태그 바로 다음에 아래와 같은 코드를 추가합니다.

<a href="#main" class="skip-navi">본문으로 바로가기</a>

CSS 는 다음과 같습니다.

/* 처음에는 숨깁니다. for-reader 등의 스크린리더를 위한 공통의 class를 사용해도 좋을것같습니다.*/
a.skip-navi {
display: block;
position:absolute;
top:0;
left:-2000px;
}

/* 포커스를 받으면 화면 좌상단에 표시합니다. 식별하기 좋게 말이죠 */
a.skip-navi:hover, a.skip-navi:focus {
left:0%;
width:200px;
padding: 10px;
background: #FFFFCC;
border:1px dotted #FF9900;
color: #990000;
text-align:center;
font-size:1.3em;
}

본문으로 건너 뛰면 그만 ?

보통의 홈페이지 레이아웃

보통의 홈페이지들은 위와같은 레이아웃을 가집니다.

1. 헤더: 로고, 메인메뉴와 그 하위 메뉴 목록, 검색, 유틸 메뉴 …
2. 서브메뉴: 현재 페이지의 이웃 혹은 하위 메뉴 …
3. 콘텐츠 영역: 웹 어플리케이션 혹은 콘텐츠 …
4. 사이드바: 퀵 링크, 관련 메뉴, 위젯 …
5. 풋터: 퀵 링크, 저작권, 연락처 …

건너뛰기 링크는 위에서 1번과 2번 영역을 건너뛰게 해줍니다. 바로 3번으로 접근하도록 해주죠. 하지만, 3번 영역의 콘텐츠를 모두 사용한 다음은 어떨까요 ? 콘텐츠를 모두 읽은 후에 다른 페이지로 이동 하려면 ? 네, 다시 TAB을 연타한 후  다시 페이지 처음으로 돌아가 메뉴를 뒤져야 합니다. 위의 사이트 (웹 접근성 연구소) 처럼 4번(사이드바) 다음에 “위로가기” 링크(헤더로 이동)를 제공하면 그나마 낫습니다. 지금까지 봐온 바로는 보통 4번 (사이드바)을 플로팅 시키기 위해서 4번(사이드바)과 5번(풋터)의 순서를 바꿔서 마크업 하고, 4번과 5번에 또 수십게의 링크가 존재하기도 합니다. 상단에 “본문 바로가기” 건너뛰기 링크를 제공한 의미가 퇴색됩니다.

그래서 저는 본문 콘텐츠가 끝나고 나서 바로 다시 한번 건너뛰기 링크를 제공하는게 어떤가 하고 제안합니다.  사이드바, 풋터 역시 매 페이지마다 반복되는 “반복 영역”이기 때문에 이를 건너뛰기 위한 수단이 필요한게 아닌가 하고 말이죠. 게시판과 같은 경우에야 목록에서 게시물 선택 해 조회하고 다시 “목록”등의 버튼을 눌러 페이지간 이동이 용이하지만, 단순 콘텐츠의 경우에는 콘텐츠가 끝나는 지점에 “메뉴로 가기”, “사이트 맵 바로가기” 등과 같이 다른 페이지로 이동할 수 있는 기능을 제공하는 곳으로의 건너뛰기 링크를 제공하면 어떨까 합니다.

생각이 변했습니다. 이 의견도 나쁘지는 않지만 하단에 추가된 내용이 더 낫다고 생각해 본래 내용은 희미하게 처리합니다.

추가 [2010-01-19 10:45]

위에서 “본문 콘텐츠 바로 뒤에 하단의 반복 영역을 건너 뛸 수 있는 건너뛰기 링크를 제공하는게 어떤가” 하고 말씀 드렸습니다.

이에, 성민장군님께서 “사용자 스스로 상단으로 이동할 수 있으므로, 콘텐츠 뒤로 이어지는 하단에 반복되는 링크를 건너뛰는 링크는 필요없다.” 라는 말씀을 댓글로 남겨주셨습니다.

포스트 당시에도 ‘사용자가 맨 위로 이동이 안되는가 ?’ 생각했었는데, 제가 알고 있는대로 PageUp 키를 눌러서 화면을 올릴 수는 있지만 실제 포커스를 옮길 수는 없다고 판단해 위와 같은 글을 작성했습니다.

그런데, 시각장애인이 사용하는 스크린리더에는 그런 기능이 있었네요 가상커서 모드에서 Ctrl + Home 키를 누르면 문서 처음으로 이동할 수 있습니다. 그렇다면 키보드만 사용하는 환경에서는 ? 이라는 의문을 가졌지만 이도 방법이 있습니다.

firefox 에서의 설정

IE 에서의 설정

보시는 것 처럼 Firefox, IE 에서는 접근성 설정을 제공하는데, 각각 “커서키를 항상 페이지 내에서 사용”과 “새 창과 탭에서 커서 브라우징 사용” 옵션을 활성화 하면 스크린리더의 가상커서 모드처럼 Ctrl + Home 키를 이용해 문서 처음으로 이동할 수 있었습니다.

스크린 리더와 브라우저에서 페이지의 상단으로 이동할 수 있는 기능을 제공하고 있으므로 성민장군님 말씀대로 콘텐츠 뒤에 다시 건너뛰기 링크를 제공하는것은 “과한 배려”가 되는게 맞겠네요. (브라우저에서 제공하는 기능을 웹 페이지에서 중복 제공하는 건 ‘의미없다’라는게 제 생각이기에 … 확대,축소, 인쇄 같은거..)

그런데, 이러한 브라우저의 기능을 사용자들이 실제로 얼마나 알고있을지에 대해서는 여전히 회의적입니다. 이제는 웹 접근성 개선 활동에 “사용자 교육” 부분도 비중을 둬야 하지 않나 하는 생각이 듭니다.

관련 지침

• [KWCAG 2.0] 2.4.1 (반복 영역 건너뛰기) 콘텐츠의 반복되는영역은 건너뛸 수 있어야 한다.

덧1) 글을 작성하는 중간에 “임시저장” 한다는게 그만, 발행이 되어 버렸네요. RSS로 어떻게 나갔는지 모르겠지만 다 적지 않은 글이 그대로 나갔다면 구독중이신 분들에게 사과의 말씀 드리겠습니다. 죄송합니다. 꾸벅.

덧2) 반성합니다. 위의 내용은 새롭제 제정된 KWCAG2.0 을 보면서 생각한겁니다. 평소 사이트 작업하면서 저렇게 해오지는 못했습니다. 다음번 프로젝트에서 코딩할 기회가 된다면 적용하고 소개해 보도록 하겠습니다.

이런겁니다. 콤보박스가 나오고 목록에서 항목을 선택하면 새창으로 해당 사이트가 열립니다. 코드는 아래와 같습니다.

<!-- 코드 #1 -->
<p>
관련 사이트 바로가기
<select onchange="if(this.value != '') window.open(this.value);">
<option value="">관련사이트 목록</option>
<option value="http://twitter.com/yangkun7">양군의 트위터</option>
<option value="http://picasaweb.google.com/yangkun7">건이네 웹앨범</option>
<option value="http://www.greenfarm.pe.kr/">푸른농장 (준혁,서영이네)</option>
</select>
</p>

#1. 문제점

• SELECT 양식에 대한 설명이 필요합니다 . (KWCAG 1.0 항목 3.3 온라인 서식 구성)
• 키보드만 이용할 때, 해당 컨트롤로 포커스가 이동하고 이동 키(↓↑)를 이용해 그 목록을 보려 하면 바로 첫 번째 항목의 사이트로 이동해 버립니다. (KWCAG 1.0 항목 2.4 키보드로만 운용 가능)

#1. 개선

1. SELECT 양식에 대한 LABEL 추가
2. onchange 이벤트 제거
3. [이동] 버튼 추가
4. [이동] 버튼 클릭 시 해당 사이트로 이동하도록 변경.

개선된 코드는 다음과 같습니다.

<!-- 코드 #2 -->
<p>
<label for="relSites">관련사이트 바로가기<label>
<select id="relSites">
<option value="">관련사이트목록</option>
<option value="http://twitter.com/yangkun7">양군의 트위터</option>
<option value="http://picasaweb.google.com/yangkun7">건이네 웹앨범</option>
<option value="http://www.greenfarm.pe.kr/">푸른농장 (준혁,서영이네)</option>
</select>
<input type="button" value="이동" onclick="window.open(document.getElementById('relSites').value);"/>
</p>

#2. 문제점

여전히 문제가 남아 있습니다.

• 자바스크립트가 지원되지 않는 환경에서는 위의 기능을 사용할 수 없습니다. (KWCAG 1.0 항목 4.1 신기술의 사용)

#2. 개선

1. SELECT 양식 값을 전달할 수 있도록 FORM 삽입
2. SELECT 양식에 name 설정
3. SELECT 양식 값을 전달할 수 있도록 일반 버튼을 submi 버튼으로 변경
4. 전달받은 URL로 이동할 수 있는 서버측 로직 구성

개선된 코드

<!-- 코드 #3 -->
<p>
<form action="redirect.php" method="post" target="_blank">
<label for="relSites">관련사이트 바로가기<label>
<select id="relSites" name="url">
<option value="http://twitter.com/yangkun7">양군의 트위터</option>
<option value="http://picasaweb.google.com/yangkun7">건이네 웹앨범</option>
<option value="http://www.greenfarm.pe.kr/">푸른농장 (준혁,서영이네)</option>
</select>
<input type="submit" value="이동"/>
</form>
</p>

서버측 코드

<?php
// redirect.php
// 필요하면 카운팅 로직 추가
header('Location: ' . $_POST['url']);
?>

개선점

#3의 코드는 그대로 완벽한 것 같지만 개선의 여지가 남아 있습니다.

• 코드대로 실행하면 선택한 사이트가 새창으로 열리게 되는데 이에 대해 알리는 부분이 없습니다. (KWCAG 1.0 항목 2.6 반응시간의 조절기능)
• 자바스크립트가 사용 가능한 환경에서는 굳이 서버 로직을 거치지 않고 선택한 사이트로 이동하게 하고 싶을 수도 있습니다.

최종 개선 코드

<!-- 코드 #4 -->
<script type="text/javascript">
function gotoUrl(id) {
window.open(document.getElementById(id).value);
return false;
}
</script>
<p>
<form action="redirect.php" method="post" target="_blank" onsubmit="return gotoUrl('relSites');">
<label for="relSites">관련사이트 바로가기<label>
<select id="relSites" name="url">
<option value="http://twitter.com/yangkun7">양군의 트위터</option>
<option value="http://picasaweb.google.com/yangkun7">건이네 웹앨범</option>
<option value="http://www.greenfarm.pe.kr/">푸른농장 (준혁,서영이네)</option>
</select>
<input type="image" src="btn_move.gif" alt="이동 (새창)"/>
</form>
</p>

관련 지침

• (키보드 사용 보장) 모든 기능은 키보드만으로도 사용할 수 있어야 한다.

HTML Validator 를 통과하지 못했습니다. (본 블로그는 xhtml, css 2.1 을 준수하고 있습니다. -_-a)

유트브영상 삽입 하나로 9개의 HTML Validator 오류가 ...

유트브에서 제공한 코드는 다음과 같습니다.

<object width="425" height="344">
<param name="movie" value="http://www.youtube.com/v/39a1jzuqGGQ&amp;amp;hl=ko_KR&amp;amp;fs=1&amp;amp;rel=0"></param>
<param name="allowFullScreen" value="true"></param>
<param name="allowscriptaccess" value="always"></param>
<embed src="http://www.youtube.com/v/39a1jzuqGGQ&amp;amp;hl=ko_KR&amp;amp;fs=1&amp;amp;rel=0" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="344"></embed>
</object>

웹 표준

위의 코드는 HTML4에서 폐기된 EMBED 태그를 사용하기 때문에 오류로 인식되며, 더불어 태그에 포함된 type, width, height 등의 모든 속성이 오류로 인식됩니다.

그렇다고 EMBED 태그를 제거하면 OBJECT 태그의 classid 와 몇몇 이유 때문에 파이어폭스에서는 재생되지 않는 문제가 생깁니다.

아래와 같은 태그를 사용하면 모든 브라우저에서 동일한 플래시 영상을 표시할 수 있습니다.

<object type="application/x-shockwave-flash" width="425" data="플래시 url" height="344">
<param name="movie" value="플래시 url" />
</object>

ie6,ie7,ie8,chrominum 4,firefox 3.5,opera 10,safai 4 에서 테스트했습니다.

웹 접근성

플래시는 웹 접근성 관련해서 아래와 같은 제약이 존재합니다.

• 플래시 요소에 대체 텍스트 제공이 녹녹치 않습니다. accessibility 패널을 이용해 대체 텍스트와 탭 순서 제공이 가능하지만 이는 스테이지에 보이는 요소에 한정되며, 대부분의 네비게이션이 액션스크립트에의해 생성 되는걸 고려하면 좀 … 복잡해집니다.
• IE외의 브라우저에서 키보드로 접근이 힘듭니다. (tabindex=”0″ 을 주는 편법이 있다고 하지만, 꽁수는 꽁수.)
• 키보드 접근을 허용하려면 플래시의 윈도우 모드를 window로 설정해햐 합니다.
• 플래시 플러그인이 없는 환경을 고려해 플래시 외부에 대체 텍스트를 제공해야 합니다.
• 미래에는 어떨지 모르지만, 현재는 검색엔진이 플래시의 텍스트를 인덱싱 하지 못합니다. (혹시 있나요 ?)
• 페이지가 확~ 무거워져요.

반드시, 플래시 사용을 해야 한다면 위의 사항들을 고려해야 합니다. (쉽지 않아요. ㅠㅠ)

그래서, 웹 접근성 까지 고려 한다면 플래시 자체의 접근성을 확보한 후 아래의 태그를 사용합니다.

<object type="application/x-shockwave-flash" width="425" data="플래시 url" height="344">
<param name="movie" value="플래시 url" />
<p>대체 텍스트... <a href="플래시 플레이어 얻기 링크"><img src="플래시 플레이어 얻기" width="" height="" alt=""/></a></p>
</object>

(워드 프레스에서는 위와 같이 작성한 경우 P 태그를 임의로 조정해 <p></object></p> 와 같은 코드를 만들어버리네요 ㅠㅠ)

하지만,  위의 경우 IE에서 플래시 무비가 모두 다운로드 되기 전까지 플래시 플레이어가 보이지 않습니다. 이러한 문제를 피하기 위해서는 힉시 메소드를 사용하거나 A List Apart 에서 제안하는 Flash Satay 방법을 사용합니다.

힉시 메소드 (IE 의 condition comment 를 이용합니다.)

<object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://fpdownload.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=7,0,0,0" width="160" height="75" id="a" align="middle">
<param name="movie" value="플래시 url" />
<!-- Hixie method -->
<!--[if !IE]> < -->
</object><object type="application/x-shockwave-flash" data="플래시 url" width="160" height="75">
<param name="movie" value="플래시 url" />
<p>대체 텍스트</p>
</object>
<!--> < ![endif]-->

이 방법은 정보화진흥원에 접근성 교육 받으면서 성민장군님에게서 들었습니다. (꾸벅 ^^)

Flash Satay (container.swf 에서 원래의 플래시 무비를 loadMovie를 이용해 로드 합니다.)

<object type="application/x-shockwave-flash data="container.swf?path=플래시 url"  width="400" height="300">
<param name="movie" value="container.swf?path=플래시 url" />
<p>대체 텍스트</p>
</object>

Flash Satay 방법의 경우 URL이 꼬이는 수가 있습니다. 결국, 가장 쉬운 방법은 코드를 더 적어야 하긴 하지만 힉시 메소드가 아직은 제일 낫네요.

생각해보세요 위의 플래시가 사이트의 주요 네비게이션 용도로 사용된다면 플래시 자체 접근성도 확보해야 하고 “대체 텍스트”부분에 ul, li 등을 이용해 동일한 네비게이션을 제공해야 합니다. 것 보세요, 쉽지 않죠. 플래시는 자제, 자제…

제목만 봐서는 “웹 표준, 웹 접근성 모두를 만족하는 사이트 개선 작업이 필요하다.” 라는 내용으로 예상할 수 있습니다. 하지만 내용에서는 그 내용을 잠깐 언급할 뿐 “갈 길 먼 웹 접근성” 관련 이슈 몇 가지를 다루고 있습니다.

명확하고 효과적인 처벌 필요

위반 사실이 밝혀진 뒤에야 개선해도 되는 이른바 ‘네거티브’ 방식이어서 실효성도 떨어진다. 김종욱 한국장애인인권포럼 실장은 “과태료로 한정한 처벌 규정이 약하다. 현행 법으로는 시정명령·권고를 받고 난 뒤 개선해도 돼 준수 의지가 낮은 게 사실”이라고 주장했다.

제 생각은 다릅니다. 현재 웹 접근성 준수 성적이 낮은것은 처벌 규정이 약해서가 아니라 해당 기사 머리에서도 다루고 있지만 그 효과에 대한 인식과 사회적인 공감대 형성 부족이 원인이지 않을까 합니다. 즉, 명확하고 효과적인 처벌 전에 자발적으로 준수 할 수 있는 제도를 마련하고 더불어 웹 접근성 준수 여부를 따지는 명확한 기준 확립이 먼저라고 생각합니다. 그렇지 않고 처벌만을 강조 한다면 기사에서도 언급하고 있는 “무늬만 웹 접근성 준수” 사이트를 양성하게 되지 않을 까 합니다.

ActiveX

정부가 추진 중인 웹 표준화 사업과 웹 접근성 개선 사업에서 상충하는 솔루션 구축 기준의 교통정리가 필요하다. 웹 접근성 기준은 마이크로소프트(MS)의 액티브X 사용을 금하지만, 웹 표준은 이를 사실상 허용했다.

이 부분은 기사 내용이 잘못됐습니다. 기사와는 반대로 웹 접근성 기준에서는 ActiveX 자체가 접근성을 제공하거나 대체 수단이 있다면 ActiveX를 허용하고 있으며 웹 표준(호환성에 포함된)의 기준에서는 허용하지 않습니다. 기준이 맞다고 생각되는게 접근성 관점에서는 장애가 있음에도 웹 사이트의 모든 정보를 활용하거나 기능을 사용할 수 있도록 하는게 그 목적이기 때문에 그게  ActiveX 가 됐든 뭐가 됐든 보조 기기등을 이용해 접근이 가능하고 사용이 가능하면 그만인겁니다. 하지만 상호 호환성 관점에서는 다양한 플랫폼, 다양한 브라우저에서 웹 사이트의 모든 정보를 활용하고 기능을 사용할 수 있어야 하는데 ActiveX는 윈도우즈의 IE에서만 구동 가능하기 때문에 이는 호환성에 대치됩니다. 위 기사는 정부에서 실시 되고 있는 “전자정부 웹표준 강화 대책”을 말하는 것 같은데 웹 표준에서 이를 허용한게 아니고 대체 제품 사용을 권하고 있습니다. 가능한 경우 말이죠… 뭐, 결국 허용한거네요. 하지만, 진정 웹 표준은 그렇지 않다는거죠.

품질마크 인증제도

인증마크는 웹 접근성을 준수하는 기준에 불과할 뿐 ‘인증 획득=장차법 준수’라는 등식은 성립하지 않는다. 한국정보화진흥원 관계자는 “장차법 준수와 웹 접근성 인증 마크 획득은 별개 문제다. 웹 접근성 품질을 높였을 뿐 웹 접근성을 100%로 준수했다고 볼 수 없다”고 말했다.

이 부분이 좀 놀랍습니다. 인증 획득은 장차법 준수라고 생각하고 있었거든요. 사실, 개인적으로 인증 마크를 획득한 사이트들을 둘러보면서 웹 접근성 지침을 준수 하지 않은 부분을 보며 인증 마크에 대한 회의를 가지고 있었습니다만, 그건 심사에 관련한 것이었지 인증 마크에 대한건 아니었습니다. 정보화진흥원에서 제정하고 국가에서 표준으로 정한 지침을 준수하는지를 평가해 발부하는 인증 마크 획득이 장차법 준수를 의미하지 않는다면, 장차법 준수의 기준은 어디서 찾을 수 있나요 ? 표준 지침 제정 기관에서도 웹접근성 100% 준수 사이트를 가려내기가 쉽지 않음을 인정하는 상황에서 “명확하고 효율적인 처벌”은 더욱 힘들지 않을까 생각됩니다.

“웹 접근성 품질을 높였을 뿐” 이라는 말은 도저히 이해가 안되네요. 해당 사이트가 예전과는 다르게 웹 접근성 품질이 높아졌다는건가요 ? 심사할 때 예전 사이트를 함께 보는건 아닐테니 그건 아닌것 같고, 그렇다면 국내의 전체적인 웹 접근성 품질을 높였다는 건가요 ? 무슨 말입니까 ?

웹 접근성 품질마크란 ?

적어도 일정 비용을 받으면서 웹 접근성 준수 여부에 대해서 심사를 하고 품질 인증 마크를 발부했다면 해당 사이트의 웹 접근성 준수에 대해서 만큼은 인증 마크 발부 기관에서도 같이 책임을 져야 하는게 아닌지요. 심지어 정보화진흥원에서는 인증 마크를 획득한 사이트들에 대해서 정기적으로 모니터링을 하고 마크 획득 이후에 접근성이 준수 되지 않는다면 발부한 마크를 회수하는 제도도 마련해 놓고 있는데 말이죠. 안타깝습니다.

네, 웹 접근성 갈 길이 멀군요.

(정정 : 2010-01-07 12:02)

신현석님께서 품질마크 심사 비용이 무료임을 알려주셨습니다.

현재 웹접근성 연구소 홈페이지 품질마크 개요 페이지에

인증 심사료 및 품질마크 사용료: 무료(’09년 현재)

라고 명시되어 있습니다. 그러니 위에 “일정 비용을 받으면서” 는 틀린 내용입니다.
다만, 무료라는 점이 인증 마크 발부에 대한 책임을 피할 수 있는 장치라고 생각하고 있지는 않기를 바랍니다.

이러닝 콘텐츠들은 그 품질을 인증 받기위해 이러닝 품질관리센터 로부터 “품질인증”을 받고 있는데 이 기준에 접근성 항목을 포함시키는 방안을 검토중이라는 내용입니다.

장애인이나 고령자가 이용하기 어려운 국내 이러닝 콘텐츠의 접근성을 개선하기 위한 작업이 다양하게 추진된다.
한국교육학술정보원은 장애인이 불편 없이 이러닝 콘텐츠와 서비스를 이용할 수 있도록 하기 위해 이러닝 품질인증 기준과 가이드라인에 접근성 항목을 포함시키는 방안을 검토하기 시작했다고 4일 밝혔다.

굉장히 반가운 소식입니다. 웹 사이트와 관련해서는 2005년에 “웹 콘텐츠 접근성 지침”이 국가 표준으로 승인되고,  2009년 부터는 “지자체 정보화 평가”지표에 웹 접근성 보장 정도가 포함되어 지자체 별로 웹 접근성 개선 사업이 진행중인것으로 알고있습니다. 하지만 이미 납품되어 공공 기관 웹사이트에서 제공되고 있는 이러닝 콘텐츠들에 대해서는 제작 업체가 아닌 이상 접근성을 보장하기가 역부족이기에 해당 콘텐츠를 다루는 공공기관의 웹 사이트 자체에서 아무리 웹 접근성을 보장해도 실제로 장애인들이 콘텐츠를 이용할 수 없기 때문에 이는 하나마나한 단순 “액션”에 불과했습니다.

실제로, 어떤 기관에서는 웹 접근성 개선 사업을 진행하면서 방대한 이러닝 콘텐츠(동영상)를 어쩌지 못해 일부만 그 대본을 제공하고 나머지는 평가 기간 동안 사이트에서 내리기도 했다고 하니… 기 구축된 이러닝 콘텐츠가 웹 접근성 제공 관점에서 골치이긴 합니다.

부디 긍정적인 방향으로 검토가 이루어져 이러닝 콘텐츠도 접근성을 보장하고 이를 담는 웹 사이트도 접근성을 보장해 상호간 시너지 효과를 발휘해 장애인들에게도 교육 콘텐츠의 혜택이 골고루 돌아가는 계기가 되었으면 좋겠습니다.

더불어, 앞으로 교육 부분에서 많은 콘텐츠들이 디지털 화 (디지털 교과서 등) 될 것 같은데, 이 부분에서도 접근성이 충분히 고려되어 특히 교육 콘텐츠에 대해서는 장애인들이 정보에 접근하지 못해 받는 불이익은 없어야 할 것입니다.

국어문화원은 “인터넷 강국이라고 자부하는 우리가 한국 정부 기관의 홈페이지에 접속하여 입력하는데 영문이 적히는 상황은 결코 용납할 수 없는 언어 주권의 문제”라며 “앞으로 우리나라 국민을 대상으로 하여 운영하는 모든 사이트의 검색창·입력창 초기 상태가 한글로 바뀌도록 노력할 계획”이라고 밝혔다.

예전에 기관 프로젝트를 진행할 때에도 유사한 요청을 받은 적이 있습니다. 가입 혹은 로그인 시에 “성명”란은 할글을, “아이디” 란은 영문 입력모드를 자동으로 변경되도록 해달라는것이었습니다. 기술적 문제, 인터페이스의 일관성 문제, 사용성 문제를 들어 거부했었는데 국어문화원은 같은 요구사항을 기관들을 상대로 하고있네요.

해당 요구사항을 만족 시키는것은 기술적으로 쉽지 않습니다. IME 자체가 Windows, Linux, Mac 등의 플랫폼에 의존하기 때문에 모두를 만족시키기기는 쉽지않습니다. 간단하게 스타일을 적용시켜 해결된다고 하시는 블로거도 있는데 해당 스타일은 Internet Explorer 전용이라 Firefox (Firefox3 에서는 지원한다고 했었지만 국어문화원 테스트 결과 제대로 동작하지 않는것 같습니다.), Safari 등의 타 브라우저에서는 의도한대로 동작하지 않습니다. 특정 브라우저에서만 동작하는 기능이라면 사이트의 사용 일관성이 떨어지겠죠. 무엇보다 사용성의 문제가 있습니다. 대부분의 사용자들은 현재 자신의 입력모드가 입력창에 반영될것으로 기대합니다. 그리고, 많은 사용자가 현재 자신의 입력모드를 기억하고 있습니다. 그런데 시스템에서 입력창의 입력모드를 고정 해버리면 혼란이 생길겁니다. 이런 경우에 오히려 입력창 옆에 안내 문구를 달아야 할지도 모릅니다. “이 입력창은 자동으로 한글입력모드로 전환됩니다.” 라고 말이죠.

입력모드 고정 기능은 인트라넷과 같이 특정 사용자층을 겨냥하고 있으며, 사용자들이 해당 기능에 대해서 숙지하고 있는 경우에는 유용하겠지만, 그렇지 않은 경우에는 불편함을 초래하거나 심지어 불쾌감을 줄 수 있습니다. 그러니 국어문화원의 검색창, 입력창의 초기 상태를 한글로 바꾸려는 운동은 중단하시는게 나을것 같습니다.

그나저나, 국어문화원의 “언어 주권” 운운하는 부분은 오버가 심한것 같습니다. 차라리 국립국어원의 예 처럼 첫 페이지를 “Home”, “홈”, “Main”, “메인” 대신 “첫 화면” 으로 바꾸자는 운동이라면 좀 낫겠습니다만…

덧) 제 경우에는 습관적으로 한글 입력이 끝나면 바로 한/영 전환키를 눌러 영문 모드를 유지합니다. 일부 어플리케이션들에서는 한글 마지막 글자가 영문 모드로 전환되야 입력이 끝나는 경우가 있어서 말이죠. 그리고 주로 코딩을 하다보니 자연히 그런 습관이 된 것 같습니다. 그런데 국어문화원의 주장대로 입력창이 변경된다면 입력창에 포커스를 주고 한글을 쓰기 위해 한/영 전환키 누르고 입력할 경우 영문이 나오게 되겠네요.. 불편합니다 !! 비슷하게 아래아 한글 이나 오피스의 자동고침 기능도 IME 모드를 강제 변경해버려서 제 경우에는 정말 불편합니다.