NARADESIGN:BLOG » 웹 기획 http://naradesign.net/wp 웹표준, 웹접근성, 유니버설디자인, HTML, CSS, UI, UX, UD Tue, 17 Jan 2012 15:18:30 +0000 en hourly 1 http://wordpress.org/?v=3.3.1 Mobile first strategy for CSS designer. http://naradesign.net/wp/2012/01/18/1742/ http://naradesign.net/wp/2012/01/18/1742/#comments Tue, 17 Jan 2012 15:13:20 +0000 정찬명 http://naradesign.net/wp/?p=1742 마지막으로 블로그에 글을 포스팅 했던 날짜가 작년 여름이네요. 오늘 주제는 CSS 디자이너를 위한 모바일 퍼스트 전략 인데요. 작년에 썼던 'HTML5 & Responsive Web Design' 포스팅과 관련이 있습니다. 모바일 퍼스트 전략이라는 것은 IT 기업들 입에 자주 오르내리는 단어 인데요. 이 개념은 CSS 개발에도 적용할 수 있습니다. 말 그대로 모바일 우선 전략입니다. 2013년 말 또는 2014년 초에는 모바일 인터넷 사용자가 데스크탑 인터넷 사용자를 앞지를 것이라는 전망이 우리를 두근거리게 만들고 있습니다. CSS 디자이너를 위한 모바일 퍼스트 전략이란 무엇인지 알아보죠.

CSS3 Media Queries

여러분이 CSS3를 배울 기회가 있었다면 다음과 같은 코드 @media (조건문) {실행문} 으로 무엇을 할 수 있는지 알 수 있습니다. CSS3 미디어 쿼리를 이용하면 모바일 환경의 뷰와 데스크탑 환경의 뷰를 원하는 해상도에 따라 완벽하게 분기 처리할 수 있습니다. 단 하나의 HTML 문서만가지고 말입니다.

@media (max-width:799px) { ... CSS for Mobile ... }  /* 이 코드는 799px 이하의 해상도에서 해석 됩니다 */ 
@media (min-width:800px) { ... CSS for Desktop ... } /* 이 코드는 800px 이상의 해상도에서 해석 됩니다 */

현존하는 최신 버전의 브라우저들은 CSS3 미디어 쿼리를 잘 지원하기 때문에 문제가 없지만 이 코드는 두 가지 문제가 있습니다. 첫째, 미디어 쿼리를 지원하지 않는 모바일 브라우저에 적용되지 않습니다. 둘째, 미디어 쿼리를 지원하지 않는 데스크탑 브라우저에 적용되지 않습니다. 두 가지 문제를 하나씩 풀어 보도록 하지요.

Mobile First CSS

미디어 쿼리를 지원하지 않는 모바일 브라우저에 대응하기 위해 저는 다음과 같이 코드를 작성 했습니다. 모바일에 대응하기 위한 코드를 미디어 쿼리 밖에 작성한 것입니다.

... CSS for Mobile ...
@media (min-width:800px) { ... CSS for Desktop ... }

이것으로 첫 번째 문제를 해결 했습니다. 미디어 쿼리를 지원하지 않는 모바일 브라우저는 미디어 쿼리 조건문 밖에 있는 코드를 해석합니다. 미디어 쿼리 구문은 지원하지 않으므로 해석하지 않습니다. 미디어 쿼리를 지원하는 모바일 브라우저는 해상도가 800px이 넘지 않는 이상 미디어 쿼리 구문을 해석하지 않습니다. 조건에 맞지 않으니까요. 미디어 쿼리 지원 여부에 관계 없이 799px 이하의 해상도를 지닌 모든 브라우저는 모바일용 CSS 코드만 해석합니다. 간단 명료하죠? 한편 미디어 쿼리를 지원하지 않는 IE 6~8 브라우저에서는 어떻게 보일까요?

IE 6, 7, 8 Compatibility

