[접근성연구·저시력] 우리 이미지엔 이름이 있는가

alt 점검 관점

〈디지털 접근성 연구 034〉 — 이 글은 규정이 아니라 하나의 연구 관점입니다. 인용 수치·기준은 출처와 함께, 미확정 영역은 그렇다고 밝혀 작성합니다.

들어가며

앞의 두 편에서 대체텍스트가 무엇이며(032), 그것이 빠지면 어떤 막힘이 생기는지(033)를 살펴봤다. 이제 가장 실용적인 질문이 남는다. 우리 화면의 이미지엔 제대로 된 이름이 있는가? 이 질문에 "있을 것이다"가 아니라 "확인해 보니 이렇다"로 답하는 방법을 정리하는 것이 이번 편이다.

이번 편은 'C 점검' 관점이다. alt 점검은 함정이 많다. '있다/없다'는 자동 도구로 쉽게 세지만, 그것만으로는 '맞게 적혔는가'를 알 수 없기 때문이다. 자동 검사를 통과한 화면이 실제로는 막혀 있을 수 있고, 반대로 의도적으로 비운 장식 이미지가 '누락'으로 잘못 잡힐 수도 있다. 그래서 alt 점검은 기계와 사람의 손을 함께 써야 한다. 누구나 따라 할 수 있는 점검 동선을, 그 함정과 함께 정리한다.

1. 점검 전에 — alt의 세 가지 상태를 구분한다

alt 점검은 이미지를 세 가지 상태로 나누는 데서 시작한다. 이 구분이 흐릿하면 점검 결과도 흐릿해진다.

1-1. 채워야 할 이미지

정보를 담은 이미지와 기능 이미지(버튼·링크)다. 이들은 반드시 대체텍스트가 있어야 하고, 그 내용이 맥락에 맞아야 한다. 점검의 핵심 대상이다.

1-2. 비워야 할 이미지

순수 장식 이미지다. 빈 alt(alt="")로 두어 스크린리더가 건너뛰게 해야 한다. 이들이 '누락'으로 잡히면 안 된다. 비어 있는 것이 '맞는' 상태다.

1-3. 판단이 필요한 이미지

같은 이미지가 맥락에 따라 정보일 수도, 장식일 수도 있다. 이 경계의 이미지는 "여기서 이 그림이 하는 역할이 무엇인가"를 사람이 판단해야 한다. 점검에서 가장 시간이 드는 부분이다.

이 세 상태를 미리 염두에 두면, '비어 있다'를 무조건 '누락'으로 적는 실수를 피할 수 있다.

세 상태를 '바른 처리'와 '잘못 잡기 쉬운 점'과 함께 정리하면 다음과 같다.

상태	해당 이미지	바른 처리	잘못 잡기 쉬운 점
채워야 함	정보·기능 이미지	alt 채우고 맥락 맞춤	형식만 채우고 통과 처리
비워야 함	순수 장식	빈 alt(`alt=""`)	빈 것을 '누락'으로 오인
판단 필요	맥락 의존 이미지	역할 보고 결정	일괄 채움·일괄 비움

(인용) 세 상태 구분은 W3C WAI의 역할별 대체텍스트 결정 트리에 바탕을 둔다. 경계 판단은 맥락에 달려 있어 원문 확인을 권한다.

2. 점검 동선 — 기계와 사람을 함께 쓰는 순서

alt 점검은 자동 도구로 큰 그물을 친 뒤, 사람이 내용을 들여다보는 두 단계로 가는 것이 효율적이다.

2-1. 1단계 — 자동 도구로 'alt 없음'을 모은다

브라우저 개발자 도구나 접근성 검사 확장 프로그램으로, 대체텍스트 속성이 없는 이미지를 한 번에 찾는다. 이 단계는 '아예 빠진' 이미지를 빠르게 모으는 데 유용하다. 다만 자동 도구는 'alt가 있는지'만 보고 '내용이 맞는지'는 보지 못하므로, 여기서 끝내면 안 된다.

