제안창은 입력과 검색 버튼 사이에

KRDS SP-029 — 검색어 입력 도움창을 검색어 입력 필드와 검색 버튼 사이에 제공하여 스크린 리더 가상 초점으로 콘텐츠에 접근하는 경우에도 논리적인 순서에 따라 콘텐츠를 이용할 수 있도록 하고 있다.

0. 들어가며 — 제안창이 DOM에서 엉뚱한 데 있으면

이번 703편은 검색어 입력 도움창을 검색어 입력 필드와 검색 버튼 사이에 제공하여, 스크린 리더 가상 초점으로 접근할 때도 논리적 순서로 이용하게 하라는 규칙입니다.

제안창이 — 시각적으론 입력창 아래 떠도, DOM(코드) 순서가 엉뚱하면 스크린 리더는 논리적 순서로 못 읽죠. SP-029는 제안창을 입력 필드와 검색 버튼 사이(DOM)에 두라고 규정합니다. 이번 편을 풀어냅니다.

1. 원문 — 제안창 논리적 위치

SP-029 (서비스 패턴 > 검색 > 검색어 입력) “검색어 입력 도움창을 검색어 입력 필드와 검색 버튼 사이에 제공하여 스크린 리더 가상 초점으로 콘텐츠에 접근 하는 경우에도 논리적인 순서에 따라 콘텐츠를 이용할 수 있도록 하고 있다.”

제안창을 입력 필드와 검색 버튼 사이에 둬 스크린 리더가 논리적 순서로 이용하게 하라는 뜻입니다.

정리: 제안창을 입력 필드와 검색 버튼 사이(DOM)에 두라. 이게 SP-029입니다.

2. 왜 제안창 논리적 위치인가

스크린 리더 사용자는 화면을 DOM(코드) 순서대로 읽습니다(가상 초점/탐색 커서). 그래서 요소들의 DOM 순서가, 논리적 이용 순서와 일치해야 하죠. 검색의 논리적 순서는: 검색어 입력 → (제안 확인) → 검색 실행입니다. SP-029 는 제안창을 이 순서에 맞게 DOM 배치하라고 합니다.

제안창 DOM 위치가 잘못될 때의 문제:

읽기 순서 어긋남 제안창이 시각적으론 입력창 바로 아래 떠도, DOM에서 엉뚱한 위치(예: 페이지 맨 끝)에 있으면, 스크린 리더는 입력 필드 다음에 제안창이 아니라 검색 버튼·다른 콘텐츠를 읽습니다. 제안창을 한참 뒤에야 만나거나 못 만나죠.

논리 단절 사용자의 ‘입력 → 제안 확인 → 실행’ 흐름이, DOM 순서와 어긋나면 끊깁니다. 입력하고 바로 제안을 확인해야 하는데, 그 순서가 안 되죠.

그래서 SP-029는 — 입력 필드와 검색 버튼 사이 배치를 요구합니다:

DOM 순서: 입력 → 제안창 → 검색 버튼 제안(입력 도움)창을 DOM에서, 검색어 입력 필드 다음, 검색 실행 버튼 앞에 둡니다. 그러면 스크린 리더가, ‘입력 필드 → 제안 목록 → 검색 버튼’ 순으로 논리적으로 읽죠.

가상 초점 논리 순서 스크린 리더 가상 초점(탐색 커서)으로 콘텐츠를 훑을 때도, 입력 → 제안 → 실행의 자연 스러운 순서로 이용하게요. 입력하고 다음으로 가면 제안이, 그다음이 검색 버튼이죠.

시각 = DOM 일치 시각적 순서(입력창 아래 제안)와, DOM·읽기 순서를 일치시킵니다(읽기 순서 CP-444, WCAG 1.3.2 의미 있는 순서). CSS로 시각만 맞추고 DOM이 어긋나면 안 되죠.

‘가상 초점(virtual focus)’. 스크린 리더는 실제 키보드 포커스 외에, 가상 커서로 화면 콘텐츠를 훑습니다(읽기 모드). 이 가상 탐색도 DOM 순서를 따르므로, 제안창의 DOM 위치가 중요하죠. 키보드 포커스(SP-027)뿐 아니라 가상 탐색에서도 논리적이게요.

WCAG 1.3.2(의미 있는 순서). 콘텐츠의 제시 순서가 의미에 영향을 주면, 올바른 읽기 순서가 프로그램적으로 결정 가능해야 한다(WCAG 1.3.2). 검색 입력→제안→실행의 순서를, DOM으로 보장하는 게 SP-029입니다.

