링크 텍스트 - by. UXKM

  • A11Y
  • A11y Creation Tech
  • 모바일 접근성 제작 기법
  • 링크 텍스트
요약 설명

관련 지침(쉬운 내비게이션) : 링크 텍스트만으로도 이동 목적이나 용도를 이해할 수 있는가?
‘여기’, ‘더보기’만 반복되면 보조 기술 사용자는 링크 목록에서 구분할 수 없습니다. 동작 결과가 드러나는 이름을 씁니다.

모바일 앱 접근성 체크리스트(MACAG) 전체 보기
WCAG 2.2 — Link Purpose (In Context)

필요성

하이브리드 앱의 인앱 브라우저, 딥링크, 텍스트 내 링크는 모두 목적이 분명해야 합니다. 같은 문구라도 맥락 없이 연속되면 사용자는 잘못된 화면으로 이동할 수 있습니다.

대상

  • 스크린 리더 사용자

    링크만 모아 읽는 로터/목록에서 구분해야 하는 사용자.

  • 음성 제어 사용자

    보이는 레이블과 음성 명령이 맞아야 하는 사용자.

  • 저시력 사용자

    주변 문맥 없이 색만으로 링크를 찾기 어려운 사용자.

  • 콘텐츠 운영자

    딥링크·푸시 알림 문구와 화면 내 버튼 이름이 일치해야 혼선이 줄어듭니다.

체크리스트

  • 중복 문구

    ‘자세히 보기’가 연속될 때 각각 다른 목적지인가? (앞뒤 문장으로 구별 가능한가?)

  • 아이콘 링크

    아이콘만 있을 때 접근 가능한 이름에 행동+대상이 포함되는가?

  • 외부 앱

    ‘열기’, ‘공유’ 등 OS 시트에 나오는 이름이 실제 서비스명과 연결되는가?

  • WebView

    앵커 텍스트가 DOM 순서와 함께 읽혀도 목적이 유지되는가?

구현 시 참고

  • 네이티브 버튼을 링크처럼 쓸 때도 accessibilityHint보다 이름에 목적을 담는 것을 우선합니다.
  • 아이콘만 링크인 경우 대체 이름에 ‘무엇으로 이동’인지 포함합니다.
  • 동일 화면 내 앵커 이동은 현재 위치와 이동 후 섹션을 음성으로 구분할 수 있게 합니다.

점검 방법

  • 스크린 리더의 링크/버튼 요약 목록만으로 원하는 화면을 고를 수 있는지 테스트합니다.
  • 동일한 문자열 링크가 한 화면에 여럿 있을 때 앞 문장만으로 구별되는지 확인합니다.

개발방법

아래 코드는 링크 텍스트 검사항목을 실제 UI 동작에 반영할 때 참고할 수 있는 예시입니다. 링크 텍스트만 읽어도 이동 대상과 결과를 예측할 수 있는 표현을 사용합니다.

네이티브

iOS (Swift)

Android

하이브리드

html

Vue

React

접근성 테스트 도구 활용 점검방법

결론

접근성은 시작은 있지만 끝이 없는 작업입니다.
오류 항목을 정기적으로 점검하여 접근성 개선을 한다면 점차 검사를 할 항목이 줄어들게 될 것입니다. 모두가 차별 없이 서비스를 이용할 수 있도록 접근성 유지를 위한 모두의 노력이 필요합니다. 무엇보다 접근성 작업은 서비스를 제공한다면 선택이 아닌 필수로 지켜야하는 항목임을 잊지 말아야 합니다.

접근성 작업 시 점검 필수사항

  • 접근성 가이드(WCAG, KWCAG, WAI-ARIA) 내용 숙지
  • 접근성 체크리스트 작성
  • 접근성 자동 및 수동 검사(스크린리더) 진행
  • 접근성 검사 툴(Lighthouse Accessibility 등) 활용 오류 항목 개선 및 내용 정리
  • 접근성 사용자 테스트
  • 접근성 정기적인 모니터링