미디어 쿼리를 지원하지 않는 데스크탑 브라우저(IE 6~8)는 모바일 퍼스트 CSS 코드만 해석하기 때문에 모바일 뷰로 보일 것입니다. 낡은 데스크탑 브라우저가 미디어 쿼리문을 바르게 해석하도록 하기 위해 저는 다음과 같이 CSS3 미디어 쿼리 활성 스크립트를 HTML 문서에 추가 했습니다. 

<!--[if lt IE 9]>
<script src="http://css3-mediaqueries-js.googlecode.com/svn/trunk/css3-mediaqueries.js"></script>
<![endif]-->

IE 조건부 주석 'if lt IE 9 = if less than IE 9 = IE 9 미만이면 해석'을 사용하여 IE 9 보다 버전이 낮은 브라우저에서만 이 스크립트를 해석하게 됩니다. 표준계열 브라우저는 이 부분을 주석으로 처리하죠. 이제 IE 6~8 브라우저는 미디어 쿼리 구문을 올바르게 해석할 수 있게 됐습니다. 간단 명료하죠?

Tip 1: Performance Improvement

미디어 쿼리를 이용하여 데스크탑용 배경 이미지(background-image)와 모바일용 배경 이미지를 다르게 설정해 보세요. 미디어 쿼리를 이용하여 해상도별로 배경 이미지를 다르게 설정하면 다른 해상도에 필요한 배경 이미지는 서버로 전송 요청하지 않습니다. 즉, 특정 해상도에서 필요로하는 이미지만 요청(http request)하므로 미디어 쿼리를 통해 네트워크 자원을 아낄 수 있습니다. 웹 브라우저 개발자 도구의 네트워크(Network) 탭을 통해서 직접 확인해 보세요.

Tip 2: Override Mobile by Desktop CSS

모바일 퍼스트 CSS 코드는 낮은 해상도의 모바일용 브라우저에서만 해석하는 것이 아니라 높은 해상도의 데스크탑 브라우저에서도 동시에 해석하게 됩니다. 따라서 미디어 쿼리 조건문 안에서는 데스크탑용 CSS 코드가 모바일용 CSS 코드보다 더 높은 우선순위를 가질 수 있도록 덮어쓰기 하는 작업이 필요합니다. 손이 많이 갈것 같지만 모바일용 코드는 비교적 단순하기 때문에 그리 어렵지는 않을 것입니다.

References

]]> http://naradesign.net/wp/2012/01/18/1742/feed/ 6 HTML5 & Responsive Web Design(반응형 웹 디자인). http://naradesign.net/wp/2011/05/27/1483/ http://naradesign.net/wp/2011/05/27/1483/#comments Thu, 26 May 2011 17:36:48 +0000 정찬명 http://naradesign.net/wp/?p=1483 최근 블로그를 HTML5와 반응형 웹 디자인으로 리팩토링 했습니다. 제목은 거창한데 사실 별것 없습니다. 바꾸는데 하루도 걸리지 않았고 무엇을 바꾸었는지 소스 코드를 한 줄씩 설명해 보겠습니다.

HTML5

HTML5로 변경하는데는 약 2~3시간 정도 밖에 걸리지 않았습니다. 하지만 고민했던 시간은 꽤 길었습니다. div, section, article 요소를 혼동하지 않기 위해서 의미를 정확하게 이해해야 했습니다. DTD를 변경하고 header, footer 같은 새 요소들을 사용하면 IE6와 같은 낡은 브라우저에서 저 낮선 요소들을 어떻게 처리하는지 걱정도 했습니다.

HTML5 DTD declaration

HTML5 DTD는 매우 간단합니다. 예전에는 DTD를 외워보려고 갖은 애를 써도 그러지 못했는데 이제는 잊으려 애를 써도 잊지를 못합니다. <!doctype html> 이라고 적으면 끝입니다. case-insensitive. 대소문자를 구별하지 않으니 대문자로 쓰거나 소문자로 쓰거나 섞어 쓰거나 상관 없습니다. HTML5는 DTD 뿐만 아니라 요소와 속성 모두 case-insensitive 입니다. 대소문자를 구별하지 않습니다. 그러나 요소 이름과 속성을 대문자로 쓴다고 하면 말리고 싶습니다. 다른 이유는 없구요. 보기 불편하니까요.

