대체 텍스트 - by. UXKM

요약 설명

관련 지침 : 텍스트가 아닌 콘텐츠는 대체 가능한 텍스트와 함께 제공되어야 한다.
대체 텍스트는 비 텍스트 콘텐츠를 설명하는 중요한 요소로, 접근성을 높이기 위해 필수적으로 제공되어야 합니다. 다양한 테스트 도구를 활용해 웹 및 모바일 앱에서 대체 텍스트를 포함한 접근성 요소를 철저히 점검하고, 사용자 경험을 개선할 수 있습니다. 접근성을 준수함으로써 모든 사용자에게 포용적인 디지털 환경을 제공합니다.

WCAG 2.2 Quick Reference - Non-text Content

필요성

대체 텍스트는 이미지, 동영상, 아이콘 등 비 텍스트 콘텐츠의 의미를 텍스트로 설명하여, 시각 장애인이나 저시력 사용자가 스크린 리더를 통해 콘텐츠를 이해할 수 있도록 돕습니다. 이는 접근성을 보장하며, 웹 및 앱에서 모든 사용자가 동등하게 콘텐츠에 접근할 수 있게 합니다.

대상

  • 시각 장애인

    스크린 리더를 사용하는 사용자들.

  • 저시력 사용자

    텍스트 크기 조정 및 색상 대비에 의존하는 사용자들.

  • 고령자

    시력이 저하된 사용자들.

  • 인지 장애인

    복잡한 비주얼 콘텐츠를 이해하는 데 어려움을 겪는 사용자들.

체크리스트

이미지 요소에 어떤 내용으로 대체 텍스트를 제공할 것인지 고민하기 전에, 이미지를 어떤 목적으로 사용하고 있는지를 생각해 봐야 합니다.
이미지가 주요 콘텐츠의 일부로서 사용자에게 정보를 전달하는 역할을 한다면 적절한 의미에 맞는 대체 텍스트를 제공하면 됩니다.
반대로 이미지가 콘텐츠의 내용을 설명하는 핵심적인 요소가 아니라면 대체 텍스트를 생략하거나 배경 이미지 속성을 활용함으로써 스크린 리더 사용자에게 불필요한 정보를 전달하지 않도록 합니다.

  • 대체 텍스트 제공 여부

    모든 비 텍스트 콘텐츠에 대체 텍스트가 제공되고 있는가?

  • 적절성

    대체 텍스트가 콘텐츠의 의미를 정확하게 전달하고 있는가?

  • 중복 여부

    같은 콘텐츠에 대해 중복된 대체 텍스트가 제공되고 있지 않은가?

  • 불필요한 정보 배제

    장식용 이미지에 대체 텍스트가 불필요하게 포함되어 있지 않은가?

  • 스크린 리더 테스트

    대체 텍스트가 스크린 리더에서 올바르게 읽히는가?

기기별 테스트 방법

iOS

  • VoiceOver 활성화

    설정 > 접근성 > VoiceOver를 활성화하여 대체 텍스트가 올바르게 읽히는지 테스트합니다.

  • Accessibility Inspector 사용

    Xcode의 ‘Accessibility Inspector’를 통해 UI 요소의 대체 텍스트 적용 상태를 확인합니다.

  • 상세 가이드

    iPhone 사용 설명서 - VoiceOver

Android

  • TalkBack 활성화

    설정 > 접근성 > TalkBack을 활성화하여 대체 텍스트가 적절하게 읽히는지 테스트합니다.

  • Accessibility Scanner 사용

    Google Play에서 제공하는 ‘Accessibility Scanner’ 앱을 사용하여 대체 텍스트의 적용 여부를 자동으로 탐지합니다.

  • 상세 가이드

    Android 접근성 고객센터 - TalkBack 및 Android

QA 지표

  • 대체 텍스트 오류 비율

    대체 텍스트가 누락되거나 부정확하게 제공된 UI 요소의 비율.

  • 스크린 리더 정확성

    스크린 리더를 통해 올바르게 읽히는 대체 텍스트의 비율.

  • 사용자 피드백

    실제 사용자 테스트를 통해 대체 텍스트의 적절성에 대한 피드백을 수집.

개발방법

