[SW개발] 코멘토 직무부트캠프: 웹 접근성- 제3주차

 

제3주차 소회

이번 주차는 세션을 진행하고 과제를 받아 제출했다. 이번 세션에서는 지난 과제의 피드백보다는 강의를 이어나갔다고 보는 게 옳은데, 1주차에서의 양이 많아서 처리하기가 어려웠기 때문이다. 이번 웹 접근성은 보통 알려진 것보다 더욱 세부적인 것들을 다루게 되었다. 지난 주차보다 다양한 부분을 다루었는데, 각각 내용은 길지는 않고 중요한 부분만 남겨보기로 한다.

 

 

제스처 애니메이션

제스처 애니메이션에서 웹 접근성에 대한 고려는 단순히 스크린리더 사용자 외에도 고려해야할 것이 있는데, 손떨림이 있거나 제스처를 사용하기 어려운 사람들을 위해서는 제스처만이 아닌 다른 형태로도 화면을 넘길 수 있어야 한다. 예를 들어, 슬라이더가 있다 치면 단순히 스와이프해서 넘기는 것만이 아닌, prev/next 버튼을 두어 다음으로 넘길 수 있게 하여야한다.

 

이런 형식으로 단순히 핑거링 제스처 외에도 화면을 넘길 수 있는 방법이 있어야한다

 

그 외에도 제스처 애니메이션을 끄는 등의 옵션을 주어 스크린리더기의 제스처와 겹치지 않게 처리하는 방법도 존재한다.

 

탭메뉴 UI

탭 메뉴 UI에 대해서는 문제가 될 수 있는 부분이 있는데, 이는 탭 메뉴의 특성 때문이다. 다음에 서술할 SPA의 문제점과 비슷하게 탭 메뉴는 화면이 바뀌지 않아 스크린리더가 바로 읽지 않는 문제가 있는데, 이 때문에 일어나는 문제는 바로 탭 메뉴의 하위 메뉴가 어떤 탭메뉴의 것인지 알 수가 없다는 점이다. 즉, A 탭 하위에 있는 메뉴들이 A가 존재하는 곳과 별개의 위치에 존재한다면, 스크린리더는 A탭, B탭, C탭을 읽고 A탭 하위 메뉴를 읽는다는 것. 이런 부분을 방지하기 위해서는 A탭 하위에 위치시키거나 하는 게 낫다. 또한 탭메뉴들은 반드시 스크린리더에게 "지금 탭을 선택했다"는 것을 알려주는 WAI-ARIA 속성(role="tablist", role="tab", aria-selected="true")을 필수로 구현하는 것을 추천하고 있다.

 

SPA 웹 접근성

React 시대가 되면서 SPA(Single Page Application)이 대세가 되었는데, 이는 웹 접근성에서 취약하다고 할 수 있다. 화면이 완전히 새로고침 되지 않고 콘텐츠만 조용히 바뀌는 SPA 특성 상, 로드되어야 읽는 스크린리더는 다시 읽지 못하기 때문이다. 이러한 SPA의 단점을 상기하고, MPA가 아닌 SPA를 사용한다면 화면이 바뀔 때마다 강제로 스크린리더에게 알려주는 등의 추가적인 접근성 조치가 필요하다.

 

Focusable과 Tabbable

Focusable은 간단히 말하면 초점(Focus)를 받을 수 있느냐고, Tabbable은 간단히 말하면 탭버튼으로 접근할 수 있느냐다. 이러한 개념은 정확히 기술이라기보다는 접근성을 설계할 때 무엇을 Focusable 해야하는지, Tabbable 해야하는지 나누기 위한 개념이라고 이해하면 좋다. 특히 스크린리더의 경우 이 Tabbable이 중요하기 때문에, 탭버튼만으로도 기능에 도달할 수 있는가를 중요하게 여긴다.

 

 

랜드마크롤

랜드마크 롤Landmark Role은 role="" 과 같은 속성으로 표기할 수 있는데, 스크린 리더 등 보조 기술 사용자가 웹페이지의 주요 구역(머리글, 본문, 탐색 메뉴 등)을 쉽게 파악하고 원하는 곳으로 바로 건너뛸 수 있도록 돕는 구조적 식별자이다. HTML5인 지금은 시멘틱 태그가 대체하고 있고, 사실 role 자체의 한계로 인하여 시멘틱 태그가 주로 채용되는데, IE(인터넷 익스플로러)에서는 시멘틱 태그의 사용이 지원되지 않아 시멘틱 태그를 포기하고 role을 사용하는 경우도 존재한다. 이에 대표가 네이버.

 

네이버의 소스코드, div에 role을 넣는다

주로 사용되는 role은 8개로, banner,  navigation,  main,  complementary,  contentinfo,  search,  form,  region 이렇게 있다고 할 수 있으며, 롤 이름과 역할은 꽤 직관적이라고 할 수 있다.

 

 

WAI-ARIA

ARIA에 대해서는 내가 다음과 같은 포스트를 공부를 위해 올렸다.

https://bbbbabbbababababa.tistory.com/143

[개인 개발 공부] 그래서, ARIA가 뭔데?

 

그러므로 여기서는 브레드크럼(Breadcrumbs)에 대해서만 이야기하겠다. 브레드크럼이란, 사용자의 현재 위치를 알려주는 내비게이션이라고 할 수 있다.

 

