대문자만 쓴 글(ALL CAPS)과 접근성: 가독성이 떨어지는 이유
영문을 전부 대문자로 쓰는 방식(ALL CAPS)은 두 단어짜리 레이블에는 괜찮지만, 그보다 긴 글에는 좋지 않은 선택입니다. 대문자가 길게 이어지면 읽는 속도가 느려지고, 일반적인 대소문자 표기가 담고 있던 정보가 사라집니다(“US”는 미국일까요, “us”일까요?). 게다가 스크린 리더는 대부분 대소문자를 무시하기 때문에 의도한 강조는 사라지고, 오히려 짧은 단어 몇 개가 한 글자씩 읽히기도 합니다. 접근성을 지키려면 텍스트는 일반적인 대소문자로 쓰고, 디자인상 정말 대문자가 필요한 곳에만 CSS로 대문자를 적용하세요. 다만 이 방법도 완벽하지는 않습니다.
대문자가 길게 이어지면 읽기 어려운 이유
연구자들은 거의 한 세기 동안 대문자로 읽을 때와 소문자로 읽을 때를 비교해 왔습니다. Kevin Larson이 Microsoft에 쓴 글 “The Science of Word Recognition”은 1938년 Woodworth까지 거슬러 올라가는 연구들을 정리하고 있는데, 같은 글을 대문자로 조판했을 때보다 소문자로 조판했을 때 독자들이 5~10% 더 빨리 읽었습니다.
흔히 드는 설명은 ‘단어 모양(word shape)’입니다. 소문자 단어는 위아래로 튀어나온 획(어센더와 디센더) 덕분에 저마다 독특한 윤곽을 갖지만, 대문자는 모든 단어를 직사각형으로 만들어 버린다는 것이죠. Larson은 근거가 이 설명을 뒷받침하지 않는다고 말합니다. 우리는 단어를 이루는 글자를 보고 단어를 알아보며, 소문자가 유리한 주된 이유는 소문자를 그만큼 많이 읽어 왔기 때문이라는 것입니다. 대문자를 많이 읽게 하면 사람들은 대문자도 더 빨리 읽게 됩니다.
유용한 바로잡기지만, 그렇다고 사이트에 올린 대문자 단락이 괜찮아지는 것은 아닙니다. 여러분의 독자는 그런 연습을 해 본 적이 없고, 그 부담은 원래 읽기를 힘들어하는 사람들에게 가장 크게 돌아갑니다. MDN의 text-transform 페이지는 대문자로 된 긴 텍스트가 “may be difficult for people with cognitive concerns such as Dyslexia to read”(난독증 같은 인지적 어려움이 있는 사람은 읽기 어려울 수 있다)고 경고합니다. GOV.UK 스타일 가이드는 이 점을 직접 보여 줍니다. “DO NOT USE BLOCK CAPITALS FOR LARGE AMOUNTS OF TEXT AS IT'S QUITE HARD TO READ.”(긴 텍스트를 대문자로 쓰지 마세요. 꽤 읽기 어렵습니다.)
대문자는 정보를 지워 버립니다
대문자와 소문자를 섞어 쓰는 것은 장식이 아닙니다. 대문자는 그 단어가 이름인지, 약어인지, 문장의 시작인지 알려 줍니다. 다음 문장을 읽으면서 얼마나 많은 것을 짐작해야 하는지 느껴 보세요.
PLEASE CONTACT US ABOUT POLISH ORDERS IN MARCH. NASA SAYS HI.미국(United States)일까요, 우리(us)일까요? 폴란드(Poland) 고객일까요, 가구 광택제(polish)일까요? 3월(March)일까요, 시위 행진(march)일까요? 한번 대문자로 입력된 텍스트에서는 소프트웨어도 답을 되살릴 수 없습니다. 이 줄을 저희 대소문자 변환기의 ‘문장 형식’(Sentence case) 옵션으로 변환하면 “Please contact us about polish orders in march. Nasa says hi.”가 나옵니다. 모든 글자를 소문자로 바꾸고 각 문장의 첫 글자만 대문자로 만드는데, 변환기가 알 수 있는 것은 그것뿐이기 때문입니다. 이름은 직접 다시 고쳐야 합니다.
스크린 리더는 대문자 텍스트를 어떻게 읽을까
대부분은 아무 처리도 하지 않습니다. 스크린 리더는 단어를 읽어 줄 뿐 대소문자는 언급하지 않습니다. 2022년 접근성 컨설턴트 Adrian Roselli가 대문자로 된 법률 문구를 JAWS, NVDA, Narrator, Orca, VoiceOver, TalkBack에서 기본 설정으로 테스트했는데, 텍스트가 대문자라고 알려 준 스크린 리더는 하나도 없었습니다. NVDA의 음높이 변경이나 “say cap” 같은 옵션은 텍스트를 한 글자씩 이동하며 읽을 때를 위한 것이지, 문장을 소리 내어 읽을 때를 위한 것이 아닙니다.
여기서 두 가지 결과가 생깁니다.
- 의미를 담은 대문자가 사라집니다. 대문자로 ‘이건 중요하다’를 표현했다면(경고, 계약 조항, 외치는 단어 등) 듣는 사람에게는 평범한 텍스트로 들립니다. 예외는 점자 사용자입니다. 점자에는 대문자 기호가 있기 때문입니다.
- 짧은 단어 일부는 한 글자씩 읽힙니다. 음성 엔진은 대문자 덩어리가 약어인지 아닌지 추측합니다. Roselli는 스크린 리더가 대문자일 때 흔히 한 글자씩 읽는 단어로 “AM”, “ADD”, “IT”를 꼽았고, 실무자들은 “CONTACT US”가 “contact U.S.”로 읽혔다고 보고했습니다.
어떤 단어가 한 글자씩 읽히는지는 스크린 리더, 음성, 사용자 설정, 때로는 브라우저에 따라 달라지고, 버전이 바뀔 때마다 변합니다. 확실하게 예측할 수 없다는 점이야말로 중요한 단어를 처음부터 대문자로 쓰지 말아야 할 가장 좋은 이유입니다.
자간을 공백으로 흉내 내지 마세요
넓게 띄운 대문자는 인기 있는 디자인 요소지만, S A L E처럼 띄어 입력하는 것은 그 모양을 내는 가장 나쁜 방법입니다. 스크린 리더는 글자를 하나씩 따로 읽고, WCAG는 “using white space characters to control spacing within a word”(단어 안의 간격을 공백 문자로 조절하는 것)를 실패 사례로 꼽습니다(기법 F32). 아래 예시처럼 CSS letter-spacing을 쓰세요.
대문자를 입력하지 말고 CSS text-transform: uppercase를 쓰세요
버튼, 탭, 작은 제목을 대문자처럼 보이게 하고 싶다면 텍스트는 일반적인 대소문자로 쓰고, 보이는 모양만 CSS로 바꾸세요.
<button class="caps">Add to basket</button>
.caps {
text-transform: uppercase;
letter-spacing: 0.06em; /* capitals need a little extra room */
}HTML 안의 텍스트는 “Add to basket” 그대로 남고, 덕분에 몇 가지 이점이 생깁니다.
- 디자인을 바꾸기 쉽습니다. 나중에 대문자를 없애려면 CSS 한 줄만 고치면 됩니다. 모든 레이블과 번역 파일을 뒤질 필요가 없습니다.
- 텍스트가 어디로 가든 문제없습니다. 피드, 내보낸 파일 등 스타일시트가 닿지 않는 곳에도 대소문자가 제대로 된 단어가 전달됩니다.
- 언어별 규칙은 브라우저가 처리합니다. 브라우저는
lang속성에 따라 언어별 규칙을 적용합니다. MDN의 text-transform 문서에 그 규칙이 정리되어 있습니다. 예를 들어 그리스어 모음은 대문자로 바꾸면 악센트가 빠지고, 튀르키예어는i를İ와 짝짓습니다. CSS를 쓰면 저장된 그리스어 텍스트의 악센트가 그대로 남지만, 대문자로 직접 입력하면 악센트가 영영 사라집니다.
그렇다고 과신해서는 안 됩니다. 브라우저가 변환된 텍스트를 보조 기술에 넘길 수 있기 때문입니다. 2016년에 등록된 WebKit 버그는 아직 해결되지 않았는데, VoiceOver가 대문자 스타일을 적용한 “Add to Cart” 버튼을 “A D D to cart”로 읽는 문제를 다룹니다. 개발자들은 Chrome에서 VoiceOver를 쓸 때도 같은 현상을 보고했습니다. 또 CSS로 만든 대문자도 눈으로 읽는 사람에게는 여전히 대문자이므로, 긴 대문자 텍스트의 부담은 그대로입니다. text-transform은 몇 단어에 대문자를 적용하는 올바른 방법일 뿐, 단락 전체를 대문자로 만들어도 된다는 허가가 아닙니다.
대문자를 써도 괜찮은 경우와 대신 쓸 방법
대문자가 금지된 것은 아닙니다. WCAG에는 대문자를 막는 성공 기준이 없고, 짧게 쓰면 문제가 거의 없습니다. 저희라면 다음과 같은 곳에 대문자를 남겨 둡니다.
- NASA, HTML, BBC 같은 진짜 약어와 두문자어.
- 짧은 레이블, 탭, 제목 위에 붙는 작은 ‘아이브로(eyebrow)’ 문구. 저희 기준은 세 단어 이하이며, CSS로 적용합니다.
- “New” 같은 배지 단어 하나. 단, 그 단어를 특별하게 알아들어야만 의미가 통하는 경우가 아니어야 합니다.
그 밖의 경우에는 스타일이 바뀌거나 소리 내어 읽혀도 살아남는 방법을 쓰세요.
- 강조:
<strong>을 쓰고 굵기나 크기로 스타일을 주세요. 대부분의 스크린 리더는 기본 설정에서 굵은 글씨도 알려 주지 않으니, 중요한 내용은 말 자체에 담으세요. “You can't undo this”(되돌릴 수 없습니다)라는 문장이 어떤 서식보다 많은 것을 전달합니다. - 경고: “Deleting your account removes all your files”(계정을 삭제하면 모든 파일이 삭제됩니다)처럼 짧고 평이한 제목이 대문자 덩어리가 하려던 역할을 해내고, 음성으로도 그대로 읽힙니다.
- 법률 문구: 미국 계약서는 보증 부인 조항을 대문자로 쓰는 경우가 많은데, 통일상법전(Uniform Commercial Code)이 이 조항을 “conspicuous”(눈에 잘 띄게) 표시하도록 요구하기 때문입니다. 하지만 이 법의 정의는 문서 본문에 대문자를 요구하지 않습니다. 더 큰 글자, 대비되는 글자, 글꼴이나 색상, 또는 텍스트를 구별해 주는 표시도 요건을 충족합니다. 약관을 바꾸기 전에 작성 담당자와 확인하되, 대문자만이 유일한 방법은 아니라는 점을 기억하세요.
유니코드 ‘작은 대문자’는 대문자가 아닙니다
저희 유니코드 화려한 텍스트 생성기에는 ‘작은 대문자’ 스타일이 있는데, 이 스타일이 실제로 무엇을 만들어 내는지 솔직하게 말씀드릴 필요가 있습니다. “Sale on now”를 입력하면 “sᴀʟᴇ ᴏɴ ɴᴏᴡ”가 나옵니다. 이것은 글자를 작게 그린 것이 아니라 아예 다른 문자이며, 대부분 음성 기호 알파벳에서 빌려 온 것입니다. 작은 대문자 버전이 없는 글자도 있어서 “s”는 평범한 소문자 s로 남고, “q”는 오고넥이 붙은 o인 “ǫ”로 나옵니다.
소프트웨어 입장에서 이 문자들은 원래 단어와 아무 관계 없는 기호입니다. 그래서 맞춤법 검사기가 오류로 표시하기 쉽고, 일반 단어로 검색하면 찾지 못할 수 있습니다. 스크린 리더는 비슷하게 생긴 문자를 매우 제각각으로 처리합니다. 비슷한 ‘가짜 굵은 글씨’ 문자를 테스트했을 때는 일부 스크린 리더가 단어를 아예 건너뛰었습니다. 그 테스트는 스크린 리더를 위한 글쓰기 가이드에서 자세히 다룹니다. 이런 스타일은 일반 텍스트 옆의 장식으로만 쓰고, 누군가 들어야 하는 단어에는 절대 쓰지 마세요.
대문자 사용 빠른 체크리스트
- 텍스트는 일반적인 대소문자로 입력하고, 대문자는
text-transform으로 적용하세요. - 대문자는 몇 단어로 제한하세요. 단락 전체는 절대 안 됩니다.
- 대문자에는
letter-spacing을 약간 더하되, 공백으로 간격을 만들지는 마세요. - 의미는 서식이 아니라 말에 담으세요.
- 출시 전에 주요 버튼과 레이블을 VoiceOver와 NVDA로 직접 들어 보세요.
- 중요한 내용에는 유니코드 유사 문자를 쓰지 마세요.
약어부터 법률 문서의 제목까지, 글에서 대문자가 정말 필요한 곳은 대문자는 언제 써야 할까 가이드에서 확인하세요.
