WCAG 2.2 i EAA — accessibility obowiązkowa od czerwca 2025

WCAG 2.2 i European Accessibility Act stały się obowiązkowe 28 czerwca 2025. Każda strona sprzedająca w UE musi spełniać accessibility standards lub ryzykuje kary do 4% rocznych przychodów. Plus: 15% audience (osoby z niepełnosprawnościami) excluded od niedostępnych stron. To nie tylko compliance — to dobry biznes (i bonus SEO).

TL;DR — WCAG 2.2 + EAA

Element	Detale
Co to jest EAA	Dyrektywa UE wymagająca digital accessibility
Effective date	28 czerwca 2025
Standard techniczny	WCAG 2.2 AA (Level AA)
Kogo dotyczy	Firmy sprzedające w UE (B2C primarily)
Zwolnienia	Mikrofirmy <10 pracowników i <$2M obrotu
Kary	Do 4% rocznych przychodów (PL)
Bonus	SEO boost (Google rewards accessibility)
Tools	Lighthouse, axe DevTools, WAVE (free)

---

Co to jest WCAG i EAA?

WCAG (Web Content Accessibility Guidelines)

WCAG to międzynarodowy standard accessibility opracowany przez W3C. Wersje:

• WCAG 2.0 (2008) — wciąż valid, ale zastąpiony
• WCAG 2.1 (2018) — added mobile, vision, cognition
• WCAG 2.2 (2023) — current — added 9 nowych success criteria
• WCAG 3.0 (planned) — w pracy

Każda wersja ma 3 conformance levels:

• A (basic) — minimum
• AA (recommended) — standard biznesowy
• AAA (high) — maximalny, rzadko full compliance

EAA wymaga WCAG 2.2 AA.

European Accessibility Act (EAA)

EU directive z 2019, enforceable od 28 czerwca 2025. Pokrywa:

Produkty:

• Komputery, smartfony, tablety
• Bankomaty, terminale płatnicze
• E-readers
• TV smart

Usługi:

• Websites + mobile apps
• E-commerce
• Banking online
• Travel booking
• E-books
• Communication services (telephony, voice)

EAA nie dotyczy B2B services, internal corporate tools, government websites (those have own directives).

Główne zasady WCAG 2.2 — POUR

WCAG bazuje na 4 fundamentach (POUR):

1. Perceivable (postrzegalny)

Information must be presentable in ways users can perceive.

• Tekst alternatywy dla obrazów (alt text)
• Captions dla wideo
• Sufficient color contrast (4.5:1 dla text, 3:1 dla UI)
• Text resizable do 200% bez utraty funkcjonalności

2. Operable (operowalny)

Interface must be operable z różnych devices.

• Keyboard accessibility (wszystko działa bez myszki)
• Focus indicators visible
• No seizures (no flashing >3 razy/sekunda)
• Adequate time (no 5-second timeouts)

3. Understandable (zrozumiały)

Content + UI must be understandable.

• Clear language
• Predictable behavior (links/buttons consistent)
• Error identification + suggestions
• Form labels

4. Robust (solidny)

Content must be robust enough for assistive tech.

• Valid HTML
• ARIA labels gdzie semantic HTML niewystarcza
• Compatible z screen readers (NVDA, JAWS, VoiceOver)

Top 10 najważniejszych accessibility wymogów

1. Alt text dla obrazów

<!-- Złe -->
<img src="chart.png" />

<!-- Dobre -->
<img src="chart.png" alt="Wykres pokazujący 50% wzrost organic traffic w 6 miesięcy" />

<!-- Decorative (no info) -->
<img src="divider.png" alt="" />

2. Color contrast

WCAG AA wymaga:

• Body text: 4.5:1 ratio
• Large text (18pt+): 3:1 ratio
• UI components: 3:1

Tools: Chrome DevTools → Inspect → Accessibility tab → Contrast ratio.

3. Keyboard navigation

Every interactive element must be reachable + operable z klawiatury (Tab, Enter, Esc, Arrow keys).

Test: zamknij myszkę, próbuj operować stroną. Wszystko działa? OK. Coś niedostępne? Fix.

4. Focus indicators

Visible outline gdy user tabs through. Default browser focus rings often too subtle.

/* Dobre — ulepszenie default */
*:focus-visible {
  outline: 3px solid #0066cc;
  outline-offset: 2px;
}

/* Złe — usuwa visibility */
*:focus { outline: none; }

5. Form labels

<!-- Złe -->
<input type="email" placeholder="Email" />

<!-- Dobre -->
<label for="email">Email address</label>
<input type="email" id="email" />

<!-- Acceptable z aria-label -->
<input type="email" aria-label="Email address" />

6. Semantic HTML

Use proper HTML elements, nie divs:

• <button> dla przycisków (nie <div onclick>)
• <nav> dla nav
• <main>, <header>, <footer>, <aside>
• <h1> przez <h6> w hierarchii

7. Heading structure

Tylko jeden <h1> per page. Skip levels nie dozwolone:

• ✅ H1 → H2 → H3 → H4
• ❌ H1 → H3 (skip H2)

8. Link text

<!-- Złe -->
<a href="/article">Click here</a>

