도메인을 잃어버렸다.

지금까지 10년 넘게 개인 홈페이지와 블로그에 사용해오던 gregshin.pe.kr 도메인이 만료되고, 잠시 재등록을 하지 않은 사이에 누군가 도메인을 가로채버렸다. gregshin.pe.kr 도메인을 검색해본 결과는 아래와 같다.

도메인이름 : gregshin.pe.kr
등록인 : 정한
책임자 : 정한
책임자 전자우편 : rmdrk@hanmail.net
등록일 : 2016. 12. 05.
최근 정보 변경일 : 2016. 12. 05.
사용 종료일 : 2017. 12. 05.
정보공개여부 : N
등록대행자 : 메가존(주)(http://HOSTING.KR)
DNSSEC : 미서명

괘씸하게도 내가 예전에 사용하던 무지개 모양의 파비콘을 유지한 채로 실제 사이트는 오픈하지도 않았다. 즉, 도메인 장사를 하려고 선점한 것이다. pe.kr은 개인용 국내 도메인으로 가격도 싸고 가장 인기 없는 도메인이다. 내 홈페이지와 블로그는 최근에 거의 활동이 없었지만, 과거에 축적된 데이터는 꽤 많기 때문에 외부에서 참조하여 들어오는 링크는 상당히 많다. 그래서 함부로 도메인을 포기하는 것은, 인터넷(웹)과 나 자신의 신뢰도를 떨어뜨리는 것이라 꺼려지는 일이다. 그렇다고 도메인 장사꾼에게 웃돈을 주고 도메인을 사오고 싶지도 않았다. 하는 수 없이 기존 도메인을 포기하고, 호스팅 업체에서 제공하는 sshin.cafe24.com을 당분간 유지하기로 했다. 울며 겨자 먹기로 새롭게 gregshin.kr 도메인을 새로 구입했다.

문제는 과거에 내가 스스로 내 홈페이지 내부에서, 또는 소셜 미디어(페이스북, 트위터, 구글플러스, 링크드인 등)에서 과거 도메인으로 참조를 하고 있는 경우가 너무 많고, 대부분 수정도 되지 않았다. 또, 다른 사이트에서 아직도 내 과거 홈페이지 도메인을 참조하고 있는 링크가 꽤 많은데 이것은 내가 직접 고칠 수가 없다. 작은 일이지만 잠깐 소흘히 한 결과의 댓가가 크다는 것을 알았다. 우선 내가 직접 고칠 수 있는 것(내부에서 링크를 하고 있는 것)들부터 하나하나 고쳐나가기로 했다. 우선 절대 참조로 되어 있는 링크는 되도록이면 상대 참조 링크로 바꾸고 있는데, 이미지, 파일과 특정 블로그 포스트를 가리키는 링크 등 생각보다 많아서 시간이 꽤 걸린다. 또 하나하나 수정하는 과정 중에 외부로 나가는 링크도 깨져 있는 것이 다수 있는 것을 발견했다.

사실 gregshin.pe.kr에다가 보안 서버 인증서를 설치하고 싶었는데 할 수 없이 gregshin.kr에 설치했다. https로 바꾸고 나니 할 일이 상당히 많았다. 워드프레스(WordPress)와 기존 엑스프레스엔진(XpressEngine)의 기본 URL을 수정하는 것은 물론이고, http로 들어왔을 때에 https로 리디렉션 하도록 .htaccess 파일을 수정해주는 것, 그리고 곳곳에 숨어있는 내부 링크, 이미지 등에 쓰인 과거 URL들을 바꿔주는 것 등등 끝이 없다. 검색 엔진들은 다른 사이트에서 참조하고 있는 링크들을 중요하게 여기기 때문에 sshin.cafe24.com과 gregshin.pe.kr이 아직도 먼저 노출된다. 그러다 보니 sshin.cafe24.com 도메인에는 인증서가 없어서, 인증서 없이 들어오도록 놔두어야 했다. 아무튼 gregshin.pe.kr의 현재 소유 기간이 만료되면 다시 옛날 주소로 고칠 생각인데, 그 때엔 또 얼마나 많은 작업을 해주어야 하는지…

Read more "도메인을 잃어버렸다."

굴림, 돋움 제거 작전

아직도 많은 곳에서 굴림, 돋움 글꼴이 쓰이고 있다. 윈도우즈 7에서는 사용자가 바꿀 수 없는 기본 UI의 일부로 남아 있고, 많은 웹 페이지들은 기본적인 산스세리프(sans-serif: 세리프가 없는 고딕 계열 글꼴)로 굴림(Gulim)이나 돋움(Dotum)을 아직 많이 쓰고 있다. 굴림은 윈도우즈 3.1 시절에 처음 나왔고, 윈도우즈 95에서 기본 글꼴로 쓰이기 시작했는데, 해상도가 낮은 화면에서 9포인트(pt)에 특별히 디자인된 비트맵 글꼴 이미지가 깔끔하다는 이유로 아직 널리 쓰인다.

문제는 높은 해상도의 화면이 점점 더 많이 보급되면서 낮은 해상도에서 “특별히” 디자인된 굴림이 보기 싫은 경우가 많아졌다는 것이다. 나는 14인치 Full HD (1920 * 1080) 노트북을 쓰고 있는데, 웹 사이트에서 본문에 굴림 또는 돋움이 사용된 경우, 비트맵 글꼴이 너무 얇게 디자인 되어 있어서 보기가 상당히 고약하다. 화면을 확대해서 보기도 하는데, 그래도 큰 크기에 렌더링된 굴림은 힌팅(hinting: 수학적인 방법으로 윤곽선 폰트의 모양을 보완하는 것)이 안 되어 있기 때문에 상당히 못생기고 지저분해 보인다.

과거 윈도우즈 시절엔 대안이 없어서 굴림을 여기 저기 쓰는 것이 어쩔 수 없는 일이었지만, 이제 윈도우즈 사용자에게도 대안은 많이 있다. 윈도우즈 XP에서부터 나온 마이크로소프트의 클리어타입(ClearType: 마이크로소프트 윈도우즈 고유한 방식의 힌팅 기술)이 적용된 “맑은 고딕”이 있고 그 밖에도 대안은 아주 많아졌다. 적어도 세리프(serif: 꺾임이 있는 명조 계열 글꼴)가 아닌 산스세리프 글꼴에서는. 윈도우즈를 제외한 다른 운영체제(맥 OS, iOS, 안드로이드, 크롬 OS, 리눅스 등)에서는 굴림이라는 레거시 폰트가 존재하지 않기 때문에 문제가 없다. 네이버에서 만든 나눔고딕, 애플 산돌 고딕 네오, 구글의 노토 산스, 심지어 윈도우즈 폰에서도 마이크로소프트 네오 고딕이 기본 글꼴로 사용되고, 웹 제작자가 설사 굴림을 썼다고 하더라도 굴림이 OS에 없기 때문에 브라우저에서 정한 기본 산스세리프가 대체 글꼴로 나와서 정말 보기 싫은(ugly) 상황은 연출되지 않는다. 오직 데스크톱 윈도우즈에서만 과거 시대의 유물, 굴림을 봐야 하는 불쾌한 상황이 생긴다.

가장 좋은 것은 웹 페이지를 만드는 사람들이 제발 굴림과 돋움을 기본 글꼴로 안 썼으면 좋겠다. 그래서 과거에는 윈도우즈 시스템에서 굴림/돋움을 아예 물리적으로 다른 글꼴로 바꿔버리거나, 레지스크리를 바꾸어서 굴림/돋움이라는 글꼴명이 다른 글꼴을 가리키도록 하는 방법도 시도해보았다. 상당히 만족스럽다. 그런데, 웹이 아닌 다른 응용 프로그램(application)에서 일부러 굴림을 쓴 경우를 구별하고 싶었다. 그래서 좀 덜 과격한 방법으로 웹에서만, 원하는 경우에, 굴림과 돋움을 안 보기로 했다.

주요 브라우저들이 예전에는 장애인들의 웹 접근성을 높이기 위한 한 방편으로 사용자 스타일 시트(user style sheet)를 불러와서 웹 페이지를 사용자가 원하는 방식으로 볼 수 있도록 편의를 제공했었다. 그런데 굳이 사용자가 스타일시트를 정의해서 불러 쓰는 경우가 많지 않았는지, 언제부턴가 인터넷 익스플로러를 제외하고는 그 기능이 다 사라졌다. 그래서 부득이하게 브라우저 확장 기능을 써서 굴림 글꼴을 내 눈 앞에서 사라지게 했다. 우선 굴림과 돋움이 웹 사이트에 출현하면 그것을 다른 글꼴로 대체하는 CSS (Cascading Style Sheet)를 만들었다. 굴림의 대체 글꼴은 굴림과 모양이 상당히 유사한 나눔고딕을, 돋움의 대체 글꼴은 그냥 윈도우즈에서 기본 제공하는 맑은 고딕을 사용하였다.

@font-face {font-family: Gulim; src: local("NanumGothic");} @font-face {font-family: Dotum; src: local("Malgun Gothic");} @font-face {font-family: 굴림; src: local("NanumGothic");} @font-face {font-family: 돋움; src: local("Malgun Gothic");}

cs

 

이제 브라우저별로 확장 기능을 사용해 위의 스타일을 모든 웹 사이트에 적용하였다. 사용자가 임의로 정의한 스타일시트나 스크립트를 사용하여 웹 페이지를 나만의 방식으로 보여주는 확장 기능은 상당히 많다. 대표적인 것이 초기에 센세이션을 일으켰던 파이어폭스에는 그리스몽키 (Greasemonkey)가 있고, 스타일만 바꿔주는 크롬용 스타일봇(Stylebot), 이와 유사한 스타일리시(Stylish)도 있다. 오페라, 크롬, 파이어폭스에 모두 있는 확장 기능으로는 커스텀 스타일 스크립트(Custom Style Script) (파이어폭스용, 오페라용, 크롬용)가 있다. 마이크로소프트 엣지 브라우저에도 확장 기능이 윈도우즈 스토어를 통해서 제공되는데 아직 사용자 정의 스타일을 쓸 수 있는 확장 기능은 없다. 인터넷 익스플로러는 자체적으로 사용자 정의 스타일을 불러다 쓸 수 있는데, 위와 같은 내용을 CSS로 만들어 로딩하면 이상하게 인터넷 익스플로러가 죽어버린다. 결국 오페라에는 커스텀 스타일 스크립트를, 크롬에는 스타일봇을, 파이어폭스에는 스타일리시를 이용해서 위와 같은 글꼴 대체 스타일을 적용했다. 보기 싫었던 굴림과 돋움을 웹 사이트에서 몰아내고 나니 웹 서핑이 한결 쾌적해졌다.

돋움 글꼴이 여러 곳에 쓰였다. zdnet.co.kr 기사

돋움 글꼴이 맑은 고딕으로 대체되었다.

Read more "굴림, 돋움 제거 작전"

Firefox and Internet Explorer user style sheet for better keyboardnavigation

When you tab through a web page with your keyboard, a visual focus will move through all the links and form controls in the page. Modern browsers such as Opera, Safari, and Google Chrome and most of mobile browsers provide a visually distinctive focus. This clear focus dramatically enhances usability and accessibility of keyboard users (eg. people of visually impaired or low vision) as well as general convenience for majority of users. However two widely used browsers, Internet Explorer and Firefox stick to the traditional, not very conspicuous visual focus of gray dotted outline. This faint outline focus often makes me get lost when I use my keyboard for the within-page navigation. Compare the following default visual focus of each browser (for Windows):

Prominent visual focus of three modern browsers

Apple Safari	Google Chrome	Opera

Marginally distinguishable visual focus of two major browsers

Firefox	Internet Explorer 8

To get a clearer visual cue of where I am in a web page, I set the following user style sheet for Firefox and Internet Explorer.

:active, :focus {
	outline-width: 2px !important; 
	/* outline (unlike border) property does not take the space */
	outline-style: solid !important;
	-moz-outline-radius: 4px;
	/* this affects Firefox only, it makes the outline rounded  */
}

Refer to the articles below to get information about how to set your user style sheet in the two browsers:

• How to write a user style sheet for Firefox (Modify userContent.css.)
• Where is my Mozilla profile located? (Find where the userContent.css is located.)
• Write a user style sheet for Internet Explorer for Windows

Once you configured your user style sheet successfully, all the objects (including text links, image links, radio buttons, text input fields, image type buttons, etc) will be clearly outlined and stand out! Now enjoy your keyboard navigation and never get lost within a page!

Improved visual focus of two major browsers

Firefox	Internet Explorer 8

Be careful that the Internet Explorer version 6 and 7 do not support CSS outline property.

Read more "Firefox and Internet Explorer user style sheet for better keyboardnavigation"

Two things to be fixed in next update of Internet Explorer 8

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.

Read more "Two things to be fixed in next update of Internet Explorer 8"

웹 접근성 품질 마크 심사 끝

지난 몇 달동안 나를 최대한 괴롭혔던 것이라면, 단연코, 웹 접근성 품질 마크 심사였다. 웹 접근성 품질 마크는 이번이 4회째인데 대상 웹 사이트가 갈수록 늘어나 열 댓 명의 심사위원 한 사람에게 배정된 양이 만만치 않았다. 한 사이트에 대해 세 사람이 심사하고, 세 사람의 의견을 모아서 마지막으로 다시 한 사람이 보고서를 정리한다. 주말이나 저녁에 쉬는 시간이면 품질 마크 귀신이 나를 따라다니며 "네가 지금 이러고 있을 시간이 있어?"라며 괴롭혔다. 평가 기간동안 개선이 일어나면 다시 심사를 반복해야 했는데, 접근성이 개선된 것은 참 반가운 일이지만, 평가하는 사람들에겐 노동이 더 늘어나므로 반가운 소식만은 아니었다. 스물 여섯 개의 지표를 수십 개의 페이지에서 확인하는 일은 상당한 중노동이다. 그런 수십 아니 수백 수천 개의 페이지를 만든 사람의 노고에 비하면 별 것 아니겠지만.

웹 접근성은 모로 가거나 홀로 가도 대충, 빨리 앞으로만 가면 된다는 기술 지상주의나 성장 제일주의에 대해, "올바른 방향으로, 합의된 규칙을 지키며, 다같이 함께 가지 않으면 진보하지 않는 것"이라고 딴지를 거는 제동 장치이며, 기술과 디자인의 바른 길을 제시해주는 항법 장치이다. 다행히 이런 제도 때문인지 거의 바닥에서 출발한 한국 공공 기관의 웹 접근성은 눈에 띄게 좋아지고 있다. 대부분의 일반 기업들의 웹 사이트는 아직도 세계 최하위 수준이지만.

나중에 시간이 나면, 여러 사이트에서 공통적으로 자주 나오는 문제점들을 모아서 사례집으로 만들어도 좋을 것 같다. 키보드 보안 프로그램을 강제로 설치하도록 우기는 사이트들(개인적으로 키보드 보안 프로그램이야말로 과장된 보안 위협에 기반한 사기성 프로그램의 극치라고 생각한다.), 아직도 기본 중의 기본인 URI를 감추거나 페이지 제목을 제대로 안 쓰는 사이트, 뻔한 HTML을 놔두고 정말로 희한한 자바스크립트를 개발하여 적용한 사례 등등... 아무튼 오늘로 나에게 주어진 모든 사이트에 대한 보고서까지 다 마쳤다. 제발 다시 재심이 들어오지 않았으면 좋겠다. 연말을 편하게 보낼 수 있게...

Read more "웹 접근성 품질 마크 심사 끝"

극단적인 환경의 웹 접근성: 크로스브라우징을 넘어서

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

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

박스닷넷에서 파워포인트 파일 원본 내려받기 또는 웹에서 보기 | 슬라이드셰어를 통해 웹에서 보기

Read more "극단적인 환경의 웹 접근성: 크로스브라우징을 넘어서"

주 사용 브라우저를 바꿨습니다.

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

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

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

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

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

Read more "주 사용 브라우저를 바꿨습니다."

모든 페이지에 고유한 제목을 넣었습니다.

제가 얼마 전에 블로그에 제목의 중요성에 대한 글을 썼습니다만, 구글 웹마스터 도구로 진단을 하다 보니, 정작 제 자신의 블로그에는 제목이 중복되는 페이지가 꽤 있었습니다!! 특정 카테고리(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" ...)이 모두 똑같게 나오는 문제는 여전히 남아있습니다.

Read more "모든 페이지에 고유한 제목을 넣었습니다."

제목의 중요성

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

좋은 제목의 조건

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

대표성:

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

고유성(uniqueness):

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

간결성:

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

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

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

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

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

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

한 사이트 안에서 모든 웹 페이지들이 고유한 제목을 가지고 있어야 한다고 했습니다. HTML에서는 <title> 요소 안에 제목을 표시합니다. 예를 들면 제 블로그 안에서 https://www.gregshin.pe.kr/2008/03-post.html라는 페이지는 <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 문서가 아니더라도, 제목이 잘 붙어있어서, 접근하기 쉽고, 데이터로서 가치가 높은 양질의 문서들이 많으면 좋겠습니다.

Read more "제목의 중요성"

비 라틴 계열 문자를 한꺼번에 엔티티 문자로 바꾸기

우리 회사에서는 오라클 사의 아이러닝(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

Read more "비 라틴 계열 문자를 한꺼번에 엔티티 문자로 바꾸기"

페이지 내 링크와 브라우저 버그

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

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

바로 가기 링크 시험용 예제 페이지 (다운로드 받은 후 로컬 PC에서 시험하세요.)

Read more "페이지 내 링크와 브라우저 버그"

A SMIL practice

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.

Read more "A SMIL practice"

우리바탕, 우리돋움 출시에 대한 개인 의견

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

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

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

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

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

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

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

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

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

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

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

Read more "우리바탕, 우리돋움 출시에 대한 개인 의견"

웹 표준 교과서 나왔다는데

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

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

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

Read more "웹 표준 교과서 나왔다는데"

웹 접근성 향상 캠페인

인터넷이 며칠 째 먹통이 되어 이런 캠페인을 하고 있다는 사실을 까맣게 몰랐군요. 한국 정보 문화 진흥원에서 웹 접근성 향상 캠페인을 하고 있습니다. 웹 접근성, 웹 표준, 상호 운용성 등에 대해 사람들이 말을 많이 하지만, 아직도 대다수의 사람들에게는 다른 나라 얘기이거나 도대체 무슨 이야기인지 모르는 것이 현실입니다. 그런 면에서 이런 캠페인은 보통 사람들에게 쉽고 평범하게 웹 접근성이 왜 중요하고 꼭 지켜야만 하는 것인지를 알려주는 중요한 역할을 하는 것 같습니다. 쉽고 빠르게 접근성에 대해 설명해주는 동영상, 강추입니다.

접근성에 대해 잘 아는 사람들조차도 장애인의 접근성에 대해 직접적으로 이야기 꺼내는 것을 두려워합니다. 대신에 좀 더 근사하고, 저항이 없는 국제 표준, 기술 표준, 상호 운용성, 구조와 표현의 분리, 모바일 웹, 최신 기술 등의 섹시한 단어로 포장을 해서 접근성을 간접적으로 강조하곤 합니다. 저도 그래왔었구요. 그만큼 장애인은 소수이고, 돈도 안 되고, 장애인의 문제를 가지고 제품 개발자들에게 설득하기가 쉽지 않기 때문이겠지요. 그러나 아무리 소수라고 해도 장애인들에게 "세상과 통하는" 매우 중요한 문인 웹을 닫아놓고 IT 선진국이라고 외치는 것은 자기 기만일 수도 있습니다. 사실 장애인이나 노인은 이제 소수도 아니지요.

얼마 전에 아버지에게 웹에 있는 씽크프리 오피스를 이용해서 주소록을 정리하는 것을 알려드렸던 경험이 있습니다. 접근성의 문제는 거창한 이론에서 나오지 않더군요. 접근성 지침에 있는 항목들을 다 지킨다고 되는 것이 아니라는 것을 알았습니다. 컴맹이 봐도, 누가 봐도, 장애인이 봐도 직관적으로 이해하고 교육받지 않아도 쉽게 쓸 수 있게 하는 것, 이것이 접근성입니다. 컴퓨터를 잘 모르는 아버지에게 씽크프리 오피스는 너무 복잡했고, 새롭게 익혀야 할 개념도 너무 많았습니다. 그러니 아직 갈 길이 먼 것 같습니다. 제 웹 사이트도 아직 먼 것 같습니다.

Read more "웹 접근성 향상 캠페인"

오라클이 접근성 때문에 고소당했다는 소식을 듣고

현준호님 블로그에서 글로벌 기업인 오라클이 접근성 위배로 고소당했다는 이야기를 읽었습니다. 기사 원본이 어디 나와있을까 한참 찾다보니 현준호님 글 맨 끝에 Oracle sued for failing blind users라는 기사가 연결되어 있었습니다.

우리 회사도 오라클에서 만든 교육 관리 시스템(Learning Management System, LMS)을 비롯해 인적 자원 관리를 온통 오라클로 하고 있기 때문에 관심이 갔습니다. 처음에 오라클 소프트웨어(데이터베이스가 아닌 주로 ERP 류의 소프트웨어)를 접해본 느낌은 아주 복잡하고 난해하다는 것이었습니다. 그리고 정말 사용자 인터페이스에는 전혀 신경을 쓰지 않은 것 아닌가라고 생각하게 됩니다. 그런데 기술적인 배경이 강한 사람들은 오라클을 쓰면서 점점 감탄하게 됩니다. 그 복잡한 세상을 이렇게 일관성있게 관리할 수 있도록 구축해놓은 것에 놀라게 됩니다. 그러나 여전히, 도대체 이걸 누가 쓰라고 만들어 놓은 것인가 다시 묻게 합니다. 일반적인 우리 나라의 학습 관리 시스템이라면 현황 자료를 뽑을 때에 그냥 버튼 하나 누르면 간편하게 엑셀로 다운받아 줍니다. 그런데 오라클에서는 그런 현황 자료 하나 뽑을려면, 일일이 SQL 만들어서 돌리고, 다시 템플릿을 XML이나 XSLT로 만들어서 리포트를 만들어주어야 합니다. 그것도 정말 불편하고 느린 인터페이스로 되어 있지요. 다시 말해, 사용자가 SQL, XML 따위를 모르면 아무 것도 못하게 되어 있습니다. 설사 SQL을 안다고 해도 그 거대한 시스템의 데이터베이스 구조를 기술적으로 파악하고, 또 운영을 해봐야 이게 실제 어떻게 연관된 것인지 자세히 알 수 있기 때문에 현업에서 SQL 만들어서 실제로 써먹으려면 하세월이 걸립니다. 그래도 저는 그런 오라클의 방법이 그냥 단순하게 엑셀 파일에 서식까지 잔뜩 입혀서 다운로드받게 해주는 국산 프로그램들보다 어떤 면에서 낫다고 생각했습니다. 왜냐면 엑셀 형식은 적어도 보편적인 형식이 아닌 특정한 업체의(proprietary) 형식이기 때문입니다.

또 우리 나라 업체의 제품 같으면 웹에서 트리 구조를 표현하기 위해 이상한 액티브 엑스(Active X) 깔아서 클라이언트에서 트리를 펼쳤다 닫았다 할 수 있게 만들었을 것입니다. 실제 그런 경우가 매우 많지요. 모두가 윈도우즈에 인터넷 익스플로러만 쓰고, 자기 컴퓨터에 그런 프로그램 수십 수백 개 깔리는 것 신경 안쓰는 사람들은 그게 훨씬 편한 방법일 지도 모릅니다. 그런데 오라클은 정말 느리고 불편하게 서버에서 트리를 완전히 다시 갱신하는 방법을 쓰고 있었습니다. 사실 요즘 같으면 아마 에이잭스(AJAX)를 써서 훨씬 빠르게 만들 수도 있었겠지요. 그런데 그 불편한 서버 갱신 방식을 채택한 것도 어찌 보면 이유가 있었습니다. 트리를 펼치는 것과 줄이는 것은 물론이고, 트리의 특정 노드로 점프하는 것 등이 모두 키보드로 작동 가능하고, 시각 장애인이 쓸 수 있게 해놓았더군요.

국내 학습 관리 시스템 같으면, 특정 과정을 개설할 때 강사를 지정하는 것 정도는 아무나 쉽게 할 수 있습니다만 오라클 시스템에서 그것은 무지무지하게 어려운 일에 속합니다. 시스템을 아무리 뒤져봐도 강사(instructor)라는 말이 나오지 않습니다. 그것을 한 번 하려면 오라클 권한 부여 모형(Oracle permission model)과 역할(role), 권한(privilege)을 이해해야 하고, 또 사이트(site), 자원(resource), 자원 유형(resource type)이라는 개념과 자원 예약(booking), 확인(confirmation) 개념에 대해서도 알아야 합니다. 한 마디로 한 방에 할 수 있는 것은 아무것도 없습니다. 강사 지정한다고 해서 강사 권한이 바로 부여되는 것도 아니구요.

아무튼 오라클 소프트웨어를 쓰면서 한편으로는 방대하고 어마어마한 구조에 감탄하게 되고, 한편으로는 전혀 무신경한 사용자 인터페이스에 불만을 갖게 됩니다. 오라클의 웹 소프트웨어의 사용성은 제가 써본 바로는 별로입니다. 엔지니어들에게는 많은 자유를 줄 수 있지만 기술과는 거리가 먼 업무 전문가들 입장에서는 꽝이라고 할 수도 있지요. 그런데 웹 인터페이스는 그나마 낫습니다. 재활법 508조가 있기 때문이겠지요. 적어도 형식적으로는 대체 텍스트, 키보드 접근성 등을 대부분 지켜서 나옵니다. 그렇다고 웹 표준을 지키지는 않았습니다. 웹에 있어서는 아주 구닥다리 코드들을 사용하고 있지요. 그런데 시각적으로 보이지 않는 사람이 과연 이렇게 복잡한 시스템을 머릿속에 담아서 직렬적으로 처리할 수 있을까를 생각해보니, 상당히 무리이겠다는 느낌이 들었습니다. 그래도 우리 나라에서 만든 웹처럼 다른 브라우저에서는 아예 화면이 안 뜨고, 화면 레이아웃이 깨지고, 작동도 안 하고 그런 일은 없습니다. 그런데 이번에 고소를 당한 소프트웨어는 아마 자바 애플릿 기반의 소프트웨어쪽이 대상이 된 것 같습니다. 오라클이 만든 자바 애플리케이션을 써보면 정말 가관입니다. 처음 보면 도대체 어디에서부터 무엇을 하라는 것인지 감이 오질 않습니다. 그리고 자바 애플리케이션들은 접근성을 거의 고려하지 않은 것 같습니다. 사실 자바의 접근성이 아주 나쁜 것은 아닙니다. 100% 자바로만 만든 넷지(NETg)의 이러닝(e-learning) 콘텐츠나 스킬소프트의 온라인 콘텐츠는 접근성이 아주 좋습니다. 우리 나라 이러닝 콘텐츠들의 경우는 기본적인 웹 표준과 웹 접근성, 상호 운용성, 최소한의 사용성과는 상당히 거리가 멀고 오로지 서로 다른 학습 시스템간의 상호 운용성을 보장해준다는 스콤(SCORM)에만 신경을 쓰고 있지요. 기본적인 데이터로서 가치가 낮고 재활용이 거의 불가능한 콘텐츠를 아무리 스콤 표준에 맞추어봤자 무슨 소용이 있는지 모르겠습니다만.

오라클은 아주 거대한 회사입니다. 그래서 제 주관적인 느낌으로는 움직임도 상당히 느리더군요. 그리고 워낙 제품군이 많고 방대하기 때문에 고액 연봉을 받는 오라클의 전문 컨설턴트들도 자기가 전문성을 가진 특정 분야 제품이 아니면 뭐가 어떻게 돌아가는지 자세히 모르는 것 같습니다. 재활법 508조 때문에 오라클은 형식적으로만 접근성을 지켜왔던 것이 아닌가 추측됩니다. 그나마 자바 기반의 애플리케이션에는 신경을 덜 써왔던 것이고. 이제 그런 형식적인 접근성을 지켰다고 해도, 실제 장애인 사용자의 "원활한" 사용이 "사실상" 불가능하다면 아무 소용이 없다는 것을 이번 사건이 드러내줄 것이라고 생각합니다. 이번 사건에서 장애인 사용자가 인사 정보를 열람하기 위해 항상 비장애인 사용자의 도움을 받아야 해서, 자신의 개인 정보를 남에게 다 노출할 수 밖에 없는 심각한 문제를 참아 왔다고 합니다. 그래서 접근성을 지키는 것은 어찌 보면 매우 어려운 일입니다. 겉으로 드러나는 (그리고 단순해보이는) 접근성 규칙들 이면에 숨어있는 사용자 편의성(usability)이라는 측면이 너무 복잡하게 얽혀 있기 때문입니다. 아무튼 사용자 편의성, 접근성 문제에 상대적으로 둔감함을 보여왔던 오라클에 어떤 변화가 생기는 계기가 되었으면 좋겠습니다.

Read more "오라클이 접근성 때문에 고소당했다는 소식을 듣고"

7th KWAG Workshop

I attended the 7th KWAG workshop held at one of NHN's training centers. KWAG is a voluntarily gathered non-profit, and non-government group of people who share the interest in enhancing Web accessibility in Korea, and this workshop is a kind-of unconference which has no fixed form but the content of the meeting is freely created by voluntary individuals.

KWAG launched several small groups, that is TF's at this 7th workshop. I was involved in Web Accessibility Evaluation TF and newly participated in Caption and Audio Description TF which consists of only three members (Gyu-yeon Hwang, Jiae Mun and me) now. We had a short discussion regarding the plan for this TF and picked out three initiating topics:

1. Accessibility of multimedia players (whether they are embedded in a Web or run as an independent application)


2. Field research for captioning applications


3. Effective caption(or subtitle) design

Have a quick look at the following photos to get how the workshop worked:

• some pictures taken by Hooney, one of the leading members of KWAG. The photos are grouped by the TF's.


• photos taken by corean


• All Flickr photos tagged with kwag

Read more "7th KWAG Workshop"

아웃룩 2007이 인터넷 익스플로러를 버리다니...

오늘 좀 쇼킹한 뉴스를 접하게 되었다. 새로 출시되는 마이크로소프트 아웃룩(Microsoft Outlook) 2007 버전에서 인터넷 익스플로러(Internet Explorer)를 HTML 렌더링 엔진으로 쓰지 않고, 대신 워드(Word) 2007을 사용한다고 한다. 몰리(Molly)에 따르면, HTML 형식의 이메일을 작성할 때와 읽을 때 같은 엔진을 사용함으로써 사용자들에게 일관성을 주려는 목적으로 그런 짓을 한 것 같다. 당연히 예상되었겠지만 워드 2007의 렌더링 엔진은 매우 조악하다고 한다. 특히나 CSS의 float를 지원하지 않는다고 하니, CSS 포지셔닝 기능을 이용해 HTML 형식의 이메일을 보내던 많은 기업 이메일 발송자들에게는 치명적인 문제가 생길 것 같다. 사이트 포인트에서도 이 문제에 대해 시끄럽고, 캠페인 모니터 블로그에서는 마이크로소프트가 이메일 디자인을 5년은 후퇴시켰다고 비난하고 있다.

사실 불필요하게 HTML 이메일을 남용하는 것은 좋은 생각이 아니다. 특히나 우리 나라 기업들이 보내는 수많은 엽기적인 HTML 이메일은 아무런 대체 수단 없이 통째로 하나의 이미지로 되어 있다. 오페라(Opera)에 내장된 이메일 클라이언트에서는 그래서 HTML 이메일 작성 자체를 지원하지 않는다. 물론 읽는 것은 지원하지만. 그러나 걱정이다. 이메일 클라이언트로서 아웃룩의 시장 점유율이 세계적으로 70%가 넘는다고 하는데, (아마 우리 나라에서는 90%가 훨씬 넘지 않을까) 그러면 이메일을 보내는 기업으로서는 수신자의 프로그램을 고려하지 않을 수 없다. 그래서 CSS 포지셔닝을 사용하지 않고 무조건 테이블 기반의 디자인으로 돌아가거나 아니면 많은 생각 없는 디자이너들이 선호하는 통짜의 그래픽 이미지로 메일을 보내는 사례가 늘어나지 않을까 싶어서이다. 개인적으로야 뭐 HTML 메일을 보낼 일은 거의 없지만, HTML 메일로만 캠페인을 하는 많은 사업자들은 아마 상당히 난감할 것 같다. 물론 약삭빠른 마이크로소프트에서는 자기들 렌더링 엔진에 맞도록 작성자가 HTML을 썼는지 검사하는 프로그램을 무슨 정말 표준 검사 도구인 것처럼 내놓고 있다.

안 그래도 우리 회사에서 아웃룩 쓰는 사람들이 자꾸 RTF(Rich Text Format, 워드에서 사용하는 포맷)로 메일을 보내는 통에 첨부 파일이 winmail.dat로 읽지 못하게 와서 매번 다시 보내달라고 하는 법석을 떨고 있다. 이게 독점의 폐해가 아닌가 싶다. 아웃룩이라는 고유 명사는 알지만 메일 클라이언트라는 단어는 모르고, 인터넷 익스플로러라는 단어는 알지만 브라우저라는 단어를 모르는 사람들로 꽉찬 곳에서 독점 소프트웨어의 의사 결정은 시장 전체와 다른 제품 사용자, 기존에 합의된 표준 등 여러 곳에 매우 큰 파급 효과를 미친다. 무서운 것은 그런 독점 사업자가 독점 제품을 통해 자신들의 이상한 방식을 모두에게 강요함으로써 기술 발전을 후퇴시키거나 정체시킬 수도 있다는 것이다.

Read more "아웃룩 2007이 인터넷 익스플로러를 버리다니..."

한국 웹 접근성 그룹 웹 사이트

드디어 Hooney님이 일을 저질렀군요. 한국 웹 접근성 그룹 웹 사이트를 여셨습니다. 웹 접근성과 웹 표준을 잘 지키고, 디자인도 멋지고, 위키 기반으로 되어있어서 사람들이 참여하기도 편하고, 내용도 여러 사람들이 참여해서 계속 보강해나간다면 아주 멋진 사이트가 될 것 같습니다. 처음엔 그냥 재미로 시작하는 모임이었는데 이제 책임감이 어느 정도 따르는, 그리고 우리 나라에서 웹 접근성 관련해서 유일한 스터디, 활동 모임이 되었군요. Hooney님! 정말 멋져요.

Read more "한국 웹 접근성 그룹 웹 사이트"

이해의 용이성: 웹 접근성 준수 실무 세미나 발표 자료

오늘 (2006년 11월 29일) 웹 접근성 준수 실무 세미나에서 한국형 웹 콘텐츠 접근성 지침 중 세 번째 원칙인 이해의 용이성 부분에 대해 발표하였습니다. 원칙에 대한 이론적인 설명보다는 짧은 시간에 실제 일어날 법한 사례를 다루려고 욕심을 부리다 보니 이도저도 아니게 약간 어중간하게 된 것 같습니다. 아무튼 파워포인트 발표 자료를 공유합니다. PDF로 변환한 파일은 나중에 올리겠습니다.

발표 자료: Understandable Content and Controls

Read more "이해의 용이성: 웹 접근성 준수 실무 세미나 발표 자료"