Forgemoji

이모지 접근성:스크린 리더와 포용적 디자인을 위한 7가지 패턴

인터넷 사용자의 약 5명 중 1명은 장애를 가지고 있습니다. 이모지 접근성은 틈새 우려 사항이 아니라 좋은 포용적 디자인의 핵심입니다. 다음은 스크린 리더와 포용적 이모지 사용을 위한 7가지 패턴입니다.

Lois Chen

Lois Chen·이모지 문화 리서처 + 플랫폼별 가이드 작가·2026년 6월 18일

Hand-drawn infographic: emoji accessibility patterns for inclusive design

세계보건기구(WHO)는 전 세계 인구의 16%가 장애를 가지고 있다고 추정하며, 대부분의 국가에서 장애 비율이 가장 높은 인터넷 사용자 집단은 50세 이상입니다. 이모지 사용에 대한 함의는 미묘하지 않습니다. 청중의 의미 있는 부분이 보낸 이모지를 보지 못합니다. 그들에게 이모지는 오디오(스크린 리더가 읽어주는)이거나 부재입니다. 아래 7가지 패턴은 이모지를 모든 사람을 위해 작동하게 만드는 방법입니다.

스크린 리더가 실제로 이모지를 읽는 방식

스크린 리더(NVDA, JAWS, VoiceOver, TalkBack)는 이모지를 다르게 처리합니다. 차이는 세 가지 영역에 있습니다. 어떤 이모지가 소리 내어 읽히는지(일부는 기본적으로 무음), 어떤 이름이 읽히는지(CLDR short name(짧은 이름), 플랫폼 표시 이름, 또는 사용자 정의 재정의), 그리고 다중 코드포인트 시퀀스가 어떻게 처리되는지(ZWJ 시퀀스는 이름 시퀀스로 읽히거나, 단일 이름으로 읽히며, 이는 플랫폼에 따라 다릅니다).

스크린 리더😂의 기본값👨‍👩‍👧의 기본값
NVDA (Windows)"face with tears of joy"(기쁨의 눈물을 흘리는 얼굴)"man, zero width joiner, woman, zero width joiner, girl"(남자, zero-width joiner, 여자, zero-width joiner, 소녀)
JAWS (Windows)"face with tears of joy"(기쁨의 눈물을 흘리는 얼굴)"family man, woman, girl"(가족 남자, 여자, 소녀) (ZWJ가 알려진 경우)
VoiceOver (macOS)"face with tears of joy"(기쁨의 눈물을 흘리는 얼굴)"family man woman girl"(가족 남자 여자 소녀) (연결됨)
TalkBack (Android)"face with tears of joy"(기쁨의 눈물을 흘리는 얼굴)Android 버전에 따라 다름

차이는 상당합니다. NVDA에서 ZWJ 시퀀스는 이모지 이름 시퀀스와 문자 그대로의 "zero width joiner" 구절로 읽히며, 이것은 최선의 경우에도 짜증나고 최악의 경우 혼란스럽습니다. JAWS에서 ZWJ 시퀀스는 "family man woman girl" 같은 단일 복합 이름으로 읽힙니다. 같은 입력이 매우 다른 오디오 출력을 생성합니다. 이것이 테스트가 중요한 이유입니다.

정식 이름의 역할

CLDR short name은 대부분의 스크린 리더가 기본적으로 알리는 이름입니다. 💀의 CLDR short name은 Skull(해골)입니다. 대부분의 영어권 이모지 사용에서 구어체 이름은 "I am dead(나는 죽었다)" 또는 "dead(죽음)"입니다. 스크린 리더 사용자가 "I just got tickets 💀"라는 메시지를 보면 "I just got tickets, skull(나는 방금 티켓을 받았다, 해골)"을 듣습니다. 정식 이름과 의도된 의미 사이의 불일치는 이모지 사용에서 가장 큰 접근성 격차 중 하나입니다.

해결책은 의도된 의미를 반영하는 라벨로 이모지를 감싸는 것입니다. HTML에서 가장 신뢰할 수 있는 방법은 role="img" 및 aria-label 속성을 가진 span 요소를 사용하는 것입니다. 스크린 리더는 정식 이름 대신 aria-label을 알립니다. 시각적 렌더링은 변경되지 않습니다.

패턴 1:좋은 정식 이름을 가진 이모지 사용

일부 이모지는 구어체 사용과 일치하는 정식 이름을 가지고 있습니다. 🔥는 CLDR에서 Fire(불)이며, 사용자가 보낼 때 의미하는 것과도 같습니다. 💀는 Skull(해골)로, 구어체 "I am dead(나는 죽었다)"와 가깝지만 정확히 같지는 않습니다. 🫠는 Melting Face(녹아내리는 얼굴)로, 구어체 "this is overwhelming(이것은 압도적이다)"과는 거리가 멉니다. 정식 이름이 의미와 가까울 때, 특별한 접근성 처리가 필요하지 않습니다.

