Dostepnosc dla programistow: tworzenie inkluzywnego kodu
Programisci sa architektami dostepnosci na poziomie implementacji. Podczas gdy projektanci ustalaja fundamenty wizualne i interakcyjne, to kod ostatecznie decyduje o tym, czy strona internetowa dziala z nawigacja klawiatura, poprawnie komunikuje sie z czytnikami ekranu i utrzymuje dostepnosc w roznych przegladarkach i urzadzeniach.
Dobra wiadomosc jest taka, ze wiekszosc najlepszych praktyk dostepnosci pokrywa sie z ogolnymi najlepszymi praktykami pisania czystego, semantycznego, zgodnego ze standardami kodu. Pisanie dostepnego kodu nie polega na dodawaniu zlozonosci — polega na pisaniu kodu prawidlowo od samego poczatku.
Najpierw semantyczny HTML
Najwazniejsza rzecza, jaka mozesz zrobic dla dostepnosci, jest prawidlowe uzycie semantycznych elementow HTML. HTML5 zapewnia bogaty slownik elementow, ktore niosa wrodzono znaczenie i funkcje dostepnosci. Element <button> jest automatycznie fokusowalny, aktywowalny klawiatura i oglaszany jako przycisk przez czytniki ekranu. Element <div> z handlerem onclick nie ma zadnej z tych funkcji bez znaczacej dodatkowej pracy.
Uzywaj <nav> dla regionow nawigacji, <main> dla glownej tresci, <header> i <footer> dla odpowiednich sekcji, <section> i <article> dla obszarow tresci, <h1> do <h6> dla naglowkow w prawidlowej kolejnosci hierarchicznej, <ul> i <ol> dla list, <table> z <th> dla danych tabelarycznych, <label> z atrybutami for dla kontrolek formularzy oraz natywne elementy <button> i <a> dla kontrolek interaktywnych.
Te elementy tworza drzewo dostepnosci, ktore technologie wspomagajace wykorzystuja do prezentowania tresci uzytkownikom. Gdy uzywasz ich prawidlowo, wiele aspektow dostepnosci jest obslugiwanych automatycznie.
Struktura naglowkow
Naglowki tworza strukturalny zarys Twojej strony. Uzytkownicy czytnikow ekranu czesto nawiguja po naglowkach, aby zrozumiec organizacje tresci i znalezc konkretne sekcje. Kazda strona powinna miec dokladnie jeden <h1>, a naglowki powinny podazac za logiczna hierarchia bez pomijania poziomow — <h3> nie powinien nastepowac po <h1> bez <h2> pomiedzy nimi.
Nigdy nie uzywaj elementow naglowkow do stylowania wizualnego. Jesli potrzebujesz duzego pogrubionego tekstu, ktory nie jest naglowkiem, uzyj CSS na innym elemencie. I odwrotnie, jesli tresc funkcjonuje jako naglowek, oznacz ja jako taki niezaleznie od jej wizualnej prezentacji.
Dostepnosc klawiatury
Cala funkcjonalnosc musi byc obslugiwalna wylacznie za pomoca interfejsu klawiatury. Oznacza to, ze kazdy element interaktywny — linki, przyciski, kontrolki formularzy, menu, okna modalne, suwaki, zakladki — musi byc osiagalny za pomoca klawisza Tab (lub Shift+Tab w odwrotnym kierunku), aktywowalny za pomoca Enter lub Spacji i zamykalny tam, gdzie to stosowne.
Nigdy nie tworz pulapek klawiatury, w ktorych uzytkownicy moga wejsc tabulatorem do elementu, ale nie moga z niego wyjsc. Okna modalne powinny przechwytywac fokus w obrebie okna podczas gdy jest otwarte i zwracac fokus do elementu wywolujacego po zamknieciu, ale nacisniecie Escape powinno zawsze zamykac okno.
Upewnij sie, ze kolejnosc fokusa podaza za logiczna sekwencja odpowiadajaca ukladowi wizualnemu. Kolejnosc DOM powinna generalnie odpowiadac prezentacji wizualnej. Unikaj uzywania dodatnich wartosci tabindex, ktore nadpisuja naturalna kolejnosc fokusa i tworza zamieszanie. Uzywaj tabindex="0", aby uczynic nieinteraktywne elementy fokusowalnymi w razie potrzeby, oraz tabindex="-1" dla elementow, ktore powinny byc fokusowalne tylko programowo.
Jezyk strony
Ustaw domyslny jezyk kazdej strony za pomoca atrybutu lang na elemencie <html>. Informuje to czytniki ekranu, jakich regul wymowy uzyc. Jesli jezyk zmienia sie w tresci — na przyklad francuska fraza na polskiej stronie — oznacz zmiane atrybutem lang na elemencie zawierajacym.
Dostepnosc formularzy
Formularze to miejsce, w ktorym uzytkownicy wprowadzaja dane, i sa czestym zrodlem problemow z dostepnoscia. Kazda kontrolka formularza musi miec programowo powiazana etykiete, zazwyczaj za pomoca elementu <label> z atrybutem for odpowiadajacym id kontrolki. Grupuj powiazane kontrolki za pomoca <fieldset> i <legend>.
Gdy wykryte zostana bledy wprowadzania, zidentyfikuj pole z bledem i opisz blad w tekscie. Podaj sugestie poprawek tam, gdzie to mozliwe. Dla pol akceptujacych okreslone formaty podaj jasne instrukcje dotyczace oczekiwanego formatu. Uzywaj atrybutu autocomplete, aby umozliwic automatyczne wypelnianie przegladarki dla typowych pol, takich jak imie, email, adres i numer telefonu.
Komunikaty statusu, ktore nie otrzymuja fokusa — takie jak "element dodany do koszyka" lub "znaleziono 3 wyniki" — musza byc oglaszane uzytkownikom czytnikow ekranu za pomoca regionow live ARIA lub rol statusu.
Tekst alternatywny
Kazdy niedekoracyjny obraz musi miec znaczacy tekst alternatywny opisujacy jego tresc lub funkcje. Dla obrazow informacyjnych opisz to, co obraz przekazuje. Dla obrazow funkcjonalnych (takich jak logo linkujace do strony glownej) opisz funkcje. Dla obrazow dekoracyjnych, ktore nie dodaja informacji, uzyj pustego atrybutu alt (alt=""), aby czytniki ekranu calkowicie je pomijaly.
Zlozone obrazy, takie jak wykresy, grafy lub diagramy, moga wymagac dluzszych opisow dostarczonych przez podpis, sasiednin tekst lub polaczony szczegolowy opis.
WAI-ARIA
Specyfikacja Accessible Rich Internet Applications zapewnia dodatkowa semantyke w sytuacjach, gdy natywny HTML jest niewystarczajacy. ARIA pozwala komunikowac role, stany i wlasciwosci technologiom wspomagajacym dla niestandardowych widgetow i dynamicznych tresci.
Jednak ARIA powinno byc stosowane rozwaznie. Pierwsza zasada ARIA brzmi: jesli mozesz uzyc natywnego elementu HTML, ktory ma potrzebna semantyke i zachowanie, zrob to. ARIA nie dodaje funkcjonalnosci — dodaje jedynie semantyke. <div role="button"> nadal wymaga JavaScriptu do obslugi klawiatury, podczas gdy natywny <button> obsluguje to automatycznie.
Uzywaj rol punktow orientacyjnych ARIA (lub ich odpowiednikow HTML5) do definiowania regionow strony. Uzywaj aria-label i aria-labelledby do dostarczania dostepnych nazw, gdy widoczny tekst jest niewystarczajacy. Uzywaj aria-expanded, aria-selected, aria-checked i innych atrybutow stanu do komunikowania biezacego stanu interaktywnych widgetow. Uzywaj regionow aria-live do oglaszania dynamicznych aktualizacji tresci.
Responsywny design i przeplyw tresci
Tresc musi byc prezentowalna bez utraty informacji przy szerokosci 320 pikseli CSS bez koniecznosci poziomego przewijania. Zapewnia to, ze uzytkownicy powiekszajacy do 400% na standardowym monitorze nadal moga uzyskac dostep do wszystkich tresci. Projektuj swoje uklady tak, aby przeplywaly tresc w pojedyncza kolumne przy waskich szerokosciach, zamiast wymagac przewijania w dwoch wymiarach.
Linki pomijajace
Zapewnij mechanizm umozliwiajacy uzytkownikom klawiatury pominiecie powtarzajacych sie blokow tresci, takich jak menu nawigacyjne, i przejscie bezposrednio do glownej tresci. Najczestszym rozwiazaniem jest link "Przejdz do glownej tresci", ktory jest pierwszym fokusowalnym elementem na stronie i staje sie widoczny po uzyskaniu fokusa.
Lista kontrolna programisty
Przed wdrozeniem jakiejkolwiek funkcji zweryfikuj: cala funkcjonalnosc dziala wylacznie z klawiatura; kolejnosc fokusa jest logiczna; fokus jest widoczny na wszystkich elementach interaktywnych; wszystkie obrazy maja odpowiednie teksty alternatywne; wszystkie kontrolki formularzy maja etykiety; jezyk strony jest ustawiony; hierarchia naglowkow jest prawidlowa; ARIA jest stosowane prawidlowo i tylko wtedy, gdy jest to konieczne; tresc przeplywaco przy szerokosci 320px; a dynamiczne aktualizacje tresci sa oglaszane czytnikom ekranu.
W tej sekcji
Czy Twoja strona jest dostępna?
Przeskanuj swoją stronę za darmo i poznaj swój wynik WCAG w kilka minut.
Przeskanuj stronę za darmo