NARADESIGN:BLOG

WCAG 2.0 지침이 전하는 전경색과 배경색의 명도 대비.

정찬명 — Tue, 30 Jun 2009 20:41:26 +0000

WCAG 2.0 지침에는 글꼴의 색과 문서의 배경 색이 어느 정도의 명도 대비를 지녀야 하는지에 대한 지침이 있습니다. 하지만 지침이 제시하는 것을 실무에 바로 적용하기가 어려운데 이는 지침이 제시하는 구체적인 숫자의 의미와 적합성 수준에 대한 이해를 요구하기 때문 입니다.

WCAG 2.0에서 적합성 수준의 의미.

WCAG 2.0 지침에서 ‘적합성 수준’이란 세부 지침들이 갖는 중요도를 3단계로 분류함으로써 웹 사이트의 접근성 정책을 세우는데 기준을 마련하고 웹 사이트 구축 후에는 어느 정도 수준까지 접근성을 확보 했는지 되도록 알기 쉽게 설명하려는 목적이 있습니다. 수준 ‘A’는 중요도가 가장 높고 비교적 달성이 용이한 최소한의 등급이며 수준 ‘AAA’는 중요도가 가장 낮지만 달성하기가 어렵고 달성 했을때 접근성이 극대화 되는 매우 까다로운 수준 이라고 설명할 수 있습니다.

A : 웹 접근성을 확보했다는 주장을 펼치기 위하여 반드시 지켜야 할 최소한의 수준으로써 강력하게 권장된다.
AA : 최소한의 수준을 넘어서 보다 향상된 접근성을 갖추기 위한 수준으로써 권장된다.
AAA : 웹 접근성을 극대화 하고자 할 때 갖추어야 할 수준으로써 이 수준은 의무화 하기에 너무 어려울 수도 있다.

즉, 적합성 수준이란 딱히 각각의 수준에 특별한 의미가 있는 것이 아니라 지침의 중요도에 따라서 등급을 매긴 것에 불과 합니다. 만약 여러분의 웹 사이트가 적합성 수준이 ‘A’라고 표기된 지침을 모두 지켰다면 여러분의 웹 사이트에 대한 접근성 수준은 ‘A’라고 부를 수 있을 것입니다. ‘A’ 정도만 되어도 훌륭한 것입니다. 만약 이 수준이 형편 없는 수준이라는 평가를 받아야 했다면 아마 ‘C’라고 명명했을지도 모릅니다.

전경색과 배경색의 명도 대비에 관한 지침.

1.4.3 명암 대비 (최소한의): 다음과 같은 경우를 제외하고 문자와 문자 이미지의 시각적인 표현은 최소한 4.5:1의 명암 대비를 부여해야 한다.(수준 AA)

큰 문자: 큰 비율의 문자와 큰 비율의 이미지 문자는 적어도 3:1의 명암 비율을 갖는다.

기타: 순수하게 장식적이며 누구라도 알아볼 수 없는 문자와 이미지 문자 또는 사진과 같이 시각적으로 의미를 전달하는 피상적 사용자 인터페이스 구성요소는 명암비를 필요로 하지 않는다.

로고타입: 로고나 브랜드 이름에 포함된 문자는 최소 명암비를 필요로 하지 않는다.

1.4.6 명암 대비 (향상): 다음과 같은 경우를 제외하고 문자의 시각 표현과 문자 이미지는 적어도 7:1의 명암대비를 부여해야 한다.(수준 AAA)

큰 문자: 큰 비율의 문자와 큰 비율의 이미지 문자는 적어도 4.5:1의 명암 비율을 갖는다.

기타: 순수하게 장식적이며 누구라도 알아볼 수 없는 문자와 이미지 문자 또는 사진과 같이 시각적으로 의미를 전달하는 피상적 사용자 인터페이스 구성요소는 명암비를 필요로 하지 않는다.

로고타입: 로고나 브랜드 이름에 포함된 문자는 최소 명암비를 필요로 하지 않는다.

모든 전경 글꼴과 배경 색은 최소한 4.5:1의 명암 대비를 만족해야 한다.

명암 대비는 글꼴의 크기 또는 굵기과 밀접한 관계가 있습니다. 따라서 모든 크기의 글꼴에 4.5:1의 명암 대비를 부여해야 하는 것은 아닙니다. 만약 글꼴이 크거나 굵다면 명암 대비는 조금 더 완화된 기준을 적용해도 됩니다. 지침에서는 큰 문자(18pt 이상 또는 14pt 굵은 글꼴)에 한하여 3:1 수준의 명암 대비를 갖출것을 요구하고 있으며 이는 일반적인 크기의 글꼴(약 12~14px 정도)이 4.5:1의 명암 대비를 갖추어야 하는 것으로부터 조금 완화된 기준 입니다.

WCAG 2.0 지침은 명암의 강도를 ‘1~21′ 단계로 나누고 명암을 전혀 구분할 수 없는 상태를 ‘1:1′(white:white) 으로 표현하며 전경과 배경이 확연하게 구분되는 상태를 ‘21:1′(black:white) 으로 표현 합니다.

