> 아이디어
사이드 프로젝트를 하나 만드려는데 좋은 아이디어가 떠오르지 않았다. 흔한 게시판이나 쇼핑몰, 영화 사이트가 아닌 독특하거나 난이도가 있는 프로젝트를 원했다. 생각이 늘어지다가 gpt한테 의견을 물어보면 어떨까 생각했다.
역시 gpt다. 하나 같이 좋은 아이디어들 뿐이다. 그 중에서 5번, 웹 접근성 평가 도구가 눈에 들어왔다. 평소에 웹 접근성에 대해 대충은 알고 있어도 잘은 몰랐기에 공부도 할 수 있고 무엇보다 흔치 않은 점이 마음에 들었다.
> 어떤 스타일로 만들까?
기존에 있는 웹 접근성 검사 도구들에 대해 알아보았다. 보통 명도 대비나 호환성 검사와 같이 웹 접근성의 일부 항목을 평가하거나 전체를 검사하더라도 웹 사이트보단 프로그램 형태로 존재했다. 몇가지 웹 사이트들도 대부분 옛날에 만들어진 페이지들이라 ui가 복잡했다.
(↑기존에 존재하는 페이지의 복잡한 ui)
우리가 구글에 파파고 번역기나 세금 계산기 등을 검색하여 몇 번의 입력과 클릭으로 원하는 결과를 얻듯이 검사할 파일을 툭 업로드하면 바로 검사 결과를 얻을 수 있는 사이트를 만들기로 하였다.
> 어디까지 구현하지?
웹 접근성 검사 도구를 만들기 전 몇 가지 고려사항이 존재한다. 첫째, 대상을 어디까지 잡을 것인가. html만을 검사할지 css나 js도 검사할지, 혹은 프로젝트 전체를 할지. 또 jsx나 ts 파일 등은 어떻게 처리할지 등을 정해야 한다.
둘째, 파일을 업로드할지 url을 입력할지를 정해야 한다. 두 경우에 따라 대상도 달라지는데, 예를 들어 파일을 업로드하는 경우 jsx나 ts는 컴파일이 필요할 수도 있고, 대신 html이나 js 파일로 대상을 제한할 수도 있다. 반대로 url을 입력하는 경우 이미 그려진 화면을 읽으면 된다.
이것저것 따지다보니 규모가 너무 커지고 복잡해지는 듯 했다. 너무 일을 키우면 있던 의욕도 사라지니 현실적으로 파일을 업로드하되 html과 css만을 대상으로 하기로 했다. 추후에 여유가 된다면 url을 입력받는 경우까지도 구현하기로 했다.
(↑기존에 존재하는 url을 입력받는 형식의 페이지)
> 너무나도 많은 검사 항목들
어떤 항목들을 검사해야 하나 찾아보니 너무 많은 항목들이 있었다. (이 중에서 내가 지키고 있던 것은 거의 없었다. 그동안 웹 접근성은 고려하지 않은 채로 개발을 해왔던 셈이다.) 역시 gpt가 난이도 높은 프로젝트로 추천한 이유가 있었다. 이 항목들을 모두 검사하려면 시간도 시간이거니와 난이도도 상당하다. 적당히 타협을 해야 했다. 계획은 이러했다.
- img 태그에 alt 속성 여부 검사와 같은 대표적인 항목 위주로 검사
- 검사 항목 부분을 제외한 코드를 먼저 작성하고 항목을 하나씩 추가하는 식으로 진행
- 항목이 비교적 직관적이고 간단한 레진코믹스 웹 접근성 가이드라인 참고
- 각 항목에 대한 기능은 axe-core 라이브러리 참고
> 끝
손가락을 놀게 두지 않고 싶어서 급하게 아이디어를 정하고 대충 알아본 뒤 다짜고짜 프로젝트 세팅부터 하고 봤다. 아직 정리가 되지 않은 부분이 있지만... 어떻게든 잘 해내겠지.
좋지 않은 습관이기도 하고 한편으론 장점이기도 한데, 나는 확실히 진행하면서 추가적으로 알아보고 정하는 스타일이 잘 맞는다. 협업에서는 치명적인 단점이 되는 경우가 있기에 고치고 있지만, 역시 사이드 프로젝트는 흥미, 재미가 중요하기에 편한 스타일로 진행했다.
