WCAG 5.2.2: Pełne strony

Wstęp do Zgodności z WCAG: Pełne Strony

Kryterium „Pełne strony” (WCAG 2.0/2.1 Wymóg Zgodności 5) nie jest technicznym kryterium sukcesu, ale fundamentalnym wymogiem dotyczącym zakresu deklaracji zgodności z Web Content Accessibility Guidelines (WCAG). Stwierdza ono jasno, że aby strona internetowa mogła być uznana za zgodną z WCAG (na dowolnym poziomie – A, AA lub AAA), cała strona musi spełniać wszystkie odpowiednie kryteria sukcesu. Nie można deklarować zgodności z WCAG dla pojedynczych komponentów lub fragmentów strony, jeśli reszta strony jest niedostępna.

Dlaczego Pełne Strony Mają Znaczenie dla Dostępności?

Wpływ na dostępność i doświadczenie użytkownika

Dostępność to całościowe doświadczenie. Nawet jeśli główne treści strony są zgodne ze standardami, użytkownik nie będzie w stanie w pełni z niej korzystać, jeśli niektóre elementy są niedostępne. Na przykład niedostępna dla użytkowników klawiatury nawigacja sprawia, że cała strona staje się barierą, nawet gdy sama treść jest poprawna. Częściowa zgodność prowadzi do niekonsekwentnego i często utrudnionego korzystania z serwisu.

Grupy użytkowników, których dotyczy problem

• Użytkownicy technologii wspomagających: Czytniki ekranu, oprogramowanie do rozpoznawania mowy, nawigacja klawiaturą polegają na spójnym i dostępnym interfejsie w całej witrynie. Niedostępne elementy mogą zablokować ich dostęp do kluczowych funkcji.
• Użytkownicy z niepełnosprawnością ruchową: Mogą potrzebować dostępu do wszystkich interaktywnych elementów za pomocą klawiatury lub alternatywnych urządzeń wskazujących.
• Użytkownicy z niepełnosprawnością poznawczą: Niespójne lub częściowo dostępne strony mogą prowadzić do dezorientacji, frustracji i niemożności wykonania zadań.
• Wszyscy użytkownicy: Dostępność często poprawia użyteczność dla wszystkich, niezależnie od ich zdolności. Brak pełnej zgodności z WCAG może utrudniać korzystanie ze strony również osobom bez zdiagnozowanych niepełnosprawności.

Wymogi i Kryteria Zgodności

Kryterium „Pełne strony” jest jednym z pięciu Wymogów Zgodności (Conformance Requirements), a nie kryteriów sukcesu (Success Criteria), określonych w WCAG 2.0 i 2.1:

• Wymóg Zgodności 5: Pełne strony: Zgodność (i poziom zgodności) dotyczy całej strony internetowej, a nie tylko jej fragmentów.

Oznacza to, że jeśli jakikolwiek fragment treści na stronie (np. nagłówek, stopka, nawigacja główna, pasek boczny, widżet, dynamicznie ładowana sekcja, popup, formularz) nie spełnia odpowiednich kryteriów sukcesu WCAG dla deklarowanego poziomu zgodności (A, AA lub AAA), to cała strona nie jest zgodna z WCAG.

Istnieją ograniczone wyjątki, takie jak treści stworzone przez osoby trzecie, nad którymi autor nie ma kontroli ani obowiązku prawnego (np. reklamy z zewnętrznych sieci, które są poza bezpośrednią kontrolą). W takich przypadkach należy jasno określić ich zakres i, jeśli to możliwe, zapewnić alternatywne dostępne rozwiązania lub ostrzec użytkowników o niedostępnych treściach. Jednak w większości scenariuszy deweloper lub właściciel witryny jest odpowiedzialny za zapewnienie dostępności wszystkich elementów na stronie, włączając w to wybór i integrację zewnętrznych komponentów.

Praktyczne Wskazówki dla Zgodności

Audytowanie całej strony