Human language declaration

WCAG 2.0 지침의 3.1.1 항목을 보면 다음과 같은 구문이 있습니다.

"페이지 언어: 모든 웹 페이지의 기본 휴먼 랭귀지는 기계적으로 판단할 수 있어야 한다. (수준 A)"

휴먼 랭귀지란 사람이 쓰는 자연어를 말합니다. 수준 A란 최소한의 요구 조건 입니다.

<html lang="ko">

이렇게 html 요소에 한국어 휴먼 랭귀지 선언을 할 수 있습니다. 웹 문서에 휴먼 랭귀지를 선언하면 텍스트를 음성으로 변환해주는 시각장애인용 화면낭독기는 적합한 음성 엔진을 이용해서 웹 문서를 읽어줍니다. 예를 들어 로마자는 영어에만 쓰이는 것이 아니라 유럽에서 두루 쓰이는데요. 휴먼 랭귀지 속성을 선언하면 시각장애인용 화면 낭독기가 로마자를 어떻게 발음을 해야 하는지 정확히 알 수 있습니다. 한국형 웹 콘텐츠 접근성 지침인 KWCAG 2.0 지침에도 동일한 내용이 포함되어 있습니다. KWCAG 2.0에 포함되어 있다는 것은 향후 웹 접근성 품질마크 심사 지표에도 반영이 된다는 의미 입니다. 다음 회차의 웹 접근성 품질마크에는 이 기준이 적용되므로 웹 접근성 품질마크 심사에 도전하는 제작자는 반드시 휴먼 랭귀지를 작성해야 합니다. 이것은 HTML5 뿐만 아니라 다른 버전의 마크업 언어(HTML, XHTML)에도 동일하게 적용됩니다.

HTML5 enabling script

HTML5에는 여러가지 새로운 요소들이 등장 했습니다. 그러나 낡은 브라우저들은 이것을 알아차리지 못하는 문제가 있기 때문에 새로운 HTML5 요소들을 해석하거나 렌더링하지 않습니다. 도통 사람들이 업데이트를 하려고 하지도 않고 자동으로 업그레이드를 해주지도 않는 IE 6~8 브라우저가 그렇습니다. 우리는 낡은 브라우저가 새 요소들을 인식할 수 있도록 스크립트로 처리할 수 있습니다. 이 스크립트는 문서 head에 포함해서 브라우저가 낮선 태그를 만나 허둥대는 일이 없도록 처리하는 것이 좋습니다.

<!–[if lt IE 9]>
    <script src="http://html5shim.googlecode.com/svn/trunk/html5.js"></script>
<![endif]–>

"if lt IE 9 = if less-than IE 9" IE 조건부 주석을 사용해서 IE9 보다 버전이 낮은 브라우저에서만 이 스크립트를 해석하도록 한 것입니다. 스크립트는 새로나온 HTML5 요소들을 브라우저가 인식할 수 있도록 추가해서 낡은 브라우저들이 HTML5 요소들을 해석하고 렌더링 할 수 있도록 해줍니다.

CSS Reset

새로 추가된 요소들이 inline 요소인지 block 요소인지 브라우저들은 모를 수 있습니다. 따라서 다음과 같이 CSS display 상태를 정의해 줍니다. HTML5에서 새롭게 추가된 요소들을 모두 block으로 선언 했습니다.

header, footer, section, article, aside, nav, hgroup, details, menu, figure, figcaption {
    display: block
}

HTML5 Markup – Document Structure

