STATUS IS UP웹사이트 최적화 위키
14활성화
디자인 및 UX / 활성화

웹사이트 접근성 체크리스트 - 소유자용

핵심 여정(정보 찾기, 연락, 로그인, 예약, 구매, 도움 받기)을 검토하고 장애를 수정하며 WCAG 2.2를 활용하는 실무 소유자 프로세스입니다. 자동 스캔을 규정 준수 증거로 오해하지 마세요.

웹사이트 접근성 체크리스트 - 소유자용 — 시각 가이드
읽기
7 분
출처
5
재검증
2027-03-27
검토됨
접근성 전문가 및 웹 품질 리뷰어
간단 답변

결정부터 시작하세요.

중요한 고객 여정(정보 찾기, 연락, 로그인, 예약/구매, 도움 받기)에 이 웹사이트 접근성 체크리스트를 적용하세요. WCAG 2.2 목표를 설정하고, 해당 여정에서 사용하는 템플릿과 상태를 샘플링한 뒤 키보드, 확대(줌), 콘텐츠 검토, 자동 검사기를 사용해 테스트합니다. 각 발견사항은 구체적인 수정 항목과 담당자를 지정하여 릴리스 후 재검증하세요.

단순한 클린 스캔이나 빠른 페이지 검토는 접근성이나 준수를 보증하지 않습니다. W3C는 도구만으로 사이트가 접근성 표준을 충족하는지 판단할 수 없다고 명시하며, 그들의 빠른 검사도 포괄적이지 않습니다. SIU는 사전 출시 검토와 수정 작업을 지원할 수 있지만, 이는 WCAG 인증, 법적 의견, 또는 모든 방문자가 모든 서드파티 서비스를 사용할 수 있다는 보장은 아닙니다.

시각 가이드

작업을 시스템 관점에서 보세요.

개별 전술을 실행하기 전에 이 지도로 문서의 의사결정 간 관계를 파악하세요.

SIU활성화
011. 검토 범위 정의
022. 키보드 경로 테스트
033. 구조와 명확한 의미 확인
044. 텍스트·레이아웃·색·미디어 스트레스 테스트
01

1. 검토 범위 정의

무작위 URL이 아니라 완전한 결과물을 기준으로 시작하세요. 홈페이지, 주요 콘텐츠, 검색, 연락처, 계정, 예약 또는 결제, 확인 페이지, 도움말 및 경로 상의 모든 임베디드 서비스를 매핑하세요. 재사용되는 내비게이션, 모달, 쿠키 컨트롤, 폼도 포함하세요. 하나의 결함이 사이트 전체에 반복될 수 있습니다.

목표 설정

WCAG 버전과 수준, 적용 범위, 브라우저·장치, 알려진 제외 항목을 기록하세요.

여정을 완전하게 다루기

로그인 상태, 빈 상태, 오류 보기 등 모든 단계와 상태를 검토하세요.

02

2. 키보드 경로 테스트

포인터 없이 각 선택된 작업을 완료하세요. 링크, 컨트롤, 대화상자, 메뉴, 필터, 날짜 선택기, 미디어, 벤더 위젯을 Tab과 Shift+Tab으로 이동합니다. 포커스는 시각적으로 보여야 하고, 합리적인 순서를 따르며, 갇히지 않아야 하고 대화상자가 닫힌 뒤 유용한 위치로 돌아와야 합니다. 키보드로의 조작성은 WCAG의 핵심입니다; 커스텀 마우스 제어가 키보드로 동작한다고 가정하지 마세요.

반복 건너뛰기 제공

반복되는 내비게이션을 탭으로 계속 통과하지 않고 주요 콘텐츠로 도달하는 방법을 제공하고 테스트하세요.

드래그 상호작용 확인

인터페이스가 드래그를 요구하는 경우, 적용 가능한 비드래그 대안이 있는지 검토하세요.

03

3. 구조와 명확한 의미 확인

