‘더보기’ 링크의 목적은 언제 충분하고 언제 모호한가

웹 서핑 중 뉴스 기사 목록이나 쇼핑몰 상품 리스트, 블로그 피드를 탐색할 때 '더보기', '자세히 보기', '바로가기'라는 단독 텍스트로만 구성된 링크를 마주치는 일은 일상다반사입니다. 화면을 눈으로 보면서 이전 기사 제목이나 상품 사진을 함께 인지할 수 있는 시각 중심 사용자에게는 '더보기'라는 두 글자만으로도 해당 카드의 상세 페이지로 이동한다는 사실이 직관적으로 이해됩니다. 그러나 화면을 볼 수 없어 스크린리더를 사용하는 시각장애인에게 이러한 모호한 링크는 웹 탐색의 흐름을 완전히 마비시키는 거대한 장벽입니다. 특히 시각장애인이 웹페이지의 링크만 빠르게 훑어보기 위해 보조공학의 '링크 목록 다이얼로그(Links List Dialog)'를 열었을 때, 화면에 똑같은 '더보기' 링크 30개가 연달아 나열되는 절망적인 경험을 하게 됩니다. 이 글에서는 WCAG 2.2 성공 기준 2.4.4(Link Purpose in Context)의 본질을 분석하고, 시각적 간결함과 완벽한 접근성을 양립시키는 실무 링크 설계 패턴을 다룹니다.

스크린리더 링크 목록 다이얼로그에서 발생하는 '더보기 30개' 참사

비장애인 사용자가 웹페이지를 위에서부터 아래로 훑어보며 링크를 클릭하듯이, 스크린리더(NVDA의 Insert+F7, VoiceOver의 Rotor Links) 사용자 역시 원하는 정보로 즉시 이동하기 위해 페이지 내의 모든 하이퍼링크만 알파벳순이나 나타난 순서대로 모아둔 '링크 목록 창'을 애용합니다.

이 다이얼로그에서 링크 텍스트가 '2026 웹 접근성 개정안 전문'처럼 명확하게 작성되어 있다면, 사용자는 첫 단어만 듣고도 원하는 링크를 찾아 Enter 키를 눌러 즉시 이동할 수 있습니다. 그러나 모든 링크가 단순히 '더보기', '자세히 보기', 'Click Here'로만 되어 있다면, 스크린리더는 '더보기 1/30', '더보기 2/30', '더보기 3/30'을 끝없이 반복해서 낭독합니다. 사용자는 각 더보기가 1번 기사의 더보기인지, 5번 공지사항의 더보기인지 구별할 수 없어 결국 다이얼로그를 닫고 본문 전체를 1행씩 무식하게 읽어 내려가야 하는 막대한 시간 낭비를 겪습니다.

WCAG 2.2 SC 2.4.4(A 레벨) vs SC 2.4.9(AAA 레벨)의 명확한 차이

W3C 가이드라인은 링크 목적 전달력에 대해 두 가지 성공 기준을 제시하고 있습니다.

• WCAG 2.2 SC 2.4.4 (Link Purpose in Context, Level A): 링크의 목적은 '링크 텍스트 자체'만으로 이해되거나, 혹은 '프로그래밍적으로 결정 가능한 맥락(Programmatically Determined Context)'과 결합했을 때 사용자가 충분히 이해할 수 있어야 합니다. 즉, 동일한 문단(<p>), 리스트 항목(<li>), 테이블 셀(<td>) 내부에서 앞서 언급된 제목 문맥이 명확하다면 최소 기준을 충족합니다.
• WCAG 2.2 SC 2.4.9 (Link Purpose Link Only, Level AAA): 주변 문맥의 도움 없이 오직 '링크 텍스트 자체(Link Text Alone)'만 떼어놓고 보더라도 링크의 목적이 100% 명확하게 파악될 수 있어야 합니다. 링크 목록 다이얼로그에서도 완벽한 독립적 가치를 지니는 최상위 수준의 접근성입니다.

맥락 속 링크 목적을 보완하는 3가지 실무 마크업 기법

디자이너의 시각적 미니멀리즘 요구를 수용하면서도 스크린리더 사용자에게 완벽한 독립적 링크 목적을 제공하는 3가지 실무 해결책을 상황에 맞게 적용해야 합니다.

첫 번째 기법은 '접근성 전용 숨김 텍스트(.sr-only) 병기'입니다. <a href='/notice/12'>더보기 <span class='sr-only'>- 2026년 하반기 웹 접근성 실태조사 공지사항</span></a> 형태로 마크업합니다. 시각적으로는 '더보기'만 깔끔하게 보이지만, 스크린리더는 뒤의 숨김 텍스트까지 온전히 낭독하므로 링크 목록 창에서도 어떤 공지사항인지 명확하게 식별됩니다.

