Dobre praktyki WCAG - ogólne (low-code)

WCAG - zakładka Audyt

WCAG - Audyt

WCAG - Strona zawiera formularz

WCAG - strona jako formularz

Zakładka Audyt

W przypadku modyfikacji istniejących aplikacji należy zwrócić uwagę na zakładkę Audyt. (Niestety, na ten moment sprawdzany jest tylko xml - głównie etykiety. Nie są tam wychwytywane błędy w TextContent, dlatego sprawdzając lub modyfikując wniosek pod kątem WCAG, nie należy opierać się wyłącznie na zakładce Audyt).

Ilustracja 1. Przykładowa lista naruszeń WCAG

Ilustracja 2. Przykład wniosek bez uwag w zakładce Audyt

HTML - Treści (TextContents) i komponenty niestandardowe (CustomComponents)

Przy tworzeniu i modyfikowaniu TextContent'ów warto sprawdzić HTML przy użyciu walidatora: Markup Validation Service (HTML) – https://validator.w3.org/ (dodatkowe informacje )

Ilustracja 3. Przykład użycia walidatora markup

Należy zwrócić uwagę na linki (target), obrazki (alt), listy i nagłówki (z zachowaniem właściwej hierarchi).

AriaLabel i ariaDescription

• ariaLabel – Wartość właściwości etykiety komponentu.

• ariaDescription – Wartość właściwości opisu komponentu. Jest to tekst słownie opisujący komponent, odczytywany przez czytniki ekranowe. Najczęściej stanowi rozszerzony opis pola (np. zawiera maskę pola, treść tooltipa nieczytanego przez czytnik ekranowy, walidatora).

• Domyślnie ariaLabel są puste, należy je dodać zgodnie z przykładem. (patrz Pole tekstowe (TextField) i Pole wielokrotnego wyboru (Checkbox) w tabeli poniżej)

• ariaLabel należy dodać , jeżeli komponent nie ma powiązania z etykietą.

• Atrybut ariaLabel powinien być stosowany w interaktywnych elementach strony.

Ilustracja 4. Dodatkowe zasady dotyczące użycia ARIA

Dodatkowe informacje: Using ARIA

Weryfikacja ariaLabel i ariaDescription

Sposoby weryfikacji ariaLabel i ariaDescription:

• przy użyciu czytnika ekranu – można sprawdzić, jak atrybuty są odczytywane użytkownikowi. (Linki do przykładowych czytników znajdują się na końcu dokumentacji)

• przy użyciu narzędzi developerskich – DevTools – atrybuty ariaLabel i ariaDescription można sprawdzić bezpośrednio w strukturze DOM, w zakładce Elements.

• przy użyciu wtyczki do przeglądarki np. WAVE Evaluation Tool

Ilustracja 5. Podgląd atrybutów ariaLabel i ariaDescription w DevTools

Nagłówki

• <h1> Eximee Designer domyślnie będzie miało ustawione <h1> jako tytuł wniosku. Mimo że, używanie kilku nagłówków <h1> jest dozwolone przez standardy HTML (o ile nie są zagnieżdżone), nie jest to uważane za dobrą praktykę. Zasadniczo na stronie powinien znajdować się jeden nagłówek <h1>, który opisuje główną treść strony. W przypadku dodawania nagłówków na wniosku najlepiej zacząć od poziomu <h2>.

• Nagłówki sekcji - każda dodana sekcja na wniosku może posiadać własny nagłówek. Sekcja w sekcji będzie miała kolejny poziom nagłówka (aria-level) – dotyczy to również sekcji powtarzalnej.

Ilustracja 6. Definiowanie nagłówków w Eximee Designer

• Dodatkowe informacje: <h1>–<h6>: The HTML Section Heading elements

Reużywalność komponentów złożonych (dynamiczne nazwy)

Jeśli dany komponent złożony jest używany wielokrotnie – np. w szablonie wniosku lub jako element innego komponentu złożonego - można dla jego pól ustalić różne wartości ariaLabel i ariaDescription, zależne od kontekstu użycia.

Przykładowo: pole "Imię" może mieć inny opis w przypadku wnioskodawcy, a inny dla współwnioskodawcy.

Aby to osiągnąć, należy w artefakcie zawierającym re-użyty komponent złożony :

• Przejść do zakładki Tłumaczenia.

