HTML에 입력 요소가 있다고 사람이 지금 사용할 수 있는 입력란인 것은 아니다. 감춘 원본 입력과 보이는 대체 화면, 비활성 영역이 섞여 있다. 나는 북극성이 존재하는 노드를 모두 행동 후보로 취급하지 않게 했고 예외도 실제 보이는 조작면을 기준으로 좁혔다.

자기 자신뿐 아니라 조상의 숨김도 본다

excluded는 요소에서 부모와 ShadowRoot의 host를 따라가며 hidden·inert·aria-hidden과 스타일을 확인한다. display:none과 숨긴 visibility, opacity 0도 제외한다. 버튼 자체가 보이는 속성이어도 바깥 컨테이너가 감춰져 있으면 일반 후보가 되지 않는다.

visible은 양의 너비와 높이도 요구한다. 다만 이 말이 현재 viewport 안에 있다는 뜻은 아니다. 화면 밖에 있지만 레이아웃에 존재하는 요소는 inViewport 상태로 구별할 수 있다. 숨겨진 것과 스크롤 뒤에 있는 것을 같은 조건으로 처리하면 필요한 대상을 아예 잃거나 없는 대상을 누르게 된다.

비활성과 숨김은 서로 다른 상태다

disabled 버튼은 이름을 읽을 수 있어도 행동할 수 없는 상태일 수 있다. 읽기 전용 필드와 필수 항목, 민감한 입력도 별도 상태로 둔다. 목록에서 모두 지워 버리는 것보다 왜 실행할 수 없는지 설명할 자료가 남는다.

상태를 읽었다고 입력값까지 공개하는 것은 아니다. 일반 본문 추출은 input과 textarea, 편집 가능한 영역의 내용을 별도로 취급한다. 실제 값 확인과 사이트별 편집 내용 읽기는 각 도구의 계약을 봐야 한다. 나는 요소 존재·의미 설명·값 읽기·변경 가능성을 한 단계로 합치지 않았다.

숨긴 radio의 보이는 label은 좁은 예외다

실제 서비스는 radio나 checkbox를 숨기고 label을 눌러 선택하게 만들기도 한다. choiceForLabel은 연결된 실제 입력이 radio나 checkbox이고 그 입력 자체는 보이지 않을 때 보이는 label을 조작면으로 연결한다. 일반 설명 label 전체를 버튼처럼 만드는 방식은 아니다.

역할과 checked·disabled는 연결된 control에서 읽고 실제 클릭 지점은 보이는 label에서 얻는다. 숨겨진 컨트롤 값을 직접 바꾸는 우회가 아니라 사람이 누르는 조작면과 상태를 연결하려는 설계다. 이미 보이는 일반 checkbox를 label 때문에 두 개로 중복 노출하지 않는 조건도 필요했다.

예외가 전체 숨김 정책을 바꾸지 않게 한다

편집기의 특수 입력이나 도구 설명을 다룰 때도 일반 제외 규칙을 완화하고 싶어질 수 있다. 하지만 숨긴 모든 자손을 읽게 하면 광고·비활성 패널과 민감한 입력까지 후보가 늘어난다. 현재 보완은 확인한 편집기 구조나 label 관계에 묶는다.

진단용 control-probe도 일반 값 수집기가 아니다. 접근성 트리에서 찾은 일부 입력의 구조·크기·조상 표시 상태를 제한적으로 정리하고 비밀번호 같은 입력은 제외한다. 진단할 수 있다는 사실로 그 요소를 바로 조작하지 않는다. 문제를 설명할 정보와 실행 허용 조건을 나눠 유지했다.

시험은 선택 결과와 거절을 함께 본다

숨긴 선택 항목 시험은 보이는 label이 radio와 checkbox로 나오고 일반 설명과 숨긴 label은 빠지는지 확인한다. 예약 label을 누른 뒤 실제 checked 변화와 결과 문구를 보고, disabled 상태와 나중에 바뀐 오래된 참조도 거절하는지 본다.

이 글에서는 실제 구현과 해당 Electron fixture 시험 코드를 읽었다. 기존 시험 시나리오의 범위를 설명하며 현재 사용자의 서비스에서 새 선택을 실행한 것은 아니다. 보이는 모든 사용자 정의 control과 모든 CSS 변형이 지원된다는 주장도 하지 않는다. 새 구조를 만났다면 같은 원칙으로 제한된 재현 자료부터 만들어야 한다.

없는 입력을 찾는 대신 실제 조작면을 설명한다

업무 프로그램을 만들 때도 보이는 label과 실제 값의 관계를 명확히 하면 사람과 에이전트 모두에게 유리하다. 모양만 그린 버튼보다 의미와 상태를 가진 조작면이 확인하기 쉽다. 디자인 때문에 원본 입력을 감췄다면 어떤 요소를 눌러 무엇이 바뀌는지도 계약에 남겨야 한다.

나는 숨김을 무조건 없애거나 모두 읽는 방식보다 존재·가시성·조작 가능성을 나눠 보는 쪽을 택했다. 이 구분이 있어야 없는 입력란을 있는 것처럼 설명하지 않고, 실제로 쓸 수 있는 선택 항목도 놓치지 않는다. 화면 구조를 읽는 일은 노드 수집보다 그 관계를 정확히 표현하는 일이었다.