이득:
- 인공 지능 지원을 통해 색상 대비, 대체 텍스트, 키보드 액세스 및 WCAG 기준을 제어하고 개선하는 기능
- 스크린리더 경험, 대체 텍스트, 양식 라벨 등 접근성 텍스트를 인공지능으로 생성하고 검증하는 기능
- 실제 보조 기술 및 사용자 테스트를 통해 AI의 접근성 권장 사항을 검증하는 한계 이해
접근성(줄여서 11y)은 장애인을 포함하여 모든 사람이 사용할 수 있는 제품의 능력입니다. 시각 장애가 있는 사용자는 화면 판독기(텍스트를 음성으로 변환하는 보조 소프트웨어)를 사용하여 탐색할 수 있고, 운동 장애가 있는 사람은 키보드로 무엇이든 할 수 있으며, 색맹인은 색상에 의존하지 않고 정보를 받을 수 있습니다. 포용적 디자인은 더 광범위합니다. 연령, 언어, 문화, 일시적 장애(팔 부러짐) 또는 상황적 장애(태양 아래 스크린)를 포함하여 인간의 다양성을 디자인의 중심에 둡니다. 접근성은 "추가" 사항이 아니라 대부분의 국가에서 기본적인 책임이자 법적 요구 사항입니다. AI는 이 분야의 강력한 사전 심사자이자 초안 생성자입니다. 그러나 진정한 접근성은 실제 보조 기술과 사용자 테스트를 통해서만 확인됩니다.
WCAG 및 주요 제어 영역
WCAG(웹 콘텐츠 접근성 지침)는 접근성에 대해 국제적으로 인정되는 일련의 기준입니다. 일반적으로 AA 수준이 대상입니다. 여기에는 네 가지 원칙이 있습니다. 콘텐츠는 인식 가능해야 하고, 인터페이스는 사용 가능해야 하며, 정보는 이해 가능하고 기술적으로 건전해야 합니다. 실제로 가장 일반적인 제어 영역은 다음과 같습니다.
- 색상 대비: 텍스트와 배경의 차이가 충분합니까? (AA의 경우 일반 텍스트의 비율이 최소 4.5:1입니다.)
- 대체 텍스트(대체 텍스트): 이미지에 화면 판독기에 설명하는 해당 텍스트가 있습니까?
- 키보드 접근: 마우스 없이 무엇이든 할 수 있나요? 초점 순서가 의미가 있습니까?
- 색상 전용 정보: "빨간색 필드 채우기"와 같은 문구는 색맹 사용자를 제외합니다.
- 양식 레이블: 각 입력 필드에 화면 판독기가 읽을 레이블이 있습니까?
- 터치 대상: 손가락으로 편안하게 누를 수 있을 만큼 버튼이 큰가요?
AI는 이러한 여러 영역에서 빠른 예비 스캔을 수행할 수 있습니다. 텍스트를 제공하고 "대비가 충분합니까?"라고 질문하고, 이미지 설명을 제공하고 "대체 텍스트 제안"을 요청하고, 인터페이스 설명을 제공하고 "키보드 액세스 문제가 무엇입니까"라고 질문할 수 있습니다.
주의: AI가 "접근 가능해 보인다"고 말한다고 해서 접근성이 보장되는 것은 아닙니다. 자동 검사는 WCAG 오류 중 일부만 포착합니다. 나머지는 실제 사용을 통해 드러날 것입니다.
대체 텍스트: 좋은 대체 텍스트의 비결
대체 텍스트는 시각 장애가 있는 사용자를 위한 이미지를 대체합니다. 좋은 대체 텍스트는 장식적인 세부 사항이 아닌 이미지의 기능과 의미를 전달합니다. "장바구니에 추가" 아이콘의 대체 텍스트는 "장바구니 이미지"가 아닌 "장바구니에 추가"여야 합니다. 이는 사용자에게 중요한 작업이기 때문입니다. AI는 하위 텍스트 개요를 생성하는 데 능숙하지만 맥락을 모르기 때문에 지나치게 설명적이거나 관련 없는 텍스트를 생성할 수 있습니다. 각 대체 텍스트에 "이 이미지가 왜 여기에 있나요?"라고 묻습니다. 질문으로 자르기.
시각적
약한 하위 텍스트
강력한 하위 텍스트
장바구니 아이콘(버튼)
"장바구니 아이콘, 회색 색상"
"장바구니에 추가"
제품 사진
"그림"
"블루 겨울 코트, 정면도"
장식 라인
"장식 라인"
(비워두세요 - 장식용)
그래픽
"그래픽 이미지"
"2024년 매출 : 분기마다 증가"
포괄적인 언어 및 범위
접근성은 기술적 통제에만 국한되지 않습니다. 언어도 포함됩니다. 성별(“사용자 및 그/그녀의 배우자”)을 가정하거나 능력(“눈길”, “쉽게 듣는다”)에 따라 제외하거나 문화적 가정을 포함하는 텍스트는 일부 사용자를 제외합니다. AI는 이러한 관점에서 텍스트를 스캔할 수 있지만 AI가 제안하는 "중립" 언어가 자연스럽고 이해 가능하도록 유지해야 합니다. 과도하게 수정하면 텍스트가 어색해질 수 있습니다.
세 개의 미니 케이스
사례 1 - 대비 오류가 조기에 발견되었습니다. 한 팀은 AI가 20개 화면의 텍스트 색상을 스캔하도록 했고 7개 장소에서 대비가 AA 임계값보다 낮다고 판단했습니다. 개발에 들어가지 않고 수정이 이루어졌습니다. 후속 수정 비용이 방지되었습니다. 하지만 팀은 여전히 실제 스크린리더 테스트를 건너뛰지 않았습니다.
사례 2 - 색상 관련 정보만 수정되었습니다. 한 양식에는 빨간색 테두리만 있는 오류 필드가 표시되었습니다. AI가 이를 표시했습니다. 또한 팀은 각 오류에 텍스트와 아이콘을 추가했습니다. 색맹 사용자는 이제 오류를 볼 수 있습니다. 교훈: 색상만으로는 정보를 전달할 수 없습니다.
사례 3 - AI가 잘못된 승인을 유도했습니다. 한 디자이너는 AI를 "접근 가능"하다고 불렀기 때문에 스크린 리더 테스트를 건너뛰었습니다. 실제 테스트에서는 포커스 순서가 헷갈리고 일부 버튼이 전혀 읽히지 않는 것으로 나타났습니다. 교훈: 자동 확인이 시작입니다. 실제 보조 기술 테스트는 필수입니다.
복사 가능한 프롬프트
접근성을 위해 이 인터페이스 설명을 미리 스캔하십시오. 1) 색상만을 기반으로 전달되는 정보가 있습니까?2) 클릭 가능한 각 요소에 대한 텍스트 레이블이 있습니까?3) 키보드를 통해 액세스할 수 없는 요소가 있습니까?4) 포커스 순서가 의미가 있습니까?각 문제와 제안을 나열합니다. "실제 테스트 필요"라는 메모를 추가합니다.레시피: <<text>>
이 이미지에 대한 대체 텍스트를 제안하세요. 규칙: 장식적인 세부 사항이 아닌 이미지의 기능/의미를 전달하십시오. 버튼 아이콘에 대한 작업을 작성합니다. 장식용 이미지의 경우 "대체 텍스트는 비워 두어야 합니다"라고 말합니다. 컨텍스트 및 이미지 설명: <<list>>
다음 텍스트에서 포괄적인 언어를 확인하세요. 성별 가정, 능력 기반의 배제적인 언어(예: '보기', '듣기'), 문화적 가정이 있나요? 자연스러운 대안을 제안하세요. 과도하게 수정하지 마십시오.텍스트: <<list>>
이 양식에 대한 액세스 가능한 오류 및 레이블 텍스트를 작성합니다. 각 필드에 표시되는 레이블, 화면 판독기에 대한 설명, 색상에 관계없이 오류를 설명하는 메시지(텍스트 + 아이콘)입니다. 음성 및 톤: <<카드>>양식 필드: <<목록>>
약한 프롬프트 / 강한 프롬프트
약함: "이 이미지에 대한 대체 텍스트를 작성합니다."
그 결과는 "이미지"이거나 기능을 놓치는 지나치게 설명적인 텍스트입니다.
Strong: "이러한 이미지에 대한 대체 텍스트를 제안하고, 이미지의 기능/의미를 전달하고, 버튼 아이콘에 대한 작업을 작성하고, 장식적인 아이콘은 '비워 두어야 함'으로 표시합니다."
그 결과 상황에 맞는 기능 중심의 정확한 하위 텍스트가 생성됩니다.
차이점: 강력한 프롬프트는 기능적 초점 + 버튼 규칙 + 장식적 구별을 가져옵니다.
일반적인 실수
- 인공지능 승인을 접근성 보장으로 착각합니다. 이는 실제 테스트를 대체할 수 없습니다.
- 정보를 컬러로 로드하는 것뿐입니다. 색맹 사용자는 정보를 놓치게 됩니다.
- 대체 텍스트에서 기능이 아닌 이미지를 설명합니다. 버튼 아이콘에 대한 작업을 작성해야 합니다.
- 접근성을 마지막으로 남겨둡니다. 와이어프레임 단계에서 시작하지 않으면 나중에 패치하는 데 비용이 많이 듭니다.
- 과도하게 수정된 언어. 자연스러움을 잃은 포용적 언어는 이해력도 손상시킨다.
요약하면
접근성이란 모든 사람이 제품을 사용할 수 있음을 의미합니다. 이는 추가 사항이 아니라 필수이며 대부분의 경우 법적 책임입니다. AI는 대비, 대체 텍스트, 키보드 액세스 및 포괄적인 언어 검색을 위한 빠른 비행 전 및 초안 생성기로서 가치가 있습니다. 그러나 자동 승인은 WCAG 오류 중 일부만 포착합니다. 실제 접근성은 화면 판독기와 실제 보조 기술 사용자를 대상으로 한 테스트를 통해 확인됩니다. 모델을 전면 브라우저로 사용하고 실제 테스트를 통해 증거를 얻으세요.
응용과제
- 첫 번째 프롬프트에서 접근성에 대한 인터페이스 설명을 미리 검사합니다.
- 색상 기반 정보나 라벨이 없는 항목만 수정하세요.
- 두 번째 프롬프트를 사용하여 화면의 시각적 개체에 대한 기능 지향 대체 텍스트를 생성합니다.
- 세 번째 프롬프트를 통해 텍스트에 포함된 언어가 있는지 확인하세요.
- 가능하다면 화면 판독기로 실제 테스트를 시도하고 자동 스캔에서 놓친 부분을 기록해 두십시오.
체크리스트
- [ ] 대비, 키보드 액세스 및 라벨을 사전 스캔했습니다.
- [ ] 색상만으로 정보를 남기지 않았습니다.
- [ ] 하위 텍스트는 기능적으로 작성하고 장식적인 텍스트는 공백으로 두었습니다.
- [ ] 포괄적인 언어 제어를 만들어 자연스러움을 유지했습니다.
- [ ] 자동 승인이 접근성 보장이라고 생각하지 않았습니다.
- [ ] 실제 보조 기술 테스트를 계획/실행했습니다.