사이드 메뉴와 하단 메뉴 링크의 검색상 의미

화면 위치와 탐색 역할을 구별하기

적용 방법으로 같은 화면의 옆 메뉴와 하단 목록에서 문구와 목적지 주소를 추출해 비교하는 절차를 제안합니다. 사이드 영역이 현재 주제의 다른 문서를 제공하는지, 하단 영역이 공통 안내를 제공하는지 실제 목록을 읽습니다. 위치만 보고 역할을 미리 정하면 병원 사이트가 실제로 제공하는 메뉴의 차이를 놓칠 수 있습니다. 두 영역의 내용에 맞는 탐색 목적을 작성하는 단계입니다.

중요한 페이지는 사이트의 다른 페이지 중 하나 이상에서 연결돼야 한다고 Google은 안내합니다. 반복되는 공통 링크만 세는 방법보다 필요한 문서의 발견 경로가 실제로 있는지 읽는 질문에 적용할 수 있습니다. 한 화면에서 두 번 보인다는 사실과 사이트의 여러 문서에서 접근할 수 있다는 관계는 다릅니다. 사이트 전체의 실제 연결을 조사하지 않고 특정 영역 하나를 반드시 제거해야 한다고 판단하지 않습니다.

한 페이지에 넣어야 할 링크 수는 정해져 있지 않다고 명시합니다. 메뉴 항목 수를 하나의 숫자로 맞추는 작업보다 현재 목록의 선택지가 설명되는지 읽을 수 있습니다. 같은 목적지를 두 위치에 제공했다면 각 위치의 역할이 있는지 조사하는 편집안을 제안합니다. 반복 자체에 별도 순위 상승이나 제재 효과가 있다는 설명은 붙이지 않습니다.

메뉴에서 제공하는 이름과 실제 주소 조사하기

Google은 좋은 앵커 텍스트가 구체적이고 간결하며 현재 페이지와 목적지 양쪽에 관련돼야 한다고 설명합니다. 문구가 다음 페이지에 대한 기대를 설정한다는 안내입니다. 사이드 메뉴의 짧은 이름과 하단의 공통 이름이 실제 본문을 같은 범위로 설명하는지 읽을 수 있습니다. 이름을 새로 만들기 전에 연결된 문서의 제목과 내용부터 대조하는 방법입니다.

앵커 문구만 따로 읽었을 때 구체적인 정보를 제공하며 이해되는지 시험하라는 조언도 있습니다. ‘자세히 알아보기’나 일반적인 ‘도움말’처럼 대상이 드러나지 않는 표현은 추가 설명이 필요할 수 있습니다. 메뉴의 전체 문맥을 보지 않고 목록을 선택하는 경우에도 어느 문서인지 식별되는지를 조사할 수 있습니다. 동일한 단어로 다른 목적지를 표시하면 그 차이를 읽을 자료가 있는지 대조합니다.

일반적으로 href가 있는 앵커 요소에서 링크를 크롤링할 수 있다고 Google은 설명합니다. href가 없거나 다른 태그의 스크립트 이벤트로 작동하는 연결은 주소를 안정적으로 추출하기 어렵다고 안내합니다. 사이드 메뉴가 눌린다는 사실만으로 하단의 모든 연결도 같은 방식으로 구현됐다고 답하지 않습니다. 각 영역의 실제 소스에서 대상 주소가 제공되는지 조사할 수 있습니다.

Google은 스크립트로 입력한 앵커 텍스트가 실제로 전달되는지 URL 검사 도구의 렌더링된 HTML에서 조사하도록 안내합니다. 영역의 이름이 아닌 각 연결의 텍스트가 그 결과에 들어가는지 읽을 수 있습니다.

관련된 모든 키워드를 앵커에 넣지 말고 자연스럽게 작성하라는 원칙도 있습니다. 다음 페이지를 이해하는 데 필요한 표현인지 판단하라는 설명입니다. 두 영역에서 문구를 바꿀 때 검색어를 더 많이 넣는 일보다 각 문서의 식별에 필요한 정보를 읽는 편집 방법을 적용할 수 있습니다. 중요한 안내의 이름이 반복되는 키워드 묶음으로 바뀌는지 조사합니다.

옆 목록과 아래 목록의 영역 식별 설계