시각장애인 사용자는 스크린리더 프로그램을 사용하여 콘텐츠 정보를 인식하고 사용합니다. 스크린리더는 각각의 콘텐츠가 갖고 있는 정보를 음성으로 알려줍니다.
아래 이미지중 우측 하단의 블루라이트 필터를 설정하는 스위치 버튼을 조작한다고 가정했을 때 아래와 같은 메시지를 음성으로 알려줍니다.

  • 콘텐츠의 용도를 알 수 있는 텍스트 정보(●) 예) 블루라이트 필터
  • 콘텐츠가 어떤 컨트롤인지 버튼인지, 토글 버튼인지 등 유형 정보(▲) 예) 스위치
  • 콘텐츠 유형에 따른 상태 정보(◼︎) 예) 사용 안 함
  • 콘텐츠를 사용하기에 필요한 힌트 정보(★) 예) "전환하려면 두 번 탭 하세요."
스크린리더가 각각의 콘텐츠가 갖고 있는 정보를 음성으로 알려주는 예시
[출처 : NULI]

네이티브

요약 설명

iOS는 accessibilityLabel로 Android는 contentDescription으로 대체 텍스트 정보를 제공할 수 있습니다.

iOS

  • 관련 문서

    Apple’s Accessibility Programming Guide for iOS

  • Interface Builder 이용하여 요소에 대체 텍스트 적용하는 방법
    • 방법1. Xcode의 Accessibility 패널에서 Label 제공
      [출처 : NULI]

      ① Accessibility 에서 Enabled 을 선택해 접근성 기능을 활성화한 상태에서
      ② Label 에 콘텐츠의 의미를 명확하게 전달할 수 있는 대체 텍스트를 작성합니다.

    • 방법2. 코드로 Label 제공
  • UIAccessibility API를 활용하여 코드에 대체 텍스트 제공

Android

  • 관련 문서

    Android Accessibility Overview

  • 방법1. Android Studio Properties 창에서 contentDescription 제공
    [출처 : NULI]
  • 방법2. 코드로 contentDescription제공
  • contentDescription 속성 사용
  • 코드에서 contentDescription 설정

하이브리드

하이브리드(html)

하이브리드(Vue)

하이브리드(React)

이미지 alt속성 작성 예시

기뻐하는 죠르디
[출처 : kakaopay]

위 이미지는 카카오페이 신용대출 서비스 화면에서 대출 가능성이 높음을 안내하는 배너입니다. 이 이미지를 기준으로 alt 속성을 작성한 여러 예시입니다.

alt 속성을 사용하지 않은 경우

  • 스크린 리더는 이미지에 alt 속성이 없으면 파일 이름을 표현합니다.
  • 대체 텍스트가 없기 때문에 대신 이미지 경로 정보인 src를 음성으로 전달합니다.
  • 파일의 이름으로 콘텐츠를 설명하는 것도 방법이 될 수는 있습니다.
    하지만 네트워크 오류, 콘텐츠 차단 등 서비스 관련 이미지를 표시할 수 없는 경우에는 서비스와 무관한 이미지의 alt 값이 음성으로 출력되기 때문에 접근성뿐만 아니라 다양한 환경의 사용자를 고려한다면 alt 속성은 꼭 필요한 속성입니다.

alt 속성을 사용했지만 값을 제공하지 않는 경우

  • alt 속성의 값을 빈 값("")으로 생략해 제공하는 경우에는 이미지가 핵심 요소가 아님을 뜻하기 때문에 스크린 리더는 img 태그를 해석하지 않습니다.
  • 이 경우 스크린 리더 사용자는 웹 브라우징 과정에서 이미지 요소가 있다는 것을 알 수 없습니다.
  • 따라서 배경 이미지처럼 단순 디자인의 목적을 가진 이미지는 의도적으로 대체 텍스트를 빈 값으로 작성해 스크린 리더가 읽지 않도록 할 수 있습니다.
  • 하지만 예시의 1번 이미지 영역 죠르디의 상태로 높은 대출 승인율을 표현하는 콘텐츠임을 감안하면, 사용자에게 이미지 설명을 전달할 필요가 있기 때문에 다음 단계에서 alt 속성에 대체 텍스트를 적용합니다.

