웹접근성은 인증이나 규정 준수를 위한 마지막 체크리스트에만 머물지 않습니다. 마우스 없이 메뉴를 열 수 없거나, 고정된 상담 버튼이 입력창을 가리거나, 문의폼의 오류 이유를 알 수 없다면 사용자는 중요한 과업을 끝내기 어렵습니다. 접근성 문제가 곧 문의·예약·구매 흐름의 UX 문제가 되는 이유입니다.
특히 홈페이지 리뉴얼은 화면 디자인뿐 아니라 메뉴, 폼, 팝업, 결제, 로그인 같은 상호작용을 함께 바꾸는 작업입니다. 기존 사이트의 문제를 새 디자인에 그대로 옮기지 않으려면 기획과 설계 단계에서부터 실제 조작 가능성을 점검해야 합니다.
왜 WCAG 2.2를 리뉴얼 기준으로 봐야 할까
WCAG 2.2는 2024년 12월 12일 W3C 권고안으로 발행됐습니다. W3C는 웹접근성 정책을 개발하거나 갱신할 때 가장 최신 버전의 WCAG를 사용하도록 권장합니다. WCAG 2.2에는 키보드 포커스, 터치 타깃, 드래그 동작, 인증처럼 모바일 조작과 전환 과정에 직접 연결되는 기준이 포함돼 있습니다.
따라서 리뉴얼 전 접근성 점검은 문구나 색상만 확인하는 작업이 아닙니다. 사용자가 메뉴를 탐색하고, 상품이나 일정을 선택하고, 정보를 입력한 뒤 제출하는 전 과정을 실제 조작 방식에 따라 살펴봐야 합니다.
문의·예약·구매를 막는 7가지 UX 문제
1. 마우스와 터치로만 조작되는 기능
문의·예약·구매 흐름의 모든 기능은 키보드 인터페이스만으로도 조작할 수 있어야 합니다. 마우스를 올려야 열리는 메뉴, 클릭해야만 선택되는 날짜 선택기, 터치에만 반응하는 수량 조절기, 키보드로 실행할 수 없는 제출·결제 버튼은 우선 점검 대상입니다.
리뉴얼 시에는 Tab 키 등으로 주요 흐름을 처음부터 끝까지 이동해 보는 방식이 유효합니다. 메뉴 진입, 옵션 선택, 정보 입력, 버튼 실행 중 어느 한 단계라도 키보드로 진행되지 않는다면 화면이 보여도 기능은 이용하기 어렵습니다.
2. 들어갈 수 있지만 빠져나올 수 없는 키보드 트랩
팝업, 날짜 선택기, 챗봇 같은 컴포넌트 안으로 키보드 포커스가 들어간 뒤 밖으로 이동하지 못하는 상태를 키보드 트랩이라고 합니다. 키보드로 진입할 수 있는 컴포넌트라면 키보드만으로 벗어날 방법도 제공해야 합니다.
닫기 버튼이 마우스로만 동작하거나 포커스가 컴포넌트 내부를 계속 순환하면 사용자는 다음 입력칸이나 구매 버튼으로 이동할 수 없습니다. 팝업을 새로 설계할 때는 여는 동작뿐 아니라 닫기와 포커스 이탈까지 하나의 흐름으로 검토해야 합니다.
3. 고정 요소에 완전히 가려지는 입력칸과 버튼
고정 헤더, 화면 하단의 상담·예약 버튼, 쿠키 배너는 중요한 기능을 강조하거나 안내하는 데 쓰입니다. 하지만 이런 요소가 현재 키보드 포커스를 받은 입력칸이나 버튼을 완전히 가리면 사용자는 자신이 어느 항목을 조작하는지 확인하기 어렵습니다.
WCAG 2.2의 ‘Focus Not Obscured (Minimum)’은 키보드 포커스 표시가 저작자가 만든 콘텐츠에 의해 완전히 가려지지 않도록 요구합니다. 리뉴얼 시에는 화면 상단과 하단의 고정 요소를 모두 켠 상태에서 폼의 마지막 항목까지 이동하며 포커스 위치를 확인해야 합니다.
4. 누르기 어려운 작은 터치 영역
모바일 화면에서 아이콘이 작거나 버튼 사이의 여유가 부족하면 원하는 기능을 정확히 누르기 어렵습니다. 문의·예약·구매 버튼뿐 아니라 달력 이동 아이콘, 수량 증감 버튼, 옵션 삭제 버튼처럼 과업 중 반복해서 사용하는 작은 조작 요소도 포함해 살펴봐야 합니다.
WCAG 2.2에서 추가된 AA 기준에 따르면 포인터로 누르는 타깃은 예외를 제외하고 최소 24×24 CSS 픽셀이어야 합니다. 시각적으로 보이는 아이콘의 크기만 볼 것이 아니라 실제로 반응하는 클릭·터치 영역이 충분한지 확인하는 것이 핵심입니다.
5. 드래그만 요구하는 선택 방식
슬라이더를 끌어 범위를 정하거나, 지도 위치를 움직이거나, 예약 시간표의 항목을 드래그해야만 선택할 수 있다면 일부 사용자는 과업을 완료하기 어렵습니다. WCAG 2.2는 드래그가 필수적인 경우 등을 제외하고 드래그 없이 수행할 수 있는 단일 포인터 대안을 요구합니다.
리뉴얼 설계에서는 드래그 인터페이스를 없애는 것만이 답은 아닙니다. 드래그 기능을 유지하더라도 버튼, 목록 선택 등 같은 결과를 낼 수 있는 단일 포인터 조작 방법이 함께 있는지 점검해야 합니다.
6. 무엇이 잘못됐는지 알려주지 않는 폼
문의나 예약 정보를 입력한 뒤 제출이 되지 않는데 이유를 알 수 없다면 사용자는 어느 항목으로 돌아가야 할지 판단하기 어렵습니다. 색상이나 테두리 변화만으로 오류를 표현하는 방식도 오류 내용을 구체적으로 전달하기에는 부족할 수 있습니다.
문의·예약 폼에서 입력 오류가 자동으로 감지되면 오류가 발생한 항목을 식별해 텍스트로 알려야 합니다. 수정 방법을 알 수 있는 경우에는 적절한 오류 수정 제안도 제공해야 합니다. 리뉴얼 전에는 필수 항목을 비우거나 형식에 맞지 않는 값을 입력해 오류 안내가 항목과 연결되는지 확인할 필요가 있습니다.
7. 기억력이나 퍼즐 풀이에 의존하는 로그인·본인확인
로그인과 본인확인은 구매나 예약을 완료하기 직전에 등장할 수 있는 중요한 단계입니다. 이 과정에서 비밀번호를 기억하게 하거나, 퍼즐 풀이, 객체 인식·전사 같은 인지 기능 테스트를 요구하면 과업 완료에 장벽이 생길 수 있습니다.
WCAG 2.2는 로그인·본인확인 단계를 인지 기능 테스트에 의존하지 않는 방식으로 완료할 수 있도록 요구합니다. 비밀번호 관리자를 사용하거나 복사·붙여넣기를 막지 않는 방식이 관련 예시로 제시됩니다. 리뉴얼에서는 로그인 화면의 모양뿐 아니라 입력 보조 도구가 실제로 작동하는지도 함께 확인해야 합니다.
리뉴얼 전 점검은 핵심 과업을 따라가야 한다
접근성 점검을 페이지별 체크리스트로만 진행하면 실제 전환 흐름에서 발생하는 문제를 놓칠 수 있습니다. 먼저 방문자가 완료해야 하는 핵심 과업을 정하고, 문의 시작부터 제출 완료까지, 일정 탐색부터 예약 완료까지, 상품 선택부터 구매 완료까지 순서대로 살펴보는 편이 좋습니다.
각 흐름에서는 키보드만으로 완료할 수 있는지, 컴포넌트에서 빠져나올 수 있는지, 포커스가 고정 요소에 가려지지 않는지, 터치 영역이 충분한지 확인합니다. 이어 드래그 대안, 오류 안내, 로그인과 본인확인 방식을 점검하면 일곱 가지 문제를 실제 사용자 여정 안에서 검토할 수 있습니다.
웹접근성은 특정 사용자만을 위한 별도 기능이 아니라 홈페이지의 중요한 과업을 다양한 조작 방식으로 완료할 수 있게 만드는 설계 조건입니다. 리뉴얼 전에 이 조건을 확인하면 새로운 화면을 만든 뒤 구조적인 문제를 다시 수정하는 상황을 줄이고, 문의·예약·구매 흐름을 더 명확하게 설계할 수 있습니다.
웹접근성은 인증이나 규정 준수를 위한 마지막 체크리스트에만 머물지 않습니다. 마우스 없이 메뉴를 열 수 없거나, 고정된 상담 버튼이 입력창을 가리거나, 문의폼의 오류 이유를 알 수 없다면 사용자는 중요한 과업을 끝내기 어렵습니다. 접근성 문제가 곧 문의·예약·구매 흐름의 UX 문제가 되는 이유입니다.
특히 홈페이지 리뉴얼은 화면 디자인뿐 아니라 메뉴, 폼, 팝업, 결제, 로그인 같은 상호작용을 함께 바꾸는 작업입니다. 기존 사이트의 문제를 새 디자인에 그대로 옮기지 않으려면 기획과 설계 단계에서부터 실제 조작 가능성을 점검해야 합니다.
왜 WCAG 2.2를 리뉴얼 기준으로 봐야 할까
WCAG 2.2는 2024년 12월 12일 W3C 권고안으로 발행됐습니다. W3C는 웹접근성 정책을 개발하거나 갱신할 때 가장 최신 버전의 WCAG를 사용하도록 권장합니다. WCAG 2.2에는 키보드 포커스, 터치 타깃, 드래그 동작, 인증처럼 모바일 조작과 전환 과정에 직접 연결되는 기준이 포함돼 있습니다.
따라서 리뉴얼 전 접근성 점검은 문구나 색상만 확인하는 작업이 아닙니다. 사용자가 메뉴를 탐색하고, 상품이나 일정을 선택하고, 정보를 입력한 뒤 제출하는 전 과정을 실제 조작 방식에 따라 살펴봐야 합니다.
문의·예약·구매를 막는 7가지 UX 문제
1. 마우스와 터치로만 조작되는 기능
문의·예약·구매 흐름의 모든 기능은 키보드 인터페이스만으로도 조작할 수 있어야 합니다. 마우스를 올려야 열리는 메뉴, 클릭해야만 선택되는 날짜 선택기, 터치에만 반응하는 수량 조절기, 키보드로 실행할 수 없는 제출·결제 버튼은 우선 점검 대상입니다.
리뉴얼 시에는 Tab 키 등으로 주요 흐름을 처음부터 끝까지 이동해 보는 방식이 유효합니다. 메뉴 진입, 옵션 선택, 정보 입력, 버튼 실행 중 어느 한 단계라도 키보드로 진행되지 않는다면 화면이 보여도 기능은 이용하기 어렵습니다.
2. 들어갈 수 있지만 빠져나올 수 없는 키보드 트랩
팝업, 날짜 선택기, 챗봇 같은 컴포넌트 안으로 키보드 포커스가 들어간 뒤 밖으로 이동하지 못하는 상태를 키보드 트랩이라고 합니다. 키보드로 진입할 수 있는 컴포넌트라면 키보드만으로 벗어날 방법도 제공해야 합니다.
닫기 버튼이 마우스로만 동작하거나 포커스가 컴포넌트 내부를 계속 순환하면 사용자는 다음 입력칸이나 구매 버튼으로 이동할 수 없습니다. 팝업을 새로 설계할 때는 여는 동작뿐 아니라 닫기와 포커스 이탈까지 하나의 흐름으로 검토해야 합니다.
3. 고정 요소에 완전히 가려지는 입력칸과 버튼
고정 헤더, 화면 하단의 상담·예약 버튼, 쿠키 배너는 중요한 기능을 강조하거나 안내하는 데 쓰입니다. 하지만 이런 요소가 현재 키보드 포커스를 받은 입력칸이나 버튼을 완전히 가리면 사용자는 자신이 어느 항목을 조작하는지 확인하기 어렵습니다.
WCAG 2.2의 ‘Focus Not Obscured (Minimum)’은 키보드 포커스 표시가 저작자가 만든 콘텐츠에 의해 완전히 가려지지 않도록 요구합니다. 리뉴얼 시에는 화면 상단과 하단의 고정 요소를 모두 켠 상태에서 폼의 마지막 항목까지 이동하며 포커스 위치를 확인해야 합니다.
4. 누르기 어려운 작은 터치 영역
모바일 화면에서 아이콘이 작거나 버튼 사이의 여유가 부족하면 원하는 기능을 정확히 누르기 어렵습니다. 문의·예약·구매 버튼뿐 아니라 달력 이동 아이콘, 수량 증감 버튼, 옵션 삭제 버튼처럼 과업 중 반복해서 사용하는 작은 조작 요소도 포함해 살펴봐야 합니다.
WCAG 2.2에서 추가된 AA 기준에 따르면 포인터로 누르는 타깃은 예외를 제외하고 최소 24×24 CSS 픽셀이어야 합니다. 시각적으로 보이는 아이콘의 크기만 볼 것이 아니라 실제로 반응하는 클릭·터치 영역이 충분한지 확인하는 것이 핵심입니다.
5. 드래그만 요구하는 선택 방식
슬라이더를 끌어 범위를 정하거나, 지도 위치를 움직이거나, 예약 시간표의 항목을 드래그해야만 선택할 수 있다면 일부 사용자는 과업을 완료하기 어렵습니다. WCAG 2.2는 드래그가 필수적인 경우 등을 제외하고 드래그 없이 수행할 수 있는 단일 포인터 대안을 요구합니다.
리뉴얼 설계에서는 드래그 인터페이스를 없애는 것만이 답은 아닙니다. 드래그 기능을 유지하더라도 버튼, 목록 선택 등 같은 결과를 낼 수 있는 단일 포인터 조작 방법이 함께 있는지 점검해야 합니다.
6. 무엇이 잘못됐는지 알려주지 않는 폼
문의나 예약 정보를 입력한 뒤 제출이 되지 않는데 이유를 알 수 없다면 사용자는 어느 항목으로 돌아가야 할지 판단하기 어렵습니다. 색상이나 테두리 변화만으로 오류를 표현하는 방식도 오류 내용을 구체적으로 전달하기에는 부족할 수 있습니다.
문의·예약 폼에서 입력 오류가 자동으로 감지되면 오류가 발생한 항목을 식별해 텍스트로 알려야 합니다. 수정 방법을 알 수 있는 경우에는 적절한 오류 수정 제안도 제공해야 합니다. 리뉴얼 전에는 필수 항목을 비우거나 형식에 맞지 않는 값을 입력해 오류 안내가 항목과 연결되는지 확인할 필요가 있습니다.
7. 기억력이나 퍼즐 풀이에 의존하는 로그인·본인확인
로그인과 본인확인은 구매나 예약을 완료하기 직전에 등장할 수 있는 중요한 단계입니다. 이 과정에서 비밀번호를 기억하게 하거나, 퍼즐 풀이, 객체 인식·전사 같은 인지 기능 테스트를 요구하면 과업 완료에 장벽이 생길 수 있습니다.
WCAG 2.2는 로그인·본인확인 단계를 인지 기능 테스트에 의존하지 않는 방식으로 완료할 수 있도록 요구합니다. 비밀번호 관리자를 사용하거나 복사·붙여넣기를 막지 않는 방식이 관련 예시로 제시됩니다. 리뉴얼에서는 로그인 화면의 모양뿐 아니라 입력 보조 도구가 실제로 작동하는지도 함께 확인해야 합니다.
리뉴얼 전 점검은 핵심 과업을 따라가야 한다
접근성 점검을 페이지별 체크리스트로만 진행하면 실제 전환 흐름에서 발생하는 문제를 놓칠 수 있습니다. 먼저 방문자가 완료해야 하는 핵심 과업을 정하고, 문의 시작부터 제출 완료까지, 일정 탐색부터 예약 완료까지, 상품 선택부터 구매 완료까지 순서대로 살펴보는 편이 좋습니다.
각 흐름에서는 키보드만으로 완료할 수 있는지, 컴포넌트에서 빠져나올 수 있는지, 포커스가 고정 요소에 가려지지 않는지, 터치 영역이 충분한지 확인합니다. 이어 드래그 대안, 오류 안내, 로그인과 본인확인 방식을 점검하면 일곱 가지 문제를 실제 사용자 여정 안에서 검토할 수 있습니다.
웹접근성은 특정 사용자만을 위한 별도 기능이 아니라 홈페이지의 중요한 과업을 다양한 조작 방식으로 완료할 수 있게 만드는 설계 조건입니다. 리뉴얼 전에 이 조건을 확인하면 새로운 화면을 만든 뒤 구조적인 문제를 다시 수정하는 상황을 줄이고, 문의·예약·구매 흐름을 더 명확하게 설계할 수 있습니다.