알리의 접근성 연구소 웹사이트 접근성 1차 검사 결과

이 문서는 왜 쓰는가

알리의 접근성 연구소 웹사이트는 접근성을 다루는 공간이다. 그런데 현재는 a11ylab.kr 웹 사이트 문제점 및 개선점에서도 언급한 것처럼 사용성도 불편하고 접근성도 낮은 것이 사실이다. 따라서 사이트 자체가 가진 접근성 문제를 올바른 기준으로 계속 점검하고 고쳐 가야 한다. 이 문서는 그 첫 번째 기록이다.

이번 점검은 axe라는 자동 접근성 검사 도구로 진행했다.¹ 자동 검사는 사람이 직접 사이트를 써 보며 느끼는 불편을 모두 잡아내지는 못한다. 그 대신 색 대비, 잘못된 ARIA 속성, 프레임 이름, 제목 구조, 페이지 영역 구조와 같은 기계가 비교적 안정적으로 확인할 수 있는 항목을 빠르게 찾아 준다.

따라서 이 결과는 “이 사이트의 접근성이 좋다/나쁘다”를 최종 판정한 문서가 아니다. 지금 상태에서 먼저 손볼 지점을 찾기 위한 기준선을 기록한 것이다. 이후 수정 작업을 한 뒤 같은 방식으로 다시 검사하면 무엇이 줄었고 무엇이 남았는지 비교할 수 있다.

근거 자료는 a11ylab.kr axe 기반 접근성 baseline 리포트다.

어떻게 검사했는가

2026년 6월 4일 기준으로 https://a11ylab.kr/ 사이트에 직접 접속해 검사했다. 홈 화면만 본 것이 아니라, 사이트 소개, 주요 접근성 문서, 보조공학 문서, 접근성 브리핑 목록과 글, 블로그 목록과 글, 알려진 문제점 페이지까지 대표 URL 10개를 골라 확인했다.

검사에는 Playwright Chromium 브라우저와 axe-core를 사용했다. 화면 크기는 데스크톱 기준인 1366×900 CSS px로 두었다. WCAG 2.0, 2.1, 2.2의 A/AA 관련 항목과 일부 best-practice 항목을 함께 보았다.²

즉, “실제 브라우저로 사이트를 열고, 자동 접근성 검사 도구가 문제라고 판단한 부분을 모아 본 검사”라고 요약할 수 있겠다.

한눈에 본 결과

검사한 10개 페이지 모두에서 접근성 위반 항목이 발견되었다. 페이지마다 발견된 규칙 위반은 6~~7개였고, 위반 노드 수는 31~~46개 범위였다. 전체 위반 노드 수는 367개로 집계되었다.³

다만 이 숫자를 “서로 다른 문제가 367개 있다”로 해석하기보다 같은 레이아웃 문제가 여러 페이지에서 반복해서 잡힌다고 보는 것이 타당하다. 예를 들어 모든 페이지에 공통으로 들어가는 목차, 사이드바, 댓글 영역, 검색 버튼에서 문제가 있으면, 그 하나의 구조적 문제가 페이지마다 반복 집계된다.

영향도 기준으로 보면 다음과 같다.

영향도	노드 수	읽는 방법
critical	8개	보조공학기술 사용에 직접적인 오류를 만들 가능성이 큰 문제
serious	88개	실제 사용 불편이나 정보 접근 문제로 이어질 수 있는 문제
moderate	271개	구조를 더 명확히 다듬어야 하는 문제

가장 많이 반복된 항목은 region 문제였다. 쉽게 말하면, 페이지 안의 여러 영역이 화면 읽기 프로그램이나 보조공학기술이 이해하기 좋은 구조로 충분히 나뉘어 있지 않다는 뜻이다.

먼저 손봐야 할 문제

1. 목차 버튼이 실제 제어 대상을 제대로 가리키지 않는 문제

가장 먼저 봐야 할 문제는 ‘데스크톱 화면 기준’ 오른쪽 목차의 접기/펼치기 버튼이다. 검사 결과, 이 버튼의 aria-controls 값이 실제 페이지 안에 존재하는 대상과 맞지 않는 것으로 나왔다.⁴

