웹 접근성 인증 받는 방법과 후기

일평생 처음이고, 또 마지막도 될 수 있는 웹 접근성 품질 인증 심사에 대한 포스팅입니다. 일개 힘없는 프리랜서라서 더 잘하는 분들의 힘을 얻고자 인터넷에 관련된 검색을 많이 했었는데, 인증 후기를 도저히 찾을 수 없었습니다! 왜! 힘을 주시지 않는 겁니까… 그래서 최대한 삽질하지 않기 위한 몸부림을 기록하고자 키보드를 두들기게 되었습니다. 둥당기둥당.

---

웹 접근성은 무엇인가?

웹 접근성이란 쉽게 말해 웹 환경을 이용하기 어려운 사용자들에 대해서도 사용성을 보장해달라고 하는 것입니다. 예를 들어 시각장애인은 글자를 볼 수 없기 때문에 글자를 읽어주는 프로그램인 스크린 리더기가 인식하는 방법으로 웹 페이지를 구성해야 합니다. 청각장애인은 소리를 들을 수 없기 때문에 소리로 전달되는 정보에 대해서 글자로도 볼 수 있도록 해야 하지요. 그런 느낌입니다.

웹 접근성에 대해서는 훨씬 잘 정리된 문서들이 많으니 그것을 참고해주시면 될 것 같습니다.

• 웹 접근성 연구소에서 이야기하는 웹 접근성 개요
• 웹서울랩에서 이야기하는 웹 접근성 개요
• 리메인 스타일지침서에서 이야기하는 웹 접근성 (특히 컬러부분)

어떻게 장애인들이 웹을 잘 쓰게 할 것인가는 어려운 질문입니다. 실제로 웹을 사용하는 장애인들 입장에서 어떤 것이 더 편하고 수월할지 그 기준을 잡기가 굉장히 난감합니다. 세상에 사람들이 얼마나 많은데요. 그래서 그러한 표준을 잡기 위한 세계적인 움직임이 있습니다. 웹 콘텐츠 접근성 가이드라인(영문)을 확인해볼 수 있습니다. 또한 웹 접근성 연구소에서, 이 가이드라인을 한국 사정에 맞춰 기획한 한국형 웹 콘텐츠 접근성 지침이 있습니다. 후술할 인증 심사는 전부 이 지침을 기반으로 운용됩니다.

---

웹 접근성에 대해 알아봤던 과정

그냥 아무 웹 사이트에서, 우리 사이트는 접근성을 아주 잘 지원한다고 떠벌린다고 해서 그게 진실이 될 수는 없겠지요. 한국에는 그러한 웹 접근성을 잘 지원하는 웹사이트에 대해서 공인 인증 마크를 부여하는 제도가 있습니다. 웹 접근성 품질인증 공인기관에게 인증을 받으면 1여년 동안 품질 인증마크를 사이트에 박제할 수 있게 하여, “우리 사이트는 장애인 친화적이다!“라고, 아주 근거있는 주장을 할 수 있게 됩니다.

한국에서는 3개의 심사 단체가 있습니다. (정식 명칭으로는 웹 접근성 품질인증 공인기관)

• 웹와치
• 한국웹접근성인증평가원
• 한국웹접근성평가센터

그리고 심의료는 비쌉니다. 아래 표는 한국웹접근성평가센터에서 가져온 표입니다. 가장 소규모의 페이지를 받는다고 해도 수수료를 120만원이나 받습니다. 억 소리 나옵니다. 그리고 업체별로 심의료가 얼마나 싼지 알 필요도 없습니다. 왜냐하면 심의료가 세 업체가 모두 똑같기 때문입니다! 아니, 이게 무슨 소릴까요. 업체들끼리 담합을 한 걸까요? 여기에 관한 이야기는 뒤에서 계속 하겠습니다..

더더욱 무서운 점은 만약 심사에 불합격한다 했을 때 부적합 사유가 경미한 접근성 위반으로 인한 경우에 한해 최초 1회의 보완기회를 제공 한다는 겁니다. 완전 불합격되면 환불 같은건 꿈도 꾸지 말고 그냥 심사비 날라가는 거라고 합니다. 너무 무시무시하지 않습니까? 100만원 이상을 태우는데 그 돈이 그냥 허망하게 없어질 수도 있다니… 그렇다면 사유가 경미하다고 할 때 그 경미하다는 기준은 무엇일까, 최초 1회의 보완기회를 어떻게 하면 잘 살려야 할까.. 별의 별 생각이 다 들었습니다.

