심사는 크게 ‘사전심사 > 전문가 심사 > 사용자 심사’ 과정을 거칩니다. 사전 심사는 품질마크 일부 지표와 접근성 검사 도구를 활용한 약식 검사로 진행됩니다. 전문가 심사는 웹 접근성 전문가에 의하여 전수조사 형식으로 진행 됩니다. 그러나 모든 페이지를 검사하지는 않으며 웹 접근성 저해요소가 많은 페이지를 표본으로 추출한 뒤 이를 기반으로 심사합니다. 사용자 심사는 실제 장애인에 의하여 진행되고 장애인은 주어진 과업(예를 들면 회원가입 및 게시판 글쓰기)을 완수해야 합니다.

웹 접근성 품질마크는 KWCAG 1.0 국가 표준을 참고하여 이 지침을 준수하는지의 여부를 측정하는 ’18개’의 지표로 구성되어 있는데 품질마크 인증을 획득하려면 각각의 지표에 대하여 전문가 심사에서 모두 ’95점’ 이상을 획득해야 합니다. 전문가 심사를 통과했다 하더라도 사용자 심사에서 장애인 사용자가 주어진 과업을 95% 이상 완수할 수 없는 경우 품질마크를 획득할 수 없습니다.

KWCAG 1.0 버전은 국제 웹 접근성 지침인 WCAG 2.0 지침의 수준 A 항목을 참고(부분적으로 수준 AA 참고)하여 제작 되었습니다. 즉, 웹 접근성 품질마크 인증을 획득하는 경우 KWCAG 1.0 국가 표준 지침을 준수하는 동시에 WCAG 2.0 지침의 수준 A에 이르기 쉽도록 되어 있습니다. 여기서 ‘수준 A’란 웹 접근성이 요구하는 최소한의 수준으로써 웹 사이트가 접근성이 있다고 말할 수 있는 국제적 기본 수준을 의미합니다.

한국정보화진흥원은 2009년 KWCAG 2.0을 개발하여 한국정보통신기술협회(TTA)에 표준으로 등록 했으며 2011년에는 현재의 국가 표준인 KWCAG 1.0을 대체할 것입니다. KWCAG 2.0 지침은 KWCAG 1.0 지침을 보완하기 위하여 2개의 지침을 삭제하고 9개의 지침을 새롭게 추가했으며 그 밖에 기존의 지침을 다듬어 계승했습니다.

다음 표는 ‘웹 접근성 품질마크, KWCAG 1.0, KWCAG 2.0, WCAG 2.0(수준 A, 수준 AA)’ 지침을 관련된 항목끼리 분류한 것입니다. 웹 접근성 품질마크 인증을 획득하기 위한 18개 지표를 이해하는데 활용하시기 바랍니다.

Perceivable (인식의 용이성)

정보와 인터페이스 구성요소는 사용자가 인지할 수 있는 방법으로 표시해야 한다는 지침 입니다.

Operable (운용의 용이성)

사용자 인터페이스 구성요소와 탐색 기능은 조작이 가능해야 한다는 지침 입니다.

Understandable (이해의 용이성)

정보와 사용자 인터페이스 조작은 이해할 수 있어야 한다는 지침 입니다.

Robust (견고성)

콘텐츠는 보조 기술을 포함한 다양한 사용자 응용 프로그램에 의하여 해석이 가능하도록 충분히 견고해야 한다는 지침 입니다.

Etc (기타)

그 밖에 웹 접근성 품질마크 지표에는 존재하지 않지만 KWCAG 1.0/2.0 지침에 포함된 항목과 WCAG 2.0 에서 수준 A 또는 AA로 중요하게 취급하는 추가 지표는 다음과 같습니다.

1. 제1회(2006년 9월) - 제1회 Css Design Korea 참가 후기.
2. 제2회(2006년 12월) - 2nd Web Standards Day, 웹 표준 개발자들의 잔치.
3. 제3회(2009년 2월) - 웹 표준을 넘어서…