눈으로 보는 사용자는 버튼을 눌러 목차가 접히거나 펼쳐지는 장면을 확인할 수 있지만 화면 읽기 프로그램 사용자는 버튼이 “무엇을 제어하는지”, 지금 펼쳐진 상태인지 접힌 상태인지, 그 정보가 실제 화면 구조와 맞는지에 의존한다. 버튼이 존재하지 않는 대상을 가리키면 보조공학기술은 잘못된 관계 정보를 받게 된다.

이 항목은 axe에서 critical로 잡혔다. 우선순위를 가장 높게 두고 수정해야 한다.

2. 페이지의 주요 영역이 명확한 landmark로 잡히지 않는 문제

두 번째는 페이지 구조다. 웹페이지에는 보통 본문, 탐색, 보조 정보, 바닥글(footer) 같은 주요 영역이 있다. 화면 읽기 프로그램 사용자는 이런 영역을 landmark로 빠르게 이동할 수 있다.⁵

현재 사이트는 중앙 본문이 시각적으로는 분명히 보이지만, 검사 결과상 <main> landmark가 없고 좌우 사이드바나 일부 콘텐츠도 landmark 밖에 남는 것으로 나타났다. 사이트를 짧게 볼 때는 큰 문제가 아닌 것처럼 생각할 수 있지만 문서가 많아지고 페이지 구조가 복잡해질수록 사용자는 매번 처음부터 다시 페이지를 훑어야 한다.

접근성은 “읽을 수 있다”에서 끝나면 안 된다. 필요한 곳으로 바로 이동할 수 있어야 하고, 지금 내가 페이지의 어느 영역에 있는지도 제대로 알 수 있어야 한다.

3. 댓글 영역 iframe에 이름이 없는 문제

댓글 영역은 Cusdis iframe으로 들어간다. 검사 결과 이 iframe에 접근성 이름이 없었다.⁶ 쉽게 말해, 보조공학기술 사용자가 이 프레임을 만났을 때 “이것이 댓글 영역이다”라고 바로 알아차리기 어렵다는 뜻이다.

또 iframe 안의 입력 필드도 title만으로 이름을 제공하는 문제가 드러났다. 닉네임, 이메일, 댓글 입력칸이 시각적으로는 보이더라도, 보조공학기술이 읽어 주는 이름과 실제 화면 라벨이 충분히 안정적으로 연결되어 있는지는 따로 확인해야 한다.

다만 이 문제는 완전히 손댈 수 없는 외부 서비스 문제가 아니다. 현재 댓글 기능은 포크한⁷ Cusdis를 별도로 운영하고 있으므로, iframe 이름이나 내부 폼 라벨 문제도 후속 작업에서 수정할 수 있다.

이번 1차 개선에서는 우선 웹사이트 자체를 구동하는 Quartz⁸ 레이어에 집중한다. aria-controls, <main> landmark, 영역 구조, 색 대비, 제목 단계처럼 사이트 공통 레이아웃에서 반복되는 문제를 먼저 줄이고, 댓글 기능은 그다음 단계의 별도 개선 과제로 분리한다.

4. 검색 버튼과 목차 링크의 색 대비 문제

저시력 사용자에게 가장 직접적으로 닿는 문제는 색 대비다. 이번 검사에서는 검색 버튼의 검색 텍스트가 배경과 충분히 구분되지 않는 것으로 나타났다. 대표 예시에서는 전경색 #b8b8b8, 배경색 #faf8f8 조합의 대비가 1.87:1로 측정되었다. 일반 텍스트 기준으로 기대되는 4.5:1에 미치지 못한다.⁹

검색 버튼, 현재 위치를 알려 주는 breadcrumb¹⁰, 목차 링크처럼 기능을 가진 텍스트는 장식이 아니다. 흐린 회색으로 작게 보이면 저시력 사용자는 이 요소가 있는지, 누를 수 있는지, 지금 어디에 있는지 확인하는 데 더 많은 힘을 써야 한다.