의미론적 마크업을 글로만 배우면 막상 실무에 적용할 때 생각하지 못했던 고려사항들이 발생해서 고민도 되고 마크업을 하더라도 확신이 서지 않게 됩니다. 그런 의미에서 개인 블로그는 좋은 실험 재료인 것이죠. 제 블로그의 마크업 구조는 다음과 같습니다. 

  • div
    • header
      • h1
    • section
      • article
        • h1
      • section
        • h2
      • section
        • h2
        • form
      • nav
    • nav
      • ul
        • li
    • footer

조금 더 자세히 풀어 볼까요?

  • div – 본문의 폭을 제한하거나 중앙으로 배치하는 역할만 합니다. 별 의미는 없기에 div 요소를 사용 했습니다.
    • header – 사이트 제목과 설명이 등장하는 헤더 섹션입니다.
      • h1 – 사이트 최상위 제목.
    • section – 헤더, 풋터, 네비게이션 섹션이 아닌 일반적인 섹션입니다. section 요소는 웹 문서의 구조를 결정하는 핵심 요소 입니다. 섹션은 통상 하나의 헤딩과 명시적인 관계를 갖는것이 좋습니다. section & hx의 관계는 마치 fieldset & legend 요소와 구조적으로 흡사합니다. section 안에 포함된 hx는 section 내부에 포함된 콘텐츠의 제목이 됨과 동시에 현재 웹 문서의 개요 역할을 합니다. 제 블로그의 경우 section 요소와 hx 요소 사이에 article이 끼어들어 section이 제목 없이 글 본문, 댓글, 댓글 쓰기 폼을 감싸는 역할을 하고 있습니다. section은 바로 아래 첫 번째 자식으로 hx를 갖추는 것을 구조적으로 권장하지만 제 경우는 그러지 못했네요. 하지만 꼭 그런 구조를 갖추지 못해도 괜찮습니다. hx가 없어도 section은 section 이니까요.
      • article – 포스트 본문 섹션으로써 처음에는 section 요소와 어떤 의미적 차이를 지니는지 구분하기 어려웠습니다. 그러나 article 요소는 이 영역을 독립적으로 다른곳에 옮겨놔도 하나의 완전한 문서 또는 섹션이 될 수 있는 '재 사용' 가능한 또는 '배포 가능한' 본문 영역이라고 설명할 수 있겠습니다. section 요소와 마찬가지로 hx 요소를 갖는것을 강력하게 권장합니다. section과 article 요소 가운데 무엇을 써야 할지 망설여질 때에는 주변의 맥락과 분리하여 독립해도 하나의 완전한 콘텐츠가 되는지 아닌지를 판단해 보세요. 독립적이라면 article에 가깝고 현재 문서의 개요와 구조를 결정하는 역할이라면 section에 가깝습니다.
        • h1 – 포스트 본문 제목. h1이 두 번째 등장하죠. h1은 하나의 웹 페이지에 2번 이상 등장할 수 있습니다. W3C 웹 사이트도 이런 구조를 가지고 있으며 검색엔진 최적화에 좋습니다. 게시판에서 게시물 제목도 h1으로 마크업 하면 검색엔진으로부터 좋은 점수를 받을 수 있습니다. h1에 포함된 텍스트가 문서 헤드의 title 요소에도 들어가 있으면 금상 첨화죠. 제 블로그는 그렇게 처리되어 있습니다. 검색엔진이 좋아합니다.
      • section – 댓글 목록 섹션.
        • h2 – 댓글 목록 제목.
      • section – 댓글 쓰기 섹션.
        • h2 – 댓글 쓰기 제목.
        • form – 댓글 쓰기 폼.
      • nav – 이전 포스트 / 다음 포스트 네비게이션.
    • nav – 사이트 글로벌 네비게이션.
      • ul – 비순차 목록 컨테이너.
        • li – 네비게이션 항목.
    • footer – 저작물 이용 안내 및 RSS 주소를 담은 풋터 섹션.

HTML5 Markup – Form Controls