최근에 만났던 몇몇 분들께서는 저를 보고 마치 연예인 보는것 같았다는 말씀들을 해주셔서 좀 쑥스럽기도 한데요. 제가 이 행사를 통해서 신현석님, 조훈님, 윤석찬님, 만박님을 처음 뵐 때에도 그랬었답니다. ㅋㅋㅋ

웹 표준이라는 주제에 관심을 가지고 알고자 했을 때 이 분들이 없었다면 무척 많은 시행착오가 있었을꺼예요. 시행착오는 뭐 지금도 하고 있기는 하지만 이 분들 덕분에 조금 더 쉽게 지나왔기에 항상 존경하고 스승같이 생각하고 있습니다. 때때로 이 분들의 어떤 생각에는 공감하지 못하는 상황에서도 그 사실만은 변함이 없답니다.

제4회 웹 표준의 날 행사 분위기는 참여했던 다른 분들의 포스팅을 통해서도 확인하실 수 있기 때문에 행사 풍경을 전해드리는 것은 생략하고 웹 표준의날에 대한 개인적인 바램을 적어볼까 합니다.

웹 표준의날은 동종 업계에서 동료 의식을 지닌 분들이 모여 옳은 철학과 최신 정보와 인맥을 교류하는 장으로 자리매김 되었다고 생각합니다. 지금도 부족함이 없지만 더 많은 것을 바란다면 ‘이 분야의 칭찬거리’를 발굴하는 장으로 거듭났으면 합니다.

저는 제2회를 제외하고 모두 발표자로 참여했었는데요. 이제는 저보다 더 뛰어난 후배님들께서 나서주셨으면 합니다. 저와 같거나 오히려 더 뛰어난 능력을 가진 분들이 많다는 것을 저는 잘 알고 있습니다.  아무리 나이가 어리고 경력이 짧아도 자기 분야에 대한 옳은 철학과 열정을 지닌 분들을 존경합니다. 다음 웹 표준의 날에는 그런 후배님들이 나와서 웹 표준의 날을 상큼하게 빛내 주셨으면 좋겠습니다. 

그리고 이번에 새롭게 시작된 골든벨 형식의 웹 표준 경진대회도 좋았는데요. 다음 회차부터는 ‘유니버설 웹 어워드’ 라는 주제로 특정 기간 동안 제작된 웹 사이트 가운데 웹 표준과 웹 접근성을 잘 지켜서 장애가 있고 없고를 떠나 누구나 이용할 수 있도록 만들어진 그런 사이트를 ‘추천하고 발굴하고 시상’하는 것은 어떨까요?

이런 상이 있다면 웹 표준의 날은 어쩌다 한 번 오는 그런 날이 아니라 누구나 손 꼽아 기다리는 그런 날이 되지 않을까요? 그 어떤 경품보다도 값진 상이 되지 않을까요?

그리고 갑자기 쌩뚱맞을 수도 있지만 저와 같은 업계에서 저와 같은 직군 ‘웹 디자이너, 웹 퍼블리셔, UI 개발자, 웹 개발자’로서 종사하는 동료 여러분께 한 가지 제안을 드리고 싶습니다. 일은 넘치고, 전문 인력은 턱없이 부족하고, 연봉 수준은 이런 상황에 맞지 않게 너무 짜고, 지금 하고 있는 일은 마치 노동집약형 산업이 아닐까? 라고 생각하지는 않으시는지요?

이런 상황을 타개하는 방법으로써 저는 다음과 같은 행동 강령이 필요하다고 생각합니다.

1. 첫째, 매일 야근을 하지 않으려면 더 많은 전문 인력이 시장에 투입되어야 합니다. 하루라도 빨리 부사수가 채용되길 원하신다면 여러분들의 지식을 아낌없이 회사 밖에 있는 후배들에게도 나누어 주세요.
2. 둘째, 노동집약형 산업을 벗어나려면 부가 가치를 만들어야 합니다. 완벽한 HTML/CSS/JS 코드를 생산하는 일보다 더 중요한 것은 그 코드의 가치를 인정 받는 일 입니다. 여러분의 코드가 단순히 문법적으로만 유효한 코드가 아니라는 것을 증명해 주세요.
3. 셋째, 협업하는 분들이 웹 표준 모른다고 구박만 하지 마시고 친절하세요. 우리가 하고 있는 일의 가치를 가장 가까이에서 제대로 평가해 줄 수 있는 분들이고 저희를 필요로 하는 분들이기 때문입니다.

