HTML4 명세는 tabindex를 다음과 같이 설명합니다. 이 설명은 XHTML 문서에도 동일하게 적용됩니다.

• 이 속성은 문서의 탭 순서 안에서 현재 요소의 순번을 결정한다. 값은 0부터 32767 사이의 숫자여야 한다. 브라우저는 값 앞에 0이 붙어있으면 무시해야 한다.
• 탭 순서는 사용자가 키보드를 통해 탐색할 때 어떤 요소가 초점을 받는 순서가 되는지를 결정한다.
• 초점을 받을 요소는 브라우저에서 다음과 같은 규칙에 따라 탐색되어야 한다.
1. 요소가 tabindex 속성을 지원하고 양의 값이 할당되어 있으면 먼저 탐색되어야 한다. 탐색은 tabindex 값의 가장 작은 수에서 시작하여 가장 큰 값으로 향한다. 값은 연속되는 일련의  숫자가 아니어도 상관이 없고 어떤 수로 시작해도 무방하다. 요소에 동일한 tabindex 값이 지정되어 있다면 코드 안에서 먼저 등장하는 순서대로 탐색되어야 한다.
2. tabindex 속성 지원 여부에 관계 없이 “0″의 값이 할당된 요소는 그 다음으로 탐색된다. 이 요소들은 코드 안에서 등장하는 순서대로 탐색된다.
3. disabled 속성이 사용된 요소는 탭 순서에 관여하지 않는다.
• a, area, button, input, object, select, textarea 요소가 tabindex 속성을 지원하는 요소이다.

어쨌거나 표준에 따르면 tabindex 속성에는 음수 값을 사용할 수 없습니다. 그러나 현존하는 브라우저들은 tabindex=”-1″ 속성이 부여된 요소에 대해 키보드가 접근하지 않는 방식으로 구현을 해놨더라구요. 결국 이 방식이 사실상 표준이거나 또는 공식 표준이 아닐까 하는 생각이 들어 HTML5 명세를 찾아 봤습니다.

HTML5 명세는 tabindex 속성의 음수 값을 다음과 같이 설명합니다.

• tabindex 값이 음의 정수라면 요소에 초점이 도달하지 않도록 해야 한다.

결국 tabindex 속성에서 음수 값을 사용하여 초점을 받을 수 없도록 하는 스펙을 추가한 것입니다. 그리고 현존하는 웹 브라우저들은 문서의 DTD에 관계 없이 이런 새로운 스펙을 낡은 문서에서도 사용할 수 있도록 구현해 둔 것입니다.

지구인들이 가장 많이 사용하고 있는 위지윅 에디터 TinyMCE와 CKEditor는 이런 코드를 도구모음 버튼에 적용하여 키보드 사용자들이 도구모음 블럭을 아예 건너 뛰도록 해 놨더라구요. 이런 구현방식에 대해 어떤 분들은 키보드 사용자를 고려하지 않았다고 주장할 수 있는데요. 제가 보기에는 이 친구들 센스있게 잘 처리한 것으로 봅니다. 키보드만으로 위지윅 에디터를 사용해 본 분들은 이런 처리를 이해할 수 있습니다.

네이버 스마트에디터와 다음 에디터는 도구모음 블럭에 키보드가 접근할 수 있도록 처리해 놨지만 실제로는 키보드만으로는 절대로 사용할 수가 없습니다. 일단 본문 영역에 초점이 들어가면 빠져나올 방법이 없기 때문에 문제가 시작됩니다. 편집 영역에 초점이 들어가면 Tab 키를 눌러서 빠져 나와야 하는데 Tab 키에 들여쓰기 기능을 맵핑해 놓았기 때문에 편집 영역에서 빠져나올 수 없습니다. 결국 키보드만 사용하는 시각 장애인 또는 상지 장애인(팔이 없거나 불편한)은 글쓰기 과업을 수행할 수 없었습니다.

tabindex=”1″

문서 안에서 가장 먼저 초점을 받을 수 있습니다. 그러나 자연스러운 마크업 순서를 거스르기 때문에 주의해서 사용해야 합니다. 검색엔진 사이트에서 검색창에 사용하면 적합하지만(이 대신 autofocus=”autofocus” 속성이 더 적절할 듯 해요) 그 외 적합한 경우는 잘 떠오르지 않는군요.

tabindex=”0″

키보드 초점을 받을 수 없는 div, span과 같은 요소도 초점을 받을 수 있도록 만들어 줍니다. 초점을 받되 초점을 받는 순서는 자연스러운 마크업 순서를 따릅니다.

tabindex=”-1″

키보드 초점을 받을 수 있는 요소도 초점을 받을 수 없도록 만들어 줍니다. 초점을 받을 수 없기 때문에 “-1″ 이외의 다른 음의 정수 값은 사실상 의미가 없습니다.

