23: 내비게이션 메뉴와 여러 페이지들 만들기

소개

이 글에서는 사이트 내비게이션과 메뉴에 대해 다룰 것입니다. 이 글을 읽으면 다양한 타입의 메뉴들과, HTML을 가지고 어떻게 그것들을 만들 수 있는지 알게 될 것입니다. 또한 메뉴의 사용성과 접근성에 대해서도 언급하게 될 것입니다. 메뉴의 스타일에 관해서는 아직 다루지 않을 것이지만, 이후 이 시리즈를 읽는데 필요한 기초적인 것은 알게 될 것입니다. 다운로드할 수 있는 코드 예제들 이 있습니다 – 글에서 이러한 것들을 참조하게 될 것입니다. 글의 내용은 다음과 같습니다.

  • HTML 메뉴를 만들 도구들 – 링크, 앵커, 목록
  • 유연하게 해야 하는 이유
  • 메뉴의 종류
    • 페이지 내부 네비게이션(차례)
    • 사이트 내비게이션
      • 방문자들에게 “현재 여기에 있다” 는 느낌을 주는 것
      • 사용자에게 한번에 몇개의 선택지를 주어야 하는가?
    • 컨텍스트 메뉴
    • 사이트맵
    • 페이지 분할
  • 목록으로 충분치 않을 때 – 이미지맵과 폼
    • 이미지 맵에 핫스팟을 만드는 법
    • 폼을 이용해서 공간을 절약하고 링크가 넘치지 않게 하는 법
  • 메뉴를 넣어야 할 곳, 그리고 메뉴를 건너뛰는 옵션을 제공하는 이유
  • 요약
  • 연습문제

HTML 메뉴를 만들 도구들 – 링크, 앵커, 목록

HTML에는 메뉴나 내비게이션을 만들 때 고려해야 할 몇가지 숙어idiom들이 있는데, 이러한 것들은 모두 a, link 요소와 밀접하게 연관되어 있습니다. 간단히 말하자면:

  • link 요소는 여러 문서들 사이의 연관관계를 나타냅니다. 예를 들어 사용자 에이전트에게 현재 문서는 큰 시리즈의 일부분이며, 다른 문서들이 차례에 나타난다는 점을 알려줄 수 있습니다.
  • 앵커 (a 요소) 는 다른 문서, 혹은 현재 문서의 특정 지점으로 연결할 수 있도록 합니다. 이러한 것은 자동적으로 따라가지는 것은 아니며, 사용자가 직접 활성화(마우스, 키보드, 음성인식 등을 이용해서) 해야 하는 것입니다.

링크에 관한 글 이나 목록에 관한 글 을 아직 읽지 않았다면, 먼저 그것부터 읽기를 바랍니다. 이 글에서는 반복을 피하기 위해, 거기에서 배웠을 지식들을 다시 언급하지는 않습니다.

앵커와 링크는 그 자체로서 메뉴가 되지는 않습니다. 브라우저와 사용자들이 그러한 것을 단순한 링크의 집합이 아니라 내비게이션 메뉴로서 동작한다는 사실을 인식시키기 위해 구조화하고 스타일을 입힐 필요가 있습니다. 페이지들의 순서가 중요하지 않다면, 순서없는 목록으로 만든 메뉴 예제 처럼 순서없는 목록을 사용할 수 있습니다.

ul 요소에 id를 사용한 것을 보십시오. 이렇게 한 이유는 나중에 CSS로 스타일을 적용하고, 자바스크립트로 동작을 지정하기 위한 연결점을 제공하기 위함입니다. id를 사용하면 아주 손쉽게 다른 기술들에서 특정한 HTML 요소를 식별할 수 있게 합니다.

만약 순서가 아주 중요하다면 순서있는 목록을 사용해서 내비게이션 메뉴를 만들어야 할 수도 있습니다. 예를 들어 여러개의 문서들로 구성된 온라인 교재를 집필 중이라면, 순서있는 목록을 사용한 예제 와 같이 할 수 있을 것입니다.