<!-- Dobre -->
<a href="/article">Read full SEO audit guide</a>

Screen readers list links — „Click here", „Read more" useless without context.

9. ARIA gdzie semantic insufficient

<!-- Custom dropdown -->
<div role="combobox" aria-expanded="false" aria-controls="dropdown-list">
  Select option
</div>
<ul id="dropdown-list" role="listbox" aria-hidden="true">
  ...
</ul>

ARIA = Accessible Rich Internet Applications. Use when HTML semantic doesn't cover (custom widgets).

10. Mobile accessibility

• Tap targets 44x44px minimum (WCAG AAA: 44x44, AA: 24x24)
• Pinch-to-zoom NOT disabled (<meta viewport> no user-scalable=no)
• Orientation works portrait + landscape

Tools dla accessibility

Free tools

• Lighthouse (Chrome DevTools) — accessibility score
• axe DevTools (Chrome extension) — most accurate
• WAVE (online) — visual feedback
• WebAIM Contrast Checker — color contrast
• NVDA (Windows) — free screen reader
• VoiceOver (Mac/iOS) — built-in screen reader

Paid tools

• Siteimprove — enterprise accessibility platform
• Deque axe Auditor — comprehensive
• Stark (Figma plugin) — design-time accessibility
• AccessiBe — automated overlay (controversial — not full solution)

Process recommended

1. Lighthouse w CI/CD (fail builds <90 score)
2. axe DevTools dla deep dives
3. NVDA / VoiceOver test po feature complete
4. Real user testing quarterly z osobami z niepełnosprawnościami

EAA enforcement i kary

Polska

• Implementacja: Ustawa o dostępności cyfrowej (2019, updated 2025)
• Kary: do 4% rocznych przychodów lub 4M zł
• Enforcement: PFRON + lokalni inspektorzy

Niemcy

• BFSG (Barrierefreiheitsstärkungsgesetz)
• Kary: do 100K EUR per violation

Inne kraje UE

Każdy state ma own law. Trend: kary rosną, enforcement się zaostrza.

USA (ADA — bonus)

ADA (Americans with Disabilities Act) extending to digital. ADA lawsuits +320% w 2024 (Beasley Allen statistics). Settlements typically $10-100K + remediation costs.

Accessibility a SEO

Google explicitly korzysta z accessibility signals:

• Alt text = ranking signal dla Google Images + AI Overviews
• Semantic HTML = lepsze parsing, lepsze rankings
• Mobile accessibility = mobile-first ranking factor
• Page experience włącza accessibility metrics

W 2026 accessibility = SEO. Brand inwestujący w accessibility ma:

• Lepsze rankings (Google reward)
• Większy TAM (~15% audience)
• AI Overviews citations (accessible content easier to parse)
• Brand reputation

Najczęstsze błędy

1. Accessibility overlay (AccessiBe etc.) — controversial, NIE pełne rozwiązanie, czasem szkodzi
2. Audit raz, forget — accessibility wymaga ongoing maintenance
3. Brak user testing z real users z niepełnosprawnościami
4. Skipping training dla developers
5. Compliance over user experience — ustaviać prawnik happy, ale user nadal struggling
6. Brak strategy — patching bugs zamiast designing accessible from start
7. Ignoring mobile — 70% traffic mobile
8. Documentation gaps — accessibility statement missing

Implementation roadmap

Phase 1: Audit (week 1-2)

• Lighthouse / axe DevTools full scan
• Manual review top 20 pages
• User testing z 3-5 users z różnymi disabilities
• Document findings

Phase 2: Quick wins (week 3-6)

• Fix top 10 critical issues:
  • Add missing alt text
  • Fix color contrast
  • Add form labels
  • Improve focus indicators
  • Heading structure cleanup

Phase 3: Systematic (week 7-12)

• Component library accessibility review
• Custom widgets (modals, dropdowns) — ARIA implementation
• Keyboard navigation audit
• Screen reader testing all flows

Phase 4: Process (week 13+)

• Accessibility checklist w design + dev workflows
• Lighthouse w CI/CD pipeline
• Quarterly audits
• Annual user testing
• Accessibility statement page

Accessibility statement

Każda compliant strona powinna mieć stronę:

• Conformance level (np. WCAG 2.2 AA)
• Date of compliance
• Contact dla accessibility issues
• Known limitations
• Last review date

Polski boilerplate: bip.gov.pl wzór dla websites publicznych — adaptable for private.

Podsumowanie

WCAG 2.2 + EAA 2026:

1. Compliance obowiązkowa od 28.06.2025
2. WCAG 2.2 AA standard techniczny
3. POUR principles — Perceivable, Operable, Understandable, Robust
4. Tools — Lighthouse, axe, WAVE (free)
5. User testing z real users disabilities
6. Ongoing maintenance — nie one-time
7. SEO bonus — Google rewards accessibility

Accessibility to nie compliance burden — to expansion (15% audience), SEO boost, ethical business. Firmy ignorujące accessibility w 2026 ryzykują kary, lawsuits, exclusion od large segment users.

Audyt accessibility — przeprowadzimy WCAG 2.2 audit + roadmap remediation.