사람이 이 명암의 등급을 정확히 판별하는 것은 어렵기 때문에 여기서 실무 적용시 애로 사항이 발생하게 되고 빈번하게 사용되는 색에 대한 사용 메뉴얼을 필요로 하게 됩니다. 이것을 도와주는 것이 바로 색 분석 도구 인데 웹에서 즉시 판별할 수 있고 또는 전용 소프트웨어를 설치해도 됩니다.

전경/배경색 명암 대비 분석 도구들.

Colour Contrast Check(snook.ca) – http://www.snook.ca/technical/colour_contrast/colour.html
Colour Contrast(Juicy Studio) – http://juicystudio.com/services/luminositycontrastratio.php
Colour Contrast Analyzer(Colors on the web) – http://www.colorsontheweb.com/colorcontrast.asp
Contrast Analyser(The Paciello Group) – http://www.paciellogroup.com/resources/contrast-analyser.html Windows/MAC Application.

사용해 본 결과 Colour Contrast Check(snook.ca) 도구가 가장 섬세하게 필요한 정보들을 제공해 주고 있어서 충분히 만족스러웠습니다.

WCAG 2.0 지침의 명도 대비 적합성 수준을 표시한 전경/배경색 사용 예.

모든 예를 표시할 수 없기 때문에 일반적으로 널리 사용되고 있는 흰색 배경에 무채색 글자를 표현 하였습니다. 붉은색 글씨로 Passed 표시가 된 글꼴의 명도 대비는 적어도 WCAG 2.0의 AA(지침1.4.3) 또는 AAA(지침1.4.6) 수준을 만족한다는 의미 입니다. 이 표로 알 수 있는 것은 12px 글꼴을 사용할 때 회색의 밝기는 적어도 ‘#767676′ 이 되어야만 ‘노안, 약시, 또는 일시적으로 정상 시력을 갖지 못한 사람들’에게 웹 문서가 편안하게 보인다는 사실 입니다. 이 밖의 다양한 글꼴 색 또는 배경 색에 대한 조합은 앞서 소개드린 분석 도구들을 사용하여 도움을 받으시기 바랍니다. 예제를 새창으로 보기.

CSS Quiz 5 : Anchor Navigation.

정찬명 — Fri, 12 Jun 2009 19:53:34 +0000

지난 퀴즈는 즐거우셨나요? 정답을 완성하신 분들은 언제든지 빌붙기 허용권을 꼭 이용해 주시기 바랍니다. ^^ 오늘은 지난번 퀴즈 출제 후 딱 일주일 만인데요. 재미난 퀴즈를 하나 더 준비 했습니다. 재미 뿐만 아니라 실무에서 언젠가는 꼭 한번 써먹을 수 있는 그런 실용적인 퀴즈라고 생각합니다. 그리고 이런 구현 방식은 사람의 일손을 덜어주기까지 한답니다. ^^; 일단 문제부터 보시죠.

문제

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

HTML

CSS Quiz 5 : Anchor Navigation



Anchor Navigation





Menu A


Menu B


Menu C


Menu D


Menu E










앵커 네비게이션에 오신것을 환영합니다.






이 페이지는 앵커를 이용해서 탐색할 수 있습니다.






자바스크립트를 사용하지 않고도 간단한 인터렉션이 가능하다는 것을 보여줍니다.






웹 표준을 준수하고 접근성도 뛰어나죠.






콘텐츠의 높이가 브라우저의 뷰포트 보다 작고 높이가 고정된 상황에서 적절하게 사용할 수 있습니다.












XE Open UI Project by Naradesign.

규칙

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

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

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

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

CSS Quiz 4 : Horizontal Navigation.

정찬명 — Fri, 05 Jun 2009 17:29:43 +0000

이군님께서 지난번 퀴즈때 실시간으로 중개를 참 재미있게 해주셔서 특별히 감사 드리구요. 주말에 퀴즈를 풀 수 있도록 해달라는 이군님의 요청에 따라 이번 퀴즈는 주말에 나갑니다. ^^ 퀴즈의 난이도는 지난번보다 더 쉽지만 이번 퀴즈는 이미지를 사용하면 안된다는 제약이 있습니다. 대신 실무에서 빈번하게 발생하는 상황을 그대로 퀴즈로 옮겼기 때문에 매우 실용적이라고 말씀드릴 수 있겠네요.

규칙

동일한 마크업을 이용하여 두 가지 형태의 수평 네비게이션을 구현해야 합니다.
의미에 알맞는 HTML 코드를 사용하고 표현을 위해 불필요한 코드를 사용하면 안됩니다.
HTML 요소 및 id, class 선택자를 자유롭게 사용할 수 있습니다.
두 가지 형태의 수평 네비게이션을 구현하는 동안 단 하나의 이미지도 사용하면 안됩니다.
HTML Validation을 통과해야 하지만 CSS Validation은 통과하지 않아도 됩니다.
퀴즈에 참여하실 분들께서는 정답을 제출하기 전까지 다른 분들의 정답 코드를 열람하시면 안됩니다.

문제 1

