cleanUrl: /retrospective-or-psa/severity-of-bug-that-blocks-people-from-daegue
접근성 지원을 해야 한다는 이야기를 하게 되면, 필연적으로 따라오는 반응이 있습니다. “접근성 지원, 좋죠. 그런데 지금은 당장 돈을 벌어야 해요. 장애인들을 위해 추가적인 고려를 할 여유가 없습니다” 와 같은 반응이지요.
언뜻 일리 있어보이는 말입니다. 하지만 조금만 생각해보면 이런 답변에는 장애인에 대한 (의식적이든 무의식적이든) 오해와 차별이 숨어있다는 것을 알 수 있습니다.
적지 않은 분들이 “접근성”을 고려해 개발한다고 할 때 다음과 같은 코드를 연상하는 것 같습니다.
if 장애인 == true {
/// 장애인을 위한 특별한 처리를 하는 코드
else {
/// 비장애인을 위한 코드
}
이런 식의 if문 분기처리가 많아지면 코드의 복잡도가 올라가고 이는 관리하기 어려운 제품으로 이어진다는 것이지요. 하지만 실제로는 오히려 접근성을 지원하다보면 기존보다도 더 간결한 코드가 만들어지는 경우가 훨씬 많습니다. 이 부분에 대해서는 “접근성 지원, 개발자의 빠른 성장을 도와줍니다“라는 글에서도 다룬 적이 있습니다. 위 글의 핵심만 간추리자면, iOS, Android, Web등 모든 플랫폼에서는 UI관련 API들을 만들 때 모두 접근성 지원을 염두에 두고 만듭니다. 그런데 접근성 지원이 고려된 API를 활용해 만든 제품에서 접근성 지원이 되지 않는다는 것은 그 API를 의도에 맞게 사용하지 않았다는 것을 뜻하지요. 거꾸로 접근성을 고려하며 제품을 만들다보면 자연스럽게 해당 API들을 그 의도에 맞게 쓰게 됩니다. 따라서 불필요한 코드가 줄고 더 간결한 코드가 나오게 됩니다.
접근성 지원이 어렵다면, UI관련 API를 사용하는 Best-Practice를 알기가 어려운 것이지, 결코 접근성 지원이 코드의 복잡도를 높이기 때문이 아닙니다. 거꾸로 말해, 여러분의 제품에서 접근성 지원이 잘 되고 있지 않다면, 코드의 복잡도를 개선할 수 있는 여지가 굉장히 많이 숨어있다는 뜻이기도 합니다.
여러분이 서비스하는 앱에 어떤 문제가 있어서 대구 사람들은 아예 쓸 수 없다고 해봅시다. 이 문제의 심각성은 어느 정도 일까요? 아마 어떤 서비스를 하고 있더라도 이런 문제가 있다는 것이 알려지면 새벽중에라도 당장 이 문제를 해결하기 위해 많은 사람들이 모일 것입니다. 회사에서는 문제가 해결되면 공지사항도 올리고 경우에 따라서는 사과문도 올릴 수 있겠지요.
그런데 이 문제가 오래 방치된다면 분명 대구분들의 분노에 넘치는 문의들이 들어올 것입니다. 아마 이런 형태이지 않을까요?
이 앱 대구에서만 안 된대요. 정말 어이 없어서. 대구 사람들 차별하나요? 왜 대구에서만 안 되는 것이지요? 서울 사람들은 이 앱으로 이것도 하고 저것도 한다는데 왜 대구 사람들만 못하게 해요? 대구사람들은 XX도 하지 말라는 것인가요?
이런 리뷰들이 앱스토어에 쌓이면 회사가 아무리 가치있는 임팩트를 전달하려 한다 해도, 그 진정성이 고객에게 전달 될리가 없습니다. 시중에서는 “대구 사람들 차별하는 앱”으로 통용될 것이고, 심지어는 대구 사람들로부터 법적인 소송이 들어올 수도 있습니다.
그런데 똑같은 일이 장애인들에게 일어난다고 하면 그 심각성은 훨씬 낮게 취급됩니다. 2017년 기준으로 국내 장애인 인구는 약 267만명 정도입니다. (참고: 2017년 장애인 실태조사) 웬만한 광역시의 인구 정도이지요. 대구 사람들이 우리 앱을 못 쓴다고 하면 문제라고 생각하고, 장애인이 못쓴다고 하면 문제라고 여기지 않는 것. 바로 차별입니다.
흔히들 장애는 의료적인 문제라고 생각합니다. 실제로 아주 오랜 기간동안, 장애를 의료적 관점에서 정의한 “의료적 모델”이 장애를 바라보는 기본 시선이었습니다.
1980년에 세계보건기구가 발표한 국제손상장애핸디캡 분류(International Classification of Impairments, Disabilities and Handicaps, ICIDH)는 장애에 대한 최초의 국제적 정의인데요, 이에 따르면 장애인이란