I am quite thrilled to have a standards compliant and decent new version of Internet Explorer 8 produced by Microsoft. It is absolutely different from its predecessors and good enough to be praised by lots of standards devotees. I am sure that all the users who are stick to the old school version 6 or 7 do not have any reason of hesistating to upgrade. Now there would be a very exciting browser war among star browsers: Internet Explorer, Firefox, Chrome, Safari, Opera and some more. With the launch of new Internet Explorer, I tested two things as a keyboard user. The keyboard usability is highly important especially for some group of people including users with screen readers, users with motor disabilities, users with screen magnifiers, and users with mobile devices. The result of the test was unsatisfactory and I hope to see a fix of this soon.

Keyboard navigation within a page problem

This is a well known bug in the previous version of Internet Explorer and I stated this in the other post: The next tab navigation goes wrong after the activation of a skip navigational link within a page. Developers used some work-arounds to avoid this same-page navigation problem. I expected to see an improvement of this troublesome issue in Internet Explorer 8 but it sitll has the same bug. You can identify this problem by yourself at this testing page. Safari and Chrome have the same bug and only some Gecko based browsers (i.e. Firefox, SeaMonkey, etc) work exactly as expected today. Opera works differently according to the viewport size. It works very unique way and its keyboard navigation between links (Shift + arrow keys) is dependent on how much you see within a page. Hopefully I would like to deal with this Opera’s unique problem later.

Keyboard navigation between two frames problem

This is more subtle and has not been issued a lot since framed web pages are not used often in standards friendly web development these days. The problem is like this. When you activate a link in a frame whose target is in the other frame, the focus should be jumped into the other frame. Unfortunately there is no modern visual browser which support this. Although you activate the link in the first frame, you are still in the first frame and by pressing the tab again, you will be directed to the next link in the same frame. Look at this cropped frames sample page from University of North Texas.

The link in the picture, “Links Challenge” has “right” as the target attribute and it causes a change in the right frame. When you navigate this page with keyboard only, it is natural to continue your tab navigation in the “right” frame after selecting the “Links Challenge” link in the left frame. In reality, however, when you press the tab key again after “Links Challenge” is activated, you will be directed to the “Images Challenge” within the same frame not “Skip Navigation” link in the target frame. In short, in the picture, path “a” is wrong way and path “b” is the right way to navigate with the keyboard. Unfortunately there is no visual browsers (at the time of this writing) who support the path “b” and only two screen readers, JAWS and Home Page Reader make up for this and they will lead you to follow path b according to Jim Thatcher.

2008년 11월 3일 행정 안전부와 한국 정보 문화 진흥원에서 개최한 민간 부문의 장애인 웹 접근성 제고 세미나가 있었습니다. 제가 제일 마지막에 하나를 발표했는데, 웹 콘텐츠 접근성과 모바일 웹 접근성의 유사한 점, 그리고 장애인과 모바일 웹 사용자들의 비슷한 사용자 경험 등을 소개하려고 했습니다. 세미나 하면서 이번처럼 벼락치기로 준비한 것도 처음이었습니다. 그래서 원고도 꼴찌로 내고, 발표 시간에 겨우 맞추어 헐레벌떡 도착하고, 발표 하면서도 주제가 왔다 갔다 하면서 시간도 엄청나게 초과하는 우를 범했습니다. 세미나 진행하시는 분들에게는 최고로 미운 사람이 되었을 것입니다. 죄송합니다…

아무튼 모바일 웹은 매우 중요한 유행어(buzzword)가 되었을 뿐만 아니라 앞으로 다양한 모바일 기기와 기술은 웹을 접하는 중요한 플랫폼이 될 것임에는 틀림 없습니다. 발표 자료를 공유합니다.

구글 크롬이 나오자마자 블로그 스피어가 떠들썩하네요. 사실 저는 어제 오늘 정신없이 바빠서 프로그램을 볼 겨를도 없었고, 새로 나온 혁신적인 제품을 앞장서서 써보는 얼리 어답터(early adopter)도 아니기에 그냥 바라만 보고 있었습니다. 그런데 오늘 새로운 브라우저와는 전혀 거리가 먼 아버지로부터 문자를 한 통 받았습니다. 형이 개발에 참여한 크롬이라는 새로운 제품이 출시되었다는 내용이었습니다. 이번 여름에 미국 가서 형을 만났을 때에도 새까맣게 비밀로 해서 전혀 눈치 채지 못했었는데. 애플이나 구글이나 깜짝쇼 하면서 제품 내놓는 것이 비슷하네요.

지금까지 저는 집의 컴퓨터에서 오페라를 기본 브라우저로 쓰고 있고, 파이어폭스와 사파리, 그리고 인터넷 익스플로러를 보조적으로 쓰고 있었습니다. 물론 액티브엑스(ActiveX)로 떡칠이 된 한국 정부의 추한 웹 사이트들과 독점을 조장하는 금융결제원의 업무 태만과 법원의 몰상식한 판결로 아직도 앞길이 깜깜하기만 한 한국의 인터넷 뱅킹 사이트, 기타 상업용 사이트들 때문에 어쩔 수 없이 자유로운 선택이 막혀서, 구시대의 인터넷 익스플로러 6을 찜찜한 마음으로 써야 합니다. 오페라를 기본 브라우저로 썼던 이유는 웹 표준을 매우 잘 지원해주고, 탭 브라우징이 가장 완벽하고, 그리고 가볍고 빠르기 때문이었습니다.