모든 웹 기반의 위지윅 에디터를 조사한 것은 아니지만 제가 간단하게 벤치마킹한 결과에 따르면 국내외를 막론하고 대부분의 제품들은 웹 브라우저가 기본으로 제공하는 처리 방식에 따라 p 요소에 Enter키를 맵핑해 두었고 br 요소에 Shift+Enter키를 맵핑해 두었습니다.

한편 글로벌 제품들은 p 요소에 브라우저가 제공하는 기본적인 상하 여백 {margin:1em 0} 스타일을 그대로 살려두는 방식을 채택했는데 국내 제품들은 p 요소에 브라우저가 제공하는 기본적인 상하 여백을 {margin:0} 으로 덮어쓰기 하는 방식으로 리셋 했습니다.

이를 통해서 우리는 다음과 같은 세 가지 사실을 알 수 있습니다.

• 해외에서는 Enter키를 치면 단락을 변경하는 것으로써 단락 사이의 여백이 학습되어 있다. 행간 여백 없이 줄 바꿈을 하려면 Shift+Enter를 치면 된다.
• 한국에서는 Enter키를 치면 단락을 변경하는 것이 아니라 단순히 줄 바꿈을 하는것으로 학습되어 있다. 단락을 구분하려면 Enter키를 두번 치면 된다. 문단 요소 p의 여백이 제거되어 있으므로 Shift+Enter를 알 필요도 없다.
• 외국 사람과 한국 사람은 웹에서 선호하는 글쓰기 모양도 다르고 경험도 다르다. 외국 사람은 하나의 문장에 마침표를 찍더라도 다음 문장을 줄 바꿈 없이 이어쓰며 단락을 바꿀 때에만 Enter를 치는 경향이 있고 한국 사람들은 마침표를 찍으면 다음 문장을 쓰기 위해 줄을 바꾼다. 외국인이 생성하는 태그는 의미론적 관점에서 옳은 방향이나 한국인이 사용하는 방식은 편리하다.

외국인과 한국인의 습성이 다를 뿐만 아니라 글쓰기 교육 시간에 문단을 바꿀 때에만 개행하라고 배웠다 하더라도 한국 사람들의 글쓰기가 틀렸다고 보기는 어렵다고 생각합니다. 국민 모두가 한 방향으로 틀렸다면 그 방향이 우리 나라에서는 사실상 통용되는 표준이라고 인정해야 한다는 생각입니다. 따라서 우리의 고민은 다음과 같이 전개됩니다.

• 한국에서 제품을 만들기 시작했지만 글로벌 시장에 진출하려면 사실상 국제 표준에 따라야 한다.
• 글로벌 시장에 진출하더라도 한국 시장은 포기할 수 없다.
• 우리 제품은 내수용과 수출용 구분이 따로 없다.

‘A’도 만족해야 하고 ‘B’도 만족해야 한다면 둘 다 만족 시켜주자라는 것이 중론인데요. 다음과 같은 제안들이 검토 대상에 올랐습니다.

• p 요소는 Enter키로 생성하며 br 요소는 Shift+Enter키로 생성한다.
• p 요소의 여백을 관리자 화면에서 원하는 방식으로 선택할 수 있도록 옵션을 제공한다. "[v] p 요소에 여백 제거"
• p 요소의 여백을 글 쓰는 사람이 에디터에서 직접 선택할 수 있도록 옵션을 제공한다. "[v] p 요소에 여백 제거"
• p 요소에 브라우저가 제공하는 기본 마진을 보존한 다음 Enter 한번은 br 요소를 생성하고 Enter 두번은 p 요소를 생성한다. (이 방법은 작년부터 제안되었으나 구현에 대한 난제가 있었던 것으로 지금은 정확히 기억이 나지 않네요)

글 쓰는 사람이 에디터에서 직접 선택할 수 있도록 옵션을 제공하는 방법은 개인적으로 반대하는 방법입니다. 개발자 또는 관리자가 해야 할 선택을 사용자에게 떠넘겨 UI를 복잡하게 만든다는 느낌을 지울 수가 없고 의미를 정확하게 간파하는 사용자도 드물꺼라 생각합니다. XE개발팀에서 XEED라는 새로운 에디터를 개발하며 이 문제를 어떻게 해결하는지 지켜봐주세요. 그리고 좋은 의견이나 경험담이 있으면 댓글로 함께 의견 나누시죠.

IE6는 아직 살아있다.

