기본적으로는 UX 라이팅의 기본 원칙, 정확성, 간결성, 일관성을 완벽하게 지키면 접근성 글쓰기를 잘할 수 있습니다. 여기서 중요한 점은 그 3원칙의 지평을 비장애인으로 국한하지 않는 것, 즉 글자를 보고 읽는 사람만이 아닌 듣고 읽는 사람까지 고려해서 적용해야 한다는 겁니다. 보이지 않는 것들에 대한 고려와 시각장애인의 사용 맥락을 배려한 섬세하고 예민한 라이팅 스킬이 필요합니다.

Tips for Writing Great Accessibility Labels

지난 1편에 소개했던 동영상의 연사 Jordyn Castor (Apple Accessibility QA engineer)이 제안하는 기본적인 팁 5가지를 먼저 살펴봅니다. 굵은 글씨는 Jordyn의 제안이고, 그에 대한 부연 설명은 제가 썼습니다.

모든 화면에 접근성 레이블을 추가하세요.

이게 제일 중요합니다. 여러분, 접근성 텍스트 빼먹지 마요...ㅠㅠ 미루지 말란 말이야...

컴포넌트(element) 타입은 레이블에 포함시키지 않아도 됩니다.

컴포넌트 타입(버튼, 아이콘, 팝업, 타이틀)은 OS에서 파악하기 때문에 레이블 뒤에 그 명칭이 자동 발화됩니다. 시각장애인 사용자에게 반복 발화되지 않게 레이블에 컴포넌트 이름을 넣지 마세요. Apple과 Google님이 알아서 해주실 것입니다.

UI가 변경될 때 접근성 레이블도 함께 업데이트하세요.

앱 업데이트되어서 화면에 변경점이 생기면 접근성 레이블도 같이 변경되어야 합니다. 보이는 것만 업데이트하면 반절의 업데이트일 뿐입니다. 보이지 않는 레이블이라고 놓고 가면 안 됩니다. 꼭 같이 바꿔주세요.

중복을 피하고 충분한 콘텍스트를 제공하세요.

'사진 추가, 사진 삭제, 사진 다운로드' 처럼 대상 명칭이 중복되는 경우 생략해야 합니다. 비시각장애인은 눈으로 훑고 넘어가면서도 중복된 단어를 보면 시간낭비하는 것 같아서 짜증을 내는데, 시각장애인은 그걸 엄청 빠른 소리로 계속 들어야 합니다. 시간 낭비+ 청력 고통이 수반되는 거죠.

하지만 의미 있는 정보는 빼먹지 말고 추가해야 합니다. 비장애인이 눈으로만 확인할 수 있는 핵심정보는 반드시 장애인도 들어서 알 수 있게 접근성 텍스트로 제공해줘야 합니다.

의미 있는 애니메이션에 레이블 추가해 주세요.

로딩 스피너나 프로그래스 바가 진행되고 있는데 접근성 레이블이 없다면 어떤 일이 생길까요? 소리 없는 스피너 때문에 시각장애인은 지금 무슨 일이 일어났는지 알 수 없습니다. 앱이 뻥난 건지, 자기 혼자 뭔가를 하고 있는 건지 정적만이 가득할 뿐이죠. 의미는 있지만 소리는 없는 애니메이션에는 반드시 레이블을 붙여서 진행 상태를 알려주세요.

자, 여기서부터는 제가 말씀드리고 싶 팁 3가지입니다.

iOS와 Android의 접근성 발화 방식은 약간 다릅니다.

Jordyn Castor 씨는 Apple의 엔지니어라서 Apple이야기만 하는데 iOS와 android는 접근성 레이블을 쓸 때 약간 스타일이 다릅니다. 가장 큰 차이라고 하면 iOS 쪽에는 hint 레이블 요소가 더 있습니다.

레이블 만으로 맥락과 실행 결과를 예측하기 어렵다면, hint 텍스트를 추가로 제공할 수 있습니다.

출처:Supporting VoiceOver in your app

위 이미지처럼 hint를 입력하면 play 아이콘을 눌렀을 때 "Play song, button, Play the selected song"과 같이 발화될 것 같은데, 이건 서비스마다 좀 다를 수 있습니다. 일반적으로 hint는 단정적인 레이블에 추가 정보를 주어 이 레이블에 연결된 액션을 수행했을 때 어떤 결과가 나올지를 알 수 있게 합니다.

물론 모든 컴포넌트에 hint를 넣을 필요는 없습니다. 보통 주로 1,2 어절인 레이블 단독으로는 표현하기 어려운 인터렉션이 펼쳐질 때나, 레이아웃이나 아이콘처럼 시각적 상징을 통해서만 추측할 수 있는 결과가 있을 때 힌트를 추가하여 이해도를 높이곤 합니다.

