문의폼 오류 요약을 입력란과 연결하는 방법

오류 요약은 전체 문제의 지도이고 입력란 메시지는 바로 고칠 내용을 설명합니다

문의폼 제출 뒤 단순히 ‘입력값을 확인하세요’라는 알림만 띄우면 사용자는 어느 칸이 왜 잘못됐는지 다시 찾아야 합니다. 반대로 각 입력란 옆에만 오류를 표시하면 화면 아래쪽에 있는 문제를 놓치거나, 제출 버튼 근처에서 무엇이 달라졌는지 알기 어렵습니다. 두 위치는 같은 문장을 중복 장식하는 관계가 아닙니다. 상단 요약은 오류의 개수와 위치를 훑어보는 지도이고, 입력란 가까운 메시지는 해당 값을 고치는 구체적인 지침입니다. 같은 오류 식별자를 기준으로 두 위치를 연결하면 사용자가 요약에서 문제를 선택하고 수정 지점으로 이동할 수 있습니다.참고: W3C Web Accessibility Initiative · User Notification in Forms Tutorial · GOV.UK Design System · Error summary

W3C의 Forms Tutorial 중 User Notification 문서는 제출 성공과 실패 모두에 분명한 피드백이 필요하며, 전체 피드백과 입력 요소 가까운 피드백을 함께 다룹니다. GOV.UK Design System은 페이지 상단의 오류 요약과 오류가 있는 각 답변 가까운 오류 메시지를 함께 제공하고, 요약 항목을 해당 입력으로 연결하는 구체적인 예를 제시합니다. 이 글은 두 자료를 모든 사이트의 유일한 구현법으로 선언하지 않고, 문의폼 자체 예제의 상태와 연결을 점검하는 기준으로 사용합니다.참고: W3C Web Accessibility Initiative · User Notification in Forms Tutorial · GOV.UK Design System · Error summary

자체 예제의 필드와 오류 조건을 먼저 고정해 메시지가 데이터 규칙과 어긋나지 않게 합니다

자체 예제는 실제 조직이나 고객 데이터를 사용하지 않는 ‘페이지 오류 알림’ 문의폼입니다. 필드는 문제 페이지 주소, 오류 유형, 오류 설명, 회신받을 이메일 네 가지이며 이메일만 선택 입력입니다. 제출 전에 각 필드의 목적, 허용 형식, 필수 여부, 최대 길이, 서버가 반환할 수 있는 상태를 표로 고정합니다. 이 규칙이 없으면 화면에는 이메일이 선택이라고 쓰여 있는데 서버에서는 빈 값을 거부하거나, 주소 형식이 틀렸다는 메시지를 띄우면서 어떤 형식을 원하는지는 알려주지 않는 불일치가 생깁니다.

오류 문구는 검증 규칙과 한 줄씩 대응시킵니다. 필수값이 비었을 때와 값은 있지만 형식이 맞지 않을 때를 같은 ‘잘못된 값’으로 뭉치지 않습니다. 사용자가 해결할 수 없는 네트워크 실패나 서버 중단도 입력란 오류로 돌리지 않습니다. 화면 규칙, 클라이언트 검증, 서버 검증의 이름을 동일하게 기록하면 요약 링크가 엉뚱한 입력으로 가거나 서버 오류를 사용자의 실수로 표현하는 문제를 발견하기 쉽습니다.참고: W3C Web Accessibility Initiative · User Notification in Forms Tutorial

오류 한 건마다 요약 링크·입력란·설명 요소를 하나의 식별 관계로 묶습니다

예제에서 페이지 주소 오류는 요약의 링크 `href=#dr-page`, 실제 입력의 `id=dr-page`, 입력 가까운 메시지의 `id=dr-page-error`로 나눕니다. 입력에는 기존 도움말과 오류 설명을 모두 참조하도록 `aria-describedby` 값을 구성합니다. 요약 링크는 실제로 초점을 받을 수 있는 입력 또는 질문 그룹의 첫 조작 요소로 이동합니다. 같은 id를 두 번 사용하거나, 링크 대상이 숨은 래퍼에만 붙어 있거나, 오류 메시지 id가 입력의 설명 목록에서 빠지면 시각적으로 가까워 보여도 프로그램적 관계는 끊깁니다.참고: GOV.UK Design System · Error summary