2-2. 2단계 — 스크린리더로 들어 본다

가장 중요한 단계다. 스크린리더(예: OS에 내장된 음성 안내 기능)를 켜고, 화면을 처음부터 따라 들어 본다. 이미지 자리에서 무엇이 읽히는지를 귀로 확인한다.

파일명이 읽히는가 → alt 누락(정보·기능 이미지면 막힘)
침묵하는가 → 장식이면 정상, 정보 이미지면 누락
엉뚱한 설명이 읽히는가 → 내용 부적절
기능이 아니라 생김새가 읽히는가 → 버튼·링크면 부적절

들어 보는 것은 자동 도구가 못 하는 '내용 점검'을 사람의 귀로 하는 일이다.

2-3. 3단계 — 역할별로 내용을 확인한다

들으며 걸러진 이미지들을 역할(정보·기능·장식)로 나눠, 각각의 대체텍스트가 그 역할에 맞는지 본다. 정보 이미지는 정보를 담고 있는가, 기능 이미지는 기능을 적었는가, 장식 이미지는 비어 있는가. 032편의 역할별 기준이 여기서 잣대가 된다.

2-4. 4단계 — 같은 패턴이 반복되는지 본다

한 이미지에서 문제를 찾으면, 같은 템플릿·컴포넌트·담당자의 다른 이미지도 함께 본다. alt 누락은 대개 패턴으로 반복되기 때문이다(033편). 한 곳을 고치는 점검보다, 반복되는 흐름을 찾는 점검이 효율적이다.

네 단계를, 누가(기계/사람) 무엇을 보는지와 함께 정리하면 다음과 같다.

단계	하는 일	담당	보는 것
1 자동 도구	'alt 없음' 모으기	기계	속성 유무
2 스크린리더 청취	실제 읽히는 내용	사람(귀)	내용 적정성
3 역할별 확인	정보·기능·장식 대조	사람	역할 부합
4 패턴 확인	반복 누락 추적	기계+사람	흐름의 빈틈

(관점) 1·4단계는 기계가 빠르게, 2·3단계는 사람이 정확히 본다. 어느 한쪽만으로는 '있는데 틀린 alt'를 잡지 못한다.

3. 점검에서 빠지기 쉬운 함정

alt 점검은 자동 도구에 기댈수록 함정에 빠지기 쉽다. 자주 마주치는 것들을 짚어 둔다.

3-1. 자동 검사 통과 = 안전이라는 함정

자동 도구는 'alt가 있는가'만 본다. "사진", "이미지", "돋보기 아이콘"처럼 형식상 채워졌지만 맥락에 맞지 않는 대체텍스트는 자동 검사를 통과한다. 자동 통과를 '안전'으로 읽으면, 정작 사용자를 막는 부적절한 alt가 그대로 남는다. 들어 보는 단계를 생략하면 이 함정에 빠진다.

3-2. 빈 alt를 무조건 '누락'으로 보는 함정

반대 함정이다. 장식 이미지의 의도적 빈 alt를 '누락'으로 잡아, 굳이 설명을 채우게 만드는 경우다. 그러면 32편의 '비워야 할 곳을 채운' 상태가 된다. 빈 alt가 누락인지 의도인지는, 그 이미지의 역할을 보고 판단해야 한다.

3-3. 캡션·주변 텍스트를 못 보는 함정

이미지 바로 옆 본문이나 캡션에 이미 같은 내용이 적혀 있으면, 대체텍스트가 짧거나 비어 있어도 정보는 전달된다. 이미지 하나만 떼어 보면 '부실'해 보여도, 맥락에서는 충분할 수 있다. 점검은 이미지를 주변과 함께 봐야 한다.

3-4. 점검자가 스크린리더에 서툴러 잘못 듣는 함정

