UI 디자인 키보드 포커스 순서: 작업 중심 설계 가이드

키보드 포커스 순서는 마우스나 터치 없이 인터페이스를 조작할 때 각 컨트롤에 도달하는 순서입니다. 폼을 작성하고, 대화상자를 열고, 오류를 수정한 뒤 적절한 위치로 돌아오는 하나의 작업 흐름을 기준으로 설계하세요. 기본 화면에 번호를 붙이는 것도 도움이 되지만, 그것만으로는 화면이 바뀐 뒤의 동작을 설명할 수 없습니다.

UI 디자인 협업 도구에서 화면을 준비할 때 포커스 동작도 시각적 상태와 함께 기록해 두세요. 이 글에서는 구매 주문서를 예로 들어 어떤 내용을 주석으로 남기고, 컴포넌트에서 무엇을 정하며, 개발자가 실제 페이지에서 무엇을 확인해야 하는지 살펴봅니다.

번호를 붙이기 전에 사용자의 작업부터 정하기

구매 담당자가 주문서를 작성하는 상황을 생각해 보겠습니다. 화면에는 공급업체, 배송지, 주문 항목, 선택 입력 메모와 검토 버튼이 있습니다. 주문 요약은 데스크톱에서는 폼 옆에, 모바일에서는 아래에 놓입니다. 담당자가 공급업체를 고르고 배송지를 확인한 뒤 품목을 입력하는 동안, 관련 필드 사이에서 갑자기 요약 영역으로 포커스가 이동해서는 안 됩니다.

컨트롤에 번호를 붙이기 전에 묶음을 정하세요. 공급업체와 배송지는 배송 정보 묶음이고, 품목·수량·단가는 주문 항목 한 줄에 속합니다. 소계는 정보이므로 눈에 잘 띈다는 이유만으로 Tab 키로 방문하는 지점이 될 필요는 없습니다. 반면 공급업체 상세 정보를 여는 링크는 행동을 수행하는 요소이므로 탐색 순서 안에 있어야 합니다. 보이는 라벨마다 모두 포커스를 받게 하면 간단한 작업에도 불필요한 이동이 늘어납니다.

WCAG의 포커스 순서 안내(영문)는 의미와 조작 가능성을 유지하는 순서를 요구하지만, 모든 화면에 적용할 단 하나의 시각적 순서를 정하지는 않습니다. 레이아웃이 달라질 때도 이 차이를 기억하세요. 번호가 완벽한 직선으로 이어지는지보다 사용자가 내용을 이해하고 작업을 마칠 수 있는지가 중요합니다.

Tab 이동과 컨트롤 내부 이동 구분하기

일반적으로 Tab 키는 컨트롤 사이를 이동합니다. 일부 복합 컨트롤에서는 방향키로 내부 항목을 탐색합니다. 공급업체 콤보박스라면 추천 목록을 열고, 항목 사이를 이동하고, 선택을 확정하고, 선택하지 않은 채 나오는 동작을 정해야 합니다. 모든 추천 항목을 페이지의 고정된 Tab 순서에 하나씩 넣지 마세요.

포커스 표시, 선택 상태, 마우스 호버 상태는 서로 다른 정보를 전달합니다. 디자인에서도 구분해서 보여 주세요. 키보드 포커스가 수량 필드로 이동해도 선택한 공급업체는 그대로 선택되어 있을 수 있습니다. 두 상태를 똑같이 표현하면 검토자가 저장된 값과 현재 키보드 위치를 혼동할 수 있습니다.

대화상자의 진입과 복귀를 모두 정하기

구매 담당자가 ‘배송지 변경’을 실행합니다. 대화상자에는 적절한 초기 포커스 위치, 내부 탐색 순서, 닫은 뒤 돌아갈 위치가 필요합니다. 짧은 수정 폼에서는 첫 필드가 적절할 수 있습니다. 설명이 긴 대화상자라면 제목이나 안내 내용을 먼저 접하게 해야 할 수도 있습니다. 첫 번째 버튼이 언제나 정답인 것이 아니라, 수행할 작업과 전달할 정보에 따라 결정해야 합니다.

WAI-ARIA 모달 대화상자 패턴(영문)은 모달이 열려 있는 동안 키보드 탐색이 그 안에서 이루어지고, 닫힌 뒤에는 적절한 위치로 포커스가 돌아가도록 설명합니다. 저장, 취소, Escape 동작을 각각 기록하세요. 저장하면 주문 작업을 이어 갈 수 있는 위치로 돌아가야 하고, 취소하면 이전 배송지가 유지되어야 합니다.