저희가 쓰고 있는 hint 텍스트 일부분입니다. hint는 형식이 정해진 건 아닙니다. 사용자에게 무슨 말을 해야 이 기능을 정확하게 떠올릴 수 있을지 고민하세요.

모든 사용자를 위해 아이콘에 레이블을 넣으세요.

제 책에서도 두 번 이상 강조했던 내용이지만 아이콘에 레이블을 쓰는 걸 고려해 주세요. 아이콘은 아름답고 공간 차지를 덜하는 고마운 아이템이긴 하지만, 그 모호함은 모두를 곤란하게 할 수 있습니다.

아이콘에 레이블을 추가하면 장애 여부에 상관없이 모든 사용자에게 도움이 됩니다. 만약 아이콘에 레이블이 붙어있다면, 시스템에서 시각장애인 사용자에게 그걸 그대로 읽어 발화해 줄 겁니다. 접근성 레이블을 못 챙겼다고 걱정할 필요 없이 화면에 텍스트가 있으면 OS가 알아서 읽어준다니까요.

비시각장애인은 아이콘 레이블을 읽고 아이콘 상징의 모호함을 극복할 수 있습니다. 애매한 아이콘 형태 밑에 레이블을 넣으면 빠르고 명확하게 기능을 이해할 수 있거든요. 이건 제가 UT 들어가서 볼 때마다 맨날 사용자에게 나오는 코멘트라서 진짜로 자신 있게 말할 수 있습니다.

저를 믿고 아이콘에 레이블을 병기를 적극 검토해 주세요. 텍스트를 병기하면

눈을 감고 상상하며 접근성 텍스트를 쓰세요. 그리고 계속 테스트하세요.

접근성 텍스트에는 규칙이 있고, 일단 그 규칙대로 쓰면 되기 때문에 난이도가 많이 높지 않다고 생각할 수 있습니다. 하지만 정말 이 음성 가이드가 제대로 작동할 것인가를 생각하면서 글을 쓰면 조금도 쉽지 않아요. 그래서 저는 어쩌면 접근성 글쓰기가 가장 어려운 UX 라이팅 중에 하나가 아닐까 생각하곤 합니다.

비장애인이 장애인을 위한 텍스트를 쓸 때 머리로만 쓰면 한계가 생기기 마련입니다. 그래서 접근성 텍스트를 쓸 때 저는 한 문장 쓰고 눈을 감고 화면을 터치하는 시늉을 해봅니다. 앞쪽 화면에서 시작해서 이 흐름으로 자연스럽게 들어와서 이 버튼을 눌렀을 때 이 레이블과 이 힌트가 정말 다음 액션을 동인하는 의미가 될 수 있을까...? 눈을 감고 버벅대면서 화면을 눌러보곤 합니다. 사용자가 처한 상황과 완전히 같을 수는 없겠지만, 조금이라도 가까이 가고 싶다고 생각하면서 글을 쓰는 것은 항상 중요합니다.

결국 이 모든 걸 해내는 건 우리들입니다.

올해의 마지막 날, 이 긴 Accecibility 시리즈를 마무리하면서 올해 작업했던 접근성 프로젝트 에피소드 하나를 소개하려고 합니다.

올해 4월에 멋진 숏폼 동영상 에디터 기능의 접근성 문구를 라이팅 했습니다. 이 에디터 기능의 첫 삽을 뜰 때부터 우리 팀이 함께 했으니까, 라이터들은 이미 기능에 대해 빠삭하게 잘 알고 있었죠. '아이구 오셨습니까? 접근성 레이블 의뢰 주시기를 기다리고 있었습니다' 생각하면서 함께 리뷰를 시작했습니다.

사실 접근성 라이팅 중에서는 이런 에디터, 특히 멀티 미디어 에디터 쪽이 제일 빡셉니다. 미세조정이 엄청 많은 기능이거든요. 슬라이더, 핸들, 현재 위치/시간 마커, 버튼, 아이콘에 모두 액션 텍스트를 지정해야 하고, 거기에 이펙트가 붙고 스티커를 넣고, 글자를 넣고, 컬러를 지정하고... 사실상 시각적 큐에 거의 전적으로 의존하고 있다고 할 만큼 눈과 손끝의 예민한 조정력이 결합된 고난이도의 태스크가 동시 다발적으로 일어나는데 그걸 오직 음성 디렉션으로 끌어와야 하는 '와... 라이팅하기가 너무 어려워!'란 소리가 절로 나오는 기능입니다.