넷어플리케이션즈의 2010년 9월 최근 통계에 따르면 아직 전세계적으로 IE6 사용자는 16% 수준의 점유율을 보이고 있습니다. 인터넷트렌드의 2010년 9월 통계에 따르면 국내 IE6 사용자는 무려 36%나 됩니다. IE7과 IE8은 국내에서 각각 30% 수준의 점유율을 보이고 있습니다. 사람들은 IE6 브라우저의 장례식을 치를만큼 낡은 브라우저가 하루속히 사라져주길 원하지만 IE6는 아직 죽지 않았습니다. 웹 개발자는 IE6, IE7, IE8, IE9 브라우저에 모두 대응해야 합니다.

IE 브라우저 버전은 4개 이지만 둘로 구분할 수 있다.

IE6, IE7, IE8, IE9 브라우저 버전은 4개이나 표준 준수율 또는 버그 발생률에 따라 단 두 가지 종류로 간단하게 구분할 수 있습니다.

IE8~9 브라우저는 HTML/CSS 표준 준수 테스트 도구인 Acid2 테스트에서 모두 만점을 받은 브라우저 들입니다. 따라서 이 두 버전의 브라우저는 다른 여느 표준계열 브라우저들(크롬, 사파리, 오페라, 파이어폭스)과 어깨를 나란히 합니다. IE8 또는 IE9 브라우저에 최적화된 웹 페이지는 다른 브라우저에서도 별 문제 없이 똑같이 잘 보입니다.

그러나 IE6~7 브라우저는 표준 준수율이 상대적으로 떨어지고 버그도 많습니다. 다행인것은 IE6 브라우저와 IE7 브라우저가 그다지 큰 차이가 없다는 점입니다. IE6 브라우저에서 발생하는 문제는 IE7 브라우저에서 동일하게 발생할 확률이 높습니다. IE7 브라우저가 조금 더 나을 뿐입니다.

결국 저는 IE8~9 브라우저에 대해서는 할 말이 많지 않습니다. IE6~7 브라우저의 문제 해결을 위해서 몇 가지 팁을 소개합니다.

IE6~7 문제해결.

• IE6~7 브라우저도 표준에 따라 구현된 브라우저 입니다. 표준 DTD를 사용하면 표준에 따라 잘 렌더링 해줍니다. 반드시 표준 DTD를 사용하세요. DTD를 사용하지 않으면 모든 브라우저들이 IE5 버전의 브라우저를 흉내내는 Quirks Mode 상태가 되어 각기 다른 뷰를 출력합니다.
• 사용자에게 무엇이 더 좋은지 HTML과 XHTML의 우위를 논하는 것은 무의미 합니다. 그러나 XHTML의 엄격한 문법이 개발자에게는 더 유리할 것입니다.
• 엄격한(Strict) DTD와 호환형(Transitional) DTD 가운데 호환형 DTD를 추천합니다. 엄격함은 많은 오류를 유발할 뿐입니다.
• 마이크로소프트의 독자적인 표현방식인 hasLayout이 존재한다는 것을 알아야 합니다. hasLayout이 없으면 문제가 발생하는 경우가 많습니다. IE6~7 브라우저에서 화면에 특정 요소가 보이지 않거나 잘못된 표현을 하면 { zoom:1 } 속성을 추가로 부여하여 해결되는 경우가 많습니다. zoom 속성은 hasLayout Trigger 이며 다른 브라우저들은 해석하지 않는 속성입니다.
• float된 방향와 같은 방향의 margin이 존재하는 경우 IE6 브라우저는 margin을 두 배로 출력하는 빈도 높은 버그가 있습니다. float이 부여된 요소에 display:inline 속성을 부여하면 해결됩니다. float 처리된 요소는 display 속성이 block으로 바뀌는데 이 값은 절대로 덮어쓰기가 되지 않습니다. float된 요소에 inline 속성을 부여해도 여전히 block 이라는 뜻입니다. 그 밖에 float 요소는 마지막 텍스트 콘텐츠를 복사해서 출력하는 버그도 있는데 이 때에도 display:inline 속성을 부여하면 해결됩니다.
• zoom 속성으로 문제가 해결되지 않으면 position:relative 속성을 사용해 봅니다. display:block 으로 처리한 a 요소의 클릭 영역이 제대로 잡히지 않는 문제를 해결할 수 있습니다. 마우스 커서 모양의 잘못된 출력도 바로잡아 줍니다.
• *property:value와 같은 형식으로 속성 앞에 ‘*’ 별표를 붙이면 IE6, IE7 브라우저만 이 속성을 해석하고 다른 브라우저는 무시합니다.
• _property:value와 같은 형식으로 속성 앞에 ‘_’ 언더바를 붙이면 IE6 브라우저만 이 속성을 해석하고 다른 브라우저는 무시합니다.

IE6~9 브라우저에서 CSS3 사용하기.

