프론트엔드 포트폴리오, 모달의 ‘열기·닫기’로 설계 판단 보여주기

‘모달 컴포넌트를 만들었습니다’라는 설명만으로는 개발자가 무엇을 판단했는지 드러나기 어렵습니다. 작은 기능 하나라도 선택한 이유와 예외 처리를 보여주면, 사용 기술 목록보다 구체적인 프로젝트 설명이 됩니다.

먼저 사용자 흐름을 정해요

아래는 긴 프로젝트 설명을 모달로 보여주는 가상 사례입니다. 실제 수행한 작업이나 성과가 아닙니다.

목표: 목록에서 설명을 읽고, 닫은 뒤 보던 항목부터 계속 탐색한다.

여기서 설명이 길고 별도 링크로 공유해야 한다면 독립 페이지가 더 적합할 수도 있습니다. 포트폴리오에는 모달을 골랐다는 결과뿐 아니라, 검토한 대안과 선택 조건도 남겨보세요.

열기·머무르기·닫기를 나눠 판단해요

W3C APG의 모달 지침을 기준으로 살펴볼 흐름입니다.

① 열기: 포커스를 내부로 옮깁니다. 긴 설명에서 첫 버튼으로 이동하면 본문 시작이 화면 밖으로 밀리는 경우, 상단 제목에 tabindex=-1을 두고 처음 포커스를 받게 하는 방안을 검토합니다.

② 머무르기: Tab과 Shift+Tab이 내부에서 순환하고, 배경 요소는 조작되지 않게 합니다. aria-modal=true라는 의미 표시와 실제 동작 구현은 구분해야 합니다.

③ 닫기: Escape와 눈에 보이는 닫기 버튼을 제공하고, 보통 열었던 버튼으로 포커스를 돌려줍니다. 그 버튼이 사라졌다면 이어서 할 일을 고려한 복귀 위치가 필요합니다.

‘항상 첫 입력칸으로 이동’ 같은 규칙 하나를 모든 모달에 적용하기보다 콘텐츠와 작업 흐름을 보고 결정하세요.

포트폴리오에는 판단 카드 한 장을

다음은 폴리오쉽이 제안하는 정리 양식입니다.

[상황] 사용자가 이 창을 왜 열고, 닫은 다음 무엇을 하나요?

[대안] 별도 페이지와 모달 중 무엇을 비교했나요?

[선택 이유] 첫 포커스와 복귀 위치를 그렇게 정한 이유는 무엇인가요?

[구현 범위] 기존 컴포넌트가 처리하는 동작과 내가 추가한 동작은 각각 무엇인가요?

[예외] 내용 길이 변경, 버튼 제거, 재열기 때 어떤 처리가 필요한가요?

[남은 확인] 어떤 환경이나 보조 기술에서는 아직 검증하지 못했나요?

라이브러리가 제공한 기능을 내가 모두 구현한 것처럼 적지 말고, 실제로 바꾼 설정·코드·테스트를 구분하세요.

화면 캡처보다 흐름을 증거로 남겨요

정지 화면에는 포커스의 이동과 복귀가 보이지 않습니다. 직접 수행했다면 열기부터 닫은 뒤 다음 탐색까지의 짧은 기록을 첨부하고, 사용한 운영체제·브라우저와 확인 날짜를 적어보세요. 수정 전후를 비교할 때는 같은 조건을 사용하세요. 스크린리더 테스트를 하지 않았다면 하지 않았다고 남깁니다. 키보드 점검만으로 전체 접근성 기준을 충족했다고 단정하지 마세요.

공개할 수 없는 회사 코드 대신 허가된 화면이나 직접 만든 연습 예제로 설명할 수 있습니다. 오늘은 모달 하나를 골라 ‘구현했다’ 다음에 ‘왜 이렇게 정했는가’를 세 문장으로 덧붙여보세요. 실제 작업과 앞으로의 개선 계획은 따로 표시하면 됩니다.

출처 및 편집

폴리오쉽 에디터 · 공식 에디토리얼

W3C WAI APG · Dialog (Modal) Pattern ↗