브라우저 화면에서 오른쪽 아래 버튼이라고 말하는 것은 쉽다. 하지만 화면 폭과 스크롤이 바뀌면 그 설명도 바뀐다. 나는 북극성이 버튼의 이름과 역할, 상태와 링크를 읽어 대상을 좁힐 수 있도록 구조화된 관찰을 만들었다.

보이는 글자와 접근 가능한 이름을 함께 본다

페이지의 버튼 이름은 눈에 보이는 본문 하나로 정해지지 않는다. aria-label과 aria-labelledby, 연결된 label, 버튼 값과 이미지 대체 글자, title과 placeholder 같은 단서가 있다. 현재 name 함수는 이런 정보를 정해진 순서로 살펴 제한된 길이의 이름을 만든다.

이름 후보를 무작정 모두 붙이면 같은 버튼의 표현이 매번 바뀌거나 주변 문장이 섞일 수 있다. 그래서 우선순위와 공백 정리를 명시했다. 다만 이 구현을 웹 표준 접근성 이름 계산 전체와 완전히 같다고 부르지는 않는다. 자체 도구가 어떤 근거로 대상을 설명하는지 읽을 수 있게 만든 계약이다.

역할과 상태를 이름 옆에 둔다

같은 “선택”이라는 이름도 링크인지 버튼인지 체크박스인지에 따라 다음 행동이 다르다. role 함수는 명시된 역할과 실제 태그·입력 종류를 보고 button·textbox·combobox·radio 같은 값을 만든다. 선택 상태와 펼침, 비활성·읽기 전용·필수 여부도 별도 상태로 남긴다.

이름에 “선택됨”을 계속 붙여 대상을 찾는 방식보다 상태를 따로 읽는 편이 확인에 유리하다. 특히 체크박스의 mixed와 false는 다르다. 조작 전에 무엇이 가능한지, 조작 뒤 무엇이 바뀌었는지 설명하려면 이름만 맞추는 것으로 부족했다. 링크에는 허용된 형태의 href도 함께 남긴다.

일반 규칙과 편집기 보완을 구분했다

특정 글쓰기 편집기는 실제 입력과 보이는 본문이 다른 구조에 있다. 현재 코드에는 그런 편집기의 제목·본문 모듈과 도구 버튼 설명을 읽는 좁은 보완이 있다. 일반 페이지의 숨긴 내용을 모두 읽는 것으로 해결하지 않았다.

도구 버튼의 선택 상태 설명과 실제 기능 이름도 분리한다. 아이콘 설명이 접근성 트리에서 사라지는 사례를 다루더라도 어떤 버튼 구조에만 적용하는지 제한한다. 보완이 들어간 사이트와 일반 관찰 규칙을 같은 범용 성공으로 소개하지 않으려 했다. 한 사이트를 고친 규칙이 다른 페이지의 숨김 정책을 바꾸면 안 된다.

의미를 읽었다고 바로 누르지는 않는다

이름·역할·상태를 얻으면 대상을 설명하기는 쉬워진다. 하지만 같은 이름의 두 버튼 중 어느 것인지, 현재 문서의 노드인지, 가려지지 않았는지는 실행 직전에 더 확인해야 한다. 구조화는 추측을 줄이는 자료이지 클릭 권한 자체가 아니다.

관찰 결과에는 문서와 snapshot에 묶인 참조가 붙고, 실제 조작은 기존 Broker를 통과한다. 페이지의 문장은 비신뢰 자료로 남는다. “이 버튼을 눌러라”는 본문을 읽었다고 사용자의 원래 요청 범위가 늘어나지도 않는다. 나는 의미 데이터와 실행 책임을 이어 주되 같은 것으로 합치지 않았다.

시험도 좌표 대신 실제 결과를 본다

기존 같은 업무 비교에는 이름 중복 대상 거절과 입력값, 표와 링크 읽기 같은 완료 조건이 있었다. 숨긴 radio와 보이는 label을 연결하는 별도 시험은 label의 이름과 역할, checked 상태, 비활성 거절과 실제 선택 결과를 확인한다.

이 글에서는 관찰 함수와 해당 시험 코드를 읽고 과거 비교의 범위를 대조했다. 지금 모든 사이트의 버튼을 새로 시험한 결과가 아니다. 구조화된 관찰만으로 canvas 그림의 의미나 모든 편집기 변형을 읽을 수 있다는 주장도 하지 않는다. 확인한 의미 정보가 어떤 구현에서 나오는지 남기는 제작 기록이다.

홈페이지를 만들 때도 읽히는 화면을 생각한다

사람에게 잘 보이는 버튼이라도 이름과 연결 구조가 없으면 자동화 도구가 설명하기 어렵다. 반대로 의미 있는 label과 실제 버튼, 명확한 상태를 쓰면 사람과 에이전트 모두에게 현재 동작을 설명할 단서가 생긴다. 시각 디자인과 의미 구조는 함께 설계할 수 있다.

나는 이 경험을 홈페이지와 업무 프로그램 제작에도 가져가려 한다. 다만 에이전트가 읽기 편하다는 사실을 접근성 인증이나 자동 실행 성공으로 바꾸지는 않는다. 의미를 노출하는 설계, 실제 조작의 검증, 사용자가 이해하는 문구를 각각 확인해야 읽히는 화면이 실제로 편한 업무 화면이 된다.