• Dla każdego pola osobno dodać odpowiednie klucze tłumaczeń ariaLabel i/lub ariaDescription. Uwaga: Klucz musi być pełną ścieżką do pola.

Przykład: Pole Ulica (GesTextField1), znajdujące się w komponencie złożonym, zostało użyte dwa razy w wniosku – z nadanymi id GesComplexComponent2 i GesComplexComponent3. Dla każdego wystąpienia można przypisać inne ariaLabel, np.:

• GesComplexComponent2.GesTextField1.ariaLabel : "Ulica zamieszkania"

• GesComplexComponent3.GesTextField1.ariaLabel : "Ulica korespondencji"

Ilustracja 7. Definiowanie ariaLabel dla komponentów złożonych

Sposób weryfikacji

Po wejściu na pole czytnik powinien przeczytać właściwe ariaLabel, czyli "ulica zamieszkania" i "ulica korespondencji"

Strona jako formularz

Jeśli parametr jest zaznaczony, strona wniosku ma nadaną rolę form. Domyślnie ten parametr jest włączony.

Ilustracja 8. Funkcjonalność "Strona jako formularz"

Wymagalność/ opcjonalność pól

Pola wymagane do wypełnienia powinny być oznaczone – należy dodać informację o ich wymagalności w warstwie wizualnej np. poprzez dopisek "*pole wymagane" lub symbol "*". Powinny także odróżniać się wizualnie od pól niewymaganych, aby użytkownik mógł łatwo je zidentyfikować.

Tytuł strony

Tytuł strony powinien jasno identyfikować bieżącą lokalizację, bez konieczności czytania zawartości strony.

Tekst jako obrazek

Nie należy zamieszczać tekstu w formie obrazu (wyjątek stanowi logo). (dodatkowe informacje )

Zmiana rozmiaru tekstu (niestandardowy styl)

• Po zwiększeniu rozmiaru tekstu o 200% nie może dojść do utraty czytelności ani funkcjonalności interfejsu. (dodatkowe informacje )

• Tekst powinien spełniać minimalne wymagania dotyczące odstępów, aby zapewnić jego czytelność:

  • wysokość linii: co najmniej 1,5-krotność rozmiaru czcionki

  • odstęp między akapitami: co najmniej 2-krotność rozmiaru czcionki

  • odstęp między literami: co najmniej 0,12-krotność rozmiaru czcionki

  • odstęp między wyrazami: co najmniej 0,16-krotność rozmiaru czcionki

• Wszystkie elementy musza pozostać czytelne i widoczne po zastosowaniu powyższych parametrów.

Znaki specjalne w treści

Jeśli w treści używane są znaki specjalne, np. strzałki pełniące funkcję dekoracyjną, należy je ukryć przed czytnikami ekranu za pomocą atrybutu aria-hidden. Przykład: <span aria-hidden="true">→</span> Przejdź dalej

Responsywność

Treść musi być prezentowana bez utraty informacji ani funkcjonalności na ekranach o minimalnej szerokości 320 px i wysokości 256 px. Dodatkowo nie może występować przewijanie w poziomie, z wyjątkiem dwuwymiarowych treści, takich jak: tabele, złożone obrazy, mapy oraz wykresy.

Wysoki kontrast

Wszystkie elementy powinny być widoczne i czytelne po włączeniu trybu wysokiego kontrastu. Rozszerzenie do Chrome: https://chromewebstore.google.com/detail/wysoki-kontrast/djcfdncoelnlbldjfhinnjlhdjlikmph?hl=pl

Nawigacja

Elementy nawigacji na podstronach powinny znajdować się w tym samym miejscu, zachowując spójny układ na wszystkich stronach.

CSS - Ukrycie tekstu z wizualnego przekazu + ignorowanie tekstu przez czytniki

Ilustracja 9. Przykład ukrycia elementów układu przy użyciu CSS

Dodatkowe informacje: CSS - Invisible Content Just for Screen Reader Users

display:none or visibility: hidden → ukrycie tekstu przed wszystkimi

Podsumowanie

Formularz powinien zawierać stronę z podsumowaniem danych – tzw. stronę potwierdzenia – umożliwiającą użytkownikowi ich weryfikację, cofnięcie się do wcześniejszych kroków w celu dokonania poprawek oraz ostateczne potwierdzenie poprawności danych.