다음과 같은 이유로, 메뉴를 만드는 요소로는 목록이 최선입니다:

  • 모든 HTML 들이 하나의 목록 요소(예를 들어 ul)에 담기므로, CSS와 자바스크립트를 적용하기 쉽습니다.
  • 목록은 중첩될 수 있으므로, 쉽게 내비게이션의 계층 구조를 나타낼 수 있습니다.
  • 심지어 목록에 어떤 스타일도 적용하지 않는다 하더라도, HTML 의 렌더링은 계층 구조를 보여주며 방문자로 하여금 그 링크들이 하나의 논리적인 단위임을 알 수 있게 합니다.

목록을 중첩시키려면, 포함되는 목록을 li 요소 안에 넣습니다 – 그 다음이 아니라 여기에서 정확한 예제와 틀린 예제 를 볼 수 있습니다.

브라우저에서는 두가지 예제를 똑같이 보여 준다는 것을 알 수 있습니다. 그렇지만 브라우저에 표시되는 내용이 코드의 품질에 대한 기준이 되어서는 안됩니다. 잘못된 예제에 나타난 것 같은 잘못된 HTML 구조는 스타일을 입히기 어려우며, 자바스크립트로 조작하기 어렵고, 다른 형태로 치환하기도 어렵습니다. 중첩되는 UL의 구조는 항상 다음과 같아야 하며:

<ul>
  <li>
    <ul>
      <li></li>
    </ul>
  </li>
</ul>

이렇게 되어서는 안됩니다:

<ul>
  <li></li>
  <ul>
    <li></li>
  </ul>
</ul>

유연하게 해야 하는 이유

사이트의 메뉴는 곧 바뀝니다. 기능이 추가되고 사용자들이 증가하면서 사이트는 커지게 마련입니다. 따라서 사이트가 발전함에 따라서 메뉴 아이템을 넣거나 뺄 수 있도록, 그리고 메뉴가 다른 언어로 번역될 수 있도록 신경써야 합니다. 또한, 메뉴에 적용될 HTML이 정적인 HTML이 아니라 서버사이드 언어에서 동적으로 생성하는 경우가 있을 것입니다. 그렇다고 해서 HTML에 대한 지식이 쓸모 없어지는 것은 아닙니다. 오히려 이런 경우야말로 그러한 지식이 더 중요합니다 – 서버사이드 스크립트가 사용할 HTML 템플릿을 유연하게 만들 수 있어야 하기 때문입니다.

메뉴의 종류

여러가지 웹 사이트에서 일하면서 다양한 타입의 메뉴들을 HTML로 만들게 될 것입니다. 이러한 것의 대부분을 목록을 이용해서 만들 수 있겠지만, 일부 인터페이스의 제약들은 다른 방법을 사용하게끔 강제하기도 합니다(나중에 더 다룰 것입니다). 목록에 기반한 메뉴는 다음과 같습니다:

  • 페이지 내부 내비게이션: 예를 들어 단독 페이지의 차례입니다. 이러한 것에서는 링크가 페이지의 섹션들을 가리킵니다.
  • 사이트 내비게이션: 사이트 전체(또는 그중의 서브섹션)에 대해 내비게이션 바를 사용합니다. 각각의 링크들은 사이트 내의 페이지들을 가리킵니다.
  • 내용-문맥 내비게이션: 현재 보고 있는 주제와 밀접하게 연관된 페이지를 가리키는 링크 목록입니다. 이러한 것은 같은 사이트의 페이지를 가리킬 수도, 다른 사이트의 페이지를 가리킬 수도 있습니다.
  • 사이트맵: 사이트의 모든 페이지들을 가리키는 링크들의 방대한 목록입니다. 이러한 것에서는 보통 목록이 중첩되어서 보기 편하고, 논리적인 구조를 나타냅니다.
  • 페이지 분할pagination: 현재의 페이지와 함께 더 큰 어떤 것의 섹션이나 부분을 차지하게 되는 페이지들을 가리키는 링크입니다. 예를 들어 어떤 기사의 파트 1, 파트 2, 파트 3이 서로 다른 페이지에 있는 경우입니다.