적합한 대체 텍스트를 작성하지 않은 경우

  • 시맨틱 태그는 암시적으로 role을 갖고 있으며, 스크린 리더는 <img> 요소를 '이미지'로 자동으로 결정하게 됩니다.
  • 따라서 이미지의 존재 여부를 표현하는 '사진, 이미지, 아이콘'등의 단어를 대체 텍스트에 포함하게 되면 스크린 리더가 기본적으로 해석한 '이미지'와 중복된 의미를 갖기 때문에 적합하지 않습니다.

(권장)적합한 대체 텍스트를 제공한 경우

버튼에 이미지 작성 예시

스크린 리더가 코드 해석하는 방식

  • 브라우저는 코드를 스크린 리더가 읽을 수 있는 접근성 트리(Accessibility Tree)로 만듭니다.
  • 스크린 리더는 접근성 트리의 요소를 순차 탐색하게 되는데, 접근성 트리에 표시되는 요소의 Name을 기반으로 해석합니다.
  • 여기서 말하는 Name은 Accessible Name이라고도 하며 스크린 리더가 요소를 포커스했을 때 읽는 값으로 author와 contents 중 하나로 결정됩니다.
  • 이때, author가 contents보다 우선순위가 높습니다.
    • author : aria-label, aria-labelledby, title 속성, <img>의 alt 속성, svg의 <desc>
    • contents : Text 노드

버튼 예시

기뻐하는 죠르디
[출처 : kakaopay]

위 이미지의 2번 이미지 영역에 있는 물음표 모양 버튼을 보면, 내 대출 승인율이 무엇인지 자세한 정보를 확인할 수 있는 버튼임을 인식할 수 있습니다.

  • <img>의 author는 alt 속성으로 Accessible Name은 "내 대출 승인율이란"이 됩니다.
  • <button>은 author가 설정되지 않은 경우 자식 요소의 Accessible Name을 모아 contents로 사용하는 Children Presentational이라는 특징을 갖습니다.
  • 따라서 <button>의 content는 '내 대출 승인율이란'이 되고 스크린 리더는 자동적으로 결정한 role과 결합해 "내 대출 승인율이란 버튼"이라고 해석하게 됩니다.

텍스트와 상호작용 요소의 분리 예시

요약 설명

텍스트 안에는 링크나 버튼을 넣지 않는 것이 좋습니다.
텍스트 안에 링크가 있으면 스크린 리더가 빠르게 읽어 내려가면서 시각장애인은 링크 위치를 파악하기 어려울 수 있습니다. 상호작용 요소는 텍스트와 분리해 디자인해야 인식이 용이합니다.

예시1

