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 등을 이용해 동일한 네비게이션을 제공해야 합니다. 것 보세요, 쉽지 않죠. 플래시는 자제, 자제…

NARADESIGN:BLOG 에 같은분이  HTML 어떻게 읽는것이 좋을까? 라는 포스트를 발행하셨네요.

이에 대해 “내 맘대로 보는 세상” 을 운영하시는 정태영님 께서는 RE: HTML 어떻게 읽는것이 좋을까? 라는 포스트로 다른 생각을 전하고 있습니다.

저역시, HTML 어떻게 읽는것이 좋을까? 라는 포스트에 트래백을 걸 요량으로 이글을 작성합니다.

일단, naradesign 님은  DIV 태그에 대해서 ‘디비전’이라 읽어야 한다는 이유로

1. ‘디브’라 읽는것은 듣기가 좀 그렇다(?)
2. 비전전문가가 들었을 때 그 의미와 용도를 쉽게 이해할 수 있다.

정도로 들고 있습니다. 1번이야 개인 취향이니 별 이유가 되지 못합니다. 뭐, 동료나 부하 직원들에게는 압박할 수 있는 이유가 되긴 하겠군요.

2번의 이유가 납득이 안갑니다.

일단, 비전문가(HTML을 전혀 모르는)에게 태그 이름을 직접 열거하면서 뭔가 설명하고 있다면, 설명이 잘못 되었다고 생각합니다. 실제로 그런 상황이 있을지도 모르겠고요. 설사, 태그 이름을 직접 거론하면서 설명을 한다쳐도 “디비전 태그”라는 말을 듣고 영어를 알고 있다면, “아, 뭔가를 나누는거구나” 정도로 이해할 수 있지 않겠나 싶습니다.  하지만, 실제 DIV 태그를 거론할 때에는 “뭔가를 나누는” 경우 외에도 많은 경우가 있을겁니다.  정태영님 말씀대로 “용어에 너무 익숙해진 전문가들의 착각” 일겁니다. 비전문가에게는 그가 이해할 수 있는 말들로 설명해야 할겁니다.

그리고 간과하고 계시는 부분이 있는데. HTML = English 라고 가정하신것 같은데. 당연히 알고 계시겠지만 HTML 은 영어로 표기하고는 있지만 Hyper Text Markup Language 입니다. 즉, 사람이 쓰고 브라우저가 이해하는 다른 언어인겁니다. naradesign님의 말씀 대로라면 영어를 주 언어로 사용하는 미국인들은 HTML 을 따로 배울 필요 없이 DIV 가 division 에서 왔다라는것만 알아도 슥슥~ HTML 코드를 만들어내겠네요. 그렇지 않잖아요. 유래한 단어의 뜻은 알지라도 그 의미나 용법이 완전히 다르잖아요. 결국 새로운 언어이기 때문에 새로 배워야 합니다. 물론, 교육 과정에서 DIV 는 division, ABBR 은 abbreviation의 줄임말이다 라는것을 알려주면 교육 효과가 상승하는 이점은 있겠지만 그렇다고 그게 DIV 태그를 ‘디비전’이라고 읽어야할 이유가 되지는 않는다고 생각합니다. 게다가, 여기는 주변에 영어 사용을 꺼리는 사람도 많은 “한국”이잖아요.

(추가로, 위의 교육방법은 미국이나 우리나라의 대학 정도에서 효과가 있으면 있었지 우리나라의 나머지 대상들에게는 역효과가 있지 않을까요 ? 말씀대로 누구나 쉽게 배울 수 있는 HTML 을 지향하는데 “ABBR 은 abbreviation에서 왔으면 발음은 ‘어브리비에이션’ 입니다. 용도는 …..” 영어 공부도 같이해야 하는 상황이 될 것 같네요. 거리가 더 멀어집니다.)

요컨데, HTML 은 영어가 아닌 다른 언어입니다. 그 시작에서 읽는 방법이 명시되지 않았다면 의사소통이 가능한 범위 안에서 자유롭게 읽을 수 있다는게 제 생각입니다. 미쿡에서도 그렇게 하고 있을거라 감히 예상하고요. 그래서 현재 작업하고 계시는 HTML 의”권장 표현”은 주로 커뮤니케이션 하시는 사내에서 하시는게 적당할거라고 생각합니다. “여러가지 읽는 방법”으로 변경해, 다양하게 읽히고 있는 발음들을 모으시는게 더 유의미 하지 않나 생각합니다.