제출 실패 뒤에는 문서 순서와 초점 이동을 맞춰 요약을 건너뛰지 않게 합니다

오류 요약은 해당 폼의 제목과 설명 다음, 오류가 있는 첫 질문보다 앞에 둡니다. 제출 실패로 페이지가 다시 표시되면 요약 제목이 보이고 키보드 초점도 요약에 도달할 수 있게 합니다. 사용자가 제출 버튼에 머문 채 화면 위에만 요약이 생기면 변화를 알아채지 못할 수 있고, 반대로 초점을 첫 입력으로 바로 보내면 전체 오류 수와 다른 문제를 놓칠 수 있습니다. GOV.UK 구성 예는 오류 요약을 페이지 상단에 두고 기본 동작에서 요약으로 초점을 이동시키는 방식을 제공합니다. 실제 애플리케이션에서는 라우팅, 모달, 단일 페이지 전환 구조를 고려해 같은 목적이 유지되는지 확인합니다.참고: GOV.UK Design System · Error summary · W3C Web Accessibility Initiative · User Notification in Forms Tutorial

1. 비민감 자체 예제 값을 사용해 필수 항목 두 개를 비운 상태로 제출 동작을 재현합니다.
2. 초점이 오류 요약 제목 또는 요약 컨테이너에 도달하고 화면 안에 표시되는지 확인합니다.
3. 요약을 처음부터 읽었을 때 오류 항목의 순서가 실제 폼의 위에서 아래 순서와 같은지 대조합니다.
4. 첫 요약 링크를 Enter로 활성화해 대응하는 입력 또는 선택 그룹의 첫 요소에 초점이 가는지 확인합니다.
5. 값을 수정한 뒤 다시 제출해 해결된 항목이 요약과 필드 메시지 양쪽에서 함께 사라지는지 확인합니다.
6. 브라우저 뒤로 가기, 새로 고침, 중복 제출에서도 오래된 요약이 성공 상태처럼 남지 않는지 확인합니다.

초점 이동은 화면을 강제로 빠르게 스크롤하는 효과가 아니라 현재 상태를 알리는 수단입니다. 요약 컨테이너가 `tabindex=-1`로 스크립트 초점을 받을 수 있더라도 일반 Tab 순서에 불필요하게 반복해서 끼어들지 않는지 확인합니다. 고정 헤더가 요약 제목을 덮는다면 스크롤 여백을 적용하고, 요약 링크를 누른 뒤 입력란의 보이는 레이블과 오류 메시지가 함께 화면에 들어오는지도 봅니다. 모션 감소 설정에서는 부드러운 스크롤보다 즉시 이동을 우선할 수 있습니다.참고: GOV.UK Design System · Error summary

오류 문장은 비난 대신 문제·대상·수정 행동을 짧고 같은 용어로 설명합니다

‘유효하지 않습니다’, ‘오류가 발생했습니다’, ‘잘못 입력했습니다’는 짧지만 수정 방법이 없습니다. 자체 예제는 ‘페이지 주소는 https로 시작하는 전체 주소로 입력하세요’처럼 대상과 기대 형식을 함께 씁니다. 요약에서는 질문 이름을 포함해 여러 오류를 구분하고, 입력란 가까운 메시지에서는 이미 보이는 질문을 불필요하게 길게 반복하지 않습니다. 오류를 낸 사람을 탓하거나 기술 코드, 정규식, 데이터베이스 필드명을 그대로 노출하지 않습니다. 문장 끝의 마침표, 존댓말, 필드 명칭도 한 폼 안에서 일관되게 유지합니다.참고: W3C Web Accessibility Initiative · User Notification in Forms Tutorial · GOV.UK Design System · Error summary

사용자가 고칠 입력 오류와 서비스가 처리해야 할 실패를 같은 요약에 섞지 않습니다