페이지 내부 내비게이션 (차례)

링크를 다룬 글에서 이미 이것에 관해 살펴보았지만, 여기에서는 더 깊이 설명할 것입니다.

페이지 내부 내비게이션에 관련된 예제에서, 나는 페이지로 확장되어지는 링크들의 목록을 사용했습니다. 그러한 연결을 위해서 목적지가 될 요소에 id를 사용하고, 링크의 href에는 그 id와 동일한 값 앞에 해시(#)를 붙인 값을 사용합니다. 각각의 섹션에는 또한 “메뉴로 돌아갑니다” 라는 링크가 있으며, 메뉴를 가리킨다는 점을 제외하면 완전히 동일합니다.

기술적으로는, 이것만 알고 있으면 이러한 종류의 내비게이션을 만들 수 있습니다만, 불행히도 인터넷 익스플로러에는 짜증나는 버그가 한가지 있어서 조금 더 작업을 해야 합니다.

버그는 이러한 것입니다:

  • 인터넷 익스플로러 6이나 7에서 문서를 엽니다.
  • 마우스를 사용하지 않습니다 – 키보드를 사용해서 문서 내부를 이동합니다. 탭 키를 누르면 링크에서 링크로 움직일 수 있고, 엔터 키를 누르면 링크를 활성화시킵니다 – 즉 링크의 목적지로 이동합니다.
  • 여기까지는, 모든 것이 정상적인 것처럼 보입니다. 원했던 목적지로 이동했습니다.
  • 탭 키를 다시 누르면, 정상적인 반응은 현재 위치한 섹션의 첫번째 링크로 이동하는 것입니다. 하지만 인터넷 익스플로러는 당신을 페이지 맨 위의 메뉴로 돌려보내버립니다!

이 버그를 해결하는 방법은 끔찍하게 혼란스러우며, hasLayout 이라고 하는 인터넷 익스플로러의 특정 속성을 다루어야 합니다. 그 속성은 몇가지 방법으로 활성화시킬 수 있는데, Ingo Chao 의 뛰어난 글 “On having layout 에 모두 설명되어 있습니다. 그중 가장 쉬운 방법은, 이 예제에서 사용된 것 처럼, CSS를 이용해서 div 요소에 너비를 지정하는 것 입니다. IE에는 이런 것이 필요합니니다 – 앵커들은 hasLayout 을 가지고 있는 요소 내부에 위치해야 합니다.

일일히 이런 것을 하는 것은 번거로운 일이긴 하지만, 각각의 섹션에 서로 다른 스타일을 적용하고자 한다면 필요한 일이기는 합니다. 이렇게 하면 또한 HTML에서 헤딩 요소가 갖고 있는 문제들 중 하나에 대한 해결책이 될 수도 있습니다 – 헤딩은 자신이 적용되는 섹션을 감싸지 않으며, 다음에 다른 헤딩을 만날 때 까지 그 사이의 모든 것이 같은 섹션이라고 간주하게 됩니다. 즉, div를 사용하지 않는다면 문서의 섹션 각각에 스타일을 적용하는 것이 불가능해집니다.

한가지 알아둘 것은, 오페라에서는 링크 주위의 키보드 내비게이션을 약간 다르게 처리한다는 것입니다. 위의 예제를 오페라에서 연 다음, shift 키를 누른 채로 화살표키를 이용해서 링크 주위를 이동해 보십시오(폼 요소들 사이에서도 동일합니다). 이러한 것을 공간적인spatial 내비게이션이라 부릅니다.

사이트 내비게이션

아마 사이트 내비게이션을 가장 자주 만들게 될 것입니다. 사이트 내비게이션은 사이트 전체(혹은 그 부분집합)의 메뉴이며, 사용자가 선택할 수 있는 옵션과 함께 사이트의 계층구조를 보여줍니다. 이러한 목적에는 목록 요소가 완전히 들어맞는데, 사이트 내비게이션 예제 에서 확인해 볼 수 있습니다.

별로 놀라울 것은 없습니다 – 순수한 HTML의 관점을 제외하고 본다면 말입니다. 이 시리즈의 후반에서 CSS와 자바스크립트를 가지고 이러한 메뉴를 만드는 방법을 다루게 될 것입니다. 중요한 것은 메뉴에서 현재의 문서를 눈에 띄게 보여줌으로서, 사용자에게 지금 어디에 있으며 어디로 이동하게 될 것인지 알도록 하는 것입니다. 이제 그러한 것을 살펴봅니다.

사용자에게 “지금 여기에 있습니다”는 느낌을 주는 것

웹 개발과 내비게이션에서의 황금률은, 현재의 문서는 자기 자신을 가리키는 링크를 포함해서는 안되며 메뉴에 있는 것은 명백히 다른 문서를 가리키는 것들만이어야 한다는 것입니다. 이렇게 하는 것이 중요한 이유는, 사용자에게 표지판 구실을 하기 때문입니다. “한 페이지” 사이트, 블로그의 퍼머링크permalink, 웹 프로그램 같은 것은 예외가 될 수도 있지만, 99%의 사이트들에서 현재의 페이지를 가리키는 링크는 쓸모없으며 사용자를 혼란스럽게 만든다는 것을 보여줍니다.

링크에 관한 글에서, 나는 링크가 약속이고 신뢰라는 언급을 한 적이 있습니다 – 당신은 방문자들에게 그들이 필요로 하는 정보를 더 찾아볼 수 있는 곳으로 안내할 수 있지만, 주의해야 합니다. 만약 그 링크를 따라가서 원했던 것을 얻을 수 없었거나, 예상할 수 없는 방식으로 동작하는 무언가를 만나게 된다면 신뢰를 잃게 되는 것은 당신입니다. 예를 들어 현재의 문서를 가리키는 링크를 제공할 경우, 그것을 누르면 페이지를 다시 로드하게 될 것입니다. 사용자에게 있어서 이러한 것은 예상할 수 없는 일입니다 – 이 링크의 목적이 도대체 무엇인지 알 수 없는 것입니다. 이렇게 되면 사용자는 혼란스러워집니다.

이러한 이유로, 메뉴에서는 절대 현재 페이지를 가리켜서는 안됩니다. 아예 없애버릴수도 있지만, 더 좋은 것은 이것을 링크로 만들지 않으면서 강조(예를 들어 strong 요소로 감싼다거나)하는 것입니다. 이렇게 하면 사용자는 시각적인 단서를 얻을 수 있고, 맹인 방문자 역시 이것이 중요한 것이며 메뉴의 현재 항목이라는 것을 알 수 있습니다 – 현재의 페이지를 하이라이트하는 예제 에 이러한 것이 묘사되어 있습니다.

사용자에게 한번에 몇개의 선택지를 주어야 하는가?

한가지 더 고려해야 할 것은, 방문자에게 몇가지 선택지를 보여줄 것인가 하는 것입니다. 오늘날 상당수의 웹 사이트에서는, 사이트의 모든 곳을 다 갈 수 있도록 모든 링크들을 한곳에서 제공하려고 하는 경향이 있습니다. 이런 곳에서 스크립트와 CSS 트릭이 도움이 될 수 있습니다 – 사용자가 특정한 영역을 선택할 때 까지는, 그것과 관련되어 있는 부분들을 숨김으로서 메뉴가 좀 더 사용하기 쉽도록 – 흔히 롤오버 라고 칭하는 – 만들 수 있습니다. 이러한 것은 기술적인 측면에서는 좋은 것이지만, 그 접근법 자체에는 논란의 여지가 있습니다:

  • 모든 사용자가 그런 방식에 대해 개발자가 의도했던대로 사용할 수 있는 것은 아닙니다. 예를 들어 키보드 사용자들은 찾고 있던 단 하나를 위해서 메뉴 전체를 탭 키로 이동해야만 할 수도 있습니다.
  • 이렇게 하려면 사이트의 모든 문서에 꽤나 많은 양의 HTML을 포함시켜야만 하는데, 많은 경우에서 이러한 코드들이 필요가 없습니다. 즉, 3단계의 메뉴에서 가리키고 있는 문서를 읽으려고 했다면, 4/5/6 단계의 옵션을 볼 필요는 없는 것입니다.
  • 방문자들에게 너무 많은 옵션을 한번에 제공함으로서 그들을 혼란스럽게 만들 수 있습니다 – 사람들은 보통 결정하는 것을 좋아하지 않습니다. 레스토랑에 가서 여러 페이지 짜리 메뉴를 들고는 무엇을 먹을지 결정하는데 시간이 얼마나 걸리는지 생각해보면 될 것입니다.
  • 페이지에 내용은 얼마 없으면서 링크만 가득하다면, 검색엔진들은 페이지에 쓸모있는 정보들이 별로 없다고 판단할 것이며, 그런 페이지들을 상단에 제공하지 않게 될 것입니다. 즉 검색엔진을 통해 들어오는 사용자를 잃게 될 것입니다.

결론은, 메뉴에 몇개의 링크를 둘 것인가 하는 것은 전적으로 당신이 판단할 일입니다. 디자인이 서로 다르면 선택도 서로 다를 것입니다. 하지만 어떻게 해야 할 지 판단하기 힘들다면, 메뉴를 분할해서 사이트의 주된 섹션을 향하는 것만 남도록 하는 것이 좋습니다. 적당한 곳에서 얼마든지 서브메뉴를 제공할 수 있습니다.

컨텍스트 메뉴

문맥에 기초한 메뉴라는 것은, 현재 문서의 내용에 의해 만들어졌으며 그와 연관된 더 많은 정보들을 제공하는 링크들입니다. 이러한 것의 전통적인 사례는 “관련된 글” 링크이며, 보통 뉴스 기사의 하단에서 볼 수 있습니다 – 그림 1과 같이.

그림 1. 문맥에 기초한 메뉴의 예 - 뉴스 기사에서 관련있는 뉴스들을 하단에 제공하고 있습니다.

이것은 소프트웨어 사용자 인터페이스의 컨텍스트 메뉴(우클릭 혹은 Ctrl+클릭 으로 나타나는)와는 조금 다른 것입니다. HTML의 관점에서는 이러한 것은 그저 다른 형태의 링크 목록일 뿐입니다.1)