IE 6~8, Firefox 3, Opera 9, Safari 3, Chrome 2 브라우저에서 동일한 형태로 렌더링 되어야 합니다. 메뉴 분리선의 높이는 11px 이 되어야 하고 선의 색상은 #cccccc 입니다. 분리선과 문자의 수직 정렬 위치는 제시된 화면과 일치해야 합니다. 분리선의 좌우 간격은 10px 정도로 설정하되 1~2px 정도의 오차가 발생해도 무방합니다. 선택된(hover, active, focus) 메뉴는 굵은 글씨와 밑줄이 표시되도록 구현해야 합니다.

문제 2

Firefox 3, Safari 3, Chrome 2 브라우저에서 동일하게 렌더링 되어야 합니다. 탭의 너비와 높이는 자유롭게 설정하되 선택된(hover, active, focus) 메뉴는 제시된 화면과 같이 돌출되어 보이도록 구현해야 합니다. 탭의 배경색은 #f8f8f8 이며 보더는 #cccccc 입니다. 탭의 좌우 상단 모서리는 5px 정도의 라운딩 효과가 적용되어야 합니다.

IE 6~8, Opera 9 브라우저에서는 라운딩 효과를 적용하지 않아도 됩니다. 브라우저가 CSS 라운딩 표현을 아직 지원하지 않기 때문입니다.

기간

2009년 6월 14일(일) 자정 까지. 다른 분들의 정답을 참조하지 않는다면 이 기간동안 정답을 수정할 수 있습니다.

정답자에 대한 특전

빌붙기 1회 이용권을 드립니다. 언제든 제게 밥을 사달라고 조르실 수 있습니다. 지난 퀴즈를 통해 현재까지 3분께 맛있는 식사를 대접해 드렸습니다. ^^

현재까지 참여하신 분들

양영복 – http://cfs.tistory.com/custom/blog/23/233747/skin/images/090606.html (시멘틱 마크업 보완 필요 ^^)
황준상 – http://www.webpeace.net/css4.html , http://www.webpeace.net/css_js.html (완성! 밥쏠께! ^^)
hong! – http://viewbox.hosting.paran.com/asdf2.html (완성! 밥 쏠께요! ^^)
dohoons – http://dohoons.com/test/cssQ/quiz4/index.html (완성! 밥 쏠께요! ^^)
조성민 - http://elex.clus.org/quiz/quiz.html (완성! 밥 쏠께요! ^^)
이군 – http://e2goon.kr/study/Naradesign-Quiz/chapter04/round1.html (완성! 밥 쏠께요! ^^)
조경수 – http://odini84.cafe24.com/naradesign/naradesign_question01.html (완성! 밥 쏠께요! ^^)
홍스 – http://www.textarea.co.kr/plugins/lightbox/quiz.html (완성! 밥 쏠께요! ^^)
정찬명 – http://naradesign.net/open_content/quiz/horizontalNavigation/

지난 퀴즈 다시 보기

유니버설 디자인을 위한 웹 안전 서체.

정찬명 — Thu, 04 Jun 2009 15:47:05 +0000

우리가 살고 있는 지구촌에는 다양한 웹 접근 환경이 존재합니다. 그리고 유니버설 디자인 철학은 모든 인류에게 이상적인 웹 사용 환경을 제공하는 것이 아니라 현실 속에 있는 장애를 조금씩 개선해 나아가는데 초점을 맞추고 있습니다. 그 일환으로 오늘은 웹 안전 서체라는 것을 소개하려고 합니다. 웹 안전 색상이라는 것은 익히 들어 봤지만 웹 안전 서체가 있다는 이야기는 생소하실 수 있습니다. 웹 안전 색상은 그래픽 출력기기의 성능이 낮았던 웹 초창기에 디자이너들의 유니버설 디자인 지침 가운데 하나였지만 최근에는 이런 환경도 상당히 개선이 되었기 때문에 이 지침을 강조하는 곳은 점점 줄어들고 있는 추세입니다. 오히려 이런 지침보다는 ‘시각에만 의존하여 정보를 전달하면 안된다‘는 지침이 더욱 실용적이라고 할 수 있겠습니다. 즉, 색을 사용하는 환경은 많이 개선되어 더 이상 안전 색상의 구속을 받을 필요가 없으나 색상만으로 의미를 파악할 수 있도록 하는 디자인을 하면 안된다는 것이겠지요. 자, 본론으로 돌아와서 웹 안전 서체에 대해 이야기를 해보겠습니다.

웹 안전 서체란 말 그대로 웹에서 사용하기에 안전한 서체 입니다. 그렇다면 지금까지 아무 기준 없이 서체를 사용해왔던 분들은 큰 실수를 저지른 것인가 하면 꼭 그렇게까지 생각하지 않으셔도 될 것 같습니다. 이 문제는 자국어 서체를 사용한 웹 사이트에 외국어 운영체제 사용자가 접근한 경우에 발생하는 문제이기 때문입니다. 즉, 내국인을 대상으로 서비스 하는 웹 사이트의 경우 대부분의 사용자가 내국인이고 한국어 운영체제를 사용하기 때문에 문제가 발생할 확률이 적을 것이라는 것입니다. 다소 심각한 문제가 될 수 있는 상황은 외국인을 향한 글로벌서비스에 한국어 서체를 사용한 경우 입니다.

