HTML 우선 접근은 공공 서비스 신청 폼을 자바스크립트 없이도 작동하게 만들고, 열악한 기기·브라우저·네트워크에서도 사용자가 신청을 완료할 수 있게 함

• 기존 React 앱은 고객 불만으로 3일 만에 내려갔고, 로딩 스피너·전역 자바스크립트 상태·접근성 문제·
  localStorage

5MB 한계에 걸린 이미지 저장 방식이 문제였음

• 새 구현은 Astro 기반으로 각 폼 단계를 별도 페이지로 만들고, 제출 데이터와 업로드를
  백엔드 세션에 단계마다 저장해 입력 데이터 손실을 막음
• 폼 검증은 브라우저 내장 HTML 검증을 감싼 웹 컴포넌트로 처리했고, 실패 시 브라우저 기본 검증과 백엔드 API 검증으로 이어지는
  점진적 향상 구조를 사용함
• 출시 후 폼 완료자가 두 배로 늘었고, 자바스크립트 실패로 이탈한 사용자는 자바스크립트 기반 분석 패키지에 잡히지 않는다는 점이 드러남

문제 배경과 실패한 이전 시도

• 고객은 유틸리티 회사였고, 서비스 신청은 웹사이트의 오래된 ASP 폼이나 수동 절차를 통해 가능했음
• 수동 절차는 회사에 더 비쌌고, 고객 만족도가 96% 아래로 떨어지면 수백만 파운드 벌금이 발생할 수 있는 규제 독점 상황이었음
• 문제 해결을 위한 이전 시도는 두 번 실패했고, 가장 최근 시도에서는 다른 나라의 계약자들이 React 앱을 만들었음
• React 앱은 온라인 공개 3일 뒤 고객 불만 때문에 내려갔음
• 해당 앱은 로딩 스피너와 전역 자바스크립트 상태가 뒤섞여 있었고, 접근성을 갖추지 못했음
• 이미지 업로드가 폼의 핵심 기능이었지만, 이미지와 모든 폼 데이터를 5MB 제한이 있는
  localStorage

에 저장하려 했음

HTML 우선으로 정한 기준

• 새 사이트는 Astro로 구축됐고, HTML 우선 구조를 채택함
• 자바스크립트는 웹 컴포넌트 안에서만 사용됐고, 자바스크립트 없이도 정상 작동하는 웹사이트를 점진적으로 개선하는 역할을 맡음
• 공공 서비스는 가능한 모든 기기에서 작동해야 한다는 기준이 적용됨
• 연결 상태가 나빠도 작동해야 한다는 기준이 적용됨
• 한 번 입력된 폼 데이터는 절대 사라지지 않아야 한다는 기준이 적용됨
• Terence Eden의 사례는 GOV.UK의 단순 HTML 페이지가 느리고 메모리 부족이 잦은 PlayStation Portable 브라우저에서도 주거 급여 정보를 읽을 수 있게 했다는 점을 보여줌
• GOV.UK 페이지는 가볍게 설계된 단순 HTML로 작성됐고, 형편없는 브라우저에서도 작동해야 했음

폼 구조와 데이터 보존 방식

• 폼의 각 세션은 고유 ID를 가져야 했음
• 폼 마법사의 모든 단계에서 제출 데이터와 업로드 파일은 백엔드에 저장돼야 했음
• 자바스크립트 없이도 폼 완료가 가능해야 했음
• 오래되고 성능이 낮은 웹 브라우저에서도 폼 완료가 가능해야 했음
• 접근성은 WCAG 기준을 충족해야 했고, 팀은 AAA가 아니라 AA를 목표로 정했음
• 자바스크립트와 최신 CSS는 경험을 향상하는 데 사용돼야 했음
• 최종 구조에서는 폼 마법사의 각 단계가 별도 페이지가 됐고, 사용자가 다음을 누르면 폼이 제출됐음
• API가 데이터를 유효하다고 판단하면 브라우저가 다음 단계로 리디렉션됐음
• 폼 제출과 리디렉션은 오래된 웹 애플리케이션 패턴이며, Remix 덕분에 작은 현대적 부흥을 겪었음
• 이 서비스는 실시간 데이터를 보여주는 앱이 아니라 큰 폼이었고, 렌더링 전에 20MB 자바스크립트를 보내는 방식은 부적절했음

폼 검증과 점진적 향상

• 폼 검증과 폼 오류 렌더링은 React 검증 라이브러리 때문에 팀들이 여러 인월을 쓰는 영역으로 다뤄짐
• 브라우저에는 이미 검증 시스템이 포함돼 있고, 별도 라이브러리 관리가 필요한 낮은 품질의 모방 구현보다 적은 작업으로 활용 가능함
• 구현된 HTML 웹 컴포넌트는 기존 HTML을 감싸는 단순한 커스텀 요소였음
• 이 웹 컴포넌트는 섀도 DOM을 쓰지 않았고, 자바스크립트 안에서 HTML을 거의 렌더링하지 않았음
• 컴포넌트는 HTML 폼을 감싸고 HTML 검증을 가져와 현대적인 형태로 표시했음
• HTML 검증 팝업 툴팁은 막고, 필드와 연결된
  aria-describedby

요소 안에 오류를 배치했음

• 현재는
  aria-errormessage

사용이 권장됨

• 입력 중 유효한 상태가 되면 검증을 지우고,
  blur

와 제출 시점에 다시 평가했음

• 이 사용자 경험은 1KB 미만으로 제공됐고, 실패 시 브라우저 기본 검증으로 되돌아갔음
• 브라우저 기본 검증도 실패하면 백엔드 API가 검증을 처리했음
• 검증 문제는 사용자의 브라우저가 허용하는 가장 이른 시점에 알려졌고, 실패해도 항상 수용 가능한 경험으로 폴백됐음
• 이후 일반 사용을 목표로 새 버전의 웹 컴포넌트가 처음부터 다시 작성됐고, 이름은 validation-enhancer임
• 사용 예시는
  validation-enhancer

가 HTML 폼을 감싸고, input type="email"

, required

, aria-errormessage

를 그대로 활용하는 구조임

<validation-enhancer>
<form>
<label for="my-email">Email</label>
<input type="email" name="my-email" aria-errormessage="my-email-error" required />
<div id="my-email-error"></div>
<button type="submit">Submit</button>
</form>
</validation-enhancer>

출시 결과와 결론

• 출시 후 폼을 완료한 사람 수가 두 배가 됨
• 분석 담당자들은 이 사용자들이 어디서 왔는지 알지 못했음
• 자바스크립트 기반 분석 패키지는 자바스크립트 실패로 이탈한 사용자를 보지 못함
• 백엔드 세션을 유지하고 사용자 데이터를 절대 잃지 않는 접근은 효과를 냈음
• 한 사례에서는 사용자가 폼을 시작한 지 한 달 뒤 완료했음
• 계약 업무가 끝난 뒤 후임자는 자바스크립트 없이도 항상 작동하는 구조가 팀에 더 많은 일을 만든다고 반응했음
• 오래된 브라우저 사용자, 나쁜 네트워크 연결 사용자, 보조 기술 사용자들을 배제하는 것은 독점 공공 서비스에서 받아들일 수 없음
• 소프트웨어 산업의 확장기에 나타난 거칠고 미성숙한 방식을 계속 밀어붙이는 흐름은 내려놓아야 함
• PlayStation Portable과 3G 연결에서도 작동하는 웹 애플리케이션을 만들면 모든 사용자에게 작동하고, 30년 뒤에도 작동할 수 있음