WCAG 2.4.4: 링크 목적 (문맥상)

WCAG 2.4.4는 모든 링크의 목적이 링크 텍스트만으로, 또는 링크 텍스트와 그 주변 문맥을 함께 보았을 때 파악될 수 있어야 한다고 요구합니다. 이는 스크린 리더 사용자, 키보드만 사용하는 사용자, 인지 장애가 있는 사람이 링크를 실제로 따라가 보지 않고도 그 링크가 어디로 연결되는지 이해할 수 있도록 보장합니다.

이 규칙의 의미

WCAG 2.4.4 — 링크 목적(맥락 안에서) — 은 Operable 원칙 아래의 레벨 A 성공 기준이다. 이 기준은 각 링크의 목적이 링크 텍스트만으로, 또는 링크 텍스트와 그 링크의 프로그램적으로 결정 가능한 링크 맥락을 결합했을 때 파악 가능해야 한다고 규정한다. 둘 중 어느 것도 충분하지 않다면, 해당 링크는 이 기준을 충족하지 못한 것이다.

"프로그램적으로 결정 가능한 링크 맥락"이라는 표현은 WCAG에서 엄밀하게 정의된다. 이는 링크와 같은 문장, 단락, 목록 항목, 또는 표 셀에서 파생될 수 있는 정보나, 링크를 포함하는 구역 앞에 오는 제목에서 파생될 수 있는 정보를 의미한다. 또한 aria-labelledby나 aria-describedby와 같은 ARIA 관계를 통해 노출되는 맥락도 포함한다. 중요한 점은 이 맥락이 프로그램적으로 이용 가능해야 한다는 것 — 즉, 보조 기술이 자동으로 읽을 수 있어야 한다는 것이며, 시각 사용자에게만 시각적으로 암시되는 것에 그쳐서는 안 된다.

실무적으로 이 기준의 직접적인 영향을 받는 HTML 요소와 속성은 다음과 같다: <a href> 앵커 요소, 이미지 맵의 <area> 요소, 내비게이션을 트리거하는 <button> 요소, role='link'와 같은 ARIA 역할을 사용해 링크처럼 동작하도록 스타일링되거나 스크립트 처리된 요소, 그리고 SVG의 <a> 요소. 링크의 접근 가능한 이름 — 내부 텍스트, aria-label, aria-labelledby, 또는 자식 이미지의 alt 속성으로부터 계산되는 값 — 이 목적을 전달하는 주요 수단이다.

통과로 인정되는 경우: 사용자가 추가적인 맥락 없이도 링크의 목적지나 기능을 파악할 수 있는 경우(예: "2024 연례 보고서를 PDF로 다운로드"), 또는 주변의 프로그램적 맥락이 목적을 명확히 해 주는 경우(예: 기사 제목으로 시작하는 <li> 안의 "Read more" 링크) 링크는 통과한다. 링크 텍스트가 페이지 전체에서 전역적으로 고유할 필요는 없으며, 자신의 맥락 안에서만 모호하지 않으면 된다.

실패로 인정되는 경우: "click here", "read more", "here", "more", "link"와 같은 일반적인 링크 텍스트는 주변의 프로그램적 맥락이 목적지를 명확히 구분해 주지 못할 때 실패로 간주된다. alt 속성이 없거나 비어 있는 이미지 링크 역시 접근 가능한 이름이 전혀 존재하지 않기 때문에 실패한다.

공식 예외: WCAG는 한 가지 예외를 인정한다. 링크 목적이 의도적으로 모호한 경우 — 즉, 목적을 사전에 알리는 것이 링크 자체나 주변 콘텐츠의 효용을 훼손하는 경우 — 이 기준은 적용되지 않는다. 이 예외는 매우 범위가 좁으며 실제 환경에서 적용되는 경우는 드물다.

왜 중요한가