CSS3 말고 요런걸 발표할껄 그랬나요? ^^; CSS3 발표자료는 여기 있습니다.  9 Useful CSS3 Properties.

안녕하세요? NHN 오픈UI기술팀에 근무하는 정찬명 입니다. 저는 장애인이 아니며 그 분들을 잘 알고 있는 것도 아닙니다. 다만 한 가지 공통점은 있습니다. 바로 ‘특별한 어떤 욕구를 느낀다’는 것입니다. 그리고 이 욕구는 장애인이건 비장애인이건 모두 특수하고 다양합니다. 이 점이 제가 생각하는 유니버설 디자인의 출발점입니다.

‘분리’와 ‘별도의 배려’라는 해결책에 대해

얼마 전 한 국가 산하 기관에서는 마우스의 드래그 앤 드롭을 이용한 비밀번호 입력장치를 세계 최초로 개발했다는 소식을 발표 했습니다. 그러나 마우스를 사용할 수 없는 장애인이 어떻게 사용할 수 있는지, 보충 설명이 없었기 때문에 장애인 단체는 장애인에 대한 배려 없음을 강력하게 비판 했습니다. 어떤 분들은 “장애인을 위한 별도의 방식을 만들어 보완하면 된다”는 대안을 제기하기도 했습니다. 하지만 저는 동의할 수 없었습니다. ‘별도의 배려’라는 해결책은 장애인과 비장애인을 성급히 구분하기 때문입니다.

‘장애인차별금지 및 권리구제 등에 관한 법률’은 차별에 대해 ‘장애를 사유로 정당한 사유 없이 제한, 배제, 분리, 거부 등으로 불리하게 대하는 경우, 그리고 이와 같은 사유로 불리하게 대하지 않지만 장애를 고려하지 않은 기준을 적용함으로써 장애인에게 불리한 결과를 초래하는 것’이라고 정의하고 있습니다.

마우스를 사용한 비밀번호 입력장치는 의도하지 않았지만 장애인을 해당 서비스와 분리시키는 결과를 가져왔습니다. 법 조항을 엄밀히 따지자면 차별에 해당할 수 있을 것입니다. 하지만 ‘차별이냐 아니냐’ 보다 더 중요한 일이 있습니다. 애초부터 장애인, 비장애인 모두가 이용할 수 있는 방법을 고민할 수는 없었을까 하는 것입니다. 

장애인 전용 엘리베이터를 이용하도록 하는 것을 과연 장애인들은 원할까요? 장애인 전용 홈페이지를 이용하도록 하는 것을 장애인들은 원할까요? 그 누구도 특별한 욕구가 있다고 해서 특별히 분리되는 것을 원하지는 않을 것입니다.

다양한 욕구의 수용 방법에 대해

우리가 접하는 모든 제품들은 가치의 산물입니다. 어떤 제품이 시장에 나오기까지 수 많은 사람들의 가치가 개입 됩니다. 디자이너는 더 아름답게, 엔지니어는 보다 기능적으로, 영업사원은 그 제품이 더 많이 팔리기를 원할 것입니다. 제품은 시장에 나오기까지 이런 다양한 가치들을 아우르기 위하여 치열하게 경합하게 되고 소비자들은 그런 가치의 총합인 물건을 구입하게 됩니다. 그렇다면 시장에서 많은 사람들에게 오랜 시간 사랑 받는 제품은 어떤 공통된 가치를 포함하고 있을까요? 다양한 공통점이 있겠지만 그 중의 하나는 바로 ‘다양한 욕구’에 대한 수용 이라고 생각 합니다.

제 아들은 아직 초등학교에 입학하지 않은 어린 남자아이 인데요. 가끔 공중 화장실에서 미안한 생각이 들 때가 있습니다. 화장실의 남자 소변기가 너무 높은 곳에 매달려 있기 때문입니다. 엘리베이터를 탔을 때에도 비슷한 경험을 합니다. 고층으로 이동해야 하는데 아이는 수직으로 배치되어 있는 층별 버튼 가운데 키가 닿지 않는 버튼이 있습니다. 여섯 살이면 혼자서도 엘리베이터를 조작할 줄 아는데 키가 작아서 어른의 도움을 필요로 하는 경우가 있습니다.

