필요한 것만 요청하고 요청 이유를 명확히 밝히기
사용자의 즉각적인 과제(task)에서 시작해 그 과제를 완료하는 데 필요한 데이터만 요청하세요. 뉴스레터는 이메일 주소만 필요할 수 있고, 배송에는 배송 주소가 필요합니다. 생년월일, 직함, 또는 번들 마케팅 동의는 자동으로 필요하지 않습니다. 첫 번째 결과에 필요하지 않은 추가 질문은 미루세요.
폼에서는 누가 데이터를 받는지와 목적을 명확히 적고 전체 개인정보 처리방침으로의 쉬운 링크를 제공하세요. UK GDPR의 적용을 받는 조직은 목적과 보유기간을 포함한 투명성 책임이 있으며, 이는 맥락에 따라 달라집니다. 이 내용은 범용적인 법적 조언이 아니므로, 대상 시장에 맞는 수집 및 고지 문구는 적절한 검토자의 승인을 받으세요.
별표(*) 또는 색상만으로는 충분하지 않습니다; 필수 필드와 특이한 형식은 제출 전에 명시하세요.
마케팅 동의 같은 선택적 항목은 주문, 요청 또는 계정 작업을 제출하는 데 필요한 동작과 분리하세요.
레이블과 기본(네이티브) 컨트롤에 맡기기
모든 필드, 체크박스, 라디오 그룹, select, 버튼에는 목적을 설명하는 이름이 필요합니다. 보통 label 요소의 for 값이 input id와 일치하도록 해 가시적 레이블을 컨트롤에 연결하세요. 이렇게 하면 레이블의 활성화 영역이 넓어지고 보조 기술이 올바른 컨트롤을 식별할 수 있습니다. 레이블은 입력과 가깝게 배치하세요.
힌트 텍스트는 필드 이름이 아닙니다. 입력 후 사라지는 유일한 지시문으로 사용하지 마세요. 시각적 문맥 때문에 레이블이 중복처럼 보이더라도 코드상으로 접근 가능한 이름(accessible name)을 유지하고 테스트하세요. W3C는 title 텍스트가 신뢰할 수 있는 기본 레이블 대체 수단이 아니라고 지적합니다.
`email`, `tel`, `date`, radio, checkbox, select 등 해당되는 기본 컨트롤을 사용하고 범용 텍스트 필드로 흉내 내지 마세요.
Submit보다 Create account(계정 생성) 또는 Place order(주문하기) 같은 동작 레이블이 더 명확하면 그걸 사용하세요.
수정 지원을 위한 검증을 하고, 서버에서 규칙을 강제하기
안정적인 검사를 위해 기본 제약조건을 사용하세요: 적절한 input type, `required`, 길이, 범위, 적절한 `pattern`. 오류가 되기 전에 유용한 형식 예시를 제공하세요. 클라이언트 검사는 복구를 개선하지만 보안 경계는 아닙니다. 요청은 우회될 수 있으므로 서버에서 관련 구문 및 비즈니스 규칙을 처리하기 전 반드시 검증하세요.
제출이 실패하면 수락된 값은 보존하세요. 폼 앞에 오류 요약을 두고 각 필드를 식별해 문제와 수정 방법을 설명하며 해당 필드로 링크하세요. 필드 옆에 간결한 메시지를 반복해서 보여주고, 컨트롤과 연관시키며 적절할 때는 invalid 상태를 표시하고 처음 오류나 요약으로 포커스를 예측 가능하게 이동시키세요. 성공은 명시적으로 확인해 주세요.
입력 도중 검증은 사용자에게 안정적이고 유용한 피드백을 줄 때만 사용하세요(예: 사용자명 사용 가능 여부). 입력 중간에는 피할 수 없는 형식 오류는 포커스가 필드를 벗어나거나 제출 시에 검사하는 것이 더 낫습니다. 동적 메시지는 스크린리더로 테스트하세요; 라이브 업데이트는 도움이 되지만 지속적인 간섭은 마찰을 유발합니다.
서버에서 허용되는 날짜, 옵션, 길이, 형식을 명시하세요. 의심스러운 문자를 차단 목록(denylist)에 넣는 것은 신뢰할 수 있는 주된 통제가 아닙니다.
타임아웃이나 중복 제출 시 요청이 수신되었는지 여부를 알리고 안전한 다음 행동을 제시하세요.
브라우저 자동완성(autofill) 및 모바일 입력 지원
given-name, family-name, email, tel, shipping street-address, billing postal-code, username, new-password와 같은 구체적인 autocomplete 토큰을 추가하세요. 토큰은 브라우저와 암호 관리자(password manager)가 유사한 필드를 구분하는 데 도움이 됩니다. 자동완성은 보조 기능이지 보증이 아닙니다; 동작은 다양하며 사용성 좋은 폼, name 또는 id, 제출 컨트롤에 따라 달라질 수 있습니다.
적절한 모바일 키보드를 제공하고 기본 브라우저 검증을 가능하게 하는 input type을 사용하세요. 비밀번호 필드에서 붙여넣기를 차단하거나 암호 관리자를 방해하지 마세요. 최신 브라우저는 로그인 폼에서 autocomplete가 꺼져 있어도 자격 증명 채우기를 제안할 수 있으므로, 대상 사용자가 쓰는 브라우저로 실제 여정을 테스트하세요.
한 페이지에 청구(billing)와 배송(shipping)을 둘 때 동일한 필드가 혼동되지 않도록 해당 그룹화 토큰을 사용하세요.
레이블이 계속 보이는지, 스크립트가 브라우저가 채운 값을 빈 값으로 오인하지 않는지 확인하세요.
키보드만으로 완료 가능한 흐름 만들기
포인터 없이도 폼을 완료할 수 있어야 합니다. 키보드 조작은 음성 입력과 같은 키 입력을 생성하는 다른 보조 기술도 지원합니다. 폼 앞에서 뒤로 탭할 수 있도록 순서는 작업을 따르고 포커스는 가시적이어야 하며 어느 컨트롤, 대화상자, 날짜 선택기, 오류 링크, 도움말 패널도 포커스를 가두어서는 안 됩니다.
기본 컨트롤이 이의 대부분을 제공합니다. 커스텀 드롭다운, 마스킹된 날짜, 주소 조회, CAPTCHA 대체물, 모달은 의도적인 키보드 동작, 포커스 관리, 접근 가능한 이름이 필요합니다. 커스텀 컴포넌트가 사용 가능한 기본 대안을 따라잡을 수 없다면 단순화하세요. 좁은 화면 폭과 고배율(확대)에서 테스트하세요.
Tab, Shift+Tab, Enter, Space, Escape 및 관련 화살표 키로 정상, 오류, 조건부 흐름을 완료하세요.
가드레일과 롤백을 포함해 개선사항 배포하기
가치 있는 폼을 변경하기 전에 확인된 제출 수, 필드 분류별 오류, 기술적 실패, 완료 시간의 기준선(baseline)을 기록하세요. 민감한 원시값을 수집하거나 메트릭 개선을 위해 민감 데이터를 재생(replay)하지 마세요. 집계 신호를 접근성 및 키보드 점검과 짝지어야 합니다. 단일 비율로는 사람들이 왜 어려움을 겪었는지 설명하지 못합니다.
실용적일 때 한 번에 하나의 실질적 변경을 배포하세요(예: 레이블 문구, 선택적 필드 제거, 개선된 복구). 테스트 전 가드레일을 정의하세요: 결제 승인 오류, 지원 연락처, 접근성 회귀 등이 관련될 수 있습니다. 안전한 계정과 결제 테스트 환경으로 프로덕션 구성에서 테스트하세요. 결제 스크립트, 데이터 처리, 컴플라이언스는 적격한 보안·결제·법무 검토가 필요합니다; 이 문서는 준수를 인증하지 않습니다.
SIU는 런치 사전검증(launch preflight)을 통해 더 안전하게 만듭니다: 종속성, 클라이언트 동작, 서버 응답, 확인, 롤백을 확인하세요. 이는 사전적 복구 수단이며 팀의 라이브 상태나 장애 모니터링 프로세스를 대체하지 않습니다.
누락되거나 잘못된 값, 만료된 세션, 느린 응답, 실패한 조회, 마지막 동작의 더블 클릭을 사용하세요.
이전 구성, 담당자, 노출이 증가하기 전 되돌릴 수 있는 배포 단계를 준비하세요.