# WCAG 2.2 신규 성공기준 6개 — 타겟 크기 24px까지

> WCAG 2.2에서 새로 생긴 성공기준 중 실무 비중이 큰 6개 — 포커스 가림, 드래그 대안, 타겟 크기, 도움 일관성, 반복 입력, 접근 가능한 인증을 코드 예시와 함께 정리하고, AAA 3개와 KWCAG·글로벌 대응 현황까지 짚었습니다.

**Published:** 2026-08-19 | **Updated:** 2026-08-19

---


"WCAG 2.1까지는 봤는데, 2.2는 뭐가 더 생긴 거예요?"

프론트엔드를 하다 보면 이런 질문을 종종 받습니다. 사실 WCAG 2.2가 W3C 권고안(Recommendation)으로 확정된 게 2023년 10월 5일이니 벌써 3년 가까이 됐어요. 참고로 지금 `w3.org/TR/WCAG22/`에 올라와 있는 문서는 2024년 12월 12일자 개정 권고안입니다. 성공기준이 바뀐 건 아니고, 확정 이후의 정정 사항을 반영해 다시 발행한 판이에요. 그런데 실무에서는 여전히 2.1 기준으로 체크리스트를 돌리는 팀이 많습니다. 새 기준을 몰라서라기보다, "9개나 늘었다는데 다 봐야 하나" 싶어서 미뤄둔 경우가 많더라고요.

결론부터 말하면 9개를 전부 외울 필요는 없습니다. 이 글에서는 실무에서 부딪힐 확률이 높은 **A·AA 등급 6개**를 코드와 함께 짚고, 나머지 AAA 등급 3개는 짧게만 다룹니다. 각 기준이 어떤 사용자를 위해 생겼는지, 어떤 코드가 걸리고 어떤 코드가 통과하는지를 보고 나면 "왜 이게 필요했는지" 감이 잡힐 거예요.

