UX 설계 시 시각장애인을 위해서 반드시 고려해야 할 5가지 요소에 대해서 설명합니다. 스크린리더 호환, 대체 텍스트, 키보드 탐색, 피드백 구조 등 실제 적용 기준에 대해서 알아보고 보이지 않아도 완전한 사용자 경험을 위한 설계 원칙을 실무에 바로 적용해 보세요.
서론: 시각 중심의 UX, 시각이 없다면 어떻게 설계할 것인가?
디지털 서비스의 대다수는 ‘보는 사람’을 기준으로 설계된다.
하지만 전 세계적으로 약 2억 명 이상이 시각장애를 겪고 있으며,
이들은 화면을 볼 수 없거나, 일부만 볼 수 있는 조건에서 콘텐츠를 소비하고 서비스를 이용한다.
이들은 화면을 ‘보는 것’이 아니라, 스크린리더(화면 낭독기)를 통해 듣고,
포커스를 이동시켜 구조를 탐색하며, 키보드나 보조 장치로 조작한다.
즉, UX의 인지·이해·조작 방식 자체가 시각 중심 사용자와는 전혀 다르다.
디자이너가 이런 차이를 고려하지 않으면,
- 서비스 자체가 시각장애인에게는 '닫힌 공간'이 되거나
- 접근성 인증은 받았지만 실제 사용은 불가능한 UX가 만들어진다.
이 글에서는 시각장애인을 위한 UX 설계에서 반드시 고려해야 할 핵심 요소 5가지를 실무 중심으로 정리하고,
각 항목별로 구체적인 적용 방법과 실수 예시까지 함께 설명한다.
1. 스크린리더와 호환되는 구조 설계
1) 왜 중요한가?
시각장애인은 화면을 ‘보지 않고 듣는다.’
이를 가능하게 해주는 도구가 바로 스크린리더(Screen Reader)이다.
이 소프트웨어는 웹페이지나 앱의 구조를 음성으로 읽어주며, 사용자는 키보드나 제스처로 이동하며 전체 UI를 파악한다.
2) 실무자가 고려해야 할 사항
- HTML 태그를 의미에 맞게 정확히 사용해야 함
→ 제목(h1~h3), 리스트(ul, li), 섹션(section), 버튼(button) 등 - 스크린리더는 시각적 위치가 아닌 코드 순서대로 콘텐츠를 탐색함
→ 화면상 오른쪽에 있어도 코드상 먼저 있으면 먼저 읽힘 - ARIA 속성 사용 시 꼭 테스트 병행 필요
→ aria-label, aria-labelledby, role 등은 유용하지만 과용 시 오히려 혼란을 줄 수 있음
3) 실무 예시
❌ 잘못된 예:
<div class="btn">다음</div>
✅ 올바른 예:
<button type="button">다음</button>
2. 대체 텍스트(alt text)의 의미 중심 작성
1) 왜 중요한가?
이미지를 볼 수 없는 사용자는 이미지의 의미를 대체 텍스트(alt)를 통해 인지한다.
하지만 alt 속성이 없거나, 단순히 "이미지1", "배경"처럼 입력되면 정보가 누락된다.
2) 실무자가 고려해야 할 사항
- 이미지의 ‘기능’이나 ‘의미’에 따라 alt 내용을 달리해야 함
→ 정보 전달 목적이면 설명 필수
→ 순수 배경 이미지면 빈 alt 속성으로 처리 (alt="") - 텍스트가 포함된 이미지에는 반드시 해당 내용 포함
→ "이벤트 종료" 이미지 → alt="이벤트가 종료되었습니다" - 아이콘(검색, 홈 등)은 role과 함께 명확한 대체 텍스트 제공
3) 실무 예시
❌ 잘못된 예:
<img src="banner.jpg" alt="배너">
✅ 올바른 예:
<img src="banner.jpg" alt="6월 쇼핑 이벤트 - 최대 30% 할인 쿠폰 제공">
3. 포커스 흐름과 키보드 조작의 전면 고려
1) 왜 중요한가?
시각장애인은 포인터(마우스)를 사용하지 않고,
키보드나 터치 제스처만으로 인터페이스를 조작한다.
→ 따라서 ‘포커스가 어디에 있는가’가
= ‘현재 사용자가 어디에 있는가’를 의미한다.
2) 실무자가 고려해야 할 사항
- 탭(Tab) 키를 사용해 순서대로 모든 요소를 탐색할 수 있어야 함
- 탭 순서가 자연스럽고 논리적이어야 함 (화면 구성 순서 ≠ 코드 순서 주의)
- 숨겨진 기능이나 팝업은 포커스를 자동으로 이동시켜야 함
3) 실무 예시
❌ 잘못된 예:
모달창이 떠도 포커스가 백그라운드에 머물러 있음
✅ 올바른 예:
모달창이 열리면 tabindex="-1"을 사용해 포커스 강제 이동 → 모달 내부 버튼 → 모달 닫기 후 원래 위치로 복귀
4. 명확한 에러 메시지와 피드백 설계
1) 왜 중요한가?
시각장애인은 입력 실수나 시스템 상태를
시각적으로 확인할 수 없기 때문에,
모든 피드백은 ‘음성’ 또는 ‘스크린리더 읽기’로 대체되어야 한다.
2) 실무자가 고려해야 할 사항
- 입력 오류 발생 시, 해당 필드에 직접 연결된 에러 메시지를 제공
→ aria-describedby, role="alert" 등을 활용 - 성공/실패 피드백은 색깔만으로 표현하면 안 됨
→ 소리/텍스트/진동 등의 병행 필요 - 에러 발생 필드는 포커스를 자동으로 이동시켜야 함
→ ‘다음 단계로 진행이 불가능함’을 정확히 인지시켜야 함
3) 실무 예시
❌ 잘못된 예:
"필수 입력 항목이 누락되었습니다" → 색상만 붉게 표시
✅ 올바른 예:
<span id="error1" role="alert">이름을 입력해주세요</span>
→ aria-describedby="error1"을 해당 입력창과 연결
5. 비시각적 UI 요소의 접근성 강화(예: 슬라이더, 드롭다운 등)
1) 왜 중요한가?
시각장애인에게는 비표준 UI (예: 커스텀 셀렉트 박스, 슬라이더, 아코디언 등)는
스크린리더가 정보를 전달하지 못해 완전히 작동 불가 상태가 된다.
2) 실무자가 고려해야 할 사항
- 가능한 기본 HTML 요소 사용 (select, input range 등)
- 커스텀 UI일 경우 ARIA 속성과 키보드 이벤트 지원 필수
- 드롭다운은 열림/닫힘 여부를 aria-expanded로 알리고, 하위 항목은 키보드로 탐색 가능해야 함
3) 실무 예시
✅ 커스텀 셀렉트 박스:
- role="combobox"
- aria-haspopup="listbox"
- aria-expanded="true/false"
- 키보드 화살표로 선택 이동 가능
결론: ‘보지 않고도 사용할 수 있는 경험’이 진짜 UX다
시각장애인을 위한 UX 설계는 ‘특별한 기능’을 추가하는 작업이 아니다.
오히려 기본적인 정보 구조, 피드백, 탐색 흐름을 누구나 인식하고 조작할 수 있도록 만드는
UX 설계의 근본적인 출발점이다.
접근성은 디자인의 한계가 아니라, 디자인의 깊이와 책임을 나타내는 지표다.
시각장애인을 위한 UX를 제대로 설계하면
→ 전체 사용자 경험이 향상되고
→ SEO·수익성·브랜드 신뢰도까지 함께 오른다.
이제는 ‘볼 수 없는 사용자’를 위한 UX가 아닌,
‘보지 않아도 사용할 수 있는 사용자 경험’을 설계하는 시대다.
관련 글 더보기
'개발' 카테고리의 다른 글
| 인지장애 사용자 UX 설계, 단순함이 모든 해답은 아니다 (1) | 2025.06.29 |
|---|---|
| 청각장애 사용자를 위한 UI 설계 – 자막 이상의 것을 고민하자 (0) | 2025.06.28 |
| 장애인을 위한 UX가 결국 수익성과 연결되는 이유 – 포용적 디자인이 실질적 이익으로 이어지는 구조 (0) | 2025.06.25 |
| 왜 지금 UX 디자이너는 ‘접근성’에 집중해야 하는가? (0) | 2025.06.24 |
| 디지털 접근성, 단순히 ‘장애인’을 위한 건 아닙니다 - 실무자가 알아야 할 포용적 UX의 진짜 의미 (0) | 2025.06.23 |
