중요하지만 긴급하지 않은 일, 웹 접근성

1. 시맨틱 HTML이 접근성의 기반

스크린 리더는 HTML 태그의 암묵적 역할을 해석합니다. `<button>`은 '버튼' 역할을 자동으로 갖지만 `<div onClick>`은 스크린 리더에 역할·포커스·키보드 상호작용이 없습니다. 올바른 태그를 사용하면 ARIA 없이도 접근성의 상당 부분을 확보할 수 있습니다.

핵심 용어

2. ARIA의 올바른 사용

ARIA 규칙 1번: 네이티브 HTML로 해결 가능하면 ARIA를 쓰지 마세요. ARIA는 HTML이 표현할 수 없는 복잡한 위젯(커스텀 드롭다운, 탭, 모달)을 스크린 리더에게 설명할 때만 사용합니다. aria-label로 버튼에 의미 있는 이름을 붙이고, aria-expanded로 상태를 알리며, aria-live로 동적 콘텐츠 변화를 알립니다.

핵심 용어

3. 자동화 검증 도구

axe-core와 Lighthouse 접근성 감사를 CI에 통합하면 접근성 회귀를 자동으로 감지할 수 있습니다. Playwright에서 `@axe-core/playwright`를 사용하면 E2E 테스트 실행 중에 접근성 위반을 검출합니다. 단, 자동화 도구는 전체 접근성 이슈의 30~40%만 잡을 수 있어 수동 스크린 리더 테스트를 병행해야 합니다.

핵심 용어

Q1. ARIA와 시맨틱 HTML의 관계를 설명하고, ARIA를 사용해야 하는 경우를 예를 들어 설명해주세요.

힌트

[감점 답변] 정의만 반복하거나 "ARIA와 시맨틱 HTML의 관계를 설명하고, ARIA를 사용해야 하는 경우를 예를 들어 설명해주세요."에 대해 장단점 없이 단편적으로 답하면 감점 포인트입니다. 면접관은 실무 적용 경험이 부족하다고 판단합니다. [좋은 답변] ARIA는 HTML을 보완하는 도구이지 대체제가 아닙니다. `<button>` 대신 `<div role='button'>`을 쓰면 포커스와 키보드 이벤트를 직접 구현해야 합니다. ARIA가 필요한 경우: 탭 패널, 아코디언, 커스텀 드롭다운처럼 HTML에 해당 요소가 없는 복잡한 위젯을 만들 때입니다.

Q2. 웹 접근성을 프로젝트 초기부터 고려하지 않았을 때 발생하는 문제는 무엇인가요?

힌트

[감점 답변] 정의만 반복하거나 "웹 접근성을 프로젝트 초기부터 고려하지 않았을 때 발생하는 문제는 무엇인가요?"에 대해 장단점 없이 단편적으로 답하면 감점 포인트입니다. 면접관은 실무 적용 경험이 부족하다고 판단합니다. [좋은 답변] 기술적 부채 측면: 나중에 추가하려면 컴포넌트 구조를 대거 수정해야 합니다. 비즈니스 측면: 법적 의무(미국 ADA, 유럽 EAA), 잠재 사용자 손실(전 세계 장애인 인구 15%). 팀 문화 측면: 접근성을 코드 리뷰 체크리스트에 없으면 지속되지 않습니다.

Q3. 키보드만으로 커스텀 모달을 접근 가능하게 만들려면 어떻게 해야 하나요?

힌트

[감점 답변] 정의만 반복하거나 "키보드만으로 커스텀 모달을 접근 가능하게 만들려면 어떻게 해야 하나요?"에 대해 장단점 없이 단편적으로 답하면 감점 포인트입니다. 면접관은 실무 적용 경험이 부족하다고 판단합니다. [좋은 답변] 포커스 트랩(modal 내부에서만 Tab이 순환), 열릴 때 첫 포커스 요소로 이동, 닫힐 때 트리거 버튼으로 포커스 복귀, ESC로 닫기, `role='dialog'` + `aria-modal='true'` + `aria-labelledby`로 스크린 리더에게 모달임을 알려야 합니다.