세계보건기구에 따르면 전 세계적으로 약 22억 명이 어떤 형태로든 시각 장애를 가지고 있다. 이들 중 스크린 리더에 의존하는 시각장애인 사용자는 모호한 링크 텍스트의 영향을 가장 크게 받는다. NVDA, JAWS, VoiceOver와 같은 스크린 리더 소프트웨어는 맥락에서 추출한 모든 링크의 목록을 생성해 페이지를 탐색할 수 있게 한다. 이 목록에 "read more"나 "click here"라는 항목이 수십 개 연속으로 나타난다면, 시각장애인 사용자는 각 링크가 어디로 연결되는지 알 수 없으며, 각 링크로 다시 돌아가 주변 콘텐츠를 읽어야만 하는데 — 이는 시간도 오래 걸리고 방향 감각을 잃기 쉬운 과정이다.

키보드만으로 입력하거나 스위치 제어, 시선 추적 장치로 탐색하는 운동 장애 사용자에게도 이 기준은 큰 도움이 된다. 이들은 대개 인터랙티브 요소를 순차적으로 Tab 키로 이동하며, 포커스된 요소의 레이블에 의존해 활성화 여부를 결정한다. 모호한 링크 텍스트는 추가적인 탐색 단계를 강요해 피로도와 오류율을 높인다.

주의력 결핍, 기억력 손상, 낮은 문해력 등 인지 장애가 있는 사용자 역시 명확하고 설명적인 링크 텍스트로부터 이득을 본다. 이는 페이지 구조를 이해하는 데 필요한 인지 부하를 줄여 주기 때문이다. 이들은 링크를 훑어보는 동안 맥락 정보를 작업 기억에 유지할 필요가 없다.

구체적인 실제 시나리오: 동일한 방식으로 렌더링된 "Buy Now" 버튼과 "Learn More" 링크가 각각 있는 10개의 상품을 보여주는 전자상거래 상품 목록 페이지를 생각해 보자. 링크 목록으로 탐색하는 시각장애인 사용자는 어떤 링크가 어떤 상품을 가리키는지에 대한 정보 없이 "Learn More"라는 항목을 10번 연속해서 듣게 된다. 올바른 상품을 구매하려면 각 링크에 대해 주변 맥락 전체를 읽어야 하며 — 이 과정은 몇 초가 아니라 몇 분이 걸릴 수 있다. "Learn more about the Sony WH-1000XM5 Headphones"와 같이 설명적인 링크 텍스트를 사용하면, 동일한 작업을 단 한 번의 탐색 제스처로 수행할 수 있다.

접근성을 넘어, 설명적인 링크 텍스트는 측정 가능한 SEO 이점도 제공한다. 검색 엔진 크롤러는 앵커 텍스트를 사용해 링크된 페이지의 콘텐츠를 이해하는 신호로 활용한다. 설명적이고 키워드가 풍부한 링크 텍스트는 링크된 리소스의 크롤링 및 인덱싱 가능성을 개선해 검색 순위에 긍정적으로 기여한다. 또한 명확한 링크 텍스트는 사용자가 이동하기 전에 기대치를 정확히 설정해 이탈률과 지원 요청을 줄여 준다.

테스트 방법

