웹 접근성을 고려하면서 개발한 후기
아버지가 눈이 불편하시다보니 자연스럽게 웹 접근성을 지키면서 개 발하는 방법에 대해 관심을 가지게 되었다. 특별히 웹 접근성에 대한 자료만 찾아본 것은 아니고, 컴포넌트를 개발할 때 구현 방법과 관련한 리서치를 하면 항상 검색어 뒤에 with web accessibility를 접미사마냥 붙여주었다. 다음과 같이 말이다.
How to implement tab with web accessibility?
이를 통해서 다음과 같은 경험을 할 수 있었다.
1. 표준을 고려한 컴포넌트 개발
WCAG는 웹 접근성과 관련한 표준을 제공하는데, 내가 'How to implement ~ with web acessibility'라고 검색해서 나오는 아티클들 대부분은 WCAG의 접근성 패턴 가이드를 따라서 구현하는 방법을 설명해놓았다.
그렇기 때문에 표준에 조금 더 가까운 컴포넌트를 만들 수 있었던 것 같다. 개발하면서 기억에 남는 것은 모달 컴포넌트가 보여지면 탭을 해도 모달 컴포넌트 내부 요소에서만 탭이 존재해야 하는데, 이를 돕기위해 FocusKeeper라는 컴포넌트가 존재한다는 것이었다. 내가 지금까지 모달을 제대로 구현하지 않았구나하고 깨달았던 순간이었다. FocusKeeper와 관련한 구현 내용은 Making an accessible web modal를 참고했다.
2. UI와 친해질 수 있던 기회
아무래도 다른 때 보다 UI와 관련한 용어를 많이 마주했다. 사실 이 용어들은 개발하다보면 한 번쯤 만나볼 용어들인데 지금까지 제대로 정리를 안했었다. 이 기회를 통해서 UI / UX 용어 정리에 정리하였고, 지속적으로 업데이트할 예정이다.
또한 평소에 floating label UI 요소를 볼 때마다 굉장히 과하다고 느껴져서 이런 UI가 왜 이렇게 자주 보여지는거지?라고 생각했는데, 이것이 input 태그에서 아무 생각 없이 늘상 사용해오던 placeholder가 가지는 문제점을 해결하는 UI 요소라는 것도 배울 수 있었다.
3. semantic tag와 친해질 수 있던 기회
모달을 구현할 때 <dialog>라는 태그를 사용할 수 있다는 것을 알게됐다. 모달 UI는 오래 전부터 웹 접근성을 지키면서 개발하기 까다로운 문제가 있었는데, 이를 <dialog>가 쉽게 해결해준다고 한다. open 속성도 존재하고, show, showModal, close와 같은 자바스크립트 메서드도 제공하고, 심지어는 백드롭과 관련한 스타일링까지 가능하다. 다만 개발할 때 사용하기 애매한게, Edge, FireFox, Safari등이 비교적 최근인 2020년이나 2022년에 이 태그를 release해서 마음편히 사용하기가 어렵다. <dialog>가 어떤 기능을 갖고 있는지는 Modals Will Never Be The Same - HTML dialog Element를 참고하면 좋다.
더불어서 토스트 메세지를 구현할 때는 기본적으로 status role을 갖고 있는 <output> 태그를 사용할 수 있다는 것을 알게됐다. 비교적 옛날에 release가 됐는데, 토스트 메세지와 관련한 패키지들은 이 태그를 사용하지 않고 div 태그에 status role을 적용하고 있다. Edge가 비교적 최근에 지원해서 그런가 싶기도 하다.
4. 몇 가지 궁금증 해소
지금까지 개발하면서 몇 가지 궁금했던 점이 있는데, 그 중 일부를 해결할 수 있었다.
(1) 토글 버튼 구현 방법 차이
흔히 보이는 다크모드 토글 버튼 UI는 보통 다음과 같다.
구글에 검색해보거나 유튜브를 보면 알겠지만 태그 구현 방법이 <button>태그를 이용하는 방법과 <input>과 <label> 태그를 이용하는 방법 두 가지로 나뉜다. 어떤 차이가 있는지에 대해서 FE 입문 초기부터 굉장히 궁금했었는데, 접근성을 고려한 개발을 실천하면서 궁금증을 해소할 수 있었다. 구체적인 차이는 토글 버튼 구현을 위한 두 가지 방법 : Input + label vs button에 정리해두었다.
(2) 시각적 순서와 DOM 순서가 일치해야 하는 이유
전 직장에서 이미지 편집기를 결제하여 사용했다. 이 편집기는 기능 뿐만 아니라 화면 역시도 네트워크로 전달받은 스크립트로 그려졌는데, 문제는 이 스크립트가 난독화되어 있었기 때문에 코드를 직접 수정하여 프로젝트 디자인에 맞게 수정하는 것이 불가했다.
당시 팀장님께서 지시하셨던 것은 HTML 구조는 그대로 두고 CSS만으로 바텀 탭에 있는 버튼을 헤더로 옮기라는 것이었다. UI로도 그렇고, HTML 배치도 그렇고 바텀 탭에 존재하는 버튼은 헤더 탭에 존재하는 요소들보다 아래에 존재하게된다.
당시에 그렇게 하면 문제가 될것 같다는 '느낌'만 있었지 구체적으로 어떻게 문제가되는지에 대한 이유가 안떠올랐는데 웹 접근성을 공부하면서 답을 찾을 수 있었다. 관련한 이유는 에 적어놓았다.
input과 label의 배치, 그리고 시각적 순서와 DOM 순서가 일치해야 하는 이유
5. 느린 개발 속도
접근성을 챙기다보면 개발이 너무 느려진다. 두 가지 이유에서인데, 첫 번째는 wai-aria와 관련한 다양한 속성들을 만나면서 공부하느라 느려지고, 두 번째는 WCAG의 접근성 패턴 가이드를 지키면서 개발하느라 느려진다. 만약 접근성 테스트까지 추가된다면 더욱 더 느려질 것이다.
다만 긍정적으로 생각하는 점은, wai-aria의 경우 처음에 눈에 안익어서 그렇지 사용하는 속성이 다 비슷비슷해서 시간이 지나면서 점점 익숙해져서 괜찮다고 생각하고, pattern같은 경우는 한 번 알아두면 나중에 개발할 때도 같은 패턴으로 개발할 것이기 때문에 괜찮지 않을까 싶다.
종합적으로는!
상당히 다양하고 긍정적인 경험들을 할 수 있었다. 여기서 멈추는게 아니라 계속 이러한 개발 태도를 유지하긴 하겠지만, 개발 속도가 너무 느려지는 것이 사실인지라 어느 정도 타협은 할 예정이다. 😭