접근 가능한 웹 애플리케이션을 구축하는 방법 — 실무적인 프론트엔드 튜토리얼

접근성 (Accessibility)은 마지막에 덧붙이는 터치가 아니라, 웹의 핵심적인 품질입니다. 처음부터 접근성을 염두에 두고 구축하면, 사용 가능하고 탄력적이며 종종 더 단순한 인터페이스를 만들 수 있습니다.

실무에서의 WCAG

웹 콘텐츠 접근성 지침 (WCAG, Web Content Accessibility Guidelines)은 네 가지 원칙에 따라 요구사항을 구성합니다:

• 인식 가능성 (Perceivable): 콘텐츠를 보거나 들을 수 있어야 함 (예: 이미지에 대한 대체 텍스트, 비디오를 위한 자막).
• 운용 가능성 (Operable): 인터페이스가 다양한 입력 방식과 함께 작동해야 함 (예: 키보드 내비게이션).
• 이해 가능성 (Understandable): 콘텐츠와 동작이 명확하고 예측 가능해야 함.
• 견고성 (Robust): 브라우저 및 보조 기술 (Assistive technologies) 전반에서 작동해야 함.

일반적인 목표:

• Level AA는 대부분의 팀이 목표로 하는 표준입니다.
• 색상 대비 (Color contrast): 일반 텍스트의 경우 최소 $$4.5:1$$, 큰 텍스트의 경우 $$3:1$$.
• 대체 텍스트와 명확한 포커스 상태 (Focus states)를 제공하십시오.

시맨틱 HTML (Semantic HTML) 우선

ARIA를 추가하기 전에 네이티브 요소 (Native elements)를 사용하십시오. 브라우저와 보조 기술은 이미 이들을 이해하고 있습니다.

• 제목 (Headings): 논리적 순서에 따른 <h1>부터 <h6>까지.
• 랜드마크 (Landmarks): <header>, <nav>, <main>, <footer>.
• 컨트롤 (Controls): 동작을 위한 <button>, 내비게이션을 위한 <a>, <input>과 함께 사용하는 <label>.

예시:

<main>
  <h1>계정 설정</h1>
  <form>
...

이것만으로도 추가 코드 없이 레이블 (Labels), 역할 (Roles), 키보드 지원을 제공할 수 있습니다.

ARIA: 대체가 아닌 강화

ARIA (Accessible Rich Internet Applications)는 네이티브 시맨틱 (Native semantics)이 불충분할 때 그 간극을 메워줍니다.

• 역할 (Roles)을 절제하여 사용: role="dialog", role="tablist".
• 상태를 설명하기 위해 속성 (Properties) 사용: aria-expanded="true", aria-selected="false".
• 관계 (Relationships) 사용: aria-labelledby, aria-describedby.

경험 법칙 (Rules of thumb):

• 잘못된 HTML을 수정하기 위해 ARIA를 사용하지 마십시오. HTML을 수정하십시오.
• 네이티브 요소를 사용할 수 있다면, 커스텀 역할 (Custom role)보다 네이티브 요소를 선호하십시오.

예시 (disclosure):

<button aria-expanded="false" aria-controls="faq1" id="faqBtn1">
  반품 정책은 무엇인가요?
</button>
...

키보드 내비게이션 (Keyboard Navigation)

모든 상호작용 요소는 키보드로 사용 가능해야 합니다.

• 논리적인 탭 순서(Tab order)를 보장하세요 (DOM 순서가 중요합니다).
• Tab 키로 앞으로 이동하고, Shift+Tab 키로 뒤로 이동합니다.
• 시각적인 포커스 스타일(Focus styles)을 제공하세요. 대체 수단 없이 아웃라인(Outline)을 제거하지 마세요.
• 일반적인 키를 지원하세요: 버튼 활성화를 위한 Enter/Space, 메뉴 및 탭 이동을 위한 화살표 키.

체크리스트:

• 키보드 트랩(Keyboard traps)이 없을 것.
• 모달(Modals)은 열려 있는 동안 포커스를 가두고(Trap focus), 닫을 때 포커스를 되돌려줄 것.
• 페이지 상단에 건너뛰기 링크(Skip links, 예: “본문 바로가기”)를 제공할 것.