페이지에 설명적인 제목을 부여하고, 외형이 아니라 계층 구조를 위해 제목을 사용하세요. 컨트롤은 보조 기술에 유용한 이름, 역할, 상태를 노출해야 합니다; 기본 HTML 컨트롤은 위험을 줄여줍니다. 의미 있는 이미지는 목적에 맞는 간결한 대체 텍스트가 필요하고, 장식용 이미지는 잡음을 추가해서는 안 됩니다. 상태나 지침에 색만 사용하지 말고 페이지의 언어를 식별하세요.

링크 목적 검토

문맥에서 목적지나 동작이 이해되도록 만드세요; 반복적이고 모호한 링크는 혼란을 초래합니다.

소스 순서 확인

레이아웃이 변경되거나 스타일이 없을 때도 콘텐츠와 컨트롤이 논리적으로 읽히도록 하세요.

04

4. 텍스트·레이아웃·색·미디어 스트레스 테스트

브라우저 확대(줌)과 텍스트 크기를 늘리고 주요 작업을 반복하세요. 콘텐츠는 서로 겹치거나 사라지거나 의도치 않은 가로 스크롤을 유발하지 않고 읽기 가능하고 사용 가능해야 합니다. 텍스트, 컨트롤, 포커스, 오류, 차트에 대한 실제 색 조합을 관련 상태에서 확인하세요. 녹화된 미디어의 경우 필요한 오디오 정보를 위한 자막과 콘텐츠에 적합한 텍스트 대체물을 제공하세요.

기본 상태 이상 테스트

호버, 포커스, 비활성, 오류 및 다크 모드나 대체 시각 상태를 포함하세요.

미디어 컨트롤 검토

플레이어의 키보드 테스트뿐 아니라 자막, 대본(트랜스크립트), 중요 시각 정보도 검토하세요.

05

5. 폼과 계정 작업의 복구 가능성 확보

가치가 높은 폼에 잘못된 입력, 누락, 유효한 데이터를 제출해 보세요. 입력 필드는 지속적이고 프로그래밍적으로 연결된 레이블이 필요합니다; 플레이스홀더만으로는 신뢰할 수 없습니다. 제출 전에 필수 항목을 표시하고, 문제가 무엇인지 평이한 언어로 설명하며, 해당 필드를 가리키고, 가능한 경우 입력한 데이터를 보존하세요. 로그인, 비밀번호 재설정, 일회용 코드, 결제, 확인 절차를 여정으로 테스트하세요.

색만으로 오류 표시하지 않기

오류 색상은 평이한 언어의 메시지와 식별 가능한 영향을 받은 필드와 함께 제공하세요.

벤더 경계 테스트

결제나 신원 제공자와의 핸드오프, 리디렉션, 실패 경로, 복귀를 키보드로 테스트하세요.

06

6. 도구와 사람, 수동 검토 결합

대표 페이지에서 자동 검사기를 실행하되 결과를 단서(lead)로 사용하고 합격 증명으로 삼지 마세요. 도구는 대체 텍스트가 의미 있는지, 순서가 이해되는지, 지침이 이해하기 쉬운지, 여정이 보조 기술과 함께 작동하는지 등을 판단할 수 없습니다. 수동 키보드와 확대 검사 및 목표가 명확한 스크린리더 검토를 추가하세요. 가능하면 관련 실사용 경험이 있는 사람들을 조기 참여시키고 정당하게 보상하세요.

증거를 한곳에 보관

도구 출력, 리뷰어 노트, 결정사항, 수정 내용, 재검증 결과를 한 이슈 기록에 보관하세요.

비례적으로 에스컬레이션

형식적 주장, 규제 대상 서비스, 복잡한 애플리케이션, 또는 이견이 있는 결과에는 자격을 갖춘 평가자를 활용하세요.

07

7. 수정 작업을 릴리스에 통합

