brunch

You can make anything
by writing

C.S.Lewis

by 제나로 Aug 28. 2024

모두를 위한 서비스, 장애 접근성

누구나 사용할 수 있는 IT 서비스 만들기

 잘 지내셨나요?

 저는 B2G 구축 프로젝트를 1차 마감하고 왔습니다. 프로젝트 규모가 크고, 이해관계자도 많아서 정신이 없었어요. 말도 많고 탈도 많은 프로젝트였죠. 이번 프로젝트는 공공 프로젝트였고, 웹 접근성에 대해 자세히 다뤘습니다. 몰랐던 것들을 많이 알게 됐어요. 제가 배우고 느낀 점을 나누고 싶어서, 오랜만에 글을 쓰게 됐습니다.



공공 프로젝트 준수 사항

 공공 프로젝트를 진행할 때는 다양한 분야에서 기본적으로 적용되어야 하는 가이드라인을 준수해야 합니다. 제가 참여한 프로젝트에서 특히 중요했던 가이드라인은, 네 가지만 꼽아 보라면 - 클라우드 보안에 대한 인프라, AI 리스크 관리, 개인정보 관리, 웹 접근성 이었습니다. 앞의 세개는 엔지니어링 팀이나 운영 팀에서 운전대를 잡았습니다. 저는 주어진 일만 하면 됐으니 감사한 일이죠.


 웹 접근성은 제가 운전대를 잡았는데요, 웬걸, 그 동안 접근성이라는 것을 거의 고려하지 않고 프로젝트를 기획해 왔다는 것을 깨달았습니다. 창피했죠. 기획자이자 PM에게는 쏟아지는 할일에 대한 우선순위 판단, 처리할 일감에 대한 선택과 집중 판단능력이 요구됩니다. 늘 비장애인 위주의 서비스를 만들다 보니, 장애인을 위한 기능들은 우선순위가 낮아졌고, 점점 신경쓰지 않게 되었던 것입니다. 디지털 약자나 초보자를 고려한 설계에 자신 있었는데 말이죠. 다행히 이번 프로젝트에서는 접근성을 반드시 준수하는 제품을 만들어야 했고, 접근성 기능들을 우선순위 높게 관리할 수 있었습니다.




접근성이란

 접근성에 대한 정의를 읽고도, 이 정의를 제품에 어떻게 녹여내야 할지 고민이 많았습니다. 다음은 접근성에 대한 정의입니다.


장애인이나 특별한 요구를 가진 사용자가
콘텐츠에서 제공하는 정보를
비장애인과 동등하게 접근하고 이용할 수 있도록 보장하는 것



 위의 정의에 따라, 아래와 같은 가이드라인이 있었습니다.


OS 자체에서 지원하는 발전된 각종 접근성 기술을 준수하여
애플리케이션 콘텐츠를 구현하여야 하며,
누구나 콘텐츠에 접근하고 이용할 수 있도록 지원할 것


 정의와 가이드라인을 읽고, 가장 처음 든 솔직한 생각은.. '그래서 어떻게 하라고?' 였습니다. ^^;;




레퍼런스 조사하기

 서비스 기획을 하다가 막히면 가장 처음 시도하는 일은 레퍼런스 조사입니다. 시장 선두주자는 어떻게 하고 있는지 보고 배우는 거죠. 장애인도 많이 쓸만한 서비스로 네이버를 떠올렸고, 네이버 접근성 가이드를 찾아보기 시작했습니다.


 네이버 접근성 가이드

 https://accessibility.naver.com/accessibility


자료출처 : 네이버 접근성 가이드


 네이버에서는 4가지 핵심원리를 위와 같이 꼽고 있습니다. 문제는, 그런데도 뭘 해야될 지 잘 모르겠다는 것입니다! 이럴 때 제가 잘 사용하는 방법은 예시를 찾아보는 일입니다. 제 기획서를 디자이너와 개발자들에게 리뷰할 때도 마찬가지에요. 정책만 늘어놓으면 설명이 어려워서, 꼭 예시 이미지나 플로우차트를 덧붙이곤 합니다.




레퍼런스 분석하기 

자료출처 : 네이버 접근성 가이드

 음, 이렇게 보니까 사용자를 네 그룹으로 나눠볼 수 있겠습니다.

 저는 위 사용자를 시각 보조 지원, 청각 보조 지원, 운동 보조 지원, 인지 보조 지원이 필요한 그룹으로 나누었습니다. 각각의 그룹이 겪고 있는 문제점이 뭔지 파악하고, 문제를 해결할 수 있는 방향을 제시해보면, 필요한 기능들이 떠오릅니다. 이것을 잘 발굴해 내는 것이 기획자의 역할입니다.




문제 정의하고 해결방안 찾기

 각각의 보조 지원이 필요한 그룹의 공통점과 차이점을 분석합니다. 공통점은 서비스 사용에 어려움을 겪을 수 있다는 점이고, 차이점은 각 그룹의 특징을 살펴보면 해답을 얻을 수 있습니다.


그룹의 공통 문제 정의하기

 공통 문제를 해결할 수 있는 방안으로 '서비스 사용에 막힘이 없게 하자' 는 생각이 떠올랐습니다. 서비스 사용에 막힘이 있는 사례가 있을지 검토해 봅니다. 옵션을 선택하거나 입력해야만 다음 단계로 넘어갈 수 있는 상황이 있네요. 이 상황에서, 장애 사용자라면 옵션을 선택하거나 입력하지 않아도 다음 단계로 넘어갈 수 있도록 지원해야겠다 - 는 생각이 들었습니다.


 이렇게 되면 고려해야 할 사항들이 떠오르죠. '장애 여부는 어떻게 체크하지?', '서버에 기록은 어떻게 남겨야 하지?', '예외사항은 어디까지 허용해야 하지?' 같은 질문들이 생겨납니다. 이런 것들은 실무할 때 참고할 수 있도록 잘 보관해 두고, 일단 덮어둡니다. 지금은 상위 레벨에서의 고민들을 하는 단계니까요.


그룹별 문제 정의하기

 시각 보조 지원이 필요한 그룹은 다시 세개의 그룹으로 나눌 수 있습니다. 전맹 사용자, 색각이상 사용자, 고령자와 약시자로 나눕니다. 전맹 사용자는 화면 낭독 프로그램(스크린리더)을 사용하는 데에 문제가 없어야 하고, 색각이상 사용자는 정보를 구분하는 경우에 문제가 없어야 하고, 고령자와 약시자는 작은 글씨를 읽는 데에 문제가 없어야 합니다.


 이 경우엔 이런 해결방안을 생각해볼 수 있습니다. '모든 글자, 표, 이미지를 스크린리더가 인식할 수 있게 지원한다', '정보는 색상, 구분자, 패턴 등을 적절하게 섞어서 표현한다', '글자를 확대할 수 있는 기능을 지원한다'. 정답은 아닐 수 있지만, 일단 아이데이션이 되었으니 여기서부터 고려할 것들이 있을지 생각을 시작합니다.


 청각 보조 지원, 운동 보조 지원, 인지 보조 지원 쪽도 기획의 흐름은 동일합니다. 그룹을 나누고, 그룹의 문제를 정의하고, 문제를 해결할 수 있는 단서를 떠올리고, 떠오른 단서를 테이블에 올려둡니다. 함께 일하는 사람들과 테이블에 모여앉아, 같이 상의해 보는 것도 좋고요.



 다음 글에서는 보조 지원이 필요한 그룹별로, 고려할 점들에 대해 생각을 나눠 보고자 합니다. 부족한 부분이 있다면 보완하겠습니다.




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