스크린 리더 지원 (Screen Reader Support)

스크린 리더는 구조와 레이블(Labels)에 의존합니다.

• 의미 있는 링크 텍스트를 제공하세요 (“여기를 클릭하세요”와 같은 표현은 피하세요).
• 이미지에는 alt 텍rypt를 사용하세요. 간결하고 목적에 맞게 작성해야 합니다.
• 필요한 경우 라이브 리전(Live regions)을 사용하여 동적 업데이트를 알리세요: aria-live="polite".

예시 (상태 메시지):

<div aria-live="polite" id="status"></div>

사용자가 알 수 있도록 작업이 완료되었을 때 이 요소를 업데이트하세요.

색상 및 대비 (Colour and Contrast)

충분한 대비를 고려하여 디자인하고, 색상에만 의존하지 마세요.

• 본문 텍스트의 경우 $$4.5:1$$ 이상의 대비를 충족하세요.
• 상태를 나타낼 때는 색상과 함께 텍스트나 아이콘을 쌍으로 사용하세요 (예: 오류 + 메시지).
• 포커스 표시기(Focus indicators)와 비활성화 상태(Disabled states)의 가시성을 확인하세요.

접근 가능한 양식 및 유효성 검사 (Accessible Forms and Validation)

양식(Forms)은 흔히 실패가 발생하는 지점입니다. 명시적이고 관대한 양식을 유지하세요.

• for와 id를 사용하여 레이블(Labels)을 입력창(Inputs)과 연결하세요.
• 관련 필드들을 <fieldset>과 <legend>로 그룹화하세요.
• 인라인 도움말과 오류 메시지를 제공하세요.
• 제출 시 오류를 알리고, 첫 번째 오류가 있는 곳으로 포커스를 이동시키세요.

예시:

<form novalidate>
  <fieldset>
    <legend>연락처</legend>
...

유효성 검사에 실패하면 #errors에 명확한 메시지를 삽입하고, aria-describedby를 사용하여 오류를 필드와 연결하며, 첫 번째로 유효하지 않은 입력창에 포커스를 맞추세요.

테스트: 자동 및 수동 (Testing: Automated and Manual)

자동화 도구는 일반적인 문제를 빠르게 잡아내며, 수동 테스트는 실제 사용성 문제를 찾아냅니다.

자동화:

• axe DevTools, Lighthouse, pa11y.
• 회귀(Regressions)를 방지하기 위해 CI(지속적 통합)에 통합하세요.

수동:

• 모든 흐름에 대해 키보드 전용(Keyboard-only)으로 직접 수행하기.
• 스크린 리더(Screen reader) 점검 (Windows의 NVDA 또는 JAWS, macOS/iOS의 VoiceOver).
• 200% 확대 및 리플로우(Reflow) 확인; 반응형 동작 점검.
• 색상 대비(Color contrast) 점검 및 고대비 모드(High-contrast mode) 확인.

유용한 루틴:

• 키보드 테스트부터 시작하세요.
• 자동화된 스캔을 실행하고 위반 사항을 수정하세요.
• 주요 페이지에서 스크린 리더 테스트를 수행하세요.
• 변경 사항 적용 후 다시 테스트하세요.

접근성 마인드셋 구축하기

접근성은 팀의 작업 방식에 내재화될 때 확장될 수 있습니다.

• 디자인(Design): 디자인 시스템에 대비(Contrast), 포커스 상태(Focus states), 오류 패턴(Error patterns)을 포함하세요.
• 엔지니어링(Engineering): 접근 가능한 컴포넌트(버튼, 모달, 폼 등)를 한 번 구축하여 재사용하세요.
• 콘텐츠(Content): 명확한 레이블(Label), 헤딩(Heading), 지침(Instruction)을 작성하세요.
• QA: 접근성 수락 기준(Acceptance criteria)과 테스트 케이스를 포함하세요.
• 거버넌스(Governance): 린팅(Linting) 규칙과 CI 체크를 추가하세요.

"완료(Done)\