HTML을 붙여넣어 헤딩 구조, 랜드마크, 이미지 대체 텍스트, 폼 레이블과 예상 탭 순서를 확인하세요. 코드만으로 판단하기 어려운 항목은 수동 검사로 분리해 과도한 합격 판정을 피합니다. 검사는 붙여넣은 마크업을 렌더링하지 않는 파서로 이루어지며, 결과는 규칙 ID·소스 위치·수정 방향과 함께 Markdown 보고서로 복사할 수 있습니다.
HTML만 지원합니다. JSX·Vue·Svelte 템플릿은 1차 출시 범위에 포함되지 않습니다. 입력한 코드는 서버로 전송되지 않고 브라우저에서 분석됩니다.
조각 안의 헤딩·이미지·폼·이름·ARIA 참조·포커스를 검사합니다. lang·title·main 처럼 페이지 전체에 필요한 규칙은 실행하지 않습니다.
HTML 접근성 검사기는 화면이 완성되기 전에도 마크업에서 반복적으로 발생하는 문제를 찾는 도구입니다. 헤딩 단계가 갑자기 건너뛰는지, 이미지에 alt가 있는지, 폼 필드와 label이 연결됐는지, 버튼과 링크에 읽을 수 있는 이름이 있는지, ARIA 속성이 실제 요소를 참조하는지 확인할 수 있습니다. 코드 리뷰 전에 실행하면 수정 위치를 좁히고, QA에서는 수동으로 확인할 항목을 놓치지 않는 데 도움이 됩니다.
다만 HTML만으로 웹접근성을 전부 판정할 수는 없습니다. 키보드로 실제 기능을 실행할 수 있는지, 포커스 표시가 보이는지, CSS가 적용된 시각적 순서와 DOM 순서가 일치하는지, 동적 상태가 스크린리더에 전달되는지는 실행 화면에서 확인해야 합니다. 따라서 이 도구는 페이지에 점수를 주지 않고 오류 가능성 높음, 검토 필요, 수동 검사를 나눠 보여줍니다.
버튼, 카드, 폼 일부처럼 페이지 안에 들어갈 코드만 검사할 때는 컴포넌트 조각을 선택하세요. 이 범위에서는 해당 조각 안의 헤딩, 이미지, 폼, 이름, ARIA 참조와 포커스 요소를 확인합니다. 조각에는 원래 html의 lang이나 title, main이 없으므로 이런 항목을 오류로 표시하지 않습니다.
페이지 전체 HTML을 붙여넣었다면 전체 문서를 선택하세요. 이 범위에서는 페이지 언어, 제목, 주요 랜드마크와 반복 영역 우회 방법까지 함께 검토합니다. 도구가 전체 문서처럼 보이는 입력을 발견하면 전환을 제안하지만, 검사 범위를 자동으로 바꾸지는 않습니다. 사용자가 어떤 문맥을 검사하는지 아는 것이 오탐을 줄이는 가장 확실한 방법이기 때문입니다.
헤딩은 글자를 크게 보이게 하는 장식이 아니라 문서의 목차 역할을 합니다. 스크린리더와 보조 기술은 헤딩 목록을 제공하고 사용자가 원하는 섹션으로 바로 이동할 수 있게 합니다. 가장 중요한 제목은 보통 h1, 그 아래 주요 섹션은 h2, 하위 항목은 h3처럼 콘텐츠의 포함 관계를 단계로 표현합니다.
h2 다음에 바로 h4가 나오면 중간 단계가 생략됐다고 느낄 수 있습니다. 반대로 h4에서 h2로 돌아가는 것은 앞선 하위 섹션이 끝난 정상적인 구조일 수 있습니다. 검사기는 아래 단계로 두 칸 이상 내려갈 때만 검토 항목을 만들며, 여러 h1이나 h1 부재는 WCAG 위반으로 단정하지 않고 전체 문서의 구조를 다시 확인하도록 안내합니다.
헤딩 문구 자체가 다음 내용을 정확히 설명하는지도 중요하지만, 이는 문자열만으로 판정할 수 없습니다. 상세, 기타, 더보기처럼 문맥 없이는 목적을 알기 어려운 헤딩이 있다면 사람이 직접 수정 여부를 판단해야 합니다.
header, nav, main, aside, footer와 ARIA landmark role은 페이지를 큰 영역으로 나눕니다. 보조 기술 사용자는 전체 링크를 하나씩 지나가지 않고 주요 콘텐츠나 탐색 영역으로 이동할 수 있습니다. 특히 전체 문서에는 현재 페이지의 핵심 콘텐츠를 나타내는 main이 있는지 확인할 가치가 있습니다.
같은 역할의 랜드마크가 여러 개라면 이름으로 구분해야 합니다. 예를 들어 상단 주요 탐색과 푸터 탐색이 모두 nav라면 각각에 주요 메뉴, 푸터 메뉴 같은 aria-label을 주어 목적을 알려줄 수 있습니다. 이름 없이 navigation이 반복되면 스크린리더의 랜드마크 목록에서도 서로 구분하기 어렵습니다.
랜드마크를 많이 추가하는 것이 목표는 아닙니다. 콘텐츠 구조에 필요한 영역만 사용하고, 반복되는 역할에 명확한 이름을 붙이는 것이 중요합니다. 모든 섹션에 role="region"을 붙이면 탐색 목록이 오히려 복잡해질 수 있습니다.
시각적 레이블은 화면에서 사용자가 보는 이름이고, 접근 가능한 이름은 브라우저가 접근성 API를 통해 보조 기술에 전달하는 이름입니다. 일반적인 폼 필드는 label의 for와 input의 id를 정확히 일치시키는 방법이 가장 명확합니다. label 안에 입력 필드를 넣는 암시적 연결도 가능하지만, 명시적 연결은 코드 리뷰와 유지보수에서 관계를 확인하기 쉽습니다.
placeholder는 입력을 시작하면 사라지고 레이블 역할을 안정적으로 대신하지 못합니다. aria-label은 화면에 텍스트가 없는 아이콘 버튼처럼 필요한 상황에 사용할 수 있지만, 보이는 레이블이 있다면 그 문구가 접근 가능한 이름에도 포함되어야 합니다. 화면에 검색이라고 쓰인 버튼의 aria-label이 항목 찾기라면 음성 명령 사용자가 화면에 보이는 말을 그대로 사용해 버튼을 찾기 어려울 수 있습니다.
이 도구는 aria-labelledby, aria-label, 연결된 label, 요소 안의 텍스트와 일부 native 대체값을 이용해 이름 신호를 추정합니다. 실제 accessible name 계산은 CSS 가시성, shadow DOM, host language 규칙과 재귀 관계가 얽힌 표준 알고리즘이므로, 복잡한 custom control은 브라우저 접근성 트리에서도 확인해야 합니다.
정보를 전달하는 이미지는 같은 목적을 제공하는 대체 텍스트가 필요합니다. 링크나 버튼 안의 이미지라면 이미지 모양보다 동작의 목적을 설명해야 합니다. 반대로 순수 장식 이미지는 빈 alt를 사용해 보조 기술이 건너뛰게 하는 것이 적절할 수 있습니다. 그래서 검사기는 alt 누락은 높은 가능성 문제로, 빈 alt는 장식 여부를 확인할 검토 항목으로 구분합니다.
alt 값이 image, 사진, banner-final-v3.jpg 같은 형태라면 사용자가 이미지의 의미를 이해하는 데 거의 도움이 되지 않습니다. 파일명이나 일반 단어만 들어간 경우 검사기가 경고하지만, 적절한 설명의 길이나 내용은 자동으로 판단하지 않습니다. 같은 이미지도 뉴스 기사, 상품 카드, 링크 버튼 등 사용 문맥에 따라 필요한 대체 텍스트가 달라집니다.
복잡한 차트와 다이어그램은 짧은 alt 하나만으로 모든 정보를 전달하기 어렵습니다. 핵심 요약을 대체 텍스트에 제공하고, 근처 본문이나 데이터 표에서 상세 내용을 제공하는 방식을 함께 검토하세요.
aria-labelledby, aria-describedby, aria-controls 같은 속성은 하나 이상의 요소 ID를 가리킵니다. 컴포넌트를 복제하거나 ID를 변경하면서 참조 속성만 남으면 보조 기술이 이름, 설명 또는 제어 관계를 찾지 못할 수 있습니다. 검사기는 참조된 ID가 문서 안에 실제로 존재하는지 확인하고, 중복 ID도 함께 찾습니다.
ARIA는 native HTML의 의미를 대체하는 만능 패치가 아닙니다. 가능한 경우 button, nav, main, label처럼 이미 역할과 동작이 정의된 HTML 요소를 먼저 사용하세요. custom role의 필수 상태와 키보드 동작 전체를 이 도구가 검증하지는 않으므로, 복잡한 위젯은 WAI-ARIA Authoring Practices와 실제 보조 기술 테스트가 필요합니다.
대부분의 인터페이스는 DOM 순서와 native 요소의 기본 포커스 동작을 유지하는 편이 안전합니다. tabindex에 1, 2 같은 양수 값을 사용하면 해당 요소들이 일반적인 DOM 순서보다 먼저 이동하고, 코드가 바뀔 때 관리하기 어려운 별도 순서를 만들 수 있습니다. 검사기는 양수 값을 검토 항목으로 표시하고, 숫자 순서와 DOM 순서를 조합해 예상 탭 순서를 보여줍니다.
이 목록은 실제 브라우저 테스트를 대체하지 않습니다. CSS로 숨긴 요소, display: contents, flex와 grid의 order, JavaScript로 열린 모달, 비활성 상태와 shadow DOM은 붙여넣은 HTML만으로 완전히 알 수 없습니다. 결과를 보고 의심되는 위치를 찾은 다음 실제 화면에서 Tab과 Shift+Tab으로 순서를 확인하세요.
tabindex가 -1인 경우는 프로그램으로 포커스를 옮겨야 하지만 일반 탭 순서에는 들어오지 않는 요소에 의도적으로 사용할 수 있습니다. native 버튼이나 링크에 적용됐다면 핵심 기능을 키보드로 놓칠 가능성이 있으므로 사용 이유를 검토해야 합니다.
오류 가능성 높음은 누락된 alt, 끊어진 label 연결, 이름 없는 버튼처럼 코드만으로도 수정 위치가 비교적 분명한 항목입니다. 검토 필요는 빈 alt가 정말 장식용인지, 건너뛴 헤딩 단계가 문서 구조상 문제인지처럼 문맥을 확인해야 하는 항목입니다. 수동 검사는 포커스 표시, 키보드 트랩, 색상 대비, 동적 상태처럼 실제 화면을 실행해야 확인할 수 있는 항목입니다.
발견 항목이 0개라고 해서 접근성이 완성됐다는 뜻은 아닙니다. 자동 검사는 사람이 볼 범위를 줄이는 필터에 가깝습니다. W3C도 평가 도구가 잠재적인 문제를 빠르게 찾는 데 도움을 주지만 모든 접근성 측면을 판정할 수 없고, 잘못되거나 오해를 부르는 결과가 생길 수 있다고 설명합니다.
먼저 구현한 컴포넌트의 HTML 조각을 붙여넣고 높은 가능성 문제부터 수정합니다. 그다음 헤딩 트리와 랜드마크 목록에서 콘텐츠 구조와 영역 이름을 확인하고, 예상 탭 순서에서 양수 tabindex와 이름 없는 상호작용 요소를 찾습니다. 정리가 끝나면 Markdown 보고서를 복사해 PR이나 QA 티켓에 첨부하세요.
마지막은 실제 화면입니다. 키보드 조작, 포커스 표시, 시각적 순서와 동적 상태를 직접 테스트하고, CSS가 적용된 색상 대비는 명도대비 검사기에서 따로 측정하세요. 오류·선택·차트가 색상에만 의존하는지는 색각이상 시뮬레이터로 확인할 수 있습니다.
수동 검사 8개는 발견 항목과 무관하게 항상 함께 표시됩니다. 자동 검사에서 잡히지 않는 영역을 시야에서 놓치지 않기 위해서입니다.
같은 조각이라도 h4 하나만 있는 것은 건너뛴 헤딩으로 보지 않습니다. 앞선 헤딩이 없어 단계를 비교할 수 없기 때문이며, 조각 범위에서는 lang·title·main 규칙도 실행되지 않습니다.
DOM에서는 도움말 링크가 마지막인데 탭으로는 두 번째로 이동합니다. 양수 값을 모두 제거하면 순서가 DOM 순서와 다시 일치합니다.
이 도구가 무엇인지, 누구에게·어떻게·왜 필요한지 한눈에 정리했습니다.
HTML 접근성 검사기는 붙여넣은 HTML의 구조, 대체 텍스트, 폼 레이블, 이름 신호와 포커스 순서를 정적으로 분석하는 브라우저 도구입니다.
구현 중인 마크업을 PR이나 웹접근성 QA 전에 점검하려는 프론트엔드 개발자, 퍼블리셔, QA 담당자와 PM을 위한 도구입니다.
HTML을 렌더링하지 않는 파서로 요소와 속성을 읽고, 규칙별 문제 위치·관련 WCAG 기준·수정 방향과 수동 검사 목록을 보여줍니다.
설치나 배포 전에 반복되는 마크업 오류를 빠르게 찾고, 자동 검사 결과를 전체 접근성 준수로 오해하지 않도록 검사 범위를 구분하기 위해 사용합니다.