로그인

어떤 웹사이트에서든 가장 흔한 WCAG 실패 6가지를 해결하는 방법

12 min read
Wcag고치다대체 텍스트

상위 1,000,000개 웹사이트 중 거의 96%에서 감지 가능한 WCAG 실패가 발견되며, 해마다 동일한 6가지 유형의 문제가 그 오류의 대다수를 차지합니다. 이 가이드는 각 실패 유형을 구체적인 코드 수준의 해결책과 함께 분석하여, 오늘 바로 접근성 부채를 실질적으로 줄일 수 있도록 도와줍니다.

지금 상위 백만 개 웹사이트 중 아무 곳이나 열어 보면, 자동 스캐너가 몇 초 만에 잡아낼 수 있는 WCAG 위반이 있을 확률이 100개 중 96개입니다. 백만 개의 홈 페이지 전반에서 56,114,377개의 서로 다른 접근성 오류가 탐지되었으며, 페이지당 평균 56.1개의 오류가 발견되었습니다. 특히 눈에 띄는 점은 탐지된 오류의 96%가 단 6가지 범주에 속하며, 이 6가지 가장 흔한 오류 유형은 지난 7년 동안 변하지 않았다는 사실입니다. 이는 소수의, 이미 잘 알려진 문제들만 고쳐도 웹 전체의 접근성이 극적으로 개선될 수 있다는 뜻이며 — 그 출발점은 바로 여러분의 사이트입니다.

왜 같은 여섯 가지 실패가 계속 반복될까

정교한 개발 도구가 넘쳐나고 법적 감시도 강화되는 시대에, 어떻게 매년 대규모로 같은 오류가 반복될까 궁금할 수 있습니다. 답은 시스템적인 문제에 있습니다. 이 정도의 오류 밀도는 비접근성이 웹 개발 관행 속에 얼마나 깊이 내재되어 있는지를 보여 줍니다. 템플릿의 문제는 모든 페이지로 증식합니다. 컴포넌트의 실패는 사이트 전체에서 반복됩니다. 접근성에 대한 의도적인 주의가 없다면, 표준 개발 워크플로는 체계적으로 접근성이 떨어지는 결과를 만들어 냅니다.

자동화가 만들어 내는 잘못된 진보감도 있습니다. 자동화된 테스트는 잠재적인 WCAG 실패의 30–40%만 잡아냅니다. 자동화 테스트를 통과한 사이트도 키보드 내비게이션, 스크린 리더, 인지적 접근성 측면에서 여전히 심각한 문제를 안고 있을 수 있습니다. 즉, 서류상으로는 준수해 보이는 소수의 사이트조차 실제로는 기준에 미치지 못할 가능성이 높습니다.

법적 리스크는 실제이며 점점 커지고 있습니다. Seyfarth Shaw에 따르면, 2024년에 ADA Title III 연방법 소송이 8,800건 제기되었고, 이 중 약 2,452건이 웹 접근성을 직접적으로 겨냥했습니다. 전자상거래 사이트는 불균형적으로 높은 위험에 직면해 있으며 — 웹 접근성 소송의 77%가 온라인 리테일을 대상으로 합니다. 이제 준수는 선택 사항이 아닙니다. 비즈니스 연속성의 문제입니다.

고무적인 반대 측면도 있습니다. 이러한 집중도는 실질적인 의미를 가집니다. 조직은 소수의 문제 유형에 집중함으로써 접근성 이슈의 대부분을 해결할 수 있습니다. 포괄적인 WCAG 준수에는 78개 기준 전체에 대한 주의가 필요하지만, 가장 큰 임팩트를 주는 개선은 이러한 흔한 실패를 고치는 데서 나옵니다. 이제 각 항목을 살펴보며, 오늘 바로 적용할 수 있는 실질적인 해결책을 알아보겠습니다.

실패 #1 — 낮은 대비의 텍스트 (WCAG 1.4.3)

배경과 충분한 색상 대비를 갖지 못한 낮은 대비의 텍스트는 조사된 홈 페이지의 83.6%에서 발견되었습니다. 이는 다섯 개 중 네 개가 넘는 웹사이트에 영향을 미치는 가장 흔한 WCAG 실패입니다. WCAG 1.4.3(최소 대비)은 매우 직설적입니다. 일반 텍스트는 배경과 최소 4.5:1의 대비 비율을 달성해야 하고, 큰 텍스트(18pt 또는 14pt 볼드)는 최소 3:1을 충족해야 합니다.