웹 사이트에서 문맥에 기초한 메뉴를 잘 활용하면 사이트의 다른 부분들을 효과적으로 광고할 수 있습니다.

사이트맵

사이트맵 또한 사람들이 흔히 기대하는 것입니다. 사이트맵은 사이트의 모든 페이지들(정말로 거대한 사이트를 다루고 있다면 주된 섹션들)을 담고 있는 것입니다. 방문자들은 사이트맵을 통해 사이트 전체의 구조를 훑어볼 수 있으며, 원하는 페이지가 계층구조상 깊이 있는 경우라고 하더라도 매우 빠르게 거기로 이동할 수 있습니다.

사이트맵과 사이트 검색 모두 방문자들이 탐색중에 길을 잃었거나, 시간이 없을 때 유용하게 사용할 수 있는 폴백 옵션을 제공할 수 있습니다.

HTML의 관점에서 사이트맵은 대단히 많이 중첩된 링크들 / (사이트가 아주 큰 경우) 섹션에 밀접한 계층구조 상의 중첩된 섹션 헤딩들의 목록, 또는 섹션들에 대한 검색 폼이 될 수 있습니다.

페이지 분할

여러개의 페이지로 나누어진 큰 문서를 제공한다면 페이징이 필요합니다. 방대한 이미지 목록, 혹은 검색 결과 페이지에서 페이징을 쉽게 볼 수 있을 것입니다.