낡은 브라우저 때문에 신기술을 사용할 수 없다는 생각은 극복할 수 있습니다. 마이크로소프트에서 이미 오래전에 브라우저에 탑재했던 기술이 CSS3 표준으로 채택(word-wrap, text-overflow, @font-face)이 되기도 했고 CSS3와 유사한 기술(filter)이 이미 IE6~8 브라우저에 구현되어 있기도 합니다. 우리는 신기술을 사용하거나 또는 모방하면서 브라우저 호환성도 유지할 수 있습니다.

IE6~9 브라우저에서 사용하거나 모방할 수 있는 CSS3에 대한 설명은 HTML5 오픈 컨퍼런스에서 발표했던 CSS3 소개 자료로 대신합니다.

요점 정리.

1. 현존하는 하위 버전 브라우저에 대한 호환성을 지원해야 합니다.
2. 신 기술의 사용을 두려워 할 필요가 없습니다. 좋은 도구를 선택한 사용자에게 향상된 경험을 전달해야 합니다. 
3. 낡은 브라우저 비난하기 보다는 새 브라우저를 추천 합시다.

다소 지루하고 딱딱한 발표였음에도 불구하고 관심을 가지고 들어주셔서 고맙습니다. IE10 런칭 행사에서는 더 이상 낡은 브라우저 이야기는 나오지 않았으면 하는 바램입니다. 아마 한국 마이크로소프트도 그런 기대를 가지고 있을 것입니다. 발표자료. 발표영상.

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

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 페이지에 링크되어 있습니다.

1. 명세의 시작과 끝
2. 명세의 주석
3. 연산 기호들
4. 등장하는 용어들
5. 본체와 변수
6. 요소와 속성
7. 요소 명세 읽기
8. 속성 명세 읽기
9. 참고

DTD에 표시된 URI(예: loose.dtd 또는 xhtml1-transitional.dtd)를 내려받아서 명세를 한 번이라도 열어보신 분들이라면 알 수 없는 낯선 문자들에 대한 당혹스러움을 감출 수 없었을 것입니다. HTML/XHTML의 문법 규칙들이 포함되어 있고 브라우저가 이것을 어떻게 해석해야 하는지에 대한 단서가 기록되어 있습니다. 만약 DTD가 없다면 여러분은 <address> 요소 안쪽에 어떤 요소가 허용되는지 알 수 없을 것입니다. <address> 요소 안쪽에는 블럭 요소를 허용하지 않지만 예외적으로 HTML 4.01 호환 모드(Transotional) DTD에서 블럭 요소인 <p> 요소를 허용합니다. 문법 검사기(HTML Validator)는 DTD를 근거로 문법을 검사하기 때문에 호환 모드에서 <address> 요소 안쪽의 <p>를 적법하다고 간주하며 HTML 4.01 엄격 모드(strict.dtd)에서는 적법하지 않다고 오류 메시지를 보여줄 것입니다. DTD는 HTML/XHTML 문서에 대한 가장 기초적인 명세로써 웹 브라우저가 HTML을 해석하는 기준이 되고 문법 검사기가 유효성을 판단하는 기준이 됩니다. 

지금부터는 이해를 돕기 위하여 HTML 4.01 호환모드 DTD인 http://www.w3.org/TR/html4/loose.dtd 파일을 내려받은 후 화면에 열어놓거나 또는 웹 페이지 버전의 HTML 4.01 loose.dtd 페이지(추천) 또는 웹 페이지 버전의 XHTML 1.0 – DTDs(추천)을 열어놓은 다음 이 글과 번갈아 보면서 내용을 천천히 정독해 주시기 바랍니다. HTML 4.01 Transitional DTD를 기준으로 설명하겠습니다. 이 포스트는 내용은 조금 어렵지만 몇가지 낮선 단어들과 규칙들을 익힘으로써 HTML과 XHTML 명세를 다른 사람에게 물어보지 않고도 스스로 터득할 수 있는 근본적인 지식이 될 것입니다.

명세의 시작과 끝

DTD에서 HTML 요소 및 속성에 대한 명세 구문은 여는 꺽쇠와 느낌표(<!)로 시작하여 닫는 꺽쇠(>)로 끝납니다.

<! 이곳에 명세가 들어갑니다 >

명세의 주석

명세의 주석은 — 2회 연속 작성된 하이픈 — 문자 안쪽에 기술합니다. 주석 안쪽에 포함된 내용은 기계적으로 해석되지 않고 사람이 읽을 수 있도록 자연어 문장으로 처리되어 있습니다. 아래 첫 번째 주석은 순수한 주석문이고 두 번째 주석은 명세 안에 포함된 주석문 입니다. 주석은 한 줄 또는 여러줄이 될 수 있습니다.

<!– 이곳에 주석의 내용이 들어갑니다 –>
<! 이곳에 명세가 들어갑니다 – 이곳에 주석의 내용이 들어갑니다 –>