테마, 캠페인, 플러그인, 스크립트, 디자인 토큰, 또는 벤더 변경 후 접근성이 회귀할 수 있습니다. 디자인, 콘텐츠, 품질 보증, 출시 작업에 비례한 검토를 추가하세요. SIU는 사전 출시 경로 유지, 고객 대면 결함 식별, 안전한 수정 수행, 필요 시 롤백 계획 사용 등 적극적인 업타임 최적화 및 수정 작업에 중점을 둡니다. 접근성 검토는 이 작업을 보완하며, 가용성 검사나 장애 알림으로 대체되지 않습니다.

릴리스 차단 기준 설정

주요 작업을 키보드로 완료할 수 없거나 치명적 오류가 이해 불가능한 경우 릴리스를 차단하세요.

문맥에서 재검증

수정 후 이슈를 닫기 전에 원래 작업, 모바일 및 오류 상태를 다시 확인하세요.

실행 / 검증

실무용 할 일 가이드.

  1. 01

    목표 설정

    WCAG 버전과 수준, 범위, 담당자 및 전문 검토가 필요한 시점을 기록하세요.

    검증: 한 페이지 분량의 범위 문서에 핵심 여정, 적용 범위, 제외 항목, 의사결정자가 명시되어 있습니다.
  2. 02

    여정 매핑

    정보, 연락, 계정, 구매 또는 예약, 결제, 확인, 지원에 대한 시작부터 종료까지의 경로를 나열하세요.

    검증: 각 중요 작업에 대해 대표 페이지와 상태가 선택되어 있습니다.
  3. 03

    기본 스캔 실행

    자동 검사기를 사용한 뒤 모든 발견사항에 담당자를 지정하거나 문서화하세요.

    검증: 보고서는 이슈 로그에 보관되어 있으며, 어떤 스캔도 인증으로 기록되지 않았습니다.
  4. 04

    키보드만 사용

    메뉴, 대화상자, 폼, 위젯, 오류, 확인을 포인터 없이 탐색하세요.

    검증: 포커스가 시각적으로 보이고 순서가 논리적이며 필요한 동작이 사용자에게 갇힘을 만들지 않습니다.
  5. 05

    의미성 검토

    제목, 제목 태그, 레이블, 링크, 이미지 대체 텍스트, 언어, 색 이외의 단서를 확인하세요.

    검증: 컨트롤과 콘텐츠가 시각적 표현을 벗어나서도 이해 가능하게 유지됩니다.
  6. 06

    디스플레이 조정

    확대(줌), 텍스트 크기, 대비, 포커스 및 오류 상태, 미디어 대체물을 테스트하세요.

    검증: 핵심 작업이 테스트된 조정 아래에서도 읽기 가능하고 사용 가능하게 유지됩니다.
  7. 07

    복구 시나리오 실행

    유효하지 않은 데이터와 유효한 데이터를 폼에 제출하고, 로그인, 재설정, 인증, 돌이킬 수 없는 작업을 테스트하세요.

    검증: 오류는 수정 경로를 식별하고 불필요한 데이터 손실 없이 복구할 수 있도록 합니다.
  8. 08

    공급업체 테스트

    임베디드되거나 리디렉션되는 결제 및 신원 경험을 고객처럼 따라가 보세요.

    검증: 열린 벤더 장벽에는 증거, 담당자, 에스컬레이션 경로가 있습니다.
  9. 09

    수정 및 재검증

    핵심 작업의 차단 요건을 우선순위로 지정하여 수정하고 원래 문맥에서 재검증하세요.

    검증: 닫힌 이슈에는 재검증 결과가 포함되어 있고, 열린 항목에는 담당자와 목표일이 있습니다.
  10. 10

    반복 가능하게 만들기

    관련 검사를 게시, 품질 보증, 릴리스 절차에 포함시키세요.

    검증: 릴리스 기록에 수행된 검토 내용과 변경 사항이 명시되어 있습니다.
토론 주제

트레이드오프를 비교하세요 — 개인정보는 공유하지 마세요.