페이징은 동일한 문서로 링크 – 하지만 그 링크에는 몇 페이지에서 시작한다는 추가적인 정보를 제공하는 – 한다는 점에서 일반적인 내비게이션과는 다릅니다. 몇가지 예제가 그림 2에 있습니다:

그림 2. 페이징을 사용하면 사용자들이 방대한 데이터 속에서 길을 잃지 않도록 할 수 있습니다.

다시 한 번 말하지만, 현재의 링크(데이터들 중 어떤 것이 보여지고 있으며, 페이징 속에서 어디까지 진행했는지 나타내주는)에 링크를 걸지 말고, strong 같은 것을 사용해서 강조해야 합니다.

사이트 내비게이션과 다른 점은, 페이징을 구현하기 위해서 많은 양의 프로그래밍 로직이 필요하다는 것입니다. 데이터 집합 전체 속에서 어디에 있는가에 따라 앞, 뒤, 처음, 마지막의 링크들을 보여줘야 할 수도, 숨겨야 할 수도 있습니다. 정말로 방대한 수의 페이지들을 제공해야 한다면, 100, 200, 같은 식으로 페이지 번호를 건너뛸 수 있는 옵션도 제공해야 할 것입니다. 이러한 메뉴를 하드코딩하기 보다는 아마도 서버사이드에서 만들게 될 것입니다. 그렇다고 해서 규칙이 바뀌는 것은 아닙니다 – 페이지 자신으로 링크해서는 안되며, 어디로도 갈 수 없는 링크를 제공해서도 안됩니다.

