메뉴 건너 뛰기 링크란 하나의 웹 사이트에서 모든 페이지에 걸쳐 반복해서 등장하는 글로벌 네비게이션과 로컬 네비게이션을 건너 뛸 수 있는 링크를 말합니다. 마우스를 함께 사용하는 사람은 이 링크가 왜 필요한지 알기 어렵지만 키보드만으로 웹을 탐색하는 사람들에게는 상당히 중요한 의미를 갖습니다.

2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages. (Level A) 2.4.1 블럭 우회: 여러 웹 페이지에서 반복되는 콘텐츠 블럭을 우회할 수 있어야 한다. (수준 A)

WCAG 2.0 : 2.4.1

헤딩은 콘텐츠 블럭을 우회하는 가장 효과적인 방법

시각 장애인은 마우스 포인터를 볼 수 없기 때문에 키보드만으로 웹을 탐색을 합니다. 물론 Tab키와 방향키 만으로 탐색을 하는 것은 아닙니다. 화면 낭독 프로그램은 ‘링크만, 헤딩만’ 따로 모아서 탐색할 수 있고 특히 ‘링크’ 텍스트를 설명력 있게 제공하는 것도 당연히 좋지만 적절한 ‘헤딩’을 제공하는 것은 더더욱 중요합니다. 헤딩은 콘텐츠 블럭을 건너 뛸 수 있는 단서가 되기 때문이고 시각 장애인에게는 불필요한 콘텐츠를 잘 건너 뛰게 해주는 것이 매우 중요합니다. 시각이 있는 사람들도 자각하지 못하는 사이에 이미 불필요한 콘텐츠를 무시하는 것에 학습되어 있습니다. 눈에 잘 띄도록 만든 배너를 빠르게 무시하는 것은 방법이라기 보다 본능적인 반응에 가깝습니다. 헤딩은 콘텐츠 블럭을 우회하는 가장 효과적인 방법 입니다.

반복되는 콘텐츠 블럭을 우회하는 방법

콘텐츠와 콘텐츠 사이를 빠르게 건너뛰기 위하여 시각 장애인에게 헤딩(h1, h2, h3, h4, h5, h6) 정보가 중요하다는 사실을 말씀드렸습니다만 사실 오늘의 주제는 ‘메뉴 건너 뛰기’ 입니다. 메뉴에 헤딩을 제공하는 사람은 별로 없고 제공해야 한다는 지침도 없으며 오히려 제공했을 때 더 어색하고 불편할 수 있습니다. 따라서 메뉴에는 보통 헤딩이 없습니다. 하지만 한 두 페이지 정도만 탐색해 보면 시각이 있고 없고를 떠나서 누구나 그것이 메뉴라는 것을 알게 됩니다. 같은 패턴의 데이터가 반복 되기 때문입니다.

이렇게 모든 페이지마다 지속적으로 반복되는 네비게이션들을 키보드 사용자는 어떻게 탐색해야 할까요? Tab키를 계속 누르고만 있어야 할까요? 다 필요해서 있는 것이니 반복 되더라도 계속해서 탐색하고 듣고 있어야 하는 것일까요? 아닐껍니다. 건너 뛸 수 있는 장치를 제공해 주어야 합니다. 이미 위에서 ‘WCAG 2.4.1′ 구절을 인용했지만 블럭을 우회할 수 있어야 한다는 지침은 ‘수준 A’ 입니다. 수준 A는 최소한 지켜야 하는 수준으로써 가장 중요하다는 의미와 맞닿아 있습니다. 우리는 반복되는 콘텐츠 블럭을 건너 뛸 수 있도록 하기 위하여 ‘메뉴 건너 뛰기’ 링크를 제공할 수 있습니다.

메뉴 건너 뛰기 링크에 관한 쟁점

메뉴 건너 뛰기 링크를 제공해야 한다는 의견에는 거의 모든 웹 접근성 전문가들이 동의하지만 그것을 제공하는 방법에는 크게 다음과 같은 세 가지 다른 구현 방법이 있습니다.

• 메뉴 건너 뛰기 링크는 시각이 있는 사람도 볼 수 있도록 웹 페이지 최 상단에 항상 노출해야 한다.
• 메뉴 건너 뛰기 링크는 시각이 있는 사람에게는 방해가 되므로 숨김 처리하고 키보드가 접근할 때에만 노출해야 한다.
• 메뉴 건너 뛰기 링크는 시각이 있는 사람에게는 방해가 되므로 항상 숨김 처리 해야 한다.

여러분은 어떤 의견에 동의 하시나요? 저는 두 번째 방법을 가장 좋은 방법이라고 생각하고 있습니다. 만약 여러분이 ‘네이버’ 웹 페이지를 개발한다면 여러분들은 모든 네이버 웹 사이트 최 상단에 ‘메뉴 건너 뛰기’ 링크를 넣어야 한다고 생각 하시나요? 저는 그렇게 생각하지 않습니다. ‘메뉴 건너 뛰기’ 링크는 시각이 있는 사람에게는 오히려 건너 뛰고 무시해야 할 콘텐츠가 됩니다. 마우스를 조작하는 사람에게 이 링크는 필요치 않으니까요.

그렇다고 해서 항상 숨김 처리 하는 것도 문제가 됩니다. 왜냐하면 시각 장애인만 이 링크를 사용하는 것은 아니기 때문 입니다. 시각은 있지만 손과 발을 자유롭게 사용할 수 없는 지체 장애인은 마우스 스틱이라는 빨대 모양의 막대를 이용해서 키보드만으로 웹을 탐색 합니다. 손과 발이 자유롭지 못하기 때문에 입에 막대를 물고 키보드를 두드립니다. 메뉴 건너 뛰기 링크에 접근 했을 때 링크가 화면에 보여야 하는 이유는 이렇게 시각은 있지만 키보드만을 사용할 수 밖에 없는 장애인들에게 유용하기 때문 입다. 간혹 TV에서 팔이 없는 지체 장애인이 발로 마우스를 조작하는 모습을 본 기억이 있으실 껍니다. 하지만 발이 있다고 해서 모든 지체 장애인이 발로 마우스를 자유롭게 조작하는 것은 아닙니다.

키보드 사용자에게만 유용한 메뉴 건너 뛰기 링크

키보드 사용자에게만 유용한 메뉴 건너 뛰기 링크 예제를 만드는 것은 정말 쉽습니다. 자바스크립트는 필요치 않고 HTML과 CSS만으로 가능합니다. <a> 요소의 width, height, overflow 속성을 조절해서 기본적으로 화면에 보이지 않도록 처리한 다음 a:focus 상태일 때에는 width, height 값이 auto가 되도록 처리하는 것입니다.

글로벌 네비게이션을 본문 콘텐츠보다 늦게 마크업 하는 경우

