[SW개발] 코멘토 직무부트캠프: 웹 접근성- 마지막

 

제4,5주차 소회

마지막 세션과 4주차 과제는 밀접한 연관이 있기 때문에(왜냐하면 내 업무(과제)를 확인하고 멘토님께서 같이 찾아봐주셨다), 같이 다룬다. 다만 멘토님이 세션에서 알려주신 부분들은 거의 말하지 않으려고 한다. 이 과제에 대한 '정답'을 알려주는 거랑 같기 때문에…

 

이번 업무는 velog의 웹 접근성 개선점에 다는 업무를 했는데, 무려 9페이지가 나왔다. 모든 내용을 다 다루지는 않겠지만 메인 페이지에 있는 것만 살짝 다뤄보려고 한다.

 

velog는 개발자들이 정말 사랑하는 블로그이긴한데…

 

velog의 웹 접근성은 낮다. lighthouse에서는 92점, WAVE의 AIM Score는 7.9점으로 나왔지만 높다고 할 수는 없다. 이것도 뭐 접근성이 제일 높아야하는 메인이라 내부 페이지는 더 심하다고 할 수 있다.

 

아니나 다를까 본문 포스트 점수를 봐라.

 

 

무려 메인에만 크게 세 가지의 문제점을 찾았고, 그 중 필터 드롭다운에서만 6개의 문제점을 지적했다. 

 

 

메인 로고 및 상단 아이콘의 접근성 문제

 

가장 먼저 보이는 것은 메인 로고이다. 메인 로고의 경우 <a> 링크를 사용하고 있고, 안에는 svg와 path를 사용한다. 이 방식은 세 가지 측면에서 접근성에 문제가 되고 있고, 이는 다른 메뉴 아이콘에서도 그대로 적용되는 문제다.

 

첫 번째, 어디로 향하는 링크인지 적혀져 있지 않아(텍스트 자체가 없음) 어느 링크인지 알 수 없다. 두 번째, 안에 있는 이미지에 대체 텍스트가 누락되어 알 수가 없다. 세 번째, svg 안에 직접 path 태그를 넣었다. 이것은 셋 중 하나가 해결되어도 나머지 두 가지 때문에 접근성이 낮다고 할 수 있는 문제이다.

 

먼저 이미지에 alt가 없어 velog라는 로고임을 알 수 없고, 알게 되더라도 로고만으로는 어디로 가는 링크인지 알 수 없다. 또한 path의 경우 경우에 따라 스크린 리더가 읽을 수도 있어 읽지 않도록 처리해야만 한다.

 

이 부분을 개선하기 위해서는 a 링크에 aria-label 등을 사용하여 “velog 홈으로 이동” 등을 주어 스크린 리더 사용자가 무슨 목적의 링크인지 알 수 있게 해야 한다. 또한 그 자식 태그에 aria-hidden을 넣어두는 것이 좋다. 로고 이미지에 alt를 사용하는 것도 좋지만, 본 버튼의 목적은 홈으로 가는 링크이므로 그 부분을 강조하는 쪽이 웹 접근성 측면에서 더 좋다. 이 부분은 알림 및 검색 등 다른 버튼도 마찬가지이다.

 

더 보기 메뉴와 필터 영역

 

이 부분은 특히 접근성에서 문제가 많은 부분이다. 정리해 보면 다음과 같다.

 

 

 

1) Focus 문제
velog에서는 더보기 메뉴 버튼을 a 링크나 버튼이 아니라 svg 자체를 사용하고 있다. 이 때문에 무슨 목적의 버튼인지 알 수 없고, tab을 통한 focus 또한 불가능하다. 필터 박스 또한 마찬가지인데, div 안에 "이번 주"라는 글씨만 있어 무슨 의도인지 알 수 없고, 포커스 또한 되지 않아 조작이 불가능하다. 각각 목적에 맞게(button, select) 태그를 수정해야 한다.

 

2) Focus 표시의 부재
서브 메뉴 등을 연다고 하여도 지금 연 메뉴가 무엇인지 등에 대한 focus 시각화 처리가 존재하지 않는다. 이는 일반 사용자 또한 불편함을 느낄 UI/UX적 문제라고 할 수 있다. 아웃라인을 만들거나 명도 차이를 강하게 주는 등의 처리가 필요하다.

서브 메뉴에 hover할 경우 글자 색상으로만 hover를 표기하는 것 또한 문제다. 아래는 개발자 메뉴에서 Achromatopsia(색맹) 처리를 했을 때의 모습이다.

보다시피 hover를 할 경우 단순히 짙은 회색과 검정으로서, 서로 명도 차이가 크게 나지 않아 차이점을 느끼기가 어렵다. 이 경우 배경색을 바꾸거나 border를 좀 더 굵게 하는 등의 처리를 하는 것이 좋다.

 

