SaaS 제품과 웹 앱을 위한 WCAG 2.2 AA 체크리스트

SaaS를 위한 WCAG 2.2 AA 체크리스트: 로그인, 양식, 대화상자, 단일 페이지 앱 탐색, 표, 차트, 드래그 앤 드롭, 시간 제한, 구매 측이 요구하는 ACR까지.

FixReports 편집팀2026년 10월 26일 업데이트7분 분량

SaaS 제품에는 접근성을 갖춰야 할 영역이 두 가지 있습니다. 제품을 판매하는 마케팅 사이트와 사람들이 매일 사용하는 애플리케이션입니다. 마케팅 사이트는 낮은 명도 대비, 대체 텍스트 누락, 레이블 없는 양식처럼 다른 웹사이트와 같은 방식으로 실패합니다. 애플리케이션에는 고유한 문제가 더해집니다. 비밀번호 관리자를 막는 로그인 흐름, 키보드 포커스를 가두는 대화상자, 스크린 리더가 알아차리지 못하는 단일 페이지 앱의 화면 전환, 텍스트 없는 데이터 표와 차트, 대안 없는 드래그 앤 드롭, 경고 없이 만료되는 세션 등입니다. 이 체크리스트는 일반적인 SaaS 제품의 구성 요소별로 WCAG 2.2 레벨 AA를 살펴봅니다.

핵심 요약

WCAG 2.2는 2023년 10월 W3C 권고안이 되었으며, 성공 기준 9개를 추가했고 그중 6개가 A 또는 AA 수준입니다 (W3C (새 탭에서 열림)).
Accessible Authentication(3.3.8, AA)에 따라, 비밀번호를 붙여넣거나 비밀번호 관리자를 사용할 수 있는 경우가 아니라면 로그인이 비밀번호를 기억하거나 옮겨 적는 데 의존해서는 안 됩니다 (W3C (새 탭에서 열림)).
조작할 수 있는 타깃은 최소 24 × 24 CSS 픽셀이거나 주변에 충분한 간격이 있어야 합니다(2.5.8, AA) (W3C (새 탭에서 열림)).
“저장됨”이나 “결과 3개” 같은 메시지는 포커스를 옮기지 않고도 스크린 리더에 전달되어야 합니다(4.1.3, AA) (W3C (새 탭에서 열림)).
기업과 공공 부문 구매 담당자는 접근성 준수 보고서(ACR)를 요구하는 경우가 많으며, ACR은 보통 정보기술산업협의회(ITI)의 VPAT 템플릿으로 작성합니다 (ITI (새 탭에서 열림)).

SaaS에서는 왜 소개용 웹사이트보다 접근성이 더 중요한가요?

사람들은 SaaS 제품을 몇 시간씩 사용하며, 그 제품은 대개 고용주가 선택한 것입니다. 마케팅 페이지의 장벽은 방문자 한 명을 잃게 하지만, 제품 안의 장벽은 누군가가 업무를 하지 못하게 만들 수 있습니다. 그래서 대형 고객, 대학, 공공 기관은 구매 전에 접근성에 대해 묻는 일이 늘고 있으며, 그 답변은 웹사이트뿐 아니라 애플리케이션까지 다루어야 합니다.

또 다른 이유는 자동화 테스트가 문제의 일부만 잡아낸다는 점입니다. axe-core 같은 도구는 레이블 누락이나 낮은 명도 대비처럼 마크업의 오류를 찾아냅니다. 하지만 대화상자가 포커스를 올바른 곳으로 되돌리는지, 차트의 데이터를 텍스트로 얻을 수 있는지, 어떤 작업 흐름을 키보드만으로 완료할 수 있는지는 판단하지 못합니다. 애플리케이션에는 자동 검사와 수동 테스트가 모두 필요합니다.

회원가입과 로그인은 어떻게 접근 가능하게 만드나요?

WCAG 2.2가 SaaS에 가장 중요한 새 요구 사항을 더한 곳이 인증입니다.