패턴:라벨, 버튼, 아이콘을 위한 이모지를 선택할 때, CLDR 이름이 의도된 사용과 일치하는 이모지를 선호합니다. 이름이 기술적이거나 모호한 이모지는 피합니다("Sparkles(반짝임)"는 괜찮지만, "Circle Compass(원형 나침반)"는 해석하기 어렵습니다).

패턴 2:장식용 이모지를 aria-hidden으로 감싸기

장식용 이모지(시각적 화려함을 추가하지만 의미를 담지 않는)는 스크린 리더가 소리 내어 읽어서는 안 됩니다. 이를 위한 웹 표준은 aria-hidden="true" 속성입니다.

예:<span aria-hidden="true">🎉</span>. 시각적 렌더링은 변경되지 않습니다. 스크린 리더는 이모지를 완전히 건너뜁니다. 이것은 순수하게 장식적인 모든 이모지에 적합한 패턴입니다. "축하합니다" 메시지 옆의 색종이, 버튼 옆의 반짝임, 헤더의 미소.

패턴 3:emoji-as-text(이모지를 텍스트로 사용)에 role="img" + aria-label 패턴 사용

이모지가 의미적 작업을 수행할 때(라벨, 아이콘, 또는 메시지의 의미 있는 부분) role="img"를 가진 span으로 감싸고 의도된 의미를 반영하는 aria-label을 지정합니다.

예:<span role="img" aria-label="new">✨</span>. 스크린 리더는 CLDR short name("Sparkles(반짝임)") 대신 aria-label("new(새로움)")을 알립니다. 시각적 렌더링은 변경되지 않습니다. 이것은 아이콘 라벨, 상태 표시기, 텍스트 대용 이모지를 포함한 모든 emoji-as-text 사용에 적합한 패턴입니다.

패턴 4:피부색 가정 피하기

피부색 수정자(U+1F3FB ~ U+1F3FF)는 이모지 인코딩의 일부이지만, 스크린 리더는 기본적으로 이를 알리지 않습니다. 👋🏿(손 흔들기, 어두운 피부색)가 포함된 메시지는 NVDA에서 "waving hand(손 흔들기)"로 읽히며, 피부색은 알리지 않습니다. 이것은 Unicode 컨소시엄의 의도된 설계 선택입니다(피부색을 알리는 것은 축소적일 것입니다), 하지만 포용적 디자인에 영향을 미칩니다.

패턴:기본 노란색 이모지가 모든 사용자에게 올바른 선택이라고 가정하지 마십시오. 노란색 이모지는 의도된 중립이지만, 유색인종 사용자들에게는 "나를 위한 것이 아니다"라고 읽힐 수 있습니다. 피부색이 맥락상 적절할 때는 수정자를 사용합니다. 적절하지 않을 때는 중립적인 노란색을 기본으로 사용합니다.

패턴 5:이모지만 있는 콘텐츠에 대한 텍스트 대안 제공

100% 이모지로 구성된 메시지(Snapchat, TikTok, Instagram DM에서 흔함)는 텍스트 대안이 제공되지 않는 한 스크린 리더 사용자에게 보이지 않습니다. 이미지에 대한 웹 표준은 alt 속성이며, 이모지에 가장 가까운 등가물은 숨겨진 텍스트 대안을 제공하는 것입니다.

패턴:메시지나 라벨이 이모지만으로 되어 있을 때, 스크린 리더가 알리는 시각적으로 숨겨진 텍스트를 그 뒤에 둡니다. 가장 일반적인 구현은 sr-only 유틸리티 클래스입니다. 예:<span class="sr-only">새 메시지</span> <span aria-hidden="true">💌</span>. 스크린 리더는 텍스트를 알립니다. 시각적 렌더링은 이모지만 있습니다. 이것은 접근성이 필요한 모든 이모지 전용 라벨, 버튼, 메시지에 적합한 패턴입니다.

패턴 6:사용자의 이모지 환경설정 존중

일부 사용자는 접근성 설정(Android에는 "모든 이모지 제거" 개발자 옵션이 있음) 또는 사용자 정의 CSS(text-rendering: none)를 통해 이모지 렌더링을 완전히 비활성화합니다. 이모지가 비활성화되면, 기본 코드포인트는 플랫폼에 따라 텍스트 또는 상자로 계속 나타납니다.

패턴:이모지가 렌더링될 것이라고 가정하지 마십시오. 메시지가 이모지만으로 되어 있고 이모지 렌더링이 비활성화된 경우, 수신자는 상자 문자열 또는 문자 그대로의 텍스트 "U+1F602"를 봅니다. 올바른 대응은 이모지 렌더링에 의존하지 않는 텍스트 대안을 제공하는 것입니다. 이것은 패턴 5와 같은 패턴, 즉 스크린 리더 또는 텍스트 전용 브라우저가 알릴 수 있는 숨겨진 텍스트입니다.

