Category Archives: Universal Design

도메인을 잃어버렸다.

지금까지 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의 현재 소유 기간이 만료되면 다시 옛날 주소로 고칠 생각인데, 그 때엔 또 얼마나 많은 작업을 해주어야 하는지…

굴림, 돋움 제거 작전

아직도 많은 곳에서 굴림, 돋움 글꼴이 쓰이고 있다. 윈도우즈 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 기사
돋움 글꼴이 여러 곳에 쓰였다. zdnet.co.kr 기사
돋움 글꼴이 맑은 고딕으로 대체되었다.
돋움 글꼴이 맑은 고딕으로 대체되었다.

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.

Frame navigation sample page: After activating one link by pressing Enter key in the first frame, the focus should move to the target frame (path b) not within the current frame (path a)

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으로 페이지 내 링크를 시험해보았습니다만 파이어폭스를 제외한 모든 브라우저에서 문제가 발견되었습니다. 이런 브라우저의 특성을 제작자가 다 알아서 꼼수를 써서 해결할 수는 없기 때문에 다음 버전 제품에서는 빨리 이 문제가 개선되면 좋겠습니다.

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

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.