두 번째 기법은 'aria-label 속성을 통한 전체 레이블 재정의'입니다. <a href='/notice/12' aria-label='2026년 하반기 웹 접근성 실태조사 공지사항 자세히 보기'>더보기</a> 형태로 부여합니다. 이 방식은 코드가 매우 간결해지며, 시각적 텍스트를 완전히 덮어쓰고 aria-label의 내용만을 스크린리더에 전달합니다.

세 번째 기법은 'aria-labelledby를 활용한 제목 ID 참조'입니다. 기사 카드 상단의 제목에 id='article-title-1'을 주고, 하단 더보기 버튼에 <a href='...' aria-labelledby='article-title-1 this-link-id' id='this-link-id'>더보기</a>를 연결하여 제목과 더보기를 자연스럽게 결합하여 낭독시키는 고급 기법입니다.

색상에만 의존하는 링크 식별의 2차 위험성(WCAG 1.4.1)

링크 텍스트의 문구뿐만 아니라, 링크 요소의 시각적 표현 방식에서도 중대한 접근성 결함이 자주 발생합니다. 본문 텍스트 중에서 하이퍼링크가 걸린 부분을 오직 '파란색' 글씨로만 구분하고 밑줄(Underline)이나 아이콘 등의 비색상 단서를 완전히 제거하는 실수(SC 1.4.1 Use of Color)입니다.

적록 색약이나 전색맹 사용자는 파란색 텍스트와 일반 검은색 텍스트를 거의 구분하지 못합니다. 따라서 본문 내부의 인라인 링크에는 항상 text-decoration: underline을 기본 스타일로 유지하거나, 링크 전후에 명확한 식별 기호나 아이콘을 배치해야 합니다. 밑줄을 제거하더라도 최소한 주변 본문 텍스트와 3:1 이상의 명암비를 확보하고 마우스 호버 및 키보드 포커스 시 밑줄이 나타나도록 구현하는 것이 접근성 표준의 엄격한 요구조건입니다.

WCAG 2.2 SC 2.4.4(문맥 포함)와 SC 2.4.9(링크만)의 엄격한 판정 차이

WCAG 2.2 표준에서 링크의 목적을 정의하는 기준은 적합성 수준에 따라 두 단계로 나뉩니다. SC 2.4.4(Level A)는 동일 문단이나 부모 테이블 셀 등 DOM 문맥에서 유추할 수 있으면 통과합니다. 반면 SC 2.4.9(Level AAA)는 주변 문맥 없이 오직 링크 텍스트 단독으로 목적지가 식별되어야 합니다.

실무에서는 Level AAA에 준하는 설계를 권장합니다. 그 이유는 NVDA, JAWS, VoiceOver 등 모든 스크린리더가 제공하는 링크 목록 대화상자(Insert+F7) 때문입니다. 링크 목록 창에는 본문 문맥이 모두 제거되고 순수 링크 텍스트만 나열되므로, 더보기가 수십 개 반복되면 탐색이 불가능해집니다.

• Level A (SC 2.4.4): 문맥(부모 문단, 헤딩, 테이블 행)을 통해 목적 유추 가능 시 인정
• Level AAA (SC 2.4.9): 링크 텍스트 단독으로 목적지 식별 필수
• 보조공학 링크 목록(Links List): 문맥이 거세된 상태에서 알파벳순으로 정렬되므로 고유한 텍스트 식별성이 핵심 사용성 좌우

디자인을 훼손하지 않는 sr-only 문맥 확장과 aria-describedby 비교 분석

카드 뉴스나 피드 목록에서 시각적 간결함을 유지하면서 보조공학에 완전한 정보를 제공하는 가장 우수한 방법은 .sr-only 클래스를 활용한 인라인 텍스트 확장입니다.

aria-describedby를 사용하는 방식도 가능하지만, 스크린리더가 링크 이름을 읽은 뒤 잠시 멈추고 부가 설명으로 읽어주기 때문에 일부 환경에서 낭독이 누락될 수 있습니다. 반면 .sr-only 텍스트는 accessible name 자체에 직접 결합되어 어떤 보조공학에서도 단절 없이 온전한 문장으로 읽어줍니다.

• 시각적 텍스트: "더보기" (깔끔한 카드 UI 유지)
• 스크린리더 확장: <span class="sr-only">: 2026년 웹 접근성 표준 개정 주요 내용 상세 기사 읽기</span> 삽입
• 접근성 트리 결과: "더보기: 2026년 웹 접근성 표준 개정 주요 내용 상세 기사 읽기, 링크"로 완벽한 목적 단일 산출