텍스트 링크는 버튼의 형태로 분리해서 디자인해야 합니다.
[출처 : 모바일 UI UX 기본가이드 | 브런치 스토리 by최철호]
왼쪽(DON'T)의 잘못된 점
  1. 링크가 텍스트에 포함됨

    "OO서비스의 약관에 동의해주세요"라는 안내문에서 링크가 "마이 페이지/이곳"이라는 텍스트에 포함되어 있습니다. 이 방식은 사용자가 정확히 어디를 클릭해야 할지 헷갈리게 만들 수 있습니다. 특히, 링크가 특정 단어에만 적용되면 시각적 단서가 부족하여 접근성이 떨어집니다.

  2. 링크의 가시성 부족

    링크가 일반 텍스트와 크게 구분되지 않아서 사용자가 링크임을 인지하기 어렵습니다. 이는 사용성 문제를 유발하며, 시각적 장애가 있는 사용자에게 더욱 불편할 수 있습니다.

오른쪽(DO)의 개선 사항
  1. 명확한 버튼 제공

    오른쪽에서는 "약관 동의하러 가기"라는 명확한 버튼이 제공되어 사용자가 이 버튼을 눌러야 한다는 것을 쉽게 알 수 있습니다. 버튼을 사용하는 것은 링크를 텍스트에 숨기기보다 더 직관적이고 접근성을 높이는 방법입니다.

  2. 시각적 구분

    버튼이 눈에 잘 띄는 스타일로 제공되어 사용자가 쉽게 인지할 수 있습니다. 버튼 형태로 제공하면 클릭 가능한 요소가 명확해지고, 이를 통해 사용자의 혼란을 줄일 수 있습니다.

예시2

[출처 : 모바일 UI UX 기본가이드 | 브런치 스토리 by최철호]
왼쪽(DON'T)의 잘못된 점
  1. 텍스트 버튼의 모호함

    왼쪽에서는 "1:1 모바일 상담" 버튼이 문장의 흐름에 배치되어 있습니다. 이런 디자인은 사용자가 클릭 가능한 요소임을 직관적으로 인지하기 어렵고, 사용자의 경험을 저해합니다. 특히 시각적으로 UI 요소를 쉽게 구분할 수 없는 사용자에게 혼란을 줄 수 있습니다.

  2. 시각적 강조 부족

    텍스트와 버튼이 구별되지 않아 사용자가 쉽게 인식하지 못할 수 있습니다. 시각적 힌트가 부족해 접근성 측면에서 문제가 발생할 수 있습니다. 특히, 스크린 리더를 사용하는 사용자는 링크를 감지하는 데 어려움을 겪을 수 있습니다.

오른쪽(DO)의 개선 사항
  1. 명확한 버튼 레이아웃

    오른쪽에서는 텍스트와 "1:1 모바일 상담" 버튼이 명확하게 구분된 형태로 디자인되어 있어, 사용자가 클릭할 수 있는 요소임을 쉽게 인지할 수 있습니다. 시각적 구분이 명확해져 사용자가 어떤 동작을 해야 하는지 직관적으로 파악할 수 있습니다.

  2. 시각적 강조

    버튼은 텍스트와 차별화된 디자인을 가지고 있어 클릭 가능한 요소임을 강조합니다. 이로 인해 접근성이 향상되며, 사용자가 혼동 없이 필요한 작업을 수행할 수 있습니다.

점검 기준

텍스트가 아닌 콘텐츠에 해당 이미지가 제공하는 의미나 용도를 동일하게 인식할 수 있는 적절한 대체 텍스트를 제공해야 합니다.

오류 유형

  • 이미지 요소가 제공하는 정보와 동일한 정보가 음성으로 출력되지 않는 경우
  • 의미와 용도를 이해할 수 없는 대체 텍스트를 제공하는 경우
  • 의미없는 이미지에 대체텍스트를 제공하는 경우
  • 대체 텍스트 제공 없이 설명만 제공되는 경우(Hint로만 제공된 경우)
  • 객체 유형 정보가 반복 제공되는 경우 (~이미지이미지, ~버튼버튼 등)
  • 객체 유형에 대한 정보가 잘못 제공된 경우
  • display:none, visibility:hidden으로 대체텍스트가 제공된 경우
  • 화면에 보이지 않는 형태로 대체텍스트가 제공된 경우 (터치방식으로 대체정보 확인이 불가한 경우)

주의사항

  • 기능을 제공하는 경우 이용방법 등 충분한 설명을 제공하지 않은 경우 (권고)
  • 숫자 정보에 대해 의미전달이 미흡한 대체텍스트를 제공하는 경우 (권고)
  • 준수 예) 6.20 → 6월 20일
  • 권고) 객체 유형정보를 정확히 제공할 것을 권장함(Traits 정보)
  • IR기법으로 대체텍스트를 제공 시 hidden형태가 아니더라도 화면 터치방식으로는 대체정보 인지 불가함(오류)

점검 방법

iOS

  • 음성출력 형태

    VoiceOver는 UI 요소의 accessibilityLabel을 읽어줍니다. 예를 들어, “Submit button”이라고 출력합니다.

  • 제공 방법

    Xcode의 Interface Builder에서 Label 필드에 텍스트를 입력하거나, 코드에서 accessibilityLabel을 설정합니다.

Android

  • 음성출력 형태

    TalkBack은 contentDescription 속성에 설정된 텍스트를 읽어줍니다.

  • 제공 방법

    Android Studio에서 XML의 contentDescription 속성을 사용하거나, 코드에서 직접 설정합니다.

방법 1 (네이티브-문서 제공기준)

TalkBack(또는 Voice Assistant 등) 기능으로 텍스트가 아닌 콘텐츠에 대응하는 대체 텍스트의 적절성 여부를 확인합니다.

  • 화면 구성 정보를 제공하는지 확인합니다. (Title, List View, Grid View)
  • 화면 내 구체적인 Contents를 읽어주는지 확인합니다. (Text, Imge)
  • 화면 내 기능을 읽어주는지 확인합니다. (Button 등)