글로벌 네비게이션을 본문 콘텐츠보다 나중에 마크업 하는 경우도 있습니다. 화면에 보이는 것과 마크업 순서를 다르게 처리 한다고 해서 항상 논리적인 순서가 잘 못 되었다고 말 할 수는 없습니다. 지금 제가 사용하고 있는 Textyle 블로그와 WordPress 블로그는 모두 본문 콘텐츠가 먼저 마크업 되고 글로벌 메뉴가 나중에 마크업 되어 있습니다. 이런 경우라면 ‘메뉴 건너 뛰기’ 링크보다 ‘본문 건너 뛰기’ 링크가 더 적절할 것이고 나아가 ‘건너 뛰기 링크’는 생략해도 됩니다. 본문 콘텐츠는 모든 페이지에서 반복되는 내용도 아니고 많은 링크가 포함되어 있지도 않기 때문 입니다.

지나치게 많은 ‘** 건너 뛰기’ 제공은 오히려 공해

반복되는 블럭을 건너 뛰어야 한다는 지침을 잘 못 이해해서 모든 웹 페이지 상단에 굉장히 많은 ‘** 건너 뛰기’ 링크를 제공하는 경우가 있습니다. 이것은 오히려 건너 뛰어야 할 공해 콘텐츠가 됩니다. 건너 뛰어야 할 것은 ‘반복되는 블럭’인데 마치 한 페이지의 ‘목차’ 처럼 제공하는 경우가 있다는 것입니다. 건너 뛰기 링크는 보편적인 경우에 ‘메뉴 건너 뛰기’ 하나면 충분 합니다. 한편 모든 페이지에서 반복되지는 않지만 상당히 많은 버튼이나 링크가 존재한다면 해당 블럭을 건너 뛸 수 있도록 건너 뛰기 링크를 제공하는 것이 좋습니다.

• 네이버 뉴스 클러스터링 – 키보드가 접근 할 때 화면에 보이는 메뉴 건너 뛰기 링크 하나를 제공하고 있다.
• 네이버 스마트에디터 베이직(오픈소스) - 본문에 등장하는 콘텐츠로써 키보드가 접근 할 때 도구 모음을 건너 뛸 수 있는 링크를 제공하고 있다.
• 미디어 다음 – 화면에 보이지 않는 메뉴 건너 뛰기 링크 하나를 제공하고 있다.

메뉴 건너 뛰기에 관한 더 많은 의견들

• Skip Navigation은 Quick Link가 아닙니다. - 성민장군
• KWCAG 2.0 의 Skip Navigation(건너뛰기 링크) – 본문으로 가면 그만? - 양군팩토리

Lined Tab Navigation

Faced Tab Navigation

List Item Navigation

Tab Navigation 예제의 특징

• 중첩 목록(ul>li>ul>li)을 이용한 탭 네비게이션 예제.
• 목록의 계층 구조가 논리적으로 마크업 되어 있다.
• 키보드만으로도 접근이 가능하고 키보드 접근 순서가 논리적으로 처리되어 있다.
• jQuery 사용.

이 밖에 더 많은 예제들이 OUIF | XEUI 페이지에 링크되어 있습니다.

미리 알려드립니다만 저는 주로 인터렉션을 프로토타이핑 해서 보여줄 목적으로 자바스크립트를 작성하기 때문에 제 블로그에서 보여드리는 예제 코드가 모두 XE에 반영되는 것은 아닙니다.

예제를 새 창으로 보기

HTML

• ‘LOG-IN’ 링크에 accesskey 속성을 사용. ‘Alt+L’ 또는 ‘Alt+Shift+L’ 키를 사용하면 링크에 직접 접근.
• 논리적인 키보드 접근 순서. 로그인 레이어를 열거나 닫더라도 포커스는 초기화 되지 않고 문맥에 알맞게 순서를 유지.

CSS

• 화면 전체를 덮는 반투명 레이어.
• 로그인 상자를 화면의 정 중앙에 배치.
• 서밋 버튼을 텍스트로 처리해서 텍스트를 교체할 수 있음.

Javascript

• ‘LOG-IN’ 링크를 클릭해서 모달 윈도우 처리된 레이어 띄우기.
• 인풋에 포커스가 들어가거나 빠질 때 ‘레이블’ 텍스트를 숨기거나 보여주기.
• ‘로그인 유지’ 항목에 체크하면 경고문 보여주기.
• ‘ID/PW’를 입력하지 않았을 때 상황에 맞는 알럿 띄우기.
• ‘Open ID’ 링크를 클릭하면 오픈 아이디 화면으로 전환하기.
• ‘ESC’키를 누르거나 ‘여백’ 또는 ‘X’ 버튼을 클릭하면 창 닫기.

P.S.

저는 얼마 전부터 텍스타일에서 글을 쓰고 있습니다. 여러분이 만약 이 글을 제 워드프레스에서 보셨다면 배달된 글을 보고 계신 겁니다. 텍스타일에서 작성한 글은 워드프레스, 미투데이, 트위터 등으로 자동으로 배달 된답니다. 번거롭게 퍼다 나르고 다닐 일이 없어서 좋네요. 텍스타일 한 번 사용해 보세요. 즐거운 글쓰기 경험도 해 볼겸 해서 말이죠. ^^

이 밖에 더 많은 예제들이 OUIF | XEUI 페이지에 링크되어 있습니다.

오늘은 웹 전문가들 사이에서 필요로 하는 몇 가지 개념에 대한 이야기를 하려고 합니다. "저 친구는 사람은 좋은데 이 분야에 대한 개념이 좀 없더라구" 이런 소리를 듣지 않으려면 이 분야에서 쓰는 용어에 대한 개념 정도는 탑재를 하는게 좋겠지요. 차라리 "저 친구 네가지는 없는데 이 분야에 대한 개념은 있더라구" 라는 말을 듣는게 더 낫지 않겠습니까?

• "웹 2.0 서비스 구현을 위한 웹 표준."
• "ActiveX를 사용하면 접근성이 떨어진다."
• "1%를 위한 접근성 때문에 99% 사용자를 위한 사용성을 포기 하라구요?"
• "상호 운용성이나 호환성이나 뭐가 달라요?"
• "접근성이나 보편적 설계나 결국 같은 말 아닌가요?"

이런 개념 없는 대화의 주인공 속에는 저도 포함되어 있습니다. 제 블로그 포스트나 댓글에서도 찾을 수 있구요. 지금도 그다지 개념이 충만한것 같지는 않지만 멀리 떠난 개념 찾아 오늘 한번 떠나 보렵니다. 웹 개발자가 기본적인 소양으로 알아 두어야 할 개념 몇 가지를 소개하려고 하는데 사전적인 정의는 위키백과에서 참고하는 것을 더 권장 드립니다. 제가 소개하는 각 용어들의 개념은 백과 사전에는 없는 다소 주관적인 관점 입니다.

웹 표준

