4 zasady WCAG 2.0, które powinieneś znać!

Jakiś czas temu miałem okazję uczestniczyć w bardzo ciekawym szkoleniu z zakresu stosowania zasad WCAG 2.0 (Web Content Accessibility Guidelines) prowadzonym przez Oskara Michalskiego z fundacji „Szansa dla Niewidomych” w ramach akcji „Postaw na dostępność! Akcja przeciwdziałania wykluczeniu cyfrowemu osób niepełnosprawnych i seniorów”.

Według szacunku Narodowego Spisu Powszechnego Ludności i Mieszkań z 2011 roku, aż 12,2% populacji kraju stanowią ludzie z różnego rodzaju niepełnosprawnościami. Z myślą o tej grupie organizacja W3C opracowała standard WCAG 2.0. Dokument określa w jakim stopniu strona internetowa powinna być przystosowana i dostępna dla osób niepełnosprawnych (w tym osób starszych i wykluczonych cyfrowo). Od 15 października 2012 roku wytyczne te posiadają status międzynarodowej normy ISO/IEC 40500:2012. Choć sam dokument jest dość zwięzły, aby uniknąć błędnej interpretacji, towarzyszą mu dwa dokumenty uzupełniające: Understanding WCAG 2.0 oraz Techniques for WCAG 2.0. Te natomiast po wydrukowaniu okazują się być blisko tysiąc stronicową księgą! Nie oszukujmy się – żaden programista nie da rady jej „wchłonąć”. Spełnienie minimum da nam pewność, że strona internetowa będzie dostępna nie tylko dla osób niepełnosprawnych, ale również dla każdego obywatela mającego trudności w odnalezieniu się w cyberprzestrzeni.

Gdzie leży granica „minium” ?

W Dzienniku Ustaw z dnia 16 maja ukazało się Rozporządzenie Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz. U. 2012, pozycja 526). Zapis ten zobowiązuje wszystkie podmioty realizujące zadania publiczne do dostosowania swoich serwisów internetowych do standardu WCAG 2.0 i wejdzie w życie w maju 2015 roku. Nasze minimum to właśnie to, co określa ta ustawa. Badania wykazały, że zaledwie 8% stron sektora publicznego jest dostosowana do zasad, które określa ten zapis.

Każde zalecenie WCAG 2.0 posiada kryterium sukcesu: A, AA lub AAA. Dostosowanie strony do wszystkich zaleceń jest niemożliwe, o ile nie chcemy oszpecić naszego serwisu, a zatem omówimy wspomniane wcześniej „minimum”, skupiając się na stronie technicznej, dotyczącej administratorów i developerów. Kwestie dotyczące zarządzania treścią poruszymy tylko w najbardziej krytycznych rejonach.

 

Zasada WCAG nr 1: postrzegalność

  • Elementy graficzne i inne nie będące tekstem muszą mieć czytelną i zrozumiałą alternatywę tekstową, umożliwiającą osobom niewidomym zrozumienie danego zdjęcia, animacji, apletu. Ile razy spotkaliśmy się z pustymi znacznikami „alt”? Nawet jeśli je wypełniamy, robimy to zbyt powierzchownie. Co bowiem powie niewidomemu opis „Ścieżka” do zdjęcia nowo otwartego parku? Opisujmy więc zdjęcia z myślą o tych, którzy nie mogą ich zobaczyć. Trzymając się zdjęcia parku napiszmy: alt=”Park Centralny – w kadrze ścieżka główna oraz fontanna. Doskonałe miejsce na spacery jeśli lubisz piękny śpiew ptaków”. Elementy czysto dekoracyjne, nie mające związku z artykułem, powinny posiadać puste znaczniki alt.
  • Materiały audio takie jak wywiady, wykłady czy audycje powinny mieć transkrypcję tekstową, natomiast filmowe – napisy dla osób niesłyszących. Ponadto sterowanie odtwarzaczem musi być dostępne z poziomu klawiatury – osoby niewidome nie używają przecież myszy. Pliki multimedialne oraz SWFy powinny być udostępnione w formie alternatywnej.
  • Tabele prezentujące dane muszą posiadać nagłówki oraz być zbudowane w najprostszy możliwy sposób. Nie mogą natomiast stanowić konstrukcji strony
  • Istotne informacje nie mogą opierać się jedynie na zmysłach – serce naszego artykułu powinno zawierać suche fakty.
  • Kolor nie może być jedynym sposobem wyróżnienia tekstu, a odnośniki muszą być wyraźnie widoczne – zamiast pokolorowanego <span> zastosujmy <em> lub <strong>. Linki natomiast prezentujmy tak, aby wyraźnie różniły się od tła i otaczającego je tekstu.
  • Unikajmy stosowania muzyki w tle strony. Jeśli z jakiegoś powodu jednak musisz ją mieć – pamiętaj, aby dać możliwość jej zatrzymania lub ściszenia z poziomu klawiatury. Dotyczy to wszystkich dźwięków trwających dłużej niż 3 sekundy.
  • Kontrast wszystkich elementów na stronie powinien wynosić minimum 4,5:1 dla kryterium sukcesu A. Dla AAA wartość ta powinna wynosić co najmniej 7:1.
  • Informacje na stronie powinny być w pełni widoczne po powiększeniu strony dwukrotnie używając przy tym narzędzi przeglądarki – tekst nie może na siebie nachodzić w żadnym miejscu. Najlepiej jeśli cała strona mieści się na ekranie bez konieczności przewijania jej poziomo.
  • Zawartość plików PDF czy DOC powinna być dostępna dla osób niewidomych – tworzenie PDFa zawierającego zeskanowany dokument odpada, gdyż tekst w takim przypadku wcale nie jest tekstem a tylko jego obrazem, co za tym idzie – nie jest on widoczny dla screen readerów.

 

