Zespół audytorów Biura ds. Osób z Niepełnosprawnościami UW stale wykonuje kontrole zgodności stron i aplikacji internetowych Uniwersytetu z Ustawą z dnia 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych. Wynikiem badań witryn UW są indywidualne raporty wraz z sugestiami sposobów ich naprawy. Generowane są Deklaracje Dostępności do umieszczenia na stronach. Specjaliści BON przebadali już ok. 340 stron i aplikacji internetowych pod kątem ich zgodności z wytycznymi standardu WCAG 2.1. Wyniki badań znajdują się w naszym autorskim Systemie Audytów Dostępności.

Przypominamy, że istotne zmiany istniejących witryn, oraz każdą nową stronę w domenie “uw.edu.pl” należy bezzwłocznie zgłosić do badania zgodności z ustawą.

Po kilku seriach audytów przedstawiamy najczęściej spotykane błędy i problemy występujące w badanych serwisach. Zamieszczamy też  krótkie wyjaśnienia i sposoby uniknięcia tych błędów.

  1. Jako błąd oznaczono naruszenia kryteriów sukcesu WCAG 2.1 poziom AA. Oznacza to, że serwis nie spełnia wymogów Ustawy.
  2. Jako problem oznaczono rozwiązania i elementy witryn, które mogą wiązać się z utrudnieniem odczytu lub obsługi strony. Są to albo naruszenia niewymaganego poziomu AAA, albo sytuacja, gdy serwis formalnie spełnia wymogi WCAG 2.1, ale niekoniecznie poprawia to jego dostępność.

Najczęstsze błędy i problemy dostępności stron UW oraz propozycje ich naprawy:

Stan na maj 2022 r.

Serwis nie posiada mapy stron. (problem) – Procent wystąpień: 72,2%

Dotyczy kryteriów sukcesu WCAG: 2.4.5 Wiele dróg

Kto może poprawić: Administrator strony

Opis / zalecane rozwiązanie: Mapy stron bardzo ułatwiają wyszukanie stosownej treści osobom z każdego rodzaju dysfunkcjami. Pozwalają dotrzeć do wszelkich istotnych informacji alternatywną drogą (np. oprócz nawigacji w menu, czy odnośników na podstronach). Zaleca się zamieścić mapę strony w postaci listy odnośników do wszystkich głównych obszarów (np. kategorii, najważniejszych stron) oraz istotnych obszarów podrzędnych i zagadnień. Systemy CMS często mają wtyczki pozwalające na automatyczne generowanie mapy, istnieją także generatory online. Warto szukać hasła: “HTML Site Map Generator”.

Błędy łączy (odnośniki, linki).

  • Serwis posiada odnośniki kontekstowe, których treść nie informuje jednoznacznie o celu (błąd) – Procent wystąpień: 44,5%
  • Serwis posiada powtórzone linki – Procent wystąpień: 28,6%
  • W serwisie występują elementy klikalne bez jednoznacznych etykiet lub tekstów linków (problem) – Procent wystąpień: 14,3%
  • Serwis posiada odnośniki, których treścią jest adres URL (błąd) – Procent wystąpień: 9,8%
  • Serwis posiada odnośniki, które nie informują o otwarciu podstrony w nowym oknie – Procent wystąpień: 9,8%

Dotyczy kryteriów sukcesu WCAG:

Kto może poprawić: w treści — Redaktor treści, linki generowane automatycznie — Web developer

Opis / zalecane rozwiązanie: Każdy element klikalny powinien być jednoznacznie opisany (tytułem, etykietą, treścią), aby technologie wspomagające informowały użytkowników o jego funkcji i przeznaczeniu. Odnośniki powinny precyzyjnie opisywać cel, do którego prowadzą. Przykład: poprawnym tekstem odnośnika (lub atrybutu alt w przypadku grafik będących linkami) poniżej fragmentu artykułu w aktualnościach będzie np.: “Czytaj więcej o Tytuł Artykułu”, a niepoprawnym: “Więcej”. Oczywiście można część takiego opisu ukryć wizualnie używając np. klasy CSS Bootstrap – <a href="artykul"><span class="sr-only">Czytaj </span>więcej <span aria-hidden="true">... </span><span class="sr-only">o Tytuł Artykułu</span></a>. Taki kod wyświetli tekst “Czytaj więcej o Tytuł Artykułu” a jednocześnie czytniki ekranu odczytają całą treść.

O ile to możliwe adres URL zastępujemy opisem. Np. zamiast https://google.com podajmy Wyszukiwarka Google. Podobnie z przyciskami — jeśli zawierają grafikę, dodajemy treść przycisku w atrybucie “alt”. np:

<button type="button"><img src="play.png" alt="włącz muzykę" /></button>

lub tekstem <button type="button"><img src="play.png" alt="" /><span class="sr-only">włącz muzykę</span></button>

Odnośniki znajdujące się obok siebie i prowadzące do tego samego celu należy zastąpić jednym. Zamiast osobnych obrazka, tytułu i fragmentu treści, z których każdy jest odnośnikiem do tego samego artykułu, można obrazek i tytuł zamieścić razem wewnątrz jednego linku i usunąć linkowanie z fragmentu treści. Ten błąd najczęściej występuje  w listach odnośników np.: na stronach aktualności, na stronach archiwów WordPressa.

Łącza otwierające nowe okno / kartę przeglądarki powinny zawierać taką informację. Nieoczekiwana zmiana kontekstu wprowadza w błąd i bardzo utrudnia korzystanie z serwisu. Dobrą praktyką może być np. umieszczenie graficznego oznaczenia z atrybutem alt=”otwiera nowe okno”.

Obsługa przy użyciu klawiatury

  • Elementy rozwijalne menu głównego nie są dostępne za pomocą klawiatury (błąd). – Procent wystąpień: 40,3%
  • Strona zawiera elementy klikalne, które nie są obsługiwane przy użyciu klawiatury  (błąd) – Procent wystąpień: 25,4%
  • Elementy menu głównego nie są dostępne z poziomu klawiatury (błąd) –  Procent wystąpień: 20,9%
  • Serwis posiada elementy klikalne, które nie są dostępne przy użyciu klawiatury (błąd) – Procent wystąpień: 12,7%

Dotyczy kryteriów sukcesu WCAG: 2.1.1 Klawiatura

Kto może poprawić: Web developer

Opis / zalecane rozwiązanie: Budowa menu musi zapewniać dostęp do wszystkich jego elementów przy pomocy klawiatury. Każdy kolejny link w menu musi być dostępny, gdy naciskamy klawisz Tab.

Elementy rozwijalne należy zawsze oznaczać atrybutami ARIA: aria-haspopup="true", oraz ich stan przy pomocy aria-expanded="false/true". Należy też tak budować obsługę rozwijania, aby reagowała ona na klawisz Enter i zmieniała wartość aria-expanded. Element rozwijalny nie powinien zawierać linku, bo zamiast rozwinąć podmenu, przejedzie do celu odnośnika. Dzięki temu nawigujący klawiaturą mają możliwość szybkiego dotarcia do potrzebnego menu i dostępu do jego podmenu. Są również uprzedzani, czy Tab przeniesie ich do kolejnego głównego elementu menu, czy do rozwiniętej listy. Pamiętajmy o prawidłowej kolejności list rozwijanych, by wyjście z nich prowadziło do kolejnego elementu głównego menu i nie pomijało go (prawidłowy tabindex).

Należy się upewnić, że każdy aktywny element serwisu, wyszukiwarki i funkcji sterujących działaniem strony otrzymuje focus klawiatury i że kolejność tabindex jest logiczna. Każdy przycisk, ikona, którą można kliknąć, muszą być obsłużone klawiaturą i poprawnie zgłaszać swój stan czytnikom ekranu. Dobrą praktyką jest budowanie menu w oparciu o strukturę listy z linkami. W przypadku skomplikowanych rozwiązań np.: megamenu należy w razie potrzeby opatrzyć jego elementy atrybutem tabindex ze stosowną wartością. Należy także pamiętać o poprawnym sposobie opuszczenia elementu i przejścia do dalszej części strony przy pomocy klawiatury.

Serwis może posiadać odnośniki do dokumentów, które nie są dostępne (problem). – Procent wystąpień: 42,7%

Dotyczy kryteriów sukcesu WCAG: wiele kryteriów – osadzane i linkowane dokumenty same powinny być zgodne z WCAG.

Kto może poprawić: Redaktor treści