회사에서는 사파리가 주 사용 브라우저였습니다. 그 이유는 회사에서 정책적으로(?) 파이어폭스와 오페라를 설치하지 못하도록 막아놨는데, 이상하게 사파리는 아직까지(!) 설치 및 실행이 가능했기 때문입니다. 맥용이 아닌 피씨용 사파리는 사실 별로 썩 편하진 않습니다. 느린 속도와 한글 처리에 있는 약간의 버그, 일반 윈도우즈용 프로그램과는 전혀 다른 방식의 글자 처리 등 때문에.

파일 크기가 474 킬로바이트밖에 안 된다는 말에 혹해 뒤늦게(?) 구글 크롬을 회사 컴퓨터에 받아봤습니다. 다행히 지금까지 다운로드 및 설치를 막아놓진 않았군요. 일단 다운로드 및 설치는 1분이면 끝납니다. 그리고 몇 개 사이트를 띄워봤습니다. 뭐 프로그램이 워낙 가볍고, 탭별로 서로 다른 독립적인 프로세스로 움직이는 점, 자바스크립트 처리 속도가 빠른 점이 일단 마음에 듭니다. 사파리와 컹커러(Konqueror)에서 사용하는 웹킷(Webkit)을 기본 렌더링 엔진으로 사용하기 때문에 새삼 웹 표준 지원에 대해서는 별로 걱정하지 않았고, 다른 사용자들이 이미 시험 결과를 많이 내놓았습니다. 저의 개인 블로그에서는 CSS 2.1의 외곽선(outline) 속성을 쓰고 있고, 일체의 시스템 종속적인 글꼴을 다 빼고, 오로지 범용 글꼴(generic font)만을 쓰고 있는데, 지금까지는 오로지 오페라만이 정확히 의도한 바를 표시했었습니다. 그런데 구글 크롬도 문제 없이 잘 표시해주네요.

운영체제(OS)가 아닌 웹이 플랫폼이 되어가는 시기에서 브라우저는 웹을 열어주는 관문으로서 잘 드러나지 않지만 매우 중요한 프로그램입니다. 사실 제가 하루에 컴퓨터를 쓰는 동안 브라우저를 닫아 놓고 있는 순간은 아마 거의 없을 것입니다. ‘컴퓨터로 하는 일’ = ‘웹에서 하는 일’이 거의 동의어가 된 지 오래되었습니다. 그런 의미에서 바람직한 브라우저는 사용자가 느끼지 못할만큼 투명하고 가볍게 뒤에서 사용자의 웹 작업을 도와주는 것이 시대의 요구였던 것 같습니다. 그런데 그런 요구에 가장 근접한 브라우저가 현재로선 크롬이라는 생각이 듭니다. 그래서 회사 컴퓨터에서 사파리를 대체해 크롬이 저의 제일 브라우저로 설정이 되었습니다. 집의 컴퓨터는 내일로 미루기로…

제가 얼마 전에 블로그에 제목의 중요성에 대한 글을 썼습니다만, 구글 웹마스터 도구로 진단을 하다 보니, 정작 제 자신의 블로그에는 제목이 중복되는 페이지가 꽤 있었습니다!! 특정 카테고리(category)와 태그(tag) 페이지까지는 제목을 구분해주었지만, 검색 결과 페이지가 블로그의 처음 페이지와 제목이 똑같았었고, 특정 카테고리가 여러 페이지로 구성된 경우, 카테고리까지만 구분이 되고 페이지 번호는 구분이 되지 않아, 모든 페이지의 제목이 똑같았습니다!

그래서 모든 페이지에 정말로 고유한(unique 또는 distinctive) 제목을 붙이기 위해 워드프레스의 header.php 파일의 페이지의 제목을 나타내는 부분을 아래와 같이 고쳤습니다.

<title>
	<?php 
		bloginfo('name'); 
		if ( is_home() ) { 
			echo(": ");
			bloginfo('description');
		} 
		if ( is_single() ) { 
	?>		- Archive
	<?php 
		} 
		if ( is_category() ) {
	?>		- Category
	<?php
		}
		if ( is_tag() ) {
	?>		- Tag
	<?php
		}
		if ( is_search() ) {
	?>		- Search results for 
	<?php 
				the_search_query(); 
		}
		wp_title(' - ',true,'');
		if ( is_paged() ) {
	?>		- Page <?php echo($paged); } ?>
</title>

이제 현재 보는 페이지가 홈이면 블로그의 제목이, 특정한 글이면 글 제목이, 특정한 카테고리이면 카테고리 제목이, 태그 페이지이면 태그 제목이, 검색 결과이면 검색 결과라고 표시됩니다. 추가로, 카테고리나 태그, 또는 검색 결과가 여러 페이지로 구성된 경우에는 각각의 페이지마다 페이지 번호를 제목에도 넣어주었습니다. 예를 들면 아래와 같이 나옵니다.