아주 흔한 케이스로 영문이나 일문 또는 중문으로 구성된 콘텐츠에 ‘Dotum’ 따위의 서체를 적용하는 상황인데 이런 경우 문제 상황이 발생할 수 있습니다. ‘Dotum’ 서체는 모든 국가별 운영체제에 기본으로 탑재된 서체가 아니기 때문입니다. ’Gulim, Batang’ 서체는 Win 2000, Win XP 버전의 모든 국가별 운영체제에 공통으로 탑재되어 있지만 ‘Dotum’ 서체는 Vista에 이르러서야 모든 국가별 운영체제에 탑재되기 시작했기 때문에 Vista를 사용하지 않는 해외의 자국어(영문, 일문, 중문…) 운영체제 사용자는 ‘Dotum’ 서체를 만나는 경우 다음과 같은 문제 상황에 직면할 수 있습니다. Windows 버전별로 어떤 서체가 모든 국가별 버전에 기본 탑재되어 있는지 확인하시려면 Microsoft의 Typography 웹 사이트에 있는 Fonts and products 페이지를 참고하시면 됩니다.

첫 번째 문제는 웹 페이지에 지정된 한국어 서체가 사용자 윈도우즈에 설치되어 있지 않은 경우 운영체제가 자동으로 한국어 서체 다운로드를 시도한다는 점 입니다. 이마저도 되는지는 잘 모르겠습니다.
두 번째 문제는 서체가 깨져서 출력된다는 점 입니다.

이런 두 가지 오류 상황은 제가 직접 경험한 것이 아니라 오픈소스 UI 개발을 경험하면서 간접적으로 알게된 사실들 입니다. 따라서 보다 정확한 사실이나 오류 상황에 대하여 알고 계신 분들이 있으시면 보충설명 해주시면 좋겠습니다.

결국 여러분들이 글로벌 환경을 고려해야만 하는 웹 사이트를 구축하고 계신다면 다음과 같이 다양한 운영체제에서 공통으로 지원하고 있는 안전한 시스템 서체를 사용할 것을 권장 합니다.

Browser Safe Fonts : All versions of Windows & Mac equivalents.
Generic Family	Family Name		Example
Generic Family	Windows Font Name	Mac Font Name	Example
Sans-serif ^{Normal fonts without serifs}	Arial	Arial	Safe Fonts, 안전서체, 安全書体, 安全字体
	Arial Black	Arial Black	Safe Fonts, 안전서체, 安全書体, 安全字体
	Lucida Sans Unicode	Lucida Grande	Safe Fonts, 안전서체, 安全書体, 安全字体
	Tahoma	Geneva	Safe Fonts, 안전서체, 安全書体, 安全字体
	Trebuchet MS	Helvetica	Safe Fonts, 안전서체, 安全書体, 安全字体
	Verdana	Verdana	Safe Fonts, 안전서체, 安全書体, 安全字体
	MS Sans Serif	Geneva	Safe Fonts, 안전서체, 安全書体, 安全字体
Serif ^{Normal fonts with serifs}	Georgia	Georgia	Safe Fonts, 안전서체, 安全書体, 安全字体
	Palatino Linotype	Book Antiqua	Safe Fonts, 안전서체, 安全書体, 安全字体
	Times New Roman	Times	Safe Fonts, 안전서체, 安全書体, 安全字体
	MS Serif	New York	Safe Fonts, 안전서체, 安全書体, 安全字体
Monospace ^{Fixed-width fonts}	Courier New	Courier New	Safe Fonts, 안전서체, 安全書体, 安全字体
Monospace ^{Fixed-width fonts}	Lucida Console	Monaco	Safe Fonts, 안전서체, 安全書体, 安全字体
Cursive ^{Fonts that emulate handwriting}	Comic Sans MS	Comic Sans MS	Safe Fonts, 안전서체, 安全書体, 安全字体
Fantasy ^{Decorative fonts, for titles, etc.}	Impact	Impact	Safe Fonts, 안전서체, 安全書体, 安全字体

참조 문서

Web Style Sheets CSS tips & tricks - http://www.w3.org/Style/Examples/007/fonts.html
Microsoft typography – http://www.microsoft.com/typography/fonts/default.aspx
Common fonts to all versions of Windows & Mac equivalents - http://www.ampsoft.net/webdesign-l/WindowsMacFonts.html

IE6~7 : button, input. Extra padding bug.

정찬명 — Wed, 13 May 2009 13:01:46 +0000

"나는 목에 칼이 들어와도 리바이벌은 안해" 라는 개그맨의 유행어가 생각납니다. 오늘 새벽에는 새 글쓰기 욕심을 잠시 접어놓고 작년 가을에 공개했던 CSS Text Button Design. 이라는 포스트를 갱신하기로 했습니다. 정확하게 말해서 갱신한 것은 포스트가 아니라 포스트에서 주요하게 설명했던 CSS 버튼 예제코드 입니다. 한번 작성한 코드를 두고 두고 쓰면 좋겠지만 버그도 발견되고 브라우저도 좋아졌고 여러분들이 댓글로 주신 피드백도 반영하면서 좀 더 이상적인 코드를 작성해야겠다는 생각이 들었습니다. 지금도 완벽하지 않을지 모르지만 6개월 전보다 확실히 좋아졌다고 자평해 봅니다. 해결했던 버그에 대해서 조금 더 자세히 설명해 드리겠습니다.

