드디어 출시된 WCAG 22 새 기능 및 변경 사항 정리

드디어 출시된 WCAG 22 새 기능 및 변경 사항 정리
Cozy CodingPosted On Jul 12, 20248 min read

새로운 WCAG 표준은 무엇입니까?

image

저자의 주: 2023년 10월 5일, W3C는 WCAG 2.2를 권고안으로 발표했습니다. 따라서 WCAG 2.2가 현재 공식 표준으로 채택되었습니다. 이 노트를 제외하고는 본 문서를 수정하지 않겠습니다.

대단히 오래 기다려진 WCAG 2.2 표준이 현재 W3C의 "제안 권고안"입니다. 이것은 "권고안"이 되기 전 과정으로, 곧 새로운 W3C 공식 접근성 가이드라인이 됩니다. 이제 W3C의 공식 투표만 남았습니다. 이 투표는 2023년 8월 19일에 종료되었다고 합니다 (출처).

그래서, 거의 다 정해졌나봐요. 편집자 초안도 확인해 봤는데, 발표된 초안과 별 다를 게 없네요. 다시 말해, 앞으로 바뀔 내용은 없는 것 같아요. “환호와 격려”를 준비하세요!

2021년 12월에 WCAG 2.2의 새로운 기준을 자세히 설명하는 기사를 썼었죠. 그 이후로, 몇 가지 추가 기준이 생겼고 일부는 이동되었어요.

WCAG 2.2의 번호 매기기

이전에는 기준들이 각각의 수준에 따라 순서가 매겨졌었어요. 하지만 W3C는(내 의견으로는 현명한 선택이었죠) 존재하는 기준에 추가하기만 해서 번호 충돌과 기존 WCAG 2.1 기준과의 혼란을 피하는 것이 가장 나을 것이라고 결정했어요.

성공 기준 졸업반

새로운 기준 목록입니다. 모두의 이름을 다 부르기 전에 박수는 나중에 해주세요.

  • 성공 기준 2.4.11 초점 가려지지 않음 (최소) (수준 AA)
  • 성공 기준 2.4.12 초점 가려지지 않음 (향상) (수준 AAA)
  • 성공 기준 2.4.13 초점 모양 (수준 AAA)
  • 성공 기준 2.5.7 드래깅 움직임 (수준 AA)
  • 성공 기준 2.5.8 대상 크기 (최소) (수준 AA)
  • 성공 기준 3.2.6 일관된 도움말 (수준 A)
  • 성공 기준 3.3.7 중복된 입력 (수준 A)
  • 성공 기준 3.3.8 접근 가능한 인증 (최소) (수준 AA)
  • 성공 기준 3.3.9 접근 가능한 인증 (향상) (수준 AAA)

모두 살펴보겠습니다.

성공 기준 2.4.11 포커스 가려지지 않음 (최소) (등급 AA)

나는 올해 초에 이 새로운 기준에 관한 기사를 썼어 (2023년). 내가 알기로는 그 때부터 아무 변화가 없는 것 같아; 그래도 링크를 클릭하지 않아도 되게끔 내용을 알려줄게.

간단히

포커스 표시기(탭 키를 몇 번 누르면 텍스트 상자/버튼/링크 주변에 나타나는 그 화려한 거 아시지?)와 포커스된 요소는 사용자에게 완전히 숨겨져서는 안 돼요.

여기서 이해할 수 있나요? 요소가 초점을 가지고 있다면 시각적 사용자는 그 놈을 볼 수 있어야 합니다.

위반 예시:

  • 초점을 받는 요소를 가리는 "붙는" 또는 고정된 푸터
  • 열릴 때 초점을 받지 않는 모달

누구에게 도움이 되나요?

  • 페이지를 이동할 때 키보드를 사용하는 시각이 있는 사람
  • 시력이 제한되거나 낮은 사람
  • 주의, 기억 및 실행 처리에 제한이 있는 사람들

이것은 AA 수준의 기준입니다. 따라서 WCAG(웹 콘텐츠 접근성 지침)을 준수하려면 이 기준을 준수해야 합니다.

성공 기준 2.4.12 초점이 가려지지 않음(향상됨)(레벨 AAA)

SC 2.4.12에서 대부분 다루었기 때문에 굳이 이 부분에 들어갈 필요가 없습니다. 본질적으로 이 레벨 AAA SC는 초점 표시기와 초점을 받는 요소가 전혀 가려지지 않도록 하는 반면 SC 2.4.11은 일부가 가려져도 괜찮습니다.