axe DevTools 또는 Lighthouse를 사용한 자동 스캔: axe DevTools 브라우저 확장(Chrome 또는 Firefox)을 설치하거나 Chrome DevTools에서 Lighthouse 접근성 감사를 실행한다. 전체 페이지 스캔을 실행하고 link-name 및 duplicate-id-aria 규칙으로 결과를 필터링한다. 표시된 각 요소를 검토하여 link-name 위반의 경우 계산된 접근 가능한 이름이 없거나 비어 있는지 확인하고, duplicate-id-aria 위반의 경우 중복 ID가 ARIA 레이블 참조를 깨뜨리고 있는지 검증한다. 이러한 자동 검사에 통과하더라도 2.4.4를 완전히 준수했다는 의미는 아니므로, 수동 단계로 진행해야 한다.
수동 링크 목록 검토: Firefox에서 NVDA를 사용할 때 Insert+F7 키 조합을 눌러 요소 목록 대화 상자를 열고 "Links"를 선택한다. 시각적 맥락 없이 목록의 각 항목을 개별적으로 검토한다. 각 링크 텍스트만으로 어디로 연결되는지 알 수 있는지 자문해 보라. Chrome에서 JAWS를 사용할 때도 Insert+F7로 링크 목록을 열어 동일하게 반복한다. macOS의 Safari에서 VoiceOver를 사용할 때는 Control+Option+U를 눌러 Web Item Rotor를 열고 "Links"를 선택한다. 목적이 고립된 상태에서 모호한 모든 링크는 프로그램적 맥락에 비추어 검토해야 한다.
키보드 내비게이션 테스트: Tab 키만 사용해 페이지의 모든 인터랙티브 요소를 탐색한다. 포커스가 링크에 도달할 때마다 주변 시각 콘텐츠는 보지 말고, 발표되는 텍스트만 읽는다. 발표되는 내용만으로 링크의 목적지를 파악할 수 없다면, 해당 링크는 2.4.4를 위반했을 가능성이 크다. 아이콘만 있는 링크(소셜 미디어 아이콘, 화살표 버튼)와 이미지 링크에 특히 주의를 기울인다.
맥락 검증: 주변 맥락에 의존하는 링크(예: 목록 항목 안의 "Read more")에 대해서는, 링크와 맥락 텍스트가 동일한 문장, 단락, 목록 항목, 또는 표 셀 안에 있는지 DOM을 검사해 확인한다. 시각적으로만 인접해 있고 프로그램적으로 연관되어 있지 않은 맥락은 이 기준을 충족하지 못한다. 브라우저 DevTools를 사용해 계산된 접근성 트리를 검사하고 관계를 확인한다.
ARIA 레이블 감사: 페이지 소스 코드에서 링크 요소에 사용된 모든 aria-labelledby 및 aria-describedby를 검색한다. 참조된 각 ID가 문서 내에 정확히 한 번만 존재하는지, 그리고 참조된 요소가 의도한 설명 텍스트를 포함하는지 확인한다. Chrome DevTools의 Accessibility 탭에서 제공되는 접근성 트리 패널을 사용해 각 링크의 계산된 이름을 확인한다.

수정 방법

접근 가능한 이름이 없는 아이콘 전용 링크 — 잘못된 예

<!-- An icon link with no text and no aria-label -->
<a href='https://twitter.com/accsible'>
  <svg viewBox='0 0 24 24' width='24' height='24'>
    <path d='M23 3a10.9 10.9...' />
  </svg>
</a>

접근 가능한 이름이 없는 아이콘 전용 링크 — 올바른 예

<!-- aria-label provides a descriptive accessible name for screen readers -->
<a href='https://twitter.com/accsible' aria-label='Accsible on Twitter'>
  <svg viewBox='0 0 24 24' width='24' height='24' aria-hidden='true' focusable='false'>
    <path d='M23 3a10.9 10.9...' />
  </svg>
</a>

카드 목록에서의 일반적인 "Read more" 링크 — 잘못된 예

<!-- Multiple identical link texts with no distinguishing context -->
<ul>
  <li>
    <h3>Istanbul Accessibility Summit 2024</h3>
    <p>Join us for the annual summit on digital inclusion.</p>
    <a href='/events/istanbul-2024'>Read more</a>
  </li>
  <li>
    <h3>New WCAG 2.2 Guidelines Released</h3>
    <p>W3C has published the updated guidelines.</p>
    <a href='/news/wcag-22'>Read more</a>
  </li>
</ul>

카드 목록에서의 일반적인 "Read more" 링크 — 올바른 예

<!-- Option 1: Visually hidden text appended to the link -->
<ul>
  <li>
    <h3>Istanbul Accessibility Summit 2024</h3>
    <p>Join us for the annual summit on digital inclusion.</p>
    <a href='/events/istanbul-2024'>
      Read more
      <span class='sr-only'>about the Istanbul Accessibility Summit 2024</span>
    </a>
  </li>
  <li>
    <h3>New WCAG 2.2 Guidelines Released</h3>
    <p>W3C has published the updated guidelines.</p>
    <a href='/news/wcag-22'>
      Read more
      <span class='sr-only'>about the New WCAG 2.2 Guidelines</span>
    </a>
  </li>