필수값 누락, 형식 불일치, 허용 길이 초과는 사용자가 화면에서 고칠 수 있는 입력 오류입니다. 네트워크 단절, 메일 전송 장애, 데이터 저장 실패, 요청 제한은 사용자가 특정 입력을 바꿔도 해결되지 않을 수 있는 서비스 상태입니다. 서비스 실패를 이메일 입력란에 연결하면 사용자는 값을 반복해서 고치게 되고, 실제 문제는 가려집니다. 자체 예제는 입력 오류만 요약 링크 목록에 넣고, 서비스 실패는 폼 전체 상태 안내로 분리해 다시 시도 방법과 입력 보존 여부를 설명합니다.참고: W3C Web Accessibility Initiative · User Notification in Forms Tutorial

• 입력 오류 응답에는 안정된 오류 코드, 대응 필드, 사람이 읽는 메시지를 함께 둡니다.
• 서비스 실패에는 특정 필드 id를 임의로 붙이지 않고 폼 전체 안내 영역을 사용합니다.
• 전송 실패 뒤 사용자가 적은 비민감 입력이 유지되는지 확인하고 비밀번호 같은 민감값은 별도 기준을 적용합니다.
• 재시도 버튼은 중복 요청을 만들지 않도록 진행 상태와 비활성 조건을 함께 표시합니다.
• 세션 만료처럼 다시 인증해야 하는 상태는 입력 오류가 아니라 이동 이유와 복귀 경로로 설명합니다.
• 오류 로그에는 화면에 노출할 필요가 없는 서버 경로나 개인정보를 남기지 않습니다.

오류 요약의 제목도 상태를 구분합니다. 사용자가 수정할 항목이 있으면 ‘입력 내용을 확인하세요’, 서비스가 응답하지 않으면 ‘지금 문의를 전송하지 못했습니다’처럼 원인 범위를 다르게 씁니다. 원인을 확정할 근거가 없을 때는 네트워크나 서버 중 하나라고 단정하지 않고 관찰된 결과만 설명합니다. 대체 이메일을 제공한다면 실제 주소, 링크 목적, 같은 개인정보 처리 범위가 맞는지도 별도로 확인해야 합니다.참고: W3C Web Accessibility Initiative · User Notification in Forms Tutorial

좁은 화면과 키보드에서 요약·링크·입력·오류 설명의 왕복 경로를 확인합니다

데스크톱에서 한 줄인 오류 링크는 390픽셀에서 두세 줄이 될 수 있습니다. 링크 문구가 줄바꿈되어도 전체 문장이 하나의 조작 영역인지, 긴 URL이나 이메일 예시가 가로 넘침을 만들지 않는지, 고정 헤더가 이동한 입력을 가리지 않는지 확인합니다. 200퍼센트 확대에서는 요약과 첫 질문이 한 화면에 동시에 보이지 않을 수 있으므로 초점 표시와 문서 순서가 더 중요합니다. 오류 상태를 색상만으로 구분하지 않고 텍스트 접두사, 테두리, 아이콘 대체 정보의 역할을 나눕니다.참고: W3C Web Accessibility Initiative · User Notification in Forms Tutorial · GOV.UK Design System · Error summary

스크린리더 한 종류에서 들린다는 사실만으로 모든 보조기술 조합을 대표하지 않습니다. DOM의 label, fieldset과 legend, 설명 참조, alert 역할을 먼저 점검하고 가능한 범위에서 여러 브라우저와 보조기술을 추가 확인합니다. 라이브 영역을 사용한다면 같은 오류를 요약, 개별 메시지, 토스트에서 세 번 연속 알리지 않는지 봅니다. 자동 알림의 양보다 현재 문제와 수정 경로를 안정적으로 찾을 수 있는 구조가 우선입니다.참고: W3C Web Accessibility Initiative · User Notification in Forms Tutorial

오류 상태별 재현 기록을 남겨 보이는 문구와 실제 연결을 따로 판정합니다