휠체어를 탄 지체 장애인도 마찬가지 입니다. 엘리베이터의 버튼은 보다 낮은 곳에 수평으로 배치해 두면 애초부터 모두가 편하지 않았을까요? 또 시각 장애인을 위해 점자 버튼을 추가하는 일은 비효율적인 발상일까요?

최근에는 ‘터치’로 작동하는 전자제품들이 많이 쏟아져 나오고 있는데요. 이런 제품들이 오랜 시간 사랑 받으려면 무엇을 개선해야 할까요? 조작 방법을 시각에만 완전히 의존하도록 하지 않는다면 주머니 속에 넣고도 간단한 기능은 조작할 수 있지 않을까요? 다양한 사람들의 욕구를 처음부터 고려하는 것은 비용만 많이 들어가는 골치 아픈 일일까요?

특별한 시선은 불편할 수 있습니다

어떤 분들은 장애인을 장애우라고 부르기도 하는데요. 한국장애인단체총연합회에서는 이와 같은 용어의 사용을 중단할 것을 요청 했습니다. 사실 장애를 가진 분들 가운데는 ‘친구’ 이상의 연배를 가진 분들도 많습니다. 이분들을 모두 뭉뚱그려 ‘친구’라고 부르는 것은 우리 사회의 장애인에 대한 어떤 시각의 단면일 수도 있습니다.

잘 아시는 것처럼 장애인은 특정 집단으로 분류하거나 시혜의 대상으로 보는 시선에 대하여 거부감을 느끼고 있습니다. 때문에 장애인을 위하여 ‘무엇을 했다’ 라는 생색내기도 그리 달갑게 받아들이지 않습니다. 특별한 시선과 동정의 눈빛은 오히려 벽과 같다는 게 장애인들의 입장입니다.

저는 개인적으로는 ‘장애라는 말을 사람에게 쓰는 것 자체가 문제가 아닐까’라는 생각을 합니다.  진짜 장애는 ‘다른 욕구를 지닌 사람을 돕지 못하는 환경’에 있는 것이지 ‘조금 다른 사람’에게 있는 것이 아니기 때문입니다. 장애 유무를 떠나서 누군가는 나와 조금 다른 것을 자연스럽게 받아들일 수 있도록 모두가 더 노력해야 될 것 같습니다. (물론 저를 포함해서 ^^) 앞으로 네이버 서비스가 차별, 다름이 없는 서비스가 될 수 있도록 더 노력하겠습니다. 감사합니다.

관련 포스트

‘어둠 속의 대화’ 전시 체험
‘모두를 위한 설계’ 유니버설디자인

전적으로 마우스(드래그 앤 드롭)를 이용한 비밀번호 입력 방식으로 키보드 사용자는 이용할 수 없다.

시각장애인은 마우스 포인터를 볼 수 없기 때문에 마우스를 사용할 수 없습니다. 또한 팔을 자유롭게 사용할 수 없는 지체 장애인은 마우스를 사용할 수 없기 때문에 마우스 스틱(빨대 모양의 막대기)이라는 장비를 이용해서 키보드를 두드립니다. 태어 날때부터 이런 장애를 지닌 사람도 있고 불의의 사고를 당해서 이렇게 되신 분들도 있습니다. 이런 장애인들은 비밀번호를 어떻게 입력해야 하나요?

더군다나 한국인터넷진흥원 이라는 곳에서 이런 기술을 개발했다고 하는데 이건 한국 인터넷을 진흥 시키기는 커녕 오히려 한국 인터넷을 망치는 기술 입니다. 이런 기술을 사용하게 되면 장애인차별금지 및 권리구제 등에 관한 법률에 의하여 소송 대상이 되고 법적 분쟁에 휘말렸을 경우 승소할 확률은 0% 입니다.

사용하지 말아야 할 기술 입니다.

