WCAG 2.4.5: 여러 가지 방법

WCAG 2.4.5는 웹사이트가 하나의 웹 페이지 집합 내에서 사용자가 특정 페이지를 찾을 수 있도록, 사이트 검색, 사이트맵, 내비게이션 메뉴와 같은 둘 이상의 방법을 제공할 것을 요구합니다. 이는 서로 다른 능력과 선호를 가진 사용자들이 자신에게 가장 잘 맞는 방법을 사용해 콘텐츠를 찾을 수 있도록 보장합니다.

이 규칙의 의미

WCAG 2.4.5 — Multiple Ways(여러 가지 방법)는 Operable(운용 가능) 원칙 아래의 레벨 AA 성공 기준이다. 이 기준은 더 큰 웹 페이지 집합의 일부인 모든 웹 페이지가 최소 두 가지 서로 다른 탐색 메커니즘을 통해 도달 가능해야 한다고 요구한다. 다시 말해, 사용자가 어떤 페이지를 찾기 위해 단 하나의 경로에만 의존하도록 강요되어서는 안 된다.

이 기준을 충족하는 일반적인 탐색 메커니즘에는 다음이 포함된다. 사이트 전체 검색 기능, 사이트맵(독립된 페이지이든 인라인 구조이든), 목차, 일관된 탐색 메뉴 또는 사이드바, 브레드크럼(breadcrumb) 경로, 관련 페이지 간 링크 등이다. 이들 중 아무 두 가지 — 또는 이와 동등한 다른 메커니즘 — 를 함께 사용하면 요구 사항을 충족한다.

이 기준은 특히 웹 페이지 집합에 적용된다. 더 큰 사이트나 애플리케이션에 속하지 않는 독립형 웹 페이지는 예외이다. 또한 결제 확인 페이지, 폼 제출 성공 화면, 마법사(wizard) 단계와 같이 어떤 프로세스의 결과이거나 그 과정 중 한 단계인 페이지 역시 명시적으로 예외이다. 이러한 페이지는 본질적으로 순차적이며, 순서를 무시하고 직접 접근할 수 있도록 허용하는 것은 부적절하거나 해로울 수 있기 때문이다.

통과하려면 최소 두 개의 독립적인 탐색 메커니즘이 사이트 전반에 걸쳐 존재하고, 기능하며, 접근 가능해야 한다. 실패는 단 하나의 메커니즘만 존재할 때 발생한다 — 예를 들어, 검색도, 사이트맵도, 다른 탐색 보조 수단도 없이 상단 탐색 메뉴만 제공하는 사이트가 이에 해당한다. 또한 보조 메커니즘이 작동하지 않거나 접근 불가능한 경우(예: 결과를 전혀 반환하지 않는 검색 상자, 보조기술에서 숨겨진 사이트맵 등)에도 실패로 간주된다.

중요한 점은, 이 기준이 특정 메커니즘 조합을 강제하지는 않는다는 것이다. 이러한 유연성은 의도적인 것이다. 서로 다른 사용자는 콘텐츠를 찾는 전략이 근본적으로 다르며, 표준은 특정 해결책을 규정하기보다는 중복성을 요구함으로써 이러한 다양성을 인정한다.

왜 중요한가

탐색은 모든 웹 경험의 기반이며, 탐색에 대한 장벽은 장애가 있는 사람들에게 불균형적으로 큰 영향을 미친다. 탐색 경로가 하나뿐일 때, 그 경로를 사용할 수 없는 사용자는 사실상 콘텐츠에서 배제된다.

운동 장애가 있는 사용자 — 스위치 접근, 시선 추적 장치, 음성 제어 소프트웨어, 키보드 전용 탐색 등을 사용하는 사람들을 포함 — 에게 복잡한 계층형 메뉴는 매우 피로하거나 효율적으로 탐색하는 것이 불가능할 수 있다. 사이트 검색은 여러 단계의 메뉴를 거치지 않고도 곧바로 콘텐츠로 이동할 수 있게 해준다. 반대로, 특정 인지 또는 기억 장애가 있는 사용자는 개방형 검색 필드를 혼란스럽거나 효과적으로 사용하기 어렵다고 느낄 수 있다. 이들에게는 명확하게 구조화된 사이트맵이나 탐색 가능한 카테고리 트리가 훨씬 더 유용하다.