붙여넣기와 비밀번호 관리자를 허용합니다(3.3.8, AA). 비밀번호나 인증 코드 입력란에 붙여넣기를 막지 말고, autocomplete="username", autocomplete="current-password", autocomplete="one-time-code"를 사용해 브라우저와 비밀번호 관리자가 자동으로 채울 수 있게 합니다.
퍼즐을 유일한 방법으로 두지 않습니다. 일그러진 글자를 옮겨 적거나 퍼즐을 풀게 하는 CAPTCHA는 인지 기능 테스트에 해당합니다. 대안을 제공하고, 사용자 조작이 필요 없는 확인 방식을 우선합니다 (W3C (새 탭에서 열림)).
모든 입력란에 레이블을 붙입니다(1.3.1 및 3.3.2, A). 입력란과 연결된, 눈에 보이는 <label>을 사용합니다. 플레이스홀더 텍스트는 입력을 시작하면 사라지므로 레이블이 될 수 없습니다.
오류를 텍스트로 알리고(3.3.1, A) 수정 방법을 제안합니다(3.3.3, AA). “비밀번호는 12자 이상이어야 합니다”는 도움이 되지만, 빨간 테두리만으로는 도움이 되지 않습니다.
같은 것을 두 번 묻지 않습니다(3.3.7, A). 여러 단계로 된 회원가입에서 회사명이나 주소를 이미 물었다면, 다시 입력하게 하지 말고 자동으로 채우거나 선택할 수 있게 합니다.
도움말을 같은 위치에 둡니다(3.2.6, A). 채팅, 도움말 링크, 연락처를 제공한다면 흐름의 모든 페이지에서 같은 상대적 위치에 둡니다.

가장 많은 실패를 일으키는 양식과 오류 처리 패턴은 무엇인가요?

애플리케이션 오류의 대부분은 양식에 있습니다. WebAIM이 2026년에 100만 개 홈페이지를 조사한 결과 51%에서 양식 레이블 누락이 발견되었으며 (WebAIM (새 탭에서 열림)), 애플리케이션에는 홈페이지보다 훨씬 많은 양식이 있습니다.

각 입력란에 프로그래밍 방식으로 인식할 수 있는 이름을 지정하고, 라디오 버튼처럼 관련된 컨트롤은 <fieldset>과 <legend>로 묶습니다.
사용자가 알아차릴 수 있는 곳에서 오류를 알립니다. 양식 상단의 오류 요약이나 첫 번째로 잘못된 입력란으로 포커스를 옮기고, 요약의 각 항목을 해당 입력란에 연결합니다.
필수 입력란은 색상만이 아니라 텍스트로 표시합니다(1.4.1, A).
사용자가 옵션을 선택하기만 했을 때 양식을 제출하거나 맥락을 바꾸지 않습니다(3.2.2, A). 명시적인 조작이 있을 때까지 기다립니다.

대화상자, 메뉴, 팝오버는 어떻게 동작해야 하나요?

키보드와 스크린 리더 지원이 가장 자주 깨지는 곳은 직접 만든 컴포넌트입니다. WAI-ARIA 작성 관행 가이드(APG)는 패턴별로 기대되는 동작을 설명합니다 (W3C (새 탭에서 열림)).

대화상자: 열릴 때 포커스를 대화상자 안으로 옮기고, 열려 있는 동안 Tab 이동을 대화상자 안에 유지하며, Escape 키로 닫히게 하고, 닫히면 대화상자를 연 컨트롤로 포커스를 되돌립니다. 네이티브 <dialog> 요소나, aria-modal="true"와 이름을 지정한 role="dialog"를 사용합니다.
키보드 트랩 없음(2.1.2, A): 모든 컴포넌트에서 키보드로 빠져나올 수 있어야 합니다.
포커스 표시(2.4.7, AA): 포커스가 보여야 하며, 고정 헤더, 쿠키 배너, 채팅 위젯 뒤에 가려지지 않아야 합니다(2.4.11, AA, 2.2에서 신설).
툴팁과 팝오버(1.4.13, AA): Escape 키로 닫을 수 있고, 포인터를 올려도 사라지지 않으며, 닫을 때까지 계속 표시되어야 합니다.
단일 문자 단축키(2.1.4, A): 글자 키 하나로 동작이 실행된다면 단축키를 끄거나 다시 지정할 수 있게 하거나, 해당 컴포넌트에 포커스가 있을 때만 작동하게 합니다.

단일 페이지 앱의 탐색은 어떻게 처리하나요?

단일 페이지 앱에서는 페이지를 새로 불러오지 않고 URL이 바뀌므로, 스크린 리더가 무슨 일이 일어났는지 알리지 않을 수 있습니다.