첫 페이지:

Greg Shin’s Blog: 신승식의 블로그

특정한 글 하나만 나오는 페이지:

Greg Shin’s Blog – Archive – 한국이 중국인가?

“accessibility” 태그 페이지:

Greg Shin’s Blog – Tag – accessibility

“Review” 카테고리 페이지:

Greg Shin’s Blog – Category – Review

“Review” 카테고리 중 두 번째 페이지:

Greg Shin’s Blog – Category – Review – Page 2

“accessibility”를 넣어 검색한 결과 페이지:

Greg Shin’s Blog – Search results for accessibility

“accessibility”를 넣어 검색한 결과 중 두 번째 페이지:

Greg Shin’s Blog – Search results for accessibility – Page 2

제목은 이렇게 해서 고유해졌는데, 메타 데이터(meta data)가 중복되는 페이지가 있군요. 페이지의 키워드, 설명 등 메타 데이터도 페이지의 특성에 가장 맞게 동적으로 생성해서 넣어야 겠는데, 이것에 대해서는 좀 고민해봐야겠습니다. 현재는 심플 태그(Simple Tags)라는 플러그인을 쓰고 있어서, 태그로 사용된 단어가 페이지의 키워드(<meta name="keywords" ...)로는 들어가게 되어 있습니다만, 페이지의 설명(<meta name="description" ...)이 모두 똑같게 나오는 문제는 여전히 남아있습니다.

최근 여러 개의 웹 사이트들을 자세히 뜯어볼 일이 생겨서 혹 뭐 트집(?)잡을만한 것 없나 의심의 실눈을 뜨고 페이지들을 살펴보았습니다. 그리고 두 가지를 느꼈습니다. 하나는 아마추어인 내가 점점 이해하기 어려운 방식의 코드가 늘어난다는 것이고, 다른 하나는 그럼에도 아주 복잡한 기법을 쓰는 사람들이 정작 기본적인 것을 놓치는 경우도 있다는 것입니다. 그 기본적인 것 중에 하나가 바로 “제목”입니다.

좋은 제목의 조건

이 세상 모든 것에는 제목이 있습니다. 사람에게는 이름이 있고, 컴퓨터의 파일에도 이름이 있고, 웹 페이지에도 이름이 있어야 합니다. 그 이름은 반드시 그 페이지의 내용을 대표할 수 있게 적절하게 지어야 합니다. 10개의 페이지로 이루어진 사이트가 있는데, 첫째도 “환영합니다”, 둘째도, 세째도, 마지막 페이지도 “환영합니다.”라는 똑같은 이름을 가졌다면, 웹 페이지 방문자들은 혼란스러워합니다. 그래서 이름을 짓는 것, 제목을 붙이는 것은 아무리 강조해도 지나치지 않은 매우 중요한 작업입니다. 제목은 다음과 같은 특성을 갖고 있어야 합니다. 아니 갖고 있어야 한다고 저는, 생각합니다.

대표성:

제목은 그 제목이 대변하는 더 많은 내용을 대표할 수 있어야 합니다. 예를 들어 이메일을 작성할 때에도 “아무개 회사 누구입니다.” 라고 모든 메일의 제목을 똑같이 쓰는 사람과 메일을 주고받다 보면 짜증이 납니다. 나중에 제목만으로 어떤 메일이 어떤 메일이었는지 구분이 안 되기 때문입니다. 게시판에 글을 올릴 때에도 “급한 질문입니다.” 이렇게 글을 올리면, 그 질문의 내용이 무엇이었는지 들어가보지 않으면 모릅니다. 나중에 특정한 질문을 찾으려고 검색을 해도 이런 “급한 질문”은 도움이 안 됩니다. 웹 페이지의 제목도 마찬가지입니다. 그 페이지의 내용을 가장 잘 대표하는 단어나 문장, 문구로 이루어져 있어야 합니다.

고유성(uniqueness):

모든 페이지의 제목은 고유해야 합니다. 그래서 페이지의 제목을 붙이는 것은 쉬운 일이 아닙니다. 하다 못해, 게시판에 글이 여러 개 있는데, 어떤 글을 읽을 때, 그 글에 답변을 달 때, 글목록을 볼 때, 글을 지울 때, 다른 글을 읽을 때 모두 각각의 상황에 맞고 다른 것과 구별되는 페이지 제목을 가지고 있어야 합니다. 아주 엄격히 말해서 페이지가 1,000개가 있다면 1,000개가 모두 다른 제목을 가지고 있어야 합니다. 이렇게 페이지의 제목이 다른 것과 구별되게 함으로써, 페이지가 너무 많아져도, 제목만으로 쉽게 구분할 수 있도록 할 수 있습니다. 이렇게 고유한 페이지의 제목은 일반 사용자들은 물론이고, 비시각적인 단서를 이용하는 시각 장애인들에게는 여러 개의 웹 페이지를 왔다갔다 하는 데에 매우 큰 도움이 됩니다.