일단 한국웹접근성인증평가원을 선택하여 진행했습니다. 하여튼 진행이 수훨하게 잘 될지 걱정이 많았는데, 주된 이유는 두가지였습니다.

---

프리패스된 자가진단

첫째로는 자가진단과 관련된 이야기입니다. 접근성 인증을 받고자 하면 신청서를 제출하기 전에 자가진단을 하여, 그 진단 결과를 신청서에 첨부해야 합니다. 자가진단은 업체에서 명시한 방법으로 진행하는데, K-WAH 4.0 프로그램을 이용하는 법, 혹은 웹 접근성 자가진단 서비스를 이용하는 법 두 가지를 제시받았습니다.

하. 지. 만. 우리의 웹 사이트는 해당 툴을 지원하지 않는다는 겁니다! 이유를 전화로 물어봤습니다. 그랬더니 자바스크립트 기반으로 돌아가는 웹페이지는 지원하지 않을 가능성이 높다고 하는 겁니다. 프론트엔드를 vue.js 로 만들었어요. 근데 vue가 뭡니까? 기본적으로 단일페이지 웹 어플리케이션(SPA) 아닙니까? 이거는 지원되지 않는다는 겁니다. 그래서 어떻게 하면 좋냐고 물어보니, 그냥 업체 정보만 적어서 신청서 보내주시면, 자기네들이 알아서 지원되지 않는 페이지로 간주하고 자가진단 부분은 면제가 된다고 했습니다.

자가진단이 면제가 된다고 해서 마냥 좋지만은 않았는데요, 이건, 자가진단 프로그램에서 수정이 필요하다고 판단되는 부분을 미리 수정할수 있는 기회가 날라간 것이나 마찬가지였기 때문입니다. 만약 자가진단 툴이 제대로 되었다면, 본 심사 과정도 통과할 확률이 조금이나마 올라가지 않을까요? 근데 그런 시도조차 할 수가 없으니 답답한 마음이 들었습니다. 후술하겠지만 나름대로 vue-axe 라는 툴을 통해서 접근성을 최대한 보장해보고자 했는데, 시도는 좋았지만 지금 생각해보면 더 꼼꼼할 필요가 있었다는 생각이 들었네요.

---

애매한 평가 기준

둘째로는, 애매한 전문가 심사 평가 기준입니다. 본 심사는 크게 두 가지로 이루어져 있는데, 전문가 심사와 사용자 심사입니다. 제 나름대로 느낀 바로 구분을 해보겠습니다.

• 전문가 심사 : 웹 접근성 전문가가 평가 항목을 잘 수행했는지 보고, 이상이 없으면 OK.
• 사용자 심사 : 실제 장애인이 직접 특정 과업을 수행해보고 이상이 없으면 OK.

사용자 심사는 특정 과업 선정 후 수행 성공만 하면 된다는 아주 간단해보이는 기준이 있지만, 전문가 심사는 저 평가 항목 부분이 굉장히 애매했습니다. 어떻게 되어있는지를 한번 봅시다.

저기 저 세부평가항복이라는 오타 보입니까? 별로 관심이 없다는 증거가 아닐까요? (아님 말고)

세부평가항목에서 레이블 제공. 표의 구성. 이렇게 한두 단어로 띡 던져주면, 무엇이 오류이고 무엇이 괜찮은지 알 방도가 없습니다. 코딩적으로 어떻게 해야 한다는 지침도 전혀 없고요. html 태그를 어떻게 구성해야 하는지, 어떤 속성을 적절하게 넣어야 하는지에 대한 기준이 없으니까 정말 혼란스러웠습니다. 제 클라이언트와 아무래도 심사 넣기 전 불안한 부분들이 있다고 이야기를 하니까, 그러면 거기에 전화해서 기준을 물어보자고 했습니다. 왜 그 생각을 못했을까요!! 바로 전화하여 그 세부 평가 항목에 대해서, 어떻게 평가를 하는 건지 물어봤습니다. 그랬더니 친절하게도 자료를 보내주었습니다. 짜잔~ (대외비는 아닌 것 같아서 공개합니다.)