스크린 리더에 의존하는 시각장애인 사용자에게는, 건조한(밀집된) 탐색 메뉴가 건너뛰기 링크가 있더라도 매 페이지 방문마다 반복되는 장애물이 될 수 있다. 사이트맵이나 검색 바로가기(쇼트컷)는 이러한 인지적·물리적 부담을 크게 줄여준다. 화면 확대를 사용하는 저시력 사용자의 경우, 넓은 탐색 메뉴는 높은 확대 수준에서 일부만 보일 수 있어, 텍스트 기반 검색이나 사이트맵이 중요한 대체 수단이 된다.

난독증이나 주의력 장애와 같은 인지 장애가 있는 사용자에게는, 정확한 메뉴 계층 구조를 기억하거나 인식할 필요 없이 대략적이거나 부분적인 용어로 검색할 수 있는 능력이, 스스로 콘텐츠를 찾는 것과 완전히 포기하는 것 사이의 차이를 만든다.

구체적인 실제 시나리오를 생각해 보자. 류마티스 관절염이 있는 사용자가 키보드 전용 탐색으로 터키의 전자상거래 플랫폼을 방문한다. 이 사이트의 메가 메뉴는 하위 카테고리를 표시하기 위해 정교한 마우스 오버 상호작용을 요구하고, 키보드 포커스 동작은 신뢰할 수 없다. 만약 이 사이트가 검색창과 사이트맵도 제공한다면, 그 사용자는 여전히 필요한 상품 페이지를 찾을 수 있다. 이러한 대안이 없다면, 이 사이트는 사실상 그 사용자에게 사용 불가능한 것이며 — 이는 고객 상실이자 잠재적인 법적 책임을 의미한다.

접근성을 넘어, 여러 탐색 메커니즘은 측정 가능한 SEO 및 사용성 이점을 제공한다. 사이트맵은 검색 엔진 봇의 크롤링 가능성을 향상시킨다. 사이트 검색 기능은 사용자 참여를 높이고 이탈률을 줄인다. 브레드크럼 경로는 구조화된 데이터와 함께 구현될 경우 검색 엔진 결과 페이지에서 클릭률을 개선한다. 이러한 이점은 2.4.5를 충족하는 것이 단순한 규정 준수 작업이 아니라, 건전한 웹 디자인 관행임을 의미한다.

테스트 방법

