웹 접근성 미드레벨 기술면접
새 면접Q. ARIA(Accessible Rich Internet Applications)의 5가지 주요 규칙(rules)에 대해 설명하고, 실무에서 ARIA 속성을 과도하게 사용하는 것이 오히려 접근성을 해칠 수 있는 이유를 설명해주세요.
시맨틱 HTML을 먼저 고려하고, ARIA는 보완적으로 사용해야 하는 이유를 생각해보세요.
ARIA의 5가지 규칙은 1) 시맨틱 HTML을 사용할 수 있다면 ARIA를 사용하지 말 것, 2) 네이티브 요소의 의미를 변경하지 말 것, 3) 모든 인터랙티브 요소는 키보드로 접근 가능해야 할 것, 4) role='presentation'이나 aria-hidden='true'를 포커스 가능한 요소에 사용하지 말 것, 5) 모든 인터랙티브 요소는 접근 가능한 이름을 가져야 할 것입니다. ARIA를 과도하게 사용하면 스크린 리더 사용자에게 불필요한 정보를 제공하여 오히려 혼란을 야기하고, 브라우저의 네이티브 접근성 기능과 충돌할 수 있습니다. 또한 ARIA 속성은 시각적 동작을 자동으로 제공하지 않아 개발자가 JavaScript로 모든 동작을 직접 구현해야 하므로 유지보수가 어렵고 버그 발생 가능성이 높아집니다.
- • 시맨틱 HTML 우선 사용
- • ARIA는 보완적 수단
- • 과도한 사용 시 스크린 리더 혼란
- • 키보드 접근성 보장 필수
복잡한 SPA에서 커스텀 컴포넌트를 만들 때 네이티브 요소를 최대한 활용하고 필요한 경우에만 ARIA로 보완하는 설계 결정을 내릴 때 사용됩니다.
aria-label과 aria-labelledby의 차이점과 각각을 사용하기 적합한 상황을 설명해주세요.
Q. 포커스 관리(Focus Management)가 중요한 이유를 설명하고, SPA(Single Page Application)에서 페이지 전환 시 포커스를 적절히 관리하는 전략과 Tab 트랩(Focus Trap)을 구현해야 하는 상황 및 구현 방법을 설명해주세요.
모달이나 다이얼로그 같은 오버레이 UI와 동적 콘텐츠 로딩 상황을 고려해보세요.
포커스 관리는 키보드 사용자와 스크린 리더 사용자가 현재 위치를 파악하고 순차적으로 탐색할 수 있게 하는 핵심 요소입니다. SPA에서 페이지 전환 시에는 새로운 콘텐츠의 메인 제목(h1)이나 컨테이너에 tabindex='-1'을 설정하고 프로그래밍 방식으로 포커스를 이동시켜야 하며, 이전 페이지의 스크롤 위치를 초기화해야 합니다. Tab 트랩은 모달, 다이얼로그, 드롭다운 메뉴처럼 사용자가 특정 컨텍스트 안에서만 상호작용해야 하는 오버레이 UI에서 필수적입니다. 구현 방법은 포커스 가능한 요소들을 querySelectorAll로 찾아 첫 요소와 마지막 요소를 식별한 후, 마지막 요소에서 Tab 키 입력 시 첫 요소로, 첫 요소에서 Shift+Tab 입력 시 마지막 요소로 포커스를 순환시키며, 모달이 닫힐 때는 모달을 열기 전 포커스 위치로 복원해야 합니다.
- • SPA 페이지 전환 시 포커스 이동
- • Tab 트랩은 오버레이 UI에서 필수
- • 포커스 순환 구현
- • 모달 종료 시 이전 포커스 복원
React나 Vue로 만든 SPA에서 라우팅 변경 시 포커스를 적절히 관리하고, 모달 컴포넌트에서 키보드 사용자가 모달 외부로 벗어나지 않도록 구현할 때 사용됩니다.
Skip Navigation 링크의 목적과 구현 방법, 그리고 최근의 대안적 접근 방법에 대해 설명해주세요.
Q. WCAG 2.1의 색상 대비 기준(AA, AAA)을 설명하고, 실무에서 디자이너가 제공한 디자인이 색상 대비 기준을 충족하지 못할 때 어떤 방식으로 문제를 해결할 수 있는지 구체적인 전략을 제시해주세요.
대비율 계산 도구와 색상 조정 외에 다른 시각적 단서를 추가하는 방법도 고려해보세요.
WCAG 2.1 AA 기준은 일반 텍스트(18pt 미만)에 대해 4.5:1 이상, 큰 텍스트(18pt 이상 또는 14pt 굵은 글씨)에 대해 3:1 이상의 대비율을 요구하며, AAA 기준은 각각 7:1과 4.5:1입니다. 디자인이 기준을 충족하지 못할 때는 먼저 Contrast Checker 같은 도구로 현재 대비율을 측정하고 디자이너와 협의하여 색상의 명도를 조정합니다. 브랜드 색상을 유지해야 한다면 텍스트 크기를 키우거나 굵기를 조정하고, 색상만으로 정보를 전달하지 않도록 아이콘, 텍스트 레이블, 패턴을 추가합니다. CSS 미디어 쿼리 prefers-contrast를 활용해 고대비 모드 사용자를 위한 대체 스타일을 제공하거나, 사용자가 직접 테마를 선택할 수 있는 옵션을 제공하는 것도 좋은 전략입니다.
- • AA 기준 4.5:1, AAA 기준 7:1
- • 대비율 측정 도구 활용
- • 색상 외 추가 시각 단서 제공
- • prefers-contrast 미디어 쿼리 활용
디자인 시스템을 구축할 때 컬러 팔레트를 정의하거나, 버튼과 링크의 색상을 선택할 때 접근성 기준을 충족하는지 검증하는 데 사용됩니다.
색맹 사용자를 위한 디자인 고려사항과 색상에만 의존하지 않는 UI 설계 원칙을 설명해주세요.
Q. 동적으로 변경되는 콘텐츠(예: 알림 메시지, 검색 결과 업데이트, 로딩 상태)를 스크린 리더 사용자에게 적절히 전달하기 위한 ARIA Live Region의 종류와 각각의 사용 사례를 설명하고, 실무에서 발생할 수 있는 주의사항을 설명해주세요.
aria-live의 polite, assertive, off 값과 aria-atomic, aria-relevant 속성의 역할을 생각해보세요.
ARIA Live Region은 aria-live 속성으로 구현하며 polite, assertive, off 세 가지 값이 있습니다. polite는 스크린 리더가 현재 읽고 있는 내용을 끝낸 후 알림을 전달하며 검색 결과나 폼 검증 메시지에 적합하고, assertive는 즉시 중단하고 알림을 전달하므로 긴급한 오류나 타이머 종료 같은 중요한 정보에 사용합니다. role='status'는 aria-live='polite'와 동일하며, role='alert'는 aria-live='assertive'와 동일합니다. aria-atomic='true'는 변경된 부분만이 아닌 전체 영역을 읽도록 하고, aria-relevant는 어떤 변경사항을 알릴지 제어합니다. 주의사항으로는 Live Region이 DOM에 미리 존재해야 변경사항이 감지되므로 초기 렌더링 시 빈 요소로 배치해야 하고, 너무 빈번한 업데이트는 사용자 경험을 해치므로 debounce를 적용하며, 시각적으로 숨길 때는 display:none이 아닌 sr-only 클래스를 사용해야 합니다.
- • polite는 비긴급 알림, assertive는 긴급 알림
- • Live Region은 DOM에 미리 존재해야 함
- • 빈번한 업데이트 시 debounce 적용
- • sr-only로 시각적 숨김 처리
실시간 채팅 애플리케이션에서 새 메시지 알림, 폼 검증 오류 메시지 표시, 비동기 데이터 로딩 상태를 스크린 리더 사용자에게 전달할 때 사용됩니다.
무한 스크롤이나 가상 스크롤이 구현된 목록에서 스크린 리더 사용자를 위한 접근성을 보장하는 방법을 설명해주세요.
Q. 웹 접근성을 검증하기 위한 자동화 도구(axe-core, Lighthouse 등)의 한계점을 설명하고, 실무에서 수동 테스트가 반드시 필요한 영역과 효과적인 접근성 테스트 프로세스를 제안해주세요.
자동화 도구는 기술적 기준만 검증할 수 있고, 실제 사용자 경험은 수동으로 확인해야 합니다.
자동화 도구는 WCAG 기준의 약 30-40%만 검증할 수 있으며, 색상 대비나 alt 속성 누락 같은 기술적 오류는 찾을 수 있지만 맥락에 맞는 대체 텍스트인지, 포커스 순서가 논리적인지, 콘텐츠가 이해하기 쉬운지는 판단할 수 없습니다. 수동 테스트가 필수인 영역은 키보드만으로 전체 기능 사용해보기, 스크린 리더로 실제 탐색 경험 확인하기, 확대/축소 시 레이아웃 깨짐 확인하기, 폼 제출 흐름의 논리성 검증입니다. 효과적인 프로세스는 개발 단계에서 eslint-plugin-jsx-a11y 같은 린터로 1차 검증하고, PR 단계에서 axe DevTools로 자동 검사를 수행하며, QA 단계에서 키보드와 스크린 리더로 핵심 시나리오를 수동 테스트하고, 정기적으로 실제 장애인 사용자 테스트를 진행하는 것입니다.
- • 자동화 도구는 30-40%만 검증 가능
- • 맥락과 사용성은 수동 테스트 필수
- • 개발-PR-QA 단계별 검증 프로세스
- • 실제 사용자 테스트 병행
스프린트마다 새로운 기능을 배포하기 전에 접근성 회귀를 방지하고, 접근성 기준을 충족하는지 체계적으로 검증하는 품질 관리 프로세스를 구축할 때 사용됩니다.
CI/CD 파이프라인에 접근성 테스트를 통합할 때 고려해야 할 사항과 추천하는 도구를 설명해주세요.
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!