겉으로는 색을 조금 진하게 바꾸는 일처럼 보여도, 실제로는 탐색 비용을 줄이는 작업이다.

5. 제목 단계가 건너뛰는 문제

일부 페이지에서는 heading order 문제가 검출되었다.¹¹ 예를 들어 앞에 h2가 없는 상태에서 h3가 등장하면, 제목만 따라 이동하는 사용자는 페이지 구조를 오해할 수 있다.

제목은 글자의 크기를 정하는 장치가 아니라 문서의 뼈대를 구성한다. 화면 읽기 프로그램 사용자는 제목 목록을 열어 페이지 전체 구조를 빠르게 파악하기도 한다. 그래서 시각적 크기는 CSS¹²로 조정하더라도, heading level은 문서 구조에 맞게 정리해야 한다.

이번 검사에서 단언할 수 없는 것

이번 검사는 자동 도구 기반 검사다. 그래서 다음 항목은 별도의 사용성 평가가 필요하다.

키보드만으로 검색, 탐색, 그래프, 댓글 영역을 실제로 사용할 수 있는가?
VoiceOver 같은 화면 읽기 프로그램에서 landmark, 제목, 링크 이동이 자연스러운가?
200% 또는 400% 확대에서 레이아웃이 무너지지 않는가?
모바일 화면에서 같은 문제가 어떻게 나타나는가?
다크 모드, 고대비 환경, 텍스트 간격 조정에서 읽기 피로도가 어느 정도인가?
한국어 문맥에서 링크 이름과 문서 제목이 충분히 의미 있게 제시되는가?

그러므로 이번 문서는 “자동 검사에서 드러난 1차 문제 목록”이다. 실제 사용성 평가는 수동 검토와 보조공학기술 테스트를 이어서 해야 한다.

개선 우선순위

현재 기준으로는 다음 순서가 적절하다.

TOC 버튼의 aria-controls 오류를 고친다.
중앙 본문에 <main> landmark를 두고, 좌우 탐색과 보조 영역의 구조를 정리한다.
검색 버튼, 목차 링크, breadcrumb 등 기능 텍스트의 색 대비를 높인다.
그래프 뷰와 일부 문서의 제목 단계를 정리한다.
같은 10개 URL로 axe 재검사를 실행해 baseline과 비교한다.
이후 키보드, VoiceOver, 확대, 모바일, 다크 모드 검사를 별도로 진행한다.
댓글 iframe과 입력 필드 라벨 문제는 포크한 Cusdis 쪽 후속 개선 과제로 분리해 처리한다.

마무리

어쩌면 이번 결과는 접근성 측면에서 알리의 접근성 연구소 웹사이트의 민낯을 드러내는 것일지 모른다. 하지만 접근성 개선에서 중요한 것은 발생한 문제를 숨기는 게 아니라, 문제를 확인 가능한 형태로 남기고 다시 검사할 수 있게 만드는 일이다.

이 웹사이트는 접근성을 연구하고 설명하는 곳이기도 하지만, 동시에 접근성을 실험하고 고쳐 가는 현장이기도 하다. 이번 1차 검사는 그 출발점이다. 그래서 자동 검사에서 드러난 구조적 문제를 먼저 줄이고, 그다음 실제 사용자 경험을 확인하는 방식으로 이어 가야 한다.

접근성은 한 번 통과하고 끝나는 체크리스트가 아니다. 사이트가 바뀌면 다시 흔들리고, 기능이 늘어나면 또 새로운 문제가 생긴다. 그래서 이번 문서의 의미는 “현재 상태의 부족함”을 적는 데서 그치지 않는다. 앞으로 무엇을 고쳤는지, 무엇이 남았는지, 어떤 검사를 더해야 하는지 비교할 수 있는 첫 기준을 세웠다는 데 그 의미가 있다.

자기 자신의 접근성을 고쳐 나가는 과정, 알리의 접근성 연구소의 또 하나의 큰 여정에 여러분의 응원이 함께 하기를 바란다.