경로가 바뀔 때마다 문서 제목을 업데이트해 각 화면에 설명적인 제목을 붙입니다(2.4.2, A).
새 화면의 주 제목으로 포커스를 옮기거나 polite 라이브 영역으로 변경을 알립니다. Next.js 같은 프레임워크에는 이를 위한 경로 알림 기능이 포함되어 있습니다.
논리적인 포커스 순서를 유지합니다(2.4.3, A). 항목을 삭제한 뒤에는 포커스가 페이지 맨 위로 돌아가지 않고 알맞은 이웃 항목으로 이동해야 합니다.
건너뛰기 링크나 랜드마크처럼 반복되는 탐색 영역을 건너뛰는 방법을 제공합니다(2.4.1, A).

대시보드, 데이터 표, 차트는 어떻게 접근 가능하게 만드나요?

표: 실제 <table> 마크업을 사용하고, 머리글에는 <th>와 scope를, 그리고 표 제목(caption)을 붙입니다(1.3.1, A). <div> 요소로 만든 그리드에는 ARIA 그리드 패턴 전체를 구현해야 하므로 올바르게 만들기가 훨씬 어렵습니다.
차트: 각 차트에 핵심을 전달하는 대체 텍스트를 붙이고, 데이터를 표로도 제공합니다(1.1.1, A). 계열 구분을 색상에만 의존하지 말고(1.4.1, A) 레이블이나 패턴을 더합니다.
명도 대비: 텍스트는 4.5:1(1.4.3, AA), 차트 선, 아이콘, 입력란 테두리는 배경 대비 3:1(1.4.11, AA)이 필요합니다. 다크 모드는 따로 확인하십시오. 저희 색상 대비 검사기로 어떤 색상 조합이든 테스트할 수 있습니다.
상태 메시지(4.1.3, AA): “저장됨”, “업로드 완료”, 결과 개수에는 role="status"나 라이브 영역을 사용해, 스크린 리더 사용자가 현재 위치를 잃지 않고 들을 수 있게 합니다.

WCAG 2.2의 새 기준은 웹 앱에 무엇을 바꾸나요?

기준	수준	앱에서의 의미
2.4.11 Focus Not Obscured (Minimum)	AA	고정 툴바, 배너, 채팅 위젯이 포커스를 받은 요소를 완전히 가려서는 안 됨
2.5.7 Dragging Movements	AA	칸반 보드 순서 변경처럼 드래그로 하는 모든 작업에는 메뉴나 위·아래 버튼 같은 단일 포인터 대안이 필요함
2.5.8 Target Size (Minimum)	AA	버튼과 링크는 최소 24 × 24 CSS 픽셀이거나, 각 타깃을 둘러싼 24픽셀 원이 다른 타깃과 겹치지 않을 만큼 간격을 두어야 함
3.2.6 Consistent Help	A	도움말 링크, 채팅, 연락처가 모든 페이지에서 같은 상대적 위치에 있어야 함
3.3.7 Redundant Entry	A	같은 프로세스에서 이미 입력한 정보는 자동으로 채워지거나 선택할 수 있어야 함
3.3.8 Accessible Authentication (Minimum)	AA	붙여넣기, 비밀번호 관리자 또는 다른 방법을 허용하는 경우가 아니라면, 암기나 옮겨 적기 없이 로그인할 수 있어야 함

WCAG 2.2는 접근성에 더 이상 실질적인 영향을 주지 않는 4.1.1 Parsing도 삭제했습니다 (W3C (새 탭에서 열림)).

시간 제한, 레이아웃, 확대는 어떻게 해야 하나요?

세션 시간 제한(2.2.1, A): 시간 제한이 필수적이거나 20시간을 넘는 경우가 아니라면, 세션이 만료되기 전에 경고하고 간단한 조작으로 연장할 수 있게 합니다. 작업 중인 내용을 저장해 두면 최악의 상황을 피할 수 있습니다.
리플로우(1.4.10, AA): 콘텐츠는 너비 320 CSS 픽셀(1280픽셀 화면에서 400% 확대한 것과 같음)에서도 두 방향으로 스크롤하지 않고 사용할 수 있어야 합니다. 데이터 표 같은 콘텐츠는 예외입니다.
텍스트 간격(1.4.12, AA): 줄 간격과 글자 간격을 늘려도 텍스트가 잘리지 않아야 합니다. 높이가 고정된 컨테이너에서 자주 잘립니다.
화면 방향(1.3.4, AA): 꼭 필요한 경우가 아니라면 앱을 세로나 가로 방향으로 고정하지 않습니다.