</ul>

<!-- Option 2: Use aria-label to override the visible text entirely -->
<a href='/events/istanbul-2024' aria-label='Read more about the Istanbul Accessibility Summit 2024'>
  Read more
</a>

빈 alt 속성을 가진 이미지 링크 — 잘못된 예

<!-- The image has an empty alt, making the link completely unnamed -->
<a href='/products/overlay-widget'>
  <img src='widget-logo.png' alt='' />
</a>

빈 alt 속성을 가진 이미지 링크 — 올바른 예

<!-- The alt attribute on the image provides the link's accessible name -->
<a href='/products/overlay-widget'>
  <img src='widget-logo.png' alt='Accsible Overlay Widget — product details' />
</a>

중복 ID를 참조하는 aria-labelledby — 잘못된 예

<!-- Two elements share the same ID; the second link resolves to the wrong label -->
<div>
  <span id='card-title'>Accsible SDK Documentation</span>
  <a href='/docs' aria-labelledby='card-title'>View</a>
</div>
<div>
  <span id='card-title'>Accsible Pricing Plans</span>
  <a href='/pricing' aria-labelledby='card-title'>View</a>
</div>

중복 ID를 참조하는 aria-labelledby — 올바른 예

<!-- Each ID is unique; each link resolves to the correct label -->
<div>
  <span id='card-title-docs'>Accsible SDK Documentation</span>
  <a href='/docs' aria-labelledby='card-title-docs'>View</a>
</div>
<div>
  <span id='card-title-pricing'>Accsible Pricing Plans</span>
  <a href='/pricing' aria-labelledby='card-title-pricing'>View</a>
</div>

자주 발생하는 실수

