웹접근성 점검 도구를 오픈소스로 — 알리첵(A11y Check) 이야기

“우리는 인증도 받았으니 괜찮겠지.” 웹사이트를 만드는 쪽에서 이렇게 안심하기 쉽습니다. 그런데 인증 마크가 붙은 사이트에서도, 스크린 리더 사용자가 로그인 버튼을 못 찾고 저시력 사용자가 회색 위 회색 글씨를 못 읽는 일은 흔합니다. 점검을 한 번 받았다는 것과, 지금 이 순간 쓸 수 있다는 것은 다른 이야기거든요.

그 간극을 줄여보려고 만든 웹접근성 점검 도구가 알리첵(A11y Check) 입니다. 웹 주소 하나만 넣으면 웹접근성을 자동으로 검사해 보고서와 개선 가이드를 돌려주는 서비스예요. 이 글에서는 알리첵이 무엇을 하고, 어떻게 동작하며, 왜 오픈소스로 열었는지를 정리합니다. 먼저 이 도구가 어디에서 왔는지부터요.

모두웹이 남겨둔 자리

예전 세미나 발표에서 모두웹(ModuWeb) 이라는 오버레이형 접근성 보조 도구를 소개한 적이 있습니다. 스크립트 한 줄로 사용자가 글자 크기·색 대비·키보드 이동을 스스로 조정하게 돕는, 오픈소스 도구였어요.

그때 모두웹의 여정을 세 단계로 그렸습니다.

• STAGE 1 — 오버레이 지원: 사용자가 직접 접근성을 조정 (운영 중)
• STAGE 2 — 점검 & 가이드: 개발자·운영자가 스스로 고치도록 (그때는 계획)
• STAGE 3 — 내재화된 웹: 오버레이가 필요 없는 세상 (지향점)

오버레이는 급한 불을 꺼주지만 근본을 고치진 못합니다. 화면 위에 덧대는 방식이라, 정작 HTML 코드의 문제는 그대로 남거든요. 그래서 언젠가는 코드 자체를 고치는 단계로 가야 한다고 적어뒀습니다. 그 STAGE 2를 실제로 만든 것이 알리첵입니다.

방향이 이렇게 잡힌 데는 이유가 있어요. 접근성을 잘 갖춘 큰 기업·기관은 이미 전담 인력과 예산이 있습니다. 정작 도움이 급한 곳은 소규모 공공기관, 복지·비영리 단체, 접근성이 낯선 중소기업이에요. 이런 곳에 필요한 건 완벽한 컨설팅이 아니라, “지금 뭐가 문제고 어디를 고치면 되는지"를 바로 알려주는 도구입니다. 논쟁을 기다려줄 여유가 없는 현장에는, 손에 잡히는 다음 한 걸음이 먼저니까요.

알리첵이 하는 일

알리첵의 일은 한 문장으로 줄이면 이렇습니다. 웹 주소를 받아, 접근성 위반을 찾아, 고칠 수 있는 형태로 돌려준다.

점검 기준은 두 가지를 함께 봅니다.

• WCAG 2.2 AA — 국제 표준인 웹 콘텐츠 접근성 지침(Web Content Accessibility Guidelines)의 AA 등급
• KWCAG 2.2 — 그 한국형 버전(한국형 웹 콘텐츠 접근성 지침). 국내 법·공공 조달·품질인증이 이 기준을 씁니다

둘은 뿌리가 같아 상당 부분 겹치지만, 항목 번호와 표현이 다릅니다. 예컨대 “명도 대비 부족"은 WCAG에선 1.4.3, KWCAG에선 5.4.1이에요. 국내 사이트라면 둘 다 봐야 국제 기준도 국내 기준도 빠지지 않습니다. 알리첵은 한 번 검사에서 두 기준의 항목을 나란히 매겨줍니다.

결과로는 세 가지가 나옵니다.

1. 준수율 — 점검한 요소 중 통과 비율을 한 숫자로. 추세를 보려고 검사할 때마다 기록해요.
2. 위반 목록 — 규칙별로 “어느 페이지의, 어떤 요소가, 왜 걸렸는지”
3. 개선 가이드 — 각 위반을 어떻게 고치는지. 여기가 알리첵이 가장 공들인 부분입니다