마지막 기록은 ‘폼 정상’이라는 한 줄 대신 오류 코드, 재현 입력, 요약 문구, 링크 대상, 필드 메시지, 초점 결과, 값 보존, 화면 폭을 행으로 남깁니다. 문구가 맞아도 링크가 동작하지 않을 수 있고, 링크가 맞아도 해결된 오류가 요약에 남을 수 있으므로 존재·연결·상태 갱신을 분리합니다. 서버 요청을 보내지 않은 정적 점검은 실제 접수 성공으로 기록하지 않고, 운영자 승인을 받아 시험한 범위만 결과에 포함합니다.

1. 필수 누락, 형식 불일치, 길이 부족, 선택값 형식, 서비스 실패, 성공의 여섯 상태를 구분합니다.
2. 각 상태에서 화면에 표시된 요약 항목과 입력란 메시지의 문구를 기록합니다.
3. 요약 링크의 href와 실제 고유 id를 대조하고 활성화 뒤 초점 대상을 기록합니다.
4. 오류 수정 전후의 입력값 보존과 해결된 항목 제거를 비교합니다.
5. 320·390픽셀과 200퍼센트 확대에서 가림·겹침·가로 넘침을 기록합니다.
6. 실제 문의 도착, 응답 시간, 사용자 성공률처럼 확인하지 않은 결과는 별도 미측정으로 남깁니다.

오류 요약과 입력란의 연결을 확인한 순서

1. 빈 입력 검사에서 필수 오류 3개를 표시합니다. 첫 요약 링크를 실행해 페이지 주소 입력란으로 초점이 이동하는지 봅니다.
2. example.com 주소·오류 유형·20자 이상 설명을 채워 다시 검사합니다. 해결한 오류는 요약과 필드 양쪽에서 사라져야 합니다.
3. 이메일은 비워도 허용해야 합니다. 정상 안내는 입력 검사 완료와 전송·저장하지 않았음을 함께 설명해야 합니다.

오류 요약과 입력란의 연결 판단에서 제외한 범위

• 이 글의 문의폼은 구조를 설명하는 자체 예제이며 실제 고객 정보, 실제 문의 기록 또는 운영 성과를 포함하지 않습니다.
• W3C와 GOV.UK 자료는 접근 가능한 오류 피드백을 설계하는 참고 기준이며 특정 사이트의 법적 준수나 모든 보조기술 호환을 자동으로 입증하지 않습니다.
• 클라이언트 검증만 확인해서는 서버 저장, 메일 도착, 요청 제한, 세션 만료 같은 운영 상태를 판정할 수 없습니다.
• 오류 요약과 필드 연결이 정확해도 실제 사용자의 이해도나 과업 성공이 높아진다고 단정할 수 없으며 별도 사용자 연구가 필요합니다.

오류 요약과 입력란의 연결에 사용한 원문

원문별 확인일과 참고 범위를 아래에 표시했습니다. 예제 입력값은 설명을 위한 설정이며 원문 기관의 제품 평가를 뜻하지 않습니다.

1. User Notification in Forms TutorialW3C Web Accessibility Initiative · 확인 2026-08-20

   폼 제출의 성공·실패를 알리는 전체 피드백과 입력 요소 가까운 피드백, 이해하기 쉬운 오류 지침의 범위를 확인했습니다.

2. Error summaryGOV.UK Design System · 확인 2026-08-20

   페이지 상단 오류 요약과 개별 입력 오류를 함께 제공하고 요약 항목을 해당 질문의 조작 요소로 연결하는 구현 예를 참고했습니다.

선택 목록과 라디오 예시의 식별자

위의 작동 폼에서 오류 유형은 선택 목록이며 요약 링크는 해당 select 요소로 연결됩니다. 본문 표의 dr-kind-typo는 라디오 질문 그룹으로 설계를 바꾸는 경우의 별도 예시입니다. 현재 폼에 그 라디오 항목이 존재한다는 뜻이 아닙니다. 생성 도식의 field·field-error는 참조 관계를 단순화한 식별자이며 실제 HTML의 dr 접두 식별자와 그대로 복사해 섞지 않습니다. 회신 이메일은 선택 항목으로 빈 값을 허용하며 입력한 경우에만 형식을 확인합니다.