[출처 : 모바일 애플리케이션 접근성 제작기법]

방법 2 (네이티브-문서 제공기준)

음성출력 표시 기능으로 텍스트가 아닌 콘텐츠에 대응하는 대체 텍스트의 적절성 여부를 점검합니다.
설정 → 접근성 → 시각 → Talk Back → 설정 → 개발자 설정 → 음성출력 표시 체크 후 확인합니다.

[출처 : 모바일 애플리케이션 접근성 제작기법]

방법 3 (네이티브-문서 제공기준)

UIAutoMatorViewer를 활용하여 점검합니다.

  1. Android Studio를 이용한 실행방법
    • Toolbar에서 Android Device Monitor 버튼을 선택
      [출처 : 모바일 애플리케이션 접근성 제작기법]
    • Devices 탭에서 디바이스가 연결된 상태로 점검할 화면을 띄운 뒤 Dump View Hierarchy for UI Automator버튼을 선택
      [출처 : 모바일 애플리케이션 접근성 제작기법]
  2. ADT(Android Developer Tools) 를 이용한 실행 방법
    • DDMS(Dalvik Debug Monitor Server) 를 실행
    • Devices 탭에서 디바이스가 연결된 상태로 점검할 화면을 띄운 뒤 Dump View Hierarchy for UI Automator버튼을 선택
      [출처 : 모바일 애플리케이션 접근성 제작기법]
  3. SDK 내부의UIAutomator Viewer 실행
    • Android sdk폴더의 tools 안에있는 uiautomatorviewer.bat 파일실행
      [출처 : 모바일 애플리케이션 접근성 제작기법]
    • 실행화면
      [출처 : 모바일 애플리케이션 접근성 제작기법]
    • Device Screenshot 선택
      [출처 : 모바일 애플리케이션 접근성 제작기법]

방법 4 (네이티브-문서 제공기준)

UIAutomatorViewer를 이용하여 점검합니다.

  1. 점검할 화면을 띄운 후, 점검할 UI 객체를 선택하여 상세정보를 확인합니다.
    [출처 : 모바일 애플리케이션 접근성 제작기법]
  2. ImageButton, ImageView의경우 content-desc항목이 적용되어있는지 확인해야 합니다.
    • 대체텍스트 적용 시 Node Detail과 계층구조의{ }안에 대체텍스트내용이 표시 됩니다.
      [출처 : 모바일 애플리케이션 접근성 제작기법]
    • 대체텍스트 미적용 시 Node Detai과 계층구조에 대체텍스트가 표시되지 않습니다.
      [출처 : 모바일 애플리케이션 접근성 제작기법]
  3. TextView, Button, EditText등의 경우 content-desc에 대체텍스트가 적용되지 않고 text에 대체텍스트가 적용될 수 있습니다.

    [출처 : 모바일 애플리케이션 접근성 제작기법]

방법 5 (하이브리드)

크롬(Chrome) 브라우저 요소검사를 이용하여 점검합니다.
해당 이미지 요소를 선택하여 우측클릭하여 요소검사를 하여 코드로 확인합니다.

[크롬(Chrome) 브라우저 이미지 요소검사]

주의사항

  • 개발방법에 따라 연관된 타 UI 객체에 대체텍스트를 적용하고 있는경우가 있습니다. 이런경우엔 오류항목으로 볼 수 없습니다.
  • UIAutoMatorViewe를 활용한 대체텍스트 확인은 다른 점검기법과 병행되어 사용하는 것이 바람직합니다.

준수 사례

사례 1) 아이콘 + 텍스트와 같이 제공되는 경우

[출처 : 무인정보단말기 UI 플랫폼]

음성출력 형태(Talkback) : "UI 가이드 원칙 링크 6개 중 첫번째. 활성화하려면 두 번 탭하세요. 링크 사용가능. 세 손가락으로 탭 동작으로 보기."

사례 2) 이미지로 제공되는 경우

[출처 : 무인정보단말기 UI 플랫폼]

