접근 가능한 인증 - by. UXKM

2025-05-16

요약 설명
관련 지침 : 인증 과정은 인지 기능 테스트에만 의존해서는 안 된다.
사용자 로그인 등과 같은 인증 과정이 인지 기능 테스트(예: 로그인을 위한 비밀번호 입력, 터치스크린 화면의 패턴 인식, 임의의 문자열 기억, 계산 수행, 특정 객체를 포함하고 있는 이미지 찾기 등)에 의존하는 경우, 인지 기능 테스트에 의존하지 않는 인증 방법을 적어도 하나 이상 제공해야 합니다.
인지 기능 테스트에 의존하지 않고 인증을 하기 위해서는 브라우저가 아이디/비밀번호를 저장할 수 있도록 마크업된 서식, 공개 인증(OAuth: Open Authorization)을 통한 서드 파티, 신체(얼굴, 지문 등)나 물건(휴대폰, USB 등)을 이용한 인증 등을 이용할 수 있습니다.
다만, 이미 사용자 자신에게 익숙하여 별도의 인지적인 노력을 필요로 하지 않는 사용자의 이름이나 이메일 주소, 전화번호는 인지 기능 테스트로 간주하지 않습니다.

인지 기능 테스트란?

인지 기능 테스트란, 사용자가 기억하거나, 인식하거나, 추론하거나, 문제를 해결해야만 통과할 수 있는 과정을 의미합니다. 이러한 테스트는 특히 인지 장애가 있는 사용자에게 장벽이 될 수 있으므로, 웹 접근성 지침에서는 이러한 테스트만으로 인증을 요구하지 말 것을 권장하고 있습니다.

인지 기능 테스트 예시

비밀번호 입력
사용자가 기억한 비밀번호를 정확히 입력해야 합니다.
이미지 선택 CAPTCHA
"자동차가 있는 이미지를 모두 고르세요" 같은 시각 인식과 판단이 필요합니다.
문자 인식 CAPTCHA
"일그러진 문자를 읽고 입력하세요" – 문자 인식과 입력이 요구됩니다.
패턴 입력
정해진 순서의 패턴이나 그림을 기억해서 입력해야 합니다.
간단한 산수 문제
"5 + 3 = ?" 같은 계산 능력이 요구됩니다.
임의의 문자열 따라 입력하기
"ABX7D2" 같은 무작위 문자열을 보고 따라 써야 합니다.

기대효과

사용자는 복잡한 기억이나 판단 없이도 로그인 및 인증 과정을 원활하게 진행할 수 있어, 기억, 읽기, 숫자 계산 등에 어려움이 있는 사용자도 인지 능력에 상관없이 인증 과정을 수행할 수 있습니다.
이를 통해 인지 장애를 포함한 다양한 사용자들이 서비스에 동등하게 접근할 수 있으며, 사용자 경험이 향상되고 인증 실패로 인한 이탈률이 줄어들어 더 많은 사용자층의 신뢰와 참여를 유도하는 긍정적인 효과를 가져옵니다.

필요성

가장 널리 사용되고 있는 인증 형태인 아이디(또는 이름, 이메일 등)와 비밀번호를 사용하는 방법은 사용자의 기억 능력에 의존해야 하기 때문에 인지 장애가 있는 사용자들은 어려움을 겪을 수 있습니다.
또한 추가 인증 단계로 일회성 확인 코드를 따라 작성하거나 문제를 풀어야 하는 등의 방식이 제공되는 경우, 학습 능력이나 인지 능력에 어려움이 있는 사용자는 인증이 불가능할 수 있습니다.

인지 기능에 대한 부담 감소
보조 기술 사용자 배려
다양한 수단 제공 (메일 인증, 생체 인증 등)

대상

사용자 유형
이유

인지장애인

비밀번호 기억, 보안 질문 응답이 어려움
시각장애인

CAPTCHA 이미지 해석 불가
고령자

복잡한 인증 구조 인지 어려움
보조기기 사용자

인증 흐름에 대한 시멘틱 안내 필요

체크리스트

CAPTCHA에 대체 수단 제공 여부
autocomplete 등 저장된 인증 정보 활용 가능 여부
인증 흐름을 보조기술로 안내 가능한지

테스트 방법

스크린 리더 인증 흐름을 테스트합니다.
키보드만으로 인증 가능 여부를 확인합니다.
오류 메시지와 재입력 UX를 확인합니다.

QA 지표

인증 실패율
자동입력 필드 활용률
보조기기 사용자의 인증 완료 성공률

개발방법

인증 과정에서 보안과 접근성 사이의 균형을 유지하면서, 사용자의 인지 또는 학습 능력에 의존하지 않는 다양한 인증 방식의 대안을 제공해야 합니다.
예를 들어, 다음과 같은 대안을 고려해 볼 수 있습니다.

