작업 우선으로 시작하고 작은 정보 구조를 유지하세요
정보 구조(Information architecture)는 콘텐츠와 기능을 어떻게 그룹화하고, 명명하고, 연결하는지에 관한 것입니다. 방문자의 작업을 나열한 뒤 각 작업의 시작 페이지, 다음 페이지, 성공적 종료 상태를 매핑하세요. 이는 메뉴 항목이 유용한지, 아니면 방문자가 해독해야 하는 내부 용어인지를 보여줍니다. 기본 내비게이션은 해당 작업을 시작하는 섹션에 집중하세요.
내비게이션은 사이트맵이 아닙니다. GOV.UK는 서비스의 모든 부분을 나열하는 대신 유용한 최상위 섹션을 나열할 것을 권합니다. 여정에 필수 순서가 있다면 전역 메뉴에서 추론하게 하지 말고 콘텐츠나 작업 목록에 명시하세요.
방문자가 동일한 답변이나 작업을 기대하는 페이지를 함께 묶으세요. 소유 팀별로 묶지 마세요.
빽빽한 헤더 대신 랜딩 페이지와 문맥적 링크로 세부사항을 제공하세요.
목적지를 예측하는 레이블을 사용하세요
레이블은 그 뒤에 무엇이 올지에 대한 약속입니다. 목적지와 일치할 때는 “Pricing(요금)”, “Documentation(문서)”, “Get support(지원받기)”, “Manage account(계정 관리)”와 같은 익숙한 이름을 우선하세요. 방문자가 내용을 예측할 수 없다면 “Resources(자료)”나 “Explore(탐색)”처럼 모호한 레이블은 피하세요. 문구와 순서를 일관되게 유지하세요.
Google은 문맥 밖에서도 이해할 수 있는 간결하고 관련성 높은 링크 텍스트를 권합니다. 일반적인 “click here”나 키워드만 잔뜩 넣은 링크는 모두 적합하지 않습니다. 아이콘 전용 컨트롤에는 그 동작을 설명하는 접근성 이름(accessible name)을 제공하세요.
대상이 요금제라면 “Learn more(자세히 보기)” 대신 “View plans(요금제 보기)”를 사용하세요.
표시된 페이지를 시각적으로 그리고 프로그램적으로 표시하세요; W3C는 표시된 페이지용으로 aria-current=page를 설명합니다.
목적지를 크롤러가 접근 가능하고 구조적으로 명확하게 만드세요
내비게이션 목적지는 보통 실제 웹 주소로 해석되는 href를 가진 HTML 앵커(anchor)여야 합니다. Google은 렌더된 마크업이 그 구조를 유지할 경우 동적으로 삽입된 앵커도 일반적으로 크롤할 수 있다고 합니다. 클릭 핸들러나 사용자정의 속성만으로 대체하는 것은 신뢰할 수 있는 대안이 아닙니다. 프레임워크 소스뿐만 아니라 렌더된 출력(rendered output)을 점검하세요.
주요 내비게이션 주변에는 의미론적 구조를 사용하세요. W3C는 nav 요소와, 일반 사이트 내비게이션의 경우 목록(list)을 권장합니다. 페이지에 여러 내비게이션 영역이 있을 때는 각 영역에 레이블을 달아 화면 읽기 프로그램 사용자가 기본 내비게이션과 푸터 또는 로컬 내비게이션을 구분할 수 있게 하세요.
클라이언트 사이드 렌더링 후 데스크톱과 모바일의 중요한 목적지가 앵커와 href 값을 갖는지 확인하세요.
URL 검사(URL Inspection)는 Google의 크롤링, 색인, 제공 정보를 보여주지만 방문자가 페이지를 찾을 수 있음을 증명하지는 않습니다.
모바일 메뉴를 완전한 상호작용으로 설계하세요
반응형 내비게이션은 축소될 수 있지만 남아 있는 목적지는 화면 크기 간에 동일한 문구, 순서, 대상을 유지해야 합니다. W3C는 하위 내비게이션에서 항목을 축소하거나 숨기는 것을 허용하면서도 일관성을 요구합니다. 헤더가 혼잡하다고 해서 중요한 경로를 데스크톱 전용으로 만들지 마세요; 우선순위가 낮은 정보를 이동하거나 계층 구조를 재고하세요.
보여주기/숨기기 방식의 메뉴에는 링크 그룹을 제어하는 버튼을 사용하고 열려 있는지 여부를 전달하세요. W3C의 disclosure-navigation 예제는 aria-expanded와 aria-controls를 사용하고 Tab, Shift+Tab, Escape를 다룹니다. 예제는 교육용이므로 실제로 사용자들이 쓰는 조합으로 컴포넌트를 테스트하세요.
상위 페이지와 그 하위 링크가 모두 필요할 때는 페이지 링크와 확장 제어를 구분하세요.
포인터 호버로 드러나는 모든 항목은 키보드 포커스와 터치로도 찾을 수 있어야 합니다.
방향성과 키보드 이동을 지원하세요
키보드 접근성은 마무리 장식이 아닙니다. WCAG 2.1 성공 기준(Success Criterion) 2.1.1은 경로 의존 입력(path-dependent input)을 제외하고 기능이 키보드 인터페이스를 통해 조작 가능해야 함을 요구합니다. 헤더에서는 방문자가 제어 요소를 Tab으로 순회하고, 포커스를 확인하고, 링크와 버튼을 활성화하며, 함정(trap)에 빠지지 않고 이동할 수 있어야 합니다.
반복되는 헤더 링크는 페이지 이동을 느리게 만들 수 있습니다. 시작 부분 근처에 건너뛰기(skip) 링크를 두면 키보드 사용자가 주요 콘텐츠로 가는 경로를 얻을 수 있습니다. GOV.UK는 이 링크가 키보드 사용 시까지 시각적으로 숨겨진다고 설명합니다. 링크가 의미 있는 대상에 도달하는지 테스트하세요.
확대했을 때도 보이는 명확한 대신 표시(브라우저 기본 포커스 표시)를 제거하지 마세요.
헤더에서 대상 페이지로 Tab, Shift+Tab, Enter, Space, Escape를 사용해 이동해 보세요.
릴리스 전후에 찾기 쉬움을 테스트하세요
대표성 있는 사용자에게 해지 안내를 찾거나 요금제를 비교하는 등 현실적인 작업을 완료하도록 요청하세요. 그들이 어디로 가기를 기대했는지, 어떤 레이블을 오독했는지, 내비게이션이 실패했을 때 검색으로 전환하는지를 관찰하세요. 의도한 레이블로 이끌지 마세요. 각 장벽을 기록하고 이를 제거할 수 있는 가장 작은 변경을 식별하세요.
과제 테스트와 함께 기술적 점검을 병행하세요. W3C의 Easy Checks는 마우스 없이 테스트하는 것, 포커스 가시성, 탭 순서, 키보드 트랩, 드롭다운을 포함한 점검을 권장합니다. 핵심 작업을 좁은 너비와 큰 텍스트 크기에서 반복하세요. 자동화된 점검은 마크업 문제를 지적할 수 있지만, 레이블이 의미가 있는지를 판정할 수는 없습니다.
테스트 전에 의도된 끝점과 지원할 장치 또는 입력 방법을 기록하세요.
이해관계자의 선호에 의존하지 말고 동일한 작업에 대해 이전 경로와 새 경로를 비교 테스트하세요.
내비게이션 변경을 가용성 민감 릴리스로 다루세요
헤더는 로드되었지만 중요한 경로가 사실상 사용할 수 없게 되는 상황이 발생할 수 있습니다: 체크아웃, 로그인, 지원 경로, 문서 페이지가 깨진 상태, 오래된 링크, 잘못된 리다이렉트 뒤에 있을 수 있습니다. 릴리스 전에 중요 목적지를 목록화하고 데스크톱·모바일 경로를 테스트하며 렌더된 링크가 의도된 페이지로 연결되는지 확인하세요. 인증되거나 지역별 경로는 권한 있는 환경에서 확인하세요.
SIU의 역할은 선제적 수정입니다: 사전 점검을 실행하고 배포 후 필수 경로를 확인하며, 수정을 되돌릴 수 있게 만드세요. 메뉴 구성의 버전 관리를 유지하고, 복원할 수 있는 담당자를 지정하며, 복원된 경로를 검증하세요. 이것은 릴리스 영향을 제한하지만 사용성 조사나 라이브 상태 모니터링을 대체하지는 않습니다.
중요 목적지가 누락되었거나 잘못되었거나 키보드와 터치로 도달할 수 없을 때 게시를 차단하세요.
재구조화 전에 이전 구성, 소유자, 트리거, 검증 절차를 문서화하세요.