자동 스캔 — 기준선 설정: 사이트의 대표 페이지에 대해 axe DevTools 또는 Lighthouse를 실행한다. 두 도구 모두 2.4.5 위반을 직접 표시하지는 않지만, 이 감사를 활용해 레이블 누락, 잘못된 ARIA 역할, 포커스 관리 문제 등 기본적인 접근성 문제를 가진 탐색 구성 요소(메뉴, 검색 입력, 브레드크럼)를 식별한다. 2.4.5에서 유효한 “방법”으로 인정받을 수 없으므로, 먼저 이러한 문제를 해결해야 한다.
탐색 메커니즘 목록화: 사이트를 수동으로 검토하고, 사용자가 특정 페이지에 도달하기 위해 사용할 수 있는 모든 개별 메커니즘을 나열한다. 상단 탐색 메뉴, 푸터 링크, 사이트 검색, 사이트맵 페이지, 브레드크럼, 관련 콘텐츠 링크, 카테고리 인덱스 등이다. 순차적 프로세스에 속하지 않는 모든 페이지에서 이들 중 최소 두 가지 메커니즘이 존재하고, 기능하며, 사용 가능한지 확인한다.
키보드 전용 탐색 테스트: Tab, Enter, 방향키, Escape 키만 사용하고(마우스 사용 금지), 두 가지 다른 메커니즘을 통해 특정 비-홈 페이지에 도달해 본다. 예를 들어, 검색창을 사용해 상품 페이지를 찾은 다음, 사이트맵이나 탐색 메뉴를 사용해 같은 페이지에 도달한다. 두 경로 모두 마우스 없이 완전히 조작 가능해야 한다.
NVDA + Firefox 스크린 리더 테스트: NVDA를 실행하고 Firefox를 열어 홈 페이지로 이동한다. NVDA의 브라우즈 모드(F6로 랜드마크, H로 제목)를 사용해 검색 랜드마크와 사이트맵 또는 탐색 링크를 찾는다. 두 메커니즘이 올바르게 안내되는지, 폼 필드에 접근 가능한 레이블이 있는지, 결과 또는 대상 페이지가 로드되어 읽을 수 있는지 확인한다.
VoiceOver + Safari(macOS/iOS) 스크린 리더 테스트: VoiceOver(Cmd+F5)를 활성화하고 Rotor(VO+U)를 사용해 페이지의 폼 컨트롤과 링크를 살펴본다. 검색 필드가 목록에 나타나고 레이블이 지정되어 있는지, 사이트맵 또는 대체 인덱스로 이어지는 탐색 링크가 존재하고 조작 가능한지 확인한다.
JAWS + Chrome 스크린 리더 테스트: JAWS 탐색 키(F로 폼으로 이동, Insert+F7로 링크 목록)를 사용해 검색 입력과 사이트맵 링크가 키보드와 가상 커서 모두에서 발견 가능하고 사용 가능한지 확인한다.
순차적 프로세스 예외 확인: 결제, 다단계 폼, 로그인 흐름 등 프로세스의 단계에 해당하는 페이지를 식별한다. 이러한 페이지는 여러 가지 방법 요구 사항을 충족할 필요가 없음을 확인한다. 잘못된 실패를 피하기 위해 접근성 감사에 이를 문서화한다.
검색 결과 기능 검증: 상품명, 기사 제목, 지원 주제 등 대표적인 검색을 여러 번 수행한다. 결과가 나타나는지, 관련성이 있는지, 결과 페이지가 키보드와 스크린 리더로 접근 가능하고 탐색 가능한지 확인한다.

수정 방법

사이트 검색 누락 — 잘못된 예

<!-- Site only has a navigation menu; no search or sitemap provided -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/urunler'>Ürünler</a></li>
    <li><a href='/hakkimizda'>Hakkımızda</a></li>
    <li><a href='/iletisim'>İletişim</a></li>
  </ul>
</nav>
<!-- No search, no sitemap link, no other navigation mechanism -->

사이트 검색 누락 — 올바른 예

<!-- Navigation menu retained, and a site search is added as a second mechanism -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/urunler'>Ürünler</a></li>
    <li><a href='/hakkimizda'>Hakkımızda</a></li>
    <li><a href='/iletisim'>İletişim</a></li>
  </ul>
</nav>

<!-- Second navigation mechanism: accessible site search -->
<form role='search' action='/arama' method='get'>
  <label for='site-search'>Sitede Ara</label>
  <input
    type='search'
    id='site-search'
    name='q'
    placeholder='Ürün veya konu arayın...'
    aria-label='Site genelinde arama'
  />
  <button type='submit'>Ara</button>
</form>

접근 불가능한 사이트맵 — 잘못된 예

<!-- Sitemap link is present but visually hidden and unreachable by keyboard -->
<footer>
  <a href='/site-haritasi' style='display:none;'>Site Haritası</a>
</footer>
<!-- display:none removes the element from both visual display AND
     the accessibility tree, so screen reader users cannot reach it.
     This sitemap cannot count as a valid second navigation mechanism. -->

접근 불가능한 사이트맵 — 올바른 예

<!-- Sitemap link is visible and accessible to all users -->
<footer>
  <nav aria-label='Footer navigation'>
    <ul>
      <li><a href='/site-haritasi'>Site Haritası</a></li>
      <li><a href='/gizlilik'>Gizlilik Politikası</a></li>
      <li><a href='/iletisim'>İletişim</a></li>
    </ul>
  </nav>
</footer>
<!-- The sitemap page itself should list all major sections and pages
     of the site using <nav>, <ul>, and <a> elements. -->

접근 가능한 레이블이 없는 검색 폼 — 잘못된 예