생체인증
지문, 얼굴 인식 등 사용자가 별도로 기억하실 필요 없이 신체 정보를 활용하여 인증합니다.
기기 기반 인증
패스키, 인증 앱 등을 통해 간편하게 인증합니다.
자동 완성 지원
비밀번호 관리 프로그램이 입력 필드를 자동으로 채울 수 있도록 허용합니다.
복사/붙여넣기 허용
OTP나 비밀번호를 복사하여 붙여넣는 과정을 제한하지 않습니다.
링크 기반 인증
이메일 또는 SMS로 전달되는 링크를 클릭하여 인증을 완료하실 수 있도록 제공합니다.

html 예시 – 이메일 인증

								<form>
									<label for="email">이메일</label>
									<input type="email" id="email" autocomplete="email" />
									<button type="submit">인증 메일 보내기</button>
								</form>

CAPTCHA 대체 질문

								<label for="question">5 더하기 3은?</label>
								<input id="question" type="text" />

Vue 예시

								<template>
									<div>
										<label>이메일</label>
										<input v-model="email" autocomplete="email" />
										<button @click="sendLoginLink">로그인 링크 전송</button>
									</div>
								</template>

								<script setup>
									import { ref } from 'vue';
									const email = ref('');
									const sendLoginLink = () => alert(`${email.value} 주소로 인증 메일을 전송했습니다.`);
								</script>

React 예시

								function LoginForm() {
									const [email, setEmail] = React.useState('');
									const sendLogin = () => alert(`${email}로 인증 메일 전송`);
									return (
										<>
											<label htmlFor="email">이메일</label>
											<input
												id="email"
												type="email"
												value={email}
												onChange={e => setEmail(e.target.value)}
												autoComplete="email"
											/>
											<button onClick={sendLogin}>로그인 링크 전송</button>
										</>
									);
								}

점검 기준

인증 방식이 기억 기반만인가?
CAPTCHA에 대체 수단 제공되는가?
시멘틱 구조로 스크린 리더가 흐름 안내 가능한가?

점검 방법

보조기기(스크린 리더 등)를 사용하여 필드 및 버튼 안내가 제대로 이루어지는지 테스트합니다.
키보드 조작만으로 인증을 완료할 수 있는지 확인합니다.

준수/미준수 사례

미준수 사례

인지 기능 테스트만으로 인증

다음은 게시글 자동 등록을 방지하기 위한 인지 기능 테스트로, 사람이 맞는지를 인증하는 사례입니다.
왜곡된 문자 그림을 보고 그대로 입력하거나, 빠르게 들려주는 음성을 듣고 기억하여 입력해야 하는 테스트이기 때문에, 난독증 등을 가진 일부 사용자분들께는 테스트를 통과하기가 매우 어려울 수 있습니다.

개선 방법: 사용자께서 패턴을 찾거나 해독하지 않아도 되는, 인지적 부담이 적은 대체 방법을 제공합니다.
예를 들어 “나는 로봇이 아닙니다”와 같은 ReCAPTCHA v3를 고려해 볼 수 있습니다.

캡챠 인식과 인지 기능을 같이 요구

인증 과정에서 문자 인식, 순서 기억, 시각적 탐색, 정확한 클릭 등 복잡한 인지 과정을 동시에 요구하는 CAPTCHA 방식은 기억력이나 주의력, 시각 처리 능력 등에 어려움이 있는 사용자분들께 심각한 접근성 장벽이 됩니다.
문자가 왜곡되어 표현되고 배경에 시각적 노이즈가 많아 시각적 혼란을 유발하며, 스크린 리더를 사용하는 사용자에게는 인식이 불가능합니다.
또한, 이러한 인지 기능 테스트 외에 대체 인증 수단이 제공되지 않아, 인지 장애나 시각 장애가 있는 사용자분들은 서비스 이용 자체가 제한될 수 있는 문제가 있습니다.

개선 방법: 시각 장애인도 가능한 인증 방법 및 사용자가 패턴을 찾거나 해독하지 않아도 되는 인지 부담이 적은 대체 방법을 제공합니다.

준수 사례

사용자 기기를 사용한 인증 방식 제공

사용자 기기를 사용하여 기기의 생체 인증, 패스키, 인증 애플리케이션 등을 통해 인증을 대체하는 방식을 제공합니다. 이는 기기에 저장된 패스키를 사용하여 인지 능력을 활용하지 않고도 인증을 받을 수 있도록 제공한 사례입니다.
단, 이러한 방식으로 제공할 경우 QR 코드를 촬영하기 위해서는 시각을 활용하기 어려운 사용자분들을 위한 또 다른 대체 방안이 제공되어야 할 수 있습니다.

복사하여 붙여넣기, 자동 채움 기능 허용