간결성:

두 말하면 잔소리이지요. 요즘에 많이 줄었지만 페이지 제목에 이상한 문자를 넣는 경우가 있습니다. 예를 들면 “▒▒▒▒ 무슨무슨 기관 홈페이지에 오신 것을 환영합니다. ▒▒▒▒” 이런 식으로 말입니다. 사실 홈페이지 방문자를 정말 환영하고 싶으면, 제목부터 간결하게 쓸 데 없는 특수 문자 다 빼고, 환영한다는 말도 제목에서는 빼는 게 좋습니다. 대신 페이지의 내용에서 환영한다고 뜻을 밝혀도 충분합니다. 그냥 “무슨무슨 기관”만으로도 충분하지요.

합법적인(의미적인) 코드(semantic code):

웹 페이지에 있는 구성 요소들은 지금까지 합의된 합법적인 방법으로 제목을 표시해주어야 합니다. 그렇지 않고, 작성자가 맥락적으로 또는 암묵적인 방법으로 그것이 제목이라고 아무리 우겨도, 합의된 코드를 사용해서 명시적으로 제목을 표시해주지 않으면, 많은 사람들이 제목의 혜택을 얻지 못합니다. 즉, 내용과 제목을 명확하게 짝지어 주어야 합니다(explicit binding, 명확한 짝짓기). 자 이제 합의된 방식으로 제목을 표시하는 HTML의 기본 중의 기본을 한 번 나열해봅니다.

HTML에서 제목을 나타내는 방법

각 요소/속성마다 링크를 걸어놓았으니 모든 HTML 요소나 속성들에 대한 구체적인 사용법은 링크를 따라가서 참조하십시오.

페이지의 제목: <title> 요소

한 사이트 안에서 모든 웹 페이지들이 고유한 제목을 가지고 있어야 한다고 했습니다. HTML에서는 <title> 요소 안에 제목을 표시합니다. 예를 들면 제 블로그 안에서 http://gregshin.pe.kr/blog/archives/163 라는 페이지는 <title>신승식의 블로그 – Blog Archive » 청와대여, 기자들이여, 쑈를 하라!</title>와 같이 제목을 표시했습니다. 간혹 이 제목 부분에 자바스크립트를 써서 글자가 움직이게 하는 경우가 있는데, 절대 하면 안 되는 아주 나쁜 제작 습관입니다. 화려함을 자랑하고 싶다면 내용에서 해도 충분합니다.

프레임의 제목: title 속성

요즈음에는 프레임을 잘 사용하지 않지만, 프레임을 혹 사용한다면, 각각의 프레임이 고유하고, 내용이나 기능을 대표하는 제목을 가지고 있어야 합니다. 주의할 것은 프레임 제목을 사람이 알 수 있게 작성해야 한다는 것입니다. 예를 들면 title=”frame1″과 같이 하면 안 되고, title=”뉴스 브리핑”과 같이 해주어야 합니다.

문단의 제목: 헤딩 요소 <h1>, <h2>, <h3>, <h4>, <h5>, <h6>

자바도 아니고, 자바스크립트도 아닌 HTML은 정말 쉽습니다. 그런데 그 쉬운 HTML, 그리고 그 중에서도 정말 쉬운 문단의 헤딩을 빠뜨린 웹 페이지가 정말 많습니다. 많은 양의 텍스트, 그림, 도표 등이 있는 문서를 만들 때에 체계를 만들고, h1을 이용해 보통은 페이지를 대표하는 제목을, h2를 이용해 큰 제목을, h3을 이용해 중간 제목을, h4를 이용해 작은 제목을 달아주면 됩니다. 이렇게 하지 않고, 아무리 큰 글씨로 “이게 제목이야”라고 우겨도, 상당히 많은 사용자들은 그게 제목인지 알지 못하고, 제목만으로 내용 블럭을 구분하지 못합니다.

데이터가 담긴 표의 제목: <caption>

우리 나라 웹 페이지에서 잘 볼 수 있는 특이한 표현 방식 중에 하나는 빤히 데이터가 들어있는 대량의 텍스트나 표를 아예 이미지로 표시한다는 것입니다. 이렇게 이미지로만 표현된 데이터는 기계적으로는 아무 데이터가 아닙니다. 게다가 그것에서 유의미한 텍스트를 재활용한다든지, 추론을 한다든지, 일부를 복사한다든지, 시각적으로 크게 보기 위해 확대한다든지, 또는 줄인다든지, 더 선명한 색깔로 바꾼다든지, 나의 브라우저 환경에 맞게 재구성하거나 다른 감각 양식(modality)으로 바꾸어 전달해 주는 것이 거의 불가능합니다. 그래서 데이터가 담긴 표는 되도록이면 <table>이라는 요소를 이용해서 나타내야 합니다. 그리고 그 표가 무엇을 나타낸 표인지 한 개의 제목으로 압축해서 제목을 붙여주어야 합니다. 그럴 때에 <table> 바로 밑에다가 <caption>을 넣어주면 됩니다.

표 안에서 한 열이나 한 줄을 대표하는 제목: <th>