목록으로 충분치 않을 때 – 이미지맵과 폼

99%의 경우에 ul과 ol로 메뉴를 만들 수 있습니다 – 논리적인 순서와 포함관계를 CSS를 이용해서 스타일링할 수 있는 경우에는 더욱 그렇습니다. 하지만 다른 디자인 테크닉을 필요로 하는 경우도 간혹 있습니다.

이미지 맵에 핫스팟을 만드는 법

한가지 테크닉은 클라이언트 사이드 이미지맵입니다. 이미지맵은 이미지의 영역들에 링크를 걸어서, 이미지를 메뉴로 만드는 방법입니다. 이미지맵 예제에서 확인해볼 수 있습니다. 링크를 따라가서, 그림 3에 나타나는 삼각형의 각 부분들을 눌러 보십시오.

그림 3. area 요소를 통해 맵을 정의함으로서 이미지의 부분들을 인터랙티브 요소로 변환할 수 있습니다.

영역들(핫스팟이라고도 합니다)이 정의된 맵을 이용해서 어떤 이미지든지 메뉴로 바꿀 수 있습니다. 그 맵에 name 속성을 사용하고, img 요소에서 usemap 속성을 사용하여 맵과 이미지를 연결합니다. 이것이 페이지 내부 링크와 완전히 동일하게 동작한다는 것을 알 수 있습니다 – 즉 usemap 속성의 앞에 해시(#)를 붙여야 한다는 것입니다.
각각의 영역들은 다음과 같은 속성을 갖습니다:

href

영역이 가리키게 될 URL을 정의합니다. 동일한 문서내의 대상으로 링크할수도 있습니다.

alt

이미지가 보이지 않거나, 사용자 에이전트가 이미지를 지원하지 않는 경우에 대비한 대체 텍스트를 정의합니다.

shape

영역의 모양을 정의합니다. rect(사각형), circle(원형), poly(다각형)을 사용할 수 있습니다.

coords

핫스팟이 될 이미지의 좌표들을 정의합니다. 이러한 값들은 이미지의 왼쪽 위 꼭지점에서부터 측정한 값이며, 픽셀 또는 퍼센트 단위를 사용할 수 있습니다. 사각형 영역에서는 왼쪽 위 꼭지점과 오른쪽 아래 꼭지점만 지정하면 됩니다. 원형에서는 그 원의 중심점과 반지름을 지정해야 하고, 다각형에서는 모든 꼭지점의 목록을 제공해야 합니다.

HTML로 이미지맵을 정의하는 것은 까다롭습니다. 어도비 이미지레디 또는 파이어워크 같은 프로그램에서 눈으로 보면서 이미지 맵을 정의할 수 있습니다.(프로그램에서 HTML을 생성해 줄 것입니다)

폼을 이용해서 공간을 절약하고 링크가 넘치지 않게 하는 법

select 요소를 이용해서 폼을 만드는 방법 역시 고려해볼만 합니다. 링크가 가리킬 페이지들을 select 요소의 옵션들의 값으로 사용하고, 방문자가 옵션을 선택해서 폼을 제출하면 그 페이지로 이동하는 것입니다. 폼 메뉴 예제에서 확인해볼 수 있습니다.

이렇게 하는 것의 가장 큰 혜택은, 많은 양의 옵션을 사용하더라도 브라우저에서는 한 줄에 그리기 때문에 공간을 많이 차지하지 않는다는 것입니다.

그림 4. select 요소로 만든 메뉴는 화면에서 한 줄 만을 차지합니다.

더 여러가지를 해 볼 수 있습니다. optgroup 요소를 사용하면, optgroup 예제에서 보는 바와 같이 메뉴 옵션들을 그룹으로 묶을 수 있습니다.

이렇게 하면 그림 5와 같이, 메뉴에 선택할 수 없는 옵션들(그룹의 이름입니다)이 나타납니다.

그림 5. select 메뉴는 사용자에게 옵션이 어떤 그룹에 속하는지 알려줄 수 있습니다.

이렇게 select 요소를 사용해서 메뉴를 만들게 되면 공간을 거의 차지하지 않는다는 장점이 있지만, 사용자들이 선택한 페이지로 이동시키기 위해 서버사이드 스크립트를 사용해야만 합니다. 자바스크립트를 사용할 수도 있지만, 그것에만 의존해서는 안됩니다. 자바스크립트를 꺼 둔 사용자들도 메뉴를 이용할 수 있어야 하기 때문입니다.

그리 분명하지는 않은 장점이 한가지 더 있습니다. 하나의 문서에 너무 많은 링크를 사용하지 않게 된다는 것입니다. 이것의 의미는 보조 기술의 사용자를 압도해 버리지 않는다는 것입니다. 또한 검색 엔진에서 페이지의 내용/링크 비율을 따질 때 메뉴의 옵션들을 링크로 계산하지 않도록 함으로서, 가치 없는 페이지로 판단하지 않도록 하는 장점도 있습니다. 하지만, 많은 보조 기술에서 페이지에 포함된 링크들의 맵을 생성할 수 있다는 점을 기억해야 합니다. 중요한 링크들을 전부 select 메뉴에 넣게 된다면, 그러한 기능을 사용할 수 없게 될 가능성이 있습니다. 따라서 중요한 링크들을 a 요소로 제공하고, select 메뉴를 이용해서 더 많은 옵션을 제공하는 것도 괜찮은 아이디어입니다. 사용자들은 그것을 이용할 수 있지만, 검색엔진 같은 것은 그것이 존재한다는 사실을 인식하지 못할 것입니다.

메뉴가 있어야 할 곳, 그리고 그것을 건너뛸 수 있도록 하는 것

HTML 메뉴에 대해 언급해야 할 것이 한가지 더 있습니다 – 메뉴의 위치가 매우 중요하다는 것입니다. 스크롤 기능을 사용할 수 없거나, 키보드만을 가지고 사이트를 이용해야 하는 사용자의 경우를 생각해 보십시오. 페이지가 로드되었을때 그들이 처음으로 만나는 것은 그것의 위치와 제목입니다. 그 다음으로 문서를 처음부터 끝까지 읽어 내려가는데, 링크를 만날때마다 멈춰서 그 링크를 따라갈 것인지 아닌지를 묻게 됩니다. 다른 옵션은 모든 링크들의 목록을 만들거나, 제목에서 제목으로 이동하는 것입니다.

메뉴가 문서의 맨 위에 있다면, 사용자가 제일 처음으로 만나는 것은 메뉴가 될 것입니다. 문서의 내용으로 이동하기 위해 15-20개의 링크들을 건너뛰는 것은 매우 번거로운 일이 될 수 있습니다. 이에 대응하기 위한 방법이 두가지 있을 수 있습니다. 첫번째는 메뉴를 문서의 주된 컨텐츠 뒤에 위치시키는 것입니다(이렇게 마크업하더라도, 원한다면 CSS를 이용해서 맨 위에 보이게끔 할 수 있습니다). 두번째 방법은 메뉴를 건너뛸 수 있는 링크를 제공하는 것입니다. 건너뛰는 링크는 메인 메뉴의 앞에 위치하며, 사용자가 원한다면 메뉴를 건너뛰고 내용으로 즉시 이동할 수 있게끔 합니다. 문서의 끝에 “메뉴로 가기” 같은 링크를 배치해서 쉽게 처음으로 이동할 수 있게끔 할 수도 있습니다. 건너뛰는 링크를 사용한 예제를 보고 더 많은 영감을 얻기 바랍니다.

건너뛰는 링크는 장애를 가진 사람들에게 유용할 뿐만 아니라, 작은 화면을 갖고 있는 모바일 장치에서도 매우 유용합니다.2)