IE 6~7 브라우저에서 발생하는 button, input 요소의 패딩 버그.

IE 6~7 브라우저는 button, input 요소의 표시 값으로 텍스트를 취할 때 문자열의 길이에 따라 좌우 패딩이 비정상적으로 늘어나는 버그가 있습니다.

button, input 요소의 표시 값으로 텍스트를 취한 예.

위 버튼은 실제로 코딩한 버튼 입니다. IE 6~7 브라우저로 접근해서 보시면 표준계열 브라우저에서 보는 것과 다르게 보일 것입니다.

위 버튼은 IE 6~7 에서 렌더링 하는 모습을 이미지로 떠온 화면 입니다. 표준계열 브라우저와 비교하면 1~2px 정도가 아니라 눈속임을 할 수 없을만큼 심하게 차이가 나서 좁은 공간에서 버튼이 여러개 나열되는 경우 줄 바꿈되는 상황을 어렵지 않게 추측할 수 있습니다.

무엇이 문제인가? 버튼의 너비가 가변적인 경우 문제.

문자열의 길이를 알 수 없는 텍스트 버튼을 구현하고자 할 때 문제가 됩니다. 문자열의 길이가 불변하는 버튼이라면 CSS의 width 속성을 이용하여 너비를 고정해 버리면 간단하게 해결되지만 상황에 따라 또는 다국어 버전을 준비해야 한다면 CSS로 너비를 고정하면 안됩니다. padding:0 속성으로도 저 여분의 패딩은 제거되지 않습니다.

해결 방법. overflow:visible.

의외로 간단하게 해결 됩니다. button 또는 input 요소에 CSS의 overflow:visible 속성을 적용하면 IE 6~7 브라우저에서 여분의 패딩이 제거 됩니다. 얼마전에 우연히 발견 했는데 벼르다 벼르다 이제서야 블로그에 공유 하네요. 사실 검색해서 찾아보면 답이 있는데 그걸 여태 찾아볼 생각도 못했습니다. ㅠㅠ;

button, input 요소에 overflow:visible 적용한 예.

표준 계열 브라우저로 보시면 별 변화가 없겠지만 IE 6~7 브라우저로 보시면 여분의 패딩이 사라진 것을 확인하실 수 있습니다. IE 6~7 에서 좌우 패딩이 너무 적다고 판단 되시면 그때 비로소 CSS padding 속성으로 좌우의 패딩을 조절하시면 됩니다. CSS Text Button Design. 예제 코드에 이 해결방법이 적용되어 있습니다. 한번 써보시고 다른 문제는 없는지 지속적인 관심과 피드백 주시면 저도 열심히 한번 갱신해 보겠습니다.

CSS Quiz 3 : Rounded Corner!

정찬명 — Mon, 27 Apr 2009 19:48:13 +0000

CSS Quiz 1~2탄이 다소 아쉬운 분들을 위해 바로 3탄을 준비 했습니다. 이번 문제는 조금 더 실용적이고 조금 더 쉽습니다. 주어진 마크업을 이용하여 제시된 화면을 구현하는 것이 이번 퀴즈 입니다. 늘 그렇지만 정답은 하나가 아닐 수 있습니다.

주어진 Markup은 다음과 같습니다.



    메뉴 하나


    메뉴 둘


    메뉴 셋


    메뉴 넷


    메뉴 다섯

코드 설명 : 전형적인 메뉴 네비게이션 마크업 입니다. 이 코드를 사용해야 하고 이것을 수정하거나 다른 요소 또는 속성을 추가할 수 없습니다. html, head, style, body 와 같은 문서 기본 코드는 물론 사용해야 함.

다음 화면을 CSS로 구현하세요.

화면 설명 : 문서의 배경색이 #EEEEEE 이고 상자의 보더 색이 #CCCCCC 이며 상자의 배경색이 #FFFFFF 인 수직 메뉴 네비게이션. 상자의 모서리는 라운딩 처리가 되어 있다.

다음과 같은 제한이 있습니다.

HTML은 주어진 마크업을 사용해야 하고 절대로 변형하거나 다른 코드를 추가해서는 안됩니다.
HTML/CSS 이외 다른 언어는 사용할 수 없으며 HTML/CSS 표준 문법을 준수해야 합니다. HTML Validation, CSS Validation.
CSS 코드 작성시 오직 타입 선택자 및 하위 선택자만 사용할 수 있습니다. 1번 규칙에 따라서 당연히 ID 선택자, CLASS 선택자는 사용할 수 없습니다.
CSS 는 UL, LI, A 요소 이외 요소에 적용하지 않습니다.
단 하나의 이미지만을 사용할 수 있습니다. 이미지는 스스로 창작해서 준비하세요.
상자는 고정폭 너비(200px)를 갖지만 높이는 메뉴의 개수에 따라 가변적으로 대응이 가능해야 합니다.
문서의 배경색이 달라지더라도 상자의 배경은 흰색으로, 둥근 모서리는 자연스럽게 유지되어야 합니다.
IE 6~8, Firefox 3, Safari 3, Opera 9, Chrome 1 브라우저에서 깨지지 않고 거의 동일하게 보여야 합니다. 단, 제시한 화면과 픽셀 그리드를 정확하게 일치시킬 필요는 없습니다.