HTML5 Form의 위력은 아이폰을 사용하는 분들이면 쉽게 체감할 수 있습니다. 제 블로그에서는 다음과 같은 타입의 Form Control을 사용 했습니다. 제 블로그의 End-user 페이지에서 Form Control 이라고 해 봐야 검색창과 글쓰기창 뿐인데요. 적용 결과는 다음과 같습니다.

<input type="search" autocomplete="on" />
검색창의 인풋 타입이 search 입니다.

<input type="url" autocomplete="on"  />
댓글 쓰기 창에서 웹 사이트 주소 입력 인풋 타입이 url 입니다.

이 밖에도 HTML5에는 새롭게 추가된 다양한 input type이 있습니다. 아래 항목들은 HTML5에 새롭게 추가된 input type 입니다. 링크를 클릭하면 실제로 코딩된 페이지를 만날 수 있습니다. 현재는 오페라 브라우저만 input type을 거의 완벽하게 지원하고 있습니다. 오페라 브라우저를 통해 예제를 확인해 보세요. 다른 브라우저와는 다르게 인풋을 좀 더 편리하게 작성할 수 있도록 도울 것입니다.

HTML5의 인풋 타입을 적절하게 사용하면 아이폰 사용자에게 다음과 같이 문맥에 알맞는 자판을 보여줄 수 있습니다. 입력 커서가 인풋에 들어갔을 때 인풋 타입을 인식해서 최적화된 자판 배열을 표시합니다.

input type="search" 일 때 아이폰은 자판에 Search 키를 보여줍니다. 아이폰으로 input type="search" 테스트 해보기.
input 타입이 search 일 때 아이폰 자판 - 자판에 검색 버튼이 등장

input type="tel" 일 때 아이폰은 자판에 숫자와 + * # 키를 보여줍니다. 아이폰으로 input type="tel" 테스트 해보기.

input 타입이 tel 일 때 아이폰 자판 - 숫자 입력 전용 키패드가 등장

input type="url" 일 때 아이폰은 자판에 .com과 Go 키를 보여줍니다. 아이폰으로 input type="url" 테스트 해보기.

input 타입이 url 일 때 아이폰 자판 - .com .net .co.kr 등과 같은 빠른 입력 키가 등장

input type="email" 일 때 아이폰은 자판에 @와 . 키를 보여줍니다. 아이폰으로 input type="email" 테스트 해보기.

input 타입이 tel 일 때 아이폰 자판 - Space 입력키 우측에 @키와 .(닷)키가 등장

input type="number" 일 때 아이폰은 자판에 숫자와 특수문자 키를 보여줍니다. 아이폰으로 input type="number" 테스트 해보기.

input 타입이 number 일 때 아이폰 자판 - 숫자키와 특수문자 키가 등장

Responsive Web Design

사용자가 어떤 해상도의 단말을 사용하든 그에 알맞는 뷰를 보여줄 수 있는 유연한 레이아웃 설계 기법입니다. 이름은 정말 근사하지만 막상 내용 뜯어보면 참 볼것 없습니다.

Mobile Viewport Declaration

모바일 단말기는 기본적으로 PC용 화면 전체를 작은 화면 안에서 모두 보여줍니다. 작은 화면에 전체를 담으려니 다음과 같이 글씨가 깨알만해져서 확대하지 않고는 보기가 어렵겠지요.(물론 아이폰4는 그냥 봐도 보입니다. 326dpi & 640*960px을 자랑하는 레티나 디스플레이잖아요.) 적당히 확대한 다음 수직 수평 스크롤을 해 가면서 어렵게 읽을 수 밖에 없습니다.

모바일 뷰포트를 설정하지 않고 아이폰에서 보는 화면

모바일 뷰포트를 선언하면 모바일 단말에 탑재된 웹 브라우저(Safari Mobile for the iPhone, Android browser, webOS browser in Palm Pre and Pixi devices, Opera Mini, Opera Mobile and BlackBerry browsers)는 웹 페이지를 적절히 크게 확대해서 보여줍니다.