요약

이 글에서는 HTML로 작성하게 될 메뉴들에 대해 알아보았습니다. 다음과 같은 내용을 다루었습니다:

  • HTML로 메뉴를 만들 때 앵커의 목록이 안성맞춤인 이유
  • 메뉴가 고정된 것이 아니라 바뀔 것이라고 예상하고 있어야 하는 이유
  • 페이지 내부 내비게이션: 현재 문서의 섹션들로, 그리고 메뉴로 돌아오도록 링크
  • 사이트 내비게이션: 현재 사이트의 페이지들과 그 계층구조를 보여주는 메뉴. 사용자가 현재 위치한 페이지를 강조하는 것이 중요한 이유도 살펴보았습니다.
  • 문맥에 기초한 내비게이션: 사이트의 다른 곳(혹은 다른 사이트)에 있는 연관된 페이지들로의 링크를 제공하는 것
  • 페이징: 방문자들이 여러개의 페이지로 분할된 문서를 볼 수 있도록 하는 도구를 제공하는 것
  • 이미지 맵: 이미지에 영역을 설정해서 그래픽 메뉴를 만드는 것
  • 폼 메뉴: 공간을 많이 차지하지 않고, 사용자를 당혹스럽게 만들지 않고, 검색엔진에서 저평가되지 않으면서도 많은 수의 링크들을 제공하는 것