W3C는 웹이 상호 운용성(어떤 소프트웨어나 하드웨어에서도 접근 가능한 웹)을 갖는 것을 목표로 하고 있는데 이 때 상호 운용성을 확보할 수 있도록 주요한 수단으로써 제시하고 권고하고 있는 것이 바로 웹 표준 입니다. 여기서 흔히 발생하는 실수는 웹 표준 자체를 목표로 삼는 것입니다. 상호 운용성이라는 목표는 궁극의 가치(?)로써 변하지 않는 것이고 변해서도 안되나 웹 표준이라는 수단은 상황에 따라서 적절히 변형하거나 포기하는등의 방법으로 현실에 임해야 하는데 수단을 목표로 삼게 되면 웹 표준에 고집스럽게 집착하게 됩니다. 단적으로 말해서 웹 표준에 집착하게 되면 정책 결정 과정에서 자칫 현실 감각을 잃고 원래의 목표인 상호 운용성을 포기해 버리는 우스운 상황도 발생하게 됩니다. 저는 웹 표준을 신뢰하고 웹이 표준에 기대는 방법으로 구현되어야 한다고 철썩같이 믿고 실무에 응용하며 지지하는 사람이지만 웹 표준이 현실을 반영하지 못하는 상황에서까지 웹 표준을 물고 늘어지고 싶지는 않습니다. 웹 표준을 이해하되 한계를 알고 표준 자체가 목표가 되어서는 안된다는 생각을 하고 있습니다.

또한 웹 2.0이라는 용어를 웹 표준과 함께 섞어 쓰는 표현은 요 몇해를 통틀어 가장 우스운 표현 가운데 하나라고 생각 합니다. 웹 표준은 웹 2.0 이라는 마케팅 용어가 등장하기 이전부터 이미 존재하는 개념인데 마치 웹 표준이  웹 2.0의 필수 요소이고 기술 스펙이며 트랜드가 된 것처럼 취급하는 문장이 만연 합니다. 웹 2.0 서비스라고 불리우는 웹 사이트들이 상호 운용성을 확보하기 위해 웹 표준에 기대는 경향이 있는 것은 사실이지만 웹 표준이 웹 2.0의 필수 요소도 아니고 웹 2.0 이라는 용어를 기술 스펙 처럼 이해하는 것도 문제라고 생각 합니다. 웹 2.0이 특정 기술 스펙을 요구하고 있다는 식으로 접근하는 것은 잘못된 현상이며 현재의 사회/문화적 측면을 해설하기 위해 창조된 용어로써 이해해야 한다는 겁니다. 좀 더 까칠하게 이야기 하면 웹 2.0 이라는 용어는 마케팅 수단에 불과하다는 생각도 가지고 있습니다.

웹 접근성

웹 접근성은 장애인이 웹을 이용할 수 있는 상태 또는 그것을 측정하는 개념 입니다. 하지만 W3C에서 조차도 이 개념을 이렇게 정의해 놓고 비 장애인들의 접근 환경을 아우르는 개념을 WCAG(Web Content Accessibility Guidelines) 지침에 추가로 언급 함으로써 웹 접근성의 개념 자체를 모호하게 만드는데 일조하고 있다고 생각 합니다. 저도 오랜시간 장애인이 아닌 사용자들의 접근환경을 측정할 때 웹 접근성이라는 개념을 사용해서 잘못된 지식을 전파하고 다녔습니다. 비록 그것이 결과적으로 긍정적이었을지는 모르지만 논란을 불러 일으킬 수 있는 표현이었음을 인정하지 않을 수 없습니다.

ActiveX와 같은 부가 애플리케이션이 비록 Microsoft에 종속된 기술로써 상호 운용성이 없을 지언정 접근성이 없다고 단언하는 등 잘못된 표현을 해왔던 것입니다. 웹 접근성은 장애인이 웹에 접근할 수 있는지를 측정하는 개념이기 때문에 장애인이 IE 브라우저를 통해서 ActiveX를 설치 및 실행할 수 있다면 그것은 자체적으로 웹 접근성을 확보한 상태이기 때문에 접근성이 없다는 표현은 틀린 표현 입니다.

비 장애인의 웹 접근에 관한 개념을 설명할 때에는 '상호 운용성, 호환성, 사용성' 따위의 개념을 빌어 설명하거나 측정해야 합니다. 앞으로 웹 접근성이라는 개념을 사용할 때에는 그 중심에 '장애인'이 포함된 개념인지를 분명히 짚고 넘어가 주시기 바랍니다.

사용성

사용성은 효율과 효과를 측정하는 개념 입니다. 흔하게 발생하는 오해는 사용성이 비 장애인들만을 평가 대상으로 하고 있다는 점입니다. 하지만 사용성은 장애인들의 사용 효율과 효과를 측정할 때에도 필요한 개념으로써 사용성 자체는 장애인과 비 장애인을 구분하지 않습니다. 사용성이 비 장애인들의 효율과 효과를 측정하는 개념이라는 오해는 마우스와 같은 특정 입력 장치에만 인터렉션을 의존하도록 만들었습니다.

마우스 클릭 횟수를 줄이고 마우스 휠을 이용해서 탐색하는 방법을 도입함으로써 사용성을 높였다고 말하지만 왜 거기서 장애인과 키보드를 선호하는 고급 사용자는 제외되어야 하나요? 사용성은 그런 개념이 아닙니다. 일단 장애인도 접근할 수 있도록 구현해 놓고 그 안에서 다양한 유형의 사용자 패턴을 모두 고려해야 합니다. 신체 건강한 20~30대 성인 8명쯤 모아놓고 사용성 테스트 진행하면서 얻을 수 있는 결론만으로 웹의 만족도를 10% 증가 시켰다는 이야기는 키보드를 선호하는 사용자들 눈에 그들만의 잔치일 뿐입니다.

사용성 테스트가 뽑아내는 숫자 놀이에 '모든 사람의 만족' 이라는 개념이 빠진것은 아닌지 점검해 봐야 한다고 생각 합니다.

상호 운용성 & 호환성

상호 운용성과 호환성이라는 용어는 사실 둘 중 어느 것을 선택 하더라도 개념 없다고 표현할 만큼 명백하게 구분되는 개념은 아닙니다. 하지만 한 가지 분명한 것은 상호 운용성은 소프트웨어와 하드웨어를 넘나드는 호환성을 지녔을 때 또는 그런 개념을 측정할 때 사용한다는 것이고 호환성은 특정 소프트웨어 또는 특정 하드웨어 안에서만 제한적으로 호환이 될 때에만 사용한다는 점이 다릅니다. 호환성이 있다고 표현할 수 있는 대표적인 기술은 ActiveX 이고 상호 운용성이 있다고 표현할 수 있는 기술은 HTML 정도가 되겠습니다.

만약 앞으로 이런 용어를 사용한다면 그것이 특정 하드웨어 또는 소프트웨어 안에서만 실행 가능한 것인지 하드웨어와 소프트웨어를 넘나드는 것인지를 분별해서 보다 정확한 용어를 사용해야 할 것입니다.

유니버설 디자인

웹 접근성이라는 개념의 중심에 '장애인'이 있었다면 유니버설 디자인의 중심에는 '모든 사람'이 있다는 점이 다릅니다. 유니버설 디자인은 설계에 있어서 장애인과 비 장애인을 구분하는 것을 금기하고 있으며 모든 사람이 되도록 동일한 방법으로 사용하고 동일한 만족을 얻을 수 있도록 개선하는 것에 초점을 맞추고 있습니다.

웹 접근성이나 사용성은 웹을 측정하는 개념으로써 주로 장애를 제거하거나 개선하기 위하여 사용되는 개념인 반면 유니버설 디자인은 철학 또는 이념으로 이해해야 합니다.

