접근성 관점의 이모지·스티커: 스크린리더는 어떻게 읽는가
화면에는 웃는 얼굴 하나가 가볍게 보입니다. 하지만 스크린리더를 켠 독자에게는 그 그림이 전혀 다른 길이의 말로 들릴 수 있습니다.
워드프레스에 넣은 이모지와 캐릭터 스티커는 무엇으로 읽힐까요? 시각적으로 친근한 요소를 음성 환경에서도 부담 없이 전달하려면 어떻게 표시해야 할까요?
같은 그림이어도 읽히는 방식은 다릅니다
이모지는 글자처럼 다뤄지는 경우가 많습니다. 유니코드라는 문자 체계에 들어 있는 문자이거나, 여러 문자가 이어진 조합으로 처리됩니다.
유니코드에는 이모지마다 짧은 이름과 검색용 단어가 마련되어 있습니다. 이 이름이 음성으로 바뀌어 읽힐 수 있지만, 실제 표현은 사용자의 언어 설정과 기기 환경에 따라 달라질 수 있습니다.
반면 캐릭터 스티커는 대개 이미지입니다. 스크린리더는 그림 속 캐릭터를 직접 보는 것이 아니라, 이미지에 붙은 대체텍스트나 접근 가능한 이름을 읽습니다.
이모지는 자동 해석에 맡겨지는 글자에 가깝습니다. 스티커는 운영자가 읽힐 이름을 정해야 하는 그림에 가깝습니다.
같은 그림도 결과는 다릅니다.
화면에서 한 줄인 이모지가 귀에는 길게 들리는 이유
블로그 글을 읽던 한 독자가 이모지를 여러 개 만났다고 생각해 보겠습니다. 눈으로는 웃는 얼굴 다섯 개가 한눈에 지나가지만, 스크린리더는 그것을 차례로 읽을 수 있습니다.
NVDA 프로젝트의 공개 이슈에는 반복된 이모지를 하나씩 읽어 발화가 길어지는 문제가 다뤄졌습니다. 2018년 7월 11일에 등록된 이 사례는 장식처럼 보이는 반복이 음성 환경에서는 큰 읽기 부담이 될 수 있음을 보여 줍니다.
W3C도 이모지의 기본 이름이 글쓴이가 의도한 의미와 다를 수 있다고 설명합니다. 글쓴이는 “괜찮아요”라는 뜻으로 이모지를 넣었지만, 음성으로는 그 모양의 이름만 전달될 수 있습니다.
눈에 보이는 뜻과 들리는 뜻이 어긋나는 것입니다.
그래서 블로그 운영자는 “예쁘게 보이면 충분하지 않을까?”라는 질문을 다시 하게 됩니다.
이모지는 자동으로 읽히지만 의미까지 보장하지는 않습니다
한 줄로 답하면 이렇습니다. 이모지는 기기와 음성합성기가 해석한 이름으로 읽힐 수 있지만, 캐릭터 스티커는 대체텍스트가 사실상 전부입니다.
이모지는 읽힌다고 끝이 아닙니다.
같은 이모지도 사용자의 언어와 구현 환경에 따라 다른 이름으로 읽힐 수 있습니다. 새로운 이모지나 조합이 추가되면 버전에 따라 해석 방식도 달라질 수 있습니다.
그래서 문장에 꼭 필요한 의미를 이모지 하나에만 맡기는 일은 조심해야 합니다. 모양보다 이 요소가 독자에게 어떤 뜻을 전달해야 하는지를 먼저 정해야 합니다.
이모지의 기본 이름이 문맥과 맞지 않는다면, 역할과 이름을 직접 정해 설명할 수도 있습니다. W3C는 이런 경우 그림 역할을 지정하고, 접근 가능한 이름을 제공하는 방법을 안내합니다.
대체텍스트는 짧게, 역할에 맞게 써야 합니다
접근성에서 가장 중요한 기준은 이모지나 스티커가 정보를 더하는지입니다. 단순히 화면을 꾸미는지, 내용을 설명하는지, 클릭할 기능을 갖는지를 나눠 보세요.
- 장식용: 본문 뜻을 바꾸지 않으면 읽히지 않게 합니다.
- 정보성: 문맥에 필요한 의미를 짧게 설명합니다.
- 기능성: 모양이 아니라 버튼이나 링크의 목적을 적습니다.
장식용 스티커라면 이미지의 대체텍스트를 빈 값으로 둘 수 있습니다. 설명을 붙이면 스크린리더가 불필요한 말을 더 읽어 본문 흐름이 끊길 수 있기 때문입니다.
장식은 조용해야 합니다.
반대로 정보성 이미지라면 중요한 내용을 짧게 적어야 합니다. 주변 문장이 이미 같은 뜻을 설명한다면 빈 대체텍스트로 중복 낭독을 막는 편이 낫습니다.
클릭 가능한 캐릭터라면 “웃는 캐릭터”라고 쓰지 마세요. “댓글 보기”나 “다음 글로 이동”처럼 그 요소가 하는 일을 적어야 합니다.
기능성 이미지는 모양보다 목적이 먼저입니다.
접근성을 고려한 글 구성과 DecoBlocks
접근성을 점검한 뒤에도 글의 시각적 흐름을 정리할 수 있습니다. DecoBlocks는 워드프레스 글에 말풍선, 상자, 강조, 목차, 장식 효과 등을 넣는 플러그인입니다. Section Box (Solid)로 안내나 주의 내용을 묶고 Divider Line – Solid로 구역을 나눌 수 있습니다.
스티커를 넣을 때는 Insert Character Sticker로 설치한 스티커 팩의 캐릭터 스티커를 추가할 수 있습니다. 다만 스티커가 장식용인지 정보성인지 기능성인지는 운영자가 따로 판단해야 하며, 대체텍스트와 접근 가능한 이름도 그 역할에 맞게 정해야 합니다.
직접 고칠 때 가장 자주 막히는 지점
실제로 막히는 곳은 워드프레스에 이미지를 넣은 다음입니다. 파일 이름을 대체텍스트처럼 사용하거나, 캐릭터의 생김새를 길게 설명하거나, 장식용 이미지마다 같은 말을 반복해 넣기 쉽습니다.
이모지를 여러 개 붙여 감정을 표현한 문장은 더 어렵습니다. 화면에서는 귀엽지만, 스크린리더에서는 같은 이름이 연속으로 낭독되어 독자가 본문에 도착하기까지 기다려야 할 수 있습니다.
귀여움이 읽기 부담이 되기도 합니다.
직접 확인할 때의 한계도 있습니다. 내 컴퓨터에서 한 번 자연스럽게 들렸다고 해서 모든 방문자에게 같은 소리가 보장되지는 않습니다.
브라우저, 운영체제, 스크린리더, 음성합성기의 조합에 따라 읽히는지와 표현이 달라질 수 있습니다. 대체텍스트를 생략하면 일부 스크린리더가 파일명을 읽을 수도 있습니다.
반대로 접근성을 챙긴다며 장식용 스티커에 설명을 붙이면 낭독이 더 길어집니다. 좋은 설명은 많이 쓰는 설명이 아니라, 필요한 역할만 남긴 설명입니다.
자동 검사는 의미까지 대신 정하지 못합니다.
자동 검사가 의미를 정하지 못한다면, 글의 시각적 구조와 문장의 의미를 각각 점검하는 방식이 필요합니다. DecoBlocks의 Auto Table of Contents는 게시 후 글의 H2와 H3 제목을 바탕으로 목차를 만듭니다.
긴 글에서 구역을 파악하는 데 필요한 제목 구조를 목차로 보여 줄 수 있습니다. 목차나 상자 같은 장식은 대체텍스트와 접근 가능한 이름을 대신 정하지 않으므로, 그 판단은 별도로 진행해야 합니다.
내 글에서는 무엇을 어떻게 정하면 될까
먼저 글 속 이모지와 스티커를 세 부류로 나누세요. 장식용이면 읽히지 않게 하고, 정보성이면 의도한 의미를 짧게 적고, 기능성이면 클릭 후 일어나는 일을 적습니다.
감정이나 상태를 보충하는 이모지는 모양의 이름보다 문맥을 기준으로 생각하세요. 예를 들어 독자가 알아야 할 것이 “웃는 얼굴”이 아니라 “축하하는 마음”이라면, 전달할 의미도 그쪽에 맞춰야 합니다.
반복은 줄이는 것이 안전합니다. 문장 끝에 같은 이모지를 여러 번 이어 붙이기보다, 필요한 감정이나 상태를 짧은 말로 함께 적는 편이 음성 환경에서 분명합니다.
반복보다 문장이 분명합니다.
게시한 뒤에는 NVDA나 VoiceOver 중 하나로 실제 낭독을 들어 보세요. 장식은 조용히 지나가는지, 정보는 뜻이 맞는지, 버튼은 목적을 말하는지 확인하면 됩니다.
결국 기준은 “화면에서 예쁜가”가 아닙니다. “보이지 않는 독자도 같은 뜻과 기능을 받을 수 있는가”가 기준입니다.
같은 뜻과 기능이 핵심입니다.
이모지와 스티커를 사용할 때는 화면의 장식보다 독자가 받아야 할 의미와 기능을 먼저 정해야 합니다. 그다음 실제 스크린리더로 낭독을 확인하고, 필요한 구역만 시각적으로 정리하면 됩니다.
DecoBlocks는 말풍선, 상자, 목차, 구분선, 캐릭터 스티커를 워드프레스 글에 넣어 이런 구성 작업을 돕습니다. 다만 접근 가능한 이름과 대체텍스트의 판단은 각 요소의 역할에 맞게 운영자가 직접 해야 합니다.
자주 묻는 질문
Q. 내 사이트에서는 이모지와 스티커를 어떻게 나눠 점검하면 되나요?
A. 먼저 장식용, 정보성, 기능성으로 나누세요.
장식용은 읽히지 않게 하고, 정보성은 필요한 의미를 짧게 적으며, 기능성은 클릭 후 일어나는 일을 적습니다. 게시 뒤에는 NVDA나 VoiceOver로 실제 낭독을 확인하세요.
Q. 워드프레스의 이모지는 스크린리더에서 항상 같은 말로 읽히나요?
A. 아닙니다. 언어 설정과 브라우저, 운영체제, 스크린리더, 음성합성기의 조합에 따라 읽히는 이름과 표현이 달라질 수 있습니다.
Q. 이 문제를 도구로 쉽게 해결할 수 있나요? 어떤 도구를 쓰면 되나요?
A. 접근성 검사 도구와 스크린리더를 함께 사용할 수 있습니다. 다만 자동 검사만으로는 문맥상 의미를 판단하기 어려우므로, 게시 후 실제 낭독도 들어 보는 것이 안전합니다.
Q. 접근성 점검을 마친 긴 글의 구조는 어떻게 보여 주면 되나요?
A. 먼저 제목 단계와 문장 흐름을 정리한 뒤 필요한 구역만 시각적으로 나누면 됩니다.
DecoBlocks의 Auto Table of Contents는 게시 후 H2와 H3 제목을 바탕으로 목차를 만들고, Section Box (Solid)는 관련 내용을 상자 안에 묶어 보여 줍니다. 목차와 상자는 스크린리더가 읽을 이름이나 대체텍스트를 대신 정하는 기능이 아니므로, 이미지와 기능 요소의 의미는 따로 점검해야 합니다.
워드프레스 관련 플러그인