데이터가 있는 표는 보통 제목줄 또는 제목열과 일반 데이터가 있는 수많은 칸들로 이루어져 있습니다. 이 제목줄과 제목열에 예쁘게 하늘색으로 칠해준다고 제목이 되는 것이 아닙니다. 반드시 제목을 나타내는 요소인 <th>를 사용해야 합니다. 조금 복잡한 표의 경우 사용법이 좀 까다롭기 때문에 여기서는 이 정도만 언급합니다.

사용자 입력을 받는 폼 요소의 제목: <label>

웹의 저자가 일방적으로 무언가를 보여주는 것이 아니고, 사용자로부터 입력을 받는 양식을 폼(form)이라고 합니다. 폼에는 체크 상자, 라디오 버튼, 텍스트 입력 상자, 목록 상자 등 여러 종류가 있습니다. 그런데 이런 폼들이 달랑 폼만 나오면 사람들은 거기에다 무엇을 입력해야 하는지 모릅니다. 그래서 이런 폼에는 반드시 그게 무엇을 입력해야 하는 폼인지 제목을 <label>을 이용해 붙여줘야 합니다. 예를 들어 아이디를 넣어야 하는 입력 상자 앞에 그냥 텍스트로 “아이디”라고 넣어주는 것만으로는 부족합니다. 반드시 <label>을 이용해서 표시해주어야 합니다. 그렇게 해야 맥락을 파악하기 어려운 시각 장애인들이 해당 폼에 갑자기 툭 떨어졌을 때에, 그것이 “아이디”를 넣으라는 폼인지 알 수 있습니다.

유사한 여러 개의 폼 요소를 한 개의 집단으로 묶은 <fieldset>의 제목: <legend>

폼이 너무 많아지면, 폼 안에서 길을 잃을 수 있습니다. 예를 들어 회사 정보와 개인 정보를 각각 10가지씩 입력해야 하는 폼의 경우, 중간쯤 왔는데 “주소”를 넣으라고 하고, “우편번호”를 넣으라고 합니다. 그런데 이게 회사의 주소였는지 개인이 사는 집의 주소였는지 헷깔릴 수 있습니다. 따라서 이런 경우, 회사 정보 입력하는 부분을 묶어서 “회사 정보”라는 제목을 붙여주는 것이 좋습니다. 그럴 때 이용하는 것이 바로 <fieldset>이라는 요소입니다. 이렇게 함으로써 특히 폼을 쓰는 데에 어려움을 겪는 시각 장애인들이나 너무 많은 폼 안에서 이동의 어려움을 겪는 키보드 사용자들은 임의의 묶음으로 건너뛸 수 있어서 도움을 받습니다.

목록 상자에서 여러 개 목록 묶음을 대표하는 제목: <optgroup>

목록 상자(list box)에 목록이 너무 많을 때, 예를 들면, 전국 도시 이름을 목록 상자에 다 집어 넣고, 선택하라고 할 때에 순차적으로 목록을 탐색해야 하는 사람에게는 상당한 고역일 수 있습니다. 그럴 때에 도시들을 강원도, 경기도 등과 같이 지역별로 묶어서 제목을 적절히 붙여준다면 좀 더 쉽게 선택할 수도 있습니다.

용어 설명에 대한 용어 제목: <dt>

어떤 것에 대한 정의, 설명, 정의, 설명이 여러 번 반복된다면, 이것은 정의 목록(definition list, 즉 <dl>)을 이용하는 것이 좋습니다. 그래서 정의 부분은 <dt>로, 설명 부분은 <dd>로 나타냅니다. 이렇게 함으로써 이 설명이 무슨 용어, 또는 무슨 제목에 대한 설명이었는지 알 수 있게 됩니다.

참 다양한 요소에 제목을 붙일 수 있게 되어 있습니다. 꼭 HTML 문서가 아니더라도, 제목이 잘 붙어있어서, 접근하기 쉽고, 데이터로서 가치가 높은 양질의 문서들이 많으면 좋겠습니다.

우리 회사에서는 오라클 사의 아이러닝(iLearning)이라는 학습 관리 시스템을 쓰고 있다. 그 시스템은 비교적 국제화(globalization)가 잘 되어 있어서 지금까지 영어, 한국어, 스페인어, 프랑스어, 네덜란드어, 독일어로 된 하위 시스템을 구축하는 데에 문제가 거의 없었다. (물론 그냥 데이터는 그 밖에 언어인 중국어, 러시아어 등을 쓰는 데에도 문제가 없었다.) 그런데 이번에 중국어(Simplified Chinese) 기반으로 다시 하위 시스템을 만드는 과정에 여러 곳에서 문제가 발견되었다. 중국어쪽 고객이 많지 않아서인지 아예 중국어쪽 메뉴 타이틀에 대한 사전(dictionary)을 만들어놓지 않은 경우도 꽤 있었다.