옆과 아래에 각각 탐색 목록을 제공하는 설계에서는 두 영역을 구별할 이름도 필요합니다. W3C의 Menu Structure는 여러 메뉴의 라벨을 짧고 설명적으로 작성해 찾고 이해하기 쉽게 하라고 권고합니다. 화면의 위치를 알 수 없는 방식으로 읽는 사람에게도 목록의 목적이 전달되는지 판단할 수 있습니다. 실제 문서군이 무엇인지 먼저 파악한 뒤 그 군의 이름을 붙이는 적용 방법입니다.

시각적으로는 사이드 칼럼과 하단 칼럼이 떨어져 있어도 구조에서는 같은 이름으로 제공될 수 있습니다. 제목을 사용한 라벨, aria-label, aria-labelledby는 원문이 제시한 세 방법입니다. 메뉴의 제목을 연결할 때에는 그 제목의 식별자가 실제 탐색 영역의 속성과 대응하는지 소스를 대조할 수 있습니다. 한 화면에 여러 목록이 존재한다는 사실만으로 이러한 관계가 자동으로 만들어지지 않습니다.

W3C의 예는 nav에 aria-labelledby를 지정하고 그 값에 해당하는 식별자를 제목에 부여합니다. 제목은 시각적으로 숨겨져 있지만 메뉴의 이름을 제공하는 구조입니다. 이 예를 적용할 때에도 화면의 제목을 숨기는 것 자체가 목적은 아닙니다. 보이는 제목을 사용할지 별도의 라벨을 사용할지는 실제 화면과 이용 방식에 맞춰 선택하되, 메뉴의 이름을 제공하는 연결이 성립하는지 읽는 질문으로 사용할 수 있습니다.

nav로 탐색 영역을 식별하는 방식은 사용자가 그 메뉴로 직접 접근할 수 있게 한다는 설명과 연결됩니다. 따라서 아래쪽 목록이 화면에서 멀리 떨어져 있다는 이유만으로 그 목록에 접근하는 모든 이용 방식이 똑같이 길다고 단정할 수 없습니다. 실제 마크업에서 탐색 영역으로 식별되는지와 링크를 발견하는 검색로봇의 조건은 각각 조사해야 합니다. 접근성의 영역 식별이 링크마다 href를 자동으로 생성하는 기능은 아닙니다.

목록의 구조를 전달하면 보조기술은 항목의 수를 알리고 목록에 맞는 탐색 기능을 제공할 수 있습니다. 아래 메뉴를 여러 줄의 일반 텍스트로만 작성한 상태와 목록 요소로 전달한 상태를 비교하는 질문입니다. 몇 개의 항목이 존재하는지 사용자에게 제공하는 정보와 페이지에 몇 개의 링크를 넣어야 하는지 정하는 규칙은 서로 다릅니다. W3C의 구조 안내를 링크 개수 제한으로 읽지 않습니다.

순서의 의미도 실제 자료와 맞춰야 합니다. 메뉴 항목에 특별한 차례가 없다면 ul, 단계처럼 순서가 중요한 목록이라면 ol을 쓰는 원문의 구분을 적용할 수 있습니다. 하단이 화면의 마지막이라는 사실은 그 안의 항목이 순차 절차라는 뜻이 아닙니다. 실제로 이용 순서가 필요한 목록인지, 어느 항목부터 선택해도 되는 문서군인지에 따라 의미를 전달하는 요소를 선택합니다.

현재 읽는 문서를 알리는 구조는 이동 가능한 목적지와 구별할 수 있습니다. W3C는 보이지 않는 현재 페이지 안내를 붙이고 해당 항목에서 앵커를 제거한 예를 제공합니다. 링크를 제거할 수 없다면 aria-current에 page 값을 지정하는 방식을 제시합니다. 옆 목록과 하단 목록에 같은 문서가 등장할 때에는 어느 항목이 현재 문서를 뜻하는지 각각의 실제 구조에서 조사할 수 있습니다.

반응형 화면에서 일부 항목을 접거나 하위 메뉴 안에 숨길 수 있다는 설명도 있습니다. 표시되는 항목의 차례, 표현, 도착지는 유지해야 한다는 조건입니다. 사이드 목록이 작은 화면에서 하단으로 옮겨진 설계라면 옛 위치와 새 위치를 별도의 문서군으로 오해하지 않고 항목을 대응시키는 방법을 적용할 수 있습니다. 버튼을 열었을 때 실제로 제공되는 목록과 원래 메뉴를 대조하는 질문입니다.

이어서 읽을 주제

검색으로 들어오는 블로그 문서의 관계를 읽을 때: 블로그 상위노출.

문서 정보를 기계가 해석하는 표현을 읽을 때: 구조화 데이터.