Zasada WCAG nr 2: funkcjonalność

  • Ostrożnie z animacjami – szybko poruszające się teksty, w szczególności w kolorze czerwonym stanowią poważne zagrożenie dla epileptyków. Jeśli jakiekolwiek elementy zmieniają swoją pozycję na stronie dynamicznie – musimy dać użytkowi możliwość zatrzymania tego procesu za pomocą klawiatury.
  • Każdy pojedynczy element strony powinien być dostępny bez użycia myszy – pułapki klawiaturowe (focus) są nie do zaakceptowania. Jeśli użytkownik wejdzie do formularza za pomocą klawiatury, to musi mięć również możliwość opuszczenia go.
  • Czas – bardzo skomplikowana zasada, warto więc na chwilę się przy niej zatrzymać. Otóż zasada ta mówi, że dla każdej funkcjonalności, która posiada limity czasowe musimy udostępnić użytkownikowi możliwość jej kontroli. Co to oznacza w praktyce? Nie więcej niż to, że aby zaliczyć kryterium A, musimy zapewnić co najmniej jedną z następujących funkcjonalności:
    • możliwość wyłączenia – użytkownik może wyłączyć odliczanie przed upływem czasu; lub
    • dostosowanie – użytkownik ma możliwość przedłużenia czasu dostępności zawartości co najmniej 10-krotnie; lub
    • przedłużenie – użytkownik musi być ostrzeżony o kończącym się czasie co najmniej 20 sekund przed jego upływem i mieć możliwość szybkiej reakcji (np. poprzez naciśnięcie danego przycisku na klawiaturze) skutkującej przedłużeniem odliczania.Od tej reguły są jednak pewne wyjątki:
    • gdy limit czasu jest kluczowy, gdyż dotyczy wydarzenia mającego miejsce w czasie rzeczywistym i nie ma możliwości jego przedłużenia. Dotyczy to np. aukcji; lub
    • gdy limit czasu jest kluczowy, gdyż przedłużenie lub usunięcie go może skutkować unieważnieniem fundamentalnej funkcjonalności, która to nie może zostać dostarczona w inny sposób; lub
    • limit czasu wynosi więcej niż 20 godzin.
  • Każda funkcja odświeżająca zawartość strony w sposób dynamiczny, która rusza automatycznie musi mieć opcję jej zatrzymania, ukrycia lub dostosowania częstotliwości. Wyjątkiem podobnie jak w poprzednim punkcie jest sytuacja, w której odświeżanie jest kluczowe dla danej funkcjonalności.
  • Dla dużych serwisów, gdzie w nawigacji głównej jest dużo odnośników zaleca się zastosowanie linku pozwalającego w prosty sposób przejść do głównej treści strony.
  • Tytuł strony (znacznik <title>) powinien być spójny, zwięzły i unikalny oraz dobrze odzwierciedlać zawartość strony.
  • Do każdej treści na stronie powinny prowadzić co najmniej dwie różne drogi – zawsze należy zastosować chociaż dodatkowy sposób nawigacji poza tą główną. Może to być mapa strony czy wyszukiwarka.
  • Podstrony powinny być oparte o nagłówki (h1 – h6), przy czym h1 zarezerwowany powinien być dla tytułu strony i pojawiać się tylko raz. Współczesne screen readery dają możliwość „przeskakiwania” po nagłówkach, co znacząco pomaga dostać się do konkretnej, interesującej nas informacji. W związku z tym nagłówki powinny być używane w taki sposób, aby łącznie zresztą artykułu stanowiły spójną treść  – pilnujemy hierarchii i nie wstawiamy do artykułu h3 jeśli 2 akapity wcześniej użyliśmy h4.
  • Nawigacja powinna być zbudowana w sposób spójny i logiczny – focus powinien przebiegać kolejno po wszystkich odnośnikach, bez pomijania pojedynczych pozycji.
  • Focus powinien być dobrze widoczny – często usuwamy szkaradne domyśle style pseudo selektorów :focus. To duży błąd, skutkujący tym, że serwis nie przejdzie pomyślnie audytu (pozycja ta stanowi kryterium A). Jeśli usuwamy domyślne style bez powodu lub z myślą o unifikacji we wszystkich przeglądarkach, to pamiętajmy o udostępnieniu takich, które będą wyraźne i zauważalne dla osób niedowidzących.

 