쿠팡의 페이지, 상품 상세페이지 상단의 이 내비게이션을 브레드크럼이라고 한다.

 

 

폼 요소 만들기

폼 요소를 만들 때의 주의점도 들었다. placeholder만 사용하지 않고, label을 사용하여 정확하게 input과 안내 문구를 연결시킬 것.

무신사 페이지. 이런 식으로 placeholder만으로 안내하면 안 된다는 것이다.

 

그리고 오류 처리에 대해서도 들었는데, 폼에서 오류와 관련된 문구(비밀번호가 일치하지 않는다 등)에 대해서는 가시성 있게 처리를 하고, 헷갈리지 않도록 처리를 한다. 특히 스크린리더 사용자에게는 오류에 대한 안내가 실시간으로 들릴 수 있도록 처리(예를 들어 aria-live 등을 통한 처리)하는 것이 좋다.

 

Browser fallback

해당 부분은 좀 기억이 잘 안 나는데 최신 기술이나 특정 기능을 지원하지 않는 구형 브라우저나 환경을 위해 준비해 두는 부분을 이야기한다. 위에서 네이버의 경우도 알 수 있듯, 모든 접근성 기능이 바로 적용되는 것은 아니다. 이에 따라 구형 브라우저를 사용하더라도 문제없이 돌아갈 수 있도록 해야한다는 이야기다.

 

 

로딩처리

이 부분은 간단히 말하면 로딩 화면에 대한 스크린리더기 처리이다. 로딩이 시작되면 안내를 시작하고, 로딩이 종료되면 해당 페이지를 읽는 등 스크린리더 사용자에게 "기다려야 한다"를 알려줘야 한다. 다만, 최근 인터넷과 기기의 스펙과 처리 속도가 늘어남에 따라 로딩 시간이 실질적으로 짧아지기도 하여, 1초 미만의 짧은 로딩은 안내하지 않거나 하는 게 좋다. 이러한 로딩을 안내하냐 마냐 또한 웹페이지를 만드는 사람이 생각하고 정해야한다.

 

 

스핀Spin 버튼

스핀버튼은 숫자를 직접 타이핑해 입력할 수도 있고, 옆에 달린 위/아래 화살표 버튼(▲▼)을 눌러서 값을 1씩 증가시키거나 감소시킬 수 있는 입력창을 이야기한다. 이러한 스핀버튼의 경우 탭으로만 하기엔 어렵기 때문에, 직접 값을 입력할 수 있거나, 키보드 버튼(↑↓)을 눌러서 조정할 수 있도록 해야한다.

 

 

아코디언 컴포넌트

아코디언 컴포넌트는 흔히 FAQ 등에서 발견할 수 있다. 누르면 아래로 내용이 나타나는 형태로, 다음과 같이 생겼다.

무신사의 아코디언 컴포넌트. 질문을 누르면 아래로 답변 내용이 나타난다.

 

접근성에서 이러한 아코디언 컴포넌트의 경우 질문을 누르면 자연스레 내용도 읽을 수 있도록 처리해야한다. 또한 tabbable하는 것이 좋고, 누르지 않았을 경우에는 답변을 듣지 않게 처리하는 게 좋다. aria-expanded 를 사용하면 간편하게 열림/닫힘 상태가 실시간으로 알려지기 때문에 추가해두는 것이 좋다.

 

 

과제

3주차 과제는 웹 접근성을 개선해야할 포인트 찾아보기였다. 이번에는 분량 제한이 없었기 때문에 사이트 다섯개를 찾아 최대한으로 개선 포인트를 찾았었다. 대상 사이트는 각 다른 분야(쇼핑, 엔터테이먼트, 구직, 문화생활, SNS)를 기준으로 t선정하여, ① 무신사 ② SOOP ③ 잡코리아 ④ NOL 인터파크 티켓 ⑤ 인스타그램 이렇게 다섯 가지를 선정했다. 총 13페이지를 달성했는데, 내용이 다른 과제에 사용될 여지가 있을까봐 짧게만 올려둔다.

 

각각 SOOP의 웹 접근성 지적 파트와 인스타그램의 웹 접근성 지적 파트

 

근본적으로 5개의 사이트 모두 명암 대비에서는 아쉬운 점수가 나타났다. 이 부분은 고대비 설정이라는 것이 다크모드 설정에 비해서 보편화되지 않았기 때문이다(실제로 다크모드 또한 지원하는 곳이 크게 없지만, 고대비보다는 더 많이 지원되고 있다)

 

위 과제 이미지에서 "자막 지원 미비"를 들었듯, 접근성에 대한 지적은 단순히 기술적인 부분만이 아닌, 실질적으로 이 사이트를 이용할 수 있는가에 대한 초점을 두었다. 실제 서비스하는 사람들도 이에 염두해야한다. 인스타그램에서도 마찬가지인데, 사진을 빠르게 넘기는 슬라이드 등에서 스크린리더 사용자가 과연 이미지를 진짜 인지할 수 있는지에 대한 의문이 있어 이에 대해서도 지적하였다.

 

이에 대한 멘토님의 피드백으로 코멘토에서 제출받은 과제 중 제일 잘했다고 하셨는데, 이에 대해서 뿌듯한 마음이 들었다. 꼼꼼하게 조사해간 보람을 느꼈고, 과제를 하며 생각보다 기업들이 웹접근성을 신경쓰지 않는다는 점이 뼈저리게 다가와 조금 씁쓸해졌다.