대비 실패는 종종 가독성보다 미적 요소를 우선시하는 디자인 결정에서 비롯됩니다. 흰 배경 위의 연한 회색 텍스트는 시력이 완벽한 디자이너에게는 세련되어 보입니다. 그러나 저시력 사용자, 고령 사용자, 혹은 눈부심이 있는 화면에서 읽는 누구에게나 그것은 읽을 수 없는 텍스트입니다. 보조 라벨, 폼 플레이스홀더, 푸터 텍스트, 비활성 버튼 상태가 주된 문제 요소입니다 — 눈에 띄지 않게 보이도록 스타일링되지만, 그 결과 여러분의 사용자 중 상당수에게는 보이지 않게 됩니다.

해결책은 거의 항상 CSS 조정입니다. WebAIM의 대비 도구나 브라우저 DevTools의 접근성 패널 같은 대비 검사기에 색상 쌍을 넣어 보고, 통과할 때까지 전경색이나 배경색 값을 조금씩 조정하세요. 다음은 흔히 실패하는 패턴과 이를 수정하는 방법입니다:

/* 실패 — 대비 비율 약 2.3:1 */
.secondary-label {
  color: #aaaaaa;
  background-color: #ffffff;
}

/* 통과 — 대비 비율 약 7:1 */
.secondary-label {
  color: #595959;
  background-color: #ffffff;
}

플레이스홀더 텍스트의 경우, WCAG는 이를 장식용 힌트가 아닌 실제 텍스트로 취급한다는 점을 기억해야 합니다 — 따라서 4.5:1 기준을 충족해야 합니다. 안내를 전달하는 수단으로 플레이스홀더 텍스트에만 의존하지 말고, 항상 눈에 보이는 <label> 요소와 함께 사용하세요. 텍스트가 포함된 이미지를 사용하는 경우, CSS로 대비를 고칠 수 없습니다 — 이미지를 다시 만들어야 하며, 이는 텍스트를 그래픽에 구워 넣기보다 라이브 HTML 텍스트를 선호해야 하는 또 다른 이유입니다.

실패 #2 — 누락된 이미지 대체 텍스트 (WCAG 1.1.1)

대체 텍스트가 없는 이미지는 홈 페이지의 58.2%에서 발견됩니다. 이미지에 alt 텍스트가 없으면, 스크린 리더 사용자는 의미 있는 콘텐츠가 있어야 할 자리에 침묵이나 의미 없는 파일 이름만 접하게 됩니다. 이 문제는 새로운 것이 아닙니다. Alt 텍스트는 1999년 WCAG 1.0 이후로 기본적인 접근성 요구사항이었습니다. 25년이 지난 지금도 대부분의 웹사이트는 여전히 이를 일관되게 구현하지 못하고 있습니다.

이 문제가 지속되는 이유는 지식의 부족이 아니라 워크플로의 공백입니다. 이 실패율은 콘텐츠 워크플로의 체계적인 공백을 보여 줍니다. 작성자와 편집자는 alt 텍스트가 필요하다는 사실을 모르는 경우가 많습니다. 콘텐츠 관리 시스템은 항상 이를 입력하라고 요구하지 않습니다. 품질 보증 단계에서도 누락을 잡아내지 못합니다. 따라서 해결책은 기술적인 층위와 프로세스 층위, 두 가지가 있습니다.

기술적인 측면에서, 의미 있는 모든 이미지는 이미지가 전달하는 것과 같은 정보를 전달하는 alt 속성이 필요합니다. 장식용 이미지 — 정보를 추가하지 않는 순수한 시각적 장식 — 는 스크린 리더가 완전히 건너뛰도록 빈 alt=""를 지정해야 합니다. 이 구분을 올바르게 하는 것은 속성을 추가하는 것만큼 중요합니다. 상당수의 이미지가 alt 텍스트가 없거나 부정확한 alt 텍스트를 가지고 있습니다. 의미 있는 이미지에 설명이 전혀 없는 경우도 있고, 장식용 이미지가 의미 있는 콘텐츠로 취급되기도 합니다. 두 경우 모두 인지 가능한 콘텐츠에 대한 WCAG 준수를 깨뜨립니다.

<!-- 의미 있는 이미지: 이미지가 전달하는 내용을 설명 -->
<img src='team-photo.jpg' alt='The Accsible engineering team at their 2024 offsite in Lisbon' />