시리즈의 후반에서 CSS에 대해 다루면서 이러한 주제들에 대해 다시 보게 될 것입니다. 거기에서 살펴보는 내용을 익힌다면 HTML 구조를 보기좋게 하면서도, 사용자가 그것이 메뉴임을 더 분명히 알 수 있도록 할 수 있을 것입니다.

연습문제

  • 메뉴를 목록으로 마크업하는 것이 좋은 이유는 무엇입니까?
  • 내비게이션 메뉴를 디자인할 때, 이후를 대비하기 위해 어떤 것들이 필요합니까?
  • 메뉴에서 select 요소를 사용하는 것의 장단점은 무엇입니까?
  • area 요소를 사용해서 정의하는 것은 무엇입니까? area 요소에서 nohref 속성이 의미하는 것은 무엇입니까? (후자는 이 글에서 언급되지 않았습니다. 온라인에서 찾아보아야 할 것입니다)
  • 건너뛰는 링크의 장점은 무엇입니까?

저자에 관하여

Chris Heilmann은 지난 10년간 웹 개발자로서 활동해 왔으며 취미삼아 라디오 저널리즘에 관한 일도 한다. 그는 영국에 있는 야후에서 트레이너와 리더 개발자로 근무하고 있으며 유럽과 아시아의 front end 코드의 품질을 관리한다.

그의 블로그는 Wait till I come 에 있으며 많은 소셜 네트워크에서 “codepo8”로 알려져 있다.

이 글과 비슷한 종류의 글은 'HTML' 카테고리에서 더 찾아볼 수 있습니다. 또한, , , , 태그로도 검색해 보실 수 있습니다. 북마크를 하시려면 퍼머 링크로 기억해 주세요.
이 글을 다 읽어주셨다면, 댓글을 남겨주세요. 좋았다라는 격려도 좋고, 잘못된 부분을 지적해 주시는 것도 좋습니다. 마음에 드셨다면 아래 Like 버튼을 눌러서 페이스북과 트위터로 소개해 주시면 더욱 좋겠습니다.