AI가 만든 UI, 접근성은 어떻게 검사할까? 디자이너용 체크리스트

AI가 10초 만에 만든 예약 화면은 그럴듯합니다. 하지만 Tab 키를 눌렀을 때 포커스가 사라지고, ‘다시 생성’ 아이콘의 뜻이 읽히지 않으며, 결과가 바뀌어도 스크린리더가 알리지 않는다면요? 화면은 완성됐어도 누군가에게는 시작할 수 없는 제품입니다.

생성형 UI는 매번 다른 카드·폼·차트·버튼을 조합합니다. 그래서 접근성은 마지막에 화면 몇 장을 검사하는 일이 아니라, 생성해도 깨지지 않는 규칙을 먼저 만드는 일입니다.

1. 키보드만으로 끝까지 갈 수 있는가

마우스를 치우고 Tab·Shift+Tab·Enter·화살표 키만으로 입력, 옵션 선택, 결과 수정, 저장까지 해봅니다. 생성 카드의 버튼·메뉴도 순서대로 닿아야 하고, 모달이 열릴 때 포커스가 뒤 화면으로 빠지면 안 됩니다. WCAG 2.2는 키보드 조작과 포커스가 가려지지 않을 것을 다룹니다.

2. 지금 조작하는 위치가 보이는가

스트리밍 결과나 새 패널이 열릴 때 포커스 표시가 묻히기 쉽습니다. 버튼·칩·표의 포커스를 선명한 테두리나 색 변화로 드러내고, 변화 전후 대비를 확인하세요. 은은한 그림자 하나만으로는 현재 위치가 충분히 보이지 않을 수 있습니다. W3C Focus Appearance

3. 이름·역할·상태가 읽히는가

‘저장’ 아이콘의 의미, 생성 중 버튼의 비활성 상태, 펼쳐진 아코디언을 보조기술도 알아야 합니다. 컴포넌트의 이름·역할·값·상태와 변경 알림이 프로그램적으로 전달되는지 확인하세요. W3C의 ARIA 가이드는 동적 콘텐츠와 고급 UI 컨트롤을 보조기술에 전달하는 방법을 다룹니다. WAI-ARIA

4. 색만으로 말하지 않는가

추천의 초록색, 오류의 빨간색, 선택된 필터의 연한 배경만으로 상태를 알리지 마세요. 텍스트·아이콘·패턴을 함께 쓰고 텍스트 대비를 검사합니다. AI가 새 배경과 배지를 만든다면, 허용 색 토큰과 대비 기준을 프롬프트가 아니라 디자인 시스템 제약으로 둡니다.

5. 상태를 알리고, 되돌릴 수 있는가

‘생성 중’, ‘근거 없음’, ‘3개 옵션으로 갱신됨’을 시각적으로만 바꾸지 마세요. 상태 변화가 읽히고 사용자는 수정·재시도·취소할 수 있어야 합니다. Apple은 생성 결과 곁에 Edit·Undo·Retry 같은 통제 수단과 변경 피드백을 두도록 권고합니다. Apple HIG

6. AI가 실패해도 핵심 과업을 할 수 있는가

생성이 늦거나 막혔을 때 빈 카드와 ‘재시도’만 남기지 마세요. 일반 검색, 수동 입력, 기본 템플릿으로 이어지는 fallback을 설계합니다. Apple도 AI를 쓰지 않거나 사용할 수 없어도 좋은 경험을 제공하라고 안내합니다.

자동 검사 통과로 끝내지 마세요. 실제 생성 결과를 키보드와 스크린리더로 통과시켜 보세요. Generative UI의 목표는 더 많은 화면이 아니라, 어떤 화면이 나와도 사용자가 다음 행동을 잃지 않게 만드는 일입니다.

참고한 자료

• W3C WCAG 2.2
• W3C WAI-ARIA
• Apple HIG: Generative AI