<!-- 장식용 이미지: 빈 alt, role 불필요 -->
<img src='wave-divider.svg' alt='' />

<!-- 링크된 이미지: 이미지가 아닌 목적지 설명 -->
<a href='/pricing'>
  <img src='pricing-icon.svg' alt='View pricing plans' />
</a>

프로세스 측면에서는, CMS 템플릿을 업데이트하여 콘텐츠 이미지에 대한 alt 필드를 필수로 만들고, 에셋을 업로드하는 모든 사람을 교육해야 합니다. Accsible 같은 자동화 도구는 사이트 전체에서 alt 텍스트가 없거나 비어 있는 이미지를 탐지해, 팀이 체계적으로 처리할 수 있는 감사 가능한 목록을 제공합니다.

실패 #3 — 누락된 폼 입력 라벨 (WCAG 1.3.1, 3.3.2)

웹사이트의 48.6%는 폼 입력 라벨이 누락되어 있습니다. 이 실패는 특히 치명적인데, 폼은 사용자가 실제로 무언가를 하는 곳이기 때문입니다 — 가입, 결제, 문의, 지원 요청 제출 등. 많은 폼이 접근 가능한 라벨이 없고, 플레이스홀더에만 의존하며, 안내와 오류 메시지를 프로그래밍적으로 노출하지 않거나, 키보드만으로 사용할 수 없습니다. 폼은 대부분의 디지털 경험에서 필수적이기 때문에, 이러한 실패는 심각한 사용성 장벽을 만듭니다.

가장 흔한 실수는 <label> 대신 플레이스홀더 텍스트를 사용하는 것입니다. 플레이스홀더는 사용자가 입력을 시작하는 순간 사라지므로, 단기 기억에 어려움이 있는 사람이나 — 혹은 단지 폼 작성 중에 방해를 받은 사람 — 은 해당 필드가 무엇을 위한 것인지 알 수 없게 됩니다. 스크린 리더는 플레이스홀더를 처리하는 방식이 제각각이며, 어떤 방식도 올바른 라벨 연결만큼 신뢰할 수 없습니다.

올바른 패턴은 for와 id 속성을 매칭시켜 입력과 연결된 <label> 요소를 사용하는 것입니다. 디자인상의 이유로 눈에 보이는 라벨을 사용할 수 없다면, aria-label이나 aria-labelledby를 사용하세요 — 하지만 <label>을 쓸 수 있는 상황에서 ARIA부터 찾지는 마세요.

<!-- 올바름: 명시적인 라벨 연결 -->
<label for='email'>Email address</label>
<input type='email' id='email' name='email' autocomplete='email' />

<!-- 잘못됨: 플레이스홀더만 사용 -->
<input type='email' placeholder='Email address' />

<!-- 라벨을 시각적으로 숨겨야 할 때 허용되는 패턴 -->
<label for='search' class='visually-hidden'>Search the site</label>
<input type='search' id='search' name='q' />

오류 메시지도 프로그래밍적으로 연결되어야 합니다. 폼 검증에서 오류를 발견하면, 메시지는 aria-describedby를 사용해 해당 필드와 연결해야 하며, 이상적으로는 포커스를 첫 번째 잘못된 필드로 이동시켜야 합니다. 폼 검증 오류는 효율적이고 직관적이며 접근 가능해야 합니다 — 오류가 명확히 식별되고, 문제 요소로 빠르게 접근할 수 있어야 하며, 사용자가 오류를 쉽게 수정하고 폼을 다시 제출할 수 있어야 합니다.

실패 #4 — 비어 있는 링크와 버튼 (WCAG 2.4.4, 4.1.2)

웹사이트의 44.6%는 비어 있는 하이퍼링크를 가지고 있습니다. 비어 있는 버튼은 거의 30%의 페이지에서 발견되었으며, 이 수치는 전년 대비 증가했습니다. 이는 시각장애인이나 저시력 사용자가 제출, 초기화, 필터, 검색 같은 버튼의 목적을 이해하지 못한다는 뜻입니다. 비어 있는 링크와 버튼은 스크린 리더 사용자에게 가장 좌절스러운 경험 중 하나입니다 — 이름이 없는 인터랙티브 요소를 만나는 것은, 어디로 이어지는지 알 수 없는 문 손잡이를 잡는 것과 같습니다.

