# 접근성 높은 웹페이지 만들기
> 스케치노트 by [Tomomi Imura](https://twitter.com/girlie_mac)
```mermaid
journey
title 당신의 접근성 학습 모험
section 기초
사용자 이해하기: 5: 당신
테스트 도구: 4: 당신
POUR 원칙: 5: 당신
section 스킬 구축
시맨틱 HTML: 4: 당신
시각 디자인: 5: 당신
ARIA 기법: 4: 당신
section 마스터 실습
키보드 탐색: 5: 당신
폼 접근성: 4: 당신
실제 테스트: 5: 당신
```
## 강의 전 퀴즈
[강의 전 퀴즈](https://ff-quizzes.netlify.app/web/)
> 웹의 힘은 보편성에 있습니다. 장애에 상관없이 누구나 접근할 수 있어야 한다는 것은 필수적인 측면입니다.
>
> \- Sir Timothy Berners-Lee, W3C 디렉터이자 월드 와이드 웹의 발명가
여기 놀랄 만한 사실이 있어요: 접근성 높은 웹사이트를 만들면 단지 장애가 있는 사람들만 돕는 게 아니라, 실제로 모두를 위한 더 나은 웹을 만드는 거예요!
길 모퉁이에 있는 그 경사로, 본래는 휠체어 이용자를 위해 설계되었지만 이제는 유모차를 밀고 다니는 사람, 배달 노동자의 카트, 여행객의 바퀴 달린 가방, 자전거 이용자에게도 도움을 줍니다. 바로 접근성 웹 디자인이 그런 식으로 작동하는 거죠—한 그룹을 돕는 해결책이 종종 모두에게 이롭게 작용한다는 의미입니다. 멋지죠?
이번 강의에서는 누구든지 어떤 방식으로 웹을 탐색하든 제대로 작동하는 웹사이트를 만드는 방법을 살펴봅니다. 이미 웹 표준에 내장된 실용적인 기법을 발견하고, 테스트 도구를 직접 사용해 보며, 접근성이 모든 사용자에게 사이트를 더 사용하기 쉽도록 만드는 방법을 체험할 거예요.
이 강의를 마치면 접근성을 개발 워크플로우에 자연스럽게 통합할 수 있는 자신감이 생길 것입니다. 사려 깊은 디자인 선택이 어떻게 수십억 사용자가 웹에 접근할 수 있게 열어주는지 탐험할 준비 되셨나요? 함께 시작해 봅시다!
```mermaid
mindmap
root((웹 접근성))
Users
화면 낭독기
키보드 탐색
음성 제어
확대
Technologies
HTML 시맨틱
ARIA 속성
CSS 포커스 표시기
키보드 이벤트
Benefits
더 넓은 사용자층
더 나은 SEO
법적 준수
유니버설 디자인
Testing
자동화 도구
수동 테스트
사용자 피드백
실제 보조 기술
```
> 이 강의는 [Microsoft Learn](https://docs.microsoft.com/learn/modules/web-development-101/accessibility/?WT.mc_id=academic-77807-sagibbon)에서 수강할 수 있습니다!
## 보조 기술 이해하기
코딩에 들어가기 전에, 다양한 능력을 가진 사람들이 실제로 웹을 어떻게 경험하는지 잠시 알아봅시다. 이건 단순한 이론이 아니라—이런 실제 탐색 패턴을 이해하면 훨씬 더 뛰어난 개발자가 될 수 있어요!
보조 기술은 장애가 있는 사람들이 웹사이트와 상호작용하도록 돕는 놀라운 도구입니다. 이런 기술들이 어떻게 작동하는지 익히면, 접근성 높은 웹 경험을 만드는 것은 훨씬 직관적이 됩니다. 마치 다른 사람의 눈으로 코드를 보는 법을 배우는 것과 같습니다.
### 화면 낭독기
[화면 낭독기](https://en.wikipedia.org/wiki/Screen_reader)는 디지털 텍스트를 음성이나 점자 출력으로 변환하는 꽤 정교한 기술입니다. 주로 시각 장애인이 사용하지만, 난독증 같은 학습 장애가 있는 사용자에게도 매우 도움이 됩니다.
저는 화면 낭독기를 똑똑한 해설자가 책을 읽어주는 것이라고 생각합니다. 내용은 논리적 순서로 읽어주고, "버튼"이나 "링크" 같은 상호작용 요소를 알리며, 페이지를 빠르게 이동할 수 있도록 키보드 단축키를 제공합니다. 하지만 여기 중요한 점은—화면 낭독기가 제대로 작동하려면 우리가 웹사이트를 올바른 구조와 의미 있는 내용으로 만들어야 한다는 점입니다. 바로 여러분 개발자의 역할이에요!
**플랫폼별 인기 화면 낭독기:**
- **윈도우**: [NVDA](https://www.nvaccess.org/about-nvda/) (무료이자 가장 인기), [JAWS](https://webaim.org/articles/jaws/), [Narrator](https://support.microsoft.com/windows/complete-guide-to-narrator-e4397a0d-ef4f-b386-d8ae-c172f109bdb1/?WT.mc_id=academic-77807-sagibbon) (내장)
- **macOS/iOS**: [VoiceOver](https://support.apple.com/guide/voiceover/welcome/10) (내장 및 매우 강력)
- **안드로이드**: [TalkBack](https://support.google.com/accessibility/android/answer/6283677) (내장)
- **리눅스**: [Orca](https://wiki.gnome.org/Projects/Orca) (무료 오픈소스)
**화면 낭독기의 웹 콘텐츠 탐색 방법:**
화면 낭독기는 숙련된 사용자가 효율적으로 탐색할 수 있도록 여러 가지 방법을 제공합니다:
- **순차 읽기**: 책을 읽듯이 위에서 아래로 내용 읽기
- **랜드마크 탐색**: 페이지 구역(header, nav, main, footer) 간 빠르게 이동
- **헤딩 탐색**: 제목 간 건너뛰면서 페이지 구조 파악
- **링크 목록**: 모든 링크 목록 생성 후 빠르게 접근
- **폼 컨트롤**: 입력 필드와 버튼 사이를 직접 탐색
> 💡 **정말 놀라운 사실**: 화면 낭독기 사용자 중 68%가 주로 헤딩을 이용해 탐색합니다 ([WebAIM 설문조사](https://webaim.org/projects/screenreadersurvey9/#finding)). 즉, 당신의 헤딩 구조는 사용자에게 일종의 길잡이 지도가 되는 셈입니다—잘 만들면 사용자가 콘텐츠를 훨씬 빠르게 찾도록 돕는다는 뜻이죠!
### 테스트 워크플로우 구축하기
좋은 소식입니다—효과적인 접근성 테스트는 부담스러울 필요가 없어요! 자동화 도구(명백한 문제 발견에 탁월함)와 직접 테스트를 병행하면 됩니다. 제가 효과적이라고 생각하는 체계적인 방법은 다음과 같으며, 하루 종일 시간을 빼앗기지 않고도 많은 문제를 발견할 수 있어요:
**필수 수동 테스트 워크플로우:**
```mermaid
flowchart TD
A[🚀 테스트 시작] --> B{⌨️ 키보드 탐색}
B --> C[모든 상호작용 요소를 탭으로 이동]
C --> D{🎧 화면 읽기 프로그램 테스트}
D --> E[NVDA/VoiceOver로 테스트]
E --> F{🔍 확대 테스트}
F --> G[200% 확대 후 기능 테스트]
G --> H{🎨 색상/대비 확인}
H --> I[모든 텍스트가 대비 비율 충족하는지 확인]
I --> J{👁️ 포커스 관리}
J --> K[포커스 표시기가 보이는지 확인]
K --> L[✅ 테스트 완료]
style A fill:#e3f2fd
style L fill:#e8f5e8
style B fill:#fff3e0
style D fill:#f3e5f5
style F fill:#e0f2f1
style H fill:#fce4ec
style J fill:#e8eaf6
```
**단계별 테스트 체크리스트:**
1. **키보드 탐색**: Tab, Shift+Tab, Enter, Space, 화살표 키만 사용
2. **화면 낭독기 테스트**: NVDA, VoiceOver, Narrator 활성화 후 눈 감고 탐색 시도
3. **확대 테스트**: 200% 및 400% 배율에서 테스트
4. **색상 대비 확인**: 모든 텍스트 및 UI 요소 점검
5. **포커스 표시 테스트**: 모든 상호작용 요소가 눈에 띄는 포커스 상태인지 확인
✅ **Lighthouse로 시작하기**: 브라우저 개발자 도구에서 Lighthouse 접근성 감사를 실행한 후 결과를 참고해 수동 테스트 초점 영역을 정하세요.
### 확대 및 돋보기 도구
휴대폰에서 텍스트가 너무 작을 때 핀치 줌 하거나, 밝은 햇빛 아래서 노트북 화면을 찡그려 본 경험 있죠? 많은 사용자가 매일 콘텐츠를 읽기 쉽게 확대 도구를 사용합니다. 저시력자, 고령자, 야외에서 웹사이트를 읽으려는 사람 모두 포함됩니다.
현대 확대 기술은 단순히 크기를 키우는 것을 넘어 발전했습니다. 이 도구들이 어떻게 작동하는지 이해하면, 어떤 확대 수준에서도 기능적이고 매력적인 반응형 디자인을 만들 수 있어요.
**현대 브라우저 확대 기능:**
- **페이지 확대**: 텍스트, 이미지, 레이아웃 등 모든 콘텐츠를 비례 확대—가장 권장되는 방법
- **텍스트 전용 확대**: 원래 레이아웃은 유지하면서 폰트 크기만 커짐
- **핀치 투 줌**: 모바일 제스처로 임시 확대 지원
- **브라우저 지원**: 모든 최신 브라우저가 500%까지 확대해도 기능 깨지지 않음
**특수 확대 소프트웨어:**
- **윈도우**: [Magnifier](https://support.microsoft.com/windows/use-magnifier-to-make-things-on-the-screen-easier-to-see-414948ba-8b1c-d3bd-8615-0e5e32204198) (내장), [ZoomText](https://www.freedomscientific.com/training/zoomtext/getting-started/)
- **macOS/iOS**: [Zoom](https://www.apple.com/accessibility/mac/vision/) (내장, 고급 기능 포함)
> ⚠️ **설계 고려사항**: WCAG는 콘텐츠가 200% 확대 시에도 제대로 작동할 것을 요구합니다. 이 경우 가로 스크롤은 최소화하고, 모든 상호작용 요소가 접근 가능해야 합니다.
✅ **반응형 디자인 테스트**: 브라우저 확대를 200%와 400%로 설정해보세요. 레이아웃이 자연스럽게 조정되나요? 불필요한 스크롤 없이 모든 기능에 접근할 수 있나요?
## 최신 접근성 테스트 도구
이제 사람들이 보조 기술로 웹을 어떻게 탐색하는지 이해했으니, 접근성 높은 웹사이트를 구축하고 테스트하는 데 도움이 되는 도구들을 살펴봅시다.
비유하자면 자동화 도구는 명백한 문제(예: 누락된 alt 텍스트)를 잘 찾아내고, 직접 테스트는 실제로 사이트 사용 감각을 확인하는 역할을 합니다. 둘이 함께 작동해야 모두가 사용할 수 있는 사이트를 만들 수 있어요.
### 색상 대비 테스트
좋은 소식: 색상 대비는 가장 흔한 접근성 문제 중 하나이지만, 동시에 가장 쉽게 고칠 수 있기도 합니다. 적절한 대비는 시각 장애인뿐 아니라 해변에서 휴대폰을 읽는 사람 등 모두에게 이익이 됩니다.
**WCAG 대비 기본 요구사항:**
| 텍스트 유형 | WCAG AA (최소) | WCAG AAA (향상) |
|-------------|----------------|------------------|
| **일반 텍스트** (18pt 미만) | 4.5:1 대비 비율 | 7:1 대비 비율 |
| **큰 텍스트** (18pt 이상 혹은 14pt 이상 볼드) | 3:1 대비 비율 | 4.5:1 대비 비율 |
| **UI 구성 요소** (버튼, 폼 경계 등) | 3:1 대비 비율 | 3:1 대비 비율 |
**필수 테스트 도구:**
- [Colour Contrast Analyser](https://www.tpgi.com/color-contrast-checker/) - 색상 선택 기능 있는 데스크톱 앱
- [WebAIM Contrast Checker](https://webaim.org/resources/contrastchecker/) - 웹 기반, 즉시 피드백 제공
- [Stark](https://www.getstark.co/) - Figma, Sketch, Adobe XD 용 디자인 도구 플러그인
- [Accessible Colors](https://accessible-colors.com/) - 접근성 있는 색상 팔레트 찾기
✅ **더 나은 색상 팔레트 만들기**: 브랜드 색상을 기준으로 대비 검사 도구를 사용해 접근성 있는 변형을 만드세요. 이런 변형을 디자인 시스템의 접근성 색상 토큰으로 문서화하세요.
### 종합적인 접근성 감사
가장 효과적인 접근성 테스트는 여러 접근법을 결합합니다. 단일 도구가 모든 것을 잡아내지 못하므로, 다양한 방법을 활용해 테스트 루틴을 만드는 것이 철저한 검증을 보장합니다.
**브라우저 내장 테스트(개발자 도구):**
- **크롬/엣지**: Lighthouse 접근성 감사 + 접근성 패널
- **파이어폭스**: 상세 트리 뷰가 있는 접근성 인스펙터
- **사파리**: VoiceOver 시뮬레이션이 포함된 웹 인스펙터 감사 탭
**전문 테스트 확장 프로그램:**
- [axe DevTools](https://www.deque.com/axe/devtools/) - 업계 표준 자동화 테스트
- [WAVE](https://wave.webaim.org/extension/) - 시각적 피드백 및 오류 하이라이트
- [Accessibility Insights](https://accessibilityinsights.io/) - 마이크로소프트의 종합 테스트 스위트
**명령줄 및 CI/CD 통합:**
- [axe-core](https://github.com/dequelabs/axe-core) - 자동화 테스트용 자바스크립트 라이브러리
- [Pa11y](https://pa11y.org/) - 명령줄 접근성 테스트 도구
- [Lighthouse CI](https://github.com/GoogleChrome/lighthouse-ci) - 자동화 접근성 점수 측정
> 🎯 **테스트 목표**: Lighthouse 접근성 점수 95+를 목표로 하세요. 자동화 도구는 약 30-40%의 문제만 잡아내므로 수동 테스트가 여전히 필수입니다!
### 🧠 **테스트 기술 점검: 문제 찾을 준비 되셨나요?**
**접근성 테스트에 대해 어떻게 느끼시는지 확인해 봅시다:**
- 지금 가장 접근하기 쉬운 테스트 방법은 무엇인가요?
- 하루 종일 키보드만 사용해 탐색할 수 있을 것 같나요?
- 온라인에서 개인적으로 경험한 접근성 장벽은 무엇인가요?
```mermaid
pie title "다양한 방법으로 발견된 접근성 문제"
"자동화 도구" : 35
"수동 테스트" : 40
"사용자 피드백" : 25
```
> **자신감 상승 팁**: 전문 접근성 테스터들이 바로 이 조합을 사용합니다. 여러분도 업계 표준 관행을 배우고 있는 셈이죠!
## 처음부터 접근성 구축하기
접근성 성공의 핵심은 처음부터 토대에 반영하는 것입니다. "나중에 접근성을 추가하면 되겠지" 하는 생각은, 이미 지어진 집에 경사로를 붙이려는 것과 같습니다. 가능은 하지만 쉽지 않죠.
접근성을 집 설계와 비슷하게 생각하세요—처음 건축 계획 단계에서 휠체어 접근성을 포함하는 게, 나중에 다시 공사를 하는 것보다 훨씬 쉽습니다.
### POUR 원칙: 접근성의 기초
웹 콘텐츠 접근성 가이드라인(WCAG)은 POUR라는 네 가지 기본 원칙으로 구성되어 있습니다. 걱정 마세요—딱딱한 학술 이론이 아니라 모두를 위한 콘텐츠를 만드는 실용적인 가이드라인입니다.
POUR 원칙을 익히면 접근성 결정을 훨씬 직관적으로 내릴 수 있습니다. 설계 선택을 안내하는 마음속 체크리스트 같은 느낌이죠. 하나씩 살펴봅시다:
```mermaid
flowchart LR
A[🔍 인지 가능 사용자가 감지할 수 있나요?] --> B[🎮 조작 가능 사용자가 사용할 수 있나요?]
B --> C[📖 이해 가능 사용자가 이해할 수 있나요?]
C --> D[💪 견고함 모든 곳에서 작동하나요?]
A1[대체 텍스트 자막 대비] --> A
B1[키보드 접근 발작 방지 시간 제한] --> B
C1[명확한 언어 예측 가능 오류 도움] --> C
D1[유효 코드 호환 가능 미래 대비] --> D
style A fill:#e1f5fe
style B fill:#e8f5e8
style C fill:#fff3e0
style D fill:#f3e5f5
```
**🔍 인지 가능(Perceivable)**: 사용자가 자신의 감각으로 인지할 수 있는 방식으로 정보 제공
- 텍스트가 아닌 콘텐츠(이미지, 비디오, 오디오)에 텍스트 대체 수단 제공
- 모든 텍스트 및 UI 구성요소에 충분한 색상 대비 확보
- 멀티미디어 콘텐츠에 캡션과 전사 제공
- 내용이 200% 확대 시에도 기능 유지하도록 설계
- 정보를 전달할 때 여러 감각적 특성(색상만 사용하는 것이 아님) 활용
**🎮 조작 가능(Operable)**: 모든 인터페이스 요소가 사용 가능한 입력 방법으로 조작 가능해야 함
- 키보드 탐색만으로도 모든 기능에 접근 가능하게 하기
- 사용자가 읽고 상호작용할 충분한 시간 제공
- 발작이나 전정 장애를 유발할 수 있는 콘텐츠 피하기
- 명확한 구조와 랜드마크로 효율적 탐색 지원
- 상호작용 요소의 목표 크기 최소 44px 확보
**📖 이해 가능(Understandable)**: 정보와 UI 작동 방식이 명확하고 이해하기 쉬워야 함
- 청중에게 적절한 명확하고 단순한 언어 사용
- 내용이 예측 가능하고 일관된 방식으로 표시 및 작동되도록 하기
- 사용자 입력에 대한 명확한 지침 및 오류 메시지 제공
- 사용자 실수를 이해하고 수정하도록 도움 제공
- 논리적 읽기 순서와 정보 계층 구조로 콘텐츠 구성
**💪 견고함(Robust)**: 다양한 기술과 보조 기기에서 콘텐츠가 안정적으로 작동해야 함
- **유효하고 시맨틱한 HTML을 기초로 사용하기**
- **현재 및 미래의 보조 기술과 호환성 확보**
- **코딩 시 웹 표준과 모범 사례 준수하기**
- **다양한 브라우저, 기기 및 지원 도구에서 테스트하세요**
- **고급 기능이 지원되지 않을 때도 콘텐츠가 자연스럽게 동작하도록 구조화하세요**
### 🎯 **POUR 원칙 점검: 확실히 익히기**
**기본 개념에 대한 빠른 성찰:**
- 각 POUR 원칙을 충족하지 못하는 웹사이트 기능을 생각해 본 적 있나요?
- 개발자로서 어떤 원칙이 가장 자연스럽게 느껴지나요?
- 이 원칙들이 장애가 있는 사용자뿐 아니라 모든 사람의 디자인을 어떻게 개선할 수 있을까요?
```mermaid
quadrantChart
title POUR 원칙 영향 매트릭스
x-axis 낮은 노력 --> 높은 노력
y-axis 낮은 영향 --> 높은 영향
quadrant-1 빠른 성공
quadrant-2 주요 프로젝트
quadrant-3 나중에 고려
quadrant-4 전략적 집중
Alt Text: [0.2, 0.9]
Color Contrast: [0.3, 0.8]
Semantic HTML: [0.4, 0.9]
Keyboard Nav: [0.6, 0.8]
ARIA Complex: [0.8, 0.7]
Screen Reader Testing: [0.7, 0.6]
```
> **기억하세요**: 영향력이 크고 노력이 적은 개선부터 시작하세요. 시맨틱 HTML과 alt 텍스트는 최소한의 노력으로 최대의 접근성 향상을 제공합니다!
## 접근 가능한 시각 디자인 만들기
좋은 시각 디자인과 접근성은 함께 갑니다. 접근성을 염두에 두고 디자인하면 이러한 제약이 모든 사용자에게 혜택을 주는 더 깔끔하고 우아한 해결책으로 이어지는 경우가 많습니다.
시각적 능력이나 콘텐츠를 보는 조건에 관계없이 모두에게 잘 작동하는 시각적으로 매력적인 디자인을 만드는 방법을 살펴보겠습니다.
### 색상 및 시각적 접근성 전략
색상은 강력한 커뮤니케이션 수단이지만 중요한 정보를 전달하는 유일한 방법이 되어서는 안 됩니다. 색상을 넘어서서 디자인하는 것은 더 견고하고 포괄적인 경험을 창출하여 더 다양한 상황에서 작동합니다.
**색각 차이를 고려한 디자인:**
남성의 약 8%, 여성의 0.5%가 일종의 색각 차이(일명 '색맹')를 가지고 있습니다. 가장 흔한 유형은:
- **적녹색맹 (Deuteranopia)**: 빨간색과 녹색 구분 어려움
- **적색맹 (Protanopia)**: 빨간색이 더 어둡게 보임
- **황청색맹 (Tritanopia)**: 파랑과 노랑 구분 어려움 (희귀)
**포괄적인 색상 전략:**
```css
/* ❌ Bad: Using only color to indicate status */
.error { color: red; }
.success { color: green; }
/* ✅ Good: Color plus icons and context */
.error {
color: #d32f2f;
border-left: 4px solid #d32f2f;
}
.error::before {
content: "⚠️";
margin-right: 8px;
}
.success {
color: #2e7d32;
border-left: 4px solid #2e7d32;
}
.success::before {
content: "✅";
margin-right: 8px;
}
```
**기본 대비 요구 사항을 넘어서서:**
- 색맹 시뮬레이터로 색상 선택을 테스트하세요
- 색상 코드와 함께 패턴, 질감, 형태를 사용하세요
- 상호작용 상태가 색상 없이도 구분 가능하도록 하세요
- 고대비 모드에서 디자인이 어떻게 보이는지 고려하세요
✅ **색상 접근성 테스트**: [Coblis](https://www.color-blindness.com/coblis-color-blindness-simulator/)와 같은 도구를 사용하여 사용자가 색각 차이를 어떻게 보는지 확인하세요.
### 포커스 표시기 및 상호작용 디자인
포커스 표시기는 디지털 커서와 같아서 키보드 사용자가 현재 페이지에서 어디에 있는지 보여줍니다. 잘 디자인된 포커스 표시기는 모든 사용자가 상호작용을 명확하고 예측 가능하게 만드는 경험을 개선합니다.
**최신 포커스 표시기 모범 사례:**
```css
/* Enhanced focus styles that work across browsers */
button:focus-visible {
outline: 2px solid #0066cc;
outline-offset: 2px;
box-shadow: 0 0 0 4px rgba(0, 102, 204, 0.25);
}
/* Remove focus outline for mouse users, preserve for keyboard users */
button:focus:not(:focus-visible) {
outline: none;
}
/* Focus-within for complex components */
.card:focus-within {
box-shadow: 0 0 0 3px rgba(74, 144, 164, 0.5);
border-color: #4A90A4;
}
/* Ensure focus indicators meet contrast requirements */
.custom-focus:focus-visible {
outline: 3px solid #ffffff;
outline-offset: 2px;
box-shadow: 0 0 0 6px #000000;
}
```
**포커스 표시기 요구 사항:**
- **가시성**: 주변 요소와 최소 3:1 대비 비율 유지
- **굵기**: 요소 전체를 둘러싸는 최소 2픽셀 두께
- **지속성**: 포커스가 이동할 때까지 표시 유지
- **구분성**: 다른 UI 상태와 명백히 구분되어야 함
> 💡 **디자인 팁**: 훌륭한 포커스 표시기는 윤곽선, 박스 그림자, 색상 변화를 결합해 다양한 배경과 상황에서 가시성을 확보합니다.
✅ **포커스 표시기 점검**: 웹사이트를 탭 키로 탐색하며 명확한 포커스 표시기가 있는지 확인하세요. 보기 어렵거나 전혀 없는 요소가 있나요?
### 시맨틱 HTML: 접근성의 기반
시맨틱 HTML은 보조 기술에 웹사이트의 GPS 역할을 합니다. 의도된 목적에 맞는 HTML 요소를 사용하면 스크린 리더, 키보드, 기타 도구에 효과적인 탐색을 위한 상세 지도를 제공하는 셈입니다.
제가 이해하기 쉬웠던 비유를 하나 드리자면, 시맨틱 HTML은 명확한 카테고리와 유용한 안내판이 있는 잘 정리된 도서관과 책이 무작위로 흩어져 있는 창고의 차이입니다. 두 곳 모두 같은 책들이 있지만 어느 쪽에서 더 쉽게 원하는 책을 찾을 수 있을까요? 당연히 도서관이겠죠!
```mermaid
flowchart TD
A[🏠 HTML 문서] --> B[📰 헤더]
A --> C[🧭 내비게이션]
A --> D[📄 본문]
A --> E[📋 푸터]
B --> B1[h1: 사이트 이름 로고 & 브랜딩]
C --> C1[ul: 내비게이션 주요 링크]
D --> D1[article: 콘텐츠 section: 하위 섹션]
D --> D2[aside: 사이드바 관련 콘텐츠]
E --> E1[nav: 푸터 링크 저작권 정보]
D1 --> D1a[h1: 페이지 제목 h2: 주요 섹션 h3: 하위 섹션]
style A fill:#e3f2fd
style B fill:#e8f5e8
style C fill:#fff3e0
style D fill:#f3e5f5
style E fill:#e0f2f1
```
**접근 가능한 페이지 구조의 기본 구성 요소:**
```html
Your Site Name
Article Title
Published on
First Section
Content that relates to this section...
Second Section
More related content...
```
**시맨틱 HTML이 접근성을 혁신하는 이유:**
| 시맨틱 요소 | 용도 | 스크린 리더 이점 |
|------------------|---------|----------------------|
| `` | 페이지 또는 섹션의 헤더 | "배너 랜드마크" - 상단으로 빠르게 이동 |
| `