자료에는 각 평가 항목마다 어떻게 평가해야 하는지가 자세하게 적혀져 있습니다. 그리고 이 문서에서 살펴보면 알 수 있듯이, 심사 과정, 종류 뿐만 아니라 심사 비용까지 모두 세세하게 다 정해주고 있습니다! 그렇습니다. 심사 기관 세 개가 모두 같은 가격이고 평가 항목도 똑같은 이유는 정부로부터 공인받는 단체는 그렇게 해야 하기 때문이었습니다~

---

개발 전 고려사항

만약 이 글을 읽고 계신 분이 아직 웹 사이트 개발을 시작하시지 않은 분이라면, 그리고 정부와 관련된 사이트, 아주 많은 사람들이 사용하는 사이트를 개발하시는 거라서 인증 마크를 필수로 따야 하는 게 아니라면, 웹 접근성 인증에 대해서 다시 생각해보시기를 강력하게 권해드립니다. 단순히 웹사이트의 퀄리티를 보장받기 위해서 웹 접근성 인증을 따려는 시도는 하지 말아야 합니다. 정말 웹 사이트에 대해서 순수하게 접근성을 높이고자 한다면, 웹 접근성 체크 툴을 꼼꼼하게 사용하는 걸로도 충분하고, 접근성과 관련된 문서를 더 세밀하게 보거나 관련 컨퍼런스 혹은 세미나에 참석하는 게 더 도움이 될 것 같습니다. 사실, ui 관련 라이브러리를 쓴다면 접근성에 대해 그렇게 크게 신경쓰지 않으실 수도 있습니다. 라이브리에는 컴포넌트화된 ui 요소들이 많은데, 유명하고 많이 쓰는 라이브러리(예: 부트스트랩)에는 직접 만드는 것보다 더 치밀하게 웹 접근성이 보장되어 있는 경우가 많습니다.

그렇다면 이제 반드시 웹접근성 인증을 받아야 된다, 하시는 분들은 웹사이트 개발 초기부터 설계를 잘 잡아야 합니다. 필자는 접근성의 접도 잘 모르던 때부터, 웹사이트가 생소한 디자이너과 함께 사이트를 디자인했는데 막상 개발을 시작하고 보니 접근성에서 걸리는 부분들이 정말 많았습니다.

---

색상과 관련된 디자인

사용가능한 색상

사용할 수 있는 색상의 범위가 제한되므로 디자인할 때부터 신경을 써야 합니다. 크고 굵은 글씨는 명도 대비가 3:1 이상이어야 하고, 일반 텍스트는 4.5:1 이상이어야 합니다.

위 문구는 3:1 비율을 겨우 맞춘 색상입니다. 진해보이지만 놀랍게도 3:1에 근접한 색상입니다. 저 색상은 본문용으로는 사용할 수 없습니다. 글씨를 얇게 해서도 사용 못합니다.

와~ 이건 #767676 이에요~

위 문구는 본문용으로 사용할 수 있는 색상으로, 흰 바탕에서 접근성 색상(4.5:1)을 만족하는 최대 옅은 회색입니다. #777777 이 되어버리면 불합격 합니다. 회색이긴 하지만 아주 옅지는 않지요. 디자인적으로 잘 살릴 수도 있겠지만, 그래도 아주 옅은 색깔을 원한다면 좀 아쉬운 부분입니다.

사이트를 정말 이쁘게 만들고 싶어서 색상을 포기할 수 없다면, 두 가지 버전을 만드는 것이 방법이 될 수 있습니다. 접근성을 전혀 고려하지 않은 예쁜 색상만을 쓴 버전과, 접근성을 고려하여 명도 차이가 확실한 버전으로요. 물론 시도는 안해봤는데, 개발에 착수하고 한참 뒤에 색 때문에 고통을 받았지만, 처음부터 개발한다고 생각하면 괜찮은 생각이라고 생각합니다.

Webaim Contrast Checker (색상 명도 대비 확인하는 곳)

색상만으로 구분되는 콘텐츠를 넣지 말자.