연산 기호들

연산 기호들은 주로 특정 요소가 자식 요소로써 어떤 요소들을 어떻게 허용하는지 정의할 때 사용합니다. 예를 들어 <a> 요소는 다른 인라인 요소들은 모두 허용하지만 예외적으로 자신과 동일한 요소인 <a> 요소만은 자식으로 둘 수 없다고 -(A) 선언되어 있는데 이러한 선언은 모두 연산자를 통해 표시 됩니다. 

• ( … ) : 연산 그룹의 범위
• A : A는 필수적이며 한 번만 사용할 수 있다
• A+ : A는 필수적이며 한 번 이상 사용해야 한다
• A? : A는 생략하거나 한 번만 사용할 수 있다
• A* : A는 생략하거나 한 번 이상 사용할 수 있다
• +(A) : 추가적으로 A를 사용할 수 있다
• -(A) : 예외적으로 A는 사용할 수 없다
• A | B : A 또는 B를 사용할 수 있다
• A, B : A 그리고 B는 순서를 지켜야 한다
• A & B : A 그리고 B는 순서에 무관하다

등장하는 용어들

• #PCDATA(Parsed Character Data)
  XML 해석기에 의하여 해석되는 문자 데이터를 의미 합니다. 텍스트와 HTML 요소들을 있는 그대로 브라우저로 보내는 것이 아니라 적절하게 렌더링하기 위하여 변환합니다. 예를 들면 ‘<, >’ 기호는 요소의 시작 또는 끝으로 해석하고 ‘&’ 기호는 HTML 문자의 본체(Entity)가 시작되는 것으로 간주 합니다. 따라서 #PCDATA 안쪽에서 ‘&’ 기호를 해석하지 않고 화면에 그대로 표시하려면 HTML Entity 형식을 빌어 ‘&amp;’ 와 같이 작성해야 합니다.
• CDATA(Character Data)
  XML 해석기에 의하여 해석되지 않는 문자 데이터를 의미 합니다. CDATA 안쪽에서 표기하는 모든 문자는 해석기가 해석하지 않기 때문에 브라우저에 그대로 전달 됩니다. 부등호(<, >)와 연산자(&) 사용이 많은 <script> 요소 안쪽에서 웹 브라우저가 이 기호들을 HTML 요소 또는 Entity가 시작되는 것으로 오해하는 것을 예방하기 위하여 CDATA 형식을 선언 <![CDATA[ ... ]]> 하기도 합니다.
• #REQUIRED
  반드시 요구되는.
• #IMPLIED
  생략 가능한. (생략하는 대신 웹 브라우저가 기본 값을 제공하거나 부모로부터 상속을 받기도 함)
• #FIXED
  주어진 값만 사용할 수 있는.

본체와 변수

DTD에서는 본체(Entity)와 변수(Parameter) 개념을 사용합니다. 본체란 변수의 실체(원래 모습)이며 변수는 본체를 대체하는 문자 입니다. <!ENTITY> 구문 안쪽에 선언된 내용들은 본체와 변수에 관한 선언 입니다.

<!ENTITY %  변수 이름  "변수의 실체">

예를 들어 <h1>~</h6> 요소는 %heading; 이라는 변수 이름의 실체 입니다. <h1>~<h6> 요소는 각각의 이름만 다를 뿐 각각의 요소는 모두 동일한 속성과 콘텐츠 모델(자식 요소)을 갖습니다. DTD에서는 같은 내용을 일일이 반복해서 열거하는 것을 피하기 위하여 <h1>~</h6> 요소에 대하여 %heading; 이라는 변수를 선언했습니다. %heading;에 대한 실체는 문서 상단에 한 번 선언해 놓고 본문에서는 <h1>~<h6> 요소 대신에 %heading; 이라는 변수를 사용합니다. 다음 구문은 %heading; 이라는 변수와 본체를 선언하는 구문 입니다.

<!ENTITY % heading "H1|H2|H3|H4|H5|H6">

다음 구문은 DTD 본문에서 %heading; 이라는 변수를 사용한 예 입니다. 퍼센트 ‘%‘ 기호로 시작하여 세미콜론 ‘;‘ 기호로 끝나는 것은 모두 변수이며 모든 변수들은 각각의 실체에 해당하는 본체가 문서 상단에 기술되어 있습니다. (%heading;)의 본체는 (H1|H2|H3|H4|H5|H6) 이므로 아래 구문은 <h1>~<h6> 요소의 명세를 기술하는 구문 입니다.

<!ELEMENT (%heading;)>

요소와 속성

