제목의 중요성

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

좋은 제목의 조건

이 세상 모든 것에는 제목이 있습니다. 사람에게는 이름이 있고, 컴퓨터의 파일에도 이름이 있고, 웹 페이지에도 이름이 있어야 합니다. 그 이름은 반드시 그 페이지의 내용을 대표할 수 있게 적절하게 지어야 합니다. 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 문서가 아니더라도, 제목이 잘 붙어있어서, 접근하기 쉽고, 데이터로서 가치가 높은 양질의 문서들이 많으면 좋겠습니다.

Share this

7 thoughts on “제목의 중요성”

  1. 언제나 느끼는 것이지만, 권고안이나 기술문서 한번 안 읽어보고 사이트를 개발하는 사람이 너무 많은것 같아요.

    ㅎㅎ 제목 관련 태그가 너무 정리가 잘되어있는데요~? 잘배우겠습니다~~

  2. 좋은 말씀과 함께 실제적으로 사용하게 될 코드의 좋은 설명까지 달아주셔서 많은 사람에게 도움이 될 것 같습니다~! ㅎㅎ

    이거 스탠다드 메거진에 투고하는건 어떨까요~? ㅎㅎ

  3. ^^ 오랜만에 방문했습니다.

    글도 오랜만이네요…

    제목의 중요성에 대해 다시금 정리해주셔서 정말 감사합니다.

    저역시 잘 배우고 갑니다~ ^^

    참… 안그래도 아침에 지하철에서 html 4.01 명세를 프린트해서 꼼꼼히 보면서 왔는데, 궁금한게 있었습니다.

    <blockquote cite="http://www.w3.org/TR/html401/interact/forms.html#h-17.9">For those controls that have implicit labels, user agents should use the value of the value attribute as the label string.

    여기서 implicit labels 이라는게 구체적으로 어떤건지 궁금합니다. 뒤에 있는 예제에서 label을 쓰지 않고 value로 처리한게 있는데요.

    <code>

    <INPUT type="radio" name="sex" value="Male"> Male

    <INPUT type="radio" name="sex" value="Female"> Female

    </code>

    이 예에서는 label을 쓰지 않고 value만으로 implicit labels 이 된다는 말인가요?

    시간되시면 답변 부탁드립니다~ ^^

  4. deute님, 요한님, 복잡한 스크립트는 제가 잘 모르니까 그냥 HTML 기본을 한 번 정리해봤습니다. ^^성민장군님, 제가 이해한 게 맞는지 모르겠습니다.암묵적 레이블링(implicit labeling)이라는 말은 명확하게 레이블과 폼이 짝지어지지 않아도 "정황상" 이게 레이블일 것이다라고 사람이 추측하거나, 웹 표시 장치가 추측할 수 있도록 한다는 것인데, 몇 가지 단계가 있는 것 같습니다.

    <dl><dt>1. 가장 낮은 단계: 레이블이 있을 만한 위치에 텍스트를 놓는 방법</dt><dd>예를 들면, <code>전화번호: <input type="text" name="phone" /></code>와 같이 폼 바로 앞이라는 위치는 정황상 레이블일 가능성이 많다는 것이죠. 그러나 가장 불명확하고 불완전한 방법이겠죠.</dd><dt>2. 낮은 단계: value 속성값을 그대로 쓰는 것</dt><dd>성민장군님이 보여주신 예가 이 경우겠네요. <button>의 경우에는 버튼 자체에 value가 있어서 그것이 시각적으로도 보이고, 기계도 그것을 레이블이라고 처리하니까 문제가 없습니다. 그러나 라디오 버튼의 경우에는 value값을 데이터로 처리하지만, 시각적으로 레이블은 따로 보여주어야 합니다. 그래서 그냥 텍스트로 라디오 버튼 옆에다 value에 있는 값을 그대로 다시 한 번 써주면 암묵적으로 레이블이라고 볼 수 있다는 것이죠.</dd>

    <dt>3. 중간 단계: <label>을 쓰되, 명시적으로 폼과 짝지어놓지 않은 것</dt><dd>예를 들면 <code><label>First Name<input type="text" name="firstname"/></label></code>에서와 같이 레이블이 무슨 폼과 짝지어지는지 명시적으로 for나 id 속성값을 주지 않고, 대신에 레이블이 폼을 완전히 감싸서, 바깥에 있는 텍스트가 안에 있는 폼에 대한 레이블이라고 암묵적으로 표시하는 방법입니다. </dd><dt>4. 명시적 레이블링(explicit labeling): for와 id를 써서 레이블과 폼을 명확하게 짝지은 것</dt><dd>예를 들면, <code><label for="firstname">First Name</label><input type="text" name="firstname" id="firstname"/></code>에서와 같이 레이블의 for와 폼의 id를 짝지어줌으로써 명확하게 해당 폼의 레이블이 무엇인지 알 수 있게 하는 방법입니다. 권장되는 방법이지요. 물론 라디오 버튼의 경우, id는 모두 따로 주되, name은 여러 개의 폼이 공유를 해야 한 그룹 내에서 배타적인(exclusive) 선택이 되겠지요. 성민장군님의 예를 명시적인 레이블링으로 다시 표현하면, <code><input type="radio" name="sex" id="male" value="Male"/><label for="male">Male</label><input type="radio" name="sex" id="female" value="Female"/><label for="female">Female</label></code>정도가 되겠네요.</dd></dl>

  5. 네.. 제가 궁금했던게 2번째 항목입니다.

    작업을 하다보면 통상 추천하는 방식인 4번째 방법을 사용하게 되는데(1번, 3번 항목은 쓰지 않습니다.), 마크업의 양이 늘어나서 가끔 더 좋은 방법이 없을까 생각을 한적이 있습니다.

    그러다가 'implicit labels'에 대한 명세서 내용을 보고, 만약 value 값으로 레이블링 하는 것이 문제가 없다면 이 방법도 괜찮은거 아닌가 하는 생각이 들었습니다.

    굳이 label을 쓰지 않더라도 말이죠.(사용성은 떨어질지 몰라도)

    물론 label을 써야한다는건 동의합니다. ^^

    value 값으로 처리되는 것에 대한 접근성의 문제를 다루는 글이 있다면 혹시 주소라도 알 수 없을까요? (저도 열심히 찾아보겠습니다.)

    그게 왜 낮은 단계인지, label을 대체할 수 없다는 그런 글이요.. ^^

    무식하니 언제나 공부공부공부!!! ㅋㅋ

    답변 정말 감사합니다.

  6. 제가 잠깐 생각해 본바로는…

    문서를 읽는 방법에서(스크린리더가 되었든, 브라우저가 되었든)

    input의 value를 암묵적 label로 처리하기에는 label 보다는 단계가 당연히 낮을 수 밖에 없을것 같은데요. value를 label의 뜻과 동일하게 사용해야한다는 법이 있는것도아니구요.

    label이 연결된 경우 label 을 읽어 주는 것이 최상의 접근이며 그렇지 않은경우 value를 암묵적 label로 읽어 주는 두번째 단계라고 생각 할 수 있지 않을까 해요(단지 제생각입니다.;; )

Leave a Reply

Your email address will not be published. Required fields are marked *