디자인할 때 흔히 현재 활성화된 메뉴와 그렇지 않은 메뉴를 색상으로 구분하곤 하는데, 그렇게 하면 안 돼요. 색상만으로 한다면 완전히 다른 색상으로 구분을 주어야 합니다. “패턴, 명암(7:1 이상) 등으로 색에 관계없이 직관적으로 인식되도록 제공해야 준수한 것으로 인정” 한다고 하니깐요.

---

어떤 삽질을 해야 하는지 미리 알기

이건 사실 경험이 쌓여야 알 수 있는 것이지만 (그리고 경험이 쌓였다고 해서 그게 미래에 똑같이 적용되리라는 보장도 없긴 하지만) 후술할 필자의 삽질이 조금이나마 도움이 되기를 바랍니다.

---

인증과 실제의 괴리

본격적으로 인증하는 과정과 삽질을 적기 전에, 인증하면서 느꼈던 여러가지 부조리함을 먼저 적고 싶네요.

최신화되지 않은 문서

앞서 살펴보았던 웹 접근성 품질인증 표준심사 지침 문서의 가장 최신에 갱신된 날짜는 2015년 10월입니다. 하루하루 변화하는 웹 기술과는 대조적으로, 이런 지침 문서는 과거에 머물러있습니다. 대한민국은 빠르게 변화하는 시대에 맞춰 이런 리소스들을 발전시켜야 나간다고 생각합니다. 제가 장애인들을 생각하는 마음이 깊은 건 아니지만, 여러모로 많은 생각이 들었습니다.

문서가 갱신된 지 오래되었기 때문에 문서에서 나와있는 방법이 통하지 않을 때가 많습니다. 예를 들어 지표별 전문가심사 기준에서 모바일 명도대비평가는 http://troy.labs.daum.net 에서 보이는 화면을 CCA로 측정한다고 하는데, 저 서비스는 2020년 11월에 서비스가 종료되었습니다. 제가 처음 문서를 확인할 시점에는 접속이라도 가능했는데, 지금 이 글을 쓰고 있는 기준으로는 접속조차 되지 않습니다.

세부 항목들도 지금은 표준에서 더이상 사용하지 말라고 권고하는 속성이나 태그들이 이따금씩 보입니다. 인증에 통과하려면 최신 접근성 기술보다는 낡은 기법으로 사이트를 만들어야 합니다.

---

심사 기준 브라우저

기가 찼던 부분은 심사 기준 브라우저가 Internet Explorer (이하 IE) 최신 버전인 겁니다. 위키백과에 따르면 IE 는 2013년 10월 17일에 윈도우 8.1과 함께 출시되었다고 합니다. 개발자에게는 IE 자체가 표준을 지키지 않는다고 악명이 높지요. 그래서 개발자 도구가 잘 되어 있는 크롬 브라우저로 확인할 뿐만 아니라 직접 IE로 사이트를 구동시켜서 제대로 동작하는지 일일히 체크해야 한다는 것입니다! IE 에서도 원활하게 잘 돌아가도록 해야 하는 삽질이 늘어났습니다. 이는 후술토록 하겠습니다.

어찌보면 IE 로 심사 기준을 잡은 것은 굉장히 현실적이라고도 볼 수 있습니다. HTML5 기술지원센터의 데이터에 따르면 아직까지 10.8%의 점유율을 차지하고 있다는 것을 알 수 있고, 오늘날 대부분의 젊은 층 혹은 기술에 대해 조금이라도 알고 있는 사람들이 IE를 잘 사용하지 않는다 라는 뇌피셜로 유추해보건대, 아직까지 정보에 취약한 계층이 IE를 많이 사용하고 있다고 생각할 수 있습니다.

---

완성도가 떨어지는 센스리더

센스리더란, 심사에서 기준이 되는 윈도우용 스크린 리더 입니다. (참고 링크: (주)엑스비전테크놀로지 센스리더)스크린 리더란, 시각장애인들을 위해 화면에 나온 글자나 컨텍스트를 파악하여 소리로 읽어주는 프로그램입니다. 이 센스리더는 프로그램의 완성도가 일단 떨어집니다. 시각장애인들이 많이 사용하니까 심사에서도 기준이 되는 프로그램이겠지만, 프로그램을 직접 사용해보면 굉장히 옛날에 만들어진 프로그램이라는 것을 몸소 느낄 수 있습니다. 아래는 제가 겪었던 것들 중에 일부입니다.