비밀번호 관리 프로그램을 사용하여 비밀번호 입력 필드를 자동으로 채우는 기능을 허용함으로써 사용자가 기억력에 의존하지 않도록 합니다.
추가 인증 과정에서 이메일로 OTP 코드를 발송하고 이를 작성하게 하는 등의 경우에도, 단순히 복사하여 붙여넣는 기능을 허용하여 사용자가 인지 능력에 의존하지 않도록 합니다.
다음은 메일로 전송된 인증 코드를 복사하여 인증 코드 입력창에 붙여넣을 수 있도록 허용된 사례입니다.

oAuth를 사용하여 타사 공급자를 통한 인증 제공

소셜 미디어 계정이나 이메일 계정과 같이 익숙한 타사 공급자 계정을 사용하여 인증할 수 있도록 제공합니다.

이메일 링크 인증

이메일 링크 인증은 사용자가 인지 능력을 과도하게 사용하지 않고도 계정에 접근할 수 있도록 돕는 인증 방식입니다. 기본적으로 사용자 이름과 비밀번호를 통한 로그인 방식을 제공하되, 비밀번호를 잊었을 경우 이메일을 통해 별도의 인증 링크를 제공합니다. 사용자가 자신의 이메일 주소를 입력하고 양식을 제출하면, 사이트는 해당 이메일로 인증 링크를 전송합니다. 사용자는 도착한 이메일 속 링크를 클릭하기만 하면 복잡한 절차 없이 곧바로 웹 사이트에 로그인됩니다.
이 방법을 통해 사용자는 복잡한 비밀번호를 기억하거나 퍼즐을 푸는 등의 인지 부담을 덜 수 있으며, 별도의 인지 기능 테스트에 의존하지 않고도 안전하고 편리하게 인증 과정을 거칠 수 있습니다. 이러한 접근은 다양한 사용자분들께 편의를 제공하며, 접근 가능한 인증을 구현하는 한 사례가 됩니다.

접근성 테스트 도구 활용 점검방법

Lighthouse

Lighthouse는 구글에서 제공하는 웹 페이지 품질 개선을 위한 오픈 소스로 자동화 도구입니다. Lighthouse는 사이트의 성능, 접근성, SEO 등에 대한 전반적인 진단을 해줍니다.
상세 설명 : Lighthouse Overview 공식 문서 참조

참고

Lighthouse 모바일의 경우 네트워크 속도를 최대 4배정도 느리게 측정하기 때문에 모바일 Performance가 비교적 낮게 나옵니다.
Metric 별로 어떤 성능 점수가 나는지 Lighthouse 계산기를 통해서 자세히 확인할 수 있습니다.

카테고리가 측정하는 내용

Performance
웹 페이지의 로딩 속도 등 실제 성능을 측정. 성능의 측정항목은 6가지 Metric으로 정의되며, 각 Metric들은 페이지가 로드되는 속도를 다양한 측면에서 측정합니다.
상세 설명 : Lighthouse Performance Audits.
Best practices
Best practices를 따라 개발되었는지 확인
Accessibility
접근성 확인. 폰트 사이즈, 메뉴간 간격 등을 측정
Progressive Web App (PWA)
웹과 네이티브 앱의 기능 모두의 이점을 가지도록 만들어진 서비스인지 체크
SEO
Search Engine Optimization의 약자로 검색 엔진 수집 최적화 측정

사용법

Google Chrome에서 웹 페이지를 엽니다.
DevTools (F12)를 열고 ‘Lighthouse’ 탭을 선택합니다. (단축키 맥:Cmd⌘+Option⌥+I / 윈도우:Ctrl+Shift+I)
‘Accessibility’ 항목을 선택하고 우측 상단의 ‘Analyze page load’를 클릭하여 보고서를 생성합니다.

[Lighthouse를 활용한 검사]
Lighthouse는 접근성 점수와 함께 개선이 필요한 부분을 제시합니다.

[Lighthouse를 활용한 검사]

iOS : Accessibility Inspector

iOS 앱 개발도구인 xcode에는 Accessibility Inspector 툴을 통해 접근성을 수동 검사할 수 있습니다.

사용법

Xcode에서 Accessibility Inspector 툴을 실행합니다. (Xcode > Open Developer Tool > Accessibility Inspector)

[출처 : NULI]
테스트할 장치를 선택합니다. 개발 중인 앱을 Simulator로 빌드 하셨다면 Simulator를 선택하여 진단하실 수 있습니다.

[출처 : NULI]
Accessibility Inspector 툴 오른쪽 상단에서 audit 버튼을 선택합니다. Run Audit 버튼을 선택합니다.