덧)

HTML 도 HTML이지만, 아스키 기호들은 어떻게 읽고 계신지 궁금합니다. 저는 이부분이 더 혼란스러운 것 같아요.

아래는 아스키 기호들에 대해 지금까지 들어봤던 표현들을 묶어 봤습니다. 여러분은 어떻게 읽으시나요 ?

• |  : 수직 바, 오어, v-bar, vertical var, 원 표시 위에꺼 (전화상으로 듣고 오호~), 파이프 (정태영님 제보)
• & : 앤드, 앰퍼샌드, 눈사람 (귀엽죠), 앰프 (&amp; 를 아시는분)
• * : 별표, 별, 아스타리스크, 와일드카드
• < : 꺽쇠, 여는 꺽쇠, 꺽쇠 열고, 엘티 (오~ &lt; 이거 알어…)
• > : 꺽쇠, 닫는 꺽쇠, 꺽쇠 닫고, 쥐티 (ㅋ)
• ~ : 물결, 틸드 (나만 이렇게 읽음)
• @ : 골뱅이, 앹
• ^ : 위 꺽쇠, 제곱 (–;)
• ” : 큰 따옴표, 더블퀕, 쿼테이션 마크
• : : 땡땡, 콜론
• # : 샾, 우물정 (옛날 컴퓨터 학원에서…)
• - : 다시, 대시, 하이픈
• _ : 밑줄, 언더바, 언더스코어
• ` : 물결 밑에꺼, 빽퀕 (얼마전에 찾아보고 알았음)

이런 아스키 코드 공식 명칭표가 있나요 ?

참고로 정태영님께서 링크 걸어주신 프로그래밍에 쓰이는 영단어와 발음 문제. 쓰레드도 죽~ 보면 참고가 될것 같습니다.
※ database : 다타바세 (압권이군요 ㅎㅎ)

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

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

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

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

ActiveX

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

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

품질마크 인증제도

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

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

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

웹 접근성 품질마크란 ?

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

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

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

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

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

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

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

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

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

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

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

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

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

현재 W3C 의 CSS Validator 에는 버그가 있습니다. 사용에 주의를 요합니다.

버그 내용

아래와 같은 CSS 구문을 입력해 검사를 해보면

#someElement {
background: url(images/img.png) no-repeat center;
}

잘못된 값 : background 해석 오류 [empty string] 이라는 오류를 보실 수 있습니다.

CSS Validator 에서 오류가 아닌 항목을 오류로 판단하고 있습니다.

마지막 background-position 부분에서 값을 하나 생략하는 경우 이와 같이 해석 오류를 보고 하고 있습니다.

CSS 2.1 스펙

CSS 2.1 Specification – background-position

하지만 이 구문은 링크에서 보시는 것 처럼 CSS 2.1 표준에 부합하는 구문이며, 심지어 스펙에서 제공하는 예제 조차 CSS-Validator는 오류를 보고 하고 있습니다.

이 문제는 W3C 의 버그 리포트에도 등록된 상태 입니다. (상태는 NEW ;;)

해법

1. 처음 제시한 구문을 아래 처럼 값 2개를 모두 명시하도록 수정 하거나

#someElement {
background: url(images/img.png) no-repeat center center;
}

2. http://qa-dev.w3.org:8001/css-validator/ 를 이용해서 점검하면 위의 오류를 피할 수 있습니다.

(사족)

# 너무 오랜만에 블로그에 글을 써서 그런지 시간이 굉장히 오래 걸렸습니다. (미리보기를 몇번이나 확인 하는지 ;;)

# 이래서야 2009년에 그랬던 것처럼 블로깅 하기가 꺼려질텐데 … 좀 가볍게 임해야겠습니다.

업데이트 목록

• 디렉토리 창에서 이전에 방문한 폴더 아이콘을 유지함.
• 반복 재생 도구모음 단추 추가.
• 자동 실행 사용자 도구에서 키 입력 기록을 재생할 수 없던 문제 해결.
• -s 명령행 옵션 (구문 디렉토리).
• 창 목록과 디렉토리 창에서 Ctrl+A 키 허용.
• '웹 서버 루트 디렉토리' 옵션에서 https:// 허용
• 중첩된 주석 지원을 위한 #NESTED_COMMENT=y 구문 파일 선언문.
• FTP 업로드를 취소할 때 프로그램이 다운될 수 있던 버그 수정.
• 찾기 대화상자에서 '다음 파일로 계속' 옵션 추가.
• 표식 있는 줄 색상 옵션 ('기본설정'->'색상')
• 최근 파일의 코드 생략 상태 기억.
• '빈 줄 지우기' 명령을 실행하면 프로그램이 다운될 수 있던 문제 해결.
• 패치 설치 시 윈도우 7 에서 경고메시지가 나올 수 있던 문제 해결.
• '문서'->'자동 완성' 옵션 도구모음 단추 추가.
• 최대 파일 종류 숫자를 50으로 늘임.
• 디렉토리 표시창에 수평 스크롤바 표시.
• 소리 끄기 옵션 ('기본 설정'->'일반').

뭐, 대부분 버그 수정입니다만 그 중에 개인적으로 반가운 업데이트가 있어 기쁜 마음에 몇가지 소개 드릴까 합니다.

디렉토리창 트리 모드 지원

꾸준히 (까지는 아니고 몇번) ES-Computing 에 메일로 요청을 했던 부분입니다.
저의 요청만으로 추가 된 기능은 아니겠지만, 제일 반가운 부분입니다.

 편해졌지요 ?

파일종류 선택의 추가옵션

에디트플러스는 Syntax Highlight, 자동 완성, 칸표식, 함수패턴, 들여쓰기 등을 파일종류 별로 설정할 수 있습니다. 이런 파일종류를 이전에는 파일의 확장자로만 지정할 수 있었는데 이번 업데이트 (언제 업데이트 된건지는 모르겠습니다. Change Log에서는 안보이네요) 에서 [추가옵션]을 지원하면서 다양하게 파일을 선택할 수 있도록 해줬습니다.

이제는 일일이 적용되는 모든 확장자를 나열할 필요없이 와일드 카드(*,?)를 사용해 선택할 수 있게 됐습니다. (박수~)
그리고 [파일 첫 줄] 옵션도 제공해 ruby, python,shell 등의 스크립트 언어도 확장자 상관없이 선택할 수 있게 됐습니다. (한번 더 박수~~)
#!/bin/sh 머 이런걸 지정해서 사용하면 유용할 듯 싶습니다. (아직 해보지는 못했습니다.)

표식 있는 줄 색상 옵션

에디트플러스는 줄 단위로 표식 지정을 지원합니다. 다른 에디터들의 "북마크"기능과 같습니다.
이전에는 그 표식의 인식을 좌측 Gutter 부분에 작은 네모 상자로만 했었는데요 이번의 업데이트를 통해 해당 줄의 색상을 설정가능하게 되어서 표식의 인식이 쉬워졌습니다.

이쁩니다~~ *^^*

외에도 반가운 업데이트 소식이 더 있지만 대충 개인적으로 반가운것들만 추려봤습니다.
아직 업데이트 못 하신 분들 얼렁얼렁 업데이트 하세요. 가볍게 [도움말 > 최신 버전 확인] 하시면 됩니다.

그리고 !! 아직도 정품이 아니신 분들 … 3만원입니다.

맺음

계속해서 업데이트 노력을 아끼지 않으시는 에디트플러스 개발자 분들에게 감사의 말씀드립니다.
화이팅 입니다.
 

edocr 이라는 사이트에서 여러 사용자들이 등록한 문서들중에 cheatsheet 태그가 붙은 문서들을 모아 보여주는 페이지입니다.

각종 cheatsheet (커닝페이퍼?) 들이 등록되어 있어서 유용하게 사용할 수 있을것 같습니다.
(cheatsheet 는 A4 한장으로 출력해 참조 할 수 있는 reference 정도로 볼 수 있겠습니다.)

포함하는 cheatsheet 로는 javascript, ruby, adobe AIR 등 다양합니다… 심지어 Twitter 까지 등록되어 있네요.

각각의 cheatsheet 의 상세보기는 FLASH PAPER 로 깔끔하게 보여주고 있습니다.

다운로드도 제공 하고 있는데요. 다운로드를 위해서는 edocr에 로그인한 후에 가능합니다.

MooTools cheatsheet

섭섭한건 MooTools cheatsheet 가 없네요…
그래서 !! 제가 찾아서 업어왔습니다. ^^
mediaVROG Blog 의 mootools 1.2 cheatsheet 에서 업어왔습니다.

MooTools 1.2 Basic Cheatsheet 다운로드