1. 프로그램이 실행될 때 계정으로 로그인 하면 정식 버전으로 실행되고, 로그인 안하고 닫기 누르면 체험판으로 자동으로 넘어가는 방식에서, 아주 낡은 프로그램이구나 하는 인상을 받았습니다.
2. 프로그램이 실행되는 중에 다른 프로그램의 단축키가 먹힐 때도 있고 안먹힐 때도 있는 등 버그가 많습니다. 특히 VSCode 랑 센스리더랑 동시 사용은 절대 못할 것 같았습니다. 아예 텍스트 입력도 잘 안되는 경우가 많았습니다.
3. 문서화된 매뉴얼이 정말 옛날스럽습니다… 다소 불편하게 되어 있습니다. 지금은 프로그램을 삭제해서 캡처를 못했네요.
4. 센스리더에서 지원하지 않는 WAI-ARIA 속성이 존재하는데, 만약 센스리더가 이러한 속성을 맞닥뜨리게 되었을 때의 동작이 정의되어있지도 않고, 엑스비전테크놀로지에서 이러한 부분에 대해 내부적으로 따로 문서화해두지 않는다고 합니다. 이는 인증평가원에서 답변받은 내용입니다.

장애인들 입장에서, 점점 울며 겨자먹는 것들이 많아지는 게 아닌가 싶은 생각이 들었지만, 그 분들이 실제로 이 프로그램을 잘 활용하고 있는가는 제가 알 길이 없기 때문에, 여기까지 하도록 하겠습니다. 2009년에 쓰여진, 내가 센스리더를 구매한 이유 라는 블로그 글에서는 스크린 리더기가 최신 기술을 활용하기 어려운 현실에 대한 내용이 있습니다.

---

심사 절차

심사 절차는 그냥 제가 느낀 바에 따라 적겠습니다. 우선 위 심사 지침 문서를 참고하여 모든 항목을 완벽하게 충족시켰다고 가정하겠습니다.

자가진단

우선 자가진단을 합니다. 자가진단이 불가능하다면 패스해도 됩니다.

인증신청

신청서를 적습니다. 신청서를 적는 건 그다지 어렵지 않습니다. 신청서 날인은 사이트 운영자(클라이언트)의 대표자 것이 필요합니다. 개발과 관련된 내용은 전부 개발 담당자 혹은 유지보수 담당자에게 연락이 갈 것입니다. 인증 신청을 하면 인증 센터에서 인증 견적서와 앞으로의 일정 진행에 관한 메일이 옵니다.

입금

메일로 날라온 견적서의 내용에 따라 입금합니다.

본격적인 심사 들어가기 전에 가볍게 수정하기

본격적인 심사가 들어가기 전에 담당자가 연락이 옵니다. 언제쯤 심사가 들어갈 예정이고, 언제쯤 1차 결과가 보내질 것이라는 내용입니다. 또한 담당자가 간단한 수정사항을 요청합니다. 대개 색상과 관련된 문제입니다. 1차적으로 검수하는 건 자동화된 툴을 사용하는 것처럼 보였습니다. 분명 색상 기준을 지켰는데도 기준이 안맞다고 나온다는 겁니다. 그래서 한번 더 확인해봤더니, 서서히 나타나는 요소들이 그 중간에 색상이 기록되어서 기준이 맞지 않았던 겁니다. 그런 것 이외에도 자잘한, 진짜 수정해야 하는 사항들이 있었는데, 그것들을 수정하고 나서 다시 담당자에게 연락하고 하는 과정이 있었습니다.

거금을 들이는데 걱정이 되어서 담당자한테, 혹시나 불통될 여지가 있는 부분은 없는지, 막 잘 부탁드린다고 이야기를 드렸었는데, 이정도면 1차 보고서 나가고 해당 내용 반영만 잘 되면 아무런 문제 없을 거라고 안심시켜주셨습니다. 이 자리를 빌어 감사의 인사 올립니다. 문서상으로는 칼같이 경미한 사항에 대해서만 재심사 요청이 가능하다고 되어 있지만, 왠만해서는 유연하게 잘 처리해주시는 것 같네요.

1차 보고서 수령 및 반영하기