스크린리더는 단축키와 읽기 방식이 익숙하지 않으면, 무엇이 왜 읽히는지 헷갈릴 수 있다. 점검자가 도구에 서툴면, 정상을 문제로 또는 문제를 정상으로 잘못 적는다. 점검 전에 스크린리더의 기본 조작(다음 요소 이동, 이미지 읽기)을 익혀 두는 것이 안전하다.

네 함정과, 각각을 피하는 점검 습관을 표로 둔다.

함정	잘못된 결론	피하는 습관
자동 통과=안전	부적절 alt를 안전으로	스크린리더 청취 병행
빈 alt=누락	장식까지 채우게 함	역할 보고 판단
캡션 못 봄	충분한데 부실로 기록	주변 텍스트와 함께 봄
점검자 서툼	정상↔문제 뒤바뀜	기본 조작 미리 익힘

(관찰) 네 함정 모두 '맥락을 떼어 놓고 본 것'에서 생긴다. alt는 이미지 하나가 아니라 그 자리의 역할·주변과 함께 봐야 한다.

4. 점검 결과를 어떻게 적을 것인가

alt 점검의 결과는 '몇 %에 alt가 있다'는 숫자로 끝내면 절반만 적은 것이다. 역할과 내용까지 담아야 다시 찾을 수 있다.

어디서: 어느 화면의 어느 이미지인가
역할: 정보 / 기능 / 장식 중 무엇인가
현재 상태: alt 없음 / 빈 alt / 채워짐 중 무엇인가
문제 유형: 누락 / 부적절 / 과잉 / (정상) 중 무엇인가
들은 내용: 스크린리더가 실제로 무엇을 읽었는가

특히 '들은 내용'을 적어 두면, 나중에 같은 자리를 다시 들어 확인할 수 있다. 우리는 alt 점검의 목적이 '커버리지 점수'를 올리는 데 있다고 보지 않는다. 듣는 사용자가 이미지를 통해 무엇을 얻거나 잃는지를 확인하고, 그 자리를 다시 찾을 수 있게 남기는 것 — 그것이 점검이 하는 일이다.

5. 점검을 '등록 흐름'으로 옮기기

alt 점검을 매번 사람이 다 듣는 방식은 한계가 있다. 이미지가 계속 추가되기 때문이다. 그래서 점검을 사후 검사가 아니라, 이미지를 올리는 순간의 흐름으로 옮기는 관점이 필요하다.

콘텐츠 관리 시스템(CMS)에서 이미지를 등록할 때 대체텍스트를 묻고, '장식'이라면 명시적으로 비울 수 있게 하면, 누락이 등록 단계에서 걸러진다. '무엇을 적어야 하는가'에 대한 팀 공통의 짧은 안내(정보는 정보를, 기능은 기능을, 장식은 비움)를 등록 화면 옆에 두면, 담당자마다 다른 품질을 줄일 수 있다. 033편에서 '결핍은 못 본 것'이라고 한 것과 같은 맥락이다 — 보이게 만들면, 빠지지 않는다.

자동 도구는 이 흐름을 보조한다. 등록 후 정기적으로 'alt 없음'을 모아 사람에게 알려 주면, 사람은 그 목록을 들어 보며 내용을 확인한다. 기계는 빠진 것을 모으고, 사람은 맞는지를 듣는 — 이 분업이 alt 점검을 지속 가능하게 한다.

사후 검사와 등록 흐름 점검의 차이를 정리하면 다음과 같다.

구분	사후 검사	등록 흐름 점검
시점	이미지 쌓인 뒤	올리는 순간
누락	계속 쌓임	단계에서 걸러짐
부담	매번 전수 청취	신규 분만 확인
품질	담당자마다 갈림	공통 안내로 균질

(관점) alt 점검의 종착지는 '쌓인 누락을 다 듣는 것'이 아니라 '올리는 순간 빠지지 않게 하는 것'이다. 보이게 만들면 빠지지 않는다.

5-1. 반론과 한계

점검 동선이 명확해도 모든 부적절 alt를 잡아내지는 못한다. 아래 반론을 함께 둔다.

