관리자 화면에서 ‘저장’을 눌렀는데 오류가 났다. 빨간 테두리는 보이지만 이유는 없고, 화면 아래 알림은 곧 사라진다. 마우스를 쓰는 사람은 주변을 둘러보며 문제를 찾을 수 있지만, 키보드나 화면 낭독기로 작업하는 사람은 어디서부터 고쳐야 할지 알기 어렵다. 이 장면은 색 대비 한 항목만 통과한다고 해결되지 않는다.
웹 접근성은 예쁜 보조 기능이 아니라 사용자가 주요 업무를 끝낼 수 있는가라는 제품 품질의 문제다. 견적 요청, 신청서 제출, 주문 승인, 관리자 설정 같은 업무 웹앱은 입력과 상태 변화가 많아 특히 그렇다. 이 글은 법률상 준수 여부를 판정하려는 문서가 아니다. W3C의 WCAG 2.2 권고안과 실무 자료를 기준으로 개발·기획·QA 팀이 우선 확인할 수 있는 작업 경로를 정리한다.
기준표보다 먼저, 완료해야 할 업무를 고른다
WCAG는 인지 가능, 운용 가능, 이해 가능, 견고함이라는 네 원칙 아래 시험 가능한 성공 기준을 둔다. 2.2는 2.1에 새 기준을 더하며, W3C는 웹 접근성 정책을 새로 만들거나 갱신할 때 최신 버전을 참고하도록 권한다. 그러나 제품 팀이 첫 회의에서 모든 기준을 줄줄 외울 필요는 없다. 먼저 사용자가 실제로 수행해야 할 대표 흐름 세 가지를 고르면 된다. 예를 들어 ‘로그인 → 주문 검색 → 상세 보기 → 승인’, ‘문의 입력 → 오류 수정 → 제출’, ‘설정 변경 → 확인 모달 → 완료’다.
각 흐름에서 질문은 단순하다. 화면을 보지 못해도 의미를 알 수 있는가? 마우스 없이 조작할 수 있는가? 실수했을 때 고칠 수 있는가? 화면 단위 체크가 아니라 시작부터 완료까지 연결된 작업을 따라가면, 특정 컴포넌트는 좋아 보여도 다음 단계로 넘어가지 못하는 문제를 발견할 수 있다. 접근성은 한 페이지의 점수가 아니라 사용자 여정의 속성이다.
첫 번째 진단: 마우스를 치우고 키보드만 쓴다
가장 빠른 현장 진단은 마우스에서 손을 떼고 Tab, Shift+Tab, Enter, Space, Escape만으로 핵심 업무를 해 보는 것이다. 메뉴에 들어갈 수 있는지, 선택한 버튼이 무엇인지 보이는지, 필터를 바꾼 뒤 초점이 사라지지 않는지, 모달을 닫고 원래 위치로 돌아오는지 확인한다. 관건은 ‘Tab을 여러 번 누를 수 있다’가 아니라 초점의 순서가 작업 순서와 일치하는가다.
‘키보드 초점이 보이는가’와 ‘초점을 받은 요소가 가려지지 않는가’는 별도 점검이다. 예를 들어 초점 테두리를 없애면 어디에 있는지 알기 어렵다. 고정 상단 메뉴나 하단 배너가 초점 요소를 통째로 덮어도 문제가 된다. WCAG 2.2의 2.4.11 ‘Focus Not Obscured (Minimum)’은 작성자가 만든 콘텐츠 때문에 초점 요소가 완전히 가려지지 않아야 한다는 AA 기준이다. 반면 초점 표시의 면적·대비를 더 구체적으로 다루는 2.4.13은 AAA 기준이다. 두 기준을 섞어 ‘AA면 반드시 특정 굵기의 테두리’라고 단정하지 않는다.
구현은 가능하면 네이티브 HTML부터 시작한다. 이동은 링크, 동작은 버튼, 입력은 실제 폼 컨트롤을 사용한다. 마우스 클릭 이벤트만 달린 일반 div를 버튼처럼 꾸미면 키보드 동작, 역할, 초점 표시를 일일이 다시 구현해야 한다. 디자인 시스템에 버튼·탭·드롭다운의 초점 상태와 키보드 동작을 함께 정의하면 화면마다 같은 실수를 반복하지 않는다.
두 번째 진단: 입력 전 안내와 오류 후 회복
업무 웹앱의 실패는 입력 폼에서 자주 드러난다. 필수 항목 표시가 색상뿐이거나, 입력 형식을 제출 후에야 알려 주거나, 오류 메시지가 필드와 연결되지 않은 경우다. W3C의 폼 레이블 가이드는 각 컨트롤의 목적을 설명하는 레이블을 권한다. 플레이스홀더는 입력을 시작하면 사라지므로 레이블의 대체물이 아니다. ‘담당자 이메일’처럼 보이는 이름과 코드의 <label> 연결을 함께 제공해야 한다.
사용자에게 무엇을 넣을지 미리 말하고, 실패하면 어떤 항목을 어떻게 고쳐야 하는지 알려 준다. 예를 들어 ‘입력 오류’보다 ‘납기일은 오늘 이후 날짜로 입력해 주세요’가 좋다. 오류를 빨간 테두리 하나로 표현하지 말고 필드 근처의 텍스트, 필요하면 상단 오류 요약과 해당 필드로 가는 경로를 함께 둔다. 작성 중인 다른 입력을 날리지 않는 것도 중요하다. W3C의 폼 검증 자료는 오류 식별과 수정 안내를 강조하며, 클라이언트 검증만으로 서버 검증을 대체하지 말라고 설명한다.
비동기 저장이나 제출 완료 상태도 같은 원리다. 스피너가 사라졌다고 사용자가 결과를 안 것은 아니다. 저장 중인지, 완료됐는지, 실패해 재시도해야 하는지 명확한 상태 메시지를 제공하고, 화면 낭독기에도 전달되는지 점검한다. WCAG의 ‘상태 메시지’ 기준은 초점 이동 없이도 보조 기술이 중요한 상태 변화를 알 수 있도록 다룬다. 실제 구현에서는 필요 이상으로 모든 변화에 알림을 쏘지 말고 업무상 중요한 결과에 집중한다.
세 번째 진단: 모달이 열리고 닫힐 때 초점은 어디로 가는가
삭제 확인, 담당자 선택, 첨부 파일 추가처럼 모달이 많은 앱은 화면에서는 그럴듯해도 키보드 사용자를 잃기 쉽다. 모달을 열 때 초점은 내부의 적절한 위치로 가고, 열려 있는 동안 Tab 이동은 모달 밖으로 새지 않아야 하며, Escape나 닫기 버튼으로 닫을 수 있어야 한다. 닫힌 뒤에는 보통 모달을 연 버튼으로 돌아간다. 다만 해당 버튼이 삭제되었다면 다음 작업에 맞는 합리적인 위치로 옮긴다. 이는 W3C WAI-ARIA 모달 대화상자 패턴의 핵심이다.
aria-modal="true"만 붙였다고 모달이 되는 것은 아니다. 배경이 실제로 조작 불가능해야 하고, 시각적으로도 비활성 상태가 표현돼야 한다. 역할·이름·상호작용이 서로 어긋나면 보조 기술 사용자에게 오히려 잘못된 상태를 알린다. 기본 HTML <dialog>를 사용할 수도 있지만, 어떤 방식이든 실제 브라우저와 보조 기술 조합에서 열린 상태, 초점 순환, 닫기 후 복귀를 시험해야 한다.
네 번째 진단: 작은 터치 대상과 확대 화면
마우스와 키보드만큼 손가락 터치와 화면 확대도 중요하다. 표의 행마다 붙은 아주 작은 ‘더 보기’ 아이콘이나 서로 붙은 삭제·수정 버튼은 조작 실수를 부른다. WCAG 2.2의 2.5.8 ‘Target Size (Minimum)’은 포인터 대상 24×24 CSS 픽셀을 AA 기준으로 두되 간격, 동등한 대체 조작 등 예외를 둔다. 따라서 모든 아이콘을 무조건 한 크기로 바꾸라는 뜻은 아니지만, 실제 손가락 조작이 어렵지 않은지 우선 확인할 명확한 기준점이다.
텍스트를 200%로 확대하거나 좁은 화면에서 열었을 때 고정 헤더·사이드바·표·모달이 중요한 입력이나 버튼을 덮지 않는지도 본다. 화면을 가로로 넓히지 않으면 불가능한 복잡한 표라면 정보 구조와 대체 탐색 방식까지 검토한다. W3C의 빠른 접근성 점검은 확대, 키보드 접근, 폼 등을 처음 살펴볼 항목으로 정리한다.
실무 적용: 디자인 시스템, 개발, QA에 나눠 담기
접근성을 출시 직전 한 번의 검사로만 다루면 ‘수정해야 하는 페이지’가 끝없이 생긴다. 업무 웹앱은 공통 컴포넌트가 여러 화면에 반복되므로 책임을 나눠야 한다. 디자인 단계에서는 초점 스타일, 오류·성공 상태, 작은 화면의 배치, 아이콘 버튼의 이름을 명세한다. 개발 단계에서는 의미 있는 HTML, 레이블 연결, 초점 관리, 상태 알림을 공통 컴포넌트에 넣는다. QA 단계에서는 자동 검사와 함께 실제 작업 경로를 키보드와 화면 낭독기로 수행한다.
자동화는 누락된 alt 텍스트나 일부 이름·대비 문제를 빠르게 찾는 데 도움이 된다. 그러나 ‘주문 승인 흐름이 이해 가능한가’, ‘모달 닫힌 뒤 어디로 가는가’, ‘오류 설명이 수정에 충분한가’ 같은 판단은 사람이 사용 맥락에서 확인해야 한다. 따라서 자동 검사 통과를 접근성 완료 선언과 동일하게 취급하지 않는다. 제품의 핵심 여정에 맞는 수동 시나리오를 회귀 테스트로 보관하면 업데이트 때마다 같은 품질을 반복 확인할 수 있다.
출시 전, 이 순서로 확인하자
- 대표 업무 흐름을 2~3개 고르고, 마우스 없이 처음부터 끝까지 완료해 본다.
- 초점 위치가 보이고, 논리적인 순서로 움직이며, 고정 요소에 가려지지 않는지 본다.
- 모든 입력의 레이블·필수 여부·형식 안내를 확인하고, 오류를 일부러 만들어 수정해 본다.
- 모달·드롭다운을 열고 닫으며 초점이 내부에 머물고 작업 위치로 돌아오는지 본다.
- 모바일 터치 대상과 확대·좁은 화면에서 핵심 버튼과 입력이 사용 가능한지 확인한다.
- 자동 검사 결과와 수동 키보드·보조 기술 시험 결과를 함께 기록하고, 공통 컴포넌트부터 고친다.
결국 좋은 웹 접근성은 체크박스를 더 채우는 일이 아니라 한 사람이 도움 없이 일을 끝낼 수 있게 만드는 설계다. 색 대비는 중요하지만 시작일 뿐이다. 키보드 이동, 이해 가능한 입력 안내, 복구 가능한 오류, 예측 가능한 모달까지 이어질 때 업무 웹앱의 품질이 올라간다.