Zasada WCAG nr 3: zrozumiałość

  • Język na stronie wielojęzycznej lub dla dokumentów do pobrania w wielu wersjach językowych powinien być określony w sposób umożliwiający rozpoznanie go niewidomym – postawienie przed nazwą pliku flagi używając CSS background odpada. Powinniśmy przynajmniej dorzucić kod języka w nawiasie. Ponadto język strony oraz każdego obcojęzycznego fragmentu treści powinien być określony w atrybucie lang.
  • Zdecydowanie nie powinniśmy otwierać automatycznie żadnych okien, kart, popup’ów (w tym dynamicznych modali) bez wiedzy użytkownika. W przypadku modali pamiętajmy o możliwości dostania się do ich zawartości za pomocą klawiatury.
  • Zmiana kontekstu na stronie może mieć miejsce tylko po zatwierdzeniu jej przez użytkownika.
  • Formularze:
    • <label> nadal potrzebny – atrybut „placeholder” nie jest w żadnym wypadku alternatywą dla opisu pola formularza. Poprawne etykiety są kluczowe dla formularzy.
    • Pola obowiązkowe muszą być oznaczone w sposób wyraźny i zrozumiały – idealnym rozwiązaniem jest po prostu dopisanie „(wymagane)” tuż za etykietą.
    • Jeśli wymagamy konkretnego formatu danych podawanych przez użytkownika, to powinniśmy ten format jasno określić, najlepiej w sposób tekstowy, np. dla daty dodajmy: „(dd-mm-rrrr)”.
    • W przypadku odrzucenia formularza w związku z błędami w formularzu konieczne są sugestie dotyczące usunięcia tych błędów – walidacja graficzna to za mało. Niewidomy nie zobaczy czerwonej ramki, czy też graficznego wykrzyknika wstawionego przez CSS. Ponadto nie wystarczy napisać obok pola: „Błąd”. Jeśli użytkownik podał niepoprawny e-mail, to należy go o tym poinformować wskazując pole e-mail jako przyczynę niepowodzenia.
    • Powinniśmy dać użytkownikowi szansę na zrewidowanie i modyfikację podanych przez niego danych przed ostatecznym zatwierdzeniem. Dobrym przykładem jest strona podglądu zamówienia podczas procesu zakupu online. Po podaniu adresu (lub adresów, jeśli adres dostawy jest inny), wybraniu metod dostawy i zapłaty, najczęściej widzimy stronę z podsumowaniem dającym szansę na szybki powrót do danej sekcji formularza i edycję poszczególnych pól.

Zasada WCAG nr 4: solidność

  • Strona (i wszystkie jej podstrony) nie powinny zawierać błędów składniowych – punktem odniesienia jest osławiony wśród programistów Front-End walidator W3C (HTML oraz CSS).
  • Wszystkie ramki powinny posiadać tytuły.

Cóż, większość wymienionych wyżej zaleceń mieści się w kryterium sukcesu A, ale to nie znaczy, że w AAA znajdziemy same „hardkory”. Są pewne wisienki w tej strefie, które są technicznie bardzo proste do zaimplementowania, a nawet wiele z nich zostało już zaimplementowanych wcześniej. Jako przykład można tu przytoczyć „okruszki” (z ang. breacrumbs), które wiele serwisów stosuje ze względu chociażby na SEO.

Mam nadzieję, że ten długi, aczkolwiek nie wyczerpujący w pełni tematu artykuł przyda się wielu osobom i być może posłuży nawet jako swoista „checklista” przed opublikowaniem serwisu.

 

pluswerk