저는 웹 표준, 웹 접근성, 사용성과 같은 각각의 개념들이 모두 모여도 웹을 바르게 구현하는데 한계가 있고 서로 충돌하는 가치도 발생하기 때문에 그 한계를 극복하기 위한 철학으로써 이것이 필요하다고 주장하고 있습니다. 다소 추상적인 개념으로 다가올 수 있으나 유니버설 디자인은 보다 균형잡힌 시각을 길러주고 웹 개발의 궁극의 목표를 잃어버리지 않는데 도움이 될꺼라고 믿습니다.

대화의 기술

이런 주제로 결론을 맺는 것은 아직 세상 덜 살아본 저 자신에게 다소 부담스러운 주제이기도 한데요. 3학년이 되니까 선배랍시고 자꾸 2학년 후배들에게 잔소리를 하고 싶어지네요. 전문 분야에 대한 해박한 지식을 가지고도 대화의 기술이 부족해서 종종 트러블 메이커가 되거나 좋지 못한 평판을 받는 후배들을 응원하고 싶은 겁니다. 3학년 선배들도 2학년땐 그랬거든요.

한참 군생활 하던 시절에 소대 하사관이 "너희들 동그라미가 되고 싶은 세모의 마음을 아느냐" 라는 쌩뚱맞은 질문을 해서 참 실없다 하고 웃고 말았는데 그 질문이 살다보니 한 10년도 지나서 이해가 되더라구요. 지금은 모가 나서 잘 움직이지도 못하고 때로는 다른 사람에게 뾰족한 모서리로 상처를 주기도 하지만 동그라미가 되고 싶은 세모의 마음을 가끔씩 헤아려 봐 주세요.

블로그 포스트를 읽거나 미투데이를 사용하다 보면 다양한 분들의 이야기를 듣게 되는데요. 종종 반박의 여지를 남겨두지 않는 강한 표현들과 비난 수준의 비판이 심심치 않게 발견 됩니다. 부정적인 표현은 긍정적인 표현으로 바꾸는 연습도 해보세요. 욕이 고통을 감소시켜 준다는 실험결과도 있다고 하는데요. 욕을 듣는 사람의 입장을 배려하면 공공 장소에서 함부로 배설하지 않는게 에티켓 이겠죠.

대화의 기술은 나의 지식이 완전하지 않고 세상 속에서 타인들과 부대끼며 다듬어 질 필요가 있다는 것을 깨닫는 것으로부터 출발한다고 생각 합니다. 전문분야의 해박한 지식과 함께 네가지를 갖춘 UI 개발자가 되었으면 좋겠습니다. 일단 저부터 좀 되구요.

'세상에는 차별이 존재하고 우리들은 그런 사람들을 위해서 특별한 배려를 해왔지만 배려의 방법은 성숙하지 못했다. 다양한 지침들이 존재하지만 지침을 준수하는 것만으로는 여전히 풀리지 않는 문제 상황들을 만나기 때문에 그것을 해결해야 하는게 우리들의 과제다. 특별한 장애 유형을 위한 특별한 배려를 하지 말자. 장애를 구분하지 말고 은폐해야 한다. 이것이 유니버설 디자인의 철학이자 방법론이다.'

라는 메시지를 전달하려고 했었습니다. 여유있는 상황에서 작성한 것이 아니라(핑계) 정리가 좀 덜 된 느낌이고 이야기 전개가 매끄럽지도 못한것 같아서 보여드리기가 좀 부끄럽지만 혹시나 한 분이라도 잘 봐주시면 좋을것 같아서 공유하려고 합니다. 슬라이드 장수가 150여장 정도로 많지만 글자는 많지 않아서 약 15분 정도면 보실 수 있을것 같습니다. 프리젠테이션 버전, PDF 버전, TXT 버전.

PC에 과부하를 주는 문제가 있어 본문에 삽입했던 프리젠테이션을 제거 했습니다. 프리젠테이션 버전 링크를 이용해 주세요. 감사합니다.

문제

지금 보시는 화면은 현재 페이지의 콘텐츠를 앵커로 탐색하는 아주 흔한 네비게이션 입니다. 그리고 특정 섹션을 탐색 할 때 다른 섹션은 화면에 노출하지 않고 스크롤 과업도 없애서 되도록 내용에 집중할 수 있도록 고려된 디자인 입니다. 탭을 누를 때마다 마치 슬라이드가 한장씩 넘어가는것 같죠? 오늘의 문제는 이런 인터렉션을 아래 제시된 HTML 코드에 여러분이 직접 CSS 코드를 입혀서 자바스크립트 없이 구현하는 것 입니다.

HTML

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="ko">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>CSS Quiz 5 : Anchor Navigation</title>
<style type="text/css">
/* 여러분의 CSS 코드를 이곳에 넣으세요 */
</style>
</head>
<body>
<div id="header">
<h1>Anchor Navigation</h1>
</div>
<ol id="navigation">
<li><a href="#s1">Menu A</a></li>
<li><a href="#s2">Menu B</a></li>
<li><a href="#s3">Menu C</a></li>
<li><a href="#s4">Menu D</a></li>
<li><a href="#s5">Menu E</a></li>
</ol>
<div id="body">
<div id="content">
<div id="s1" class="section">
<p>앵커 네비게이션에 오신것을 환영합니다.</p>
</div>
<div id="s2" class="section">
<p>이 페이지는 앵커를 이용해서 탐색할 수 있습니다.</p>
</div>
<div id="s3" class="section">
<p>자바스크립트를 사용하지 않고도 간단한 인터렉션이 가능하다는 것을 보여줍니다.</p>
</div>
<div id="s4" class="section">
<p>웹 표준을 준수하고 접근성도 뛰어나죠.</p>
</div>
<div id="s5" class="section">
<p>콘텐츠의 높이가 브라우저의 뷰포트 보다 작고 높이가 고정된 상황에서 적절하게 사용할 수 있습니다.</p>
</div>
</div>
</div>
<div id="footer">
<address>
<abbr title="Xpress Engine">XE</abbr> Open <abbr title="User Interface">UI</abbr> Project by <a href="http://naradesign.net/">Naradesign</a>.
</address>
</div>
</body>
</html>

규칙

여러분은 CSS 코드만 작성하시면 됩니다. HTML 코드는 이미 제가 작성해 둔 것을 복사해서 변경 없이 사용해야 하고 자바스크립트는 사용하시면 안됩니다. 글상자 레이아웃의 너비는 800px, 높이는 400px 이며 브라우저의 창 크기를 조절하더라도 글 상자는 항상 화면의 정중앙에 위치해야 합니다. 그 외 자질구레한 레이아웃 요소들의 너비와 높이 및 색상은 여러분이 각자 알아서 결정하시면 됩니다. IE 6~8, Firefox 3, Safari 4, Opera 9, Chrome 2 브라우저에서 호환성을 유지해야 하고 CSS 문법 유효성 검사는 통과하지 않으셔도 됩니다. 캡쳐된 예제는 상자 모서리들이 라운딩 처리가 되어 있지만 그렇게 하지 않으셔도 됩니다. 선택된 메뉴(:active) 배경색이 현재 검정색으로 표시되어 있지만 그렇게 하지 않으셔도 됩니다.