요소에 대한 명세는 <!ELEMENT> 안쪽에 선언되고 이 요소의 속성에 대한 명세는 <!ATTLIST> 안쪽에 선언 됩니다. <!ELEMENT> 구문이 등장하면 곧 관련된 <!ATTLIST> 구문이 자연스럽게 등장합니다.

<!ELEMENT 이곳에 요소의 명세가 들어갑니다>
<!ATTLIST 이곳에 속성의 명세가 들어갑니다>

요소 명세 읽기

요소의 명세는 다음과 같은 순서로 기술하는데 띄어쓰기를 이용해서 각각을 구분 합니다. 

<!ELEMENT  요소 이름  시작 명세  종료 명세  자식 명세  – 주석 –>

‘시작 명세’와 ‘종료 명세’는 단순히 태그가 ‘필수(-)’적인지 또는 ‘생략(O)’할 수 있는지를 선언합니다. ‘자식 명세’는 다른말로 표현해서 ‘허용하는 자식 요소의 형태’라고 이해해도 됩니다. 조금 더 구체적으로 이해하기 위하여 문단을 의미하는 <p> 요소의 명세를 보여 드리겠습니다. 

<!ELEMENT P – O (%inline;)* — paragraph –>

<p> 요소의 명세를 사람이 이해할 수 있는 자연어로 번역하면 다음과 같습니다. %inline; 이라는 변수가 연산을 위한 괄호() 안에 포함되었고 별표 연산자 ‘*’를 통해서 몇 번 사용할 수 있는지도 설명 되었습니다.

P 요소는 시작 태그가 반드시 필요(-)하고 종료 태그는 선택적(O)이다. 인라인 콘텐츠만(%inline;)을 자식으로 가질 수 있는데 이를 생략하거나 한 번 이상 사용(*)할 수 있다. — 문단을 의미한다. –

<p> 요소에 대하여 웹 브라우저 또는 문법 검사기는 다음과 같이 해석할 것입니다.

1. ELEMENT : 요소에 관한 명세임
2. P : 요소 이름은 P
3. - : 시작 태그는 필수적
4. O : 종료 태그는 선택적
5. (%inline;) : 자식 요소로써 인라인 콘텐츠만 허용
6. * : 자식 요소는 생략하거나 한 번 이상 사용 할 수 있음
7. – paragraph — : 문단임

요소 이름 다음에 등장하는 기호 하이픈(-) 또는 알파벳(O)는 시작 태그 또는 종료 태그가 필수적인지 선택적인지를 기술하는데 하이픈(-)은 태그의 선언이 필수적임을 의미하며 알파벳(O)는 선택적으로 생략할 수도 있다(can be Omitted)는 것을 의미 합니다. 만약 시작과 종료 태그가 모두 필수적이라면 ‘P – -’ 이라고 표기 될 것이며 모두 필수적이지 않다면 ‘P O O’ 라고 표기 했을 것입니다.

시작 태그와 종료 태그 다음에 등장하는 ‘자식 명세’는 자식 요소로써 무엇을 허용할 것인지에 대한 내용이 선언됩니다. 예를 들어 HTML/XHTML 호환모드에서 <address> 요소는 기본적으로 인라인 요소만을 허용하나  예외적으로 <p> 요소도 허용하고 있는데 DTD 명세는 이것을 어떻게 설명하는지 확인해 보겠습니다.

<!ELEMENT ADDRESS – - ((%inline;)|P)*  – information on author –>

<address> 요소는 시작과 종료 태그가 모두 필수적이고 인라인(%inline;)요소 또는(|) 문단 요소 <p>를 사용할 수 있다. 자식 요소들은 모두 생략이 가능하고 한 번 이상 사용할 수 있다.

<img> 요소와 같이 자식 요소를 포함하지 않는 요소들은 어떻게 선언할까요? ‘자식 명세’를 정의하는 곳에 EMPTY 라고 적혀 있는 경우 자식 요소를 가질 수 없다는 의미 입니다.

<!ELEMENT IMG – O EMPTY — Embedded image –>

<img> 요소는 시작태그는 필수적이지만 종료태그는 생략 가능한데 자식 요소는 비어(EMPTY)있다.

속성 명세 읽기

속성에 관한 명세는 항상 관련 요소에 대한 명세 다음에 등장하지만 어떤 요소에 대한 설명인지 보다 명확히 하기 위하여 명세 안쪽에 명시적으로 관련 요소 이름을 지명 하고 있습니다. 속성의 명세는 다음과 같은 구조를 갖습니다.

<!ATTLIST  관련 요소 이름을 지명
    속성 이름  속성의 값  속성의 기본 값 또는 필수적인지 아닌지  – 설명 –
>

좀더 구체적으로 이해하기 위하여 <input> 요소에 대한 속성 명세를 예제로 옮겨 왔습니다. 일단 어떤 모양인지 눈여겨 봐 주세요. 이해하기 쉽게 몇 가지 속성만 추렸고 각각을 분리해서 설명드리겠습니다.

