Zasady POUR: fundament dostepnosci stron internetowych

Kazde wymaganie w WCAG jest zbudowane na czterech podstawowych zasadach. Jesli doglebnie zrozumiesz te zasady, czesto mozesz intuicyjnie identyfikowac problemy z dostepnoscia, nawet bez zapamietywania poszczegolnych kryteriow sukcesu. Te cztery zasady — Postrzegalnosc, Funkcjonalnosc, Zrozumialosc i Solidnosc — definiuja fundamentalne warunki, ktore musza byc spelnione, aby tresci byly dostepne.

Postrzegalnosc: uzytkownicy musza byc w stanie postrzegac tresc

Zasada postrzegalnosci dotyczy najbardziej fundamentalnego wymogu dostepnosci: informacja musi byc dostepna dla co najmniej jednego ze zmyslow uzytkownika. Jesli uzytkownik w ogole nie moze postrzegac tresci, zaden dobry projekt interakcji ani czysty kod nie uczyni jej uzyteczna.

Ta zasada napedza wymagania dotyczace alternatyw tekstowych dla tresci nietekstowych, napisow i transkrypcji dla audio i wideo, wystarczajacego kontrastu kolorow, mozliwosci zmiany rozmiaru tekstu oraz oddzielenia informacji od jej prezentacji wizualnej.

Jak to wyglada w praktyce:

Obraz baneru promocyjnego oglaszajacego sezonowa wyprzedaz potrzebuje tekstu alternatywnego opisujacego promocje, poniewaz niewidomy uzytkownik nie zobaczy obrazu. Film szkoleniowy potrzebuje napisow, poniewaz niesalyszacy uzytkownik nie uslyszy narracji. Tekst podstawowy na Twojej stronie potrzebuje wystarczajacego kontrastu z tlem, poniewaz slabowidzacy uzytkownik moze nie byc w stanie przeczytac tekstu o niskim kontrascie. Formularz uzywajacy czerwonej ramki do wskazywania bledow potrzebuje rowniez komunikatu tekstowego, poniewaz daltonista moze nie dostrzec czerwonego koloru.

Typowe bledy:

Obrazy bez tekstu alternatywnego. Filmy bez napisow. Niewystarczajacy kontrast kolorow. Informacje przekazywane wylacznie przez kolor. Tresc, ktora staje sie niedostepna przy powiekszeniu do 200%. Tekst zastepczy uzywany jako jedyna etykieta pol formularzy.

Funkcjonalnosc: uzytkownicy musza byc w stanie obslugiwac interfejs

Zasada funkcjonalnosci zapewnia, ze uzytkownicy moga wchodzic w interakcje ze wszystkimi elementami interfejsu i nawigowac przez cala tresc, niezaleznie od tego, jak wchodza w interakcje ze swoim urzadzeniem. Piekna, postrzegalna strona internetowa jest bezuzyteczna, jesli uzytkownik nie moze kliknac, dotknac ani przejsc klawiatura do potrzebnej tresci.

Ta zasada napedza wymagania dotyczace dostepnosci klawiatury, wystarczajacego czasu na interakcje z trescia, unikania tresci mogacych powodowac napady padaczkowe, skutecznych mechanizmow nawigacji i elastycznych metod wprowadzania danych.

Jak to wyglada w praktyce:

Menu rozwijane otwierajace sie przy najechaniu musza rowniez otwierac sie przy fokusie klawiatury i byc nawigowalne klawiszami strzalek. Limit czasu sesji na stronie bankowej musi ostrzec uzytkownika i pozwolic mu przedluzyc sesje. Pokaz slajdow, ktory automatycznie sie przesuwa, musi miec kontrolki wstrzymywania. Panel filtrow wyszukiwania musi byc dostepny klawiatura, aby uzytkownicy nie mogacy uzywac myszy mogli nadal filtrowac wyniki. Elementy interaktywne musza byc wystarczajaco duze, aby mozna je bylo dotknac bez przypadkowego trafienia sasiadujacych kontrolek.

Typowe bledy:

Elementy interaktywne reagujace tylko na klikniecie mysza. Menu rozwijane niedostepne klawiatura. Pulapki fokusa w oknach modalnych lub widgetach. Brakujace linki pomijajace. Limity czasu bez opcji przedluzenia. Tresc migajaca szybko.

Zrozumialosc: uzytkownicy musza byc w stanie zrozumiec tresc i interfejs

Zasada zrozumialosci zapewnia, ze zarowno prezentowane informacje, jak i sposob dzialania interfejsu sa zrozumiale dla uzytkownikow. Tresc, ktora jest postrzegalna i funkcjonalna, ale niezrozumiala, nadal nie spelnia testu dostepnosci.

Ta zasada napedza wymagania dotyczace czytelnej tresci, przewidywalnego zachowania interfejsu oraz pomocy przy wprowadzaniu danych, ktora pomaga uzytkownikom unikac i poprawiac bledy.

Jak to wyglada w praktyce:

Strona napisana po polsku ma atrybut lang="pl", aby czytniki ekranu uzywaly prawidlowej wymowy. Menu nawigacyjne pojawiaja sie w tym samym miejscu i kolejnosci na kazdej stronie. Gdy uzytkownik popelni blad w formularzu, blad jest jasno zidentyfikowany i podana jest sugestia poprawki. Uzytkownicy sa ostrzegani przed czynnosciami o istotnych konsekwencjach, takimi jak przeslanie platnosci lub usuniecie danych.

Typowe bledy:

Brakujace deklaracje jezyka. Niespojana nawigacja miedzy stronami. Walidacja formularzy identyfikujaca bledy bez ich wyjasniania. Automatyczne zmiany kontekstu wyzwalane przez wybranie opcji lub wejscie do pola. Tresc pelna zargonu bez wyjasnien.

Solidnosc: tresc musi dzialac w roznych technologiach

Zasada solidnosci zapewnia, ze tresc jest zbudowana na solidnych podstawach technicznych, ktore dzialaja niezawodnie w roznych przegladarkach, urzadzeniach i technologiach wspomagajacych — zarowno obecnych, jak i przyszlych.

Ta zasada napedza wymagania dotyczace czystych, zgodnych ze standardami znacznikow, prawidlowego uzywania ARIA, gdy natywny HTML jest niewystarczajacy, oraz programowej komunikacji stanow i wartosci elementow do technologii wspomagajacych.

Jak to wyglada w praktyce:

Niestandardowy widget rozwijany uzywa prawidlowych rol, stanow i wlasciwosci ARIA, aby czytnik ekranu oglosil go jako pole kombi, przekazal, czy jest rozwiniety, czy zwiniety, i zidentyfikowal aktualnie wybraoc opcje. Wskaznik czatu na zywo uzywa regionu ARIA live, aby czytniki ekranu oglaszaly nowe wiadomosci bez koniecznosci nawigowania uzytkownika do okna czatu. Komunikaty statusu, takie jak "Element dodany do koszyka", sa oglaszane czytnikom ekranu poprzez odpowiednie role.

Typowe bledy:

Niestandardowe widgety bez rol i stanow ARIA. Komunikaty statusu wyswietlane tylko wizualnie, ale nie oglaszane czytnikom ekranu. Nieprawidlowe uzycie ARIA konfliktujace z natywna semantyka HTML. Tresc dzialajaca w jednej przegladarce, ale zawodzaca w innej z powodu niestandardowego kodu.

Stosowanie POUR jako zasady projektowania

Zasady POUR to nie tylko kategorie organizujace kryteria sukcesu — to ramy myslenia. Oceniajac dowolny fragment tresci lub funkcjonalnosci, zadaj cztery pytania: Czy wszyscy uzytkownicy moga to postrzegac? Czy wszyscy uzytkownicy moga to obslugiwac? Czy wszyscy uzytkownicy moga to zrozumiec? Czy bedzie to dzialac we wszystkich odpowiednich technologiach? Jesli odpowiedz na ktorekolwiek z tych pytan brzmi nie, zidentyfikowales bariere dostepnosci.