이 예에서는 다음처럼 적을 수 있습니다. ‘열기: 기본 주소 필드에 포커스. 취소 또는 Escape: 요약을 바꾸지 않고 배송지 변경 버튼으로 복귀. 저장: 요약을 업데이트하고 대화상자를 닫은 뒤 배송지 변경 버튼으로 복귀.’ 저장 후 그 버튼이 화면에서 사라지는 설계라면 남아 있는 다른 목적지를 지정해야 합니다. 더 이상 존재하지 않는 요소를 화살표로 가리키는 것은 동작 명세가 아닙니다.

행 추가·오류·좁은 화면의 변화까지 설계하기

주문서에는 ‘품목 추가’ 버튼도 있습니다. 행을 추가한 뒤 새 품목 필드로 포커스를 옮길지, 추가 버튼에 유지할지 정하세요. 새 내용을 명확히 알려 준다면 새 행으로 이동하는 방식은 바로 입력하기에 유용합니다. 여러 행을 연속으로 추가하는 작업이라면 버튼에 포커스를 유지하는 방식이 적합할 수 있습니다. 어느 쪽이든 의도한 작업 흐름을 설명해야 합니다.

삭제도 같은 주의가 필요합니다. 포커스가 있던 삭제 버튼이 행과 함께 사라진다면 유용한 위치로 이동해야 합니다. 다음 행의 같은 컨트롤, 다음 행이 없을 때 이전 행, 목록이 비었을 때 품목 추가 버튼처럼 경우를 나눠 정하세요. ‘포커스 복귀’라고만 쓰지 말고 세 가지 상황을 구체적으로 기록합니다.

검토 버튼을 눌렀을 때 여러 오류가 발견된다면, 사용자가 오류를 알아차리고 각각의 필드에 도달하는 경로도 정해야 합니다. 오류 요약에서 누락된 공급업체와 잘못된 수량 필드로 연결할 수 있습니다. 값을 하나 수정했다고 사용자를 갑자기 다음 오류로 이동시키지는 마세요. 피드백이 갱신되어도 현재 작업은 안정적으로 이어져야 합니다.

모바일에서는 주문 요약이 필드 아래로 이동합니다. 개발자와 함께 의도한 읽기 순서와 포커스 순서를 비교하세요. CSS로 시각적 배치를 바꿔도 문서 순서는 그대로일 수 있습니다. 디자인 파일만으로 실제 브라우저의 탐색 순서를 입증할 수는 없고, 좁은 화면의 캡처 한 장만으로도 이 차이를 알아내기 어렵습니다.

Pixso에서 포커스 명세 만들기

기본 주문서, 배송지 대화상자, 행 추가, 행 삭제, 입력 오류 상태를 하나의 Pixso 파일에 배치합니다. 프레임마다 같은 공급업체와 품목을 사용해 데이터 변화가 아니라 탐색 동작에 집중할 수 있게 하세요. 컨트롤의 라벨을 가리지 않는 위치에 번호 주석을 붙입니다.

각 상태 전환 옆에 실행 계기, 이동 위치, 유지할 정보를 적습니다. 예를 들면 ‘중간 행 삭제 → 다음 행의 삭제 버튼으로 이동, 남은 품목의 수량 유지’라고 적을 수 있습니다. 복합 컨트롤 내부의 이동에는 다른 주석 표현을 사용해 페이지 수준의 Tab 순서와 혼동하지 않게 합니다. 프로토타입으로 시각적 상태를 연결해 흐름을 논의하되, 구현에 필요한 키보드 동작은 명시적으로 기록하세요.

아직 정하지 못한 동작은 해당 컴포넌트나 화면에 연결해 남기세요. ‘마지막 행을 삭제한 뒤 포커스는 어디로 이동해야 하나요?’는 유용한 리뷰 질문입니다. ‘접근성을 개선해 주세요’만으로는 결정할 내용과 확인할 조건이 드러나지 않습니다.

구현된 인터페이스에서 실제 경로 확인하기

먼저 마우스를 클릭하지 않고 키보드로 구매 작업을 시작합니다. 앞뒤로 이동하고, 대화상자를 열고 닫고, 행을 추가·삭제하고, 입력이 덜 된 상태로 제출해 보세요. 포커스가 실제로 어디에 놓이며 표시가 계속 보이는지 관찰합니다. 좁은 뷰포트와 확대 상태에서도 반복하세요. 고정된 버튼 영역이 포커스가 있는 컨트롤을 가려서는 안 됩니다.

문제를 발견하면 시작 상태, 누른 키, 예상 위치, 실제 위치, 작업에 미친 영향을 재현 가능한 순서로 기록합니다. 대화상자를 닫은 뒤의 복귀를 확인한 브라우저 테스트는 화살표가 그럴듯한 캡처보다 강한 근거입니다. 디자인 주석으로 원하는 동작에 합의하고, 실제 인터페이스로 그 동작이 구현되었는지 확인하세요.

Pixso에서 다음 화면의 포커스 경로 설계하기