• Kompleksowe testowanie: Przeprowadzaj testy dostępności dla wszystkich elementów strony: nagłówków, stopek, nawigacji głównej, pasków bocznych, treści głównych, formularzy, wyskakujących okienek (modali), a także wszystkich dynamicznie ładowanych komponentów i interakcji.
• Testy z rzeczywistymi użytkownikami: Zawsze uwzględniaj testy z osobami korzystającymi z technologii wspomagających, aby upewnić się, że całe doświadczenie jest płynne i wolne od barier.
• Pamiętaj o wszystkich stanach: Testuj nie tylko początkowy stan strony, ale także wszystkie stany interaktywne (np. po rozwinięciu menu, po walidacji formularza, po załadowaniu nowych treści).

Zarządzanie treściami zewnętrznymi i dynamicznymi

• Osadzone treści (iframes, widżety): Jeśli używasz osadzonych treści od stron trzecich (np. mapy, odtwarzacze wideo, widżety społecznościowe), upewnij się, że są one dostępne. Jeśli nie masz na to wpływu, poszukaj alternatyw lub zapewnij dostępne zamienniki (np. link do dostępnej wersji, tekstowy opis).
• Dynamiczne ładowanie treści: Upewnij się, że treści ładowane asynchronicznie (AJAX, aplikacje jednostronicowe – SPA) są również dostępne i prawidłowo aktualizują drzewo dostępności (ARIA live regions). Informuj użytkowników technologii wspomagających o zmianach na stronie.
• Zależności od JavaScriptu: Upewnij się, że podstawowa funkcjonalność strony jest dostępna nawet bez JavaScriptu lub że dla użytkowników, którzy mają go wyłączonego, dostępne są równoważne alternatywy.

Spójność i odpowiedzialność

• Spójny design i kod: Projektuj i koduj wszystkie części strony z myślą o dostępności. Używaj spójnych wzorców dla elementów interaktywnych, nawigacji i prezentacji treści.
• Odpowiedzialność zespołu: Cały zespół deweloperski, projektowy i contentowy musi rozumieć, że dostępność jest odpowiedzialnością każdego, a nie tylko „eksperta” od dostępności. Włączaj dostępność do każdego etapu cyklu życia projektu.
• Dokumentacja i wytyczne: Twórz i utrzymuj wewnętrzne wytyczne dotyczące dostępności, aby zapewnić spójność w całym projekcie i organizacji.

Przykłady Prawidłowych i Nieprawidłowych Implementacji

Poniższe przykłady ilustrują koncepcyjnie, jak wygląda zgodność lub jej brak w kontekście „Pełnych stron”.

Przykład prawidłowej implementacji

<!DOCTYPE html>
<html lang="pl">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Dostępna Strona Internetowa</title>
    <!-- Link do dostępnego CSS zapewniającego odpowiednie kontrasty i fokus -->
    <link rel="stylesheet" href="/css/accessible-styles.css">
</head>
<body>
    <header role="banner">
        <nav aria-label="Główna nawigacja">
            <ul>
                <li><a href="#home">Strona główna</a></li>
                <li><a href="#about">O nas</a></li>
                <li><a href="#contact">Kontakt</a></li>
            </ul>
        </nav>
    </header>
    <main id="main-content">
        <h1>Witaj na naszej dostępnej stronie!</h1>
        <img src="image.jpg" alt="Opis obrazu, który jest alternatywnym tekstem">
        <p>Ta treść jest w pełni dostępna i łatwa do odczytania dla wszystkich użytkowników.</p>
        <!-- Osadzony, w pełni dostępny widżet pogodowy -->
        <iframe title="Aktualna pogoda z alternatywnym opisem" src="https://example.com/accessible-weather-widget" style="border:0;"></iframe>
    </main>
    <footer role="contentinfo">
        <p>© 2023 Wszelkie prawa zastrzeżone. <a href="#privacy">Polityka prywatności</a></p>
    </footer>
</body>
</html>
Skopiuj tekst

Przykład nieprawidłowej implementacji