정답은 2009년 6월 30일 자정까지 받겠습니다. 여러분의 계정에 정답 페이지를 생성해서 작성하신 다음 댓글에 URL을 적어 주세요. 퀴즈에 참여하실 분들은 정답을 제출하기 전까지는 다른 분들의 정답을 열람하시면 안됩니다. 이번에도 성공하신 분들께는 빌붙기 이용권이 제공 됩니다. 정답을 맞추시면 언제든 제게 밥을 사달라고 조르실 수 있습니다. ^^ 도전하세요!

참여하신 분들(빌붙기 이용권 획득)

1. dohoons – http://dohoons.com/test/cssQ/quiz5/test.html | http://dohoons.com/test/cssQ/quiz5/test2.html
2. 조성민 – http://elex.clus.org/quiz/quiz5.html
3. 황준상 – http://www.webpeace.net/css5.html
4. 이군 – http://e2goon.kr/study/naradesign-quiz/quiz5.html
5. vori – http://www.vori.net/css/AnchorNavigation.htm
6. hong! – http://viewbox.hosting.paran.com/asdf3.html
7. 조경수 – http://odini84.cafe24.com/naradesign/quiz5.html
8. 현쿠 – http://rokustd.blogspot.com/
9. 길앞잡이 – http://sljy.cafe24.com/temp/exam5.htm
10. 양영복 – http://cfs.tistory.com/custom/blog/23/233747/skin/images/quiz5.html
11. KevinCharis – http://www.kevincharis.com/quiz/anchor_Navigation.html
12. 얼리 - http://esayc.styx.in/quiz/quiz.html
13. 지연 - http://blog.naver.com/hautain/71028325
14. 무엇인가 - http://ecdemo32978.cafe24.com/quiz/cssquiz5.html
15. 조소 - http://pds15.egloos.com/pds/200906/29/28/css5.html
16. 정찬명 – http://naradesign.net/open_content/quiz/anchorNavigation/

1. 해외의 장애인 웹접근성 사례 (음성 및 텍스트형 별도 홈페이지 사례) – 음성 솔루션과 텍스트 전용 페이지가 필수라는 주장.
2. 음성 및 텍스트형 별도 홈페이지에 대한 잘못된 정보 – 음성 솔루션과 텍스트 전용 페이지가 필수가 아니라는 주장.

국내를 포함하여 어떤 국가의 법률 또는 접근성 전문가들의 견해도 TTS(Text To Speech, 음성 솔루션)를 필수적이라고 말하는 경우는 없으며 TTS 솔루션 제조사들은 장차법을 자신들의 사업에 유리한 방향으로 다르게 해석하고 있습니다. 해묵은 논쟁이라고 치부하기에 이런 제조업체들의 논점은 웹 접근성이 매우 비싼 댓가를 치뤄야 하는 것처럼 인식시키는 문제가 있어서 그냥 두고만 볼 수도 없었습니다. 실제로 제가 많이 받았던 질문 가운데 하나가 웹 접근성을 지키려면 TTS를 꼭 탑재해야 하나요? 라는 질문인데 매번 똑 같은 답변을 되풀이 하기도 이제는 솔직히 지겹습니다.

의견 감사합니다. 하지만 귀하의 글과 내 글은 근본적으로 논점과 대상이 다릅니다. 귀 하의 글은 주로 스크린리더를 사용하는 전맹인(8만)에 해당하는 문제를 집중적으로 부각해서 웹 기반 TTS를 무조건 반박만 하는데 제 글은 스크린리더를 사용할 수 없는 보편적 장애를 가진 모든 사람들에 대한 내용을 포함 하는 것 입니다. 무조건 자기 주장만 옳다고 주장하지 마시고 열린 마음으로 다른 의견도 수용할 수 있는 자세로 의견을 제시해 주셨으면 합니다.

보편적 장애란 말 그대로 스크린리더를 사용할 수 없는 장애인, 노인, 저학력자, 인지장애자 등과 같은 사람들을 모두 포함해서 얘기합니다. 다음이 음성과 키보드 제어 등 보이스몬에서 제공하는 기능이 필요한 장애 유형 입니다.

1. 난독증, ADHD와 같은 인지 및 언어장애자
2. 스크린리더를 사용하지 않은 저시력 시각장애인
3. 마우스를 사용하지 못하는 신체장애자 혹은 뇌병변장애자
4. 일정 부분 신체기능이 저하된 노인(경증장애인 범주)
5. 스크린리더사용법을 모르는 시각장애인 (제품별 키보드 약어가 통일 되어 있지 않습니다.)
6. 문맹자 (일정부분 문화적 장애인 범주)
7. 스크린리더가 설치되지 않은 컴퓨터 환경에서의 시각장애인
8. 색약 등 시각장애인
9. 사물 및 시각적 인지능력이 부족한 뇌병변 장애인
10. 스크린리더 사용조차 하기 힘든 복합 중증시각 신경 장애인

toysun님께서 말씀하신 내용 가운데 제가 동의하는 내용과 동의하지 않는 내용을 정리 했습니다.

1. 난독증, ADHD와 같은 인지 및 언어장애자
6. 문맹자 (일정부분 문화적 장애인 범주)

보이스몬과 같은 음성 솔루션의 도움을 받을 수 있는 사람은 정확하게 ‘난독증, 문맹’ 뿐이라고 판단 합니다. ADHD의 경우는 인지나 언어장애가 아니라 주의력 결핍과 과잉행동장애가 있는 사람으로써 글을 음성으로 읽어준다고 해서 접근성이 높아지는 것을 기대하기 어렵다고 판단 합니다. 보이스몬과 같은 음성 솔루션이 ‘난독증, 문맹’을 도울 수 있다고 해서 이것을 필수적이라고 말하거나 더군다나 별도의 텍스트 전용 페이지가 필요하다고 말하는 것은 어불성설 입니다. 굳이 음성 솔루션을 제공하고자 한다면 별도의 텍스트 페이지 아닌 본래의 페이지에서 제공하는 것이 더욱 바람직하고 가능한 일이며 경제적 입니다. 이때 제공되는 솔루션은 당연히 시각장애인들의 화면낭독기와 충돌하지 않도록 음성이 자동으로 흐르지 않도록 처리해야 하고 키보드 충돌 상황도 충분히 고려해야 합니다. 보이스몬과 같은 음성 솔루션은 웹 접근성을 향상시키기 위하여 필수적인 솔루션이 아니며 단지 있으면 좋은 것이되 이 솔루션 때문에 추가 페이지를 만들지 않더라도 자체적으로 충분히 웹 접근성이 있다고 판단 합니다. 만약 이 솔루션이 필수 였다면 웹 접근성 품질마크 인증을 받은 수많은 공공기관(2009년 4월 현재 58개) 웹 사이트들은 전부 기준에 적합하지 않기 때문에 인증을 받을 수 없었을 것입니다. 참고로 현재까지 웹 접근성 품질 인증을 받은 사이트들 가운데 텍스트 전용 페이지를 제공하는 곳은 단 한 곳도 존재하지 않으며 음성 솔루션의 경우 단 두 곳 제공하고 있지만 모두 본 페이지에서 소극적으로(음성 끔 상태로)만 제공하고 있습니다.