이 프롬프트를 팀이나 웹사이트 소유자 커뮤니티와 함께 사용하세요. 방법과 교훈은 공유하되, 인증 정보·고객 기록·비공개 인프라 세부사항은 절대 붙여넣지 마세요.

  1. 01

    키보드 사용자에게 잃어버렸을 때 가장 치명적인 고객 여정은 무엇이며, 다음 검토의 담당자는 누구인가요?

  2. 02

    팀이 유용한 자동화 발견사항을 수동 또는 전문 검토가 필요한 주장과 구분하는 데 어떤 증거가 도움이 될까요?

  3. 03

    디자인, 콘텐츠, 엔지니어링, 벤더 팀이 고객 또는 보안·민감 데이터 노출 없이 장애를 어떻게 공유할 수 있을까요?

주요 / 신뢰할 수 있는 자료

출처 자료 열기

World Wide Web Consortium (W3C)Web Content Accessibility Guidelines (WCAG) 2.2 ↗

원칙, 성공 기준, 수준, 적합성 범위에 대한 규범적 표준입니다.

검토일: 2026-09-27
W3C Web Accessibility InitiativeEasy Checks – A First Review of Web Accessibility ↗

기본 검사에 대한 실용적 시작점과 해당 도구의 한계를 설명합니다.

검토일: 2026-09-27
W3C Web Accessibility InitiativeEvaluating Web Accessibility Overview ↗

도구가 왜 지식 있는 사람의 평가가 필요한지 설명하고 평가 자원에 연결합니다.

검토일: 2026-09-27
W3C Web Accessibility InitiativeHow to Meet WCAG (Quick Reference) ↗

WCAG 2.2 기준과 지침을 수준, 기술, 역할, 주제별로 필터링합니다.

검토일: 2026-09-27
MDN Web DocsAccessibility tooling and assistive technology ↗

도구링, 접근성 트리, 스크린리더, 사용자 테스트에 관한 실무 배경을 제공합니다.

검토일: 2026-09-27

출처 정책 초안 작성 전에 출처를 검토했습니다. 이 문서는 W3C/WAI 표준과 평가 지침을 우선시하며, 구현 교육에는 MDN을 참고했습니다. SIU 링크는 내비게이션용이며 증거로 간주하지 않습니다. 형식적 적합성(conformance), 법적·보안·결제·계약 관련 결정은 자격을 갖춘 검토가 필요합니다.

빠른 설명

자주 묻는 질문

자동 접근성 스캔만으로 웹사이트가 접근 가능하다고 말할 수 있나요?

아니요. 일부 반복적 문제를 찾아내긴 하지만 많은 맥락 의존적 장애는 판별하지 못합니다. 도구와 수동 테스트를 결합하고, 위험이 클 경우 자격 있는 평가와 실제 사용자 피드백을 받으세요.

소유자는 WCAG 2.2 AA를 목표로 삼아야 하나요?

AA는 A와 AA 기준을 포함하는 유용한 결정 프레임워크지만, 목표는 적용되는 요구사항, 계약, 대상, 서비스 위험에 따라 달라집니다. 부분적 검토만으로는 적합성 주장(conformance claim)을 뒷받침할 수 없으니, 필요할 경우 자격 있는 접근성 전문가 및 법률 자문을 구하세요.

임베디드된 벤더 도구가 접근 불가능할 때 책임은 누구에게 있나요?

공급업체가 코드를 통제할 수는 있지만 고객은 결합된 여정을 경험합니다. 핸드오프를 테스트하고, 장벽을 문서화하고, 수정 요청을 하며 대안이나 완화책을 검토하세요. 벤더 문서만으로 실제 여정의 사용성을 증명할 수 없습니다.

Status Is UP Editorial Team · 가동 시간(업타임) 지원 편집자

검토자: 접근성 전문가 및 웹 품질 리뷰어. 게시 2026-09-27; 업데이트 2026-09-30.