그 중에 하나가 로컬에서 만든 CJK(중국어, 일본어, 한국어) 문자가 포함된 유니코드 파일을 서버에 업로드하면 문제가 생겼다. 서버는 분명히 유니코드 인코딩 방식의 하나인 UTF-8로 페이지를 보여주고 있었지만… 처음에는 파일을 잘못 만들었나 여러 가지로 검토해보았으나, 문제는 명백히 서버 쪽에 있었다. 그래서 결국에는 원본 파일에서 CJK 문자를 쓰지 않도록 할 수 밖에 없었는데, CJK 문자를 문자열 단위로 HTML의 엔티티 문자(entity character)로 바꾸어주는 사이트를 이용하다가 이건 아무래도 너무 불편해서, HTML 타이디(Tidy)에 인코딩 방식을 자동으로 바꾸어주는 옵션이 있다는 것을 알았다. CJK 문자가 포함된 문서를 ISO-8859-1로 바꾸면서 CJK 문자를 한꺼번에 엔티티 문자로 바꾸려면 아래와 같이 하면 된다.

tidy --input-encoding utf8 --output-encoding latin1 input_file > output_file

페이지 내 링크(within page link, same page link)란 한 웹 페이지 안에서 이동하는 링크입니다. 많이 쓰는 곳은 FAQ나 법 조항처럼 페이지 위쪽에 목차나 목록이 먼저 나오고 하나를 선택하면 그것과 대응하는 답변이나 상세 내용이 있는 부분으로 이동하기, 시각 장애인이나 키보드 사용자가 페이지 안에서 너무 많거나 복잡한 메뉴를 건너 뛰고 중요한 곳으로 바로 이동하기, 또 페이지 아주 밑으로 갔다가 페이지의 상단부로 다시 돌아오기 정도가 아닐까 생각됩니다. 이 중에 복잡한 메뉴를 건너 뛰는 목적의 링크를 보통은 바로 가기(skip navigation) 링크라고 합니다.

링크와 링크, 양식(form) 요소, 또는 다른 요소들 사이를 이동하는 방법은 브라우저마다 조금씩 다릅니다. 그러나 키보드를 사용했을 때에, 현존하는 브라우저 중에 이런 페이지 내 링크를 정말로 제대로 지원해주는 것을 찾기가 쉽지 않습니다. 우선 윈도우즈에서 자주 사용하는 인터넷 익스플로러 7, 파이어폭스 2, 오페라 9, 사파리 3으로 페이지 내 링크를 시험해보았습니다만 파이어폭스를 제외한 모든 브라우저에서 문제가 발견되었습니다. 이런 브라우저의 특성을 제작자가 다 알아서 꼼수를 써서 해결할 수는 없기 때문에 다음 버전 제품에서는 빨리 이 문제가 개선되면 좋겠습니다.

바로 가기 링크 시험용 예제 페이지

SMIL represents Synchronized Multimedia Integration Language recommended by W3C. It is one of the XML applied domains which can control multiple images, videos, sounds, and texts. It is theoretically known as easy to develop, fairly accessible, and web native while it is not accessible in most common environment, only supported partly by a few web agents or players.

I developed a simple SMIL file for practice purpose. I just started to learn its syntax by myself and I am still far from making it highly compatible, standard-compliant, or accessible. I tested this first SMIL presentation with RealOne player and Ambulant Player 1.8. Ambulant Player is the only player who supports SMIL version 2.1 and RealOne supports 2.0 while Apple’s QuickTime supports 1.0. Although Internet Explorer 5.5 or higher supports XHTML+SMIL, this combination does not work on other browsers.

Therefore, I tried to embed the SMIL file in my web page using standard <object> HTML element with type="application/smil+xml" attribute but failed because I could not find any browser which supports this MIME type automatically. I had no choice but to include non-standard deprecated <embed> element for non-Internet Explorer browsers with RealPlayer ActiveX for Internet Explorer.

Download the SMIL presentation file: October Trip to Haneul Park with CMHV Befrienders(2007)

Any feedback including comments, suggestions, or critiques for more accessible SMIL and more compatible SMIL embedding in a web page would be welcomed.

The presentation shows a series of photos taken at Haneul Park with my community members in CMHV paralleled with a background musical piece which was composed by me long time ago.

한글날을 맞아 우리글닷컴에서 개발한 소위 지능형 한글 글꼴이라는 것을 무료로 배포하고 있다고 신문에 보도되었습니다. 글꼴을 만드는 작업은 고도의 기술력과 프로그래밍, 디자인, 노력, 비용의 산물이기 때문에 우리글닷컴에서 개발한 결과물에 대해 감사와 경의를 표합니다. 그런 노력에 꼬투리를 잡으려는 의도는 아니며, 전문가가 아닌 일반 사용자로서 느낀 몇 가지 아쉬움, 신문 기사의 오류에 대해 말하고자 합니다. 제가 틀린 내용을 주장한다면 댓글로 반박해주십시오.

첫째, 서명덕 기자님의 기사에는 약간 오류가 있습니다. 기존에 윈도우즈 사용자들이 쓰던 굴림, 돋움 글꼴은 비트맵 글꼴이 아니라 트루타입 글꼴이지만, 작은 크기에서 트루타입 힌팅(hinting)이나 래스터라이징(rasterizing) 기술이 떨어질 때에 만들었던 글꼴이라 가독성을 임의로 높이기 위해 글꼴 크기마다 비트맵으로 디자인을 해놓은 것 뿐입니다.