<!-- Search input has no label; screen readers announce only 'edit text' -->
<form action='/search'>
  <input type='text' name='q' placeholder='Search...' />
  <button type='submit'><img src='search-icon.png' /></button>
</form>

접근 가능한 레이블이 없는 검색 폼 — 올바른 예

<!-- role='search' identifies the landmark; label associates text with input;
     submit button has an accessible name via aria-label -->
<form role='search' action='/arama' method='get'>
  <label for='global-search'>Arama</label>
  <input
    type='search'
    id='global-search'
    name='q'
    autocomplete='off'
  />
  <button type='submit' aria-label='Aramayı başlat'>
    <img src='search-icon.png' alt='' aria-hidden='true' />
  </button>
</form>

자주 발생하는 실수

XML 사이트맵을 사용자용 탐색 메커니즘으로 간주하는 경우: 검색 엔진에 제출되는 XML 사이트맵(예: /sitemap.xml)은 기계가 읽을 수 있는 파일이며 일반 방문자가 사용할 수 없다. 사람(사용자)이 탐색할 수 있는 HTML 사이트맵 페이지만이 유효한 두 번째 탐색 메커니즘으로 인정된다.
순전히 장식적이거나 고장 난 검색 폼 제공: 항상 빈 결과만 반환하거나, 제출 시 오류가 발생하거나, 404 페이지로 리디렉션되는 검색 입력은 2.4.5를 충족하지 못한다. 이 메커니즘은 기준을 통과하기 위해 실제로 기능해야 한다.
실패하거나 비활성화된 JavaScript 뒤에 사이트맵 링크를 숨기는 경우: 사이트맵으로 가는 유일한 링크가 동적으로 삽입되는 모달 내부나 특정 환경에서 실패하는 JavaScript 의존 드롭다운 안에만 있는 경우, 해당 JavaScript를 실행할 수 없는 사용자(일부 보조기술 구성 포함)는 그 탐색 메커니즘에 접근할 수 없게 된다.
모바일 뷰포트에서 탐색 메커니즘에 display:none 또는 visibility:hidden 적용: 모바일 레이아웃에서 검색창이나 사이트맵 링크를 완전히 숨기면 모바일 사용자에게서 해당 메커니즘이 완전히 사라지므로 실패에 해당한다 — 데스크톱 레이아웃이 통과하더라도 마찬가지다. 접근 가능한 토글 버튼 뒤에 메커니즘을 접어 두는 것은 허용되지만, DOM이나 접근성 트리에서 제거하는 것은 허용되지 않는다.
추가 지원 없이 브레드크럼을 독립적인 두 번째 메커니즘으로 취급하는 경우: 브레드크럼은 현재 페이지로 가는 경로만 보여 줄 뿐이며, 사용자가 사이트의 임의의 페이지를 발견하고 탐색하는 데 독립적으로 충분하지 않다. 다른 메커니즘을 보완할 수는 있지만, 일반적으로 두 개 요구되는 메커니즘 중 하나로 단독 사용될 수는 없다.
요구 사항에서 페이지를 잘못 예외 처리하는 경우: 순차적 프로세스 예외는 결제 4단계 중 2단계와 같이 실제로 프로세스의 단계인 페이지에만 적용된다. 카테고리 페이지, 상품 상세 페이지, 블로그 글은 사용자가 퍼널을 통해 도달했더라도 예외가 아니다.
type='text'인 검색 입력을 사용하고 폼에 role='search'를 생략하는 경우: 이는 직접적인 2.4.5 위반은 아니지만, 랜드마크를 기준으로 탐색하는 스크린 리더 사용자가 검색 영역을 찾지 못하게 만든다. 메커니즘이 기술적으로는 존재하지만 실질적으로 발견하기 어려워져, 이 기준의 의도를 훼손한다.
사실상 동일한 두 메커니즘 제공: 링크와 구조가 완전히 동일한 상단 탐색 메뉴와 푸터 탐색 메뉴는 의미 있게 다른 두 탐색 메커니즘으로 간주되지 않는다. 의도는 동일한 전략을 페이지에 두 번 반복하는 것이 아니라, 서로 다른 필요를 가진 사용자가 대체 전략을 찾을 수 있도록 하는 것이다.
특정 페이지 유형을 탐색 시스템에서 제외하는 경우: 일부 CMS 구성은 블로그 글, 법률 관련 페이지, 사용자 계정 페이지를 기본 사이트맵이나 검색 인덱스 밖에 두기도 한다. 사용자가 최소 두 가지 메커니즘을 통해 이러한 페이지를 찾을 수 없다면, 사이트의 나머지 구조가 아무리 잘 되어 있어도 해당 페이지는 2.4.5를 위반한 것이다.
보조기술로 메커니즘을 테스트하지 않는 경우: 2.4.5는 수동 테스트를 요구하기 때문에, 자동 도구에만 의존하는 팀은 검색 폼의 키보드 트랩, 레이블 없는 입력, DOM에는 존재하지만 스크린 리더 랜드마크 탐색으로는 도달할 수 없는 사이트맵 등으로 인한 실패를 놓치게 된다.

