이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
저는 캡스톤 프로젝트에서 팀 웹사이트 퍼블리싱을 혼자 맡았는데, 처음에는 div 남발로 구조를 잡았다가 스크린리더 테스트에서 내비게이션이 전혀 읽히지 않는 걸 뒤늦게 알았습니다. 그때부터 header, main, nav, footer 같은 시맨틱 태그를 의식적으로 쓰고, 이미지에는 빠짐없이 대체 텍스트를 달았습니다. 색 대비는 WCAG 4.5:1 기준을 맞추려 팔레트를 세 번 바꿨고, 그 과정에서 디자이너와 "시각적으로 예쁜 회색이 접근성 기준 미달"이라는 충돌도 있었습니다. 결국 접근성 계층 구조를 함께 보여 주면서 대비 높인 버전으로 합의했습니다. 지금은 HTML 초안을 쓸 때부터 시맨틱 구조와 탭 이동 순서를 먼저 그리는 습관이 생겼고, 마크업이 끝나면 키보드만으로 전체를 돌아보는 과정을 꼭 거칩니다.
인턴 기간 중 회사 랜딩 페이지 리뉴얼을 맡았을 때, 사이트를 탭 키로만 이동해 보니 포커스 인디케이터가 아예 없어 어느 요소가 선택됐는지 알 수 없었습니다. 처음에는 이게 얼마나 심각한 문제인지 잘 몰랐는데, 사내 세미나에서 저시력 사용자가 키보드에 의존해 사이트를 쓴다는 걸 알게 된 후 태도가 바뀌었습니다. 버튼·링크·폼 요소 전체에 포커스 스타일을 적용했고, 스킵 내비게이션 링크도 추가했습니다. 막히는 부분은 MDN 웹 접근성 문서를 찾아가며 해결했는데, 예상보다 수정 범위가 넓어서 3일 일정이 5일로 늘어났습니다. 그 경험 이후 새 컴포넌트를 만들 때 키보드 접근성을 처음부터 체크리스트에 넣게 됐습니다.
학교 수업에서 포트폴리오 사이트를 만들면서 시각 효과와 웹표준 사이에서 꽤 갈등했습니다. 애니메이션 전환을 여러 겹 쌓았더니 모션에 민감한 사용자에게 불편할 수 있다는 피드백을 받았고, 처음에는 이 설정 자체를 몰라서 당황했습니다. 미디어 쿼리로 움직임 최소화 분기를 추가하고, 폰트도 가변 폰트 하나로 줄여 불필요한 네트워크 요청을 줄였습니다.
Lighthouse 접근성 점수가 72에서 91로 오른 걸 보고, 표준을 지키는 게 성능과 접근성을 동시에 잡는다는 걸 체감했습니다. 지금은 디자인 시안을 받으면 움직임 기준과 색 대비 비율을 먼저 확인하는 버릇이 생겼고, 시각적으로 예쁜 것도 중요하지만 기준선을 지키는 쪽이 장기적으로 더 낫다는 생각을 합니다. 혼자 작업할 때는 타협하기 쉽지만, 코드 리뷰나 접근성 자동 검사가 있으면 일관성을 유지하는 데 도움이 된다는 것도 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 incross UX/UI 디자이너 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.