퀴즈 참여자에 대한 특전.

가장 먼저 정답을 제출하신 한 분께는 프리미엄 빌붙기 1회 허용권.
늦더라도 ‘양심껏 도전’(정답을 보지 않고 스스로 해결하신)해서 정답을 제출하신 선착순 아홉 분께는 빌붙기 1회 허용권.

그냥 빌붙기와 프리미엄 빌붙기의 차이에 대해 궁금하신 분들은 CSS Quiz 2! 결과를 확인하세요! 포스팅 하단을 참고해 주세요. 농담이 아니라 어느 곳에서든 정답자 가운데 저를 보시는 분께는 밥을 쏘겠습니다. 집사람에게 결재도 다 받아 놨습니다!

현재까지 퀴즈에 참여하신 분들.

황준상 - http://www.webpeace.net/test3.html 정답 인정. 프리미엄 빌붙기 1회 허용권 획득.
지기지 - http://www.zigizi.net/rc.html 메뉴가 짝수인 경우에 대한 고려 필요. 고치시면 인정해 드립니다. ^^
dohoons - http://dohoons.com/test/cssQ/quiz3/index.html 정답 인정. 빌붙기 1회 허용권 획득.
김성준 - http://temp.azki.org/ 정답 인정. 빌붙기 1회 허용권 획득.
나에 - http://rhplus.kr/dev/naradesign_quiz/003/quiz.html 정답 인정. 빌붙기 1회 허용권 획득.
청설모 - http://reedids.springnote.com/pages/3245732 정답 인정. 빌붙기 1회 허용권 획득.
terijoon - http://terijoon.tistory.com/entry/CSS-Quiz-3-Rounded-Corner 정답 인정. 빌붙기 1회 허용권 획득.
이현석 - http://ecstatic.monoless.com/quiz_3.html 정답 인정. 빌붙기 1회 허용권 획득.
hong! - http://viewbox.hosting.paran.com/asdf.html 정답 인정. 빌붙기 1회 허용권 획득.
초식동물 - http://image.gmarket.co.kr/test/quiz3.htm 정답 인정. 빌붙기 1회 허용권 획득.
아이단 - http://rgbmix.ft.co.kr/naraquiz/03/index.html 정답 인정. 빌붙기 1회 허용권 획득.
양영복 - http://cfs.tistory.com/custom/blog/23/233747/skin/images/test.html 정답 인정. 빌붙기 허용권은 다음 기회에. ^^
최영은 - http://203.229.188.8/DMMail/test/roundBox.html 정답 인정. 빌붙기 허용권은 다음 기회에. ^^
정찬명 - http://naradesign.net/open_content/quiz/roundCorner/ 정답을 살짝 응용 또는 확장한 예제.

CSS Quiz2! 결과를 확인 하세요!

정찬명 — Thu, 23 Apr 2009 20:24:28 +0000

우선 CSS Quiz2! 라는 듣보잡 이벤트에 묻지도 않고 따지지도 않고 참여해 주신 여러분들께 감사드리고 여러분들의 그 열정에 박수를 보내드립니다. 이벤트에 참여 하기 위해 사랑하는 사람과 보내야 할 귀중한 시간도 잠시 미루고 늦은 퇴근을 했거나 또는 잠을 미루셨을 줄로 압니다. 굳이 밥 한끼 얻어 먹어보자고 참여하신 분은 없으실테니까요.

이벤트 참여에 대한 보상은 이 퀴즈에 도전하는 순간 이미 각자에게 충분히 주어졌다고 생각합니다. 약간의 흥분과 재미를 느끼셨다면 말이죠. 그러나 가벼운 선의의 경쟁과 그 결과에 대한 보상을 전혀 기대하지 않았다고는 생각하지 않습니다. 제가 여러분들께 드릴 수 있는 작은 보상은 각 개인의 답안을 나름대로 분석해 보고 정량화 해서 피드백을 드리는 일이라고 생각 했습니다. 물론 1등 하신 분께는 밥도 쏴야 하구요. ㅋㅋ.

솔직히 말씀드려서 평가 결과를 점수로 환산하고 순위를 매기는 일이 쉽지는 않았습니다. 나름 머리 쥐어 뜯어가며 고민 했지만 스스로 생각하기에도 완전히 공평하거나 합리적인 최선의 기준이었다고는 생각하지 않습니다. 또 생각보다 낮은 점수와 순위를 받으신 분들의 결과까지 공개가 되기 때문에 상처받으실까봐 걱정도 됩니다. 여하튼 결국 이 퀴즈의 평가라는 것은 객관적인 기준 없이 제 멋대로 설정했기 때문에 절대로 결과를 신뢰해서는 안되며 오직 재미를 위해 이것을 했다고만 생각해 주셨으면 좋겠습니다.

