FAQ
웹 접근성 셀프체크를 시작하기 전 확인할 핵심 질문
자동 검사 결과의 의미, WCAG·KWCAG 프로필, 수동 검토 범위, 입력값 처리와 공식 근거를 질문별로 설명합니다.
이 FAQ는 도구 사용 순서와 판단 경계를 먼저 설명한 뒤, 대비·터치 대상·키보드 초점·제목 구조·폼 레이블처럼 실제 점검에서 자주 막히는 주제를 다룹니다. 자동 결과는 출발점이며 문맥과 실제 브라우저 동작은 사람이 다시 확인해야 합니다.
표준의 적용 의무나 법률 해석은 프로젝트와 관할 기관에 따라 달라질 수 있으므로, 아래 공식 문서와 함께 확인하세요.
서비스 운영 및 검사 원칙
자동 검사에서 모두 통과하면 웹 접근성을 완전히 준수한 것인가요?
아닙니다. 자동 검사는 태그 누락이나 명암비 수치 미달처럼 구문화 가능한 일부 결함만 신속히 포착합니다. 대체 텍스트의 맥락적 적절성, 키보드 Tab 논리 순서, 실제 화면낭독기 음성 전달 품질 등은 사람이 직접 수동으로 검토해야 합니다. 자동 도구는 1차 결함 탐지용이며, 완전한 적합성을 보장하지 않습니다.
다음 확인·행동: 자가진단 도구 실행 후 각 결과 하단의 '수동 확인이 필요한 범위' 체크리스트를 점검하세요.
KWCAG와 WCAG 결과가 다르면 무엇을 기준으로 삼아야 하나요?
KWCAG와 WCAG 중 어떤 기준을 적용할지는 서비스의 대상 사용자, 제공 지역, 관련 법령·고시, 계약상 요구사항, 프로젝트의 접근성 목표에 따라 달라집니다. 국내 프로젝트라면 적용 가능한 법령과 고시, 계약 조건을 먼저 확인하고 KWCAG 관련 기준을 별도로 검토하세요. 글로벌 서비스라면 WCAG 적용 범위와 버전을 프로젝트 기준으로 정한 뒤 해당 성공 기준을 확인하세요. 이 도구는 법적 의무나 인증 여부를 자동으로 결정하지 않으며, 두 표준의 결과를 하나의 합격 점수로 합치지 않습니다.
다음 확인·행동: 적용 법령·계약·관할에 따라 요구사항을 확인하고, 프로젝트 성격에 맞는 표준 프로필(WCAG 또는 KWCAG)을 선택하여 각각 독립적으로 검사하세요.
이 도구의 결과를 정부 공인 접근성 품질인증 자료로 제출할 수 있나요?
제출할 수 없습니다. 본 사이트는 개발 및 디자인 단계에서 능동적으로 결함을 사전에 식별하도록 돕는 독립 자가진단 보조 도구입니다. 법적 효력이 있는 공인 인증 마크 취득이나 공식 감리 보고서 제출을 대신할 수 없습니다.
다음 확인·행동: 공식 인증이 필요한 경우 국가 공인 웹 접근성 품질인증 심사기관을 통해 정식 심사를 신청하세요.
도구에 입력한 HTML 조각이나 색상 코드가 서버에 저장되거나 전송되나요?
현재 도구의 입력 처리 범위에서 서버·URL·Analytics로 전송하지 않습니다. 사용자가 입력한 색상 값, HTML 조각, 픽셀 좌표는 브라우저 로컬 메모리(Inert DOMParser) 안에서만 순수 TypeScript로 연산되며 외부 웹 서버나 데이터베이스에 저장되지 않습니다.
다음 확인·행동: 입력값 유출 걱정 없이 브라우저 내에서 안전하게 테스트 케이스를 점검하세요.
도구 판정이나 분석 아티클에서 기술적 오류를 발견하면 어떻게 제보하나요?
공식 문의처(liebe2460@naver.com) 또는 소개·문의 페이지를 통해 재현 입력값, 기대 결과, 관련 W3C 규격 링크를 보내주시면 운영자가 대조 검증 후 수정 내역과 반영일을 변경 기록(Changelog)에 투명하게 공개합니다. 실제 고객 정보나 민감 데이터는 반드시 제외하고 보내주세요.
다음 확인·행동: 오류 제보 시 최소 재현 코드와 공식 규격 원문 링크를 함께 첨부해 주세요.
도구별 계산 및 경계값 판단
명암비 4.48:1을 반올림하여 4.5:1로 합격 처리해도 되나요?
안 됩니다. WCAG 2.2 SC 1.4.3은 최소 4.5:1 이상(Level AA)을 규범적 조건으로 요구하므로, #777777(약 4.478:1)은 명백한 미달(Fail)입니다. 반올림(4.5:1)은 화면 가독성을 위한 표기일 뿐이며, 실제 스타일에는 최소 #767676(약 4.542:1) 이상의 안전 마진을 확보해야 실측 검사 탈락을 방지할 수 있습니다.
다음 확인·행동: 색상 대비 도구에서 계산된 내부 부동소수점 원값을 확인하고 전경색을 상향 조정하세요.
버튼 아이콘이 20×20px여도 접근성 기준을 통과할 수 있는 예외가 있나요?
통과할 수 있습니다. WCAG 2.2 SC 2.5.8에 따르면 24×24px 미만의 조작 대상이라도, 인접한 다른 조작 대상과의 중심 간 거리가 24px 이상 유지되어 간격 원(Spacing Circle) 영역이 서로 겹치지 않으면 '간격 예외(Spacing Exception)'로 적합 판정을 받습니다. 또한 인라인 문단 텍스트 링크도 예외로 인정됩니다.
다음 확인·행동: 대상 크기 도구에서 중심 좌표와 크기를 입력해 간격 예외 충족 여부를 계산하세요.
브라우저 기본 키보드 포커스 링을 유지하면 초점 가이드라인이 충족되나요?
충분하지 않습니다. 기본 아웃라인이라도 어두운 배경에서 3:1 이상의 색상 대비가 부족하거나, 상단 고정 헤더(Sticky Header) 뒤로 스크롤되어 초점이 가려지면 WCAG 2.4.11 실패입니다. :focus-visible 스타일에 명확한 대비를 부여하고, CSS scroll-padding-top 속성으로 고정 레이어에 의한 가림을 방지해야 합니다.
다음 확인·행동: 초점 표시 도구에서 헤더 높이와 scroll-padding-top 보정 코드를 대조하세요.
HTML 마크업 및 보조기술 탐색
웹페이지에서 H1 제목 태그는 반드시 문서 전체에서 하나만 써야 하나요?
H1 태그가 2개 이상이라고 해서 WCAG에서 무조건 실패로 판정하지는 않습니다. 핵심은 H1의 개수보다 H1 다음에 H3으로 건너뛰는 불연속 마크업(Skipped Level)을 피하고, 스크린리더 사용자가 헤딩 단축키(H)로 문서 전체의 개요를 논리적으로 탐색할 수 있도록 계층 순서를 일관되게 유지하는 것입니다.
다음 확인·행동: 제목 구조 도구에서 HTML 조각을 분석하여 단계 건너뜀 결함 여부를 확인하세요.
입력 폼에서 placeholder 텍스트가 label 요소를 대신할 수 있나요?
대신할 수 없습니다. placeholder는 사용자가 입력을 시작하는 순간 사라지므로 지속적인 지시문(WCAG 3.3.2) 역할을 할 수 없습니다. 고유한 id와 for 속성으로 연결된 시각적 <label>을 제공하고, placeholder는 단순 예시 힌트 용도로만 보조적으로 사용하는 것을 강력히 권장합니다.
다음 확인·행동: 폼 레이블 도구에서 input과 label의 명시적 바인딩 상태를 점검하세요.
‘더보기’나 ‘상세보기’ 같은 링크 텍스트는 항상 접근성 결함인가요?
화면상으로는 상위 카드 제목 아래에 있어 문맥으로 이해되더라도, 스크린리더 사용자가 링크 목록(Links List) 단축키로 모아볼 때는 목적지를 알 수 없는 모호한 링크(Ambiguous Link)가 됩니다. '공지사항 더보기'처럼 링크 텍스트 자체를 구체화하거나, aria-label 또는 숨김 텍스트(<span class='sr-only'>)로 목적을 보강해야 합니다.
다음 확인·행동: 링크 이름 도구에서 상위 맥락과 독립된 접근 가능한 이름 산출 결과를 비교하세요.