성공 기준 2.4.13 초점 모양 (레벨 AAA)

이 SC를 이전 게시물에서 언급했었고, 그들이 문구를 업데이트했으면 좋겠다고 희망했습니다. 다행히 그들이 업데이트했습니다.

간단히 말하면,

초점 표시기 색상은 색상 대비 비율이 배경과 3:1 이상이어야 하며, 네 방향의 모든 측면에서 최소 2픽셀 두께의 테두리만큼 커야 합니다.

예를 들어, 백그라운드가 흰색인 페이지의 버튼에 파란색 (#0000FF) 포커스 지시기가 적용되어 있고 두께가 2픽셀이며 버튼을 둘러싼 경우, 이것은 확실히 준수하고 있습니다.

가끔 개발자들은 버튼의 포커스 여부를 나타내기 위해 색상을 변경할 수 있습니다. 포커스를 갖는 버튼과 포커스를 갖지 않는 버튼 간에 3:1의 색상 대비 비율이 유지된다면 이는 완벽히 허용됩니다.

위반 사례 예시:

  • 포커스 지시기가 컨트롤 아래에 2픽셀 라인으로 표시됨
  • 포커스 지시기와 배경 간의 색상 대비 비율이 3:1보다 낮음
  • 포커스 지시기의 배경 색상 값이 CSS에서 적합하지만 낮은 투명도를 사용하여 색상이 비준수적인 경우. 이를 확인하기 위해 일종의 색상 체커를 사용해야 합니다. 이는 종종 자동 접근성 도구를 우회하게 됩니다.
  • Medium의 헤더 컨트롤. 아래 이미지에서 Medium의 "새 이야기" 페이지의 헤더의 스크린샷 다섯 개가 있습니다. 포커스를 갖는 컨트롤이 어느 것인지 알아내기 어렵다는 것을 보실 수 있나요?

Image

  • 현재(기사 작성 시점 기준) 구글 크롬과 마이크로소프트 엣지의 텍스트 상자 구현은 모두 1px 두께의 outset 테두리를 사용합니다.

누구를 도와주나요?

  • 페이지 탐색에 키보드를 사용하는 시각적인 사람들
  • 시력이 제한되거나 낮은 사람들
  • 주의력, 기억력 및 실행 기능이 제한된 사람들

조금 실망스러운데, 이 SC가 Level AA 인증을 받지 못했다는 사실을 말해야겠어요. 웹 저자들이 Level AAA에 호환이 가능한 콘텐츠를 만들려는 경우는 드물죠. 이 SC의 Level AA 버전이 있었으면 더 좋았을 텐데, 심사 기준이 덜 엄격한 버전이라도 말이에요.

위 스크린샷 중 Level AA 인증을 받은 것은(접근성은 제외하고, 인증만 받은 것입니다) 사용자 버튼이 초점을 맞춘 화면을 제외한 나머지입니다. 이는 SC 2.4.7 "포커스 표시 가능"을 위반합니다.

성공 기준 2.5.7 드래깅 동작 (Level AA)

간단한 용어로 정리하면

사용자에게 끌어서 이동하는 동작 수행을 강요해서는 안 됩니다. 이는 컨트롤이 끌어서 이동 기능을 가져야 하지 않는다는 것을 의미하는 것이 아닙니다. 사용자가 컨트롤과 상호 작용할 수 있는 유일한 방법이 끌어서 이동하는 것일 수는 없다는 것뿐입니다.

위반 예시:

  • 사용자가 물건을 끌어서 재정렬할 수 있도록 하는 목록 상자이지만, 다른 방법으로 재정렬할 수 없는 경우
  • 값을 변경하기 위해 끌어서 이동을 허용하는 슬라이더 컨트롤이지만, 키보드 또는 단일 클릭을 사용하여 값 변경을 허용하지 않는 경우

이것은 누구에게 도움이 될까요?

  • 손재주가 있는 사람들
  • 웹 콘텐츠와 상호 작용하기 위해 마우스를 사용하지 않는 사람들

성공 기준 2.5.8 대상 크기(최소) (수준 AA)

일반어

클릭 가능한 모든 컨트롤이 적어도 지름 24픽셀 크기의 원과 같게 만드세요. 다른 컨트롤과의 간격에 따라 예외사항이 있을 수 있지만 — 여러분, 제어요소를 그렇게 작게 만들 이유는 없잖아요.

위반 사례:

  • 서로 바로 옆에 있는 (여백/패딩 없음) 네비게이션 바의 버튼이 폭과 높이가 23픽셀인 경우
  • 선택 컨트롤에서 옵션이 높이가 24픽셀 미만인 경우

이것이 누구에게 도움이 되나요?

  • 기능 저하 도전을 가진 사람들
  • 시력이 낮은 사람들
  • 모바일 기기를 사용하는 사람들

테이블 태그를 마크다운 형식으로 변경해주세요.

도움말 기능이 있으면 모든 페이지에서 본질적으로 동일한 위치에 있어야 합니다. 예를 들어, "도움말 기능"은 단순한 연락처 정보 링크일 수도 있습니다. 이 링크는 페이지에 나타날 때마다 항상 동일한 위치에 있어야 합니다. 일반적으로 페이지 상단에 일관된 내비게이션 바가 있는 경우 이렇게 됩니다.

물론, 챗봇이나 다른 강력한 도움 기능이 있는 경우에도 동일한 상대적인 위치에 있어야 합니다.

다만, 이 SC는 도움말 기능을 가져야 한다는 것이 아니라, 도움 기능이 있는 모든 페이지에서 일관된 위치에 있어야 한다는 것입니다.

  • "Contact" 링크는 한 페이지의 네비게이션 바에 있고, 다른 페이지에서는 페이지 본문에만 있습니다.
  • 도움 챗봇을 열기 위한 버튼은 한 페이지의 푸터에 나타나지만, 다른 페이지에서는 측면 네비게이션 섹션에 나타납니다.

누구를 도와주나요?

  • 인지적 도전을 겪는 사람들에게

성공 기준 3.3.7 중복 항목 (수준 A)

간단히 말해서, 사용자가 여러 단계로 이뤄진 양식과 같은 프로세스를 진행 중인 경우, 동일한 프로세스에서 이미 입력한 정보를 다시 입력할 필요가 없어야 합니다. 정보가 이미 입력되었지만 더 이상 유효하지 않거나 보안 요구를 충족하기 위해 필요한 정보인 경우를 제외하고요.

가장 흔한 예로는 사용자가 제품을 구매하고 배송 주소를 입력한 후 사이트가 청구 주소를 요구하는 경우가 있습니다. 다행히 대부분의 주요 쇼핑 사이트에는 사용자가 청구 주소를 입력하지 않고도 배송 주소와 동일하다는 체크박스나 버튼이 있습니다.

물론, 이 규칙은 암호를 두 번 입력해야 하는 비밀번호 재설정 페이지와 같은 경우에는 적용되지 않습니다.

위반 사례:

  • 다단계 프로세스에서 사용자가 이전에 입력한 정보를 다시 입력해야 하는 경우
  • 사용자가 텍스트 상자에 텍스트를 입력하고 버튼을 클릭하여 사이트에서 검색을 수행한 후, 다음 페이지에서 검색 결과가 표시되지만 텍스트 상자가 비어 있거나 사용자가 입력한 텍스트와 다른 텍스트가 표시되는 경우

누구에게 도움이 되나요?

  • 인지나 기억에 도전이 있는 사람들
  • 키보드 이외의 입력 장치를 사용하는 사람들

이것은 WCAG 준수를 위해 만족해야 하는 Level A 기준입니다.

성공 기준 3.3.8 접근 가능한 인증 (최소) (Level AA)

간단한 언어로

사용자가 브라우저의 자동 입력 기능을 사용하여 필수 암호를 입력할 수 있도록 허용합니다. 사용자가 암호 필드에서 가려진 문자와 가려지지 않은 문자 사이를 전환할 수 있도록 허용합니다. 사이트에서 검증 코드를 사용한 이중 인증을 구현한 경우, 사용자가 코드를 붙여 넣을 수 있도록 허용합니다. QR 코드, USB 기반 방법 또는 사용자의 지문이 필요한 전화 알림을 사용한 이중 인증을 구현한 경우, 정상적으로 작동합니다.

기본적으로 사용자가 기억력이나 계산 능력을 사용하지 않고 입력해야 하는 요구는 없어야 합니다.

이 기준은 실제로 무엇을 전달하려고 하는지를 쉽게 이해할 수 있도록 작성되어야 합니다. 이 기준을 처음 볼 때, '로봇이 아님' (CAPTCHA) 테스트에 대해 이야기하고 있구나 생각했습니다. 하지만 '인지 기능 테스트'는 비밀번호를 기억해야 하는 것을 포함합니다.

이 기준은 인증 프로세스의 모든 부분에 적용됩니다. "물체 인식"은 본질적으로 CAPTCHA 예시입니다. 사용된 물체는 가능한 한 보편적이어야 합니다. 예를 들어 "모든 비스킷을 선택하세요"는 미국과 영국 사람 중 서로 다른 항목을 선택할 가능성이 높습니다.

"개인 콘텐츠" 테스트의 예시는 사용자에게 애완동물의 이미지를 업로드하도록 요청하는 것입니다. 그런 다음 인증 프로세스의 일환으로, 사이트가 다양한 애완동물 이미지를 보여주며 사용자가 제출한 이미지 중 하나를 포함합니다. 사용자는 올바른 이미지를 선택하고 인증 프로세스의 다음 단계로 넘어갑니다.

여기 중요한 내용이에요: 사용자가 인증할 때 그들의 기억에 의존하지 않도록 요구하지 마세요. 무언가를 인식하는 능력을 사용하는 건 괜찮지만, 그걸 기억하는 데 의존하게 하지 마세요.

위반 예시:

  • JavaScript를 사용하여 사용자가 클립보드에서 비밀번호를 붙여넣는 것을 막는 경우
  • 사용자에게 수학 문제를 제시하여 계속하기를 요구하는 경우
  • 비밀번호 텍스트 상자의 autocomplete 속성을 current-password로 설정하지 않는 경우

이것이 누구에게 도움이 되나요?

  • 인지적 도전을 겪는 분들
  • 어려움을 겪는 분들, 예를 들어, 간질증 같은 독해 장애가 있는 분들

성공 기준 3.3.9 접근 가능한 인증 (고급) (수준 AAA)

이 성공 기준은 수준 AA에 해당하는 성공 기준(SC 3.3.8)과 동일하지만, Object Recognition 또는 Personal Content를 허용하지 않습니다.

이제 뭘 할까요?

회사에서 일하는 접근성 전문가라면 할 일이 좀 있어요. 이미 시작하지 않았다면 새로운 기준을 파이프라인에 구현하기 시작해보세요.

설득력을 부여하는 것을 잊지 마세요. 다시 말해, 새로운 기준이 무엇인지 팀에게 알려주는 것뿐만 아니라 그것이 어떤 목표를 이루려는 것이며 누구를 도와주는지 설명해야 해요 (그래서 각각에 그것을 포함했어요) 그리고 어떻게 하는지요.

각 기준의 끝에 링크도 제공했으니 더 깊이 이해할 수 있도록 살펴보세요.

2024-07-12-WCAG22Itsfinallyhere_2.png

WCAG 3.0에 대해 어떻게 생각하세요?

WCAG 3.0에 대해서는 기대가 됩니다만, 준비될 때까지는 오랜 시간이 걸릴 것으로 예상됩니다. 저의 첫 글 중 하나(2년 전에 작성)에서는 WCAG 3.0이 2023년까지 준비될 것이라고 언급했었는데, 얼마나 틀렸는지요! 만약 2025년에 나온다면 정말 놀랄 것입니다.

하지만 그것이 내일 나왔다 하더라도 걱정하지 마세요. WCAG 2.2와 3.0은 병렬 표준이 될 것입니다. 다시 말해, 한 가지에 대해 준수한다면 WCAG 준수를 할 수 있을 것입니다.

결론

이 기사가 도움이 되었기를 바랍니다. 웹을 보다 접근 가능한 곳으로 만드는 노력에 도움이 되기를 바랍니다. 접근성은 그냥 규정 준수가 아니라 목표입니다.

링크

WCAG

  • WCAG 2.2
  • 2023년 8월에 예정된 WCAG 2.2 최종 웹 표준
  • WCAG 2.2에서 새롭게 추가된 내용

내 관련 기사

  • WCAG 2.2 업데이트: 어떤 변화가 빨리 다가올지
  • WCAG 2.2: 중복 항목 — 의미와 준수 방법
  • WCAG 2.2: 시각적인 제어 요소 — 의미와 준수 방법
  • WCAG 2.2 초점이 가려지지 않음 — 최신 WCAG 표준 후보
  • WCAG 2.2가 다시 연기되었고, 나는 그것에 문제 없어요
  • WCAG 3.0: 접근성 표준의 미래에 대해 알아야 할 사항