버튼 이름과 표를 구조적으로 읽을 수 있게 되면 무엇이든 읽을 수 있는 것처럼 설명하기 쉽다. 하지만 구조가 노출되지 않는 화면과 읽기 한도, 지원되지 않는 프레임은 남는다. 나는 읽기 성공이라는 말 옆에 그 결과가 어디까지의 자료인지 적어야 했다.

빈 대상 목록이 빈 페이지를 뜻하지 않는다

요소가 하나도 반환되지 않아도 화면에는 자료가 있을 수 있다. 페이지가 아직 준비되지 않았거나 본문만 있고 control이 없거나 실제 조작면을 현재 규칙으로 찾지 못했을 수 있다. 빈 배열 하나를 사이트가 고장 났다는 결론으로 바꾸지 않는다.

현재 관찰에는 대상이 없을 때 일부 pageHealth 구조 정보를 남기는 경로가 있다. 루트 표시 상태와 DOM 수 같은 단서로 무엇을 더 확인할지 고른다. 이것이 화면 내용을 완전히 진단하는 기능은 아니다. 빈 결과를 성공과 실패 중 하나로 성급히 밀어 넣기보다 원인을 좁힐 자료로 다뤘다.

열린 Shadow DOM과 닫힌 구조를 구분한다

현재 roots 함수는 접근 가능한 shadowRoot를 따라가며 후보를 모은다. 열린 구조를 읽었다고 닫힌 Shadow DOM 내부도 같은 방식으로 모두 읽는 것은 아니다. DOM에서 확인할 수 없는 내용을 임의 추측으로 의미 대상 목록에 추가하지 않는다.

접근성 진단이 일부 입력을 알려 줄 수 있어도 그것을 바로 안정된 행동 참조로 바꾸는 것은 별도 문제다. 진단 경로와 일반 관찰의 의미가 다르다. 어떤 보조 정보가 있다는 사실을 전체 닫힌 구조 지원으로 확대하면 실제로 실행할 수 없는 기능을 약속하게 된다.

화면 캡처와 의미 해석은 다른 산출물이다

canvas에 그린 문서나 도표는 화면 이미지로 보일 수 있어도 버튼·행·셀의 의미가 일반 DOM처럼 노출되지 않을 수 있다. 스크린샷을 저장하는 기능과 그 그림에서 정확한 조작 대상을 얻는 기능을 구별한다. 이미지가 생겼다고 같은 이름·역할 계약을 얻은 것은 아니다.

북극성의 후속 캡처 기능도 이 차이를 없애는 증거로 쓰지 않는다. 화면이나 영역을 저장한 결과는 그림의 범위와 파일 검증으로 확인해야 한다. 모든 canvas 편집기의 입력과 읽기가 지원됐다는 결론은 별도의 재현과 실행 근거가 필요하다. 같은 프로그램 안의 다른 기능이어도 성공 조건은 달랐다.

프레임과 본문 한도도 지원 범위에 포함한다

현재 프레임 탐색에는 수와 깊이 제한이 있고 요소·텍스트·표에도 개별 한도가 있다. 제한 안에서 반환한 자료가 정상이라고 페이지 전체가 완전하다는 뜻은 아니다. 지원되지 않은 프레임은 원인과 함께 남고 더 읽지 않은 부분은 다음 판단에서 구별해야 한다.

로그인이나 공개 주소 제한으로 제외된 프레임을 무조건 우회해 읽는 것도 아니다. 사용자의 요청과 기존 접근 경계를 유지한다. “읽을 수 없다”는 결과가 필요할 때도 있다. 모든 빈 곳을 메워야 한다는 생각으로 보호 규칙을 완화하면 기능 범위를 넓힌 대신 원래 계약을 잃을 수 있다.

진단 자료도 최소한의 구조로 남긴다

control-probe는 일부 접근성 입력의 태그·역할·크기·표시 속성과 조상 상태를 정리한다. 비밀번호와 특정 민감 입력은 제외하고 일반 값·본문·이름·주소를 읽는 진단 함수로 만들지 않는다. 현재 제한된 입력 수와 프레임 수 안에서만 결과를 모은다.

이 글에서는 실제 진단 함수와 관찰·프레임 코드, 관련 fixture와 정책 시험을 읽었다. 새로 모든 비표준 화면을 실행한 검수는 아니다. 진단 자료가 있다는 것과 원인을 고쳤다는 것, 같은 사이트에서 실제 입력을 검증했다는 것도 별도 상태로 남겨야 한다.

지원 범위를 적으면 다음 개선이 구체적이 된다

한계를 적는 것은 기능을 낮춰 소개하는 일이 아니다. 어떤 화면을 새로 재현하고 어떤 완료 조건을 시험해야 하는지 정하는 일이다. 나는 “모든 사이트 지원”이라는 문장보다 읽기 경로와 한도, 지원하지 않는 구조를 함께 보여 주는 설명이 실제 업무 연결에 더 도움이 된다고 본다.

새 편집기를 연결할 때도 기존 일반 규칙을 먼저 확인하고 부족한 구조만 좁게 보완한다. 테스트를 통과한 작은 사례를 전체 호환성으로 바꾸지 않는다. 이렇게 남긴 범위가 있어야 후속 글과 모듈에서 무엇이 개선됐고 무엇이 아직 남았는지 정확히 비교할 수 있다.