<meta name="viewport" content="width=device-width, initial-scale=1, minimum-scale=1, maximum-scale=2, user-scalable=yes" />
meta 태그의 각 속성에 대한 자세한 설명

그러나 콘텐츠의 너비가 크기 때문에 당연히 수평 스크롤이 필요합니다. 아래 이미지를 보면 아시겠지만 오른쪽에 내용이 더 있는데 잘려서 보이지 않습니다. 사용자는 여전히 수직 수평 스크롤을 모두 해야만 하는데 이것은 여간 짜증스러운 일이 아닙니다.

모바일 뷰포트를 설정하여 아이폰에서 적당히 확대된 화면

그래서 필요한 것이 바로 Responsive Web Design 입니다. 사용자가 어떤 해상도의 단말기를 가지고 있더라도 알아서 유연하게 콘텐츠를 정돈해서 보여주는 기술이 필요합니다. 한때는 320px의 화면 너비가 모바일 화면 크기의 대세가 될 줄 알았지만 지금은 그렇지 않습니다. 매우 다양한 해상도를 지닌 디바이스들이 쏟아져 나오고 있지요. 그렇게 새로운 단말기가 등장할 때마다 그 해상도에 맞는 웹 페이지 화면을 추가로 개발하시겠습니까? 세상에 그런 삽질을.

CSS3 Media Queries

CSS3에는 Media Query 라는 명세가 있고 최신 브라우저들(IE9, Chrome, Safari, Firefox, Opera)과 아이폰용 모바일 사파리 브라우저도 이를 지원하고 있습니다. 다음은 모바일 뷰포트를 설정해서 적당히 확대한 다음 Media Query를 이용해서 레이아웃을 알맞게 정돈한 제 블로그의 모바일 화면 입니다. 아름답지요.

미디어 쿼리 문법을 간단하게 살펴보죠. 제 블로그는 모바일 환경이든 아니든 불문하고 브라우저의 너비가 980px 이하로 작아지면 화면 우측에 있는 글로벌 네비게이션이 화면 아래쪽으로 뚝 떨어집니다. 지금 브라우저의 폭을 조절해서 한번 확인해 보세요. IE 6~8 브라우저는 미디어 쿼리를 지원하지 않기 때문에 재현이 되지 않습니다. (그 낡아 빠진 브라우저 좀 그만 쓰면 안될까요?)

@media only all and (max-width:980px) {    /* 화면 너비가 980px 이하일 때에만 아래 코드를 실행 */
    .content{ float:none; width:auto }    /* 콘텐츠 플롯을 해제하고 너비를 자동으로 */
    .nav{ float:none; width:auto }    /* 네비게이션 플롯을 해제하고 너비를 자동으로 */
}

딱 이정도의 사용법만 알아도 반응형 웹 디자인은 게임 끝입니다. CSS3의 Media Query에 대해 더 자세히 알고 싶다면 아래 링크된 문서들을 참고해 보세요.

 게임 끝.

]]> http://naradesign.net/wp/2011/05/27/1483/feed/ 22 국내외 유명 웹 에디터 ‘p, br’ 구현방식 벤치마킹. http://naradesign.net/wp/2011/04/06/1461/ http://naradesign.net/wp/2011/04/06/1461/#comments Tue, 05 Apr 2011 19:26:39 +0000 정찬명 http://naradesign.net/wp/?p=1461 웹에서 마치 워드프로세서를 사용하는 것과 같은 편리함을 주는 글쓰기 도구를 우리는 통상 웹 기반의 위지윅 에디터라고 부릅니다. 오픈소스 XE 개발에 참여하며 오래전부터 심심치 않게 논쟁꺼리가 되어왔던 p, br, p margin 처리 방식을 고민하며 유명한 국내외 웹 에디터가 어떻게 구현되어 있는지 살펴 보았습니다.

