행동을 분류합니다
서비스 상세로 가기, 문의 위치로 이동, 모달 열기, 선택 변경과 제출을 목록으로 적습니다. 같은 시각 스타일을 써도 역할은 다를 수 있습니다. 방문자가 새 탭 열기나 주소 복사 같은 일반 링크 동작을 기대하는지도 고려합니다.
설계 예시
아래는 역할을 구분하는 단순 예시입니다. 모달 초점과 폼 처리 등 나머지 기능은 별도로 구현하고 검수해야 합니다.
<a href="/contact/">상담 문의 작성하기</a>
<button type="button" aria-controls="demo-quote-panel">견적 요약 열기</button>
<button type="button">선택 초기화</button>
<button type="submit">문의 접수하기</button>
이름과 결과
가정한 예로 ‘시작하기’라는 이름이 여러 곳에서 다른 동작을 하면 독자가 결과를 예측하기 어렵습니다. 목적지와 상태 변화가 드러나는 문구를 검토합니다. 아이콘 버튼은 접근성 이름과 화면의 의미가 맞는지 확인하고 툴팁에만 핵심 설명을 맡기지 않습니다.
검수 순서
- 각 컨트롤의 실제 행동과 요소 역할을 대조합니다.
- Tab·Enter·Space 등 해당 기본 동작을 시험합니다.
- 폼 안 보조 버튼의 제출 부작용을 확인합니다.
- 링크 목적지와 상태·초점 변화의 일치를 봅니다.
disabled 표시만 하고 실제 클릭은 계속 받는지, 링크에 버튼의 비활성 상태를 무리하게 흉내 낸 것인지도 확인합니다. 이벤트 핸들러가 기본 링크 이동을 막는다면 이유와 대체 동작을 검수합니다. 기본 브라우저 기능을 불필요하게 제거하지 않습니다.
완료 기준
시각·보조기술의 이름과 실제 행동이 일치해야 합니다. 자동 검사 통과뿐 아니라 사용자가 핵심 작업을 완료하는지 확인합니다. 공통 버튼 컴포넌트를 바꾸면 문의·계산기·메뉴의 대표 경로를 함께 검수하고 관련 없는 동작까지 일괄 변경하지 않습니다. 클릭 측정은 링크 이동이나 접수 완료와 별도 의미로 유지합니다.
자주 묻는 질문
- div에 클릭 이벤트를 달면 버튼과 같은가요?
- 이름·초점·키보드·기본 동작을 별도로 구현해야 할 수 있습니다. 실제 의미에 맞는 네이티브 요소를 우선 검토하고 스타일만으로 동작이 같다고 보지 않습니다.
- 폼 안의 버튼은 모두 제출용인가요?
- 닫기·초기화·기간 선택은 다른 동작일 수 있습니다. 의도한 유형을 명시하고 키보드와 클릭에서 불필요한 제출이 없는지 확인합니다.
공식 참고자료와 작성 기준
공식 문서는 도구·검색 기능의 근거이며, 위의 점검 순서와 완료 기준은 현랩의 실무 설계 제안입니다. 예시를 실제 고객의 성과나 검색엔진의 보장으로 해석하지 않습니다.