비어 있는 링크는 아이콘이나 이미지가 <a> 태그의 유일한 자식이고, 텍스트 대체가 제공되지 않을 때 가장 흔히 발생합니다. 비어 있는 버튼은 아이콘만 있는 버튼 — 햄버거 메뉴, 닫기 아이콘, 소셜 공유 버튼 — 에 접근 가능한 이름이 없을 때 발생합니다. 둘 다 해결은 간단합니다.

<!-- 비어 있는 링크 — 실패 -->
<a href='/dashboard'><svg>...</svg></a>

<!-- aria-label로 수정 -->
<a href='/dashboard' aria-label='Go to dashboard'><svg aria-hidden='true'>...</svg></a>

<!-- 비어 있는 버튼 — 실패 -->
<button><svg>...</svg></button>

<!-- 시각적으로 숨겨진 텍스트로 수정 -->
<button>
  <svg aria-hidden='true'>...</svg>
  <span class='visually-hidden'>Close menu</span>
</button>

각 수정 예제에서 SVG에 aria-hidden='true'가 있는 점에 주목하세요. aria-label이나 시각적으로 숨겨진 텍스트로 텍스트 대체를 제공할 때는, 접근성 트리에서 SVG를 숨기고 싶어집니다 — 그렇지 않으면 스크린 리더가 라벨과 SVG 자체의 title이나 description을 모두 읽어, 혼란스러운 이중 안내가 발생할 수 있습니다. "click here", "read more", "learn more" 같은 모호한 링크 텍스트도 관련된 실패입니다. 모호한 링크 텍스트와 같은 다른 하이퍼링크 문제는 홈 페이지의 거의 14%에서 발견되었으며, 전년 대비 증가했습니다. 적절한 텍스트를 가진 하이퍼링크는 사용자가 링크가 어디로 이끄는지 알 수 있도록 하는 데 중요합니다. 각 링크의 접근 가능한 이름은 문맥 밖에서도 의미가 통하도록 해야 합니다. 스크린 리더 사용자는 페이지의 모든 링크 목록을 불러와 탐색하는 경우가 많기 때문입니다.

실패 #5 — 문서 언어 누락 (WCAG 3.1.1)

이 문제는 대비나 alt 텍스트에 비하면 사소해 보일 수 있지만, 약 16%의 페이지는 문서 언어가 설정되어 있지 않습니다 — 그리고 스크린 리더 사용자에게 미치는 영향은 즉각적이고 충격적입니다. 스크린 리더 사용자가 특정 언어 팩을 설치했다면 콘텐츠는 올바른 언어로 읽힙니다. 그렇지 않으면 어색한 발음으로 들리거나 이해할 수 없을 수 있습니다.

해결책은 단 하나의 HTML 속성 — 말 그대로 한 줄의 코드이며, 이를 누락할 변명은 없습니다. <html> 요소에 적절한 BCP 47 언어 태그를 사용해 lang 속성을 추가하세요. 페이지의 일부 구간이 전체 페이지와 다른 언어로 되어 있다면, 해당 요소에도 lang 속성을 추가해야 합니다.

<!-- 누락: lang 속성 없음 -->
<html>

<!-- 올바름: 영어 페이지 -->
<html lang='en'>

<!-- 올바름: 프랑스어 페이지 -->
<html lang='fr'>

<!-- 페이지 내 인라인 언어 전환 -->
<p>The French phrase <span lang='fr'>joie de vivre</span> means a cheerful enjoyment of life.</p>

CMS나 정적 사이트 생성기를 사용하는 경우, lang 속성은 기본 템플릿에 설정해야 합니다. 템플릿을 한 번 확인하고, 한 번 수정하면, 사이트의 모든 페이지가 즉시 수정됩니다. 이는 이 목록 전체에서 아마도 가장 높은 노력 대비 효과를 가진 수정입니다 — 템플릿 한 번 변경으로 도메인 전체에서 문제를 제거할 수 있습니다.

실패 #6 — 접근 불가능한 키보드 내비게이션과 포커스 관리 (WCAG 2.1.1, 2.4.7)

키보드 접근성은 자동화 테스트와 실제 사용성 사이의 격차가 가장 큰 영역입니다. 자동화 도구는 비시맨틱 태그로 만든 인터랙티브 요소처럼 일부 키보드 실패는 탐지할 수 있지만, 탭 순서, 포커스 트래핑, 화살표 키만으로 드롭다운 메뉴를 탐색하는 경험 등은 시뮬레이션할 수 없습니다. 사이트는 기본 포커스 표시를 제거하면서 대체 표시를 제공하지 않는 경우가 많아, 키보드 내비게이션을 거의 불가능하게 만듭니다. 이는 운동 장애가 있는 사용자뿐 아니라 키보드 내비게이션을 선호하는 사람, 파워 유저, 스위치 장치를 사용하는 사람 모두에게 영향을 미칩니다.