한편 아래 항목들은 다음과 같은 이유로 보이스몬과 같은 음성 솔루션의 혜택이 미치지 못하는 것으로 판단 합니다.

2. 스크린리더를 사용하지 않은 저시력 시각장애인
5. 스크린리더사용법을 모르는 시각장애인 (제품별 키보드 약어가 통일 되어 있지 않습니다.)
7. 스크린리더가 설치되지 않은 컴퓨터 환경에서의 시각장애인
9. 사물 및 시각적 인지능력이 부족한 뇌병변 장애인

이 부류의 사람들은 이미 화면낭독기, 점자 출력기 또는 화면 확대 프로그램을 사용하고 있는 것으로 봐야 합니다. 장애인으로 등록이 되어 있다면 정부에서 보조기기 지원(구입시 정부에서 80~90% 지원함)을 하고 있기 때문에 구입이 어려운 것도 아니고 이 프로그램들이 없으면 윈도우 부팅도 못합니다. 윈도우 부팅도 못하는 사람들에게 웹 페이지만을 읽어주겠다는 것은 마치 휠체어에 앉은 절단 장애인에게 목발을 써보라는 것과 같습니다. 보이스몬과 같은 솔루션들은 단순히 웹 페이지만 읽어주기 때문에 브라우저 주소창에 다른 URL을 넣거나 보이스몬이 없는 페이지는 이용할 수 없고 모든 웹 사이트가 보이스몬을 설치한 것은 아니기 때문에 통상 웹 페이지에서 제공되는 음성 솔루션 자체를 기대하지 않습니다. 웹 사이트마다 제공하는 음성 솔루션도 다르고 단축키도 다르고 솔루션이 없는 사이트는 이용할 수 없고 브라우저 콘트롤도 제어를 못하는데 시각 장애인들이 과연 이것을 대안이라고 생각하고 있을까요? 정 믿지 못하시겠으면 인터넷을 사용하는 시각장애인에게 직접 물어 보십시오. 인터넷을 사용하는 시각장애인이 스크린리더를 모를리가 없고 단축키가 다른것은 시장에 표준이 없기 때문에 당연하며 단축키는 제품에 따라 학습 합니다. 수많은 단축키가 제공되지만 서너개만 알고 있어도 탐색 하는데는 문제가 없습니다. 화면낭독기가 설치되지 않은 환경에서 다른 사람의 도움 없이는 PC 앞에 앉아 있기도 힘들고 운영체제 부팅도 불가능 하므로 이 때에는 주변인의 도움을 받고 있는 것으로 판단해야 합니다. 보이스몬이 있다 한들 집 밖으로 나섰을 때 스스로는 절대로 아무것도 할 수 없을 것입니다. 뇌병변 장애인과 같은 경우는 워낙 증상이 다양하기 때문에 상황에 따라 다를 수 있고 모든 경우에 음성 출력이 대안이 되는 것은 아니며 음성이 대안이 되는 경우는 극히 일부일 것입니다.

3. 마우스를 사용하지 못하는 신체장애자 혹은 뇌병변장애자
4. 일정 부분 신체기능이 저하된 노인(경증장애인 범주)
10. 스크린리더 사용조차 하기 힘든 복합 중증시각 신경 장애인

이 분류는 마우스를 사용하지 못하는 사람들이거나 또는 반대로 키보드를 사용하지 못하는 사람들 인데요. 이런 사람들에게 필요한 것은 키보드 또는 마우스를 보다 수월하게 이용할 수 있는 보조 공학기기이지 이것을 음성으로 출력해 주는 것은 대안이 아닙니다. 마우스나 키보드 또는 화면낭독기를 사용하기 어렵다면 보이스몬과 같은 음성 솔루션을 사용하는 것도 마찬가지로 어려운 일이므로 음성 제공이 대안이라고 할 수 없죠.

8. 색약 등 시각장애인

색약도 시각장애의 일종이지만 볼 수 없는 것은 아니기 때문에 음성 출력 솔루션이 대안은 아니죠. 그렇다고 해서 보이스몬이라는 솔루션이 문제가 있는 색을 색각장애인도 볼 수 있도록 변환해 주는 것은 아니잖아요? 색약을 위한 별도의 솔루션이라는 것은 존재할 필요가 없고 단지 색의 변별력을 이용한 정보 제공 방법만 피하면 됩니다. 색이 아닌 명도 차이를 이용하거나 색이 아닌 모양을 이용하거나 색 데이터에 문자 정보를 명시해서 함께 제공하면 간단하게 해결되는 문제 입니다.

toysun님의 주장과 같이 웹 접근성 보장을 위해 ‘음성 솔루션’을 필수로 탑재해야 할 의무는 없으며 ‘텍스트 전용’ 웹 페이지 제공도 원본 웹 페이지의 자체적인 접근성을 확보하면 해결되는 문제이기 때문에 필수적이라고 말하는 것은 잘못된 정보라는 겁니다. 오히려 서로 동등한 정보를 담고 있을 것으로 추정되는 페이지를 둘 로 분리 했을 때 이 두 페이지는 똑같지 않기 때문에 반드시 차별 요인이 발생하게 되고 이것은 보통 텍스트 전용 웹 페이지 사용자를 오히려 차별하게 됩니다. 데이터가 동일하게 업데이트 된다고 해서 차별이 없다고 말할 수 있을까요? 제가 판단하기에 일반인과 다른 경로를 제공하는 것 자체가 차별이라고 판단할 수도 있을것 같은데요. 의도 했는지 여부는 관계가 없습니다. 비장애인과 장애인에게 웹에서 서로 다른 경로를 제공하려면 장애인이 스스로 분리되었다고 느끼지 않아야 한다고 생각 합니다. 이것이 불가능한 일도 아닌데 마치 불가능한 일인냥 웹에서까지 ‘장애인 전용’을 만들어 놓는것이 과연 옳은 일일까요?

• a
• area
• button
• input
• object
• select
• textarea

이 요소들 이외의 요소에 tabindex 속성이 지정되면 문법적으로 유효하지 않습니다. 그러나 문법적으로 옳고 그름을 떠나 한 가지 질문을 던져 보겠습니다.

tabindex 속성을 왜 사용하시나요?

여러분은 아마도 아래 두 가지 경우중 하나의 대답을 선택할 것입니다.

• 사용성을 높이기 위하여.
• 접근 순서를 보완하기 위하여.

tabindex, 사용성을 높인 사례.

포털 초기화면에서 가장 많은 포커스를 가져가는 곳을 순서대로 정렬시켜 보면 어떨까요?

1. 검색 인풋
2. 아이디 인풋
3. 비밀번호 인풋
4. 로그인 버튼