<!DOCTYPE html>
<html lang="pl">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Częściowo dostępna strona</title>
    <style>
        /* Niski kontrast dla nagłówka - BŁĄD <a href="https://wcag.dock.codes/rewrite/pl/wcag143">WCAG 1.4.3</a> */
        header { background-color: #f0f0f0; color: #aaaaaa; padding: 1em; }
        /* Brak widocznego focusu dla linków w nawigacji - BŁĄD <a href="https://wcag.dock.codes/rewrite/pl/wcag247">WCAG 2.4.7</a> */
        nav a:focus { outline: none; }
        nav a { margin-right: 1em; color: #aaaaaa; }
        /* Brak etykiety dla inputa - BŁĄD <a href="https://wcag.dock.codes/rewrite/pl/wcag332">WCAG 3.3.2</a> */
        footer input[type="text"] { padding: 0.5em; }
    </style>
</head>
<body>
    <header>
        <h1>Witamy na stronie</h1>
        <div> <!-- Zamiast <nav> - BŁĄD semantyczny -->
            <a href="#main">Główna</a>
            <a href="#services">Usługi</a>
        </div>
    </header>
    <main>
        <p>Ta sekcja jest w pełni dostępna i spełnia wszystkie kryteria WCAG.</p>
        <!-- Osadzony odtwarzacz wideo bez napisów i kontroli klawiaturą - BŁĄD <a href="https://wcag.dock.codes/rewrite/pl/wcag122">WCAG 1.2.2</a>, <a href="https://wcag.dock.codes/rewrite/pl/wcag211">WCAG 2.1.1</a> -->
        <iframe src="https://www.youtube.com/embed/somevideo" frameborder="0" allowfullscreen></iframe>
    </main>
    <footer>
        <form>
            <input type="text" placeholder="Twoje imię"> <!-- Brak etykiety <label> - BŁĄD <a href="https://wcag.dock.codes/rewrite/pl/wcag332">WCAG 3.3.2</a> -->
            <button type="submit">Wyślij</button>
        </form>
    </footer>
</body>
</html>
Skopiuj tekst

Najlepsze Praktyki i Typowe Pułapki

Najlepsze praktyki

• Dostępność od początku: Włącz testowanie dostępności do każdego etapu cyklu życia projektu – od projektu, przez rozwój, po testowanie i wdrożenie.
• Kompleksowe narzędzia: Używaj kombinacji automatycznych narzędzi do testowania (np. Lighthouse, Axe), ręcznych kontroli (np. testowanie klawiaturą, analiza kontrastu) i testów z użytkownikami technologii wspomagających.
• Edukacja zespołu: Zapewnij regularne szkolenia z dostępności dla wszystkich członków zespołu – projektantów, deweloperów, redaktorów treści, menedżerów produktu.
• Jasne procedury dla treści zewnętrznych: Określ politykę dotyczącą włączania treści od stron trzecich i wymagaj od dostawców zgodności z dostępnością lub zapewniaj alternatywy.
• Ciągłe monitorowanie: Dostępność to nie jednorazowe zadanie. Regularnie monitoruj i aktualizuj witrynę, aby zapewnić jej zgodność z ewoluującymi standardami i potrzebami użytkowników.

Typowe pułapki

• Częściowa kontrola: Przyjęcie, że jesteś odpowiedzialny tylko za główną treść lub nowo dodane funkcje, ignorując starsze sekcje lub elementy szablonu.
• Ignorowanie elementów wizualnych: Zapominanie o kontraście kolorów w nagłówkach, stopkach, ikonach lub grafikach, które nie są częścią „głównej treści”.
• Niedostępne widżety: Osadzanie widżetów stron trzecich (np. czat, kalendarz, mapy) bez sprawdzenia ich dostępności i bez zapewnienia alternatyw.
• Dynamiczne treści poza kontrolą: Treści ładowane asynchronicznie, które nie są prawidłowo ogłaszane czytnikom ekranu lub są trudne do nawigowania klawiaturą (np. karuzele, modale bez pułapki focusu).
• Zaniedbanie treści archiwalnych: Stare, ale nadal dostępne strony lub sekcje, które nie zostały zaktualizowane pod kątem dostępności, mimo że są częścią ogólnej witryny.
• Brak testowania z klawiaturą: Poleganie wyłącznie na myszy podczas testowania, co prowadzi do ignorowania problemów z dostępem dla użytkowników klawiatury.

Podsumowanie

Wymóg „Pełne strony” jest kluczowy dla zapewnienia prawdziwej dostępności. Deklarowanie zgodności z WCAG oznacza, że każdy element na danej stronie internetowej przyczynia się do dostępnego doświadczenia dla wszystkich użytkowników. Całościowe podejście do dostępności jest nie tylko zgodne z przepisami i standardami, ale przede wszystkim tworzy lepsze, bardziej intuicyjne i inkluzywne środowisko cyfrowe dla każdego.