직접 살펴보는 예제
불필요한 연락처를 받지 않는 오류 제보 예제
실제 개인정보 대신 예시 주소를 사용하세요. 이 안에서 하는 입력은 브라우저 밖으로 전송되지 않습니다.
아래 내용은 구조를 설명하기 위해 만든 예제입니다. 실제 상품·고객 성과 자료가 아닙니다.
전송·저장 기능이 없는 연습용 입력란입니다.
문의 범위와 개인정보 고지 예제에서 나눈 판단
필수 항목을 비워 검사하면 해당 필드로 연결되는 오류 요약이 표시됩니다. 회신 이메일은 선택이며, 입력한 경우에만 형식을 확인합니다. 정상 입력에서도 ‘입력 검사 완료’라고 표시하며 어떤 메일이나 서버로도 내용을 보내지 않습니다.
문의 페이지는 연락처 장식이 아니라 받을 수 있는 요청과 처리 경계를 공개하는 운영 문서입니다
이메일 주소와 입력 칸만 있으면 연락은 보낼 수 있지만, 방문자는 어떤 주제를 받아 주는지, 무엇을 준비해야 하는지, 답변이 어떤 방식으로 오는지 알기 어렵습니다. 반대로 ‘언제나 빠르게 답변합니다’처럼 이행 여부를 확인하지 않은 약속을 크게 쓰는 것도 적절하지 않습니다. 이 글은 문의 페이지를 신뢰도 점수로 평가하지 않고, 문의 범위·필수 정보·사용 목적·처리 결과·정정 경로가 보이는지와 실제 조작이 가능한지를 확인합니다.
W3C의 Labels or Instructions 해설은 입력을 요구할 때 사용자가 어떤 정보를 넣어야 하는지 알 수 있도록 레이블이나 지침을 제공해야 한다고 설명합니다. GOV.UK 디자인 시스템의 이메일 주소 패턴은 이메일을 왜 요청하는지 분명히 하고 올바른 형식 입력을 돕도록 안내합니다. 이 글은 두 문서를 특정 문의 폼의 정답으로 복제하지 않고, 필드 이름과 수집 목적, 입력 도움말을 분리해 검사하는 기준으로 사용합니다.참고: W3C Web Accessibility Initiative · Understanding Success Criterion 3.3.2: Labels or Instructions · GOV.UK Design System · Email addresses
폼보다 먼저 문의 유형과 필요한 자료, 받지 않는 정보를 표로 고정합니다
자체 예제는 실제 업체와 무관한 ‘페이지 오류 정정 창구’입니다. 받는 요청은 오탈자, 깨진 링크, 날짜 불일치 세 가지이며, 필요한 정보는 문제가 보인 페이지 주소와 오류 설명입니다. 이름과 전화번호는 처리에 필요하지 않아 받지 않고, 회신을 원하는 경우에만 이메일을 입력하도록 설계합니다. 처리 기한은 운영 자료가 없으므로 약속하지 않으며, 접수 여부와 회신 가능성의 차이를 안내합니다.
| 문의 유형 | 필요 정보 | 선택 정보 | 받지 않는 정보 | 결과 안내 |
|---|---|---|---|---|
| 오탈자 | 페이지 주소·잘못된 문구 | 회신 이메일 | 전화번호·주소 | 확인 후 수정 여부를 이메일로 안내 가능 |
| 깨진 링크 | 페이지 주소·링크 위치 | 재현 화면 | 계정 비밀번호 | 링크 상태를 확인한다는 범위만 안내 |
| 날짜 불일치 | 서로 다른 날짜가 보이는 위치 | 참고 문서 링크 | 주민번호·결제 정보 | 자료 확인 뒤 정정 기록에 반영 가능 |
| 제작 문의 | 별도 제작 문의 경로 사용 | 없음 | 오류 폼에 사업 자료 입력 | 알맞은 경로로 이동 안내 |
이 표가 있어야 입력 필드와 개인정보 안내를 실제 목적에 맞출 수 있습니다. ‘혹시 필요할지 모른다’는 이유로 회사 규모, 예산, 전화번호를 모두 필수로 만들지 않습니다. 반대로 회신이 반드시 이메일로만 가능하다면 그 이유와 사용 범위를 필드 가까이에 적습니다. 접수할 수 없는 긴급 신고나 법적 요청이 있다면 숨은 약관에만 두지 않고 문의 유형 설명에서 별도 공식 경로를 안내해야 합니다.참고: GOV.UK Design System · Email addresses · Information Commissioner’s Office · What privacy information should we provide?
각 입력 칸은 보이는 레이블, 사용 이유, 형식 도움말을 서로 다른 문장으로 제공합니다
placeholder만으로 ‘이메일’을 표시하면 사용자가 입력을 시작한 뒤 필드 목적이 사라질 수 있습니다. 예제는 보이는 label에 ‘회신받을 이메일’을 쓰고, 바로 아래 도움말에 ‘정정 결과 회신을 요청한 경우에만 사용합니다’라고 적습니다. type=email, autocomplete=email, spellcheck=false를 적용하고 붙여넣기를 막지 않습니다. GOV.UK 이메일 패턴은 요청 이유를 설명하고 올바른 형식 입력을 돕도록 권고하며, 최대 길이와 필드 폭도 고려하도록 안내합니다.참고: GOV.UK Design System · Email addresses
| 필드 | 보이는 레이블 | 도움말 | 검증 | 피해야 할 구현 |
|---|---|---|---|---|
| 페이지 주소 | 오류가 보인 페이지 주소 | 주소창의 전체 주소를 붙여넣으세요 | URL 형식과 길이 | placeholder만 제공 |
| 오류 설명 | 어떤 내용이 잘못되었나요 | 보이는 문구와 기대한 정보를 적으세요 | 빈 값·최대 길이 | ‘내용’이라는 모호한 레이블 |
| 이메일 | 회신받을 이메일 | 회신을 원하는 경우에만 입력 | 선택값이면 형식만 확인 | 선택인데 필수 표시 |
| 동의 | 입력 정보 전송 동의 | 목적·보관 안내 링크 제공 | 선택 상태 확인 | 약관 전체를 한 문장에 묶음 |
레이블은 입력 형식뿐 아니라 과업 목적을 설명해야 합니다. W3C는 너무 많은 지침도 너무 적은 지침처럼 혼란을 줄 수 있다고 설명하므로, 모든 법률 문장을 필드 아래 반복하지 않습니다. 필드 가까이에는 필요한 핵심 이유와 형식을 두고, 전체 처리 목적·보관·권리 정보는 개인정보 문서로 연결합니다. 링크 문구는 ‘자세히’가 아니라 ‘문의 정보 처리 기준 확인’처럼 도착 내용을 예고합니다.참고: W3C Web Accessibility Initiative · Understanding Success Criterion 3.3.2: Labels or Instructions
필수값을 빠뜨렸을 때의 안내까지 설계하려면 오류 요약과 입력란을 연결하는 예제로 레이블·오류 메시지·초점 경로를 함께 확인할 수 있습니다.
개인정보 안내는 푸터에만 숨기지 않고 전송을 결정하는 위치에서 요약합니다
개인정보 링크가 푸터에 존재하는 것과 사용자가 전송 전에 처리 범위를 이해하는 것은 다릅니다. 예제 폼의 제출 버튼 앞에는 ‘페이지 주소, 오류 설명, 선택한 회신 이메일을 정정 확인과 회신에 사용합니다’라는 짧은 요약을 둡니다. 보관 기준, 담당자, 삭제·정정 요청, 외부 도구 사용 여부는 별도 개인정보 문서에서 확인할 수 있게 연결합니다. 실제 운영에서 받는 항목이 바뀌면 요약과 문서, 서버 전송값을 함께 갱신해야 합니다.참고: Information Commissioner’s Office · What privacy information should we provide?
영국 정보위원회는 개인정보를 제공할 때 목적, 보관 기간, 공유 대상, 권리 등 여러 정보를 투명하게 안내해야 한다는 공식 지침을 제공합니다. 이 문서는 영국 규정에 관한 것이므로 국내 사이트의 법적 충족 여부를 대신 판정하지 않습니다. 다만 폼 화면에 적은 짧은 요약과 전체 개인정보 문서, 실제 처리 흐름이 서로 일치하는지를 확인하는 정보 설계 참고자료로 사용합니다.참고: Information Commissioner’s Office · What privacy information should we provide?
- 폼이 실제로 전송하는 필드와 화면에 설명한 수집 항목이 같은가
- 이메일을 필수로 받는다면 회신 외의 사용 목적이 있는지 명확히 적었는가
- 첨부 기능이 없다면 파일을 보낸다고 오해할 문구가 없는가
- 외부 폼·메일 도구를 쓰면 실제 전달 범위를 문서와 맞췄는가
- 보관과 삭제 문구가 실행할 수 없는 무기한 약속이나 즉시 삭제 보장을 하지 않는가
- 개인정보 관련 문의와 콘텐츠 정정 요청의 경로를 구분해 찾을 수 있는가
제출 실패와 성공을 같은 화면에서 구분하고 대체 연락 경로를 남깁니다
실패한 경우에는 입력을 바로 지우지 말고 고칠 항목이나 재시도 경로를 안내합니다. 성공 문구는 실제 접수된 단계까지만 말합니다. 연습 폼의 입력 검사 완료는 서버 접수와 다릅니다. 화면 상태의 구체적인 연결은 오류 요약과 입력란에서 확인할 수 있습니다.
오류 정정·일반 문의·협찬 제안을 섞지 않아 필요한 정보만 받습니다
모든 요청을 하나의 자유 입력칸으로 받으면 방문자는 무엇을 써야 할지 모르고 운영자는 불필요한 개인정보까지 받기 쉽습니다. 예제는 오류 정정 폼과 일반 이메일 문의를 분리합니다. 실제 사이트가 협찬 제안을 받는다면 제안 범위와 광고 표시 원칙을 먼저 보여 주고 별도 유형을 제공합니다. 선택한 유형에 따라 필요하지 않은 필드는 숨기되, 숨은 필드가 DOM에서 제출되거나 키보드 초점에 남지 않는지도 확인합니다.참고: W3C Web Accessibility Initiative · Understanding Success Criterion 3.3.2: Labels or Instructions · Information Commissioner’s Office · What privacy information should we provide?
| 경로 | 첫 질문 | 최소 입력 | 운영 문서 연결 | 완료 조건 |
|---|---|---|---|---|
| 오류 정정 | 어느 페이지가 잘못됐는가 | 주소·설명 | 수정 원칙 | 접수 상태와 정정 기록 경로 |
| 일반 문의 | 어떤 답이 필요한가 | 제목·내용·회신 이메일 | 개인정보 문서 | 전송 상태와 대체 이메일 |
| 협찬 제안 | 어떤 관계와 대가가 있는가 | 브랜드·제안 내용·회신 이메일 | 광고·제휴 고지 | 표시 기준 확인과 접수 상태 |
| 개인정보 요청 | 열람·정정·삭제 중 무엇인가 | 식별에 필요한 최소 정보 | 개인정보 문서 | 별도 담당 경로 안내 |
경로를 나누는 목적은 메뉴를 복잡하게 만드는 것이 아니라 기대와 입력 범위를 맞추는 것입니다. 실제 운영 인력이 하나라면 한 폼 안에서 유형을 선택하게 할 수 있지만, 선택 전후의 설명과 필수 필드가 일치해야 합니다. 유형 선택만 바뀌고 제출 데이터가 모두 같은 메일 제목으로 들어가면 화면 분류가 실제 처리 흐름과 어긋납니다. 테스트용 제출은 운영자 승인 아래 별도 표식과 비민감 예제 데이터로 수행해야 하며, 이 작성 단계에서는 실제 문의를 전송하지 않습니다.
공개 전에는 내용·입력·전송·회신 기대를 서로 다른 시험으로 확인합니다
문의 유형별로 목적·필수 정보·받지 않는 정보·결과 안내를 한 행에 놓고 폼 필드와 비교합니다. 선택 이메일을 필수로 거절하거나 받지 않는다고 쓴 값을 실제 전송에 넣지 않았는지 봅니다. 실제 전달 과정은 전송·수신·답변의 단계와 나누어 확인합니다.
문의 범위와 개인정보 고지에 사용한 원문
원문별 확인일과 참고 범위를 아래에 표시했습니다. 예제 입력값은 설명을 위한 설정이며 원문 기관의 제품 평가를 뜻하지 않습니다.
- Email addressesGOV.UK Design System · 확인 2026-08-20
이메일 주소를 요청하는 이유, 입력 형식, type·autocomplete·spellcheck와 붙여넣기 허용에 관한 공식 패턴을 참고했습니다.
- Understanding Success Criterion 3.3.2: Labels or InstructionsW3C Web Accessibility Initiative · 확인 2026-08-20
사용자 입력을 요구하는 필드에 충분한 레이블과 지침을 제공해야 한다는 기준을 폼 검수에 적용했습니다.
- What privacy information should we provide?Information Commissioner’s Office · 확인 2026-08-20
개인정보 처리 목적, 보관, 공유, 권리 등의 정보를 투명하게 제공하는 항목을 화면 요약과 전체 문서 대조에 참고했습니다.