맞나요? 객관적으로 제시할 근거 자료는 없지만 저는 거의 확신하고 있습니다. 국내 양대 포털인 DAUM과 NAVER에 가서 키보드만으로 웹 페이지를 탐색해 보세요. tab 키는 ‘검색 인풋-아이디 인풋-비밀번호 인풋-로그인 버튼’ 순으로 이동할 것입니다. 양대 포털은 누가 먼저랄 것도 없이 이 네 가지 요소에 tabindex를 적용 했습니다. 굳이 누가 먼저 했는지를 따지는 것은 의미는 없는 일입니다. 어느 한쪽이 뒤늦게 이것을 했다고 해서 따라했다는 소리를 들을 필요는 없다고 생각하니까요. 키보드만으로 웹 페이지를 탐색하는 사람들은 보통 장애인이거나 또는 숙련된 사람들 입니다. 이 사람들에게 포털에서 제공한 tabindex키는 분명 도움이 되었을 것입니다. 굳이 제공하지 않더라도 접근에 제한이 되는것은 아니지만 제공함으로써 효율적인 탐색이 가능하게 되었으니 사용성을 높였다고 평가할 수 있습니다. ‘검색 인풋-아이디 인풋-비밀번호 인풋-로그인 버튼’ 탐색이 끝나면 포커스는 페이지에서 가장 처음 등장하는 a, area, button, input, object, select, textarea 요소를 찾고 그 이후로는 순차적으로 웹 페이지를 탐색할 것입니다.

tabindex, 키보드 접근 순서를 보완한 사례.

tabindex가 접근성을 높여준다는 오해가 있는데 완전히 잘못된 상식입니다. 만약 여러분이 사용성을 높이기 위한 목적이 아니라 HTML의 접근 순서를 보완하기 위하여 tabindex를 사용했다면 그것은 여러분의 HTML이 논리적인 순서로 마크업 되지 않았다는 것을 반증하는 것입니다. HTML의 마크업 순서가 논리적으로 작성되었다면 tabindex 속성은 애시당초 필요하지 않습니다. 심지어 tabindex 속성은 HTML 스펙에서 사라지더라도 전혀 문제가 없는 속성이라고 생각합니다. 빈번하게 발견되는 예를 한번 들어 보겠습니다.

다음과 같이 table을 이용하여 로그인 서식을 배치하는 경우 키보드 접근 순서는 ‘아이디 인풋-로그인 버튼-비밀번호 인풋’이 됩니다. 이 순서는 HTML 마크업 순서에 따라 발생하는 순서로써 논리적이라고 보기 어려운 순서 입니다. 

HTML 코드를 보면 왜 이런 순서로 탐색이 되는지 알 수 있습니다.

<table border="1">
  <tbody>
    <tr>
      <th scope="row"><label for="uid">아이디 :</label></th>
      <td><input type="text" id="uid" /></td>
      <td rowspan="2"><input type="submit" value="로그인" /></td>
    </tr>
    <tr>
      <th scope="row"><label for="upw">비밀번호 :</label></th>
      <td><input type="password" id="upw" /></td>
    </tr>
  </tbody>
</table>

로그인 버튼은 병합된 첫 번째 행의 세 번째 컬럼에 포함되기 때문에 아이디 인풋 다음으로 포커스를 받게 됩니다. 비밀번호를 작성하지 않은 상태로 로그인 하도록 유도하는 상황 입니다. 문제는 웹 페이지 저작자들이 이 문제를 해결하기 위하여 table을 걷어내지 않고 ‘아이디, 비밀번호, 로그인’ 콘트롤에 tabindex 속성을 사용한다는 데 있습니다. 여기서 tabindex를 사용하게 되면 tab키는 다른 어떤 항목보다 로그인 서식을 먼저 탐색하게 됩니다. 이것이 의도한 경우라면 문제가 되지 않지만 만약 ‘로그인’ 서식이 아니고 웹 페이지에서 가장 먼저 탐색이 되어야 하는 콘텐츠가 아니라면 어떨까요? 어설프게 tabindex를 사용한 다음 그 순서가 잘못 지정된 것을 바로잡지 않은 사례가 무척 많이 발견 됩니다. 또 그것을 그대로 복사해서 다른 곳에 아무 생각 없이 가져다 쓰는 사례도 많습니다. 이런 경우 tabindex가 접근성을 오히려 훼손하게 됩니다. 지금 당장 여러분이 제작한 웹 사이트를 찾아서 tabindex가 사용되었는지를 확인하고 접근 순서를 오히려 훼손하고 있지 않은지 테스트 해보세요.

tabindex 대신 HTML의 논리적인 구조를 바로잡아야.

테이블이 사용되지 않아야 할 곳에 테이블이 사용되었다면 테이블을 걷어내야 합니다. 위에서 예로 든 로그인 서식의 경우 적어도 th 요소가 있기 때문에 table이 의미에 맞지 않는다고 보기는 어렵습니다. 단지 논리적인 구조를 갖지 못할 뿐이죠. 그러나 table을 걷어낸다면 적어도 tabindex를 사용하지 않아도 될 것입니다. 매우 치밀하게 사용하고 관리하지 않는다면 tabindex를 사용하는 것은 여러분의 웹 사이트에 땜빵질을 하는 것과 같습니다. 땜빵하는 방법 대신 얼개를 바꾸기를 강력하게 권장 합니다.

한국산업인력관리공단 통계에 의하면 웹 디자인 기능사는 2007년 말까지 26,811명이 응시하여 6,232명이 자격을 취득 했으며 매년 2천명 이상의 합격률 추이를 보이고 있습니다. 2009년 2월 현재의 통계는 나와있지 않지만 과거의 응시율과 합격률로 추정컨데 현재까지 약 8,000여명 이상이 이 자격증을 보유하고 있을 것으로 예상 됩니다. 2007년 합격율은 26.9%나 되는군요. 저도 2005년에 이 자격증을 취득 했고 이 분야에서 1~2년 이상 실무에 종사해본 경험이 있는 분들은 그리 어렵지 않게 취득이 가능한 수준입니다.

그러나 현재에 이르러 이 자격증의 실기시험 평가기준은 대폭 수정해야 할 것 같습니다. 웹 표준, 웹 접근성, 유니버설 디자인, 인터렉션 디자인에 관한 측면은 전혀 평가를 하지 않고 있으며 단순하게 제한된 시간에 저작도구를 얼마나 빨리 잘 다루는지만을 측정하고 있기 때문입니다. 이 자격증은 실무에서 전혀 도움이 되지 않으며 그저 웹 디자인 할 줄 아는 사람인지 아닌지 정도만 평가하는 수준밖에 안됩니다. 따라서 이런 자격증은 아예 폐기하거나 대폭 바꿔야 한다고 생각합니다.

다행히도 한국정보문화진흥원에서 ‘웹 접근성 자격증 도입방안’에 대한 연구를 의뢰하는 용역을 발주(2009년 2월 17일) 했습니다. 이것은 웹 접근성 자격증을 당장 개설하겠다는 것이 아니라 웹 접근성 전문가의 자질을 객관적으로 평가하는 것이 가능한지를 가늠하고 이것이 실효를 거둘 수 있는지를 미리 알아보기 위한 검토가 시작되었다는 것을 뜻합니다. 긍정적인 검토가 나오면 그땐 정말 생길 수도 있겠지요. 어쨌거나 몸담고 있는 분야가 더욱 발전하고 하나의 기술로 인정받을 수 있는 계기가 생겨난다는 측면에서 무척 환영할만한 일입니다.