스마트폰에서도 쓸 수 있는 방안을 마련한다구요? 일단 스마트폰에는 마우스가 없구요. 마우스 전용 이벤트 헨들러 같은 것도 없습니다. 스마트폰에서 마우스를 이용할 수 있는 전용 어플리케이션이라도 지원 하시게요? 어떻게 하시려는지 참 궁금합니다. 그것도 세계 최초로 개발해서 같이 특허 내십시오.

다 같이 잘 살기가 이렇게 힘들어서야 원.

• [단독]비밀번호 입력, 마우스로 ‘드래그’
• 마우스를 쓰지 못하는 사람은 어떻게? – 비밀번호 입력, 마우스로 드래그
• 마우스만을 이용하는 패스워드 입력장치 키보드를 사용할 수 없는 한 통용될 수 없다
• 키보드 안쓰는 패스워드 방식…"웹 접근성 외면" 장애인 단체 반발

• ul > li > (p+p)
• ul > li > (hx+p)
• ul > li > dl > (dt+dd)
• dl > (dt+dd) + (dt+dd) + (dt+dd) …
• dl(dt+dd) + dl(dt+dd) + dl(dt+dd) …

오늘 제가 선택한 방법은 첫 번째 방법 이었습니다. 이 방법이 정답이라고 단적으로 말하기는 어렵고 다른 방법이 틀렸다고 말하기도 어렵습니다. HTML 구조에 정답이 있는것은 아니니까요. 하지만 제가 첫 번째 마크업을 선택한 이유를 설명드려 보겠습니다. 솔직히 말씀 드리자면 이 선택에 대한 확신은 아직 없습니다.

• 질문과 답변 목록은 ‘목록’ 이기 때문에 일단 ‘ul, ol, dl’ 요소 가운데 하나를 사용하는 것이 적합하다고 판단 했습니다.
• ‘ol’ 목록은 항목의 배치 순서에 의미가 있는 경우 사용하면 되는데 ‘질문/답변’ 목록은 배치 순서를 바꿔도 의미가 달라지지 않는 비 순차 목록이라고 판단해서 제외 했습니다.
• ‘ul’ 목록은 항목의 배치 순서에 의미가 없는 경우 사용하면 되는데 ‘질문/답변’ 목록은 배치 순서에 의미가 없다고 판단해서 사용 했습니다.
• ‘dl’ 목록은 정의 목록으로써 질문과 답변 형식에 사용해도 괜찮다고 판단 했지만 한 쌍의 ‘dt+dd’ 요소를 한 번 더 감싸주는 마크업이 필요한 경우 CSS 스타일을 적용하는데 제한이 발생하기 때문에 제외 했습니다.
• ‘dl+dl’ 형식은 ‘dl’ 요소를 ‘항목의 그룹핑’ 아닌 단 하나의 ‘항목’에만 적용했기 때문에 의미에 맞지 않다고 판단해서 제외 했습니다.
• ‘li > dl > (dt+dd)’ 형식은 목록 안에 또 다른 목록을 포함시키는 형태로써 하나의 항목을 두 번이나 목록 요소로 중첩 마크업 하는 것이 남용이라고 판단해서 제외 했습니다.
• ‘ul > li > (p+p)’ 형식으로 마크업 하는 것은 ‘질문/답변’을 모두 각각의 문단으로 볼 수 있기 때문에 적합하다고 판단 했습니다. 그러나 ‘질문’과 ‘답변’을 동일한 요소 ‘p’로 마크업 했다는 점에서 여전히 뒷맛이 개운치가 않네요.
• ‘li > (hx+p)’ 형식은 목록 안에 제목(hx) 요소가 들어가는 형태로써 의미상 가장 적합하다고 판단 했지만 목록 안에서 ‘hx’ 요소를 사용하는 것이 ‘hx’를 남용하는 것은 아닌지 구조의 적절함에 확신이 서지 않아서 제외 했습니다. 그러나 만약 ‘li>(p+p)’ 구조를 선택하지 않았다면 이것을 선택했을 것입니다.
• 만약 한 쌍의 ‘(dt+dd)’ 요소를 ‘dl’ 요소로 직접 감싸는 대신 ‘di’(definition item)와 같이 한번 더 묶어주는 마크업 요소가 존재 했다면 저는 ‘dl’ 요소를 선택했을 것입니다. 제가 이상적이라고 생각하는 마크업 구조는 ‘dl > di > (dt+dd)’ 이런 구조 인데 ‘di’ 요소는 실제로는 존재하지 않는 요소이므로 착오 없으시길 바랍니다.