둘째, 화면용 글꼴과 인쇄용 글꼴의 이원화는 비단 우리 나라에서만 생긴 문제는 아닙니다. 로마자 알파벳을 쓰는 서구 문화권에서도 아직까지 화면용 글꼴로는 고딕 계열(sans-serif)을 더 많이 사용하고, 인쇄시에는 명조 계열(serif)을 더 많이 사용합니다. 그것은 모니터와 글꼴의 품질이 아무리 발전했다고는 하지만 아직까지도 명조 계열을 종이에서만큼 깨끗하게 표시하는 데에 한계가 있기 때문이지 않을까 싶습니다. 그리고 사람들도 그것을 그냥 당연하거나 익숙하게 생각하기도 하구요.

셋째, 명조 계열 글꼴의 가독성이 더 좋다는 증거는 뚜렷하지 않습니다. 김태진(1991)의 실험 결과에서도 명조 계열 글꼴과 고딕 계열 글꼴의 지각적 반응 속도의 차이는 거의 없었고, 당시 유행하던 탈네모꼴 글꼴보다 네모꼴 글꼴을 더 쉽게 지각할 수 있는 것으로 나타났습니다. 그 이후로 제가 어떤 연구가 되었는지 찾아보지 않아서 추가적인 어떤 증거가 있는지는 모르겠습니다. 다른 증거가 있다면 알려주십시오.

넷째, 인터넷 한글 활자의 공급이 마이크로소프트사에만 의존하고 있다면서 한국인을 위한 한국인에 의한 인터넷 활자의 제작이라는 취지는 좋지만, 하필이면 마이크로소프트사의 인터넷 익스플로러에서만 작동하는 비표준 독점 기술인 액티브 엑스를 사용해야만 글꼴을 볼 수 있다는 것이 아쉽습니다. 다른 브라우저 사용자들은 유료로 돈을 주고 글꼴을 사야 하겠지요.

다섯째, VTT(Visual TrueType)은 마이크로소프트의 폰트 개발 도구로 윈도우즈 XP에서부터 도입된 소위 클리어타입(ClearType)이라는 발전된 힌팅 기술을 적용해 글꼴을 개발할 수 있게 해주는 것입니다. 이 툴을 이용했다는 것과, 한글 글꼴폭을 가변적으로 했다는 것만으로 지능형 한글 시스템이라는 이름을 붙인 것은 좀 과장인 것 같습니다. 가변폭 글꼴은 이미 1990년대에 빨래줄 글꼴이 나오면서 등장을 했고, 글자의 폭이 다르기 때문에 초기에 워드프로세서와 같은 프로그램에서 처리하기가 상당히 까다로웠었지만 옛날의 이야기입니다. 디자인 면에서는 완전히 똑같은 폭에 모든 글자를 가두지는 않고, 그렇다고 기존의 빨래꼴 글꼴처럼 심한 변화를 주지는 않았네요. 그런데 “이” 모음이 있는 글꼴이 “오”나 “우” 모음 글꼴보다 확연하게 좁게 한 것이 개인적으론 아주 자연스러워보이지는 않습니다. 다만, 아직까지 한글 글꼴에서 글꼴의 특성에 따라 시각적으로 간격을 일정하게 조정해주는 커닝(kerning)이 적용된 글꼴이 없었다는 것을 감안하면 아주 반가운 일입니다.

참고: 영문 글꼴들은 보통 글자에 따라 폭이 넓거나 좁은 대신, 글자들 사이의 간격을 일정하게 유지하는 것이 일반적입니다. 글자의 폭을 일정하게 유지해야 하는 특수한 경우(예를 들면 코딩할 때 쓰는 글꼴이나, 구식 타자기 글꼴)에는 글자의 폭을 일정하게 유지하는 대신, 세리프(serif)를 크고 과장되게 그려서 여전히 글자간의 간격을 일정하게 유지하지요.

여섯째, 클리어타입이 모든 모니터에서 다 깨끗하게 잘 나오는 것은 아닙니다. 저같이 구형 LCD 모니터를 쓰는 사람들은 대부분의 힌팅을 적용한 글꼴들이 상당히 많이 퍼져서 흐릿하게 보이거나 색번짐이 나타납니다. 그래서 윈도우즈 비스타에서 기본으로 제공하는 맑은 고딕 글꼴에 똑같이 클리어타입을 적용해서 봐도, 고급 노트북 화면에서 볼 때와 구형 아날로그 연결 방식의 LCD 모니터에서 볼 때 상당히 차이가 납니다. 그래서 구형 모니터에서는 아직도 클리어타입을 비롯한 모든 힌팅 옵션을 다 끄고, 그냥 얇고 또렷한 굴림을 사용합니다. 맑은 고딕을 강제로 적용한데다가 전경과 배경색의 대비도 흐릿하게 해놓은 웹 페이지를 윈도우즈 환경에서 구형 모니터로 보고 있으면 상당히 짜증이 납니다. 마찬가지로, 웹 페이지에서 강제로 클리어타입을 적용하도록 해서 사용자에게 선택권을 빼앗아갈 때에 불편을 느끼는 사용자도 있을 수 있습니다.