Opis / zalecane rozwiązanie: Należy sprawdzić, czy dokumenty umieszczone na stronach są w formatach umożliwiających ich odczytanie przy pomocy technologii wspomagających. Unikamy formatu pdf (chyba że mamy pewność, że pdf został przygotowany z myślą o dostępności. Najbezpieczniej zwykle umieszczać dokumenty w formacie MS Word – docx. Najbardziej porządane jest umieszczanie dokumentów w kilku formatach do wyboru.

Serwis posiada odnośniki wyróżnione tylko kolorem. – Procent wystąpień: 42,1%

Dotyczy kryteriów sukcesu WCAG: 1.4.1 Użycie koloru

Kto może poprawić: Administrator strony, Web developer

Opis / zalecane rozwiązanie: Odnośniki (oraz inne istotne elementy aktywne i informacyjne) powinny być wyróżniane również inną cechą oprócz koloru. Może być to problemem dla osób z zaburzeniami widzenia, a szczególnie z nierozróżnianiem kolorów. Dlatego właśnie warto dodać w CSS deklarację a {text-decoration: underline;}. Podobnie z komunikatami np. o poprawności wypełnienia pola formularza — samo wyróżnienie ich kolorem czerwonym, czy zielonym może być niewystarczające. Warto dodać również graficzną ikonę albo napisy (OK, Błąd!) obok takiego pola.

Kontrast koloru treści z tłem

  • Serwis posiada elementy niespełniające wymogów kontrastu (problem). – Procent wystąpień: 40,3%
  • Serwis posiada odnośniki, które nie spełniają wymogów kontrastu (błąd). – Procent wystąpień: 14,3%
  • Serwis posiada teksty umieszczane na ilustracjach, które mogą nie spełniać wymogów kontrastu – Procent wystąpień: 9,9%

Dotyczy kryteriów sukcesu WCAG: 1.4.3 Kontrast (minimum)

Kto może poprawić: gdy system pozwala – Administrator strony, Web developer

Opis / zalecane rozwiązanie: Elementy tekstowe, w tym odnośniki muszą mieć kolor zapewniający odpowiedni kontrast z tłem. Zapewni to prawidłowy odczyt i obsługę przez osoby z dysfunkcjami wzroku. Dotyczy to podstawowej wersji strony — dodatkowe wersje o wysokim kontraście mogą być nieobowiązkową, uzupełniającą funkcją. Wyjątkiem są sytuacje, gdy użyte kolory są np. częścią identyfikacji wizualnej. Wówczas należy zadbać o łatwy dostęp do specjalnej, kontrastowej wersji. W przypadku odnośników trzeba również pamiętać o prawidłowych kolorach dla wszystkich stanów (pseudoklasy CSS – : visited, :focus, :hover, :active). W przypadku tekstów na tle obrazków w uzyskaniu kontrastu możne pomóc umieszczenie ich na ramce z przyciemniającym tłem (nawet półprzezroczystym, np.: background-color: rgba(0, 0, 0, 0.5)). Polecanym narzędziem do badania kontrastu jest Colour Contrast Analyser (CCA) firmy TPGi.

Odnośniki wewnętrznie — skip linki

  • Serwis nie posiada odnośników umożliwiających bezpośrednie przejście do treści stron (błąd). – Procent wystąpień: 41,1%
  • Link do przeskoczenia do treści strony istnieje, ale jest uszkodzony – 9,8%

Dotyczy kryteriów sukcesu WCAG: 2.4.1 Możliwość pominięcia bloków

Kto może poprawić: Administrator strony, Web developer

Opis / zalecane rozwiązanie: Odnośniki pozwalające przechodzić bezpośrednio do treści (skip linki) bardzo przyspieszają obsługę strony przy pomocy klawiatury. Obowiązkowy jest link typu “przeskocz do treści”, ale w przypadku rozbudowanej strony mogą być niezbędne dodatkowe np.: “Przeskocz do menu”. Nie powinny być one domyślnie wyświetlane, natomiast muszą jako pierwsze na stronie przechwytywać focus klawiatury. Koniecznie powinny zostać wyświetlone po uzyskaniu fokusu klawiatury. To ważne dla osób widzących, które nie mogą korzystać z myszy. Umieszczamy je od razu na początku <body> przed obszarem <header> lub na jego początku.

Dodanie skip linków do strony nie wymaga wiele pracy i umiejętności. Tam, gdzie to możliwe zalecamy dopisanie kodu HTML– np. w WordPress umieszczamy go w header.php oraz formatowanie w style.css lub w opcji “Własny CSS” w menu  “Dostosuj”.  Jeśli to problem, można zastosować wtyczkę WP-Accesibility, pamiętając o poprawnej konfiguracji celu odnośnika. Wiele z tych błędów wynika z niepoprawnej konfiguracji CMS WordPress lub z zastosowania innej niż podana wtyczki “dostępności”.

Przykład poprawnego kodu skip-linku:

HTML:

<a class="skip-link screen-reader-text" href="#content">Skocz do treści</a>

UWAGA: Zakładamy tu, że kontener treści ma id=”content”. Proszę pamiętać o dostosowaniu celu odnośnika do rzeczywistego identyfikatora na stronie!!! Jeśli kontener ze swojej natury nie przejmuje fokusa klawiatury, trzeba to poprawić atrybutem tabindex np. tak:

<div id="content" tabindex="-1"> ... główna  treść ... </div>

Tak skonstruowany odnośnik będzie działał poprawnie i będzie przyjazny dla czytników ekranu (screenreaderów).

CSS:


.screen-reader-text {
border: 0;
clip: rect(1px, 1px, 1px, 1px);
clip-path: inset(50%);
height: 1px;
margin: -1px;
overflow: hidden;
padding: 0;
position: absolute !important;
width: 1px;
word-wrap: normal !important;
}
.screen-reader-text:focus-visible {
background-color: #f1f1f1;
border-radius: 3px;
box-shadow: 0 0 2px 2px rgba(0, 0, 0, 0.6);
clip: auto !important;
clip-path: none;
color: #40273a;
display: block;
font-size: 0.875rem;
font-weight: 700;
height: auto;
left: 5px;
line-height: normal;
padding: 15px 23px 14px;
text-decoration: none;
top: 5px;
width: auto;
z-index: 100000;
}

Serwis nie posiada mechanizmu wyszukiwania (problem). – Procent wystąpień: 26%

Dotyczy kryteriów sukcesu WCAG: 2.4.5 Wiele dróg

Kto może poprawić: często Administrator strony, Web developer

Opis / zalecane rozwiązanie: Możliwość wyszukiwania jest niezwykle pomocna w przypadku osób z dysfunkcjami wzroku i funkcji poznawczych. Zapewnia szybszy, nierozproszony dostęp do treści. Większość systemów CMS ma wbudowany mechanizm wyszukiwania. W przypadku stron opartych na WordPressie zalecamy natywną wyszukiwarkę wywoływaną w PHP funkcją get_search_form().  Można poprawić wyniki wyszukiwania używając wtyczki WP Extended Search. Należy bardzo uważać na wtyczki zmieniające formularz wyszukiwania. Funkcjonalność “live search” jest intuicyjna i przyspiesza wyszukiwanie, ale znane wtyczki zawierają błędy dostępności w formularzu i obsłudze podpowiadanych wyników. W przypadku innych systemów można użyć np. Programmable Search Engine firmy Google.

Grafiki i obrazy w serwisie.

  • Serwis posiada grafiki będące odnośnikami i nieposiadające opisu w znaczniku ALT lub jest on niewystarczający (błąd). – Procent wystąpień: 24,8%
  • Serwis posiada ilustracje bez tekstów alternatywnych (błąd). – Procent wystąpień: 22,4%
  • Serwis posiada ilustracje z napisami bez tekstów alternatywnych (błąd). – 7,7%

Dotyczy kryteriów sukcesu WCAG: 1.1.1 Treść nietekstowa

Kto może poprawić: obrazy w treści – Redaktor treści, obrazy zakodowane w strukturze serwisu – Web developer

Opis / zalecane rozwiązanie: Grafiki będące odnośnikami określa się jako funkcjonalne i muszą zawierać atrybut alt jednoznacznie informujący o ich przeznaczeniu lub celu odnośnika. W tym przypadku treść alternatywna obrazka staje się tekstową treścią odnośnika. Nie opisujemy ich zawartości a nazwę strony, treść, sekcję, kategorię itp. do której prowadzą.

Ilustracje przekazujące istotną treść zawsze powinny być opisane w znaczniku alt. Powinien być on dość krótki, ale jednoznacznie określający zawartość obrazka. Przykład: zamiast alt="studnia" użyjmy raczej alt="Dziewiętnastowieczny żuraw studzienny". Brak tego znacznika powoduje, że technologie wspomagające odczytują nic niemówiący adres obrazka. Z kolei obrazki o funkcji ozdobnej lub posiadające rozszerzony opis w treści zawsze oznaczamy <img src="image.png" alt="">. Pusty alt spowoduje, że czytniki ekranowe pominą ten obrazek.

Szczególnie ważne jest zapewnienie treści tekstowej w przypadku obrazków z napisami. Jeśli ich treść jest długa, oznaczmy je jako ozdobne i dodajmy tekstową wersję napisów (może być ona ukryta wizualnie). Dobrym pomysłem jest też zastąpienie obrazka z dużą ilością tekstu wersją HTML (np. obrazek w tle a informacje jako tekst — pamiętajmy o kontraście).

Elementy dynamiczne, rozwijalne serwisu

  • Serwis posiada elementy rozwijalne, które nie są dostępne przy użyciu klawiatury (błąd). – Procent wystąpień: 22%
  • W serwisie występują problemy z obsługą menu rozwijalnego przy użyciu programu odczytu ekranu – brak komunikatu informującego, że menu zostało rozwinięte – Procent wystąpień: 5,7%

Dotyczy kryteriów sukcesu WCAG:

Kto może poprawić: Web developer

Opis / zalecane rozwiązanie: Listy rozwijalne dostępne dla technologii wspomagających łatwo budować w oparciu o elementy <input type="select">. Jeżeli wykorzystujemy inną technikę, trzeba zapewnić focus klawiatury i nawigację klawiszami kursora każdemu elementowi listy. Elementy rozwijalne należy zawsze oznaczać atrybutami ARIA: aria-haspopup="true" oraz ich stan przy pomocy aria-expanded="false/true".

Serwis posiada odnośniki do pobrania dokumentów bez informacji o ich formacie (problem). – Procent wystąpień: 17%

Dotyczy kryteriów sukcesu WCAG: 2.4.9 Cel łącza (z samego łącza)

Kto może poprawić: Redaktor treści

Opis / zalecane rozwiązanie: Informowanie użytkowników o formacie dokumentu, pozwala im przygotować się do obsługi konkretnego narzędzia, którym te pliki otworzą. Mogą też dzięki temu wybrać najbardziej odpowiedni dla nich format. Warto zapewniać alternatywne formaty udostępnianych dokumentów. Treść odnośnika do dokumentu powinna zawierać jasne określenie jego formatu. Np. Pobierz TYTUŁ DOKUMENTU — dokument pdf.

Nagłówki — struktura treści.

  • Strony serwisu nie posiadają nagłówka H1 (błąd). – Procent wystąpień: 14,3%
  • Strony serwisu mogą posiadać wielokrotne nagłówki H1 (błąd). – Procent wystąpień: 14,3%
  • Strona główna nie posiada nagłówka H1 (błąd). – Procent wystąpień: 14,3%
  • Strony serwisu posiadają błędy w definicji hierarchii nagłówków lub nie posiadają nagłówka H1 (błąd) – 12,2%
  • W serwisie występują problemy z właściwą definicją struktury nagłówków (problem) – 6%

Dotyczy kryteriów sukcesu WCAG:

Kto może poprawić: Redaktor treści, nagłówki generowane automatycznie – Web developer

Opis / zalecane rozwiązanie: Jeżeli strona ma tytuł bądź tytułem jest opatrzona jakakolwiek znacząca treść (nie musi być tekstowa), to zawsze formatujemy go nagłówkiem <h1>. To najważniejszy punkt orientacyjny dla przeglądarek i technologii wspomagających. Powinien informować o zawartości treści w najszerszym kontekście. UWAGA: Na stronie może być tylko jeden nagłówek <h1>!

Sekcje treści powinny być opatrzone nagłówkami, które je identyfikują. Bardzo ułatwia to osobom niewidomym szybkie zorientowanie się i dotarcie do interesującego ich fragmentu treści. Nagłówki powinny także reprezentować logiczną strukturę i powiązania treści poprzez prawidłową hierarchię nagłówków. Przykład:

<h1>Informacje o wydziale</h1> <!-- tytuł strony -->
    <h2>Instytuty wydziału</h2>
    <h2>Pracownicy wydziału</h2>
       <h3>Władze wydziału</h3>
       <h3>Pracownicy dydaktyczni</h3>
       <h3>Pracwonicy administracyjni</h3>
   <h2>Informacje dla studentów</h2>
   <h2>Rekrutacja</h2>

Należy pamiętać, że nagłówki nie służą jedynie do graficznego wyróżniania tekstu. Ich struktura mówi technologiom wspomagającym (ale i wyszukiwarce Google), o czym jest teść (<h1>), jakie elementy zawiera(<h2>) i wewnątrz nich kolejne poziomy nagłówków pozwalają podzielić logicznie treść na kolejne składniki. Jeżeli domyślny wygląd nagłówków nie pasuje do koncepcji graficznej, do ich formatowania używamy CSS.

Serwis posiada elementy wyróżnione cechami wyglądu i nieoznaczone właściwymi znacznikami (błąd). – Procent wystąpień: 14%

Dotyczy kryteriów sukcesu WCAG: 4.1.2 Nazwa, rola, wartość

Kto może poprawić: Web developer

Opis / zalecane rozwiązanie: Należy trzymać się kanonu HTML. Poprawna semantyka kodu HTML jest kluczowa w przypadku technologii wspomagających. Jeżeli element tekstowy pełni funkcję nagłówka wyróżniającego dalszy tekst, to oznaczamy go znacznikiem <h…>, zamiast zmieniać jego wielkość i kolor. Podkreślenia tekstu kojarzone są z odnośnikami. W formularzach stosujemy elementy ⁣, zamiast zastępować je np. elementami <div> czy <span> powiązanymi z JavaScriptem. Niepoprawnie określone znaczniki HTML wprowadzają technologie asystujące w błąd i mogą powodować dodatkowe problemy np.: z responsywnością.

Częstym błędem jest używanie znaczników odnośnika <a> jako elementu wywołującego funkcję JavaScript. Link używamy, gdy dokądś prowadzi i następuje zmiana kontekstu. W celu wywołania funkcji (jakiegoś działania) standard HTML przewiduje użycie np. <button type=”button”>.

Równie często w roli elementów aktywnych używane bywa <i> – prawdopodobnie dlatego, że jest krótkie, a twórcy kodu nie chce się dużo pisać. Ten element ma swoje konkretne znaczenie w specyfikacji  i używanie go jako uniwersalnego kontenera treści czy elementu klikalnego, jest BŁĘDNE. Zwłaszcza że zazwyczaj towarzyszy temu całkowita niedostępność z klawiatury.

Jeżeli już koniecznie trzeba używać elementu innego, niż przewidziany w specyfikacji, konieczne jest całkowite odtworzenie jego zachowania przy pomocy JavaScriptu i opatrzenie go niezbędnymi atrybutami ARIA. Jeśli tylko się da, należy tego unikać. ZAWSZE lepiej użyć właściwego znacznika HTML.

Zamiast komplikować:

<i tabindex="0" role="link" onclick="goToLink(event, 'https://www.w3.org/')" onkeydown="goToLink(event, 'https://www.w3.org/')">Serwis W3C </i> plus dodatkowo kilkadziesiąt linijek CSS i JavaScript kontrolujących wygląd i działanie tego “linku”.

lepiej użyć zawsze poprawnie działającego: <a href="'https://www.w3.org/">Serwis W3C</a>

Często błędy są spowodowane próbami dostosowania wyglądu elementów formularza do pożądanej szaty graficznej. Wiele natywnych elementów HTML ma ograniczoną możliwość zmiany wyglądu. Programiści stosują wówczas sztuczki z zastępowaniem ich innymi znacznikami i nadawaniem im dowolnego wyglądu. Często ich obsługa jest ograniczona tylko do myszy, a dostępność wcale nie jest brana pod uwagę. Podmiana elementów <input><select> itp. wymaga bardzo dużej uwagi.

Serwis posiada slajdery bez możliwości sterowania przy użyciu klawiatury (problem). – Procent wystąpień: 12,5%

Dotyczy kryteriów sukcesu WCAG:

Kto może poprawić: Administrator strony, Web developer

Opis / zalecane rozwiązanie: Należy zadbać, aby każdy element funkcji sterujących działaniem strony otrzymał focus klawiatury i że kolejność tabindex jest logiczna. Pokazy slajdów/ karuzele są potencjalnym źródłem problemów, bo treść w nich zawarta może się dynamicznie zmieniać. Niezbędne jest zapewnienie dobrze widocznych i czytelnie opisanych przycisków sterowania i zatrzymania pokazu slajdów. To zapewni osobom z problemami wzroku i funkcji poznawczych możliwość odczytania zawartości slajdów bądź wyłączenia rozpraszającej ich zmiany. Często pokazy slajdów mają funkcjonalność zatrzymania po najechaniu myszą – to jest niewystarczające, trzeba zapewnić taką samą funkcjonalność przy użyciu klawiatury.

Najlepszą opcją poprawy pod względem User Experience i dostępności jest… zastąpienie sliderów i karuzel innym elementem. Są nieefektywne, bardzo wiele osób ma tzw. “slider blindness” , mało użytkowników w ogóle je czyta, denerwują część odwiedzających. Stale zmieniająca się treść (lub część treści ukryta) powoduje poważne problemy z dostępnością. Jednocześnie istnieje mało poprawnie napisanych rowiązań. Proponujemy zastąpienie sliderów statycznymi formami typu “hero image”. W niektórych przypadkach sensowne może być utworzenie osobnej podstrony np. z rodzajem galerii pracowników zamiast karuzeli z ich zdjęciami i informacjami.

Serwis posiada akapity z justowaniem (problem). – Procent wystąpień: 12,2%

Dotyczy kryteriów sukcesu WCAG:

Opis / zalecane rozwiązanie: Ważne jest zapewnienie poprawnego odczytu osobom słabo widzącym lub z zaburzeniami funkcji poznawczych. Poprawna implementacja polega na takim formatowaniu tekstów, by po ręcznej zmianie po stronie użytkownika, nadal były one czytelne i widoczne. Teksty po powiększeniu odstępów nie powinny ukrywać się pod ramkami o sztywno określonych rozmiarach ani nachodzić na siebie. Unikamy justowania tekstów, bo po powiększeniu czcionek mogą się tworzyć pomiędzy wyrazami duże odstępy, utrudniające czytanie.

Serwis posiada odnośniki wyróżnione tylko kolorem, które nie spełniają wymogów kontrastu (błąd). – Procent wystąpień: 12,2%

Dotyczy kryteriów sukcesu WCAG:

Kto może poprawić: Administrator serwisu,  Web developer

Opis / zalecane rozwiązanie: Prawidłowa widoczność odnośników jest szczególnie ważna dla osób z zaburzeniami widzenia. Przeczytaj zalecenia kontrastu podane powyżej. Dodatkowe wyróżnienie odnośników ma znacznie dla osób z zaburzeniem widzenia kolorów. Przeczytaj zalecenia wyróżniania elementów aktywnych powyżej.

Widoczność fokusa klawiatury

  • Serwis ukrywa widoczność fokusa klawiatury (błąd). – Procent wystąpień: 12,2%
  • Serwis może ukrywać widoczność fokusa klawiatury (problem). – Procent wystąpień: 11,9%

Dotyczy kryteriów sukcesu WCAG: 2.4.7 Widoczny fokus

Kto może poprawić: Administrator serwisu, Web developer

Opis / zalecane rozwiązanie: Wszelkie elementy aktywne i klikalne na stronie, które przechwytują focus klawiatury (są dostępne przez nawigację klawiszem Tab), muszą być wyróżniane graficznie. Uzyskujemy to przez stylowanie CSS dla pseudoklasy “focus-visible”. Może to być ramka, cień, inwersja kolorów lub inna metoda pozwalająca wyraźnie i jednoznacznie określić, który element jest aktywny. Zmiana musi dotyczyć więcej niż tylko samego koloru tekstu (musi być rozpoznawalna przez użytkowników ze ślepotą barw).

Przeglądarki zwykle dodają własny wskaźnik fokusu, ale tylko, jeśli w kodzie stronty nie zostanie on określony. Twórcy stron bardzo często wyłączają tę funkcję, bo kiedyś była w przeglądarkach dla pseudoklasy “focus” (ramka pokazywała się po kliknięciu myszką i uzyskaniu fokusu klawiatury) i nie wyglądało to dobrze. Jednocześnie nie zapewniano indykatorów fokusu dla klawiatury. Współczesne przeglądarki dodają obrys tylko przy nawigacji klawiaturą (focus-visible), ale ze względu na opisane przyzwyczajenie developerów nie można liczyć na jego poprawne wyświetlanie.

Proponujemy dodać następujący kod CSS do strony (w WordPress można to łatwo zrobić w funkcji “Dostosuj > Własny CSS”):

body a:focus-visible {
   outline: solid 2px blue; */zastąp kolor w zależności od potrzeb/*
   outline-offset: 2px;
}

Responsywność serwisu

  • W trybie mobilnym część informacji może być niewidoczna (błąd). – Procent wystąpień: 10,7%
  • Serwis nie umożliwia dynamicznego dopasowywania zawartości do wielkości ekranu (błąd). – 8,9%

Dotyczy kryteriów sukcesu WCAG: 1.4.10 Dopasowanie do ekranu

Kto może poprawić: Web developer

Opis / zalecane rozwiązanie: Treść po powiększeniu w przeglądarce (np. funkcją Ctrl + kółko myszki) powinna mieścić się w zmaksymalizowanym oknie bez konieczności poziomego przewijania ekranu. Jednocześnie elementy powinny płynnie zmieniać swoje położenie i nie nachodzić na siebie (nie zasłaniać jedne drugich).

Osoby z dysfunkcjami wzroku muszą mieć możliwość powiększenia czcionek. Należy zadbać, aby kontenery (ramki, obszary) zawierające tekst nie miały sztywno ustawionych rozmiarów i aby ich wielkość zmieniała się wraz z ich zawartością. Sztywne rozmiary powodują, że część treści przesuwa się poza ekran, lub ukrywa pod innymi elementami strony. Dotyczy to również obrazów, które powinny poprawnie się skalować, niezależnie od wielkości ekranu. Do określania rozmiarów czcionek, odstępów i innych elementów używamy jednostek relatywnych (em, rem). Dzięki temu powiększane czcionki nie będą nachodzić na siebie, a kontenery je zawierające będą dostosowywać swoją wielkość do czcionek. Dostosowanie CSS przy pomocy tzw. media queries pozwala uzyskać poprawny wygląd strony na różnych wielkościach ekranów i na urządzeniach mobilnych.

Formularze w witrynie

  • W serwisie występują formularze z problemami dot. właściwej sygnalizacji błędnego wypełnienia danych (błąd)– Procent wystąpień: 10,7%
  • Pole wyszukiwania nie posiada etykiety lub została ona błędnie powiązana (błąd) – Procent wystąpień: 9,9%
  • Pola formularza nie posiadają etykiet lub etykiety zostały błędnie powiązane z polami (błąd) – Procent wystąpień: 8,9%
  • Serwis posiada pola formularza bez etykiet lub tekstu alternatywnego (błąd) – Procent wystąpień: 7,8%
  • W serwisie występują przyciski bez etykiety tekstowej (błąd)– Procent wystąpień: 6%

Dotyczy kryteriów sukcesu WCAG:

Kto może poprawić: Administrator serwisu, formularze wbudowane – Web developer

Opis / zalecane rozwiązanie: Te błędy należą do najbardziej poważnych. Poprawność przesyłania informacji nie może być zakłócona lub przekłamana.

Informowanie o poprawności wprowadzonych danych jest kluczowe dla osób korzystających z technologii wspomagających. Pola, które są wymagane można np.: oznaczyć tekstem (wymagane) w znaczniku <label>. Można też w znaczniku input umieścić atrybut: aria-required="true". Koniecznie należy zadbać, aby poinformować użytkownika o sukcesie, lub niepowodzeniu wysłania danych. Techniki używane w tym celu opisano na stronie przykładami przygotowanymi przez WAI

Etykiety formularza informują technologie wspomagające o funkcji i działaniu danego elementu formularza. Poprawne działanie uzyskujemy, stosując zalecane elementy HTML. <label> dla opisania funkcji elementów <input> oraz <fieldset> i <legend> do grupowania i informowania o celu całego formularza. Teksty etykiet powinny być możliwie krótkie, ale dokładnie opisujące przeznaczenie elementu, do którego się odnoszą. Należy zadbać, aby cel, na który wskazuje atrybut “for” miał prawidłową wartość atrybutu “id” elementu formularza.

Serwis nie zawiera kontaktu do administratora strony (błąd). – Procent wystąpień: 8,3%

Dotyczy kryteriów sukcesu WCAG: wymagane w Ustawie o dostępności cyfrowej.

Kto może poprawić:  Administrator serwisu

Opis / zalecane rozwiązanie: Zgodnie z ustawą należy zamieścić kontakt do osoby odpowiedzialnej za administrowanie stroną internetową. W ten sposób użytkownicy zyskują możliwość zgłaszania uwag lub błędów związanych z dostępnością.

Język serwisu

  • Link do przeskoczenia do treści strony posiada komunikat w języku angielskim (błąd) – Procent wystąpień: 13,4%
  • Serwis zawiera znacznik języka niezgodnego z językiem treści (błąd). – Procent wystąpień: 7,1%
  • Na stronach serwisu nie określono znacznika języka (błąd). – Procent wystąpień: 6,8%
  • Serwis posiada treści w języku innym niż podstawowy język strony i nieoznaczone znacznikiem języka (błąd). – Procent wystąpień: 4,8%

Dotyczy kryteriów sukcesu WCAG:

Kto może poprawić: w treści (część tekstu) – Redaktor treści, różne wersje językowe serwisu – Administrator serwisu lub Web developer

Opis / zalecane rozwiązanie: Wartość atrybutu określającego język strony <html lang=…> musi być zgodna z tabelą określającą standard — wartość atrybutu “lang” jest wykorzystywana przez Google do tworzenia wyników wyszukiwania i przez czytniki ekranowe do wyboru języka i wymowy tekstu.

Programy do odczytu ekranu włączają automatycznie wymowę zgodną z językiem określonym w serwisie. Niezgodność tego atrybutu z treścią może spowodować, że stanie się ona całkowicie niezrozumiała.