강북 병원 홈페이지에서 진료별 설명을 나누고, 문의 양식 근처에 ‘진료 안내 더 보기’를 배치했다고 가정해 보겠습니다. 독자는 설명 페이지로 이동하려고 눌렀는데 필수 입력 안내가 뜨거나 문의 제출이 시작될 수 있습니다. 버튼에 어떤 글자를 적었는지만으로 브라우저의 동작이 정해지는 것은 아닙니다. 실제 요소가 링크인지, 양식에 연결된 제출 버튼인지부터 확인해야 합니다.
HTML의 button 요소에는 동작을 정하는 type 속성이 있습니다. submit은 양식 제출용이고 button은 그 자체로 양식을 제출하는 기본 동작이 없는 종류입니다. 여기서 살펴볼 조건은 문의 form 안에 있는 일반적인 button이며, command와 commandfor 속성이 없고 select 요소의 자식도 아닌 경우입니다. 이런 버튼에서 type을 생략하면 제출 버튼으로 해석될 수 있습니다. 화면 문구를 ‘진료 안내’로 바꾸거나 색상을 달리해도 이 조건이 자동으로 사라지지는 않습니다.
가상의 구현을 비교해 보겠습니다. 문의 form 안에 type을 생략한 ‘다른 진료 보기’ 버튼을 둔 경우에는 사용자가 눌렀을 때 양식 제출 절차가 시작될 수 있습니다. 같은 자리의 버튼에 type="button"을 명시하면 그 요소 자체의 기본 제출 동작은 없어집니다. 다만 이것만으로 다른 페이지가 열리지는 않습니다. 별도의 화면 동작을 구현했다면 그것이 무엇인지도 확인해야 합니다. 이 비교는 특정 강북 병원에서 실제로 발생한 장애 사례가 아니라, 문구가 같아도 HTML 조건에 따라 기능이 달라지는 상황을 설명한 것입니다.
별도 URL에 있는 진료 설명으로 이동하는 목적이라면 목적지 주소를 가진 a 요소의 링크를 검토할 수 있습니다. 반대로 같은 화면의 안내 영역을 여닫는 기능이라면 제출용이 아닌 버튼과 그 기능을 연결해야 합니다. 중요한 것은 모든 버튼을 한꺼번에 같은 종류로 바꾸는 일이 아닙니다. 실제 문의를 보내는 버튼은 제출 기능이 필요하고, 진료 설명을 읽는 선택은 그 행동만 수행해야 합니다.
빈 양식으로 한 번 눌러 보고 ‘아무 문의도 전송되지 않았다’고 결론내리는 검수에도 빈틈이 있습니다. 제출 버튼의 기본 동작이 시작돼도 필수 입력값 검사에서 멈출 수 있기 때문입니다. 독자는 진료 안내를 보려 했는데 이름이나 연락처 입력을 요구받을 수 있습니다. 값이 채워진 조건에서는 다른 결과가 나올 수 있으므로, 전송 여부뿐 아니라 왜 입력 검사가 시작됐는지도 확인해야 합니다. 실제 환자 정보를 넣는 대신 외부 접수로 이어지지 않는 별도 시험 환경에서 담당자가 재현하는 방식이 적절합니다.
type="button"을 적었다고 모든 제출 가능성을 없앴다고 단정해서도 안 됩니다. 사이트에 추가한 스크립트가 양식을 제출하도록 작성돼 있을 수 있습니다. 점검에서는 요소의 기본 동작과 별도로 연결된 동작을 함께 봅니다. 또한 화면상 양식 바깥에 있어도 form 속성으로 특정 양식과 연결될 수 있으므로, 보이는 위치만으로 관련이 없다고 판단하지 않습니다.
진료별 페이지가 서로 다른 정보를 잘 담았더라도 그 사이를 이동하는 선택이 문의 제출로 처리되면 독자는 필요한 설명을 읽기 어렵습니다. 이 문제의 수정 기준은 버튼의 모양이 아니라 행동의 일치입니다. ‘진료 안내 더 보기’는 안내를 열고, ‘문의 보내기’는 사용자가 확인한 내용을 제출하도록 각각 시험해야 합니다. 안내를 읽는 과정에서 개인 정보를 먼저 요구하는 동작이 남아 있다면 페이지 분리가 끝났다고 보기 어렵습니다.
근거 자료: WHATWG HTML Standard의 button 요소(type의 상태·제출 버튼 조건·form 연결) 및 a 요소의 href 설명. https://html.spec.whatwg.org/multipage/form-elements.html#the-button-element , https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-a-element