a 요소에 유효한 URL 사용하기

질문은 ‘a’ 요소로 마크업 되어 있고 ‘href’ 값으로는 유효한 ‘URL’(#a1, #a2, #a3 …)이 포함되어 있습니다. 유효하다는 것은 링크의 목적지가 존재하고 링크 주소를 따라가면 기대했던 자원이 있다는 것을 의미 합니다. 만약 누군가에게 특정 ‘질문/답변’ 항목을 링크 주소를 통해 알려주어야 한다면 여러분은 마우스 우측 버튼을 눌러 ‘링크 주소 복사’ 기능을 이용할 수 있을 것입니다. URL이 유효하지 않다면 이런 편의는 불가능한 일입니다. ‘href’ 값으로 의미 없는 값 ‘#’을 넣는다면 클릭 또는 키보드 Enter를 내리 쳤을 때 키보드 포커스는 페이지 맨 처음으로 이동해 버리기 때문에 화면 낭독기 사용자(시각 장애인)는 처음부터 다시 탐색을 시도해야 합니다. 유효한 URL을 작성하는 것은 사용성과 접근성을 모두 높여주는 일로써 되도록 모든 링크에는 유효한 URL 값을 포함해야 합니다.

관련글

• FAQ의 의미 있는 마크업은? - 추지호
• 목록(ol ul dl)의 올바른 활용 문제 – 백남중

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

중첩 목록(ul>li>ul>li) 구조로 마크업 했고 현재 페이지 활성 상태를 표시 하려면 해당 li 요소에 .active 클래스를 추가(서버측 스크립트로)해 주면 됩니다. 계층 구조가 무한대로 깊어지는 상황도 처리가 가능 합니다. ‘+/-’ 토글 버튼에 키보드가 접근해서 하위 목록 토글 인터렉션을 조작할 수 있습니다.

예제를 새 창으로 보기

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

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

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

특징

• 중첩 목록(ul>li>ul>li) 구조로 마크업 했습니다.
• 키보드만으로도 조작이 가능하고 키보드의 접근 순서는 논리적으로 처리되어 있습니다.
• 서브메뉴 토글에 jQuery의 .slideDown() 및 .slideUp() 효과를 사용 했습니다.
• 이미지를 한 번 사용 했습니다.

유의사항

간혹 이런 수직 메뉴의 서브 메뉴 펼침 동작을 onmouseover 이벤트 헨들러로 처리하는 경우가 있는데요. 그런 경우 사용성이나 접근성이 정말 나빠집니다. 

사용성이 나빠지는 이유는 아래쪽에 있는 메뉴를 선택하기 위하여 링크 위를 onmouseover 하는 순간 해당 링크의 서브 메뉴가 펼쳐지는데 이는 보통 원치 않는 동작이기 때문입니다. 

접근성이 나빠지는 이유는 마우스와 동등하게 키보드가 접근할 수 있도록 onmouseover 헨들러와 onfocus 헨들러를 병행해서 작성하지 않는 경우 입니다. 이런 경우 키보드가 서브 메뉴를 펼칠 수 없기 때문에 키보드 사용자는 서브 메뉴에 접근할 수 없습니다. onmouseover 헨들러를 사용했다면 반드시 onfocus 헨들러를 병행 작성하여 동등한 기능을 처리할 수 있도록 해야 합니다.

따라서 수직 메뉴를 드롭다운 형태로 열고 닫는 오늘의 예제와 같은 경우 onmouseover 이벤트 헨들러 사용은 절대적으로 피하는 것이 좋고 onmouseover 이벤트 헨들러 사용은 보편적인 다른 모든 경우에도 최소화 하는 것이 좋습니다.

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