가장 흔한 키보드 실패는 다음과 같습니다: 포커스를 받지 못하는 <div>나 <span> 태그로 만든 커스텀 인터랙티브 컴포넌트; 브라우저의 기본 포커스 링을 outline: none이나 outline: 0으로 제거하면서, 그만큼 눈에 띄는 대체 스타일을 제공하지 않는 CSS 규칙; 포커스를 가두지 못하는 모달 다이얼로그(키보드 사용자가 오버레이 뒤로 탭 이동할 수 있음); 마우스 없이 조작할 수 없는 캐러셀이나 아코디언.

<!-- 키보드로 접근 불가능한 커스텀 버튼 — 실패 -->
<div class='btn' onclick='doSomething()'>Submit</div>

<!-- 올바름: 실제 버튼 사용 -->
<button type='button' onclick='doSomething()'>Submit</button>

<!-- 포커스 스타일 제거 — WCAG 2.4.7 위반 -->
* {
  outline: none; /* 전역으로 절대 이렇게 하지 마세요 */
}

<!-- 더 나은 방법: 미관을 유지하면서 포커스를 눈에 띄게 스타일링 -->
:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 2px;
}

:focus-visible 의사 클래스는 여기서 최고의 도구입니다. 키보드로 탐색할 때는 포커스 스타일을 보여 주고, 마우스 클릭에는 숨겨 줍니다 — 미관을 해치지 않으면서 접근성을 유지할 수 있습니다. 모달과 드로어의 경우, 다이얼로그가 열려 있는 동안 탭 내비게이션을 다이얼로그 내부로 제한하고, 닫힐 때 트리거 요소로 포커스를 되돌려 주는 포커스 트래핑 유틸리티를 사용하세요. 팝업은 적절한 포커스 관리, 라벨, 키보드 내비게이션 지원 없이 나타나는 경우가 많습니다. 이는 가입, 로그인, 결제 같은 중요한 사용자 흐름에서 심각한 방해를 초래합니다.

개별 컴포넌트를 넘어, 스킵 내비게이션 링크 추가를 고려하세요 — 포커스가 갔을 때만 보이는 시각적으로 숨겨진 링크로, 키보드 사용자가 반복되는 내비게이션을 건너뛰고 메인 콘텐츠로 바로 이동할 수 있게 합니다. 반복적인 내비게이션을 건너뛸 수 있게 해 주는 스킵 링크는 대부분의 사이트에서 누락되어 있습니다. HTML 세 줄과 작은 CSS 스니펫이면 되며, 키보드로 콘텐츠가 많은 페이지를 탐색하는 누구에게나 큰 차이를 만들어 줍니다.

<!-- <body> 안의 가장 첫 번째 요소로 배치 -->
<a href='#main-content' class='skip-link'>Skip to main content</a>

<!-- CSS -->
.skip-link {
  position: absolute;
  left: -9999px;
}
.skip-link:focus {
  left: 0;
  top: 0;
  z-index: 9999;
}

ARIA에 대한 한 가지 메모: 신중하게 사용하라

많은 팀이 접근성 격차를 빠르게 메우기 위해 ARIA(Accessible Rich Internet Applications) 속성에 의존합니다. 데이터는 이것이 도움이 되기보다 오히려 역효과를 내는 경우가 더 많다는 것을 보여 줍니다. 평가된 홈 페이지의 약 79%가 ARIA를 사용했으며, 이는 전년 대비 증가한 수치입니다. ARIA를 사용한 홈 페이지는 ARIA가 없는 페이지보다 오류가 두 배 이상 많았습니다. 문제는 ARIA 자체가 아니라, 대개는 ARIA의 오용이나 잘못된 사용입니다. 선의의 개발자들이 ARIA를 추가하면 콘텐츠가 더 접근 가능해진다고 생각하지만, 실제로는 더 나빠지는 경우가 많습니다.