결국 맨땅에 헤딩하듯이 계속 라이팅, 테스트, 이상해!! 리라이팅, 테스트, 이게 아닌 거 같아! 를 반복했습니다. 그래도 제가 안드로이드 디바이스 접근성만 5년에 iOS까지 추가해서 5년 더 해봤는데도 '아니 뭐 이렇게 복잡한 게 다 있어...??' 싶었다니까요. BM 할 곳이라고 OS 네이티브 정도(유튜브, 인스타 에디터... 그냥 그렇더라고요)고, 아무튼 머리가 너무 아팠습니다. 결국 우리들 스스로 '이 미세조정 시점에 어떤 정보를 어떻게 뭉쳐서 발화해야 오직 음성 가이드만으로 동영상을 편집할 수 있을까?'를 계속 고민해서 쓰는 수밖에 없었어요.

근데 단일 기능 하나에 붙는 접근성 텍스트가 170개를 넘어가고 거의 한 달 반 이상 수정, 재작성이 반복되니까 라이터들이 너무 지치더라고요. 다른 라이팅 프로젝트가 밀려들어 오는데, 이 접근성 프로젝트가 도무지 끝나지가 않아서 수정 요청이 올 때마다 기억을 더듬어서 다시 리뷰하고, 관련된 용어나 정보를 모두 재수정하는 일을 반복했습니다. 보통 프로젝트가 한 번에 끝나지 않고 질질 늘어지면 하루에 5-10개 다른 서비스를 봐줘야 하는 저 같은 라이터들은 많이 지칩니다. 문구 한 개를 수정하기 위해서 그 앞뒤의 맥락을 다시 기억해 내고 파악해야 하니까요.

안녕, 같은 작업을 2달째 못 끝내고 계속 재수정하고 있는 UX 라이터라고 해. 아아아아아아아아아아아아아아아아아아악!!

반복되는 수정과 재검토, 추가건 리뷰 의뢰에 슬슬 짜증이 나려고 하던 어느 날,

불현듯 그런 생각이 들었습니다.

그동안 이토록 접근성에 진심인 기획자와 개발자가 있었던가?

시각장애인 사용자가 동영상 편집을 할 수 있게 하려고 이렇게까지 고민하는 사람들이 있었나?

어느 회사든 접근성은 릴리스되기 직전에 붙으면 양반이고 릴리스되고 난 다음에 붙는 경우, 아니면 아예 안 붙는 경우도 다반사입니다. 디자인, 기획, 개발에서 의뢰를 줘야 라이터가 리뷰를 시작하는데, 라이터가 '접근성은... 언제 의뢰 주세요...?'라고 머뭇머뭇 물어보는 일도 종종 있죠. 당장 이슈 터져서 힘들어하는 게 뻔히 보이는데, 접근성 왜 안 하시냐고 말하기가 눈치 보이는 것도 사실입니다.

그런데 이 프로젝트에 투입된 이 실력 있는 기획, 개발팀이 접근성에 너무 진심이란 말이죠. 이 똑똑한 사람들이 두 달 가까이 계속 써보고, 수정하고, 고민하고, 공부해서 개선하고를 반복하고 있더란 말입니다. 요식행위가 아니라 진짜 잘 만들고 싶어서, 정말 시각장애인 사용자가 동영상을 혼자 편집할 수 있게 만드려고요.

그걸 보니까 저도 힘이 났습니다.

그래, 우리도 열심히 하자!

기획팀에서 또 수정 건이 왔다고 PM님이 알려주시자 눈물 흘리는 라이터들 ㅋㅋㅋㅋ 그러나 서로를 껴안으면서 끝까지 함께 하겠다 다짐했습니다. 진심엔 진심으로 응답하겠어!

그 프로젝트는 결국 잘 끝났습니다. 그리고 저는 그 분들의 이름을 제 마음속에 있는 화이트 리스트에 적어두었어요. '나중에 다른 프로젝트에서 만나면 더 다정하게 잘해드려야지'라고 다짐하며 까방권+다정&친절권도 리스트에 태깅해 두었습니다.(최**님과 개발자분들... 여러분들은 모르시겠죠. 모르셔도 됩니다. 제가 멀리서 흠모하.. 아.. 아닙니다.)

장애 여부와 상관 없이 모두가 쓸 수 있도록 제품을 만들 책임은 우리 모두에게 있지만, 지금 그 책임을 다하는 사람을 찾아보기는 어렵습니다.

묵묵히 자신에게 주어진 책임을 다하는 귀한 기획자, 디자이너, 개발자분들을 응원합니다. 정말 고맙습니다.

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari