100만 개의 홈페이지를 자동 검사기에 넣고 돌리면 무슨 일이 벌어질까요?
약 5,600만 개의 접근성 오류가 쏟아져 나옵니다. 페이지당 평균 56.1개입니다.
숫자만 보면 “원래 웹이 그렇지” 하고 넘길 수도 있습니다. 문제는 방향입니다. 작년에는 51개였거든요. 1년 사이 10.1% 늘었습니다. 몇 년간 느리게나마 나아지던 웹 접근성이, 올해는 뒷걸음질을 쳤습니다.
무엇이 늘었고, 왜 늘었을까요? 2026년 2월 데이터를 담아 3월에 공개된 WebAIM Million 리포트를 함께 뜯어보겠습니다.
WebAIM Million이 뭐길래#
먼저 이 조사가 무엇인지부터 짚고 가겠습니다.
WebAIM(Web Accessibility In Mind)은 미국 유타주립대학교에 기반을 둔 웹 접근성 전문 기관입니다. 접근성 검사 도구 WAVE를 만든 곳으로도 유명하죠. 이 WebAIM이 2019년부터 매년 전 세계 상위 100만 개 웹사이트의 홈(첫) 페이지를 WAVE 엔진으로 자동 분석해 발표하는 것이 WebAIM Million 리포트입니다.
읽기 전에 알아둘 전제가 두 가지 있습니다.
- 자동 검사만으로 측정합니다. 기계가 확실하게 판별할 수 있는 오류(alt 누락, 명도 대비 부족, 레이블 없는 입력 필드 등)만 셉니다. 키보드 트랩이나 엉뚱한 포커스 순서처럼 사람이 직접 써봐야 아는 문제는 포함되지 않습니다.
- 그래서 이 수치는 실제보다 좋게 나온 수치입니다. 자동 검사를 통과했다고 접근 가능한 것은 아니니까요. 일종의 ‘최소 추정치’라고 보시면 됩니다.
최소 추정치가 페이지당 56개라는 점을 기억하면서, 올해 성적표를 보겠습니다.
올해 성적표: 방향이 꺾였습니다#
핵심 수치부터 정리하면 이렇습니다.
- 홈페이지의 95.9% 에서 WCAG 2 위반이 검출됨 (작년 94.8%)
- 페이지당 평균 오류 56.1개 (작년 51개, +10.1%)
- 페이지당 평균 요소 수 1,437개 (1년 새 +22.5%)
추이를 보면 2021년 이후 평균 오류는 대체로 50개 안팎까지 내려와 있었습니다. 2024년에 한 번 튀었다가 2025년에 다시 51개로 돌아왔는데, 올해 56.1개로 재차 올라섰습니다.
한 가지 눈여겨볼 부분은 오류 밀도입니다. 전체 페이지 요소 대비 오류 비율은 3.9%로, 요소 하나하나가 특별히 더 나빠졌다기보다는 페이지 자체가 훨씬 무거워지면서 오류의 절대량이 늘어난 그림입니다. 홈페이지 하나에 담긴 요소가 7년 전(2019년 782개)의 두 배 가까이 됐거든요.
접근성만의 문제가 아니라, 웹이 복잡해지는 속도를 품질 관리가 못 따라가고 있다는 신호로 읽을 수 있습니다.
범인은 매년 같은 여섯입니다#
이 리포트의 웃픈 전통이 하나 있습니다. 매년 상위권 오류 목록이 거의 바뀌지 않는다는 겁니다. 올해도 전체 오류의 96%가 이 여섯 유형에서 나왔습니다.
| 오류 유형 | 발생 페이지 비율 |
|---|---|
| 저대비 텍스트 | 83.9% |
| 이미지 대체 텍스트 누락 | 53.1% |
| 폼 입력 레이블 누락 | 51.0% |
| 빈 링크 | 46.3% |
| 빈 버튼 | 30.6% |
| 문서 언어(lang) 누락 | 13.5% |
주목할 점: 이 여섯은 하나같이 웹 개발 첫 학기 수준의 기초라는 겁니다. 첨단 기술이 부족해서 생기는 오류가 아닙니다.
- 저대비 텍스트 → 디자인 단계에서 대비 검사 도구 한 번이면 잡힙니다.
- alt 누락 →
<img alt="...">한 줄입니다. 100만 페이지에 이미지가 6,660만 개 있었는데, 그중 16.2%에 alt가 없었습니다. 심지어 alt 없는 이미지의 45%는 링크로 쓰인 이미지였습니다. 스크린 리더 사용자는 그 링크가 어디로 가는지 알 방법이 없습니다. - 폼 레이블 누락 →
<label for="...">연결이면 됩니다. 페이지당 입력 필드는 평균 6.9개로 3년 새 36% 늘었는데, 그중 33.1%가 레이블 없이 놓여 있습니다. - 빈 링크·빈 버튼 → 아이콘만 넣고 이름을 안 준 경우가 대부분입니다.
- lang 누락 →
<html lang="ko">. 진심으로, 한 단어입니다.
가장 쉬운 것들이 가장 많이 틀리는 시험. 어쩐지 수능 1번 문제를 틀렸을 때의 기분이 떠오르죠. 실력이 없어서가 아니라 쳐다보지 않아서 틀리는 문제들입니다.
ARIA의 역설: 많이 쓸수록 나빠진다?#
올해 리포트에서 가장 이야기할 거리가 많은 대목입니다.
ARIA(Accessible Rich Internet Applications)는 HTML만으로 표현하기 어려운 역할·상태 정보를 보조기술에 전달하는 속성 모음입니다. 잘 쓰면 복잡한 위젯도 접근 가능하게 만들 수 있는, 분명히 좋은 도구입니다.
그런데 통계는 묘한 그림을 보여줍니다.
- 홈페이지의 82.7% 가 ARIA를 사용, 페이지당 평균 133개 속성 (1년 새 +27%)
- ARIA를 쓴 페이지의 평균 오류: 59.1개
- ARIA를 안 쓴 페이지의 평균 오류: 42개
ARIA를 쓴 페이지가 오류가 더 많습니다. 물론 이건 상관관계입니다. 복잡한 페이지일수록 ARIA도 많이 쓰고 오류도 많을 수밖에 없죠. 하지만 W3C 문서에 공식적으로 박혀 있는 경고가 괜히 있는 게 아닙니다.
No ARIA is better than Bad ARIA. (잘못 쓴 ARIA보다는 안 쓴 ARIA가 낫다)
ARIA는 후추 같은 존재입니다. 적재적소에 쓰면 요리가 살지만, 접근성이 걱정된다고 통째로 들이붓는다고 요리가 되는 건 아니거든요. role="button"을 붙이는 순간 키보드 이벤트 처리까지 책임져야 하고, aria-hidden="true"를 잘못 붙이면 멀쩡한 콘텐츠가 스크린 리더에서 통째로 사라집니다. 참고로 이 aria-hidden="true", 페이지당 평균 23.3개로 1년 새 30% 늘었습니다.
기본 원칙은 변하지 않았습니다. 시맨틱 HTML로 표현할 수 있으면 HTML로. ARIA는 그다음입니다.
왜 하필 지금 후퇴했을까#
리포트가 짚는 배경은 크게 두 갈래입니다.
첫째, 페이지가 폭발적으로 복잡해지고 있습니다. 요소 수 +22.5%, ARIA +27%, 제목(heading) +20.4%. 모두 1년 사이의 증가율입니다. 서드파티 프레임워크와 컴포넌트, 위젯이 겹겹이 쌓이면서, 개발자가 직접 통제하지 않는 마크업의 비중이 커졌습니다.
둘째, 코드를 만들어내는 속도가 검토하는 속도를 앞질렀습니다. AI 지원 코딩이 보편화되면서 마크업 생산량 자체가 급증했는데, 접근성 검토가 그 속도를 따라가지 못하고 있다는 분석이 나옵니다. AI가 생성한 마크업의 접근성 문제는 전부터 꾸준히 지적돼 왔는데, 그 우려가 이제 통계로 나타나기 시작한 셈입니다.
WebAIM의 크리스토퍼 필립스(Christopher Phillips)는 이번 결과를 두고 기술 문제가 아니라 문화의 문제라고 진단했습니다. 장애인 사용자가 겪는 장벽이 조직 입장에서 너무 쉽게 간과되는 구조가 문제라는 거죠. 그가 인용한 문장이 오래 남습니다.
“모든 시스템은 지금 얻고 있는 결과를 얻도록 완벽하게 설계되어 있다.”
접근성이 후퇴한 시스템은, 접근성이 후퇴하도록 설계된 시스템이라는 뜻입니다. 뜨끔하지 않으신가요.
국내 상황과 겹쳐 보면#
“그래도 우리는 좀 낫지 않을까?” 하는 기대를 가질 수 있는데요. 아쉽지만 국내 조사 결과도 만만치 않습니다.
2026년 3월에 공개된 국내 「2025 웹사이트 정보접근성 실태조사」에서는 대체 텍스트 준수율이 17.1% 에 그쳤습니다. 측정 방식이 달라 직접 비교는 어렵지만(국내 조사는 항목별 준수율, WebAIM은 오류 검출률), “가장 기초적인 항목이 가장 많이 무너져 있다"는 결론만큼은 국내외가 정확히 일치합니다. 국내 조사 분석은 이 포스트에서 자세히 다뤘습니다.
전 세계가 같은 문제를 겪고 있다는 게 위로가 되지는 않습니다. 오히려 이렇게 읽어야 할 겁니다. 지금 기초를 지키는 것만으로도 상위권이 될 수 있다고요.
우리가 내일 할 수 있는 것#
이번 리포트의 역설적인 희망은, 오류의 96%가 자동 도구로 검출 가능한 기초 오류라는 점입니다. 검출이 된다는 건 예방도 된다는 뜻이니까요.
① CI에 자동 검사 붙이기 axe-core, Lighthouse CI, pa11y 같은 도구를 빌드 파이프라인에 넣으면 6대 오류의 대부분을 배포 전에 잡을 수 있습니다. 사람의 선의에 기대지 말고 시스템이 잡게 하세요.
② 디자인 단계에서 대비 검증 83.9%가 걸린 저대비 텍스트는 코드 문제가 아니라 디자인 토큰 문제입니다. 색상 팔레트를 정할 때 대비 비율(일반 텍스트 4.5:1)을 함께 확정해두면 이후 페이지 전체에 자동 적용됩니다.
③ AI가 만든 마크업은 접근성 리뷰를 기본으로
AI가 생성한 컴포넌트를 그대로 머지하지 않기. <div onclick> 버튼, 장식 이미지에 붙은 이상한 alt, 남발된 ARIA는 AI 생성 코드의 단골손님입니다.
④ 새 코드보다 기존 오류부터 페이지당 56개 오류의 대부분은 오늘 새로 생긴 게 아니라 방치된 것들입니다. 한 번의 스프린트로 6대 오류만 정리해도 사용자 체감은 크게 달라집니다.
마무리#
7년째 반복되는 결론을 올해도 쓰게 됩니다. 웹 접근성의 최대 장벽은 어려운 기술이 아니라 하지 않은 기초입니다.
다만 올해는 경고등이 하나 더 켜졌습니다. 웹이 복잡해지고 코드 생산 속도가 빨라질수록, “나중에 챙기지"의 이자율도 함께 오르고 있다는 것. 5,600만 개의 오류는 그 이자 고지서인지도 모르겠습니다.
내일 출근해서 여러분이 맡은 페이지를 WAVE나 axe로 한 번 돌려보시는 건 어떨까요. 평균(56.1개)보다 낮게 나온다면, 여러분은 이미 세계 평균을 이기고 있는 겁니다. 거기서 0을 향해 한 걸음씩 가면 됩니다.
참고 자료#
- The WebAIM Million — The 2026 report on the accessibility of the top 1,000,000 home pages (WebAIM)
- Tolerating Inaccessibility (WebAIM Blog, Christopher Phillips)
- The WebAIM Million Report 2026: what it tells us (Nexer Digital)
- Read Me First — No ARIA is better than Bad ARIA (W3C ARIA Authoring Practices Guide)