일곱째, 웹에서의 여러 가지 글꼴 사용에 앞서, 보편적인 정보 전달 원리를 충실히 지켜야 합니다. 웹을 종이 매체와 똑같이 보는 것에는 무리가 있습니다. 종이 매체에 한 번 찍힌 글자는 그대로 고정되지만, 웹에 찍힌 글자를 모두가 똑같은 환경에서 보지는 않습니다. 사람마다 모니터의 종류도 다르며, 모두가 윈도우즈를 사용하지도, 인터넷 익스플로러를 쓰는 것도 아닙니다. 심지어, 어떤 사람은 글자를 시각적으로 듣는 것이 아니라 음성으로 웹 페이지를 듣습니다. 즉, 모든 사람이 해당 글꼴을 똑같이 볼 수는 없다는 것을 감안한다면 글꼴에 의존적인 디자인은 경계해야 합니다. 우리글닷컴 홈페이지에는 모든 사람이 윈도우즈 환경이며, 인터넷 익스플로러에서 해당 글꼴을 볼 수 있다고 가정하고, 게다가 글꼴을 특별히 키우거나 줄이지 않고 기본값으로만 본다고 가정하고 페이지를 디자인하였습니다. 따라서 위의 조건에서 조금이라도 벗어난 모든 사람들은 이상하게 어긋나거나 해독이 어려운 텍스트들을 보게 됩니다.

이와 같은 현상은 아직도 웹이나 컴퓨터 화면의 특성을 제대로 파악하지 못하고, 고정된 폭을 가진 종이 위에 타자기로 글자를 찍던 시절에 사용하던 줄바꿈 방식을 그대로 사용하기 때문에 일어납니다. 아직도 많은 사람들이 워드프로세서나 프리젠테이션 프로그램이나, 웹 페이지를 작성할 때에 흔히 범하는 실수입니다.

너무 부정적인 의견만 내세운 것 같습니다. 천편일률적이고 멋도 없는 굴림 글꼴 때문에 많은 사람들이 쓸데없이 그래픽으로 글자를 그리던 관행에서 벗어날 수 있는 대안적인 글꼴이 많아지고 보급되는 것은 참 좋은 일입니다. 그러나 그런 글꼴도 보편적인 기술 환경에서 보편적으로 활용 가능하도록 보급했으면 더 좋았을 것 같은 아쉬움이 남습니다. 그리고 새로운 글꼴을 써서 멋스럽게 웹 페이지를 만드는 것보다 더 중요한 것은, 정보 전달이라는 원래의 의도가 어떤 환경에서도 훼손되지 않도록 신경을 쓰는 일일 것입니다.

마시코 타카히로가 쓴 웹 표준 교과서가 김대석님의 번역으로 나왔습니다. 사실 번역은 아주 오래 전에 이루어졌습니다. 원본이 영어가 아닌 일본어이다보니 웹 표준에 대해서도 능통하고, 한국어, 일본어를 모두 소화할 수 있는 번역자로 김대석님은 아주 독보적이었던 것 같습니다. 그리고 2006년 초반인 것 같은데, 강민혜님, 신현석님, 조훈님과 함께 번역된 결과물의 우리말 감수를 맡게 되었습니다. 저는 접근성 부분 감수를 맡으면서 책을 구경하게 되었습니다. 말 그대로 교과서라는 이름이 어울리는 내용입니다. 방대한 관련 표준이 참고하기 좋게 담아져 있다는 뜻이지요. 일본 책이고 여러 우여 곡절 끝에 나오다 보니 시기상으로 늦게 나온 것이 아쉽습니다. 수만님의 훌륭한 실용적인 웹 표준 시리즈에 추가해 선택의 폭이 조금 더 넓어졌습니다.

책이 나오는 과정에서 부러웠던 것은 일본이라는 나라였습니다. 우리 나라는 아직까지 번역서가 아닌 우리 토종의 웹 표준 관련 책이 하나도 없지만 이웃 일본은 관련 책이 꽤 여러 권 나와 있습니다. 그만큼 일본은 이미 이런 분야까지도 책을 쓰고, 그것이 팔리고, 소비될 정도로 왕성하게 지식을 생산하고, 유통하는 나라이지만 우리는 아직까지 새로운 지식을 만들어낼 역량이 안 되거나 토양이 척박하다는 것이지요.

얼마 전에 감수자들과 디지털미디어리서치 조광현 사장님이 간만에 모이는 자리가 있었는데 애석하게 저는 참석하지 못해서 아직 책을 손에 넣지 못했습니다. 책을 얻으면 우리 회사에 있다가 한 웹 에이전시 회사로 떠나는 디자이너에게 선물로 주기로 했습니다. 유용하게 썼으면 좋겠습니다. 번역하신 대석님, 감수하신 훈님, 쿠키님, 현석님, 그리고 조광현 사장님 모두 고생하셨습니다.