어떻게 동작하나

점검 엔진의 뼈대는 axe-core입니다. 접근성 테스트 분야에서 사실상 표준으로 쓰이는 오픈소스 규칙 엔진(Deque Systems가 만들었고 MPL-2.0로 공개돼 있어요)이죠. axe-core가 페이지를 실제로 렌더링한 뒤 색 대비, 라벨 유무, ARIA 사용, 랜드마크 구조 같은 걸 규칙에 따라 판정합니다. 알리첵은 그 위에 KWCAG 매핑과 한국 현장에서 자주 나오는 패턴을 잡는 자체 규칙을 얹었습니다.

한 건의 위반이 어떻게 기록되는지 보면 이 도구의 성격이 드러납니다. 실제 리포트의 한 항목을 그대로 옮기면 이런 모양이에요.

규칙: color-contrast (심각)
기준: WCAG 1.4.3 · KWCAG 5.4.1
페이지: /posts/high-contrast-mode
선택자: .toc-has-children > a
자동 진단: 전경색 #7a7a7a, 배경색 #f5f5f3 → 대비 3.93:1 (기대 4.5:1)
참고: dequeuniversity.com/rules/axe/color-contrast

포인트는 “어디를(선택자) 왜(진단) 얼마나(수치)“가 다 들어 있다는 겁니다. “접근성이 부족합니다” 같은 막연한 통보가 아니라, 개발자가 코드 편집기에서 바로 그 요소를 찾아 고칠 수 있는 단서를 줍니다.

여기서 한 걸음 더 나갑니다. 알리첵은 이 위반들을 모아 AI 개선 가이드 문서를 만들어요. 위반마다 [대상 위치] → [수정한 코드] → [수정 이유 한 줄] 형식으로 정리하고, “시맨틱 HTML을 ARIA보다 우선할 것, 시각 변화는 최소화할 것” 같은 작업 원칙을 앞에 붙입니다. 사람이 읽어도 되고, AI 코딩 도구에 그대로 물려도 되는 형태죠. 보고서는 화면뿐 아니라 CSV·PDF·마크다운으로도 내려받을 수 있습니다.

한 번 점검으로 끝이 아닙니다. 도메인 소유를 확인하면 정기 검사를 걸어 준수율 추세를 추적하고, 결과를 담은 인증 배지(README나 푸터에 붙이는 작은 SVG)를 발급합니다. 배지는 자동 점검에 근거한 투명성 표시예요 — 공식 인증을 대체하진 않지만, “우리는 계속 점검하고 있다"를 드러내는 장치입니다.

실제로 이 블로그 푸터 맨 아래에도 알리첵 배지를 하나 달아뒀어요. 스크롤을 끝까지 내리면 현재 준수율이 작은 배지로 보입니다. 접근성을 이야기하는 블로그가 정작 자기 접근성은 숨겨둔다면 앞뒤가 안 맞으니까, 저부터 상태를 상시 공개해두자는 마음이었습니다.

말로만 설명하면 공허하니 실제 사례를 하나. 지금 읽고 계신 이 블로그도 알리첵으로 점검했습니다. 처음 준수율은 87%였고, 리포트가 짚어준 인라인 코드 대비, 목차 링크 색, 랜드마크 이름 문제를 차례로 고쳐 100%가 됐어요. 흥미로운 건, 그 과정에서 제가 놓쳤던 opacity가 대비를 깎는 함정 같은 실수도 리포트가 대신 잡아줬다는 점입니다. 도구를 만든 사람조차 자기 사이트에서 새 버그를 배우는 걸 보면, 점검이 왜 필요한지 새삼 실감합니다.

직접 써보기 — 웹과 크롬 확장

알리첵을 쓰는 길은 두 갈래이고, 둘을 같이 쓰면 좋습니다.

웹 서비스(a11ychk.com) 가 가장 간단한 입구예요. 점검할 주소를 넣으면 잠시 뒤 보고서가 나옵니다. 로그인하고 도메인 소유를 확인하면 정기 검사와 배지까지 이어져요. “우리 사이트, 지금 상태가 어떻지?“를 한눈에 보기 좋습니다.