<!ATTLIST INPUT 
%attrs;    – %coreattrs, %i18n, %events – 
type    %InputType;    TEXT    – 타입 – 
name    CDATA    #IMPLIED    – 서버측에 넘겨주는 이름 –
>

어떤 요소의 속성에 관한 명세인지 지명하는 부분은 다음과 같이 명세의 첫 번째 줄에 등장 합니다. <input> 요소에 관한 속성 목록을 나열하겠다는 의미로 해석하면 됩니다.

<!ATTLIST INPUT

다음 구문은 온통 퍼센트 %기호로 시작하여 세미콜론; 으로 끝나는 ‘변수’로만 작성되어 있습니다. 이런 경우에는 변수가 무엇을 의미하는지 해석해야 합니다. %attrs; 라는 변수에는 다른 HTML 요소에서도 공통으로 사용되는 전역 속성들의 목록(예를 들면 id, class, style, title과 같은)이 포함되어 있습니다. 그런데 — 주석 — 안쪽에는 %attrs;라는 변수가 또 다른 변수들의 집합이라는 것을 설명하고 있네요.

%attrs;    – %coreattrs, %i18n, %events –

%coreattrs; 라는 변수는 모든 HTML 요소들의 핵심(core) 속성에 해당하는 id, class, style, title 속성을 하나의 변수로 만든것 입니다. 

%i18n; 이라는 변수는 국제화 속성으로써 lang, dir 속성을 하나의 변수로 만들었습니다. %i18n; 이라는 변수 이름은 본래 %internationalization;(%국제화;)이라는 용어가 너무 길어서 알파벳 첫 글자 ‘i’와 마지막 글자 ‘n’ 사이에 있는 18개의 알파벳을 모두 표기하지 않고 숫자로 바꿔 표기한 것입니다. 국제화 속성의 하나인 lang 속성은 콘텐츠의 자연어가 어떤 언어인지(예를 들면 영어인지 한국어인지) 지정하는 속성이고 dir 이라는 속성은 문자의 방향(direction)에 관한 속성 입니다. 대부분의 언어가 왼쪽에서 오른쪽으로(Left To Right) 읽고 쓰기 때문에 기본값은 dir="ltr" 이고 모든 요소에서 생략되어 있습니다. 만약 아랍어라면 dir="rtl" (Right To Left) 으로 지정하여 기본 ‘ltr’ 으로 설정된 방향 속성을 ‘rtl’ 으로 덮어쓰기 해야 할 것입니다.  

%events; 라는 변수는 자바스크립트 이벤트 핸들러들의 집합으로써 다음과 같습니다. 

• onclick     — 버튼을 누른 후 뗌 –
• ondblclick     — 버튼을 연달아 두 번 클릭 –
• onmousedown     — 버튼 누름 –
• onmouseup     — 버튼 뗌 –
• onmouseover     — 마우스 포인터가 위에 있는 –
• onmousemove     — 마우스 포인터가 움직임 –
• onmouseout     — 마우스 포인터가 벗어남 –
• onkeypress     — 키를 누른 후 뗌 –
• onkeydown     — 키를 누름 –
• onkeyup     — 키를 뗌 –

다음은 type 이라는 속성에 관한 명세 부분 입니다. ‘속성 이름, 속성의 값, 속성의 기본 값’ 순으로 명시되어 있습니다. 속성이 ‘필수적인지 아닌지’의 여부는 표시되지 않았는데 왜냐하면 ‘속성의 기본 값’이 표기되어 있기 때문입니다. 속성에 기본 값이 있다는 것은 속성을 생략할 수 있다는 의미로 해석이 가능하기 때문에 #IMPLIED라는 설명은 생략되었습니다.

 type    %InputType;    TEXT    – 타입 –

사람이 이해할 수 있는 말로 type 속성에 관한 명세를 풀어보면 다음과 같이 해석할 수 있습니다.