axe-core는 웹 콘텐츠의 접근성 문제를 자동으로 점검하는 JavaScript 기반 검사 엔진이다. Deque의 API 문서는 axe가 브라우저에서 실행되고, 렌더링된 콘텐츠를 분석하며, 위반 항목·통과 항목·추가 검토가 필요한 항목을 JSON 형태로 반환한다고 설명한다. 다만 숨겨진 메뉴나 아직 열린 적 없는 모달처럼 렌더링되지 않은 영역은 별도로 활성화한 뒤 다시 검사해야 한다. | Deque Systems. (n.d.). Axe API documentation. https://www.deque.com/axe/core-documentation/api-documentation/ ↩
이번 검사에서 사용한 wcag2a, wcag2aa, wcag21a, wcag21aa, wcag22aa, best-practice 태그는 axe-core rule이 어떤 기준이나 권장 관행과 관련되는지를 분류하는 표지다. Deque API 문서는 wcag2a를 WCAG 2.0 Level A, wcag2aa를 WCAG 2.0 Level AA, wcag21a를 WCAG 2.1 Level A, wcag21aa를 WCAG 2.1 Level AA, wcag22aa를 WCAG 2.2 Level AA, best-practice를 일반 접근성 권장 관행 태그로 설명한다. | Deque Systems. (n.d.). Axe API documentation. https://www.deque.com/axe/core-documentation/api-documentation/ ↩
대표 URL 10개, 페이지별 규칙 위반 6~7개, 전체 위반 노드 367개, 영향도별 critical 8개·serious 88개·moderate 271개라는 수치는 별도 baseline 리포트의 집계표와 핵심 결과 요약을 옮긴 것이다. 같은 Quartz 공통 레이아웃 문제가 여러 페이지에서 반복 집계되므로, 이 숫자는 서로 다른 결함의 개수라기보다 현재 배포본에서 반복 노출되는 접근성 문제의 규모로 읽어야 한다. | 알리의 접근성 연구소. (2026, 6월 4일). a11ylab.kr axe 기반 접근성 baseline 리포트. 내부 점검 문서. ↩
axe의 aria-valid-attr-value 규칙은 aria-로 시작하는 속성이 올바른 값 유형과 허용된 값을 가져야 한다고 본다. aria-controls처럼 다른 요소의 ID를 참조하는 속성은 실제 문서 안에 존재하는 대상을 정확히 가리켜야 보조공학이 제어 관계를 신뢰할 수 있다. 이번 검사에서 해당 항목은 사용자 영향도 critical로 분류되었다. | Deque University. (n.d.). ARIA attributes must conform to valid values. https://dequeuniversity.com/rules/axe/4.11/aria-valid-attr-value?application=playwright ↩
landmark는 페이지의 큰 영역을 보조공학기술이 이해할 수 있게 표시하는 구조다. Deque의 region 규칙은 본문, 탐색, 바닥글 같은 주요 콘텐츠가 HTML5 landmark 요소나 ARIA landmark 안에 들어가야 한다고 설명한다. 화면 읽기 프로그램 사용자는 landmark를 통해 페이지의 주요 구역으로 빠르게 이동할 수 있으므로, 콘텐츠가 landmark 밖에 흩어져 있으면 탐색 비용이 커진다. | Deque University. (n.d.). All page content should be contained by landmarks. https://dequeuniversity.com/rules/axe/4.11/region?application=playwright ↩
iframe은 다른 문서나 위젯을 현재 페이지 안에 끼워 넣는 구조다. Deque의 frame-title 규칙은 모든 frame과 iframe 요소가 비어 있지 않은 고유한 title을 가져야 한다고 설명한다. 화면 읽기 프로그램 사용자는 프레임 제목 목록을 통해 필요한 프레임을 찾기도 하므로, 댓글 iframe처럼 실제 기능을 가진 영역에는 “댓글”처럼 짧고 분명한 이름이 필요하다. | Deque University. (n.d.). Frames must have an accessible name. https://dequeuniversity.com/rules/axe/4.11/frame-title?application=playwright ↩
포크(fork)는 원본 저장소의 코드를 바탕으로 새 저장소를 만드는 방식이다. GitHub 문서는 포크를 원본 upstream 저장소와 코드를 공유하는 새 저장소로 설명하며, 버그 수정·새 기능 실험·자체 프로젝트 운영의 출발점으로 쓸 수 있다고 안내한다. 이 문서에서는 Cusdis를 원본 그대로 외부 서비스로만 쓰는 것이 아니라, 직접 수정 가능한 별도 코드 기반으로 운영하고 있다는 뜻으로 사용했다. | GitHub Docs. (n.d.). Fork a repository. https://docs.github.com/en/get-started/quickstart/fork-a-repo ↩
Quartz는 Markdown 콘텐츠를 웹사이트로 변환하는 정적 사이트 생성기다. 공식 문서는 Quartz를 Markdown 콘텐츠를 완전한 웹사이트로 바꾸는 static-site generator로 설명하고, Obsidian 호환성, 전체 텍스트 검색, 그래프 뷰, 위키링크, 댓글 기능, Cloudflare·GitHub Pages·Vercel 배포 등을 지원한다고 안내한다. 이 사이트에서는 Obsidian에 쓴 문서를 Quartz로 빌드해 공개하는 구조를 사용한다. | Quartz. (2026, May 24). Welcome to Quartz 5. https://quartz.jzhao.xyz/ ↩
axe의 color-contrast 규칙은 일반 텍스트는 최소 4.5:1, 큰 텍스트는 최소 3:1의 전경색과 배경색 대비를 요구하는 WCAG 2 AA 기준을 따른다. 이번 검사에서 검색 버튼 텍스트의 1.87:1 대비는 이 기준에 미치지 못한다. 색 대비 문제는 저시력 사용자와 색각 이상 사용자에게 특히 직접적인 읽기 부담을 만든다. | Deque University. (n.d.). Elements must meet minimum color contrast ratio thresholds. https://dequeuniversity.com/rules/axe/4.11/color-contrast?application=playwright ↩
breadcrumb는 말 그대로 ‘빵부스러기’라는 뜻이고, 『헨젤과 그레텔』에서 길을 되찾기 위해 남긴 빵부스러기에서 온 표현이다. 웹에서는 현재 페이지가 사이트 구조 안에서 어디에 있는지를 보여 주는 이동 경로 표시를 가리킨다. W3C WAI는 메뉴와 탐색 구조가 보조공학기술에 전달될 수 있도록 구조화되어야 하며, 현재 항목을 표시하면 사용자의 탐색에 도움이 된다고 설명한다. breadcrumb 역시 현재 위치를 알려 주는 탐색 정보이므로, 시각적으로 흐리거나 의미가 불분명하면 탐색 단서로서의 역할이 약해진다. | W3C Web Accessibility Initiative. (n.d.). Menu structure. https://www.w3.org/WAI/tutorials/menus/structure/ ↩
axe의 heading-order 규칙은 제목 수준이 문서 구조에 맞게 한 단계씩 증가해야 한다고 본다. 예를 들어 h1 다음 하위 섹션은 보통 h2가 되어야 하며, 시각적으로 크게 보이게 하려는 이유만으로 제목 태그를 건너뛰어 쓰면 보조공학기술 사용자가 페이지 구조를 오해할 수 있다. | Deque University. (n.d.). Heading levels should only increase by one. https://dequeuniversity.com/rules/axe/4.11/heading-order?application=playwright ↩
CSS(Cascading Style Sheets)는 HTML이나 XML 문서가 화면, 종이, 음성 등 여러 매체에서 어떻게 표현될지를 정하는 스타일 언어다. 제목의 글자 크기나 굵기 같은 시각적 표현은 CSS로 조정할 수 있지만, h1·h2·h3 같은 heading level은 문서 구조를 나타내는 HTML 의미이므로 스타일 조정과 분리해서 판단해야 한다. | MDN Web Docs. (n.d.). CSS: Cascading Style Sheets. https://developer.mozilla.org/en-US/docs/Web/CSS ↩