성공 기준의 목적은 사용자가 기존 계정에 로그인할 때 인증할 수 있는 접근 가능하고, 사용하기 쉬우며, 안전한 방법을 보장하는 것이다.
가장 널리 사용되는 인증 방식으로, 웹사이트는 일반적으로 로그인할 때 사용자 이름과 비밀번호에 의존한다.
그러나 사용자 이름과 비밀번호를 기억하는 것은 특정 인지 장애인에게 매우 큰 부담이 되거나 불가능할 수 있다.
인증 과정에 흔히 추가되는 단계도 마찬가지다.예를 들어, 일회용 인증 코드를 옮겨 적거나 퍼즐을 풀도록 요구하는 경우가 있다.
웹사이트는 이 성공 기준을 충족하기 위해 객체 인식이나 사용자가 제공한 텍스트가 아닌 콘텐츠의 인식을 사용할 수 있다.
그러나 이러한 기법은 인지 장애가 있는 사람들을 완전히 지원하지 않으므로 가능하면 피해야 한다.
더 포용적이고 접근 가능한 방법에 대한 지침은 접근 가능한 인증(향상된)을 참조한다.
이 성공 기준은 기존 사용자의 인증에 초점을 둔다.
사용자 이름을 생성하거나 계정을 개설하는 것은 다루지 않는다.
많은 웹사이트에서 최초 사용자 이름과 인증 정보를 설정하는 과정은 해당 사용자 이름으로 로그인하는 과정과 크게 다르지 않을 수 있다.
이 기준을 충족하기 위해 사용하는 기법(특히 입력 필드에 붙여넣기를 허용하고 옮겨 적기에 의존하지 않는 것)은 계정 생성 과정의 인지적 부담도 줄일 수 있다.
그러나 이 성공 기준은 사용자가 로그인하거나 다른 방법으로 계정을 인증할 때마다 이전에 제공한 정보를 기억해야 하는 지속적인 필요성을 줄이는 데 초점을 둔다.
사이트별 비밀번호를 기억하는 것은 인지 기능 검사이다.
이러한 검사는 많은 인지 장애인에게 문제가 되는 것으로 알려져 있다. 무작위 문자열을 기억하는 것이든, 터치스크린에서 수행할 패턴 제스처를 기억하는 것이든, 인지 기능 검사는 일부 사람들을 배제한다.
인지 기능 검사를 사용하는 경우, 인지 기능 검사가 아닌 다른 인증 방법을 하나 이상 제공해야 한다.
일부 캡챠 시스템은 화면에 표시된 텍스트에 대한 오디오 대체 수단을 제공한다.
사용자가 이 오디오를 옮겨 적어야 한다면 대체 방법 예외를 충족하는 데 사용할 수 없다.
그림 1. 왜곡된 텍스트의 문자를 입력하도록 요구하는 캡챠와 텍스트 필드 아래의 “오디오 대체 수단” 버튼.
인증 과정에 다단계 인증과 같이 둘 이상의 단계가 있는 경우, 이 성공 기준을 충족하려면 모든 단계가 이 성공 기준을 준수해야 한다.
인지 기능 검사에 의존하지 않고 인증을 완료할 수 있는 경로가 있어야 한다.
이메일과 비밀번호를 복구하거나 변경할 수 있는 것은 인증의 중요한 부분이다.
사용자가 계정을 복구하기 위해 대체 정보로 인증하는 경우, 인지 기능 검사가 아닌 방법이 있어야 한다.
많은 조직에서는 사용자의 신원을 확인하기 위해 서로 독립적인 수단을 결합하는 2단계 인증을 사용해야 한다.
이러한 수단은 다음과 같은 인증 방식을 조합하여 구성할 수 있다.
지식(예: 비밀번호, 암호 문구의 문자 또는 기억한 스와이프 경로 등)
소유(예: 기기에서 생성하거나 수신한 인증 코드 또는 외부 기기에서 QR 코드 스캔 등)
생체정보(예: 지문 인식, 얼굴 인식 또는 키 입력 패턴 등)
대부분의 지식 기반 인증 방법은 인지 기능 검사에 의존하므로, 사용자를 지원하는 메커니즘을 제공해야 한다.
별도의 기기에서 작업을 수행하는 방식에 인증이 의존하는 경우, 정보를 옮겨 적지 않고도 해당 작업을 완료할 수 있어야 한다.
사용자가 어떤 기기 기반 인증 방법을 사용할 수 있는지 알 수 없을 수 있다.
여러 방법을 선택할 수 있도록 제공하면 사용자가 자신에게 가장 적합한 경로를 선택할 수 있다.
웹사이트는 사용자 에이전트(브라우저)와 서드파티 비밀번호 관리자가 필드를 채울 수 있도록 작성자가 허용하는 경우, 사용자 이름(또는 이메일)과 비밀번호 입력 필드를 인증 방법으로 사용할 수 있다.
일반적으로 로그인 양식이 성공 기준 1.3.5 입력 목적 식별을 충족하고, 양식 컨트롤이 성공 기준 4.1.2 이름, 역할, 값에 따라 적절한 접근 가능한 이름을 가지고 있다면, 사용자 에이전트와 비밀번호 관리자는 해당 필드를 안정적으로 인식하고 자동으로 채울 수 있어야 한다.
그림 2. 붙여넣기를 차단하고, 사용자에게 비밀번호를 직접 입력하라는 오류 메시지를 표시하는 비밀번호 입력 필드.
그러나 사용자 에이전트와 비밀번호 관리자가 필드를 채우지 못하도록 적극적으로 차단하거나(예: 스크립트를 사용하여 양식 필드가 자동으로 채워지는 것을 방지하는 경우), 사용자가 복사 및 붙여넣기를 하지 못하도록 막는 경우(독립형/외부 서드파티 비밀번호 관리자에 의존하는 경우), 대체 방법을 제공하지 않는 한 해당 페이지는 이 기준을 충족하지 못한다.
복사 및 붙여넣기를 사용하여 옮겨 적는 것을 피할 수 있다.
사용자는 로컬 소스(예: 독립형 서드파티 비밀번호 관리자)에서 로그인 인증 정보를 복사하여 로그인 양식의 사용자 이름과 비밀번호 필드 또는 비밀번호를 요구하는 웹 기반 명령줄 인터페이스에 붙여넣을 수 있다.
그림 3. 6자리 코드의 각 숫자를 별도의 입력 필드에 입력해야 하는 시간 기반 일회용 비밀번호(TOTP) 인증. 전체 코드를 붙여넣으려고 하면 첫 번째 입력 필드에 한 자리 숫자만 입력된다.
그림 4. 비밀번호의 특정 숫자(첫 번째, 세 번째, 다섯 번째 숫자)를 입력하도록 요구하는 비밀번호 입력 양식.
인증 필드에 붙여넣는 것을 차단하거나(로그인 양식의 예 참조), 복사한 텍스트와 입력 필드에 서로 다른 형식을 사용하는 경우(예: “비밀번호의 첫 번째, 세 번째, 다섯 번째 문자를 입력하세요”), 사용자가 정보를 옮겨 적어야 하므로 다른 방법을 제공하지 않는 한 이 기준을 충족하지 못한다.
사용자 이름과 비밀번호 외에도 일부 사이트에서는 2단계 인증을 사용하여 사용자에게 인증 코드(패스코드 또는 일회용 비밀번호라고도 함)를 입력하도록 요구할 수 있다.
인증 코드를 직접 옮겨 적도록 요구하는 서비스는 이 기준을 준수하지 않는다.
사용자 이름과 비밀번호의 경우와 마찬가지로, 사용자가 최소한 코드(예: 독립형 서드파티 비밀번호 관리자, 문자 메시지 애플리케이션 또는 소프트웨어 기반 보안 키에서 가져온 코드)를 붙여넣을 수 있어야 하며, 사용자 에이전트가 필드를 자동으로 채울 수 있도록 해야 한다.
인증 코드를 보조 기기에서 수신하거나 생성해야 하는 경우가 있다.
예를 들어 노트북의 웹 브라우저에서 인증할 때 휴대전화로 SMS 문자 메시지를 통해 전송된 인증 코드가 필요할 수 있다.
그러나 대부분의 경우 코드를 기본 기기로 직접 전송한 다음 복사하여 붙여넣을 수 있다(예를 들어 보조 기기에서 코드를 복사하여 기본 기기로 이메일을 보내거나, 보조 기기에서 복사한 콘텐츠를 기본 기기에서 붙여넣을 수 있는 기기 간 공유 클립보드를 사용할 수 있다).
코드를 보조 기기에서 기본 기기로 원활하게 전송할 수 있는지 여부를 평가하는 것은 이 성공 기준의 범위를 벗어난다. 이러한 유형의 보조 기기 시스템을 사용한 인증에 의존하는 웹 콘텐츠를 평가할 때는 사용자의 클립보드에서 코드를 사용할 수 있도록 하는 수단이 마련되어 있다고 가정한다. 따라서 이 기준을 평가할 때는 웹 콘텐츠가 관련 인증 입력 필드에 클립보드의 콘텐츠를 붙여넣을 수 있는지만 확인하면 된다.
코드에 의존하지 않는 2단계 인증 시스템은 인지 기능 검사가 아니라는 점에 유의한다.
여기에는 하드웨어 인증 장치(예: YubiKey), 로그인을 시도하는 사람이 실제 사용자인지 확인하도록 요구하는 보조 애플리케이션(동일한 기본 기기 또는 보조 기기에서 실행되는 경우 모두 포함), 사용자의 운영체제에서 제공하는 인증 방법(예: Windows Hello 또는 macOS와 iOS의 Touch ID/Face ID)이 포함된다.
캡챠가 인증 과정의 일부로 사용되는 경우, 예외에 해당하지 않는 한 인지 기능 검사를 포함하지 않는 방법이 있어야 한다.
웹사이트가 설정한 것을 기반으로 하는 테스트, 예를 들어 단어를 기억하거나 옮겨 적는 것 또는 웹사이트가 제공한 그림을 인식하는 것은 인지 기능 검사에 해당한다.
객체를 인식하거나 사용자가 이전에 제공한 그림을 인식하는 것도 인지 기능 검사이지만, AA 수준의 이 기준에서는 예외로 인정된다.
그러나 이러한 경우는 AAA 수준의 성공 기준 3.3.9 접근 가능한 인증(향상된)에서는 예외로 인정되지 않는다.
그림 5. 사용자에게 일반적인 객체를 인식하도록 요구하는 캡챠의 예. 이 경우 자동차가 포함된 모든 이미지를 선택하도록 요구한다.
이 문맥에서 객체는 일반적인 영어 정의인 “보고 만질 수 있는 물질적인 것”을 의미하며, 차량과 동물 등이 포함될 수 있다.
검사가 인식을 넘어서는 경우(예: 고양이의 수와 개의 수를 곱하는 경우)에는 예외에 해당하지 않는다.
일부 형태의 객체 인식에는 특정 문화에 대한 이해가 필요할 수 있다.
예를 들어 택시는 지역에 따라 다르게 보일 수 있다. 이는 장애인을 포함한 많은 사람에게 문제가 될 수 있지만, 접근성에만 해당하는 문제로 간주하지는 않는다.
인증에 사용되는 일부 캡챠와 인지 기능 검사는 광고 차단기가 있는 경우나 비밀번호를 반복해서 잘못 입력한 경우처럼 특정 상황에서만 나타날 수 있다.
이 기준은 이러한 검사가 매번 사용되는지 또는 특정 상황에서만 실행되는지와 관계없이 적용된다.
개인 콘텐츠는 인증의 두 번째 요소로 사용되기도 한다.
예를 들어 계정을 생성할 때 사용자가 사진을 업로드하고, 로그인할 때 여러 선택지 중에서 해당 사진을 선택하도록 요구할 수 있다.
이 경우 정당한 사용자가 아닌 사람도 선택지가 주어지면 올바른 개인 콘텐츠를 추측할 수 있으므로 적절한 보안을 제공하도록 주의해야 한다.
텍스트 기반 개인 콘텐츠는 인식이 아닌 기억에 의존하고, 항목 선택이 아닌 옮겨 적기에 의존하므로 이 예외에 해당하지 않는다.
사진 기반 개인 콘텐츠도 일부 사람에게는 여전히 장벽이 되지만, 텍스트 기반 방식은 훨씬 더 큰 장벽이 되는 경향이 있다.
입력할 때 문자를 숨기는 것도 인지적 부담을 증가시키는 또 다른 요인이 될 수 있다.
이 기준에서는 사용자가 비밀번호를 직접 입력(옮겨 적기)할 필요가 없어야 하지만, 비밀번호 관리자에 저장할 비밀번호를 생성하는 경우처럼 직접 입력해야 하는 상황도 있다.
비밀번호를 선택적으로 표시할 수 있는 기능을 제공하면 일부 인지 장애인이나 정확한 입력에 어려움이 있는 사람이 성공적으로 입력할 가능성을 높일 수 있다.
그림 6. 입력된 텍스트를 기본적으로 숨기는 비밀번호 필드와 비밀번호를 일반 텍스트로 표시하도록 전환할 수 있는 버튼.
웹사이트는 적절하게 마크업된 사용자 이름(또는 이메일)과 비밀번호 필드를 로그인 인증에 사용한다(성공 기준 1.3.5 입력 목적 식별 및 성공 기준 4.1.2: 이름, 역할, 값을 충족). 사용자의 브라우저 또는 통합된 서드파티 비밀번호 관리자 확장 프로그램은 입력 필드의 목적을 식별하고 사용자 이름과 비밀번호를 자동으로 채울 수 있다.
웹사이트는 붙여넣기 기능을 차단하지 않는다. 사용자는 서드파티 비밀번호 관리자를 사용하여 인증 정보를 저장하고 복사한 후 로그인 양식에 직접 붙여넣을 수 있다.
웹사이트는 WebAuthn을 사용하여 사용자가 사용자 이름/비밀번호 대신 자신의 기기로 인증할 수 있게 한다. 사용자의 기기는 사용 가능한 모든 방식을 사용할 수 있다. 노트북과 휴대전화에서 일반적으로 사용하는 방법은 얼굴 인식, 지문 및 PIN(개인 식별 번호)이다. 웹사이트는 특정 방법의 사용을 강제하지 않으며, 사용자가 자신에게 적합한 방법을 설정한다고 가정한다.
웹사이트는 OAuth 방식을 사용하여 서드파티 제공업체로 로그인할 수 있는 기능을 제공한다.
2단계 인증을 요구하는 웹사이트는 두 번째 인증 요소에 여러 선택지를 제공한다. 여기에는 사용자가 버튼을 누르기만 하면 시간 기반 토큰을 입력할 수 있는 USB 기반 방식이 포함된다.
2단계 인증을 요구하는 웹사이트는 사용자의 기기에 있는 앱으로 스캔하여 신원을 확인할 수 있는 QR 코드를 표시한다.
2단계 인증을 요구하는 웹사이트는 사용자의 기기로 알림을 전송한다. 사용자는 신원을 확인하기 위해 기기의 인증 메커니즘(예: 사용자가 정의한 PIN, 지문, 얼굴 인식)을 사용해야 한다.
이 섹션의 각 번호가 매겨진 항목은 접근성 지침 실무 그룹이 이 성공 기준을 충족하기에 충분하다고 판단하는 기법 또는 기법의 조합을 나타낸다. 기법은 기준의 최소 요구 사항을 넘어설 수 있다. 이러한 기법에서 포괄하지 않은 기준 충족의 다른 방법이 있을 수 있다. 다른 기법 사용에 대한 정보는 WCAG 성공 기준에 대한 기법 이해, 특히 “기타 기법” 섹션을 참조하라.