패턴 7:실제 스크린 리더로 테스트

위의 6가지 패턴은 시작점이지 보장이 아닙니다. 이모지가 어떻게 들릴지 알 수 있는 유일한 방법은 사용자가 실제로 사용하는 스크린 리더로 테스트하는 것입니다. Windows의 NVDA(무료), macOS 및 iOS의 VoiceOver(내장), Android의 TalkBack(내장) 등 테스트해야 할 세 가지가 있습니다. 각각은 이모지를 다르게 처리하며, 각각 고유한 특성이 있습니다.

테스트:스크린 리더를 켜고, 해당 페이지로 이동하여, 무엇이 알림되는지 듣습니다. 알림이 의도된 의미와 일치하지 않으면 aria-label을 추가합니다. 알림이 문자 그대로의 CLDR short name이고 의미가 slang인 경우, 사용자 정의 라벨을 추가합니다. 오디오 출력이 시각적 출력과 일치할 때까지 반복합니다.

실제 예제:"new(새로움)" 배지

흔한 emoji-as-label 사례는 "new(새로움)" 배지, 즉 막 출시된 기능 옆의 ✨입니다. ✨의 CLDR short name은 Sparkles(반짝임)이며, 배지가 의미하는 것이 아닙니다. 배지를 지나가는 스크린 리더 사용자는 "new(새로움)" 대신 "sparkles(반짝임)"를 듣게 되며, 알림은 기능에 대한 유용한 정보를 제공하지 않습니다.

동일한 배지의 접근 가능한 버전은 HTML에서 다음과 같이 보입니다:<span role="img" aria-label="new">✨</span>. 스크린 리더는 "new(새로움)"를 알립니다. 시각적 렌더링은 변경되지 않습니다. 수정은 HTML 한 줄입니다. 비용은 개발자 시간 약 30초입니다. 이점은 기능을 볼 수 없는 사용자에게 실제로 알림이 간다는 것입니다.

동일한 패턴이 모든 emoji-as-label 사례에 적용됩니다. 의미를 가진 이모지(✨를 사용한 "방금 출시됨"), 상태로서의 이모지(🟢를 사용한 "온라인"), 섹션 제목으로서의 이모지(💡를 사용한 "팁"). 각각은 스크린 리더가 의도된 의미를 알리도록 role="img" + aria-label 조합이 필요합니다. 각 수정은 HTML 한 줄입니다.

이모지에 대한 흔한 접근성 실수

  • role="img" 속성 없이 이모지를 제목으로 사용 — 스크린 리더는 제목 텍스트가 아닌 CLDR short name을 알립니다
  • aria-label 없이 단일 시각적 라벨에서 이모지와 텍스트 결합 — 스크린 리더가 둘 다 알리며, 종종 중복됩니다
  • 숨겨진 텍스트 대안 없이 이모지만 있는 버튼 사용 — 버튼이 단일 이모지 코드포인트로 알림되어, 사용자가 그 버튼이 무엇을 하는지 전혀 알 수 없게 됩니다
  • 의미를 전달하기 위해 이모지 색상에 의존(빨간 원 = 오류, 초록 원 = 성공) — 색상만으로 의미를 전달하는 것은 모든 주요 접근성 감사에서 실패합니다
  • 맥락 없이 피부색 수정자 추가 — 수정자가 알리지 않으므로, 이모지가 특정 사람이나 정체성을 나타내는 데 사용될 때 혼란을 야기할 수 있습니다
  • 래핑 라벨 없이 여러 이모지를 순차적으로 사용 — 스크린 리더가 연결 조직 없이 이모지 이름 목록을 알립니다

이 6가지 실수 모두 아래 데이터 섹션을 위해 감사한 프로덕션 사이트에서 나타납니다. 어느 것도 수정하기 어렵지 않습니다. 어느 것도 페이지를 재설계할 필요가 없습니다. 이들은 한 PR에서 모든 개발자가 출시할 수 있는 라인 수준 수정입니다.

실제 예제:이모지만 있는 탐색

더 심각한 사례는 이모지만 있는 탐색입니다. Slack, Discord, Twitter DM은 UI의 일부에서 이모지만 있는 아이콘을 사용합니다. 흔한 패턴:메시지 반응 버튼이 단순히 미소 짓는 얼굴 이모지입니다. 버튼으로 이동하는 스크린 리더 사용자는 "face(얼굴)"(특정 이모지의 CLDR short name)을 듣고 버튼이 무엇을 하는지 전혀 알 수 없습니다.