[출처 : NULI]
결과 이슈 목록을 선택하거나 눈 버튼을 선택하시면 해당 항목을 보여줍니다. 장치를 보면 노란색으로 표시되고, 물음표 버튼를 선택하면 해당 이슈를 해결할 수 있는 방법을 알려줍니다.

[출처 : NULI]
물음표 버튼를 선택하면 해당 이슈를 해결할 수 있는 방법을 알려줍니다.

[출처 : NULI]
목록에서 주의 깊게 봐야 할 이슈는 description에 대한 이슈입니다. 대체 텍스트 이슈는 접근성 사용자에게 매우 크리티컬한 이슈이면서 해결 방법이 매우 수월한 이슈입니다.

[출처 : NULI]
Xcode의 Identity Inspector 탭의 Accessibility 패널에 대체 텍스트를 넣어주세요.
대체 텍스트 외에도 명도대비, 작은 터치영역등 다양한 접근성 이슈를 체크해주고 있습니다.

[출처 : NULI]
각 요소별 접근성 항목을 확인할 수 있고, iOS 스크린리더인 VoiceOver 음성으로 들어볼 수 있습니다.
1. 스피커
  현재 초점이 위치한 요소의 정보를 VoiceOver 음성으로 들려줍니다.
2. 이전 요소 탐색
  현재 초점이 위치한 곳에서 이전 요소의 정보를 VoiceOver 음성으로 들려줍니다.
3. 자동 탐색
  현재 초점이 위치한 곳에서 모든 요소를 자동으로 탐색하며 요소의 정보를 VoiceOver 음성으로 들려줍니다.
4. 다음 요소 탐색
  현재 초점이 위치한 곳에서 다음 요소의 정보를 VoiceOver 음성으로 들려줍니다.
5. 직접 탐색
  마우스로 요소를 직접 선택하여 탐색합니다.
6. 현재 초점이 위치한 요소의 접근성 항목을 나타냅니다.
  항목은 Label(대체 텍스트), Value(값), Traits(유형 정보), Identifier(식별자), Hint(힌트 정보), User Input Labels(사용자 입력 텍스트 정보)입니다.
[출처 : NULI]

Android : Lint

Android 앱 개발도구인 Android Studio 의 Lint를 통해 개발과정에서 접근성을 수동 검사할 수 있습니다.

사용법

Analyze > Inspect Code를 실행합니다.

[출처 : NULI]
Android Studio 4.1.1. 버전을 사용합니다. Android Studio Electric Eel 2022.1.1 Patch 2버전이면 Code 메뉴에 inspect Code가 보입니다.

[출처 : NULI]
Inspection profile에서 더보기 버튼을 실행합니다.

[출처 : NULI]
Inspections 창에서 Lint > Accessibility 항목 중 “Image without contentDescription” 항목과 “Missing accessibility label”을 체크합니다.
Android에서 Accessibility 항목 중 주의 깊게 봐야 할 이슈는 바로 이미지 대체 텍스트와 입력 서식 라벨에 대한 이슈입니다.
Severity를 Error로 체크해 주세요. Error 이슈를 해결하기 전까지는 빌드 성공을 할 수 없습니다.

[출처 : NULI]
진단 범위도 설정해야 합니다. 모든 범위 [In All Sccopes]

[출처 : NULI]
OK를 누르고 코드를 확인합니다. contentDescription 이 없는 ImageView 또는 ImageButton에 빨간색으로 표시된 것을 확인할 수가 있습니다. labelFor 또는 hint가 없는 EditText 역시 빨간색으로 표시된 것을 볼 수 있습니다.

[출처 : NULI]
이슈 해결 : ImageView 클래스에 contentDescription을 코드에서 추가합니다. 빨간색으로 표시되었던 코드가 노란색 코드로 변경됩니다.

[출처 : NULI]
이슈 해결 : EditText 역시 hint 코드를 추가합니다. 빨간색으로 표시되었던 코드가 노란색 코드로 변경됩니다.

[출처 : NULI]

결론

접근성은 시작은 있지만 끝이 없는 작업입니다.
오류 항목을 정기적으로 점검하여 접근성 개선을 한다면 점차 검사를 할 항목이 줄어들게 될 것입니다. 모두가 차별 없이 서비스를 이용할 수 있도록 접근성 유지를 위한 모두의 노력이 필요합니다. 무엇보다 접근성 작업은 서비스를 제공한다면 선택이 아닌 필수로 지켜야하는 항목임을 잊지 말아야 합니다.

접근성 작업 시 점검 필수사항

접근성 가이드(WCAG, KWCAG, WAI-ARIA) 내용 숙지
접근성 체크리스트 작성
접근성 자동 및 수동 검사(스크린리더) 진행
접근성 검사 툴(Lighthouse Accessibility 등) 활용 오류 항목 개선 및 내용 정리
접근성 사용자 테스트
접근성 정기적인 모니터링