터키 접근성 규정과의 관계

2025년 6월 21일 관보(Resmî Gazete) 제 32933호에 게재된 터키 대통령령 2025/10호는 광범위한 공공 및 민간 부문 기관에 대해 구속력 있는 웹 접근성 의무를 수립한다. 이 대통령령은 국제적으로 인정된 접근성 표준 준수를 의무화하며, WCAG 2.1 및 WCAG 2.2 레벨 AA를 기본 기대 수준으로 삼아 터키의 법적 요구 사항을 이에 맞추고 있다.

WCAG 2.4.5 — Multiple Ways는 레벨 AA 기준이므로, 대통령령이 요구하는 준수 수준에 정확히 포함된다. 규제 대상 기관은 이 기준에서 설명하는 대로, 집합에 속한 모든 웹 페이지가 최소 두 가지 탐색 메커니즘을 제공하도록 보장해야 한다. 이 요구 사항을 충족하지 못하는 것은 규제 명령에 대한 직접적인 비준수에 해당한다.

대통령령 2025/10호의 적용 대상에는 모든 수준의 공공 기관 및 정부 기관, 은행 및 금융 기관, 병원 및 의료 서비스 제공자, 전자상거래 플랫폼, 200,000명 이상의 가입자를 보유한 통신 사업자, 여행사, 민간 운송 회사, 그리고 교육부(Millî Eğitim Bakanlığı, MEB)의 인가를 받아 운영되는 사립 학교가 포함된다. 이러한 각 기관 유형은 자사의 웹 자산 전반에 걸쳐 접근 가능하고 다중 경로 탐색을 유지해야 한다.

의무적인 준수 요구 사항 외에도, 가족·사회서비스부(Aile ve Sosyal Hizmetler Bakanlığı)는 우수한 접근성 관행을 보여주는 기관에 Erişilebilirlik Logosu(접근성 로고)를 부여한다. 이 로고를 획득하려면 2.4.5 준수를 포함한 레벨 AA 전체 준수가 필요하다. 터키의 경쟁적인 디지털 시장에서 운영되는 기업 — 특히 전자상거래 플랫폼, 은행, 의료 서비스 제공자 — 에게 접근성 로고는 장애가 있는 사용자에게 신뢰의 신호이자 규제 준수 의지를 보여주는 증거 역할을 한다.

실질적으로, 다양한 사용자 집단을 대상으로 하는 터키 웹사이트는 여러 탐색 메커니즘을 구현함으로써 큰 이점을 얻는다. 터키에는 고령 인터넷 사용자와 디지털 문해력이 낮은 지역의 사용자가 많이 있으며, 이들 모두는 2.4.5가 요구하는 중복성으로부터 혜택을 본다. 터키어 특수 문자(ı, İ, ş, ğ, ü, ö, ç 등)를 올바르게 처리하는 터키어 지원 사이트 검색과 명확하게 구조화된 HTML 사이트맵을 결합하는 것은 이 사용자층에 잘 부합하는, 접근 가능하고 규정을 준수하는 구현 방식이다. Erişilebilirlik Logosu를 획득하거나 유지하려는 조직은 2.4.5 준수를 선택적 개선이 아니라 접근성 프로그램의 기초 요구 사항으로 간주해야 한다.