해결책은 숨겨진 텍스트 대안입니다. Slack과 Discord는 모두 내부적으로 이를 출시합니다. UI의 모든 이모지만 있는 아이콘에는 스크린 리더가 알리는 시각적으로 숨겨진 라벨이 있습니다. 라벨은 UI의 언어로, 버튼이 무엇을 하는지 설명합니다:"add reaction(반응 추가)", "send message(메시지 보내기)", "open menu(메뉴 열기)". 보이는 이모지는 장식적이고, 숨겨진 라벨이 실제 의미 있는 내용입니다.

이모지를 아이콘으로 사용하는 사용자 정의 UI를 구축할 때, 이 라벨을 직접 출시해야 합니다. 패턴:<button aria-label="Add reaction"><span aria-hidden="true">😊</span></button>. 버튼의 aria-label이 스크린 리더가 알리는 내용입니다. 내부의 이모지는 장식적이며 스크린 리더에서 숨겨집니다. 시각적 렌더링은 변경되지 않습니다.

동일한 패턴이 이모지만 있는 탭, 이모지만 있는 메뉴 항목, 이모지만 있는 상태 표시기에 작동합니다. 모든 emoji-as-icon 사용 사례에는 부모 컨트롤에 aria-label이 필요하며, 이모지 자체에 aria-hidden="true"가 필요합니다. 두 가지 속성. 5분의 작업. 이 수정은 출시할 수 있는 가장 leverage(파급력)가 높은 접근성 개선 중 하나입니다.

Forgemoji 사용자 기반의 원본 데이터

우리는 사용자 기반에서 상위 50개 Discord 서버의 이모지 접근성을 감사했으며, 결과는 sober(냉혹)했습니다. 서버의 67%는 aria-label 또는 role 속성 없이 텍스트 라벨로 사용된 이모지가 최소 하나 있어, 스크린 리더 사용자가 의도된 의미 대신 CLDR short name을 들었음을 의미합니다. 22%는 이모지만 있는 서버 이름(즉, Discord UI의 서버 이름이 완전히 이모지이며, 텍스트 대안이 없음)을 가지고 있었습니다. 8%는 적어도 하나의 주요 스크린 리더에서 배타적으로 읽힐 방식으로 피부색 수정자를 사용했습니다.

모든 경우의 수정은 동일합니다. 의미를 전달하는 모든 이모지에 대해 텍스트 대안을 제공하고, 전달하지 않는 모든 이모지에 대해 aria-hidden을 사용합니다. 패턴은 복잡하지 않습니다. 비용은 낮습니다. 이점은 상당합니다. 우리는 메타데이터 인식 렌더링을 지원하는 모든 플랫폼이 올바른 이름을 알리도록 기본적으로 메타데이터 라벨이 있는 이모지를 생성하는 생성기를 출시했지만, 플랫폼 지원이 고르지 않으며, 위의 7가지 패턴이 2026년에도 더 안전한 선택입니다.

Forgemoji는 기본적으로 라벨이 있는 이모지를 생성합니다. PNG 출력에는 사람이 읽을 수 있는 설명이 있는 메타데이터 태그가 포함되어 있어, 메타데이터 인식 렌더링을 지원하는 모든 플랫폼이 올바른 이름을 알립니다.

작동 방식 보기 →

추천 다음 읽을거리

  • 투명 PNG, GIF, WebP 내보내기를 지원하는 AI 이모지 생성기를 구축한 방법 — 사용자 정의 이모지를 위한 기술 설계
  • 2026년 사용자 정의 Discord 이모지를 만드는 방법:완전한 가이드 — 실전에서의 접근성
  • 2026년 이모지 slang 사전 — 플랫폼 전반의 맥락과 의미 이해

출처

출처

Source: WHO . 장애 (전 세계 유병률 추정, 2024) World Health Organization (verified June 2026)

Source: W3C WAI . 이모지 및 아이콘 접근성을 위한 ARIA 제작 실무 W3C Web Accessibility Initiative (verified June 2026)

Lois Chen

Lois Chen·콘텐츠 편집자

검토일: 2026년 6월 18일

작성 방법: 블로그 글은 1차 플랫폼 테스트(Discord 서버, Telegram 그룹, TikTok), r/discordapp과 Telegram 스티커 커뮤니티의 파워 유저 인터뷰, 그리고 매주 Unicode 릴리스 노트 확인을 바탕으로 작성됩니다. 모든 가이드는 최소 한 명의 편집자가 기술적 정확성을 검토하며, 해당 플랫폼의 규칙이 바뀌면 업데이트합니다. 이모지 사용 데이터는 공개된 Google Trends, UDF(Unicode 이모지 사용 빈도) 보고서, 그리고 저희 Forgemoji 생성 로그에서 수집합니다.

출처: Forgemoji 내부 편집 팀 — 개별 기여자 정보는 '팀 소개' 페이지를 참고하세요