생각보다 좋은 성적을 받으셨다면 로또 맞았다고 생각하시면 되구요. 생각보다 낮은 성적을 받으셨다면 평가 기준이 공정하지 않았다고 생각해 주시기 바랍니다. 퀴즈 낼 당시에도 말씀드렸지만 그저 재미를 위해 했습니다!

CSS Quiz2 평가 결과 및 답안 분석
순위	이름	답안	호환성							HTML			CSS
순위	이름	답안	IE6	IE7	IE8	FF3	CR1	SF3	OP9	유효성	요소수	속성수	유효성	선택자수	속성수
1	황준상	보기	pass	pass	pass	pass	pass	pass	pass	pass	10	3	pass	16	54
2	민즈	보기	pass	pass	pass	pass	pass	pass	pass	pass	10	8	pass	16	47
3	신현석	보기	pass	pass	pass	pass	pass	pass	pass	pass	10	10	pass	15	56
4	정찬명	보기	pass	pass	pass	pass	pass	pass	pass	pass	9	9	pass	15	66
5	dohoons	보기	pass	pass	pass	pass	pass	pass	pass	pass	11	9	pass	13	70
6	완규	보기	pass	pass	pass	pass	pass	pass	pass	pass	15	17	pass	20	52
7	나상욱	보기	pass	pass	pass	pass	pass	pass	pass	pass	15	16	pass	16	79
8	김대현	보기	fail	fail	pass	pass	pass	pass	pass	pass	37	41	pass	28	46

브라우저 호환성을 일일이 체크했구요. HTML 요소 수와 속성 수를 헤아렸습니다. 또 CSS 선택자 수와 속성 수를 헤아려 보았습니다. 1등은 코드를 가장 경제적으로 작성해 주신 황준상님께서 차지 하셨고(축하드립니다!) 꼴등은 불과 30분만에 이것을 해치우셨다는 김대현님께서 차지하셨습니다. 황준상님께서는 CSS 코드도 경제적으로 사용하셨지만 HTML 요소의 속성까지 아껴 사용하신 부분이 주효했다고 판단 합니다. 김대현님은 HTML/CSS 유효성 검사까지는 가볍게 pass 하셨는데 IE 6~7 브라우저 호환성에 문제가 있었습니다. 사실 이것은 IE 6~7 브라우저가 표준을 따르지 않았기 때문에 발생하는 문제지요. 꼴찌 하셨지만 한번 꽉 안아드리고 싶네요. ^^;

아래 표는 참여하신 분들의 코드를 분석하고 그 결과를 점수로 환산 했던 제멋대로 자료 입니다. 이해가 되시면 좋겠는데 굳이 이해가 되지 않는다고 하셔도 제가 뭐 드릴 말씀은 없습니다. ㅜㅜ;

CSS Quiz2 항목별 평가 점수 상세
점수	이름	기본(5)	호환성(35) 35-(N*5)	HTML(20+10)		CSS(20+10)
점수	이름	기본(5)	호환성(35) 35-(N*5)	요소 20-(N*0.5)	속성 10-(N*0.2)	선택자 20-(N*0.5)	속성 10-(N*0.1)
81	황준상	5	35	15	9.4	12	4.6
80.7	민즈	5	35	15	8.4	12	5.3
79.9	신현석	5	35	15	8	12.5	4.4
79.6	정찬명	5	35	15.5	8.2	12.5	3.4
79.2	dohoons	5	35	14.5	8.2	13.5	3
73.9	완규	5	35	12.5	6.6	10	4.8
73.4	나상욱	5	35	12.5	6.8	12	2.1
44.7	김대현	5	25	1.5	1.8	6	5.4

HTML 요소 및 속성 그리고 CSS 선택자 및 속성을 많이 사용할수록 기본점수에서 감점하는 방식을 사용 했습니다. 이런 시스템은 누가 평가를 하느냐에 따라서 항목별 변별력과 점수폭을 다르게 설정할 수 있기 때문에 주관적인 요소가 반영되어 있고 논란의 여지가 있습니다. 이것이 바로 제가 재미를 강조하는 이유 입니다. ㅡㅡ;

1등하신 황준상님께는 식당 및 메뉴를 자유롭게 선택할 수 있는 프리미엄 빌붙기 1회 사용권을 , 그리고 참여하신 모든 분들께는 가까운 기사식당에서 백반 빌붙기 1회 사용권을 드리겠습니다. 빌붙기 사용권은 저를 보시면 언제든 사용하실 수 있습니다! ^^; 감사합니다!

음성 출력 솔루션과 텍스트 전용 페이지는 필수 아님.

정찬명 — Mon, 20 Apr 2009 16:42:37 +0000

웹 접근성을 보장하기 위하여 음성 출력 솔루션과 별도의 텍스트 전용 페이지가 필수적이라는 주장과 그렇지 않다는 주장이 대립하고 있습니다.

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

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

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

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

난독증, ADHD와 같은 인지 및 언어장애자

스크린리더를 사용하지 않은 저시력 시각장애인

마우스를 사용하지 못하는 신체장애자 혹은 뇌병변장애자

일정 부분 신체기능이 저하된 노인(경증장애인 범주)