<input> 요소에는 말이지 type 이라는 속성이 있어
type 이라는 속성은 %InputType; 이라는 값을 가질 수 있는데
%InputType;은 TEXT | PASSWORD | CHECKBOX | RADIO | SUBMIT | RESET |    FILE | HIDDEN | IMAGE | BUTTON 이런 값들을 가질 수 있지
그리고 이 많은 값 가운데 기본값은 TEXT 란다
type="text" 이것이 <input> 요소의 기본 값이라는 거지
속성에 대한 기본 값이 있기 때문에 이 속성은 생략(#IMPLIED)할 수도 있단다

다음은 name 속성에 관한 명세 입니다.

name    CDATA    #IMPLIED    – 서버측에 넘겨주는 이름 –

name 속성은 값으로써 CDATA(브라우저가 해석하거나 변조하지 않고 전달이 가능한 순수한 문자들)만 올 수 있는데 이 속성은 생략할 수 있다는 의미 입니다.

참고

• HTML 4.01 Transitional DTD – http://www.w3.org/TR/html401/loose.dtd | http://www.w3.org/TR/1999/REC-html401-19991224/sgml/loosedtd.html
• HTML 4.01 Strict DTD - http://www.w3.org/TR/1999/REC-html401-19991224/strict.dtd | http://www.w3.org/TR/1999/REC-html401-19991224/sgml/dtd.html
• XHTML 1.0 DTDs – http://www.w3.org/TR/xhtml1/dtds.html
• XHTML 1.0 Transitional DTD – http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd 
• XHTML 1.0 Strict DTD - http://trio.co.kr/webrefer/xhtml/dtd/xhtml1-strict.dtd
• How to read the HTML DTD – http://www.w3.org/TR/html401/intro/sgmltut.html#h-3.3
• DTD 어떻게 읽는지 아세요? – http://www.pageoff.net/794

<div> 요소를 ‘디브, 딥, 디-아이-브이’ 라고 읽는 경우 업계 전문가들은 이것이 무엇을 말하는지 쉽게 알기 때문에 아무 문제가 없습니다. 그러나 이 표현을 듣는 비 전문가들은 <div> 요소에 대하여 발음만 피상적으로 기억하게 될 뿐입니다. 저는 HTML이 전문적인 용어로 취급되거나 전문가들의 전유물이 되어서는 안된다는 생각 때문에 이것을 풀어서 읽어야 한다고 주장합니다.

‘디비젼’이라고 읽게 되면 듣는 사람으로 하여금 ‘division’ = ‘분할’ 이라는 의미를 떠올리게 되고 이것은 <div> 요소의 본래 의미나 바른 용법을 알고자 할 때 중요한 단서가 될 것입니다. ‘디브’라고 표현할 때 ‘dive(뛰어들다), divert(우회시키다), diverse(다양한) …’와 같은 전혀 다른 의미의 용어를 떠올리는 실수는 하지 않게 되겠죠.

아래 열거하는 요소들은 모두 표준 HTML 요소들 입니다. 이 요소들의 공통점은 모두 어떤 단어들이 축약되어 HTML 요소 이름으로 정해진 것들입니다. 한 가지 재미난 실험을 해볼까요? 아래 요소들을 보이는 그대로 읽어서 비 전문가에게 전달한 다음 어떤 의미인지 알아맞혀 보라고 퀴즈를 내보십시오. 풀어쓴 말이 무엇인지. 요소들의 본래 의미가 무었인지. 또한 나는 얼마나 알고 있는지 스스로를 평가해 보십시오. 괄호 안쪽을 드래그 하면 풀어쓴 말을 볼 수 있습니다. 먼저 여러분의 답을 떠올리고 그 다음 풀어쓴 말을 확인해 보십시오.

• abbr (abbreviation)
• cite (citation)
• del (delete)
• dfn (definition)
• div (division)
• em (emphasis)
• img (image)
• ins (insert)
• kbd (keyboard)
• optgroup (option group)
• param (parameter)
• pre (preformatted)
• samp (sample)
• sub (subscript)
• sup (superscript)
• var (variable)

100점을 기록하신 분이 있다면 축하드립니다. 댓글에 코멘트 한 줄 부탁 드립니다. 저도 100점 못 받았거든요. 만약 HTML을 보이는 그대로 읽지 않고 풀어쓴 표현으로 발음한다면 어떠했을까요? 상황이 지금보다 더 좋아지지 않았을까요?

웹의 보편성을 생각할 때 HTML은 모두가 다루기 쉬워야 하고 사용하고 있는 언어가 장벽으로 작용해서는 안된다고 생각합니다. 초등학생들도 HTML을 배웁니다.

웹 전문가 여러분께 질문 드립니다. 전문가들 사이에서만 통하는 말을 하시겠습니까? 되도록 모두가 이해하기 쉬운 표현을 위해 노력 하시겠습니까? 정말 전문가라면 비 전문가인 대중에게 자신의 분야를 쉽게 설명할 수 있어야 하지 않을런지요.

모두가 이해하기 쉬운 표현을 위한 노력에 동참해 주실 분들은 HTML 요소 이름의 풀어쓴 말과 한국말 표현 페이지를 참고해 주세요. 의견도 가감없이 부탁 드립니다. 감사합니다.

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

• "웹 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에 과부하를 주는 문제가 있어 본문에 삽입했던 프리젠테이션을 제거 했습니다. 프리젠테이션 버전 링크를 이용해 주세요. 감사합니다.