ACR이란 무엇이며, 꼭 필요한가요?

접근성 준수 보고서(ACR)는 제품이 각 접근성 기준을 어떻게 충족하는지 지원, 부분 지원, 미지원으로 구분하고 비고와 함께 기록한 문서입니다. 대부분은 정보기술산업협의회가 발행하는 VPAT 템플릿으로 작성하며, 이 템플릿에는 WCAG, 미국 재활법 508조 기준, 유럽 표준 EN 301 549에 맞춘 판이 있습니다 (ITI (새 탭에서 열림)).

미국 연방 기관은 508조에 따라 접근 가능한 기술을 구매해야 하고 (Section508.gov (새 탭에서 열림)), EU 공공 기관은 EN 301 549를 참조합니다. 그래서 이런 고객에게 판매하는 B2B 제품은 조달 과정에서 ACR을 요구받는 경우가 많습니다. 알려진 부족한 점을 적은 정직한 ACR이 완전한 지원을 주장하는 ACR보다 구매 측에 더 유용합니다. ACR은 수동 테스트를 포함한 제품 테스트를 바탕으로 작성해야 하며, 자동 스캔만으로는 채울 수 없습니다.

EU 소비자에게 판매한다면 온라인 판매 방식에 유럽 접근성법이 적용될 수도 있습니다. 적용 범위는 저희 유럽 접근성법 가이드에서 설명합니다. 이 글은 법률 자문이 아닙니다.

SaaS 팀은 접근성을 어떻게 테스트해야 하나요?

기본 검사를 자동화합니다. 엔드투엔드 테스트와 마케팅 사이트에서 axe-core나 비슷한 엔진을 실행하고, 새로운 위반이 생기면 빌드가 실패하게 합니다. 저희 무료 웹 접근성 검사기는 같은 엔진을 모든 공개 페이지에서 실행합니다.
키보드로 테스트합니다. 회원가입, 레코드 생성, 설정 변경 같은 주요 작업 흐름을 Tab, Shift+Tab, Enter, Space, Escape, 방향키만으로 완료합니다.
스크린 리더로 테스트합니다. Windows의 NVDA와 macOS 및 iOS의 VoiceOver는 무료입니다. 이름, 역할, 상태, 메시지가 읽히는지 확인합니다.
확대하고 크기를 바꿔 봅니다. 200% 텍스트 확대와 너비 320픽셀 창을 확인합니다.
디자인 시스템에서 수정합니다. 대부분의 오류는 공통 컴포넌트에서 생깁니다. 버튼이나 대화상자를 한 번 고치면 그것이 쓰이는 모든 곳이 고쳐집니다.

자주 묻는 질문

WCAG는 웹 앱의 로그인 후 영역에도 적용되나요?

WCAG는 로그인이 필요한 페이지를 포함한 모든 웹 콘텐츠에 적용됩니다. 특정 제품이 법적으로 이를 충족해야 하는지는 관할 지역과 고객에 따라 다르지만, 접근성을 묻는 구매 담당자는 보통 제품 전체를 염두에 둡니다.

오버레이로 SaaS 제품을 접근 가능하게 만들 수 있나요?

아니요. 오버레이는 애플리케이션 오류가 실제로 있는 맞춤형 컴포넌트의 기반 코드를 바꾸지 않습니다. 주요 오버레이 업체에 대한 FTC의 조치는 저희 접근성 오버레이 가이드에서 다룹니다.

자동화 도구로 WCAG를 얼마나 검사할 수 있나요?

일부만 가능합니다. 자동화 규칙은 이름 누락, 레이블 누락, 대비 실패를 확실하게 찾아내지만, 의미 있는 포커스 순서, 유용한 대체 텍스트, 이해하기 쉬운 오류 메시지 같은 많은 기준은 사람이 판단해야 합니다.

어떤 WCAG 버전을 목표로 해야 하나요?

현재 버전은 WCAG 2.2 레벨 AA입니다. 많은 법률과 조달 규정은 여전히 WCAG 2.1 AA를 참조하지만, 삭제된 Parsing 기준을 제외하면 2.2 AA를 충족하면 2.1 AA도 충족합니다.

레벨 AAA까지 충족해야 하나요?

일부 콘텐츠는 모든 AAA 기준을 충족할 수 없으므로, W3C는 제품 전체에 AAA를 요구하는 것을 권장하지 않습니다. 일반적인 목표는 레벨 AA입니다.