미용실의 새 서비스를 소개하면서 아직 접수를 시작하지 않은 예약 버튼을 회색으로 표시할 수 있습니다. 그런데 마우스로는 눌리지 않던 버튼이 키보드로 선택하면 신청을 실행한다면 공개 안내와 실제 동작이 어긋납니다. 출시 전 검수에서는 버튼이 꺼진 것처럼 보이는지와 여러 조작 방식에서 정말 실행되지 않는지를 따로 확인해야 합니다.
먼저 매장이 확정한 현재 상태를 적습니다. 소개만 공개하는 단계인지, 문의만 가능한지, 실제 예약을 받는지에 따라 어떤 행동을 막아야 하는지가 달라집니다. 가령 서비스 설명은 읽을 수 있지만 예약 신청은 아직 받지 않는다는 운영 기준이 있다면 설명 링크까지 막을 이유는 없습니다. 검수자가 출시일이나 접수 허용 범위를 새로 정하지 않고 확인된 기준에 맞춰 시험합니다.
사용자가 보는 색과 접근성 정보, 실제 실행 결과를 나란히 봅니다. HTML의 기본 버튼에는 disabled라는 비활성 속성을 사용할 수 있습니다. 반면 aria-disabled="true"는 보조기기에 사용할 수 없는 상태임을 알리는 표기이며, 그것만으로 동작이 자동 차단되지는 않는다고 MDN은 설명합니다. 버튼처럼 꾸민 링크나 별도 요소인지도 확인해야 합니다. 모양이 비슷해도 같은 속성이 똑같이 작동한다고 가정하지 않습니다.
가상의 시험 화면에서 예약 버튼을 마우스로 누른 뒤 키보드로도 접근해 봅니다. 해당 장치의 실제 역할에 맞는 실행 키를 사용하고, 접수 동작이 시작되는지 확인합니다. Tab 키로 초점이 갔다는 사실만으로 오류라고 하지는 않습니다. 사용할 수 없는 항목이 있다는 것을 발견하도록 초점을 허용하는 구성도 있기 때문입니다. 판정할 것은 초점의 존재와 함께, 비활성이라고 안내한 행동이 실행됐는지입니다.
마우스만 막는 방식도 구별합니다. MDN은 CSS의 pointer-events: none이 마우스 클릭을 막아도 키보드 실행을 막지는 않는다고 안내합니다. 따라서 화면 캡처와 마우스 시험만으로 ‘예약 차단 완료’라고 기록할 수 없습니다. 개발 담당자는 실제 요소의 종류에 맞춰 비활성 상태와 실행 처리를 맞추고, 입력 방법 하나에서만 우회 실행되는 부분이 없는지 살핍니다. 이 글은 실제 운영 중인 예약을 시험 제출하라는 뜻이 아니며, 허용된 시험 환경에서 접수를 만들지 않는 방식으로 확인합니다.
반대 상태도 시험합니다. 접수 시작을 가정한 시험 조건에서 버튼이 활성으로 바뀌었는데 색만 진해지고 여전히 실행되지 않는다면 전환이 완성되지 않은 것입니다. 상태 안내와 동작을 함께 확인하고, 준비 중일 때 열려 있던 서비스 설명이나 문의 경로가 전환 뒤에도 의도대로 남는지 봅니다. 시험에서 상태를 바꾸었다는 사실을 실제 서비스 출시 승인으로 기록하지 않습니다.
공개 문구에는 지금 예약할 수 없는 이유와 확인된 다음 경로를 짧게 적습니다. 아직 정해지지 않은 시작일이나 대기 접수 제도를 임의로 추가하지 않습니다. 외부 예약 도구를 쓰는 경우에는 그 도구가 제공하는 설정과 지원 범위를 확인하고, 직접 수정할 수 없는 동작은 재현 절차와 함께 담당자에게 전달합니다. 본문의 설명을 고쳤다고 외부 버튼의 동작까지 바뀐 것으로 보고하지 않습니다.
결과 기록에는 시험한 비활성·활성 상태, 조작 방법, 표시된 안내, 실제로 실행된 행동을 남깁니다. 새 서비스의 소개가 정확하려면 아직 받지 않는 예약이 특정 입력 방식에서만 시작되는 틈이 없어야 합니다. 회색이라는 시각적 인상보다 확인된 접수 상태와 실행 가능 여부가 맞는지를 출시 준비의 한 항목으로 판단합니다.
기술 확인: MDN의 aria-disabled 설명 https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Attributes/aria-disabled 기본 비활성 속성: MDN의 disabled 설명 https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Attributes/disabled