1차 보고서 수령까지는 대략 일주일이 걸렸던 것 같습니다. 메일로 날라옵니다. 내용은 꽤 자세하고 수정해야 하는 것들도 명시되어 있습니다. 하라는 대로 하기만 하면 됩니다. 보고서대로 진행했는 데도 실제 기능에 문제가 있는 경우에는 해당 심사 담당자가 따로 연락이 와서 다른 방식으로 다시 수정해달라고 요청을 해줍니다. 그러면 그대로 다시 수정하고 연락하는 과정을 반복하면 됩니다.

완료

이렇게 앙증맞게 합격 메일이 날라와요. 아. 정말 기분이 좋았습니다.

---

인증마크를 따기 위한 삽질 혹은 팁

항상 호환 브라우저를 확인하자

모든 자바스크립트 함수에 꿰고 있다 하더라도, 해당 함수가 어느 브라우저에서 언제부터 얼마만큼 지원되는지까지 모두 알고 있는 사람은 아마 없을 것입니다. 브라우저마다 참 제각각이지요. IE 는 정말 화려한 복병입니다. 당연히 된다고 생각하는 기능도 안되었던 경우가 많았습니다. CSS Custom Properties 도 그 중에 하나였지요. (스크롤 아래로 내려가 호환 브라우저를 확인하면 IE 의 붉은 X 표시가 참 인상 깊네요.. 하하) 어떤 기능에 대해 IE 가 호환되는지 항상 확인하도록 합시다.

그리고 그냥 IE 라는 이유만으로 안되는 경우도 많습니다. 예를 들어 Flexbox 에서 세로 정렬이 안되는 문제라든지… 하하

---

svg 요소는 탭을 먹는다

IE 에서는 svg 요소에 탭 순서가 적용됩니다. 그러니까 예를 들어 A버튼과 B버튼 사이에 svg 요소가 들어가있다면, A 버튼에 포커싱이 가 있는 상태에서 두번 탭을 눌러야 B 버튼으로 포커싱이 옮겨갑니다. 기괴하죠? svg 요소가 포커싱되어 있는 상태에 대해서는 아무런 스타일이 적용되어 있지 않으므로 svg 에 포커싱이 있으면 화면상으로 아무런 티가 나지 않습니다. 즉 탭이 한 번 씹힌 것처럼 보일 수 있습니다. 이는 탭 순서가 유의미하게 옮겨갸아 하는 항목을 위배하므로, svg 요소에 대해 focusable 속성을 false로 두어야 합니다. focusable="false" 이렇게요. 그러면 아예 탭이 안갑니다. 다른 브라우저에서는 svg 요소도 여느 이미지로 인식하여 포커싱이 멈추지 않습니다. 아무런 신경을 쓸 필요가 없지요.

이 부분에 대해서는 1차 보고서에서는 단순히 허공이나 애꿎은 요소에 의미없는 포커싱이 잡힌다고 말해주는데, 문제는 짜잔~ svg 였습니다.

---

색으로만 구분되는 콘텐츠를 넣지 말자.

이는 디자인 단계에서부터 먼저 신경쓰면 됩니다. 필자 같은 경우는 이미 디자인이 확정된 상태에서 해당 문제에 부딪쳤기 때문에, 현재 상태를 알려주는 가로선 하나를 임의로 추가하는 수 밖에 없었습니다. sad..

---

모든 button 요소에 title 속성을 달자

센스리더는 모든 button 요소에 title 이 있어야 한다고 합니다. (aria-label 속성은 언급조차 되지 않네요.. 하하) 추가시켜줍시다. bootstrap-vue 에서 기본적으로 제공하는 Modal, Sidebar 등의 컴포넌트에서 닫기 버튼은 title 속성이 없으므로 동적으로 추가시켜줍니다.

(중략)
<b-modal @shown="modalPrivacyShown"> ... </b-modal>
(중략)
methods: {
  modalPrivacyShown() {
    this.getFocusCloseButton("modal-privacy");
  },
  getFocusCloseButton(modalId) {
    this.$nextTick(() => {
      const buttonElement = document
        .getElementById(modalId)
        .getElementsByClassName("close")[0];

      buttonElement.focus(); // 포커싱을 닫기에 맞춥니다.
      buttonElement.setAttribute("title", "닫기"); // 닫기 버튼에 title을 추가시킵니다.
    });
  },
},
(중략)