SP-027·028·029 종합. SP-027(키보드 활용)·SP-028(출현 탐지)·SP-029(논리 위치)가 — 함께 제안창 접근성을 완성합 니다. 고르고(027)·알고(028)·올바른 순서로(029)요.

이 규칙은 검색(SP)의 ’제안창 순서 접근성’을 담당합니다 — 제안창을 입력 필드와 검색 버튼 사이에 둬(029), 스크린 리더 가 논리적 순서로 검색을 이용하게 하죠.

정리하면 — 제안창의 DOM 순서가 어긋나면 스크린 리더가 입력→제안→실행 순서로 못 읽으므로, 제안창을 검색어 입력 필드와 검색 버튼 사이(DOM)에 둬 가상 초점에서도 논리적 순서로 이용하게 해야 합니다.

3. 점검 / 개선

무엇을 점검하나

DOM 순서 — 제안창이 DOM에서 입력 필드 다음, 검색 버튼 앞에 있는가.

가상 초점 순서 — 스크린 리더가 입력→제안→실행 순서로 읽는가.

시각=DOM — 시각 순서와 DOM·읽기 순서가 일치하는가(WCAG 1.3.2).

개선 방향

제안창 DOM 위치: 입력 필드 → 제안창 → 검색 버튼.

가상 초점 논리 순서. 시각=DOM 일치(CP-444, WCAG 1.3.2).

4. 누가 담당하나 / 우리 사이트에 해당될까?

역할	책임
퍼블리셔/개발	제안창 DOM 위치 구현
QA/접근성	가상 초점 순서 검증

기관 유형	SP-029 적용
중앙행정기관(대표·운영) / 공공기관 / 지자체	✅ 필수 (자동완성 제공 시)

자동완성·추천 검색어를 제공하는 사이트가 해당됩니다.

5. 30초 자가진단 + FAQ

✅ 30초 자가진단

□ 제안창이 DOM에서 입력 필드 다음, 검색 버튼 앞에 있나요?

□ 스크린 리더가 입력→제안→실행 순서로 읽나요?

□ 시각 순서와 DOM·읽기 순서가 일치하나요(WCAG 1.3.2)?

❓ FAQ

Q1. 시각적으론 입력창 아래 뜨는데 왜 DOM이 중요한가요? 스크린 리더는 DOM 순서대로 읽습니다(가상 초점). DOM이 엉뚱하면 제안창을 한참 뒤에 만나거나 못 만나죠. 시각=DOM이어야 논리적으로 읽습니다. Q2. ’가상 초점’이 뭔가요? 스크린 리더가 실제 키보드 포커스 외에 가상 커서로 화면을 훑는 읽기 모드입니다. 이것도 DOM 순서를 따르므로 제안창 DOM 위치가 중요하죠. Q3. 어디에 둬야 하나요? DOM에서 검색어 입력 필드 다음, 검색 실행 버튼 앞에요. 그러면 ’입력→제안→실행’의 논리적 순서로 스크린 리더가 읽습니다(WCAG 1.3.2).

6. 마무리

SP-029의 메시지:

제안창은 입력과 검색 버튼 사이에 — DOM 순서를 논리적으로 배치하라.

제안창 DOM 순서가 어긋나면 스크린 리더가 논리적 순서로 못 읽습니다. 입력 필드와 검색 버튼 사이에 둬 입력→제안→실행 순서로 이용하게 하는 게 핵심이죠. 다음 편은 자동완성·추천 계층화입니다.

다음 편 예고 ▶ 「704. (SP-030) 자동완성이나 추천 검색어 목록을 계층화하여 제공하고 있다.」

ViewCheck는 제안창이 입력 필드와 검색 버튼 사이 논리적 순서로 배치되는지를 진단합니다.

📚 참고 출처

KRDS 서비스 패턴 — 검색 가이드 — https://www.krds.go.kr/html/site/service/service_02.html

WCAG 2.1 SC 1.3.2 Meaningful Sequence — https://www.w3.org/WAI/WCAG21/Understanding/meaningful-sequence.html

KRDS #ViewCheck #공공웹사이트 #전자정부 #디지털정부 #웹접근성 #디자인시스템 #UIUX #UI컴포넌트 #웹표준

KRDS,ViewCheck,공공웹사이트,전자정부,디지털정부,웹접근성,디자인시스템,UIUX,UI컴포넌트,웹표준