3) 비표준 드롭다운 박스 사용
select 방식이 아닌 서브메뉴로 필터를 하는 것도 큰 문제다. 해당 드롭다운을 열면 focus가 바로 서브메뉴에 가지 않으며, 누른다고 해도 "오늘"이 먼저 나타난다. 오늘-이번주-이번 달-올해 이렇게 나타나는데, 문제는 사용자가 이 목록이 네 개라는 것도 알 수 없고 각 서브 메뉴의 내용이 뭔지 알 수 없다. 원하는 게 있다면 탭으로 한 번 드롭다운을 확인하고 다시 탭을 해야 하는데, 이 과정이 굉장히 번거롭다. 디자인의 목적이라면 select box를 적절한 css 처리로 꾸미는 것이 낫다.

 

4) 목적을 알 수 없는 메뉴
각 서브메뉴를 여는 버튼에도 아무런 label이 없어 무슨 목적인지 알 수 없다. 즉, 스크린 리더 사용자는 더보기 버튼의 목적도 모르고, 더보기 버튼으로 펼쳐진 메뉴들도 모르고, 심지어 서브메뉴가 펼쳐졌다는 사실조차 모를 가능성이 높다. aria-expanded의 설정이나 aria-describedby를 통한 설명이 중요하게 작용하는 부분이다.

 

5) Opacity를 사용한 화면 제어
서브메뉴에 opacity로만 on/off를 조절하는 것도 큰 문제다. visibility: hidden 등을 사용하지 않으면 스크린 리더는 화면에 보이지 않는 서브메뉴를 전부 읽어버린다. 주 메뉴가 아닌 서브메뉴를 계속 읽게 되면 스크린 리더 사용자 입장에서는 현재 위치를 잃어버리게 된다.

 

6) Tab 포커스 가두기(Focus Trap) 미비
서브 메뉴 내에서 포커스가 순환되지 않는다. tab으로 내용을 전부 안다고 하여도 tab이 루핑(Looping)되지 않기 때문에 다시 선택하려면 새로고침 등을 해야 한다. 특히 velog는 무한 스크롤을 사용하기 때문에, tab을 사용하면 거의 영원히 맨 위로 돌아올 수 없다. 서브 메뉴가 열렸을 때는 포커스를 해당 메뉴 내부로 한정시키는 처리가 필요하다.

 

탭 메뉴의 모호성과 마크업 오류

 

먼저 이 탭 메뉴의 의도가 무엇인지 추론하기 어려운 게 첫 번째 문제다. 포스트 모음을 각 메뉴에 따라서 분류했다고 추측할 수는 있으나, 실제로 화면에서 읽히는 것은 트렌딩, 추천, 최신, 피드 같은 문자뿐이다.

 

일반 사용자들의 경우 아래에 뜨는 포스트 목록을 보며 의도를 추론할 수 있겠지만, 포스트를 보지 못한 채 메뉴만 본다면 직관적으로 이해하기 어렵다. “포스트 목록”이라는 말 등도 없기 때문에 서비스 이해도가 떨어질 수 있다.

 

또한 nav 태그에 <ul>과 <li>를 사용하지 않아, 해당 메뉴가 몇 개인지 알 수가 없고 목록 탐색 단축키(L키)도 사용할 수 없게 된다. 이는 웹 접근성은 물론이고 웹 표준적으로도 어긋나 있는 부분이다.

 

기타 자잘한 문제점들과 헤더의 일관성

• IR(Image Replacement)의 부재: 좋아요 수에 대한 아이콘을 svg로만 처리하여 무슨 의미인지 알 수가 없게 되었다. 위쪽에서 언급한 이번주/올해 등의 필터 또한 IR이 없어 무슨 의도인지 알 수 없다.
• H1 태그 누락: 메인 페이지 내에 <h1> 태그가 없는 것 또한 웹 표준에 어긋난다.
• 고정 메뉴 및 헤더 일관성 문제: 우상단 고정 메뉴에서 새 글 작성 버튼이 페이지가 이동함에도 button으로 처리되어 있는 점, 포커스는 가되 outline이 나타나지 않는 점 등이 문제다.
• 무엇보다도 해당 영역들이 <header>라는 시맨틱 태그 아래에 있지 않다. 스크린 리더 사용자들이 헤더 영역을 건너뛰지 못한 채 페이지가 넘어갈 때마다 이 상단 메뉴를 매번 파악해야 하는 번거로움이 생긴다.

 

이렇게 메인에서만 많은 문제를 지적했고, 실제로 멘토님께서도 흡족하셨던 것 같다. 이 이후로 본문이나 검색, 글쓰기 등에서도 발견한 문제점이 꽤 되었으므로 직접 찾아보는 것도 도움이 될 것이다.

 

이렇게 세션을 마무리했다. 5주간 재미있는 경험을 했었고, 무엇보다도 실제 웹 페이지를 해체분석함으로써 반례로 삼을 수 있어 확실히 머릿속에 들어온 느낌이다. 웹 접근성이라는 주제가 진짜 업무를 하기 어려운 주제라 이렇게 한 것인가? 싶을 수도 있지만 실제로 멘토님께서는 이렇게 기업의 웹 접근성을 지적하고 피드백하는 업무의 경험이 있으신 듯했다. 이런 경험이 앞으로에도 도움이 많이 될 거 같아 기대된다.