지침은 단순합니다. 먼저 시맨틱 HTML을 사용하세요. <div role='button'>보다 <button>이 낫습니다. <div role='navigation'>보다 <nav>가 낫습니다. 네이티브 HTML 요소는 기본 키보드 동작, 포커스 관리, 암시적 ARIA 역할을 내장하고 있으며, 커스텀 마크업은 이를 수동으로 복제해야 합니다 — 그리고 이 수동 복제 과정에서 오류가 스며듭니다. 라이브 영역, 복잡한 복합 위젯, 동적 상태 변경처럼 HTML만으로는 의미를 표현할 수 없는 경우에만 ARIA를 사용하세요.

워크플로에 접근성을 내재화하기

기존 위반 사항을 고치는 것은 필요하지만, 새로운 문제가 생기지 않도록 막는 것이 일회성 준수 작업과 성숙한 접근성 프로그램을 가르는 기준입니다. 접근성은 한 번에 끝나는 수정이 아닙니다. 모든 콘텐츠 업데이트, 디자인 변경, 코드 배포는 새로운 문제를 유발할 수 있습니다. 이 가이드에서 다룬 여섯 가지 실패 범주는 템플릿 수준의 문제인 경우가 많습니다 — 헤더, 푸터, 공유 컴포넌트를 고치면 수백 개 페이지에서 동시에 문제를 제거할 수 있습니다.

CI/CD 파이프라인에 자동 스캐닝을 통합해, 위반 사항이 프로덕션에 도달하기 전에 잡히도록 하세요. axe-core 같은 도구는 유닛 테스트와 E2E 테스트 스위트에 내장할 수 있습니다. 여기에 정기적인 수동 키보드 점검과 스크린 리더 테스트 — macOS와 iOS의 VoiceOver, Windows의 NVDA — 를 병행하세요. 자동화 테스트는 흔한 접근성 오류를 탐지할 수 있지만, 수동 테스트는 그 빈틈을 메우는 데 도움이 됩니다. 더 빠른 온보딩이 필요한 팀의 경우, Accsible 같은 접근성 오버레이 위젯이 렌더링 레이어에서 상당수의 문제를 드러내고 완화해 주는 동안, 장기적인 코드 수준 수정 계획을 세우고 배포할 수 있습니다.

마지막으로, 코드베이스에서 가장 큰 레버리지 포인트를 다루세요: 템플릿입니다. 대부분의 웹사이트는 템플릿을 사용합니다 — 모든 페이지에 반복되는 헤더, 푸터, 내비게이션, 페이지 레이아웃입니다. 이 템플릿의 문제는 사이트 전체로 증식합니다. 최대 효과를 위해 템플릿부터 고치세요. 기본 템플릿 하나만 올바르게 수정해도, 한 번의 배포로 10,000개의 WCAG 실패를 0으로 만들 수 있습니다.

핵심 요약

  • 여섯 가지 이슈 유형이 대부분을 차지한다. 낮은 대비 텍스트, 누락된 alt 텍스트, 라벨이 없는 폼 입력, 비어 있는 링크와 버튼, 문서 언어 누락, 깨진 키보드 내비게이션이 WCAG 실패의 절대다수를 차지합니다. 이 여섯 범주를 고치면 노력 대비 압도적인 결과를 얻을 수 있습니다.
  • 대부분의 수정은 CSS나 한 줄짜리 HTML 변경이다. <html> 태그에 lang='en'을 추가하고, outline: none을 :focus-visible 스타일로 대체하며, 라벨을 입력과 연결하는 작업은 몇 달이 아니라 몇 시간의 일입니다 — 하지만 여러분의 사이트를 방문하는 모든 장애인 사용자에게 영향을 미치는 실패를 제거합니다.
  • 템플릿은 가장 레버리지가 큰 수정 지점이다. 공유 컴포넌트와 페이지 템플릿의 접근성 버그는 사이트 전체에 복제됩니다. 헤더, 푸터, 내비게이션, 폼을 먼저 점검하세요 — 거기를 고치면 어디서든 고쳐집니다.
  • ARIA는 최후의 수단이지, 첫 번째 대응이 아니다. 강력한 시맨틱 HTML 기반 없이 ARIA에 과도하게 의존하는 사이트는 접근성 오류가 줄어들기보다 크게 늘어나는 경향이 있습니다. 가능한 한 네이티브 HTML 요소를 우선 사용하세요.
  • 자동 스캐닝은 실제 문제의 절반도 잡지 못한다. 도구를 수동 키보드 점검과 스크린 리더 테스트로 보완해, 포커스 트랩, 비논리적인 탭 순서, 변경 사항을 알리지 않는 동적 콘텐츠 등 어떤 스캐너도 드러내지 못하는 실패를 찾아내세요.