크롬 확장 은 지금 브라우저에서 보고 있는 바로 그 페이지를 그 자리에서 점검합니다. 웹 서비스는 주소로 접근하다 보니 로그인 뒤 화면이나 로컬 개발 서버(localhost)처럼 URL만으로는 닿기 어려운 곳이 있는데, 확장은 그런 화면도 열려 있는 상태 그대로 검사할 수 있어요. 사이드 패널에서 준수율과 위반 상세를 보고, “페이지에 위반 표시"로 문제 요소를 화면에 바로 하이라이트하거나, “AI 수정요청 내보내기"로 개선 가이드를 그 자리에서 뽑을 수 있습니다. 개발하면서 바로바로 확인하기에 좋아요. 크롬 웹스토어에서 설치할 수 있습니다.

두 방식은 경쟁이 아니라 짝입니다. 배포된 사이트 전체는 웹 서비스로 주기적으로 훑고, 개발 중인 화면은 확장으로 그때그때 잡는 식이죠.

그리고 점검 자체도 두 겹으로 봅니다. 자동 검사로 바닥을 빠르게 훑은 다음, 사람이 수동으로 보강하는 것. 자동이 잡아준 목록을 지우고 나면 그다음은 사람 차례예요 — 대체텍스트가 맥락에 맞는지, 키보드로 눌러보면 순서가 자연스러운지. 이 자동 → 수동의 두 겹이 알리첵이 권하는 점검 흐름입니다.

자동 점검이 못 하는 것

여기서 솔직해야 할 부분이 있습니다. 자동 점검은 만능이 아닙니다.

자동 점검기는 맞춤법 검사기와 비슷해요. 오탈자(대비 부족, 빠진 라벨, 잘못된 ARIA)는 귀신같이 잡지만, 글이 말이 되는지는 모릅니다. 접근성에서 “말이 되는지"에 해당하는 것들 — 대체텍스트가 정말 그림의 맥락을 담고 있는지, 키보드로 화면을 훑는 순서가 자연스러운지, 에러 메시지가 사람이 이해할 표현인지 — 은 결국 사람이 봐야 압니다.

그래서 알리첵의 개선 가이드에도 이런 문장이 들어갑니다. “AI가 생성한 대체텍스트는 반드시 사람이 검토하세요.” 자동 도구는 바닥을 빠르게 끌어올려 줍니다. 하지만 천장은 사람의 판단이 채웁니다. 이 둘을 헷갈리지 않는 게 중요해요. 점검을 통과했다고 접근성이 완성된 게 아니라, 비로소 사람이 볼 준비가 됐다는 뜻이니까요.

어디서 본 구조 같지 않나요? 요즘 AI에게 코드를 맡기는 바이브 코딩(vibe coding) 도 똑같습니다. AI가 초안을 순식간에 뽑아주지만, 그게 맥락에 맞는지·엣지케이스를 놓치지 않았는지는 결국 사람이 마지막에 확인해야 하죠. 이렇게 자동화가 초안을 만들고 사람이 최종 판단을 쥐는 방식을 휴먼 인 더 루프(human-in-the-loop) 라고 부릅니다. 앞 절에서 말한 자동 → 수동의 두 겹이 바로 이거예요. 알리첵은 사람을 대체하려는 도구가 아니라, 사람이 정작 봐야 할 것에 집중하도록 지루한 바닥 점검을 대신 해주는 도구입니다.

오픈소스입니다 — 그래서 뭘 할 수 있나

알리첵은 GitHub에 공개돼 있습니다. 그런데 라이선스가 하나가 아니에요. 부분마다 다른 라이선스를 붙인 분할 라이선싱(split licensing) 이라, “그래서 내가 뭘 할 수 있나"가 부분마다 다릅니다.

