토스 테크 블로그에 올라온 두 편의 글을 읽으며 유니버설 디자인에 대해 다시 생각해보았다.
그리고 특정 사용자들의 접근성을 고려한다는 것은 어쭙잖은 공감을 느끼는 데서 그치지 않고 실제로 이 사용자의 불편함을 어떻게 개선할지 고민하면서 구조적으로 치밀하게 쌓아나가는 과정이란 생각이 들었다.
유니버셜 디자인 팀이 있는 조직에서 일하는 게 메이커에게 큰 행운인 것 같다. 이런 경험을 할 수 있는 조직이 세상에 몇 개나 있을까? 조직의 규모도 커야 하겠지만 개발 리소스라는 현실의 벽에 부딪혀 좌절되기 일쑤일 텐데 그걸 지원하는 조직이지 않은가...
- 보이스오버(VoiceOver) 사용성 개선 사례
- 시각장애인을 위한 얼굴 인증 UX 개선 사례
토스 접근성 개선기 1: 시각장애인에게 '정보의 순서'가 중요한 이유
원칙보다 사용성에 집중할 때 | 접근성 업무일지 #1
스크린리더의 역할 정보는 왜 항상 뒤에 읽혀야 할까? 사용자의 사용 방식을 관찰하면서, 시스템의 문법을 다시 생각해본 이야기를 들려드릴게요.
toss.tech
스크린리더는 어떻게 화면을 읽을까?
스크린리더(보이스오버)는 화면 요소를 레이블 → 역할 → 상태 순서로 읽어준다.
마케팅 알림. 체크상자. 선택됨. (잠시 쉼) 설정을 끄거나 켜려면 이중탭하십시오.
왼쪽 이미지는 오른쪽 이미지처럼 정보가 이뤄져있고, 인용구처럼 보이스오버가 읽는다.
여기서 문제는 실제 사용자들이 이 안내를 2배속 이상으로 빠르게 듣고, 필요한 정보만 스캔하듯 넘긴다는 점이었다고 한다.
- 역할 정보(버튼, 스위치 등)가 문장 맨 끝에 위치
- 사용자는 앞부분만 듣고 다음 항목으로 넘어감
- 결과적으로 버튼인지 인지하지 못하고 지나치는 상황 발생
즉, 접근성 원칙 자체는 지켜졌지만 실제 사용 맥락에서는 오히려 불편을 만들고 있던 것이다.
해결 방안 탐색
토스 팀은 세 가지 방향을 검토했다.
1안. 정보 분절
(아티클에 직접 설명되진 않았지만, 물리키로 정보를 넘길 때 그 넘기는 단위를 분절시킨다는 뜻인 것 같았다)
쌓인 이자 200원
10,000원
버튼
- 역할 인지는 빠름
- 초점이 많아져 탐색 속도가 느려질 우려
2안. 효과음 활용
(띵) 쌓인 이자 200원, 10,000원, 버튼
- 버튼, 스위치 등을 소리로 구분
- 직관적이지만 일관성 문제 존재
3안. 역할 정보 우선 읽기
버튼, 쌓인 이자 200원, 10,000원
- 탐색 시작 시 즉시 파악 가능
- 다만 iOS 시스템 문법과는 불일치 (iOS 시스템 문법 또한 역할 정보를 가장 나중에 읽음)
iOS 기능 추가
토스 팀은 사용자가 읽는 순서를 직접 선택할 수 있는 옵션을 제공하는 방향으로 초점을 맞추고 고민 중이었는데, iOS 18.4 업데이트에서 ‘컨트롤 항목 순서 설정’ 기능이 추가되었다고 한다.
우연찮게도 애플에서도 토스 팀과 같은 고민을 하고있던 셈이었고, 예상치 못한 방향으로 문제가 일부 해결된 것이다.
토스 접근성 개선기 2: 시각장애인 전용 얼굴 인증 화면 개선
시각 정보를 소리로 번역하는 법 - 시각장애인을 위한 얼굴 인증 개선기 | 접근성 업무일지 #2
프로그레스 바 같은 시각적인 정보를 어떻게 소리로 잘 전달할 수 있을까요? 시각장애인을 위한 사용 경험을 설계할 때 고려해야할 지점을 알려드릴게요.
toss.tech
문제의 시작
토스의 이상 거래 감지 과정에서는 얼굴 인증이 필요하다. 하지만 시각장애인 사용자는 타인의 도움 없이는 인증을 완료하기 어려운 구조였다고 한다.
진행 상태 전달 방식 변경 사례
AS-IS
프로그레스 바로만 진행 상황 표시되어, 시각장애인은 지금 인식 중인지, 멈춘 건지 알 수 없어 문제
TO-BE
진행 중 상태와 완료 상태를 나타내는 사운드를 각각 만들어 삽입
인식 실패 시 다시 찍기 프로세스 개선 사례
AS-IS
인식 실패시 ‘다시 찍기’ 버튼 클릭이 필요해, 이것을 터치하기 위한 동작이 시각장애인에겐 기껏 잡아놓은 자세를 흐트러뜨리는 크리티컬한 동작이 될 수 있었음. 이로 인해 또 실패하게 되는 악순환
TO-BE
“얼굴이 원을 벗어났어요” 같은 즉각적인 토스트 안내를 하고, 터치 없이 바로 다음 안내로 이어지게 바뀜. 흐름을 끊지 않으니, 사용자는 자세를 유지한 채 인증을 이어갈 수 있었다고 한다.
사실 생각해보면 그렇다. 실패했으면 특별한 이유 없이는 어차피 다시 찍을 텐데 그 버튼을 터치하는 과정이 필요할까?
카메라 권한 설정 과정 개선
AS-IS
“허용해 주세요”라는 짧은 문구로 카메라 권한 허용 절차를 안내하여, 이후에 무엇을 해야 하는지 불명확했음.
TO-BE
iOS 권한 설정 과정을 단계별로 분리, 각 단계마다 지금 해야 할 행동을 명확히 안내
스크린리더 사용자에게 인사 건네기
그리고 스크린리더를 사용하는 사용자에게 '우리는 당신이 스크린리더를 사용하는 걸 알고 있다'라는 의미의 안내문을 노출하며 시작하게 바꾸었다고 한다. 처음에는 불편함을 느낄까 염려되었는데 UT 결과가 좋았다고 한다. 사용자의 상황을 이해하고 있다는 신뢰감을 주는 요소였다고 한다.
아무래도 사용자는 메이커가 어떤 의도로 이 기능을 만들었는지 알 수 없기 때문에, 만약 메이커가 전맹 이용자를 인식하고 있다는 걸 알게 되면 더 적극적으로 앱 사용성에 대해 고민해보게 되고 토스에도 건의를 할 수 있는 긍정적인 선순환이 구축될 것 같다고 생각되었다.
인사이트 & 궁금한 점
- 접근성을 고민한다는 건 관심을 갖는 것에서 그치면 안되고, 치열하게 문제를 구조적으로 해부해서 이해하려는 태도여야한다.
- 타깃 유저가 달라지면, UX 고민의 결도 완전히 달라진다. 다른 조건의 사용자에게는, 문제없어 보이던 화면도 장애물이 될 수 있다. 마치 PC버전을 휴대폰으로 들어가면 글자도 제대로 보이지 않는 덩어리가 되는 것처럼. (이래서 역지사지가 필요해)
- OS 정책과 시스템 동작을 이해하는 것도 UX의 일부라는 걸 다시 느꼈다.
- 아무도 배제하지 않는 UX는 정말 어렵다. 큰 글자 앱도 레이아웃이 다 무너지다 보니 거의 새로운 디자인 수준으로 디자인을 하거나 처음부터 큰 글자로도 가능하도록 세심한 마진값, 패딩값, minmax값 설정이 필요하다. 이런 개발은 조직의 장이 회사 리소스를 어디에 얼만큼 사용할지 결정하면 그에 따라야 하는 경우가 대부분일 텐데, 아무도 안 다치면서 비즈니스적으로도 좋은 개발방법은 없는 걸까? 이러한 유니버셜 디자인을 주장하는 CEO는 브랜드가치나 당위성을 가지고 이를 설명할 수 있어도 PM은 '당위성'으로 무언가를 주장할 수 없다. 이래서 PM에게 회복탄력성이 필요하구나. 토스 아티클에 댓글을 다신, 남자친구분이 전맹인 타서비스 메이커분처럼... 가까운 사람이 접근성 이슈를 겪고 있을 때 이걸 주장하는 PM이 있다면 현실이 가혹하게 느껴지겠다.
- 대부분의 메이커는 비장애인이다. 그래서 더더욱 치밀한 관찰과 분석이 필요하다. 미래의 나를 위한다는 마음으로. (막말로 오늘 화장실 청소하다가 눈에 락스 들어가서 병원에 가 처치하면 나중에 회복이 된다 하더라도 치료 기간동안은 보이스오버를 써야 하는걸?)
- UT를 할 때 비장애인 메이커가 의도치 않게 무례한 언행을 할 수 있다. 이에 대한 대비책이 토스 내에 있을까? UT 진행자가 따로 공부를 하는 걸까?
컴포넌트 유형 설정 시 유의점
프로그레스 바는 보이스오버가 읽기에 부적절한 형태다.
접근성을 고려하는 앱을 제작할 때 시각장애인 사용자를 위해 아예 새로운 컴포넌트를 제작하는 게 버거울 것이 예상된다면
개발 리소스를 아끼기 위해 프로그레스 바 대신 다른 컴포넌트를 사용하거나 프로그레스 바 개발시에 구조화를 잘해서 보이스오버가 잘 읽어줄 수 있게 해야겠다는 생각이 들었다.
예를 들어 10% 갱신시마다 수치 안내를 해주거나, 5초마다 안내를 해주는 등.
음의 피치를 서서히 올려가는 것도 괜찮을지도(max값에 대한 인지가 없어서 힘들수도).
치밀한 구조화의 필요성
나는 대학생 시절에 우리 학교 프로그램을 이수한 시각장애인 학생들을 기차역까지 데려다주는 근로장학생을 한 적이 있다. 그때 전맹 친구들이 보이스오버를 활용하는 걸 보고 입이 떡 벌어졌었다. 훈련되지 않은 사람들은 알아듣지도 못할 속도로 보이스오버를 재생했고, 당연히 모든 내용을 이해했다.
그전까지만 해도 '이 많은 내용을, 시각 비장애인은 눈으로 훑어 스키밍할 수 있지만, 시각장애인은 어떻게 읽지?'하는 궁금증만 있었지 실사례를 본 적이 없었다. 그런데 그 정도의 속도로 듣는다는 걸 알고부터 프로덕트의 설계만 구조적으로 잘 되어있다면 시각장애인이 프로덕트를 이용하는 데 무리가 없겠다는 생각이 들었다. 그리고 구조가 무너져도 UI만 어떻게든 잘 끼워맞춘다면 비장애인은 정보를 이해할 수 있겠지만, 구조대로 정보를 읽는 보이스오버를 통해 프로덕트를 이해하는 시각장애인 입장에서 구조가 무너진 프로덕트는 정보가 쌓여있는 쓰레기더미겠구나, 라는 경각심이 들기도 했었다.
그래서 그 이후로는 웹서비스나 앱서비스를 기획할 때 정보의 계층을 고려하고 구조화하고자 했다. 이번 부트캠프 웹사이트 제작 과제에서도 시간이 없어 대체 텍스트를 넣거나 컴포넌트의 이름을 예쁘게 지어주진 못했지만 구조화에는 힘을 썼다.
UI적으로는 전혀 불필요한 계층이더라도 구조적으로 그룹화가 필요하다면 스택으로 묶어 넣고자 했다.