---

모든 input 요소에 title 속성을 달자

센스리더는 input 요소에 대한 정보를 불러올 때 두 가지 방법을 사용한다고 합니다. 해당 input의 title 속성을 읽는 방법과 연결된 label 태그를 참조한다고 합니다. (label 태그는 for 속성에 해당 input의 id를 주면 연결시킬 수 있습니다.) title 속성은 사실 지양해야 한다는 의견이 많지만, 센스리더를 위해 어쩔 수 없지요. 기술적으로 두 가지 중 하나만 처리하면 되지만, 안전함을 위해 title 속성도 추가시켜 줍시다. 그렇게 어려운 것이 아니니깐요!

---

탭의 이동, 링크 클릭으로 이동하고 나서의 스크롤을 신경쓰자. (fixed 요소 주의)

보통 한 페이지 안에서의 네비게이션은 a 태그의 href 속성에서 #아이디를 넣는 방법을 활용할 수 있습니다. 이 링크의 기본 동작은 해당 요소가 화면의 최상단에 위치하도록 스크롤을 조정합니다. 그러나 화면에 고정된 메뉴 (예를 들어 position: fixed; 가 적용된 메뉴) 가 상단에 있을 때에는 링크를 클릭하면 해당 요소가 고정된 메뉴 뒤로 숨어버릴 수 있습니다! 대상 요소가 화면의 최상단에 위치하지만, 마침 그 자리에 고정된 메뉴가 이미 자리잡고 있기 때문입니다. 페이지 하나에서 목차 등을 통해 스크롤을 조정하거나, 특히 본문 바로가기 링크를 동작시킬 때에는 제대로 신경써야 합니다.

탭으로 요소를 전환할 때에도 마찬가지입니다. 길이가 긴 문서에서 항목들을 Shift + Tab 으로 거꾸로 거슬러올라가는 상황이라고 가정합시다. 그러면 화면 위쪽 바깥에 있는 요소에 포커싱이 가게 되면 해당 요소를 화면에 보이기 위해 스크롤이 위로 조정될텐데, 이 때에도 마찬가지로 고정된 메뉴가 해당 요소를 가릴 수 있습니다. 이 부분에 대해 필자는 특별한 처리를 하지 않았지만 다행히도 무사히 통과를 받았는데, 아마 심사할 때 충분히 걸고 넘어질 수 있는 사안이라고 생각해서 안전하게 하려면 이런 부분까지 모두 신경을 써야 할 듯 합니다.

간단히 말하면 사용자가 조금 불편을 감수하더라도 고정된 메뉴는 만들지 않는 게 안전합니다. 사이드 바 정도는 괜찮을 것 같습니다.

또 다른 문제로는, SPA 특성상 다른 주소로 라우팅된다고 해도 스크롤도 적절하게 조정된다는 보장이 없다는 것입니다. 특히 vue 에서 router-view 요소로 하위 라우터를 구성했다면 주소가 바뀔 때마다 스크롤 위치를 적절하게 변경시켜줘야 합니다. 왠만해서는 router-view 가 뷰를 전환하는 과정에서 스크롤이 가장 위로 가겠지만, 만약 가지 않는다면 조정해줍시다.

---

aria 속성은 크게 신경쓰지 않아도 된다.

우선 심사 지침에서 aria 와 관련된 내용은 별로 많지 않습니다. aria-hidden 과 같이 정말정말 많이 쓰는 접근성 속성 정도만 신경쓰면 됩니다. 비교적 최신에 나오거나 생소한 aria는 마음 놓고 쓰지 않아도 됩니다. 단, 진정성있게 접근성에 신경쓰겠다면 올바른 role과 거기에 대한 적절한 aria 속성을 붙여줘야겠습니다.

---

복잡한 메커니즘을 가진 컴포넌트는 이왕이면 사용하지 말자 (센스리더의 한계)

앞서 말했듯이 센스리더는 최신 기술을 제대로 반영하지 못하는 경우가 있습니다. 그래서 아무리 웹접근성 표준을 지킨 컴포넌트라고 하더라도, 센스리더로는 제대로 동작하지 않았던 vue-bootstrap 의 컴포넌트가 있었는데, 바로 b-form-datepicker 컴포넌트였습니다.

