<!--
CO_OP_TRANSLATOR_METADATA:
{
  "original_hash": "90b19cde5b79b29e91babd3138cd8035",
  "translation_date": "2025-10-24T15:31:19+00:00",
  "source_file": "1-getting-started-lessons/3-accessibility/README.md",
  "language_code": "uk"
}
-->
# Створення доступних веб-сторінок

![Все про доступність](../../../../translated_images/webdev101-a11y.8ef3025c858d897a403a1a42c0897c76e11b724d9a8a0c0578dd4316f7507622.uk.png)
> Скетчноут від [Tomomi Imura](https://twitter.com/girlie_mac)

## Тест перед лекцією
[Тест перед лекцією](https://ff-quizzes.netlify.app/web/)

> Сила вебу полягає в його універсальності. Доступ для всіх, незалежно від обмежень, є важливим аспектом.
>
> \- Сер Тімоті Бернерс-Лі, директор W3C та винахідник Всесвітньої павутини

Ось що може вас здивувати: коли ви створюєте доступні веб-сайти, ви не лише допомагаєте людям з інвалідністю — ви фактично робите веб кращим для всіх!

Помічали ті з'їзди на тротуарах на перехрестях? Вони спочатку були створені для інвалідних візків, але тепер вони допомагають людям з дитячими колясками, кур'єрам з візками, мандрівникам з валізами на колесах і навіть велосипедистам. Саме так працює доступний веб-дизайн — рішення, які допомагають одній групі, часто приносять користь усім. Круто, правда?

У цьому уроці ми дослідимо, як створювати веб-сайти, які дійсно працюють для всіх, незалежно від того, як вони користуються вебом. Ви дізнаєтеся про практичні техніки, які вже вбудовані у веб-стандарти, спробуєте інструменти тестування та побачите, як доступність робить ваші сайти зручнішими для всіх користувачів.

До кінця цього уроку ви будете впевнені у тому, що доступність стане природною частиною вашого робочого процесу розробки. Готові дослідити, як продумані дизайнерські рішення можуть відкрити веб для мільярдів користувачів? Почнемо!

> Ви можете пройти цей урок на [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) — це досить складні технології, які перетворюють цифровий текст у мовний або шрифтовий вихід. Хоча вони в основному використовуються людьми з порушеннями зору, вони також дуже корисні для користувачів з порушеннями навчання, такими як дислексія.

Я люблю думати про екранний читач як про дуже розумного оповідача, який читає вам книгу. Він читає вміст вголос у логічному порядку, оголошує інтерактивні елементи, такі як "кнопка" або "посилання", і надає комбінації клавіш для переміщення сторінкою. Але ось у чому справа — екранні читачі можуть працювати лише тоді, коли ми створюємо веб-сайти з правильною структурою та змістовним контентом. Тут ви, як розробник, вступаєте в гру!

**Популярні екранні читачі на різних платформах:**
- **Windows**: [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) (вбудований і дуже потужний)
- **Android**: [TalkBack](https://support.google.com/accessibility/android/answer/6283677) (вбудований)
- **Linux**: [Orca](https://wiki.gnome.org/Projects/Orca) (безкоштовний і з відкритим кодом)

**Як екранні читачі навігають веб-контентом:**

Екранні читачі надають кілька методів навігації, які роблять перегляд ефективним для досвідчених користувачів:
- **Послідовне читання**: Читає контент зверху вниз, як книгу
- **Навігація за орієнтирами**: Переміщення між секціями сторінки (заголовок, навігація, основний контент, підвал)
- **Навігація за заголовками**: Переміщення між заголовками для розуміння структури сторінки
- **Списки посилань**: Генерація списку всіх посилань для швидкого доступу
- **Елементи форм**: Переміщення безпосередньо між полями вводу та кнопками

> 💡 **Ось що мене вразило**: 68% користувачів екранних читачів навігують переважно за заголовками ([WebAIM Survey](https://webaim.org/projects/screenreadersurvey9/#finding)). Це означає, що ваша структура заголовків — це як дорожня карта для користувачів — коли ви робите її правильно, ви буквально допомагаєте людям швидше знаходити ваш контент!

### Побудова вашого робочого процесу тестування

Ось гарна новина — ефективне тестування доступності не повинно бути складним! Вам потрібно комбінувати автоматизовані інструменти (вони чудово виявляють очевидні проблеми) з деяким ручним тестуванням. Ось систематичний підхід, який, на мою думку, виявляє найбільше проблем без зайвих витрат часу:

**Основний робочий процес ручного тестування:**

```mermaid
graph TD
    A[Start Testing] --> B{Keyboard Navigation}
    B --> C[Tab through all interactive elements]
    C --> D{Screen Reader Testing}
    D --> E[Test with NVDA/VoiceOver]
    E --> F{Zoom Testing}
    F --> G[Zoom to 200% and test functionality]
    G --> H{Color/Contrast Check}
    H --> I[Verify all text meets contrast ratios]
    I --> J{Focus Management}
    J --> K[Ensure focus indicators are visible]
    K --> L[Testing Complete]
```

**Покроковий контрольний список тестування:**
1. **Навігація за допомогою клавіатури**: Використовуйте лише Tab, Shift+Tab, Enter, Space та клавіші зі стрілками
2. **Тестування екранного читача**: Увімкніть NVDA, VoiceOver або Narrator і навігуйте із закритими очима
3. **Тестування масштабування**: Перевірте на рівнях масштабування 200% і 400%
4. **Перевірка контрасту кольорів**: Перевірте весь текст та компоненти інтерфейсу
5. **Тестування індикаторів фокусу**: Переконайтеся, що всі інтерактивні елементи мають видимі стани фокусу

✅ **Почніть з Lighthouse**: Відкрийте DevTools вашого браузера, запустіть аудит доступності Lighthouse, а потім використовуйте результати для визначення пріоритетів ручного тестування.

### Інструменти масштабування та збільшення

Ви знаєте, як іноді збільшуєте текст на телефоні, коли він занадто малий, або примружуєтеся на екрані ноутбука при яскравому сонячному світлі? Багато користувачів щодня покладаються на інструменти збільшення, щоб зробити контент читабельним. Це включає людей з порушенням зору, літніх людей і будь-кого, хто коли-небудь намагався читати веб-сайт на вулиці.

Сучасні технології масштабування еволюціонували далеко за межі простого збільшення. Розуміння того, як ці інструменти працюють, допоможе вам створювати адаптивні дизайни, які залишаються функціональними та привабливими на будь-якому рівні масштабування.

**Сучасні можливості масштабування браузера:**
- **Масштабування сторінки**: Пропорційно збільшує весь контент (текст, зображення, макет) - це рекомендований метод
- **Масштабування лише тексту**: Збільшує розмір шрифту, зберігаючи оригінальний макет
- **Збільшення за допомогою жестів**: Мобільна підтримка для тимчасового збільшення
- **Підтримка браузерів**: Усі сучасні браузери підтримують масштабування до 500% без порушення функціональності

**Спеціалізоване програмне забезпечення для збільшення:**
- **Windows**: [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 |
| **Компоненти інтерфейсу** (кнопки, межі форм) | Співвідношення контрасту 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/) - Знаходьте доступні палітри кольорів

✅ **Створюйте кращі палітри кольорів**: Почніть з кольорів вашого бренду та використовуйте перевірки контрасту для створення доступних варіацій. Документуйте їх як доступні кольорові токени вашої дизайн-системи.

### Комплексний аудит доступності

Найефективніше тестування доступності комбінує кілька підходів. Жоден інструмент не виявляє все, тому створення рутини тестування з різними методами забезпечує повне охоплення.

**Тестування в браузері (вбудоване в DevTools):**
- **Chrome/Edge**: Аудит доступності Lighthouse + панель доступності
- **Firefox**: Інспектор доступності з детальним деревом
- **Safari**: Вкладка аудиту в Web Inspector з симуляцією VoiceOver

**Професійні розширення для тестування:**
- [axe DevTools](https://www.deque.com/axe/devtools/) - Галузевий стандарт автоматизованого тестування
- [WAVE](https://wave.webaim.org/extension/) - Візуальний зворотний зв'язок з виділенням помилок
- [Accessibility Insights](https://accessibilityinsights.io/) - Комплексний набір тестування від Microsoft

**Інтеграція командного рядка та CI/CD:**
- [axe-core](https://github.com/dequelabs/axe-core) - Бібліотека JavaScript для автоматизованого тестування
- [Pa11y](https://pa11y.org/) - Інструмент тестування доступності командного рядка
- [Lighthouse CI](https://github.com/GoogleChrome/lighthouse-ci) - Автоматизоване оцінювання доступності

> 🎯 **Ціль тестування**: Прагніть до оцінки доступності Lighthouse 95+ як базового рівня. Пам'ятайте, автоматизовані інструменти виявляють лише близько 30-40% проблем доступності — ручне тестування все ще необхідне!

## Побудова доступності з самого початку

Ключ до успіху доступності — включати її в основу з першого дня. Я знаю, що спокуса думати "я додам доступність пізніше" велика, але це як намагатися додати пандус до будинку після його побудови. Можливо? Так. Легко? Не дуже.

Думайте про доступність як про планування будинку — набагато простіше включити доступність для інвалідних візків у початкові архітектурні плани, ніж переробляти все пізніше.

### Принципи POUR: основа вашої доступності

Рекомендації щодо доступності веб-контенту (WCAG) побудовані навколо чотирьох основних принципів, які утворюють абревіатуру POUR. Не хвилюйтеся — це не сухі академічні концепції! Насправді це практичні рекомендації для створення контенту, який працює для всіх.

Як тільки ви освоїте POUR, прийняття рішень щодо доступності стане набагато інтуїтивнішим. Це як мати ментальний контрольний список, який направляє ваші дизайнерські вибори. Давайте розберемо це:

**🔍 Відчутний (Perceivable)**: Інформація повинна бути представлена у спосіб, який користувачі можуть сприймати через доступні їм органи чуття

- Надавайте текстові альтернативи для нетекстового контенту (зображення, відео, аудіо)
- Забезпечуйте достатній контраст кольорів для всього тексту та компонентів інтерфейсу
- Пропонуйте субтитри та транскрипти для мультимедійного контенту
- Дизайн контенту, який залишається функціональним при зміні розміру до 200%
- Використовуйте кілька сенсорних характеристик (не лише колір) для передачі інформації

**🎮 Операбельний (Operable)**: Усі компоненти інтерфейсу повинні бути доступні через доступні методи вводу

- Робіть всю функціональність доступною через навігацію клавіатурою
- Надавайте користувачам достатньо часу для читання та взаємодії з контентом
- Уникайте контенту, який вик
Колір є потужним засобом комунікації, але він ніколи не повинен бути єдиним способом передачі важливої інформації. Дизайн, що виходить за межі кольору, створює більш надійний та інклюзивний досвід, який працює в різних ситуаціях.

**Дизайн для людей із порушеннями кольорового зору:**

Приблизно 8% чоловіків і 0,5% жінок мають певну форму порушення кольорового зору (часто називають "кольоровою сліпотою"). Найпоширеніші типи:
- **Дейтеранопія**: Складнощі у розрізненні червоного та зеленого
- **Протанопія**: Червоний здається більш тьмяним
- **Тританопія**: Складнощі з синім і жовтим (рідкісний випадок)

**Інклюзивні стратегії використання кольору:**

```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 із навколишніми елементами
- **Ширина**: Мінімум 2px товщини навколо всього елемента
- **Стійкість**: Повинні залишатися видимими, поки фокус не переміститься
- **Розрізнення**: Повинні візуально відрізнятися від інших станів інтерфейсу

> 💡 **Порада з дизайну**: Чудові індикатори фокусу часто використовують комбінацію обведення, тіні та змін кольору, щоб забезпечити видимість на різних фонах і в контекстах.

✅ **Перевірте індикатори фокусу**: Переміщайтеся по вашому сайту за допомогою клавіші Tab і зверніть увагу, які елементи мають чіткі індикатори фокусу. Чи є якісь важко помітні або зовсім відсутні?

### Семантичний HTML: основа доступності

Семантичний HTML — це як GPS для допоміжних технологій на вашому сайті. Використовуючи правильні HTML-елементи за їх призначенням, ви фактично надаєте екранним читачам, клавіатурам та іншим інструментам детальну карту для ефективної навігації.

Ось аналогія, яка мені дуже сподобалася: семантичний HTML — це різниця між добре організованою бібліотекою з чіткими категоріями та корисними знаками і складом, де книги розкидані хаотично. В обох місцях є ті самі книги, але де вам буде зручніше щось знайти? Саме так!

**Основні елементи структури доступної сторінки:**

```html
<!-- Landmark elements provide page navigation structure -->
<header>
  <h1>Your Site Name</h1>
  <nav aria-label="Main navigation">
    <ul>
      <li><a href="/home">Home</a></li>
      <li><a href="/about">About</a></li>
      <li><a href="/services">Services</a></li>
    </ul>
  </nav>
</header>

<main>
  <article>
    <header>
      <h1>Article Title</h1>
      <p>Published on <time datetime="2024-10-14">October 14, 2024</time></p>
    </header>
    
    <section>
      <h2>First Section</h2>
      <p>Content that relates to this section...</p>
    </section>
    
    <section>
      <h2>Second Section</h2>
      <p>More related content...</p>
    </section>
  </article>
  
  <aside>
    <h2>Related Links</h2>
    <nav aria-label="Related articles">
      <ul>
        <li><a href="/related-1">First related article</a></li>
        <li><a href="/related-2">Second related article</a></li>
      </ul>
    </nav>
  </aside>
</main>

<footer>
  <p>&copy; 2024 Your Site Name. All rights reserved.</p>
  <nav aria-label="Footer links">
    <ul>
      <li><a href="/privacy">Privacy Policy</a></li>
      <li><a href="/contact">Contact Us</a></li>
    </ul>
  </nav>
</footer>
```

**Чому семантичний HTML змінює доступність:**

| Семантичний елемент | Призначення | Перевага для екранного читача |
|---------------------|-------------|------------------------------|
| `<header>` | Заголовок сторінки або секції | "Орієнтир банера" - швидка навігація до верху |
| `<nav>` | Навігаційні посилання | "Орієнтир навігації" - список навігаційних секцій |
| `<main>` | Основний контент сторінки | "Орієнтир основного контенту" - перехід прямо до контенту |
| `<article>` | Самостійний контент | Оголошує межі статті |
| `<section>` | Групи тематичного контенту | Забезпечує структуру контенту |
| `<aside>` | Супутній контент на бічній панелі | "Орієнтир додаткового контенту" |
| `<footer>` | Нижній колонтитул сторінки або секції | "Орієнтир інформації про контент" |

**Суперсили екранного читача із семантичним HTML:**
- **Навігація за орієнтирами**: Миттєвий перехід між основними секціями сторінки
- **Контури заголовків**: Генерація змісту з вашої структури заголовків
- **Списки елементів**: Створення списків усіх посилань, кнопок або елементів форми
- **Контекстна обізнаність**: Розуміння взаємозв'язків між секціями контенту

> 🎯 **Швидкий тест**: Спробуйте навігацію по вашому сайту за допомогою екранного читача, використовуючи скорочення для орієнтирів (D для орієнтира, H для заголовка, K для посилання в NVDA/JAWS). Чи має навігація сенс?

✅ **Перевірте свою семантичну структуру**: Використовуйте панель доступності у DevTools вашого браузера, щоб переглянути дерево доступності та переконатися, що ваша розмітка створює логічну структуру.

### Ієрархія заголовків: створення логічного контуру контенту

Заголовки є абсолютно важливими для доступного контенту — вони як хребет, що тримає все разом. Користувачі екранних читачів сильно покладаються на заголовки, щоб зрозуміти та навігувати ваш контент. Це як надання змісту для вашої сторінки.

**Ось золоте правило для заголовків:**
Ніколи не пропускайте рівні. Завжди прогресуйте логічно від `<h1>` до `<h2>` до `<h3>` і так далі. Пам'ятаєте, як робили плани в школі? Це той самий принцип — ви б не перейшли від "I. Основна думка" прямо до "C. Підпункт підпункту", пропустивши "A. Підпункт", правда?

**Приклад ідеальної структури заголовків:**

```html
<!-- ✅ Excellent: Logical, hierarchical progression -->
<main>
  <h1>Complete Guide to Web Accessibility</h1>
  
  <section>
    <h2>Understanding Screen Readers</h2>
    <p>Introduction to screen reader technology...</p>
    
    <h3>Popular Screen Reader Software</h3>
    <p>NVDA, JAWS, and VoiceOver comparison...</p>
    
    <h3>Testing with Screen Readers</h3>
    <p>Step-by-step testing instructions...</p>
  </section>
  
  <section>
    <h2>Color and Contrast Guidelines</h2>
    <p>Designing with sufficient contrast...</p>
    
    <h3>WCAG Contrast Requirements</h3>
    <p>Understanding the different contrast levels...</p>
    
    <h3>Testing Tools and Techniques</h3>
    <p>Tools for verifying contrast ratios...</p>
  </section>
</main>
```

```html
<!-- ❌ Problematic: Skipping levels, inconsistent structure -->
<h1>Page Title</h1>
<h3>Subsection</h3> <!-- Skipped h2 -->
<h2>This should come before h3</h2>
<h1>Another main heading?</h1> <!-- Multiple h1s -->
```

**Найкращі практики для заголовків:**
- **Один `<h1>` на сторінку**: Зазвичай ваш основний заголовок сторінки або основний заголовок контенту
- **Логічна прогресія**: Ніколи не пропускайте рівні (h1 → h2 → h3, а не h1 → h3)
- **Описовий контент**: Робіть заголовки змістовними, навіть якщо їх читати поза контекстом
- **Візуальне стилювання за допомогою CSS**: Використовуйте CSS для зовнішнього вигляду, HTML-рівні для структури

**Статистика навігації екранних читачів:**
- 68% користувачів екранних читачів навігують за заголовками ([WebAIM Survey](https://webaim.org/projects/screenreadersurvey9/#finding))
- Користувачі очікують знайти логічний контур заголовків
- Заголовки забезпечують найшвидший спосіб зрозуміти структуру сторінки

> 💡 **Професійна порада**: Використовуйте розширення браузера, такі як "HeadingsMap", щоб візуалізувати структуру заголовків. Вона повинна читатися як добре організований зміст.

✅ **Перевірте структуру заголовків**: Використовуйте навігацію за заголовками екранного читача (клавіша H у NVDA), щоб переходити між заголовками. Чи розповідає прогресія логічну історію вашого контенту?

### Розширені техніки візуальної доступності

Поза основами контрасту та кольору існують складні техніки, які допомагають створити справді інклюзивний візуальний досвід. Ці методи забезпечують роботу вашого контенту в різних умовах перегляду та з допоміжними технологіями.

**Основні стратегії візуальної комунікації:**

- **Мультимодальний зворотний зв'язок**: Поєднуйте візуальні, текстові та іноді аудіо підказки
- **Прогресивне розкриття**: Представляйте інформацію у зручних для сприйняття частинах
- **Послідовні шаблони взаємодії**: Використовуйте знайомі конвенції інтерфейсу
- **Респонсивна типографіка**: Масштабуйте текст відповідно до пристроїв
- **Стан завантаження та помилок**: Надавайте чіткий зворотний зв'язок для всіх дій користувача

**CSS-утиліти для покращеної доступності:**

```css
/* Screen reader only text - visually hidden but accessible */
.sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  white-space: nowrap;
  border: 0;
}

/* Skip link for keyboard navigation */
.skip-link {
  position: absolute;
  top: -40px;
  left: 6px;
  background: #000000;
  color: #ffffff;
  padding: 8px 16px;
  text-decoration: none;
  border-radius: 4px;
  font-weight: bold;
  transition: top 0.3s ease;
  z-index: 1000;
}

.skip-link:focus {
  top: 6px;
}

/* Reduced motion respect */
@media (prefers-reduced-motion: reduce) {
  .skip-link {
    transition: none;
  }
  
  * {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
  }
}

/* High contrast mode support */
@media (prefers-contrast: high) {
  .button {
    border: 2px solid;
  }
}
```

> 🎯 **Шаблон доступності**: "Посилання для пропуску" є важливим для користувачів клавіатури. Воно повинно бути першим фокусованим елементом на вашій сторінці та переходити прямо до основного контенту.

✅ **Реалізуйте навігацію для пропуску**: Додайте посилання для пропуску на ваші сторінки та перевірте їх, натиснувши Tab, як тільки сторінка завантажиться. Вони повинні з'являтися та дозволяти перейти до основного контенту.

## Створення змістовного тексту посилань

Посилання — це, по суті, магістралі вебу, але погано написаний текст посилань — це як дорожні знаки, які просто кажуть "Місце" замість "Центр Чикаго". Не дуже корисно, правда?

Ось що мене вразило, коли я вперше дізнався про це: екранні читачі можуть витягнути всі посилання зі сторінки та показати їх як один великий список. Уявіть, що вам дали каталог усіх посилань на вашій сторінці. Чи кожне з них має сенс саме по собі? Це тест, який ваш текст посилань повинен пройти!

### Розуміння шаблонів навігації за посиланнями

Екранні читачі пропонують потужні функції навігації за посиланнями, які залежать від добре написаного тексту посилань:

**Методи навігації за посиланнями:**
- **Послідовне читання**: Посилання читаються в контексті як частина потоку контенту
- **Генерація списку посилань**: Усі посилання сторінки зібрані в пошуковий каталог
- **Швидка навігація**: Перехід між посиланнями за допомогою клавіатурних скорочень (K у NVDA)
- **Функція пошуку**: Знаходження конкретних посилань шляхом введення часткового тексту

**Чому контекст має значення:**
Коли користувачі екранних читачів генерують список посилань, вони бачать щось на кшталт цього:
- "Завантажити звіт"
- "Дізнатися більше"
- "Натисніть тут"
- "Політика конфіденційності"
- "Натисніть тут"

Лише два з цих посилань надають корисну інформацію, якщо їх читати поза контекстом!

> 📊 **Вплив на користувачів**: Користувачі екранних читачів сканують списки посилань, щоб швидко зрозуміти контент сторінки. Загальний текст посилань змушує їх повертатися до контексту кожного посилання, значно уповільнюючи їхній досвід перегляду.

### Поширені помилки тексту посилань, яких слід уникати

Розуміння того, що не працює, допомагає розпізнати та виправити проблеми доступності в існуючому контенті.

**❌ Загальний текст посилань, який не надає контексту:**

```html
<!-- Meaningless when read from a link list -->
<p>Our sustainability efforts are detailed in our recent report. 
   <a href="/sustainability-2024.pdf">Click here</a> to view it.</p>

<!-- Repeated generic text throughout the page -->
<div class="article-card">
  <h3>Web Accessibility Guide</h3>
  <p>Learn the fundamentals...</p>
  <a href="/accessibility-guide">Read more</a>
</div>
<div class="article-card">
  <h3>Color Contrast Tips</h3>
  <p>Improve your design...</p>
  <a href="/color-contrast">Read more</a>
</div>

<!-- URLs as link text (difficult for screen readers to announce) -->
<p>Visit https://www.w3.org/WAI/WCAG21/quickref/ for WCAG guidelines.</p>

<!-- Vague action words -->
<a href="/contact">Go</a> | <a href="/about">See</a> | <a href="/help">View</a>
```

**Чому ці шаблони не працюють:**
- **"Натисніть тут"** нічого не говорить про призначення
- **"Дізнатися більше"** повторюється кілька разів, створюючи плутанину
- **Сирі URL-адреси** важко чітко вимовити екранним читачам
- **Одинарні слова** на кшталт "Перейти" або "Дивитися" не мають описового контексту

### Написання чудового тексту посилань

Описовий текст посилань приносить користь усім — користувачі з нормальним зором можуть швидко сканувати посилання, а користувачі екранних читачів одразу розуміють призначення.

**✅ Приклади чіткого, описового тексту посилань:**

```html
<!-- Descriptive text that explains the destination -->
<p>Our comprehensive <a href="/sustainability-2024.pdf">2024 sustainability report (PDF, 2.1MB)</a> details our environmental initiatives.</p>

<!-- Specific, unique link text for each card -->
<div class="article-card">
  <h3>Web Accessibility Guide</h3>
  <p>Learn the fundamentals of inclusive design...</p>
  <a href="/accessibility-guide">Read our complete web accessibility guide</a>
</div>
<div class="article-card">
  <h3>Color Contrast Tips</h3>
  <p>Improve your design with better color choices...</p>
  <a href="/color-contrast">Explore color contrast best practices</a>
</div>

<!-- Meaningful text instead of raw URLs -->
<p>The <a href="https://www.w3.org/WAI/WCAG21/quickref/">WCAG 2.1 Quick Reference guide</a> provides comprehensive accessibility guidelines.</p>

<!-- Descriptive action links -->
<a href="/contact">Contact our support team</a> | 
<a href="/about">About our company</a> | 
<a href="/help">Get help with your account</a>
```

**Найкращі практики тексту посилань:**
- **Будьте конкретними**: "Завантажити квартальний фінансовий звіт" замість "Завантажити"
- **Вказуйте тип файлу та розмір**: "(PDF, 1.2MB)" для файлів, які можна завантажити
- **Зазначайте, якщо посилання відкриваються зовні**: "(відкривається в новому вікні)", коли це доречно
- **Використовуйте активну мову**: "Зв'яжіться з нами" замість "Сторінка контактів"
- **Будьте лаконічними**: Спробуйте вмістити текст у 2-8 слів, якщо можливо

### Розширені шаблони доступності посилань

Іноді візуальні обмеження дизайну або технічні вимоги потребують спеціальних рішень. Ось складні техніки для поширених складних сценаріїв:

**Використання ARIA для покращеного контексту:**

```html
<!-- When button text must be short but needs more context -->
<a href="/report.pdf" 
   aria-label="Download 2024 annual financial report, PDF format, 2.3MB">
  Download Report
</a>

<!-- When the full context comes from surrounding content -->
<h3 id="sustainability-heading">Sustainability Initiative</h3>
<p>Our efforts to reduce environmental impact...</p>
<a href="/sustainability-details" 
   aria-labelledby="sustainability-heading"
   aria-describedby="sustainability-summary">
  Learn more
</a>
<p id="sustainability-summary">Detailed breakdown of our 2024 environmental goals and achievements</p>
```

**Вказівка типів файлів та зовнішніх призначень:**

```html
<!-- Method 1: Include information in visible link text -->
<a href="/annual-report.pdf">
  Download our 2024 annual report (PDF, 2.3MB)
</a>

<!-- Method 2: Use screen reader-only text for file details -->
<a href="/annual-report.pdf">
  Download our 2024 annual report
  <span class="sr-only">(PDF format, 2.3MB)</span>
</a>

<!-- Method 3: External link indication -->
<a href="https://example.com" 
   target="_blank" 
   aria-describedby="external-link-warning">
  Visit external resource
</a>
<span id="external-link-warning" class="sr-only">
  (opens in new window)
</span>

<!-- Method 4: Using CSS for visual indicators -->
<a href="https://example.com" class="external-link">
  External resource
</a>
```

```css
/* Visual indicator for external links */
.external-link::after {
  content: " ↗";
  font-size: 0.8em;
  color: #666;
}

/* Screen reader announcement for external links */
.external-link::before {
  content: "External link: ";
  position: absolute;
  left: -10000px;
  width: 1px;
  height: 1px;
  overflow: hidden;
}
```

> ⚠️ **Важливо**: При використанні `target="_blank"` завжди інформуйте користувачів, що посилання відкривається в новому вікні або вкладці. Несподівані зміни навігації можуть бути дезорієнтуючими.

✅ **Перевірте контекст ваших посилань**: Використовуйте інструменти розробника вашого браузера, щоб створити список усіх посилань на вашій сторінці. Чи можна зрозуміти призначення кожного посилання без будь-якого навколишнього контексту?

## ARIA: посилення доступності HTML

[Доступні багаті інтернет-додатки (ARIA)](https://developer.mozilla.org/docs/Web/Accessibility/ARIA) — це як універсальний перекладач між вашими складними веб-додатками та допоміжними технологіями. Коли HTML сам по собі не може висловити все, що роблять ваші інтерактивні компоненти, ARIA заповнює ці прогалини.

Я люблю думати про ARIA як про додавання корисних анотацій до вашого HTML — щось на кшталт сценічних вказівок у сценарії п'єси, які допомагають акторам зрозуміти їхні ролі та взаємозв'язки.

**Ось найважливіше правило
5. **Почніть з простого**: Складні реалізації ARIA частіше містять помилки

**🔍 Робочий процес тестування:**

```mermaid
graph TD
    A[Write ARIA code] --> B[Validate HTML]
    B --> C[Test with keyboard only]
    C --> D[Test with screen reader]
    D --> E[Test across browsers]
    E --> F{Issues found?}
    F -->|Yes| G[Fix and re-test]
    F -->|No| H[Implementation complete]
    G --> B
```

**🚫 Поширені помилки ARIA, яких слід уникати:**

- **Суперечлива інформація**: Не суперечте семантиці HTML
- **Надмірне маркування**: Занадто багато інформації ARIA перевантажує користувачів
- **Статична ARIA**: Забування оновлювати стани ARIA при зміні контенту
- **Неперевірені реалізації**: ARIA, яка працює теоретично, але не працює на практиці
- **Відсутність підтримки клавіатури**: Ролі ARIA без відповідних взаємодій з клавіатурою

> 💡 **Ресурси для тестування**: Використовуйте інструменти, такі як [accessibility-checker](https://www.npmjs.com/package/accessibility-checker) для автоматичної перевірки ARIA, але завжди тестуйте з реальними екранними читачами для повного досвіду.

✅ **Вчіться у експертів**: Вивчайте [ARIA Authoring Practices Guide](https://w3c.github.io/aria-practices/) для перевірених шаблонів і реалізацій складних інтерактивних віджетів.

## Робимо зображення та медіа доступними

Візуальний та аудіоконтент є важливими частинами сучасного веб-досвіду, але вони можуть створювати бар'єри, якщо їх реалізувати необдумано. Мета полягає в тому, щоб інформація та емоційний вплив вашого медіа досягали кожного користувача. Як тільки ви освоїте це, це стане природним.

Різні типи медіа потребують різних підходів до доступності. Це як кулінарія — ви не будете готувати ніжну рибу так само, як готуєте ситний стейк. Розуміння цих відмінностей допомагає вибрати правильне рішення для кожної ситуації.

### Стратегічна доступність зображень

Кожне зображення на вашому вебсайті має свою мету. Розуміння цієї мети допомагає писати кращий альтернативний текст і створювати більш інклюзивний досвід.

**Чотири типи зображень і їх стратегії для alt-тексту:**

**Інформативні зображення** - передають важливу інформацію:
```html
<img src="../../../../translated_images/chart.31c7eb0eb5c4450deba10b6f236732dfee8e8a11f6c0d8f31d2c2efb9d4c00ef.uk.png" alt="Sales increased 25% from Q1 to Q2 2024">
```

**Декоративні зображення** - суто візуальні, без інформаційної цінності:
```html
<img src="../../../../translated_images/decorative-border.b2f3c4d6634fb79d57fb6357835906c16938df3d5651c1314c196c3b1c52df98.uk.png" alt="" role="presentation">
```

**Функціональні зображення** - служать кнопками або елементами управління:
```html
<button>
  <img src="search-icon.svg" alt="Search">
</button>
```

**Складні зображення** - графіки, діаграми, інфографіка:
```html
<img src="../../../../translated_images/complex-chart.c831f461a363b446a688be5ccacde20d011221758c902cb082cfd4293534ef17.uk.png" alt="Quarterly sales data" aria-describedby="chart-description">
<div id="chart-description">
  <p>Detailed description: Sales data shows a steady increase across all quarters...</p>
</div>
```

### Доступність відео та аудіо

**Вимоги до відео:**
- **Субтитри**: Текстова версія мовленого контенту та звукових ефектів
- **Аудіоописи**: Опис візуальних елементів для незрячих користувачів
- **Транскрипти**: Повна текстова версія всього аудіо- та візуального контенту

```html
<video controls>
  <source src="video.mp4" type="video/mp4">
  <track kind="captions" src="captions.vtt" srclang="en" label="English">
  <track kind="descriptions" src="descriptions.vtt" srclang="en" label="Audio descriptions">
</video>
```

**Вимоги до аудіо:**
- **Транскрипти**: Текстова версія всього мовленого контенту
- **Візуальні індикатори**: Для аудіо-контенту без відео надайте візуальні підказки

### Сучасні техніки роботи із зображеннями

**Використання CSS для декоративних зображень:**
```css
.hero-section {
  background-image: url('decorative-hero.jpg');
  /* Decorative images in CSS don't need alt text */
}
```

**Респонсивні зображення з доступністю:**
```html
<picture>
  <source media="(min-width: 800px)" srcset="large-chart.png">
  <source media="(min-width: 400px)" srcset="medium-chart.png">
  <img src="../../../../translated_images/small-chart.c50c7b1bbcce43d8d24fbfbab8f691fe47d8f25fb7c70857c9eae21d5f22862e.uk.png" alt="Website traffic increased 40% after accessibility improvements">
</picture>
```

✅ **Тестуйте доступність зображень**: Використовуйте екранний читач для навігації сторінкою із зображеннями. Чи отримуєте ви достатньо інформації, щоб зрозуміти контент?

## Навігація клавіатурою та управління фокусом

Багато користувачів навігують веб лише за допомогою клавіатури. Це включає людей із моторними обмеженнями, досвідчених користувачів, які вважають клавіатуру швидшою за мишу, і тих, у кого миша перестала працювати. Забезпечення роботи вашого сайту з клавіатурним введенням є важливим і часто робить ваш сайт більш ефективним для всіх.

### Основні шаблони навігації клавіатурою

**Стандартні взаємодії клавіатури:**
- **Tab**: Переміщення фокусу вперед через інтерактивні елементи
- **Shift + Tab**: Переміщення фокусу назад
- **Enter**: Активація кнопок і посилань
- **Space**: Активація кнопок, вибір чекбоксів
- **Стрілки**: Навігація в групах компонентів (радіокнопки, меню)
- **Escape**: Закриття модальних вікон, випадаючих списків або скасування операцій

### Найкращі практики управління фокусом

**Видимі індикатори фокусу:**
```css
/* Ensure focus is always visible */
button:focus-visible {
  outline: 2px solid #4A90A4;
  outline-offset: 2px;
}

/* Custom focus styles for different components */
.card:focus-within {
  box-shadow: 0 0 0 3px rgba(74, 144, 164, 0.5);
}
```

**Посилання для швидкої навігації:**
```html
<a href="#main-content" class="skip-link">Skip to main content</a>
<a href="#navigation" class="skip-link">Skip to navigation</a>

<nav id="navigation">
  <!-- navigation content -->
</nav>
<main id="main-content">
  <!-- main content -->
</main>
```

**Правильний порядок вкладок:**
```html
<!-- Use semantic HTML for natural tab order -->
<form>
  <label for="name">Name:</label>
  <input type="text" id="name" tabindex="0">
  
  <label for="email">Email:</label>
  <input type="email" id="email" tabindex="0">
  
  <button type="submit" tabindex="0">Submit</button>
</form>
```

### Захоплення фокусу в модальних вікнах

При відкритті модальних діалогів фокус має бути захоплений у межах модального вікна:

```javascript
// Modern focus trap implementation
function trapFocus(element) {
  const focusableElements = element.querySelectorAll(
    'button, [href], input, select, textarea, [tabindex]:not([tabindex="-1"])'
  );
  
  const firstElement = focusableElements[0];
  const lastElement = focusableElements[focusableElements.length - 1];

  element.addEventListener('keydown', (e) => {
    if (e.key === 'Tab') {
      if (e.shiftKey && document.activeElement === firstElement) {
        e.preventDefault();
        lastElement.focus();
      } else if (!e.shiftKey && document.activeElement === lastElement) {
        e.preventDefault();
        firstElement.focus();
      }
    }
    
    if (e.key === 'Escape') {
      closeModal();
    }
  });
  
  // Focus first element when modal opens
  firstElement.focus();
}
```

✅ **Тестуйте навігацію клавіатурою**: Спробуйте навігацію вашим вебсайтом, використовуючи лише клавішу Tab. Чи можете ви досягти всіх інтерактивних елементів? Чи логічний порядок фокусу? Чи чітко видно індикатори фокусу?

## Доступність форм

Форми є критично важливими для взаємодії користувачів і потребують особливої уваги до доступності.

### Асоціація міток і елементів управління формою

**Кожен елемент управління формою потребує мітки:**
```html
<!-- Explicit labeling (preferred) -->
<label for="username">Username:</label>
<input type="text" id="username" name="username" required>

<!-- Implicit labeling -->
<label>
  Password:
  <input type="password" name="password" required>
</label>

<!-- Using aria-label when visual label isn't desired -->
<input type="search" aria-label="Search products" placeholder="Search...">
```

### Обробка помилок і валідація

**Доступні повідомлення про помилки:**
```html
<label for="email">Email Address:</label>
<input type="email" id="email" name="email" 
       aria-describedby="email-error" 
       aria-invalid="true" required>
<div id="email-error" role="alert">
  Please enter a valid email address
</div>
```

**Найкращі практики валідації форм:**
- Використовуйте `aria-invalid` для позначення недійсних полів
- Надавайте чіткі, конкретні повідомлення про помилки
- Використовуйте `role="alert"` для важливих оголошень про помилки
- Показуйте помилки як негайно, так і при поданні форми

### Поля групування та Fieldsets

**Групуйте пов'язані елементи управління формою:**
```html
<fieldset>
  <legend>Shipping Address</legend>
  <label for="street">Street Address:</label>
  <input type="text" id="street" name="street">
  
  <label for="city">City:</label>
  <input type="text" id="city" name="city">
</fieldset>

<fieldset>
  <legend>Preferred Contact Method</legend>
  <input type="radio" id="contact-email" name="contact" value="email">
  <label for="contact-email">Email</label>
  
  <input type="radio" id="contact-phone" name="contact" value="phone">
  <label for="contact-phone">Phone</label>
</fieldset>
```

## Ваш шлях до доступності: основні висновки

Вітаємо! Ви щойно отримали базові знання для створення справді інклюзивного веб-досвіду. Це досить захоплююче! Веб-доступність — це не просто перевірка відповідності стандартам, це визнання різноманітних способів взаємодії людей із цифровим контентом і проектування для цієї дивовижної складності.

Тепер ви є частиною зростаючої спільноти розробників, які розуміють, що чудовий дизайн працює для всіх. Ласкаво просимо до клубу!

**🎯 Ваш набір інструментів для доступності тепер включає:**

| Основний принцип | Реалізація | Вплив |
|------------------|------------|-------|
| **Семантична основа HTML** | Використовуйте правильні HTML-елементи за їх призначенням | Екранні читачі можуть ефективно навігувати, клавіатури працюють автоматично |
| **Інклюзивний візуальний дизайн** | Достатній контраст, осмислене використання кольорів, видимі індикатори фокусу | Зрозуміло для всіх у будь-яких умовах освітлення |
| **Описовий контент** | Осмислений текст посилань, alt-текст, заголовки | Користувачі розуміють контент без візуального контексту |
| **Доступність клавіатури** | Порядок вкладок, клавіатурні скорочення, управління фокусом | Моторна доступність і ефективність для досвідчених користувачів |
| **Покращення ARIA** | Стратегічне використання для заповнення семантичних прогалин | Складні додатки працюють із допоміжними технологіями |
| **Комплексне тестування** | Автоматизовані інструменти + ручна перевірка + тестування реальними користувачами | Виявлення проблем до того, як вони вплинуть на користувачів |

**🚀 Ваші наступні кроки:**

1. **Вбудуйте доступність у ваш робочий процес**: Зробіть тестування природною частиною вашого процесу розробки
2. **Вчіться у реальних користувачів**: Збирайте відгуки від людей, які використовують допоміжні технології
3. **Будьте в курсі**: Техніки доступності розвиваються разом із новими технологіями та стандартами
4. **Пропагуйте інклюзивність**: Діліться своїми знаннями та робіть доступність пріоритетом команди

> 💡 **Пам'ятайте**: Обмеження доступності часто призводять до інноваційних, елегантних рішень, які приносять користь усім. Пандуси, субтитри та голосове управління починалися як функції доступності, а стали загальноприйнятими покращеннями.

**Бізнес-аргумент очевидний**: Доступні вебсайти охоплюють більше користувачів, краще ранжуються в пошукових системах, мають нижчі витрати на обслуговування та уникають юридичних ризиків. Але чесно? Справжня причина піклуватися про доступність набагато глибша. Доступні вебсайти втілюють найкращі цінності вебу — відкритість, інклюзивність і ідею, що кожен заслуговує на рівний доступ до інформації.

Тепер ви готові створювати інклюзивний веб майбутнього. Кожен доступний сайт, який ви створюєте, робить інтернет більш гостинним для всіх. Це дійсно вражає, якщо задуматися!

## Додаткові ресурси

Продовжуйте своє навчання доступності за допомогою цих важливих ресурсів:

**📚 Офіційні стандарти та рекомендації:**
- [WCAG 2.1 Guidelines](https://www.w3.org/WAI/WCAG21/quickref/) - Офіційний стандарт доступності з коротким довідником
- [ARIA Authoring Practices Guide](https://w3c.github.io/aria-practices/) - Комплексні шаблони для інтерактивних віджетів
- [WebAIM Guidelines](https://webaim.org/) - Практичні, дружні для початківців рекомендації з доступності

**🛠️ Інструменти та ресурси для тестування:**
- [axe DevTools](https://www.deque.com/axe/devtools/) - Галузевий стандарт тестування доступності
- [A11y Project Checklist](https://www.a11yproject.com/checklist/) - Покрокова перевірка доступності
- [Accessibility Insights](https://accessibilityinsights.io/) - Комплексний набір тестування від Microsoft
- [Color Oracle](https://colororacle.org/) - Симулятор дальтонізму для тестування дизайну

**🎓 Навчання та спільнота:**
- [WebAIM Screen Reader Survey](https://webaim.org/projects/screenreadersurvey9/) - Реальні уподобання та поведінка користувачів
- [Inclusive Components](https://inclusive-components.design/) - Сучасні шаблони доступних компонентів
- [A11y Coffee](https://a11y.coffee/) - Швидкі поради та інсайти з доступності
- [Web Accessibility Initiative (WAI)](https://www.w3.org/WAI/) - Комплексні ресурси доступності від W3C

**🎥 Практичне навчання:**
- [Accessibility Developer Guide](https://www.accessibility-developer-guide.com/) - Практичні рекомендації з реалізації
- [Deque University](https://dequeuniversity.com/) - Професійні курси з доступності

## Виклик GitHub Copilot Agent 🚀

Використовуйте режим Agent, щоб виконати наступний виклик:

**Опис:** Створіть доступний компонент модального діалогу, який демонструє правильне управління фокусом, атрибути ARIA та шаблони навігації клавіатурою.

**Підказка:** Створіть повний компонент модального діалогу з HTML, CSS і JavaScript, який включає: правильне захоплення фокусу, закриття за допомогою клавіші ESC, закриття при кліку поза межами, атрибути ARIA для екранних читачів і видимі індикатори фокусу. Модальне вікно має містити форму з правильними мітками та обробкою помилок. Переконайтеся, що компонент відповідає стандартам WCAG 2.1 AA.


## 🚀 Виклик

Візьміть цей HTML і перепишіть його, щоб він був максимально доступним, враховуючи стратегії, які ви вивчили.

```html
<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Turtle Ipsum - The World's Premier Turtle Fan Club</title>
    <link href='../assets/style.css' rel='stylesheet' type='text/css'>
  </head>
  <body>
    <header class="site-header">
      <h1 class="site-title">Turtle Ipsum</h1>
      <p class="site-subtitle">The World's Premier Turtle Fan Club</p>
    </header>
    
    <nav class="main-nav" aria-label="Main navigation">
      <h2 class="nav-header">Resources</h2>
      <ul class="nav-list">
        <li><a href="https://www.youtube.com/watch?v=CMNry4PE93Y">"I like turtles" video</a></li>
        <li><a href="https://en.wikipedia.org/wiki/Turtle">Basic turtle information</a></li>
        <li><a href="https://en.wikipedia.org/wiki/Turtles_(chocolate)">Chocolate turtles candy</a></li>
      </ul>
    </nav>
    
    <main class="main-content">
      <article>
        <h1>Welcome to Turtle Ipsum</h1>
        <p class="intro">
          <a href="/about">Learn more about our turtle community</a> and discover fascinating facts about these amazing creatures.
        </p>
        <p class="article-text">
          Turtle ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
        </p>
      </article>
    </main>
    
    <footer class="footer">
      <section class="newsletter-signup">
        <h2>Stay Updated</h2>
        <button type="button" onclick="showNewsletterForm()">Sign up for turtle news</button>
      </section>
      
      <nav class="footer-nav" aria-label="Footer navigation">
        <h2>Site Pages</h2>
        <ul>
          <li><a href="../">Home</a></li>
          <li><a href="../semantic">Semantic HTML example</a></li>
        </ul>
      </nav>
      
      <p class="footer-copyright">&copy; 2024 Instrument. All rights reserved.</p>
    </footer>
  </body>
</html>
```

**Основні покращення:**
- Додано правильну семантичну структуру HTML
- Виправлено ієрархію заголовків (один h1, логічна прогресія)
- Додано осмислений текст посилань замість "натисніть тут"
- Включено правильні ARIA мітки для навігації
- Додано атрибут lang і правильні мета-теги
- Використано елемент button для інтерактивних елементів
- Структуровано контент футера з правильними орієнтирами

## Післялекційний тест
[Післялекційний тест](https://ff-quizzes.netlify.app/web/en/)

## Огляд і самостійне навчання

Багато урядів мають закони щодо вимог доступності. Ознайомтеся із законами про доступність у вашій країні. Що охоплюється, а що ні? Прикладом може бути [цей урядовий вебсайт](https://accessibility.blog.gov.uk/).

## Завдання
 
[Аналізуйте недоступний вебсайт](assignment.md)

Кредити: [Turtle Ipsum](https://github.com/Instrument/semantic-html-sample) від Instrument

---

**Відмова від відповідальності**:  
Цей документ був перекладений за допомогою сервісу автоматичного перекладу [Co-op Translator](https://github.com/Azure/co-op-translator). Хоча ми прагнемо до точності, будь ласка, майте на увазі, що автоматичні переклади можуть містити помилки або неточності. Оригінальний документ на його рідній мові слід вважати авторитетним джерелом. Для критичної інформації рекомендується професійний людський переклад. Ми не несемо відповідальності за будь-які непорозуміння або неправильні тлумачення, що виникають внаслідок використання цього перекладу.