우리나라에 5천만명 정도의 국민이 있습니다. 그 중에 장애를 가진 사용자는 몇 명일까요? 그렇다면 과연 그들은 장애를 가지지 않은 사용자와 동일하게 서비스들을 이용하고 있을까요?
이 질문들은 '접근성'이라는 개념과 관련이 있습니다.
개발자의 입장에서 접근성 준수를 위한 첫 발걸음으로 쉽게 시작할 수 있는 것에는 어떤 게 있을까 생각해본 경험을 공유하고자 합니다.
접근성이란?
접근성에 대해 잘 알고 계신 분도 있겠지만 낯설게 느끼는 분들도 계실 것 같아 정의에 대해 알아보고자 합니다. 접근성이란 남녀노소, 장애 유무와 상관없이 모두가 동등하게 불편 없이 이용할 수 있도록 제품, 서비스, 환경 등을 디자인하는 것을 의미합니다. 쉽게 말해 모든 사람의 능력이나 상황에 상관없이 모두에게 같은 기회를 주는 것이라고 할 수 있습니다.
'모든 사용자'라는 단어에 초점을 맞춰 우리 일상을 살펴보면 더 쉽게 이해할 수 있습니다.
위 사진과 같이 진입로에 경사로가 설치된다면, 휠체어 이용자도 편리하게 접근할 수 있습니다.
높낮이 조정이 가능한 세면대가 존재한다면 모든 사람들이 불편하지 않게 세면대를 이용할 수 있습니다.
주변에서 흔히 볼 수 있는 편의 시설은 장애가 있는 사람뿐만 아니라 그렇지 않은 사람에게도 도움이 되기도 합니다. 휠체어를 위한 경사로는 유모차 또는 자전거를 이용하는 사람들에게도 쉽게 이동할 수 있도록 돕고, 건축물 출입구와 가까운 곳에 위치한 엘리베이터는 지체 장애가 있는 사람뿐만 아니라 거동이 불편한 사람들도 편리하게 이용할 수 있습니다.
이를 웹/모바일 서비스에도 확장시켜서 생각해보면 어떨까요?
시력이 저하되거나 색맹이 있는 사용자를 고려한 텍스트 크기 조정, 이미지 명도 차이, 디자인 동일성 등을 고려해 만든 서비스는 노안으로 인해 작은 글씨를 보기 힘든 사용자에게도 도움이 됩니다.
또한, 상지 장애(절단, 관절, 마비)가 있는 사용자를 위한 음성 입력 기능은 무거운 짐을 들거나 운전을 하고 있어 일시적으로 손을 사용하기 힘든 사용자에게도 도움이 됩니다.
따라서 접근성은 좁게는 장애인, 노령 사용자를 위한 서비스를 제공하는 것, 넓게는 장애인에 한정하지 않고 모든 사용자에게 필요한 서비스를 제공하는 것이라고 할 수 있습니다.
웹 접근성
접근성에는 웹 접근성과 모바일 앱 접근성이 존재합니다.
저희는 웹 접근성에 대해서만 간단하게 알아보겠습니다.
한국웹접근성인증평가원과 W3C에서 정의한 내용을 살펴보면 다음과 같습니다.
정보통신접근성(Web 접근성)은 「지능정보화기본법」에 따라 모든 사용자가 신체적·환경적 조건에 관계없이 웹 서비스에서 제공하는 정보를 동등하게 접근하고 이용할 수 있도록 보장하는 것으로 웹 접근성 준수는 법적의무사항입니다.
-한국웹접근성인증평가원 -
장애를 가진 사용자들이 사용할 수 있도록 웹 사이트, 도구, 기술이 설계 및 개발된 것
-W3C-
즉, 웹 접근성(Web Accessibility)은 모든 사용자가 신체적·환경적 조건에 관계없이 웹 사이트에서 제공하는 정보를 동등하게 이용할 수 있도록 보장하는 것을 말합니다.
그렇다면 왜?
왜 우리가 이러한 접근성을 준수해야할까요!
접근성을 준수하면 얻을 수 있는 이점을 살펴볼까요?
1. 사용자층 확대
장애인 모바일 사용자를 더 이상 배려대상이 아닌 잠재 고객으로 볼 필요가 있습니다. 서비스 이용과 직접적 영향이 있을 것으로 추정되는 장애를 가진 인구는 시각장애 25만 1,620명, 청각장애 41만 1,749명, 지체장애 119만 1,462명 정도로 모두 합치면 185만 4,831명으로 전체 인구에 3.6%(2021년 기준, 보건복지부)를 차지합니다. 약 185만 명이라는 결코 적지 않은 사용자를 배려한 서비스는 이들을 신규 고객으로 서비스와 함께 성장하는 대상으로 바라볼 수 있습니다.
2. 서비스를 이용하는 모든 사용자에게 이로움
장애를 가진 사람이 서비스를 이용하면서 겪는 불편함을 우리 모두가 경험할 수 있다고 생각해 보면 이점을 바로 알 수 있습니다. 빛 번짐이 심한 사용자나 저시력자를 위한 다크 모드는 눈에 피로가 덜 하게 화면을 보고 싶은 사람, 디자인적으로 예뻐 보여서 다크 모드를 사용하고 싶은 사람 모두가 잘 활용하는 기능이 됩니다. 청각장애인을 위한 동영상 자막 기능은 이어폰이 없는 상황에서 동영상 콘텐츠를 이용하는 사람에게 자막에 의존해 내용을 파악할 수 있는 편리함을 제공하게 됩니다.
장애물
이렇듯 접근성을 준수하면 좋은 점이 많지만, 늘 그렇듯 우리는 이러한 고민에 빠지게 됩니다.
접근성은 기술적으로만 달성할 수 있는 것이 아니며, 서비스 개발에 참여하는 PM, 디자이너, 개발자들의 이해와 협업이 필수적입니다. 접근성을 달성하기 위한 조건들이 포괄적이고, 상당한 개발 및 검증 작업을 요구하므로 단기간의 개발 생산성이 저하될 수 있습니다. 더구나 PM이 접근성 작업의 중요성을 이해하지 못하면 더욱 힘들어집니다. 또한, 개발뿐만 아니라 디자인에도 제약이 생깁니다. 예를 들어, 글자 크기, 폰트, 아이콘 디자인, 문구 등의 수정이 필요할 때가 많기 때문입니다.
하지만 "내가 편하면 사용자는 불편함을 느낄 수 있다"라는 말을 떠올려보면 이 장애물은 쉽게 허물어질 수 있다고 생각합니다. 우리가 편하면 우리 서비스를 이용하는 사용자는 불편할 수도 있습니다. 불편함을 느끼는 사용자는 언제든 떠날 수 있다고 생각해 보면 얘기가 달라질 수 있지 않을까요?
위 내용들을 통해 관련 직군의 모든 작업자가 접근성의 중요성에 대해 분명히 인식했다면 이제 우리는 개발자로서 접근성을 위해 기술적으로 어떤 것들을 수행할 수 있는지 생각해 봐야 합니다.
개발자를 위한 접근성
우리에게 주어진 개발 일정은 늘 빠듯하고, 부족하게만 느껴져 접근성까지 챙기기 힘든 것이 사실입니다. 그렇더라도, 우리가 개발을 진행하면서도 가장 쉽게 접근성을 준수할 수 있는 방법이 있습니다. 바로 뼈대를 만드는 웹 표준입니다.
웹 표준을 준수하면 브라우저, 운영체제, 디바이스 환경에 상관없이 하나의 표준으로 동일한 웹 서비스를 제공할 수 있습니다.
웹 표준의 핵심은 우리도 잘 아는 시맨틱 웹입니다.
시맨틱 태그를 사용하면 웹 데이터를 기계가 이해할 수 있게 되어 스크린 리더, 화면 돋보기, 음성 인식, 키보드 오버레이 등 보조 기술이 웹을 더 쉽게 이해할 수 있습니다. 이는 접근성을 높이는 데 큰 도움이 됩니다.
또한, 시맨틱 태그를 사용하면 검색 엔진 최적화(SEO)에도 도움이 됩니다. 기계가 웹을 이해할 수 있어야 사용자가 웹 브라우징을 더 쉽게 할 수 있기 때문에 시맨틱 웹은 꼭 필요합니다.
시맨틱 마크업을 하기 위해선 아래 예시처럼 태그를 의미에 맞게 사용해야 합니다.
- 페이지 제목 또는 글 제목에는
<header>사용 - 콘텐츠 작성자, 저작권 정보, 관련 문서 등의 내용을 포함할 때는
<footer>사용 - 문서의 핵심 주제를 포함하는 메인 콘텐츠에
<main>사용 - 독립적으로 구분해야 하는 콘텐츠에
<article>사용 - 페이지의 가장 중요한 제목으로
<h1>사용 - 순서가 없는 목록으로
<ul>과<li>사용
태그를 반드시 의미에 맞게 사용해야 하는 이유는 스크린 리더는 아래 표의 태그들처럼 태그의 기본 역할을 암묵적으로 자동 결정해 사용자에게 전달하기 때문입니다. 물론 aria-role을 통해서 개발자가 태그의 역할을 임의로 바꿀 수는 있지만 올바르지 못한 역할 지정은 스크린 리더 사용자에게 잘못된 정보를 제공하기 때문에 주의해야 합니다.
의미 있게 태그를 사용하는 것만으로도 웹 표준을 지킬 수 있으며, 웹 표준을 준수해 접근성 향상까지 기대할 수 있습니다.
그렇다면 가장 기본적인 시맨틱 태그를 제대로 이해하고 사용했을 때와 그렇지 않을 때를 비교했을 때 어떤 차이가 있는지가 중요하겠죠?
이는 스크린 리더가 어떻게 인식해 사용자에게 전달하는지를 통해서 알아보겠습니다.
스크린 리더가 읽는 방법
이미지
보통 그래픽 이미지와 같은 콘텐츠를 표현하고자 하는 경우 <img> 태그를 사용합니다. 저희도 코딩을 하며 위 태그를 주로 사용해서 이미지를 보여줬습니다.
그리고, 코드리뷰를 할 때면 항상 이러한 리뷰가 달렸습니다.
'img에는 항상 alt 속성 추가해주기!'
'img태그에는 alt 속성을 어지간하면 적어주는 것이 좋습니다. 웹 접근성의 중요한 구성요소라네요!'
'이미지가 아직 로드되지 않은 경우나, 시각장애인 스크린리더에서 사용하려면 alt 속성이 꼭 필요하답니다!'
와 같은 리뷰들,,, 한 번쯤 보신 경험 있으시죠?
<img> 태그를 사용하면, alt 속성를 추가해야한다고 하는데 어떤 역할을 하길래 그럴까요?
조금 더 자세히 알아볼까요?
alt?
이미지는 텍스트가 아니라 콘텐츠 요소이기 때문에 그 의미나 용도를 스크린 리더가 인식할 수 있도록 대체 텍스트를 제공해야 합니다.
이미지 태그의 alt 속성은 이미지에 대한 텍스트 설명을 제공하며 필수는 아닙니다. 하지만 스크린 리더는 alt의 값을 읽어 사용자에게 이미지를 설명하기 때문에 접근성 측면에서 매우 유용합니다.
아래 당근 화면을 예로 들어 스크린 리더가 <img> 태그를 개발자가 마크업한 의도와 동일하게 이해하는지 비교해 보고, 올바른 대체 텍스트 작성 방법을 알아보겠습니다. 먼저 아래 이미지의 1번 영역, 마커를 <img> 태그를 사용해 표현하고자 합니다.
alt 속성을 사용하지 않은 경우
<img src="/assets/home/main/mobile/rebranded-image-top.png" />🧑🏻💻 (개발자): 딱히 설명해 주지 않아도 될 것 같은데 alt를 제거하자!
📢 (스크린 리더): 에셋 옴 메인 모바일 리브랜디드 이미지 탑 피앤지 이미지
왜 스크린 리더는 위와 같이 해석할까요? 스크린 리더는 이미지에 alt 속성이 없으면 파일 이름을 표현합니다. 대체 텍스트가 없기 때문에 대신 이미지 경로 정보인 src를 음성으로 전달합니다. 파일의 이름으로 콘텐츠를 설명하는 것도 방법이 될 수는 있습니다. 하지만 네트워크 오류, 콘텐츠 차단 등 서비스 관련 이미지를 표시할 수 없는 경우에는 서비스와 무관한 이미지의 alt 값이 음성으로 출력되기 때문에 접근성뿐만 아니라 다양한 환경의 사용자를 고려한다면 alt 속성은 꼭 필요한 속성입니다.
alt 속성을 사용했지만 값을 제공하지 않는 경우
<img src="/assets/home/main/mobile/rebranded-image-top.png" alt="" />alt 속성의 값을 빈 값("")으로 생략해 제공하는 경우에는 이미지가 핵심 요소가 아님을 뜻하기 때문에 스크린 리더는 img 태그를 해석하지 않습니다. 이 경우 스크린 리더 사용자는 웹 브라우징 과정에서 이미지 요소가 있다는 것을 알 수 없습니다. 따라서 배경 이미지처럼 단순 디자인의 목적을 가진 이미지는 의도적으로 대체 텍스트를 빈 값으로 작성해 스크린 리더가 읽지 않도록 할 수 있습니다. 하지만 이미지 1번 영역 죠르디의 상태로 높은 대출 승인율을 표현하는 콘텐츠임을 감안하면, 사용자에게 이미지 설명을 전달할 필요가 있다고 생각하기 때문에 다음 단계로 넘어가 alt 속성에 대체 텍스트를 작성해 보도록 하겠습니다.
적합한 대체 텍스트를 작성하지 않은 경우
<img src="/assets/home/main/mobile/rebranded-image-top.png" alt="손 흔드는 당근이 이미지" />🧑🏻💻 (개발자): 당근이가 손을 흔드는 이미지니까 ‘손 흔드는 당근이 이미지’로 작성하면 되겠지?
📢 (스크린 리더): 손 흔드는 당근이 이미지 이미지
이미지를 이미지라고 하는데 왜 적합하지 않은 대체 텍스트에 해당할까요? 시맨틱 태그는 암시적으로 role을 갖고 있으며, 스크린 리더는 <img>를 ‘이미지’로 자동으로 결정하게 됩니다. 따라서 이미지의 존재 여부를 표현하는 ‘사진, 이미지, 아이콘’등의 단어를 대체 텍스트에 포함하게 되면 스크린 리더가 기본적으로 해석한 ‘이미지’와 중복된 의미를 갖기 때문에 적합하지 않습니다.
따라서 아래와 같이 대체 텍스트를 수정해야 합니다.
<img src="/assets/home/main/mobile/rebranded-image-top.png" alt="손 흔드는 당근이" />버튼
다음은 <img> 태그만큼 많이 사용하는 <button> 태그입니다. 그렇다면 어떻게 <button> 태그를 사용해야 스크린 리더도 쉽게 이해할 수 있을까요?
먼저 우리는 스크린 리더가 코드를 어떻게 해석하는지 알아야 합니다. 브라우저는 코드를 스크린 리더가 읽을 수 있는 접근성 트리(Accessibility Tree)로 만듭니다. 스크린 리더는 접근성 트리의 요소를 순차 탐색하게 되는데, 접근성 트리에 표시되는 요소의 Name을 기반으로 해석합니다. 여기서 말하는 Name은 Accessible Name이라고도 하며 스크린 리더가 요소를 포커스했을 때 읽는 값으로 author와 contents 중 하나로 결정됩니다. 이때, author가 contents보다 우선순위가 높습니다.
- author: aria-label, aria-labelledby, title 속성,
<img>의 alt 속성, svg의<desc> - contents: Text 노드
<button type="button">
<!-- <img src="/assets/home/manner" alt="매너 온도" />: 구체적이지 않으며 추상적 -->
<img src="/assets/home/manner" alt="매너 온도 설명" />
</button>🧑🏻💻 (개발자): 아이콘 모양이 물음표니까 모양 그대로 전달해야지!
📢 (스크린 리더): 내 대출 승인율이란 버튼
위 코드에서 Accessible Name을 확인해 보면 스크린 리더가 왜 “매너 온도 설명 버튼”이라고 해석하는지 쉽게 알 수 있습니다. <img>의 author는 alt 속성으로 Accessible Name은 “매너 온도 설명”이 됩니다. <button>은 author가 설정되지 않은 경우 자식 요소의 Accessible Name을 모아 contents로 사용하는 Children Presentational이라는 특징을 갖습니다. 따라서 <button>의 content는 ‘매너 온도 설명’이 되고 스크린 리더는 자동적으로 결정한 role과 결합해 “매너 온도 설명 버튼”이라고 해석하게 됩니다.
스크린 리더가 어떻게 코드를 해석하는지 이해한 것을 바탕으로, 눈이 보이지 않는 사용자라면 어떤 부분에서 콘텐츠 해석의 어려움을 느낄지 고려해 서비스를 정확히 이해하고 사용할 수 있는 Accessible Name을 제공하는 마크업 작업이 중요하다는 것을 확인할 수 있었습니다.
aria-label
스크린리더는 화면의 텍스트를 읽기 때문에 화면의 텍스트가 해당 요소를 충분히 설명하고 있다면 스크린리더 사용자가 요소의 설명을 들을 수 있고, 어떤 요소인지 파악할 수 있을 것입니다. 하지만 반대의 경우는 그렇지 못합니다.
단순한 예시를 함께 볼까요?
유저 정보를 수정하는 form의 submit 버튼입니다.
<!-- 버튼 요소에 대한 설명을 텍스트가 충분히 제공하지 않습니다. -->
<button type="submit" onClick="{onClickHandler}">수정</button>
<!-- 버튼 요소에 대한 설명을 텍스트가 충분히 제공합니다. -->
<button type="submit" onClick="{onClickHandler}">유저 정보 수정하기</button>웹 접근성 측면에서는 요소에 대한 추가적인 설명을 제공할 수 있는 WAI-ARIA 표준을 사용해 요소에 추가적인 설명, accesible name을 넣어줄 수 있고, 스크린리더가 이를 읽게 할 수 있습니다.
<!-- aria-label 속성으로 요소에 추가적인 정보를 제공할 수 있습니다. -->
<button type="submit" onClick="{onClickHandler}" aria-label="유저 정보 수정하기">수정</button>WAI-ARIA에서 정의한 설명 요소를 사용할 수 있지만, 제일 좋은 것은 텍스트의 내용과 시맨틱 태그 만으로 요소를 충분히 설명할 수 있는 요소입니다.
끝으로
스크린리더가 웹 접근성 준수의 전부는 아닙니다.
웹 접근성의 목표는 "모든 유저"입니다.
단순한 개발보다는 이런 것들을 조금 신경써보며 모든 사람이 불편하지 않고 편하게 사용할 수 있는 시간이 되었으면 좋겠습니다.
끝~!
발표자료