스크린리더사용법을 모르는 시각장애인 (제품별 키보드 약어가 통일 되어 있지 않습니다.)

문맹자 (일정부분 문화적 장애인 범주)

스크린리더가 설치되지 않은 컴퓨터 환경에서의 시각장애인

색약 등 시각장애인

사물 및 시각적 인지능력이 부족한 뇌병변 장애인

스크린리더 사용조차 하기 힘든 복합 중증시각 신경 장애인

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

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

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

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

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

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

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

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

8. 색약 등 시각장애인

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

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

IE6 bug : Horizontal scroll bar in frame.

정찬명 — Thu, 09 Apr 2009 22:32:27 +0000

IE6에서 아이프레임(iframe) 또는 프레임셋(frameset) 문서에 의도하지 않은 수평 스크롤바를 발생시키는 버그 입니다. 아래 보시는 이미지는 좌우측 동일하게 표준 DTD를 사용한 문서를 프레임으로 출력할 때 IE6 브라우저의 프레임이 어떻게 스크롤바를 발생시키는지 보여주고 있습니다. 좌측은 내용이 넘치지 않지만 우측은 내용이 넘친다는 점만 다르고 프레임 scrolling 속성의 값은 기본값인 "auto" 입니다.

버그가 발생하는 상황.

프레임에 포함될 자식 문서에 표준 DTD(HTML 4.01 ST, XHTML 1.0 ST)를 사용. 부모 문서의 DTD는 관계 없음.
자식 문서의 내용이 프레임의 수직 크기를 초과할 때 수직 스크롤바 발생.
이 때 생기지 않아야 할 수평 스크롤바가 동시 발생.

잘못된 문제 해결 방법.

프레임의 scrolling 속성을 "no" 으로 바꿈 : 자식 문서의 내용이 넘칠 경우 보이지 않는 영역의 탐색이 불가능 해진다.
프레임에 포함될 자식 문서의 DTD를 제거 : Quirks Mode 렌더링을 유발하기 때문에 브라우저 호환성 작업이 어려워지게 된다.

적당한 문제 해결 방법.

프레임의 scrolling 속성을 "yes" 으로 바꾸면 IE6에서 더 이상 수평 스크롤바가 발생하지 않는다.

이 대안의 단점.

IE를 비롯한 모든 브라우저들은 scrolling 속성이 "yes" 일때 자식 문서의 내용이 넘치지 않아도 ‘수직‘ 스크롤바 자리를 무조건 표시한다.
Opera, Firefox 브라우저는 scrolling 속성이 "yes" 일때 자식 문서의 내용이 넘치지 않아도 ‘수직 및 수평‘ 스크롤바 자리를 무조건 표시한다.
Safari, Chrome 브라우저는 scrolling 속성이 "yes" 일때 자식 문서의 내용이 넘치지 않아도 ‘수직‘ 스크롤바 자리를 무조건 표시한다.

테스트용 예제.

테스트 예제를 제대로 활용하려면 IE6 및 다양한 브라우저를 이용하여 이 문서를 보세요. 이 예제를 새 창에서 보기. 좌측에 있는 프레임은 내용이 넘치지 않는 프레임이고 우측에 있는 프레임은 내용이 넘치는 프레임 입니다.

No DTD & scrolling="auto"

Standard DTD & scrolling="auto"

Standard DTD & scrolling="yes"

tabindex 속성이 오히려 접근성을 해친다.

정찬명 — Mon, 06 Apr 2009 18:00:03 +0000

tabindex라는 속성이 있습니다. 말 그대로 tab의 접근 순서를 인위적으로 변경할 수 있는 속성 입니다. tabindex는 다음 요소에 적용할 수 있습니다.

a
area
button
input
object
select
textarea

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

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

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

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

tabindex, 사용성을 높인 사례.

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

검색 인풋
아이디 인풋
비밀번호 인풋
로그인 버튼

맞나요? 객관적으로 제시할 근거 자료는 없지만 저는 거의 확신하고 있습니다. 국내 양대 포털인 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을 걷어내지 않고 ‘아이디, 비밀번호, 로그인’ 콘트롤에 tabindex 속성을 사용한다는 데 있습니다. 여기서 tabindex를 사용하게 되면 tab키는 다른 어떤 항목보다 로그인 서식을 먼저 탐색하게 됩니다. 이것이 의도한 경우라면 문제가 되지 않지만 만약 ‘로그인’ 서식이 아니고 웹 페이지에서 가장 먼저 탐색이 되어야 하는 콘텐츠가 아니라면 어떨까요? 어설프게 tabindex를 사용한 다음 그 순서가 잘못 지정된 것을 바로잡지 않은 사례가 무척 많이 발견 됩니다. 또 그것을 그대로 복사해서 다른 곳에 아무 생각 없이 가져다 쓰는 사례도 많습니다. 이런 경우 tabindex가 접근성을 오히려 훼손하게 됩니다. 지금 당장 여러분이 제작한 웹 사이트를 찾아서 tabindex가 사용되었는지를 확인하고 접근 순서를 오히려 훼손하고 있지 않은지 테스트 해보세요.

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

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