가능한 반론	우리의 한계 인정	보완하는 태도
"전수 청취는 비현실적"	이미지 수가 많음	신규·대표 표본 우선
"역할 판단이 주관적"	경계는 모호	팀 기준으로 좁힘
"스크린리더마다 다르게 읽음"	도구별 차이 존재	같은 도구로 일관 점검

(한계) 이 글은 특정 사이트를 평가하지 않는다. 누구나 따라 할 수 있는 alt 점검 동선을 정리했을 뿐, 합격·불합격 판정은 실제 화면을 들어 본 뒤의 몫이다.

5-2. ViewCheck의 관점 — 사람과 도구의 분담

alt 점검에서, 자동 점검이 잘하는 자리와 사람이 봐야 하는 자리는 다음과 같다.

점검 항목	자동 점검이 보는 것	사람이 봐야 하는 것
alt 속성 유무	누락·파일명 노출 탐지	비운 게 맞는 장식인지
alt 내용 적정	(판정 어려움)	맥락에 맞는 설명인지
기능 이미지	버튼·링크 alt 유무	'기능'을 적었는지
반복 패턴	같은 템플릿 누락 집계	어느 흐름에서 반복되나

(관점) 도구는 '빠진 것'을 빠짐없이 모으고 반복 패턴까지 집계하지만, '맞는지 틀리는지'는 들어 본 사람만 가린다. 모으기는 기계가, 가리기는 사람이 맡는 분업이 점검을 지속 가능하게 한다.

한 장 요약

점검 단계	하는 일	함정
자동 도구	'alt 없음' 모으기	통과=안전으로 오인
스크린리더 청취	실제 읽히는 내용 확인	생략하면 부적절 alt 놓침
역할별 확인	정보·기능·장식 구분	빈 alt를 무조건 누락 처리
패턴 확인	반복 누락 추적	한 장만 보고 끝냄

맺으며

"우리 이미지엔 이름이 있는가"라는 질문에, 우리는 자동 통과율이 아니라 '실제로 무엇이 읽히는가'로 답하려 했다. alt 점검의 가장 정직한 방법은 스크린리더로 직접 들어 보는 것이다. 기계는 빠진 것을 빠르게 모으지만, 맞는지 틀리는지는 사람의 귀가 가린다.

대체텍스트는 보는 사람에게 보이지 않는 작업이라, 점검하지 않으면 결핍이 조용히 쌓인다. 그래서 우리는 점검을 사후 검사에 머물지 않고, 이미지를 올리는 흐름 안으로 옮기기를 권한다. 보이게 만들면 빠지지 않고, 들어 보면 어긋남이 드러난다. 다음 편부터는 이미지를 넘어, 화면 전체의 '구조' — 제목 계층과 마크업 — 가 스크린리더에게 어떻게 길을 안내하는지를 살펴본다.

다음 편 예고 (035): 035편은 'A 기준연구' 관점입니다. 스크린리더 사용자는 제목(heading)을 따라 화면을 빠르게 훑습니다. 제목 계층이라는 '지도'가 무엇이고, 시맨틱 마크업이 왜 길 안내가 되는지를 기준 연구의 시선으로 정리합니다.

참고한 공개 자료(출처):

W3C, Web Content Accessibility Guidelines (WCAG) 2.1 — 1.1.1 Non-text Content (원문 확인 권장)
W3C, WAI — Images Tutorial / 역할별 대체텍스트 결정 트리 (원문 확인 권장)
한국웹접근성 관련 지침(KWCAG) — 대체 텍스트 제공 관련 항목 (원문 확인 권장)
행정안전부, 「전자정부 웹사이트 품질관리 지침」 — 접근성 영역 (고시 원문 확인 권장)

※ 위 자료의 구체 조항·수치는 인용 시점과 버전에 따라 달라질 수 있어, 실제 적용 전 원문 확인이 안전합니다. 본 글은 연구·관점 정리이며 특정 기관의 평가가 아닙니다.