음성출력 형태(Talkback) : "정보접근성이 보장된 무인정보단말기 UI 플랫폼 고령자도 OK! 장애인도 OK! 무인정보단말기의 정보접근성을 모두 갖춘 무인정보단말기 UI 플랫폼과 개발도구 제공 자세히 보기. 활성화하려면 두 번 탭하세요. 링크 사용가능. 세 손가락으로 탭 동작으로 보기."

사례 3) 의미와 용도를 이해할 수 있도록 적절하게 대체텍스트를 제공한 경우

[출처 : 모바일애플리케이션콘텐츠접근성지침2.0]

"다음 메일 Kakao corp. 별점 평점 4.3”으로 해당 메일의 정보를 올바르게 제공합니다.

사례 4) 이미지 버튼에 적절한 대체텍스트를 제공한 경우

[출처 : 모바일애플리케이션콘텐츠접근성지침2.0]

"옵션 버튼" 으로 해당 버튼의 정보를 올바르게 제공합니다.

미준수 사례

사례 1) 이미지 요소가 제공하는 정보와 동일한 정보가 음성으로 출력되지 않는 경우

[출처 : 모바일애플리케이션콘텐츠접근성지침2.0]
  • 개선 전

    "이벤트"로 해당 이미지에 대해 대체텍스트가 부적절하게 제공됩니다.

  • 개선 후

    "릴레이팡팡 한방에 달성하기!"로 해당 이미지에 대해 대체텍스트가 제공되어야 합니다.

사례 2) 의미와 용도를 이해할 수 없는 대체 텍스트를 제공하는 경우

[출처 : 모바일애플리케이션콘텐츠접근성지침2.0]
  • 개선 전

    "버튼 -4 라벨지정안됨" 으로 해당 이미지 버튼에 대체텍스트가 부적절하게 제공됩니다.

  • 개선 후

    "카드 설정 버튼" 또는 "의미와 용도에 맞는 텍스트 정보"로 해당 이미지에 대해 대체텍스트가 제공되어야 합니다.

사례 3) 버튼에 대체텍스트가 제공되지 않은 경우

[출처 : 모바일애플리케이션콘텐츠접근성지침2.0]
  • 개선 전

    보안 키패드에 대체텍스트가 제공되지 않습니다.

  • 개선 후

    각 버튼에 대해 대체텍스트가 제공되어야 합니다.

키패드 적용 기본 예시

사례 4) 의미없는 대체 텍스트가 제공된 경우

개선 전

의미 없는 장식용 이미지에는 alt 속성을 비워 alt=""로 제공할 수 있습니다. 아이콘 자체에 의미가 없을 경우 빈 alt를 사용해도 문제없습니다.

[출처 : 카카오]

개선 후

불필요한 alt 값을 제거해 화면 읽기를 간결하게 하고, 중복된 내용으로 인한 피로감을 줄일 수 있습니다.

[출처 : 카카오]

사례 5) 의미없는 대체 텍스트가 제공된 경우와 암묵적으로 제시된 이미지에 중복 사용된 경우

개선 전

의미를 갖지 않는 장식용 이미지에 alt가 제공되고 있으며, 의미를 가지는 정보(예: 날짜)는 풀어서 제공해줘야 합니다.
예) 2024.09.30 → 2024년 09월 30일까지

  • 음성출력 형태(Talkback) : "유플닷컴 출석체크 이벤트 2024년 9월 30일 달력 이미지" 링크 활성화하려면 두 번 탭하세요. 링크 사용가능. 세 손가락으로 탭 동작으로 보기.
  • 음성출력 형태(Voiceover) : "유플닷컴 출석체크 이벤트 물결 2024점 9점 30점 슬래시 달력 이미지" 링크
[출처 : 카카오]

개선 후

의미 없는 장식용 이미지에는 alt 값을 제거하고, 중복된 이미지는 사용하지 않는 것이 좋습니다.

  • 음성출력 형태(Talkback) : "유플닷컴 출석체크 이벤트 기간 2024년 9월 30일 까지" 링크 활성화하려면 두 번 탭하세요. 링크 사용가능. 세 손가락으로 탭 동작으로 보기
  • 음성출력 형태(Voiceover) : "유플닷컴 출석체크 이벤트 기간 2024년 9월 30일 까지" 링크
[출처 : 카카오]

관련 영상

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

결론

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

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

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