인기있는 위지윅 에디터들의 p, br 구현방식
사용지역 에디터 이름 데모 <p>
keyboad		 <br>
keyboard		 <p>
margin
글로벌 CKEditor 있음 Enter Shift+Enter margin:1em 0
글로벌 TinyMCE 있음 Enter Shift+Enter margin:1em 0
글로벌 WYMeditor 있음 Enter Shift+Enter margin:1em 0
글로벌 widgEditor 있음 Enter Shift+Enter margin:1em 0
한국 SmartEditor Basic 있음 Enter Shift+Enter margin:1em 0
한국 Naver Smart Editor 없음 Enter Shift+Enter margin:0
한국 Daum Open Editor 있음 Enter Shift+Enter margin:0
한국 Xquerd 없음 Enter Shift+Enter margin:0
한국 Nate Editor 없음 Enter (p 대신 div 생성) Shift+Enter margin:0 (div 요소)

모든 웹 기반의 위지윅 에디터를 조사한 것은 아니지만 제가 간단하게 벤치마킹한 결과에 따르면 국내외를 막론하고 대부분의 제품들은 웹 브라우저가 기본으로 제공하는 처리 방식에 따라 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라는 새로운 에디터를 개발하며 이 문제를 어떻게 해결하는지 지켜봐주세요. 그리고 좋은 의견이나 경험담이 있으면 댓글로 함께 의견 나누시죠.

]]> http://naradesign.net/wp/2011/04/06/1461/feed/ 22 제4회 웹 표준의 날 + 9 Useful CSS3 Properties. http://naradesign.net/wp/2010/06/01/1315/ http://naradesign.net/wp/2010/06/01/1315/#comments Mon, 31 May 2010 21:25:58 +0000 정찬명 http://naradesign.net/wp/?p=1315 지난주 토요일 제4회 웹 표준의 날 행사가 있었습니다. 저는 이 행사를 2006년 첫 회 때부터 빠짐없이 참석했고 후기도 꼬박꼬박 작성해 왔었답니다.

  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.

]]> http://naradesign.net/wp/2010/06/01/1315/feed/ 26 장애인을 차단하는 세계 최초 신기술. http://naradesign.net/wp/2010/04/16/1274/ http://naradesign.net/wp/2010/04/16/1274/#comments Thu, 15 Apr 2010 17:43:21 +0000 정찬명 http://naradesign.net/wp/2010/04/16/1274/ 한국인터넷진흥원(KISA)은 어제 마우스 장치에 완전히 의존하는 비밀번호 입력 방식 ‘시큐어 패쓰’를 세계 최초로 개발했다고 언론에 공개 했습니다. 정말 어이가 없고 우리나라 IT 기술이라는게 이 정도로 후진국인가 창피해서 고개를 못 들 지경입니다. 한번 보시죠.

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

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

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

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

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

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

 

]]> http://naradesign.net/wp/2010/04/16/1274/feed/ 50 jQuery를 이용하여 FAQ 목록 만들기. http://naradesign.net/wp/2010/03/26/1265/ http://naradesign.net/wp/2010/03/26/1265/#comments Thu, 25 Mar 2010 16:15:41 +0000 정찬명 http://naradesign.net/wp/2010/03/26/1265/ FAQ(Frequently Asked Question) 목록은 어떤 요소로 마크업 할 것인지가 가장 고민이 됩니다. 예를 들면 다음과 같은 다양한 마크업 방법이 있는데요.

  • 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’ 요소는 실제로는 존재하지 않는 요소이므로 착오 없으시길 바랍니다.
jQuery를 이용한 FAQ 목록 입니다. 이런 효과를 흔히 아코디언 효과(accordion effect)라고 부릅니다. 이 예제를 새 창으로 보기 | OUIF 페이지에 더 많은 예제들이 있습니다.

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

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