본 컴포넌트를 사용자 심사 담당자가 센스리더로 조작하려니까 자꾸 의도치 않은 행동을 한다는 겁니다. 1차적인 답변은, 센스리더에서 지원하지 않는 aira 혹은 role 속성이 쓰여서 제대로 동작하지 않는다는 것이었습니다. 정말 삽질 많이 했습니다. 직접 컴포넌트의 aria 속성을 건들기 위해서는 해당 컴포넌트가 정상적으로 mount 된 다음 동적으로 해당 엘리먼트를 찾아 속성을 일일히 지워주는 작업이 필요했습니다. 해당 aria 속성은 컴포넌트의 props 로 수정할 수 없는 그런 것들이었지요. 하지만 여전히 센스리더는 오작동을 일으킨다고 했습니다. 하루 꼬박 이 조그마하지만 복잡한 컴포넌트에 목매달다가, 결국 포기하고 간단한 형태로 수정했습니다.

custom input 은 일체 사용하지 말고, 그러니까 예를 들자면 div 요소에 contentEditable 속성을 둬서 수정할 수 있는 폼을 두는 시도는 하지 말고, 맘 편하게 textarea 요소를 사용합시다. 만약 직접 select 요소를 만든다고 가정한다면, focus 부분도 일일히 처리를 해주어야 하고, 방향키, 스페이스바, 엔터 키에 대한 적절한 동작이 이루어져야 하고, 신경쓸 것이 한두 가지가 아닙니다. 가능하다면 가장 기본적인 형태의 input 을 사용합시당.

---

외부로부터 가져다 사용하는 Vue 플러그인이나 컴포넌트는 IE 에서 잘 동작하는지 매번 확인해야 한다.

별로 유명하지 않은 플러그인이라면 십중팔구 IE 에 대한 대응이 없는데요, 고로 특정 플러그인이 IE 에서 제대로 동작하리라는 보장이 없습니다. 직접 실행시켜봐야 안다는 것입니다! 필자의 경우 vue-page-title 이 IE 에서 에러를 일으킨다는 사실을 발견했습니다. 그것도 아주 힘들게 발견했습니다. 왜냐하면 IE 에서는 원체 느리기도 하고 에러가 떴을 때 로그는 절대 친절하지 않기 때문입니다. 심지어 로그가 뜨지 않을 때도 있습니다. 수많은 시도 중에 무엇이 IE 를 뻑가게 했는지 알 방법이 없으니 의심되는 기능부터 끄고 켜고를 반복할 수 밖에 없었는데, 그러면서 겨우 발견했지요. 답답한 점은 해당 플러그인이 “왜” IE에서 문제가 되는지도 알 수가 없으니 대체제를 찾거나 직접 코딩하여 구현할 수 밖에 없다는 점입니다. 필자는 vue-page-title 의 코드를 직접 보면서 구현했습니다. (나중에 코드를 더 뜯어고치면서 본래의 코드와는 동떨어진 모양이 되긴 했지만요.)

---

다른 사람과 함께 검수하자

우리는 모두 사람입니다. 모든 input 태그, 버튼 태그, 모든 이미지의 alt, 뭐 이것저것 등등 하나하나 빠짐없이 다 챙겼다고 생각했지만 구멍은 항상 존재하기 마련입니다. 그러므로 다른 사람과 함께 검수하는 과정을 거치는 것이 훨씬 좋습니다. 필자는 클라이언트와 어느정도 친밀한 관계였기에, 클라이언트가 프로그래밍적인 지식이 전혀 없었음에도 불구하고 제가 하나하나 설명하면서 어떤 항목은 어떻게 처리했다고 점검해보는 과정을 함께 할 수 있었습니다. 정말 완벽하게 했다고 생각했는데도 거짓말처럼 미처 챙기지 못한 부분이 있었지요.

---

갈무리하며

웹접근성 인증에 대한 기나긴 여정이었습니다. 제가 이런 삽질을 할 날이 다시 올지는 모르겠지만, 나름 귀중한 경험인 것 같습니다. 접근성을 보장하려고 노력하는 몬든 분들께 응원을 보냅니다. 그리고 조금이나마 도움이 되었으면 좋겠네요. 파이팅!!!