이 글의 네 기준은 **직접 눌러볼 수 있는 데모 페이지**\ 로도 만들어뒀습니다. 읽다가 "정말 그런가?" 싶은 대목이 나오면 [WCAG 2.2 신규 기준 체험 페이지](https://isaaceryn.github.io/demo_codes/wcag22-new-criteria/)를 열어 Tab 키로 확인해보세요. 위반과 개선을 나란히 놓아둬서, 같은 조작을 양쪽에서 해보면 차이가 바로 드러납니다. 글로 읽는 것과 포커스가 헤더 뒤로 사라지는 걸 직접 보는 건 꽤 다릅니다.

## 왜 지금 다시 봐야 하나

3년이나 지난 기준을 지금 다시 꺼내는 이유는 두 가지입니다.

하나는 국내 기준이 이미 움직였다는 점입니다. 한국의 **KWCAG 2.2**(한국형 웹 콘텐츠 접근성 지침)는 2022년 12월 개정되면서 WCAG 2.2의 흐름 일부를 먼저 반영했습니다. 접근 가능한 인증, 찾기 쉬운 도움 정보, 반복 입력 정보 같은 개념이 이미 국내 표준 안에 들어와 있어요.

다른 하나는 유럽 쪽 흐름입니다. EU 조달 시장에서 쓰이는 **EN 301 549**가 현재는 WCAG 2.1 기준이지만, WCAG 2.2 AA로 정렬한 개정 초안이 이미 나와 있습니다. 유럽을 상대하는 제품이라면 미리 알아둘 가치가 있어요. 자세한 내용은 뒤에서 다시 다룹니다.

## 6개 신규 기준 한눈에 보기

먼저 오늘 다룰 6개를 표로 정리했습니다.

| 성공기준 | 이름 | 등급 |
|---|---|---|
| 2.4.11 | Focus Not Obscured (Minimum) | AA |
| 2.5.7 | Dragging Movements | AA |
| 2.5.8 | Target Size (Minimum) | AA |
| 3.2.6 | Consistent Help | A |
| 3.3.7 | Redundant Entry | A |
| 3.3.8 | Accessible Authentication (Minimum) | AA |

{{< img src="images/contents/wcag22-six-criteria.png" alt="WCAG 2.2 신규 A·AA 성공 기준 6개를 카드로 정리한 다이어그램 - 포커스 가림 방지, 드래그 동작, 타겟 크기, 일관된 도움, 중복 입력, 접근 가능한 인증" >}}

## 2.4.11 Focus Not Obscured (Minimum) — 포커스가 가려지면 안 됩니다

키보드로 폼을 채워나가다 보면, 포커스가 이동했는데 정작 그 요소가 안 보이는 경우가 있습니다. 고정 헤더나 하단 배너, 챗봇 위젯 같은 저작 콘텐츠(개발자가 만든 요소)가 포커스된 요소를 가려버리는 거예요. 마우스 사용자는 스크롤로 알아서 피해가지만, 키보드나 스위치로 탐색하는 사용자는 초점이 어디 있는지 시각적으로 확인 못 하면 그대로 길을 잃습니다.

**2.4.11**은 이런 상황을 막습니다. 포커스를 받은 요소가 저작 콘텐츠에 **완전히** 가려지지는 않아야 한다는 기준이에요. "완전히"라는 단서가 중요한데, 최소 등급(Minimum)은 일부만 가려지는 건 허용합니다. 일부도 허용하지 않는 건 뒤에 나올 AAA 등급의 몫이에요.

{{< img src="images/contents/focus-obscured.png" alt="2.4.11 비교 도해 - 왼쪽은 scroll-padding이 없어 Shift+Tab으로 되돌아온 입력칸이 고정 헤더 뒤에 완전히 숨은 모습이고, 오른쪽은 scroll-padding-top을 준 덕에 같은 입력칸이 헤더 아래로 온전히 보이는 모습입니다" caption="<a href='https://isaaceryn.github.io/demo_codes/wcag22-new-criteria/#focus-not-obscured' target='_blank' title='새 창에서 열림'>직접 눌러보기</a> — 아래까지 Tab으로 내려갔다가 Shift+Tab으로 올라와 보세요" >}}

그런데 언제 가려지는지가 의외입니다. 직접 재보고 알았어요.

고정 헤더가 있는 긴 폼에서 **Tab으로 아래로 내려갈 때는 가려지지 않습니다.** 브라우저가 요소를 화면에 넣어줄 때 최소한만 스크롤하는데, 아래로 갈 때는 요소의 아래쪽을 화면 밑변에 맞추거든요. 헤더는 위에 있으니 안 걸립니다.

**문제는 Shift+Tab으로 되돌아올 때입니다.** 이번엔 요소의 위쪽을 화면 윗변에 맞추는데, 거기가 바로 고정 헤더가 떠 있는 자리예요. 입력칸이 헤더 뒤로 완전히 숨습니다.

| 이동 방향 | `scroll-padding` 없음 | `scroll-padding-top: 56px` |
|---|---|---|
| Tab (아래로) | 0% 가림 | 0% 가림 |
| Shift+Tab (위로) | **100% 가림** | 0% 가림 |

같은 폼에서 헤더 높이를 56px로 두고 잰 값입니다. 아래로만 눌러보고 "괜찮네" 하고 넘어가기 쉬운 이유가 여기 있습니다.

고칠 때는 헤더 스타일이 아니라 **스크롤 컨테이너** 쪽을 건드립니다.

```css
/* 고정 헤더 — 이 자체는 문제가 아니다 */
.site-header {
  position: sticky;
  top: 0;
  z-index: 100;
  height: 56px;
}

/* 개선: 브라우저가 요소를 보여주려 스크롤할 때 위쪽에 헤더만큼 비워둔다 */
html {
  scroll-padding-top: 56px;
}
```

`scroll-padding-top`은 "스크롤해서 뭔가를 보여줄 때 이만큼은 안전지대로 남겨둬라"는 뜻입니다. 페이지 전체가 스크롤되면 `html`에 주고, 특정 영역만 자체 스크롤한다면 그 컨테이너에 줍니다.

```css
/* 영역 안에서만 스크롤되는 경우 — 컨테이너에 준다 */
.form-panel {
  overflow-y: auto;
  scroll-padding-top: 56px;
}
```

값은 헤더 높이와 맞춰야 하는데, 손으로 두 군데 적으면 나중에 어긋납니다. 변수로 묶어두는 편이 안전합니다.

```css
:root { --header-h: 56px; }

.site-header { height: var(--header-h); }
html { scroll-padding-top: var(--header-h); }
```

하단에 쿠키 배너나 상담 위젯을 띄운다면 `scroll-padding-bottom`도 같이 챙기세요. 아래쪽 장애물은 반대로 **Tab으로 내려갈 때** 가립니다.

## 2.5.7 Dragging Movements — 드래그에는 클릭 대안이 있어야 합니다

리스트 순서 바꾸기, 슬라이더 값 조절, 캔버스에서 도형 옮기기. 이런 인터랙션은 대부분 드래그로 구현합니다. 문제는 드래그가 **정밀한 연속 동작**이라는 점이에요. 손 떨림이 있거나 마우스 대신 스위치·헤드 포인터를 쓰는 사용자에게 드래그는 버튼 클릭보다 훨씬 어렵습니다.

**2.5.7**은 드래그로만 되는 기능에 **단일 포인터 조작**(클릭·탭 한 번)으로도 같은 결과를 낼 수 있는 대안을 요구합니다. 드래그를 없애라는 게 아니라, 못 해도 같은 일을 할 수 있게 하라는 뜻이에요.

{{< img src="images/contents/dragging-alternative.png" alt="2.5.7 비교 도해 - 왼쪽은 드래그 핸들만 있어 Tab 키가 목록을 그냥 지나치는 모습이고, 오른쪽은 항목마다 위·아래 이동 버튼이 있어 키보드로 순서를 바꿀 수 있으며 변경 결과가 라이브 영역으로 안내되는 모습입니다" caption="<a href='https://isaaceryn.github.io/demo_codes/wcag22-new-criteria/#dragging-movements' target='_blank' title='새 창에서 열림'>직접 눌러보기</a> — 위쪽 목록을 키보드로 정렬해보세요" >}}

흔히 보는 위반 형태는 이렇습니다.

```html
<!-- 위반: 드래그로만 순서를 바꿀 수 있다 -->
<ul id="tasks">
  <li><span class="handle" draggable="true">⠿</span> 보고서 초안</li>
  <li><span class="handle" draggable="true">⠿</span> 예산 검토</li>
</ul>
```

`<span>`은 원래 포커스를 받지 않습니다. `draggable`을 붙여도 마찬가지예요. 키보드로는 이 핸들에 닿을 방법조차 없으니, 순서를 바꾸는 기능이 통째로 사라진 셈입니다.

그런데 이 기준의 무게는 키보드 하나에 그치지 않습니다. **HTML 드래그는 터치에서 아예 동작하지 않습니다.** `dragstart`·`dragover` 같은 이벤트가 손가락 조작으로는 발생하지 않아요. 폰이나 태블릿에서 이 목록을 열면 아무리 눌러 끌어도 반응이 없습니다.

정리하면 이렇습니다.

| 입력 수단 | 드래그 전용 목록에서 |
|---|---|
| 마우스 | 된다 |
| 키보드 | 핸들에 포커스가 안 가서 불가 |
| 스크린 리더 | 조작할 대상 자체가 없음 |
| 터치 (폰·태블릿) | HTML 드래그 이벤트가 안 뜸 |

**되는 건 마우스뿐입니다.** 2.5.7이 "손 떨림이 있는 사용자를 위한 기준"으로만 소개되곤 하는데, 실제로는 **폰으로 접속한 모든 사람**이 걸립니다. 터치 드래그를 지원하려면 포인터 이벤트로 따로 구현해야 하는데, 그 수고를 들일 거라면 버튼 대안을 먼저 만드는 편이 훨씬 쌉니다.

대안은 버튼입니다. 마크업부터 보겠습니다.

```html
<ul id="tasks">
  <li>
    <span class="handle" draggable="true" aria-hidden="true">⠿</span>
    <span class="name">보고서 초안</span>
    <button type="button" class="move" data-dir="up" aria-label="보고서 초안 위로 이동">↑</button>
    <button type="button" class="move" data-dir="down" aria-label="보고서 초안 아래로 이동">↓</button>
  </li>
  <!-- 나머지 항목도 같은 구조 -->
</ul>
<p class="sr-only" role="status" aria-live="polite" id="order-status"></p>
```

세 가지가 의도적입니다.

**드래그 핸들에 `aria-hidden="true"`.** 마우스 사용자에게는 잡을 곳을 보여주되, 스크린 리더에는 읽히지 않게 합니다. "점 여섯 개"를 읽어줘야 좋을 게 없거든요. 실제 조작 수단은 아래 버튼입니다.

**버튼 `aria-label`에 항목 이름을 넣습니다.** 화살표만 있으면 스크린 리더는 "위로 이동 버튼"을 항목 수만큼 반복해서 읽습니다. 어느 항목의 버튼인지 알 수가 없어요.

**`role="status"`인 라이브 영역.** 순서가 바뀐 건 시각적으로는 바로 보이지만, 화면을 못 보는 사용자에게는 아무 일도 안 일어난 것처럼 느껴집니다. 결과를 말로 알려줘야 합니다.

동작 코드입니다. 이벤트 위임으로 목록 하나에만 걸어둡니다.

```javascript
const list = document.getElementById('tasks');
const status = document.getElementById('order-status');

list.addEventListener('click', (event) => {
  const button = event.target.closest('.move');
  if (!button) return;

  const item = button.closest('li');
  const goUp = button.dataset.dir === 'up';
  const sibling = goUp ? item.previousElementSibling : item.nextElementSibling;
  if (!sibling) return;                       // 이미 끝이면 아무 일도 하지 않는다

  goUp ? list.insertBefore(item, sibling)
       : list.insertBefore(sibling, item);

  button.focus();                             // DOM을 옮기면 포커스가 body로 튄다
  const position = [...list.children].indexOf(item) + 1;
  status.textContent = `${item.querySelector('.name').textContent}, ${position}번째`;
});
```

`button.focus()` 한 줄이 핵심입니다. **요소를 DOM에서 옮기면 그 안에 있던 포커스는 사라집니다.** 이걸 안 넣으면 버튼을 한 번 누를 때마다 포커스가 문서 맨 처음으로 돌아가서, 두 칸 올리려면 Tab을 처음부터 다시 눌러야 해요. 드래그 대안을 만들어놓고 정작 못 쓰게 되는 가장 흔한 실수입니다.

드래그 정렬 라이브러리를 쓰는 팀이라면 라이브러리를 걷어낼 필요는 없습니다. 위 버튼과 라이브러리의 정렬 API를 같은 함수에 연결하면 두 방식이 같은 결과를 냅니다. 라이브러리가 터치를 이미 처리해주고 있다면 그건 그대로 두시고, 버튼만 얹으면 됩니다.

## 2.5.8 Target Size (Minimum) — 버튼은 최소 24×24px

터치스크린에서 작은 아이콘 버튼을 누르려다 옆 버튼을 잘못 누른 경험, 다들 있으실 거예요. 손가락 굵기는 비슷한데 버튼은 자꾸 작아지는 게 프론트엔드 디자인의 오랜 딜레마입니다. 손 떨림이 있는 사용자에게는 이 딜레마가 "못 누른다"는 결과로 바로 이어지고요.

**2.5.8**은 이 딜레마에 숫자로 선을 긋습니다. 터치나 클릭으로 조작하는 타겟은 **최소 24×24 CSS px**은 돼야 한다는 거예요. 다만 예외가 넉넉합니다.

- **간격 확보**: 타겟 자체는 작아도, 인접 타겟과 충분히 떨어져 있어 24px 원이 겹치지 않으면 괜찮습니다.
- **동등한 대안**: 같은 페이지에 같은 기능을 하는 다른 컨트롤이 있고, 그쪽이 크기 기준을 충족하면 괜찮습니다.
- **인라인**: 문장 중간에 있는 링크처럼 텍스트 흐름 안의 타겟은 예외입니다.
- **사용자 설정**: 브라우저나 OS가 기본 제공하는 크기를 그대로 쓰는 경우입니다.
- **필수적인 경우**: 지도 위 정밀 확대·축소 컨트롤처럼 작은 크기가 기능상 꼭 필요한 경우입니다.

{{< img src="images/contents/target-size.png" alt="2.5.8 비교 도해 - 왼쪽은 16px 버튼이 2px 간격으로 붙어 있어 24px 판정 원이 서로 겹치는 모습이고, 오른쪽은 같은 크기의 아이콘이지만 패딩으로 24px 영역을 확보해 판정 원이 겹치지 않는 모습입니다" caption="<a href='https://isaaceryn.github.io/demo_codes/wcag22-new-criteria/#target-size' target='_blank' title='새 창에서 열림'>직접 눌러보기</a> — 폰에서 열면 차이가 확실합니다" >}}

```css
/* 위반: 16×16px 버튼이 2px 간격으로 붙어 있다 */
.icon-button {
  width: 16px;
  height: 16px;
  padding: 0;
}
```

고치는 방법은 둘입니다. 상황에 따라 고르시면 됩니다.

**방법 1 — 버튼 자체를 키운다.** 가장 단순하고, 대부분 이걸로 충분합니다.

```css
.icon-button {
  display: inline-flex;      /* 아이콘을 가운데 두기 위해 */
  align-items: center;
  justify-content: center;
  min-width: 24px;           /* width가 아니라 min-width */
  min-height: 24px;
  padding: 4px;
}
```

`width` 대신 **`min-width`를 쓰는 게 요령**입니다. 글자가 길어지거나 사용자가 브라우저 글꼴 크기를 키웠을 때 버튼이 내용을 자르지 않고 늘어납니다. 고정 `width`에 `padding`을 더하는 방식은 `box-sizing` 설정에 따라 결과가 달라져서, 전역 리셋에 `border-box`가 걸린 프로젝트에서는 24px이 안 나옵니다.

**방법 2 — 보이는 크기는 그대로 두고 누르는 영역만 넓힌다.** 촘촘한 툴바처럼 레이아웃을 흔들면 안 되는 곳에 씁니다.

```css
.icon-button {
  position: relative;
  width: 16px;
  height: 16px;
}

/* 보이지 않는 히트 영역을 버튼 위에 덮어씌운다 */
.icon-button::after {
  content: "";
  position: absolute;
  inset: -4px;               /* 사방 4px씩 = 24×24px */
}
```

가상 요소는 레이아웃 흐름을 차지하지 않아서 **버튼 사이 간격이 그대로 유지됩니다.** 다만 인접 버튼끼리 히트 영역이 겹치면 위에 그려진 쪽이 클릭을 가져가니, 간격이 8px보다 좁으면 이 방법은 피하세요.

그리고 어느 쪽을 쓰든 **포커스 표시를 함께 챙겨야** 합니다. 히트 영역만 넓히면 키보드 사용자에겐 아무것도 달라지지 않거든요.

```css
.icon-button:focus-visible {
  outline: 2px solid currentColor;
  outline-offset: 2px;
}
```

> 24px은 **CSS 픽셀** 기준입니다. 기기 화면의 물리 픽셀이 아니에요. 그래서 고해상도 폰에서도 계산은 그대로입니다. 참고로 2.5.5(Target Size, Enhanced)는 AAA 등급에서 44×44px을 요구하는데, 애플과 구글의 디자인 가이드가 오래전부터 권해온 값이 그 근처(44~48px)라 실무에서는 24px을 하한, 44px을 목표로 잡는 팀이 많습니다.

## 3.2.6 Consistent Help — 도움 수단은 같은 자리에

여러 페이지를 도는 서비스에서 "문의하기" 링크가 어떤 페이지는 헤더에, 어떤 페이지는 푸터 맨 아래에 있다면 사용자는 도움이 필요할 때마다 그걸 다시 찾아야 합니다. 인지 장애가 있는 사용자나 저시력 사용자에게는 이 반복 탐색 자체가 큰 부담이에요.

**3.2.6**은 채팅 상담, 연락처 정보, FAQ 링크 같은 **도움 수단이 여러 페이지에 반복해서 나온다면, 같은 상대적 위치에 일관되게 배치**하라고 요구합니다. 코드보다는 배치 규칙에 가까운 기준이라, 체크리스트로 정리하면 이렇습니다.

- 사이트 전체에서 "도움받기" 관련 요소(챗봇 버튼, 문의 링크, FAQ 링크)의 위치를 한 곳으로 통일한다.
- 페이지마다 다른 컴포넌트를 쓰더라도, 다른 반복 콘텐츠(헤더·내비게이션) 대비 상대적 순서는 지킨다.
- 새 페이지 템플릿을 만들 때 이 위치 규칙을 디자인 시스템 문서에 남겨둔다.

디자인 시스템이 잘 갖춰진 팀이라면 이미 지키고 있을 가능성이 높은 기준입니다. 다만 여러 팀이 각자 페이지를 만드는 조직에서는 의외로 자주 깨집니다.

## 3.3.7 Redundant Entry — 이미 입력한 걸 또 묻지 않기

배송지 주소를 쓰고 나서 청구지 주소를 처음부터 다시 입력하라고 하는 폼, 다들 겪어보셨을 거예요. 손이 불편해서 타이핑 하나하나가 부담인 사용자나, 같은 정보를 다시 입력하는 게 인지적으로 힘든 사용자에게는 그냥 귀찮은 정도가 아니라 폼을 포기하게 만드는 장벽이 됩니다.

**3.3.7**은 같은 절차 안에서 사용자가 이미 입력한 정보를 다시 요구하지 말라고 합니다. 자동으로 채워주거나, 최소한 선택할 수 있게 해야 해요. 예외도 있습니다. 재입력 자체가 활동의 목적인 경우(예: 암기 연습), 보안상 재입력이 필요한 경우(예: 비밀번호 변경 확인), 이전에 입력한 정보가 더 이상 유효하지 않은 경우는 괜찮습니다.

{{< img src="images/contents/redundant-entry.png" alt="3.3.7 비교 도해 - 왼쪽은 배송지와 청구지를 각각 처음부터 입력하게 하는 폼이고, 오른쪽은 체크박스 하나로 이미 입력한 값을 그대로 채워주는 폼입니다. 채워진 칸은 disabled가 아니라 readOnly라 값이 서버로 전송되고 포커스도 받습니다" caption="<a href='https://isaaceryn.github.io/demo_codes/wcag22-new-criteria/#redundant-entry' target='_blank' title='새 창에서 열림'>직접 눌러보기</a> — 체크박스를 켜고 꺼보세요" >}}

```html
<label for="shipping-address">배송지 주소</label>
<input type="text" id="shipping-address" name="shippingAddress" autocomplete="shipping street-address">

<label>
  <input type="checkbox" id="same-as-shipping">
  청구지 주소가 배송지와 같습니다
</label>

<label for="billing-address">청구지 주소</label>
<input type="text" id="billing-address" name="billingAddress" autocomplete="billing street-address">
```

`placeholder`를 라벨 대신 쓰지 않고 `<label>`을 따로 둔 게 중요합니다. 플레이스홀더는 입력을 시작하면 사라져서, 다 채운 뒤에 "이 칸이 뭐였지?" 하고 되짚을 수가 없거든요.

```javascript
const sameAsShipping = document.getElementById('same-as-shipping');
const shipping = document.getElementById('shipping-address');
const billing = document.getElementById('billing-address');

sameAsShipping.addEventListener('change', () => {
  if (sameAsShipping.checked) {
    billing.value = shipping.value;
    billing.readOnly = true;        // disabled 아님 — 아래 설명 참고
  } else {
    billing.value = '';
    billing.readOnly = false;
  }
});
```

**`disabled`가 아니라 `readOnly`입니다.** 이 자리에서 `disabled`를 쓰는 코드를 자주 보는데, 두 가지가 깨집니다.

- `disabled` 필드의 값은 **폼 전송에 포함되지 않습니다.** 화면에는 주소가 채워져 있는데 서버는 빈 값을 받습니다.
- `disabled` 필드는 **탭 순서에서 빠지고** 스크린 리더도 대체로 건너뜁니다. 채워진 값을 확인하려는 사용자가 그 칸에 접근할 수 없어요.

`readOnly`는 값이 전송되고, 포커스도 받고, 읽을 수도 있습니다. 수정만 막힙니다. 여기서 원하는 게 정확히 그거예요.

체크를 풀 때 값을 비우는 것도 의도적입니다. 배송지 값이 남아 있으면 사용자가 지우고 다시 쓰는 수고를 하게 되거든요. 다만 이건 서비스 성격에 따라 갈리는 선택이라, 값을 남겨두고 편집하게 하는 쪽이 나은 경우도 있습니다.

## 3.3.8 Accessible Authentication (Minimum) — 로그인이 시험이 되면 안 됩니다

로그인 화면에 이미지 속 글자를 그대로 옮겨 적으라는 캡차가 있거나, 비밀번호 필드에 붙여넣기가 막혀 있어 손으로 일일이 타이핑해야 하는 경우가 있습니다. 이런 장치는 인지 장애가 있거나 기억력에 의존하기 어려운 사용자에게는 로그인 자체를 못 하게 만드는 벽이 됩니다. 로그인은 본인 확인 절차일 뿐인데, 부수적으로 기억력 시험을 통과해야 하는 셈이거든요.

**3.3.8**은 인증 절차가 **인지 기능 테스트**(기억해서 입력하기, 퍼즐 풀기, 필사하기 같은 것)에 의존하지 않아야 한다고 요구합니다. 다만 대안이나 보조 수단이 있으면 괜찮습니다. 비밀번호 붙여넣기를 허용하거나 비밀번호 관리자를 지원하는 것도 이 보조 수단에 해당해요. 최소 등급에는 예외도 둘 있습니다. 사물을 알아보는 테스트(예: 이미지 중에서 자동차 고르기)와, 사용자가 직접 제공한 비텍스트 콘텐츠(예: 본인이 올린 사진)를 알아보는 테스트는 허용됩니다.

```html
<!-- 위반: 붙여넣기를 강제로 막아 비밀번호 관리자 사용을 방해 -->
<input type="password" onpaste="return false" onCopy="return false">
```

```html
<!-- 개선: 붙여넣기 허용 + 브라우저·비밀번호 관리자 자동완성과 호환 -->
<input type="password" name="password" autocomplete="current-password">
```

`onpaste="return false"`는 예전엔 "보안 강화"로 여겨지던 관행인데, 지금 기준으로는 오히려 접근성을 해치는 패턴입니다. 비밀번호 관리자를 쓰는 사용자에겐 이 한 줄이 로그인 자체를 막아버리거든요.

## AAA 등급 3개는 짧게

나머지 3개는 최고 등급인 AAA에 속해서, 웹 서비스 대부분이 목표로 삼는 AA보다 요구 수준이 높습니다. 실무에서 바로 준수 목표로 잡는 경우는 적지만, 이름 정도는 알아두면 좋습니다.

- **2.4.12 Focus Not Obscured (Enhanced)**: 앞서 본 2.4.11의 강화판입니다. 포커스된 요소가 일부라도 가려지면 안 됩니다.
- **2.4.13 Focus Appearance**: 포커스 표시(아웃라인 등)의 최소 크기와 대비를 구체적인 수치로 요구합니다.
- **3.3.9 Accessible Authentication (Enhanced)**: 3.3.8의 강화판입니다. 대안·보조 수단이 있으면 되는 구조는 같지만, 최소 등급에서 허용되던 사물 인식·사용자 제공 콘텐츠 인식 예외가 사라집니다.

## 조용히 사라진 기준 하나

이번 개정에서 늘어나기만 한 건 아닙니다. 기존에 있던 **4.1.1 Parsing**(마크업이 명세대로 유효해야 한다는 기준)은 2.2에서 **폐기·삭제**됐습니다. 표준 본문에도 이 기준의 제목 옆에 "Obsolete and removed"라고 붙어 있어요.

이유는 짐작이 아니라 표준이 직접 밝혀둔 내용입니다. 원래 이 기준은 보조기술이 HTML을 **직접 파싱**하면서 생기던 문제를 다루려고 채택된 것인데, 이제는 보조기술이 HTML을 직접 파싱할 필요가 없어졌다는 겁니다. 그래서 그 문제들은 더 이상 존재하지 않거나 다른 기준에서 이미 다뤄지고 있고, 이 기준은 쓸모를 잃었다는 설명이에요. 9개가 늘고 1개가 빠졌으니 순증가는 8개인 셈입니다.

다만 오해하지 마셔야 할 게, 이건 "마크업을 대충 짜도 된다"는 뜻이 아닙니다. 중복 `id`나 잘못 닫힌 태그가 접근성 트리를 망가뜨리면 여전히 **4.1.2 Name, Role, Value**나 **1.3.1 Info and Relationships**에서 걸립니다. 검사 항목 하나가 사라졌을 뿐, 유효한 마크업이 주는 이득은 그대로예요.

## KWCAG 2.2에는 어떻게 반영됐나

국내 표준 KWCAG 2.2의 전체 구조는 [완전 해설 글]({{< relref "/posts/kwcag-22-guide" >}})에 정리돼 있고, 여기서는 이번 6개 기준과의 대응 관계만 봅니다.

한국 기준인 **KWCAG 2.2**는 2022년 12월 28일 개정되면서 지금 다룬 흐름의 일부를 이미 담아뒀습니다. 조항 번호를 1:1로 맞추기보다는, 어떤 개념이 대응되는지 정도로 정리하는 게 정확합니다.

| WCAG 2.2 성공기준 | KWCAG 2.2에 대응되는 검사항목 |
|---|---|
| 3.3.8 접근 가능한 인증 | 7.3.3 접근 가능한 인증 |
| 3.2.6 일관된 도움 | 7.2.2 찾기 쉬운 도움 정보 |
| 3.3.7 반복 입력 정보 | 7.3.4 반복 입력 정보 |
| 2.5.7 드래그 동작 | 6.5.1 단일 포인터 입력 지원 |

네 항목 모두 2022년 개정에서 새로 들어온 9개 신규 검사항목에 포함돼 있습니다. 다만 문구가 1:1로 똑같지는 않으니, 개념이 겹친다는 정도로 읽어주세요. 국내 프로젝트를 KWCAG 기준으로 준비 중이라면 이 개념들이 이미 검사 대상에 들어와 있다고 보면 됩니다. 정확한 조항 문구는 NIA 표준심사지침에서 확인하세요. 인증 절차 자체는 [웹 접근성 품질인증 준비 가이드]({{< relref "/posts/web-accessibility-certification-guide" >}})에서 서면심사부터 통과선까지 따로 정리해뒀습니다.

## 글로벌 현황: 세계는 어디까지 왔나

유럽에서는 EU 조달·적합성 추정에 쓰이는 **EN 301 549** 표준이 움직이고 있습니다. 현재 공식 적용 중인 V3.2.1(2021년)은 아직 WCAG 2.1 기준이지만, 2025년 11월에 나온 V4.1.0 초안은 **WCAG 2.2 AA로 정렬**돼 있습니다. 이 초안이 참조하는 것도 앞서 말한 2024년 12월 12일자 개정 권고안이에요. 웹(9절)뿐 아니라 비웹 문서(10절)·소프트웨어(11절) 요구사항까지 함께 맞춰졌습니다. 최종본이 EU 관보(OJEU)에 실리는 시점을 두고 상용 소스들은 2026년 10월경을 언급하지만, 이건 신뢰도가 낮은 정보라 참고만 하시길 권합니다. 방향 자체는 분명합니다 — 유럽은 2.2 쪽으로 가고 있어요.

미국은 사정이 다릅니다. 2024년 확정된 ADA(미국장애인법) Title II 웹 규칙은 2.2가 아닌 **WCAG 2.1 AA**를 기준으로 삼습니다. 준수 마감은 인구 5만 명 이상 지자체는 2027년 4월 26일, 그 외는 2028년 4월 26일인데, 2026년 4월 DOJ의 잠정 최종 규칙으로 원래 일정보다 1년 늦춰졌습니다. 연방기관 대상 Section 508은 더 오래된 WCAG 2.0 AA를 아직 쓰고 있고요.

정리하면 유럽은 2.2로 이동 중, 미국은 아직 2.1(연방기관은 2.0)에 머물러 있습니다. 어느 시장을 주로 상대하느냐에 따라 지금 맞출 기준이 달라진다는 뜻이에요.

## 한 장 요약

- WCAG 2.2는 2023년 10월 5일 권고안 확정(현재 문서는 2024년 12월 12일 개정 권고안), 신규 성공기준 **9개 추가 + 4.1.1 Parsing 폐기·삭제**.
- 실무 비중 큰 A·AA 6개: **2.4.11**(포커스 가림 금지) · **2.5.7**(드래그 대안) · **2.5.8**(타겟 24×24px) · **3.2.6**(도움 위치 일관성) · **3.3.7**(반복 입력 금지) · **3.3.8**(인지 테스트 없는 인증).
- **드래그 전용 UI는 마우스 사용자만 쓸 수 있습니다.** HTML 드래그는 터치에서 이벤트가 뜨지 않아 폰 사용자까지 막힙니다.
- AAA 3개(2.4.12·2.4.13·3.3.9)는 위 기준들의 강화판 — 대부분 서비스는 AA까지가 현실적 목표.
- **KWCAG 2.2**(2022-12-28 개정)가 인증·도움정보·반복입력·단일포인터 흐름을 이미 일부 선반영.
- 유럽 **EN 301 549**는 2.2 AA로 정렬 중, 미국 ADA는 아직 **2.1 AA**(연방기관 Section 508은 2.0) — 대상 시장에 따라 목표 기준이 다릅니다.

{{< faq >}}

## 참고 자료

- [WCAG 2.2 신규 기준 체험 페이지 (데모)](https://isaaceryn.github.io/demo_codes/wcag22-new-criteria/)

- [WCAG 2.2 (W3C Recommendation, 2023-10-05 확정 / 2024-12-12 개정 권고안)](https://www.w3.org/TR/WCAG22/)
- [웹 접근성 품질인증, 지금 어떻게 받나]({{< relref "/posts/web-accessibility-certification-guide" >}})
- [키보드 접근성 A to Z: 모든 사용자가 키보드로 사용할 수 있는 웹사이트 만들기]({{< relref "/posts/keyboard-accessibility-a-to-z" >}})
- [폼 접근성 마스터하기: 모든 사용자를 위한 입력 양식 설계]({{< relref "/posts/form-accessibility-mastery" >}})