관련글

]]> http://naradesign.net/wp/2010/03/26/1265/feed/ 46 CSS Bar Graph. Horizontal. Vertical. Star Rating. http://naradesign.net/wp/2010/03/17/1233/ http://naradesign.net/wp/2010/03/17/1233/#comments Wed, 17 Mar 2010 12:23:19 +0000 정찬명 http://naradesign.net/wp/2010/03/17/1233/ 목록(ul) 요소를 이용하여 CSS로 모양을 낸 수직 막대 그래프 입니다. 이 예제를 새 창으로 보기
목록(ul) 요소를 이용하여 CSS로 모양을 낸 수평 막대 그래프 입니다. 이 예제를 새 창으로 보기
다양한(p, ul, ol, dl) 요소에 콘텐츠로 포함되어 CSS로 모양을 낸 인라인 수평 막대 그래프 입니다. 이 예제를 새 창으로 보기
배경 이미지와 CSS로 모양을 낸 별점 그래프 입니다. 이 예제를 새 창으로 보기

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

]]> http://naradesign.net/wp/2010/03/17/1233/feed/ 40 jQuery+CSS Tree Navigation. http://naradesign.net/wp/2010/03/15/1225/ http://naradesign.net/wp/2010/03/15/1225/#comments Mon, 15 Mar 2010 12:30:15 +0000 정찬명 http://naradesign.net/wp/2010/03/15/1225/ jQuery를 이용한 Tree Navigation 예제는 어렵지 않게 찾을 수 있었는데요. 키보드만으로도 조작이 가능한 접근성 있는 예제는 찾기가 쉽지 않더라구요. 공개된 소스코드를 수정해서 사용할까 하다가 공부도 할 겸 해서 직접 만들어 봤습니다.

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

예제를 새 창으로 보기

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

]]> http://naradesign.net/wp/2010/03/15/1225/feed/ 30 메뉴 건너 뛰기 링크(Skip Navigation). http://naradesign.net/wp/2010/03/13/1221/ http://naradesign.net/wp/2010/03/13/1221/#comments Fri, 12 Mar 2010 18:11:47 +0000 정찬명 http://naradesign.net/wp/2010/03/13/1221/
  • 헤딩은 콘텐츠 블럭을 우회하는 가장 효과적인 방법
  • 반복되는 콘텐츠 블럭을 우회하는 방법
  • 메뉴 건너 뛰기 링크에 관한 쟁점
  • 키보드 사용자에게만 유용한 메뉴 건너 뛰기 링크
  • 글로벌 네비게이션을 본문 콘텐츠보다 늦게 마크업 하는 경우
  • 지나치게 많은 ‘** 건너 뛰기’ 제공은 오히려 공해
  • 메뉴 건너 뛰기에 관한 더 많은 의견들

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

    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 블로그는 모두 본문 콘텐츠가 먼저 마크업 되고 글로벌 메뉴가 나중에 마크업 되어 있습니다. 이런 경우라면 ‘메뉴 건너 뛰기’ 링크보다 ‘본문 건너 뛰기’ 링크가 더 적절할 것이고 나아가 ‘건너 뛰기 링크’는 생략해도 됩니다. 본문 콘텐츠는 모든 페이지에서 반복되는 내용도 아니고 많은 링크가 포함되어 있지도 않기 때문 입니다.

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

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

    네이버 뉴스 클러스터링 - 키보드가 접근 할 때 화면에 보이는 메뉴 건너 뛰기 링크

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

    ]]>     http://naradesign.net/wp/2010/03/13/1221/feed/ 11     Modal Windowed Login UI. http://naradesign.net/wp/2010/03/04/1199/ http://naradesign.net/wp/2010/03/04/1199/#comments Thu, 04 Mar 2010 14:47:40 +0000 정찬명 http://naradesign.net/wp/2010/03/04/1199/ 오늘은 XE에 사용하려고 모달 윈도우 처리된 로그인 UIO(User Interface Object)를 하나 만들었습니다. jQuery를 이용해서 스크립트도 직접 작성해 봤는데 잘 한건지 한 번 봐주시면 좋겠네요. 

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

    예제를 새 창으로 보기

    HTML

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

    CSS

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

    Javascript

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

    P.S.

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

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

    ]]>     http://naradesign.net/wp/2010/03/04/1199/feed/ 20