웹페이지를 제작할 때 타이틀은 매우 중요하다. 소설을 쓸 때에도 제목을 잘 지어야 하는 것 처럼.
나쁜 예부터 보자.
Bad Case 1. “무제(無題)”
요즘 청소년들도 혼자만의 감상에 못이겨 시를 쓰는지 모르겠는데, 아무튼 한때 문학소년소녀들의 자작시집에는 “무제”가 왜이리 많았는지. 머리통이 좀 굵어지고 난 후에 보기라도 할라치면 어쩌자고 저런 이름을 붙였나 낯뜨겁기까지 하다.
웹 페이지 작성시에도 타이틀을 안붙여주는 경우들이 많은데, 매우 안좋은 습관이다.
타이틀은 웹접근성을 위해서도 매우 중요하다. 시각장애인의 경우, 열려있는 문서와 프로그램들을 타이틀을 통해 구별한다. 타이틀이
없다면 구별이 아주 어렵다. 장애인뿐만 아니라 기계친화적인 문서를 필요로 할 때에도 문제가 된다. 예컨데, 검색엔진에라도 잘
걸리게 하고 싶다면 타이틀은 문서간의 구별과 문서내용을 짐작하게 해주는 아주 중요한 도구가 된다. 습관적으로 무성의 하게
타이틀을 비워두는 버릇은 버려야 한다.
Bad Case 2. “XXX 사이트”
아예 타이틀이 없는 것보다 낫긴 하지만, 그래봤자 오십보 백보. 사이트를 통털어서 모든 페이지가 같은 타이틀을 가지고 있는 것은 비워두는 것과 마찬가지이다.
왜 이런 경우가 생기는가 하면 개발자들이나 코더들이 조금 편해보겠다고 모든 페이지에 고정된 HTML 헤더를 인클루드시켜버리기 때문이다.
모든 페이지마다 독립된 타이틀을 가져야 한다. 이유는 앞 항목에서 이야기 한 것과 같은 이유. 모든 페이지의 타이틀이 같다면
색인을 만드는 기계들도 곤욕이고, 시각장애인들의 경우 자신이 보고 있는 페이지가 무엇인지 알기가 어렵다. 더군다나 팝업이나
새창이라도 몇 개 뜨고 나면 어려움은 몇 배 더 가중된다.
Bad Case 3. “~에 오신 것을 환영합니다.”
일단 두번째 케이스의 단점에 준하면서, 거기에다 시각장애인에게 짜증을 더해주는 케이스이다.딴에는 저렇게 공손히 써놓으니 스스로 친절함을 발휘한 것 같아 흐믓할지는 몰라도.
시각장애인들이 사용하는 TTS는 “모든 것”을 읽어준다. 듣기 좋은 소리도 한두번이지, 페이지 이동할 때마다 “~에 오신것을 환영합니다.”를 반복해서 듣는 것은 멀쩡한 사람도 노이로제걸리게 하기 딱 알맞다.
꼭 친절함을 표시하고 싶다면, 대문에나 한번 쓰고 말아라.
그럼 어떻게 작성하는게 올바른 방법일까?
Good Case 1. “문서 제목만 쓰기”
예를 들자면, “올바른 타이틀 작성법”처럼 현재 보이고 있는 문서의 제목만 표시해주는 것도 괜찮다. 중언부언 늘어놓는 것보다는 깔끔하게 문서 제목만 보여주자.
게시판 목록 페이지라면 “자유게시판 목록”이라거나, 게시물 읽기 페이지라면 “게시물 제목”을 써주는 식으로.
Good Case 2. “사이트 이름 – 문서 제목”
그러나 문서 제목만 가지고는 창을 여럿 띄웠을 때는 헷갈릴 수도 있다. 그러므로 사이트 이름을 같이 적어주는 것도 괜찮은 방법이다. “DNZIN – 올바른 타이틀 작성법” 이런 정도.
Good Case 3. “Path”
간단한 블로그라면 위의 두가지 정도로도 충분하겠지만, 덩치가 큰 사이트 내에서 단계가 깊은 페이지일 경우에는 경로를 보여주는 것도 좋다.
예를 들자면,
“DNZIN : 블로그 : WebStandard Archive : 올바른 타이틀 작성법” 이런 식이어도 좋을 테고, 대개 타이틀을 착실하게 써주는 사람들은 이런 형식을 선호하는 편이다.
선형 혹은 트리형태의 사이트맵을 가지고 있는 사이트에서 하위 페이지로의 접근이 단계별로 진행되는 경우에는 크게 상관은 없지만,
만약 그렇지 못한 사이트라면 이러한 타이틀은 사용자에게 혼동을 줄 수도 있다. 스파게티처럼 링크들이 얽혀있는 사이트
네비게이션이라면 주의해서 사용해야 한다. 사용자의 UX는 경험상 뒤로가기 버튼을 눌렀을 때 상위 단계로 이동하길 기대하기 때문에
개구리 뜀뛰듯 링크가 얽혀있을 때 이러한 방법은 그다지 좋다고 할 수는 없다. 물론 시각장애인들에게는 그 어려움이 두배가 된다.
이럴 때에는 <head>안의 <link>의 rel과 rev 속성을 통해 prev, next, index등을
지정해줌으로써 혼동을 막는데 도움이 된다.
게다가 이 형식에는 애초부터 시각장애인을 위한 배려가 2%쯤 부족한 아쉬움이 있다.
Good Case 4. “Reverse Path”
그 아쉬움이 뭐냐 하면…
눈을 통해 2차원적으로 동시에 정보를 수용하는 정상인들과 달리, 시각장애인들은 음성이나 점자를 통해 선형적으로 구성된 정보를
시간순으로만 접할 수 있다. 이런 경우 인간의 집중력은 최초에는 매우 강하지만 시간이 흐르면서 계속 정보가 쏟아져 들어올 경우
집중력이 점차 떨어지게 된다.
학교다닐 때 듣기 평가시간을 기억해보면 이해가 될 것이다. 대개 들려주는 지문의 처음부분은 잘 들리지만 뒤로 갈 수록 제대로
듣지 못한다. 비록 시각장애인들의 청각 집중력이 높고, TTS들도 빠르지 않게 읽어주지 않더라도 title이 길어지면 그것을
듣는데 피로해진다.
타이틀에서 중요한 것은 문서의 제목인데, 정작 중요한 제목은 한참뒤에 나온다면 얼마나 불편하겠는가.
따라서 기존의 경로형식 대신 역경로형식을 쓰는 것도 좋은 방법이다.
“올바른 타이틀 작성법 : WebStandard Archive : 블로그 : DNZIN” 이런 식으로 거꾸로 놓으면 가장 중요한 문서제목이 먼저 들리므로 시각장애인들의 어려움을 조금 덜어줄 수 있다.
그러나 좌에서 우로 읽기가 익숙한 사람들에게 저런 형태는 왠지 불편할 수도 있다. 그런 경우에는 두 방식을 혼용해서
“올바른 타이틀 작성법 : DNZIN : 블로그 : WebStandard Archive” 처럼 써주는 방법도 있겠다.
Bonus.
위의 예에서는 언어를 혼용해서 타이틀을 썼는데 실은 언어를 혼용해서 쓰는 건 그다지 좋은 방법이 아니다. 특히 국내용으로 만드는
사이트라면 되도록이면 한글을 써주자. 국내의 TTS들은 외국어 처리가 그다지 매끄럽지 않기 때문에 외국어가 포함되어있을 경우
틀린 발음으로 읽거나 혹은 아예 철자만 불러주곤 한다. 그러니 되도록이면 다른 나라 언어는 사용을 자제하고, 꼭 써야겠다면
한글발음을 병기해주는 것이 좋다. HTML 제작시에 lang 옵션을 일일이 지켜주지 않을 바에야 말이다. (실상 본인도 일일이
lang옵션 주기는 불가능. 게다가 lang옵션을 준다 한들 TTS가 제대로 읽어준다는 보장도 없고.)
0개의 댓글