스크린 리더가 시각적 맥락에서 분리해 추출했을 때 의미가 없어지는 "click here", "here", "more", "read more"와 같은 링크 텍스트를, aria-label, aria-labelledby, 또는 시각적으로 숨겨진 <span> 요소를 통한 추가 접근 가능한 이름 없이 사용하는 경우.
링크에 aria-label을 추가하면서, 레이블이 눈에 보이는 텍스트 문자열로 시작하도록 보장하지 않는 경우 — 이는 WCAG 2.5.3(레이블과 이름)을 위반하며, 음성 명령으로 보이는 이름을 말해 링크를 활성화하려는 음성 제어 사용자에게 혼란을 준다.
링크의 유일한 콘텐츠인 이미지에 alt=''를 설정해 링크의 계산된 접근 가능한 이름을 비워 link-name 위반을 유발하는 경우 — 빈 alt는 장식용 이미지에는 적절하지만, 이미지가 인터랙티브 요소의 유일한 콘텐츠일 때는 적절하지 않다.
링크 안의 유일한 텍스트 노드에 aria-hidden='true'를 적용해 접근성 트리에서 접근 가능한 이름을 제거하고, 스크린 리더 사용자에게 링크를 이름 없는 상태로 남기는 경우.
서로 다른 링크에서 aria-labelledby로 참조되는 여러 요소에 동일한 id 값을 재사용해, 브라우저의 예측 불가능한 ID 해석 때문에 스크린 리더가 하나 이상의 링크에 대해 잘못된 접근 가능한 이름을 계산하게 만드는 경우.
전체 카드 컴포넌트(제목, 이미지, 단락, 버튼)를 하나의 <a> 태그로 감싸, 스크린 리더가 카드 전체 콘텐츠를 링크의 접근 가능한 이름으로 읽게 만드는 경우 — 이는 장황하고 방향 감각을 잃기 쉬운 경험을 초래하며, 간결하고 설명적인 레이블을 사용하는 것이 바람직하다.
링크 맥락을 제공하기 위해 CSS title 속성 툴팁이나 :hover 의사 클래스를 단독으로 사용하는 경우 — title 속성은 스크린 리더에서 일관되게 노출되지 않으며, hover 상태를 트리거할 수 없는 키보드 전용 사용자에게는 완전히 접근 불가능하다.
URL 자체를 링크 텍스트로 사용하는 경우(예: <a href='https://example.com/p?id=12345'>https://example.com/p?id=12345</a>) — 이는 스크린 리더가 발음하기 어렵고 인지 장애가 있는 사용자에게 의미가 없다.
JavaScript 프레임워크로 링크 ID나 ARIA 속성 값을 동적으로 생성하면서 고유성을 보장하지 않는 경우 — React, Vue, Angular로 렌더링된 목록 컴포넌트는 명시적인 key 전략이 구현되지 않으면 중복 ID를 자주 생성한다.
Internet Explorer와 구형 Edge 버전에서 링크 안의 인라인 SVG 아이콘에 focusable='false'를 추가하는 것을 잊어, SVG가 자체 탭 정지를 가지게 하고 스크린 리더가 링크 텍스트와 별도로 SVG를 발표하게 만들어 접근 가능한 이름 계산을 분리시키는 경우.

터키 접근성 규정과의 관계

2025년 6월 21일 관보 제32933호에 게재된 터키 대통령령 2025/10은 WCAG 2.2와 정렬된 의무적 디지털 접근성 요구 사항을 수립한다. WCAG 2.4.4 링크 목적(맥락 안에서)은 레벨 A 기준으로, 이는 해당 기준이 모든 적용 대상 기관이 달성해야 하는 의무적 기본선에 포함된다는 의미다.

이 대통령령은 공공 및 민간 부문 전반에 걸친 특정 유형의 기관에 적용된다. 부처, 국가 기관, 지방자치단체, 공립 대학을 포함한 공공 기관은 대통령령 공포 후 1년 이내에 레벨 A 전면 준수에 도달해야 한다. 대통령령의 적용을 받는 민간 부문 기관은 2년의 준수 기간을 가진다. 민간 부문 범위는 광범위하며, 전자상거래 플랫폼, 은행 및 금융 기관, 민간 병원 및 의료 제공자, 가입자 200,000명 이상인 통신 사업자, 여행사, 민간 운송 회사, 그리고 교육부가 인가한 민간 학교를 명시적으로 포함한다.

이들 모든 기관에 대해, 기준을 충족하지 못하는 링크 텍스트는 직접적인 규제 위반을 의미한다. 예를 들어, 상품 목록 페이지에 프로그램적 맥락 없이 반복되는 "Satın Al"(Buy Now) 또는 "Devamını Oku"(Read More) 링크를 표시하는 터키의 전자상거래 플랫폼을 생각해 보자. TalkBack, NVDA, VoiceOver에 의존하는 시각장애인 사용자는 각 링크가 어떤 상품을 가리키는지 파악할 수 없으며, 이는 2.4.4 실패이자 대통령령 요구 사항 위반에 해당한다. 마찬가지로, 접근 가능한 이름 없이 아이콘 전용 내비게이션 링크를 사용하는 공립 병원의 예약 포털은 link-name axe 규칙과 대통령령의 의무를 모두 위반하게 된다.

2.4.4 준수는 단순한 기술적 체크박스가 아니다. 이 대통령령은 약 850만 명의 장애인을 가진 터키 시민을 위한 디지털 포용에 대한 정부의 보다 광범위한 의지를 보여 준다. 적용 대상 기관에게 링크 목적 실패를 선제적으로 해결하는 것 — 디자인 시스템 표준, 개발자 교육, 자동화된 CI/CD 스캐닝을 통해 — 은 법적 의무이자 사용성과 검색 성능 측면에서 건전한 투자다. 지정된 기한 내에 준수하지 못할 경우, 대통령령에 따라 지정된 관련 감독 기관의 규제 조치를 받을 수 있다.