1. 연구명 : 웹 접근성 자격증 도입방안 연구
2. 추진배경
   1. ‘08년 4월부터 시행된 장애인차별금지법의 효과적 운용을 위해 웹 접근성 품질평가 및 구축을 위한 전문인력 수요증가
      • ’09년부터 장애인차별금지법 적용 의무대상기관 단계적 확대
      • 교육(특수학교), 의료(종합병원), 사회복지시설, 장애복지시설 등
   2. 웹 접근성 전문성 보유 유무에 대한 객관적 검증 방안 전무
      • ‘05년부터 민간 웹 개발자 1,389명 대상 웹 접근성 교육하였으나, 교육 수혜자에 대한 웹 접근성 전문능력 검증방안 부재
3. 추진목적
   • 웹 접근성 품질평가 및 구축 전문능력에 대한 자격인증 타당성 검토 및 도입방안 연구
4. 연구내용
   1. 웹 접근성 관련 인력현황 및 전문인력에 대한 분석․정의
      • 웹 접근성 관련 전문인력 수급 현황 및 전망
      • 웹 접근성 전문가 지식, 기술 등 사항을 작업별로 추출하여 분류, 종합
   2. 웹 접근성 전문인력 자격도입에 대한 수요조사
      • 자격종목 개발의 필요성, 자격제도 운영 방법
   3. 웹 관련 자격증 관련 국내외 사례조사 및 시사점 도출
      • 웹 접근성 내용 포함 가능한 웹 관련 자격증 조사
      • 국내 환경에 적합한 웹 접근성 자격증 도입을 위해 필요한 시사점 및 고려사항 도출
   4. 웹 접근성 자격의 구조 및 출제 기준, 종목 설계
      • 웹 접근성 자격검증에 필요한 자격의 내용, 수준, 운영방법
5. 연구기간 및 예산
   1. 사업기간 : 계약일로부터 ~ 6개월까지
   2. 예 산 : 20,000,000원(부가세 포함)

한국정보문화진흥원 > 입찰공고

1. 웹 표준을 넘어서… (정찬명 http://naradesign.net/)
2. 목 차
   1. 서론
      1. 웹 표준의 의의
      2. 웹 표준의 한계
   2. 본론
      1. 웹 표준의 태동
      2. 웹 표준의 수난
      3. 웹 표준의 성장
      4. 웹 표준의 정착
   3. 결론
      1. 웹 표준을 넘어서…
3. 웹 표준의 의의
   1. "Web Interoperability" 웹의 상호 운용성
   2. "인류의 지식 기반으로써"
   3. "누구나"
   4. "뭐든지"
   5. "독점하지 않고"
   6. "공평하게"
   7. "Accessible"
   8. "Web"
   9. "The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect." Tim Berners-Lee, W3C Director and inventor of the World Wide Web
4. 웹 표준의 한계
   1. "너무 느리고"
   2. "사람의 손길이 필요"
   3. "충분하지 않다"
5. 웹 표준의 태동
   1. "2004년 한국 오픈소스 진영"
      1. kldp.org
      2. forums.mozilla.or.kr
   2. "국내 웹 표준화 운동 전개의 필요성을 느낍니다"
   3. "2005 실전 웹 표준 가이드"
      1. 윤석찬(다음커뮤니케이션)
      2. 신현석(오페라소프트웨어)
      3. 이성노(어센트네트웍스)
      4. 신정식(구글)
6. 웹 표준의 수난
   1. IE 사용자가 99%인 현실 속에서 표준은 과연 누구를 위한 것인가?
   2. 비즈니스에 도움이 되지 않는 표준은 지킬 필요가 없고 그것은 어디까지나 ‘선택’의 문제다.
   3. 전도사 라는 명칭도 마음에 들지 않는다. 웹 표준을 강요하지 말라.
7. 웹 표준의 성장
   1. "표현"
      1. 빨간책(실용예제로 배우는 웹 표준)
      2. 파란책(웹 2.0을 이끄는 방탄웹)
      3. 초록책(CSS 마스터 전략)
   2. "의미"
      1. 웹 표준 교과서
   3. "웹을 의미있게 표현하는 방법을 배우다"
8. 웹 표준의 정착
   1. "IE 사용자는 여전히 99% 인데" 1%가 세상을 바꾼 것일까요?
   2. "대한민국에 웹 표준이 뿌리내리기 시작하다"
   3. "블로그 미디어는 기업의 사회적 책임을 추궁했고 기업은 그것에 응한 것."
   4. "모두의 승리"
9. 웹 표준을 넘어서…
   1. 하지만 사람들은 여전히 웹 표준이 누구를 위한 것인지에 대하여 묻습니다.
   2. 느리고, 충분하지 않으며, 여전히 사람의 손길을 요구하는
   3. 때로는, 현실 세계와 동떨어져 골치거리가 되어버린 웹 표준은
   4. 1%의 소수를 위한 것이 아니라 모두를 위한 것입니다.
   5. 그리고 우리는 그것을 "유니버설 디자인" 이라고 부릅니다
   6. 우리는 유니버설 디자인을 해야 합니다.
   7. 유니버설 디자인을 위하여 웹 표준은 좋은 수단이 되지만 그 자체가 목적은 아닙니다.
   8. 유니버설 디자인은 사람을 장애인과 비장애인으로 분류하지 않으며 단지"모두가" 라고 말합니다.
   9. 그리고 "장애"라는 것은 "사람"에게 있는 것이 아니라 "환경"에 있다고 말합니다.
   10. 더 이상 사람에게 "장애"가 있다고 말하지 않는 그런 사회가 빨리 왔으면 좋겠습니다.
   11. 우리는 유니버설 디자인을 해야 합니다.
   12. 모두를 위한 것이니 나를 위한 것이기도 합니다.
   13. 빨간책(Universal Design)을 추천합니다.
   14. 파란책(Universal Design)을 추천합니다.
   15. 초록책(Universal Design)을 아직 찾지 못했습니다. 추천해 주세요.
10. 감사합니다.

다른 분들의 후기

• 세번째 웹표준의 날 참석 후기 – 장성민
• 세번째 웹 표준의 날 – 홍윤표
• 세번째 웹 표준의 날을 마치고 – 조현진
• 세번째 웹 표준의 날 후기 – 경험디자인
• 제 3회 웹 표준의날 참가후기 – 나인환
• 세번째 웹표준의 날 행사 풍경 – 추지호
• 웹 표준, 기술의 진정성 – 추지호
• 2009 웹표준의날 ‘웹표준을 넘어서…’ – Officer Lee
• 세번째 웹 표준의 날 후기 – 웹표준을 넘어서 – mkyoon
• 세번째 웹 표준의 날 후기 – 윤좌진
• 제 3회 웹표준의 날을 마치고 - 신현석

다른 분들의 후기로 핑백은 발송이 되는데 트랙백은 현재 기능이 고장이어서 발송이 안되고 있습니다. ㅜㅜ; 트랙백이 걸리지 않은 분들께서는 양해 부탁드립니다.