검사 엔진과 규칙 카탈로그(Apache-2.0). 여러분이 접근성 도구나 CI 파이프라인을 만들고 있다면, 우리 검사 엔진과 KWCAG/WCAG 규칙 카탈로그를 그대로 가져다 넣어도 됩니다. Apache-2.0은 수정도, 상업적 이용도, 여러분 제품에 비공개로 통합하는 것까지 허용하는 관대한 라이선스예요. “사내 도구에 KWCAG 규칙만 얹고 싶다” 같은 것도 눈치 볼 필요 없이 하시면 됩니다. 알리첵이 axe-core를 그렇게 가져다 쓴 것처럼요. 크롬 확장도 마찬가지라 포크하든 고쳐 쓰든 자유입니다.

서비스 앱(AGPL-3.0). 조건이 붙는 건 여기 하나뿐인데, 대부분의 독자와는 상관이 없어요. a11ychk.com을 그냥 이용하는 분에게는 아무 제약이 없습니다 — 평소처럼 쓰시면 돼요. 조건이 걸리는 건 이 서비스 코드를 고쳐서 여러분 서버에 올려 남들에게 제공할 때입니다. 그때는 고친 소스도 함께 공개해야 해요. 웹 서비스는 코드를 나눠주는 게 아니라 화면만 보여주니 개선을 감추기 쉬운데(흔히 ‘SaaS 구멍’이라 부릅니다), AGPL이 그 구멍을 막아 개선이 다시 공개되게 합니다.

한 줄로 줄이면 — 엔진과 확장은 마음껏 가져다 쓰고, 서비스를 통째로 복제하려면 소스를 여세요. 여러분이 접근성 도구를 만들고 있다면, 알리첵의 검사 엔진은 이미 여러분 것이나 마찬가지입니다. 그렇게 쓰이라고 열어둔 거니까요.

한 장 요약

• 알리첵은 웹 주소를 받아 WCAG 2.2 AA + KWCAG 2.2 이중 기준으로 검사하는 웹접근성 점검 도구입니다.
• 엔진은 오픈소스 axe-core + 한국 현장용 자체 규칙. 위반마다 선택자·진단·수치를 담아, 바로 고칠 수 있는 형태로 돌려줍니다.
• 산출물은 준수율·위반 목록·AI 개선 가이드(대상→코드→이유), 그리고 정기 검사와 인증 배지.
• 웹 서비스 + 크롬 확장 을 병행하고, 자동 검사로 바닥을 훑은 뒤 사람이 수동 보강합니다 — 자동화가 초안, 사람이 최종 판단인 휴먼 인 더 루프.
• 자동 점검은 바닥을 올릴 뿐 천장은 못 채웁니다 — 대체텍스트·키보드 흐름·메시지는 사람이 검토해야 합니다.
• 코드는 공개돼 있고 분할 라이선싱 — 엔진·확장은 Apache-2.0이라 가져다 써도 되고, 서비스 앱만 AGPL-3.0(고쳐서 서비스로 운영할 때만 소스 공개).

마치며

모두웹 발표를 마치며 이런 문장을 남겼습니다. “접근성은 기능이 아니라 디지털 배려입니다.” 알리첵은 그 배려를 조금 더 손에 잡히게 만들려는 시도예요. 배려하고 싶어도 어디부터 손대야 할지 몰라 멈춰 있던 곳에, 다음 한 걸음을 놓아주는 것.

이 여정의 진짜 목적지는 STAGE 3, 점검 도구가 필요 없어지는 세상입니다. 처음부터 접근성이 코드에 녹아 있어서, 알리첵 같은 검사기를 돌릴 일이 줄어드는 것. 스스로의 존재 이유를 줄여가는 게 목표라니 이상하게 들릴 수 있지만, 접근성 도구가 바라야 할 성공은 원래 그런 모습이라고 생각합니다.

아직 부족한 점이 많고 자동 점검의 한계도 분명합니다. 그럼에도 코드를 열어둔 이유는 하나예요. 혼자보다 함께가 멀리 가니까요. 더 나은 규칙, 더 정확한 진단이 있다면 언제든 얹어주세요. 그렇게 모두의 웹에 한 걸음씩 다가가면 좋겠습니다.

알리첵 둘러보기 — 웹 서비스 a11ychk.com · 크롬 확장 (웹스토어) · GitHub 오픈소스