Dobre praktyki WCAG - komponenty (low-code)

Etykieta (Text)

Dobre praktyki

  • Nagłówki oraz etykiety powinny być jednoznaczne i niezduplikowane – użytkownik powinien móc z łatwością rozpoznać, do czego odnosi się dany opis.

  • Etykiety bez powiązania z polem powinny być ustawiane jako paragraf, z użyciem opcji „Wyświetl jako paragraf (<p>)”.

Ilustracja 1. Opcja "Wyświetl jako paragraf <p>

Powiązanie etykiety z polem :

  • Jeśli etykieta dotyczy jednego komponentu – należy wybrać ten komponent z listy w polu labelRef. Przykład: jeśli etykietą Text7 ma być opis dla pola TextField2, to w konfiguracji WCAG etykiety Text7 należy wskazać komponent TextField2 jako powiązany.

Ilustracja 2. Powiązanie pola tekstowego GesTextField1 z etykietą

  • Jeśli etykieta dotyczy wielu komponentów – należy wybrać komponent pierwszy lub najważniejszy w kontekście grupy. Przykład: jeśli kod pocztowy składa się z dwóch pól typu TextField, należy powiązać etykietę z pierwszym z nich.

Spójność etykiet:

  • Te same elementy na różnych stronach powinny mieć identyczne etykiety, aby zachować spójność nawigacji i treści z punktu widzenia użytkownika, w tym osób korzystających z czytników ekranu.

Sposób weryfikacji

sprawdzenie ariaLabel oraz ariaDescription (jeśli zostało uzupełnione)

Pole tekstowe (TextField)

Dobre praktyki

Uzupełnianie etykiety i atrybutów dostępności (ariaLabel, ariaDescription):

  • Każde pole powinno mieć przypisaną etykietę lub ariaLabel (w przypadku braku etykiety wizualnej).

  • Domyślnie, po dodaniu komponentu TextField, właściwości ariaLabel i ariaDescription są puste – należy je uzupełnić ręcznie. Przykład: zamiast GesTextField1.ariaLabelKey należy użyć GesTextField1.label, co automatycznie przypisze wartość etykiety do ariaLabel.

Ilustracja 3. Przykład uzupełnienia ariaLabelKey

Dobre praktyki przy opisie pól:

Wymagalność pola

  • Komunikat "pole wymagane" może być zbyt ogólny. Zaleca się stosowanie konkretnych komunikatów, np. "Pole imię jest wymagane".

Walidacja formatu

  • Jeśli pole posiada walidację formatu (np. PESEL, NIP), należy dodać do ariaDescription opis wymagań, np.: "Wymagane 11 cyfr bez spacji ani znaków specjalnych."

Maska

  • Jeśli pole posiada maskę → opisać w ariaDescription, np. jakie znaki są dozwolone/niedozwolone.

  • Jeśli pole posiada visibleMask → opisać np.: "Dla kodu pocztowego wpisz tylko cyfry, bez myślnika."

Maksymalna długość

  • Jeśli pole ma ustawioną wartość maxLength → dodać do ariaDescription informację o ograniczeniu, np.: "Do 30 znaków."

Suggester

  • Jeśli pole zawiera suggester (podpowiedzi dynamiczne) → opisać jego działanie, np.: "Wartość może zostać zmieniona automatycznie przy wpisaniu niepoprawnej liczby."

Walidator

  • Gdy komunikat błędu walidatora jest niejednoznaczny, należy w ariaDescription zawrzeć jego sensowny opis, np.: "Pole nie może zawierać znaków specjalnych."

Formater

  • Jeśli pole zawiera formater → opisać sposób działania, np.: "Tekst zostanie automatycznie przekształcony na wielkie litery."

Ograniczenia dotyczące wklejania

  • Jeśli pole nie pozwala na wklejanie tekstu → należy to opisać w ariaDescription, np.: "Pole nie obsługuje wklejania danych."

Prefiks / sufiks

  • Jeżeli pole zawiera prefiks lub sufiks (np. „+48”, „PLN”) → dodać do ariaDescription, np.: "Pole poprzedzone kodem kraju +48."

Sposób weryfikacji

sprawdzenie ariaLabel oraz ariaDescription (jeśli zostało uzupełnione)

Pomoc kontekstowa (Tooltip)

Dobre praktyki

Jeśli tooltip posiada warunki widoczności, należy upewnić się, że są one zgodne z warunkami komponentu, do którego tooltip został przypisany.

Pole wielokrotnego wyboru (Checkbox) i Sekcja z checkboxem (CheckboxSection)

Dobre praktyki

Uzupełnianie ariaLabel i ariaDescription dla komponentu Checkbox i CheckboxSection:

  • Domyślnie, po dodaniu komponentu Checkbox, pola ariaLabel i ariaDescription są puste. Wartość ariaLabel należy uzupełnić ręcznie – zazwyczaj wystarczy przypisać jej wartość z pola text.

    Przykład: Zastąpić: GesCheckbox11.ariaLabel → GesCheckbox11.text (w efekcie: ariaLabel = text)

Ilustracja 4. Przykład uzupełnienia ariaLabel

  • Atrybut ariaDescription nie zawsze jest wymagany, ale warto go dodać w przypadku bardziej złożonego kontekstu, np. gdy checkbox wymaga dodatkowego objaśnienia.

Checkbox z treścią formatowaną (TextContent):

  • W przypadku, gdy checkbox jest zasilany treścią formatowaną z komponentu TextContent, należy pamiętać, że czytniki ekranowe nie odczytują TextContent. Dlatego treść tekstu należy również przypisać do ariaLabel, aby zapewnić jej dostępność.

Ilustracja 5. Przykład uzupełnienia ariaLabel dla checkboxa zasilanego treścią

Sposób weryfikacji

sprawdzenie ariaLabel oraz ariaDescription (jeśli zostało uzupełnione)

Pole daty (DatePicker)

Dobre praktyki

Uzupełnianie ariaLabel i ariaDescription dla komponentu DatePicker:

  • Każde pole powinno mieć przypisaną etykietę lub ariaLabel (jeśli brak etykiety wizualnej).

  • Domyślnie, po dodaniu komponentu DatePicker, właściwości ariaLabel i ariaDescription są puste. Należy je uzupełnić ręcznie lub przypisać ariaLabel do klucza etykiety komponentu.

    Przykład: Zamiast GesDatePicker1.ariaLabelKey → użyć GesDatePicker1.label (w efekcie: ariaLabel = label)

Dobre praktyki uzupełniania ariaDescription dla pól daty:

  • Jeśli pole posiada ograniczenia wyboru dat (dateRange) → należy dodać opis do ariaDescription, np.: „Wybierz datę z zakresu od 01.01.2020 do 31.12.2030.”

  • Jeśli pole ma ustawiony niestandardowy format (dateFormat) → należy opisać go w ariaDescription, np.: „Data w formacie: miesiąc–rok (MM-RRRR).”

  • Jeśli włączona jest maska (autoMask) → warto dodać informację, jak działa automatyczne uzupełnianie, np.: „Wpisuj tylko cyfry – separator zostanie dodany automatycznie.”

Sposób weryfikacji

sprawdzenie ariaLabel oraz ariaDescription (jednoznaczna informacja o formacie danych)sprawdzenie ariaLabel oraz ariaDescription (jeśli zostało uzupełnione)

Obraz (Image)

Dobre praktyki

Tekst alternatywny (imageAlt) dla obrazów

  • Każdy obrazek powinien mieć uzupełniony tekst alternatywny (imageAlt lub imageAltKey w pliku formularza).

Ilustracja 6. Przykładowy imageAltKey w źródle formularza

  • Rekomendacje:

    • Maksymalna długość tekstu: 80 znaków

    • Zachowuj spójność stylu i języka opisu z resztą interfejsu

  • Pusty atrybut alt (alt="") powinien być stosowany tylko wtedy, gdy obraz pełni funkcję dekoracyjną, np.:

    • tło

    • linia rozdzielająca treść

    • ozdobna ikona bez funkcji informacyjnej

  • Prezentacja Informacyja/Dekoracyjna - W sekcji WCAG można ustawić prezentację informacyjną (obrazek będzie można sfokusować) lub dekoracyjną (nie można go sfokusować i posiada pusty atrybut imageAlt).

  • Obrazek jako link Jeśli obrazek jest zawarty w linku, alt powinien zawierać zarówno opis graficzny, jak i informację o funkcji, np.: <a href="https://www.bank.com"> <img src="logo-bank.png" alt="Logo Banku XYZ – Przejdź na stronę główną Banku XYZ"> </a>

  • Elementy SVG Dla grafik SVG można dodać atrybut ariaLabel i ariaDescription

(informacje) Więcej: Dodatkowe informacje

Sposób weryfikacji

sprawdzenie wartości alt na wniosku

Pole wyboru wartości z listy (Combobox)

Dobre praktyki

Uzupełnianie ariaLabel i ariaDescription dla komponentu Combobox:

  • Każdy komponent ComboBox powinien mieć przypisaną etykietę lub ariaLabel (w przypadku braku etykiety wizualnej).

  • Domyślnie, po dodaniu ComboBoxa, pola ariaLabel i ariaDescription są puste – należy je uzupełnić ręcznie lub przypisać ariaLabel do klucza etykiety.

    Przykład: GesCombobox1.ariaLabelKey → GesCombobox1.label (w efekcie: ariaLabel = label)

Alternatywny tekst dla wartości domyślnej „Wybierz”:

  • W zakładce „Pozostałe” (w konfiguracji ComboBoxa) można zdefiniować alternatywny tekst dla domyślnej wartości „Wybierz”, co poprawia dostępność i zrozumiałość dla użytkowników korzystających z czytników ekranowych.

Ilustracja 7. Alternatywny tekst dla "Wybierz"

Sposób weryfikacji

sprawdzenie ariaLabel i ariaDescription

Radio grupa (RadioGroup)/ Grupa Kafli (TileGroup)

Dobre praktyki

Etykieta i atrybuty dostępności:

  • Każdy komponent powinien posiadać etykietę (label) lub ariaLabel (jeśli etykieta wizualna nie jest dostępna).

  • Domyślnie, po dodaniu komponentu (ComboBox, RadioGroup, TileGroup), pola ariaLabel i ariaDescription są puste — należy je uzupełnić ręcznie lub przypisać ariaLabel do klucza etykiety.

RadioGroup:

  • Każda opcja (Radio) powinna mieć unikalną wartość (value), aby uniknąć konfliktów w działaniu formularza oraz błędów czytników ekranu.

  • RadioGroup może mieć:

    • jeden wspólny tooltip (dla całej grupy),

    • lub oddzielne tooltipy dla każdej opcji, jeśli każda wymaga dodatkowego opisu.

TileGroup:

  • Jeżeli w treści kafelka (Tile) został dodany obrazek, należy:

    • dodać opis alternatywny (alt), który jasno informuje o zawartości obrazka,

    • ustawić alt="" w przypadku grafik dekoracyjnych, aby nie były odczytywane przez czytniki ekranu.

Sposób weryfikacji

sprawdzenie ariaLabel i ariaDescription, sprawdzenie wartości alt jeśli zostały dodane do obrazków

Sekcja powtarzalna (RepeatableSection)

Dobre praktyki

  • Sekcja powinna mieć tytuł (label) lub ariaLabel – zapewnia to, że czytnik ekranu prawidłowo zidentyfikuje jej zawartość i kontekst.

  • W atrybucie ariaDescription należy umieścić informację o minimalnej i maksymalnej liczbie możliwych wystąpień sekcji.

Sposób weryfikacji

sprawdzenie ariaDescription

Slider/Step slider

Dobre praktyki

  • Domyślnie, po dodaniu komponentu Slider, właściwości ariaLabel i ariaDescription są puste. Należy je uzupełnić ręcznie — szczególnie ariaLabel, jeśli komponent nie posiada widocznej etykiety.

  • W atrybucie ariaDescription warto umieścić informację o zakresie wartości możliwych do wyboru

Sposób weryfikacji

sprawdzenie ariaDescription

Plus Minus

Dobre praktyki

  • Domyślnie, po dodaniu komponentu typu Plus-Minus, atrybuty ariaLabel i ariaDescription są puste. Należy je uzupełnić ręcznie — szczególnie ariaLabel, jeśli komponent nie posiada widocznej etykiety.

  • W atrybucie ariaDescription warto dodać informację o minimalnej i maksymalnej możliwej wartości, aby użytkownicy czytników ekranowych mieli jasność co do dostępnego zakresu.

Sposób weryfikacji

sprawdzenie ariaDescription

Treść formatowana zwijana (RollableTextContent)

Dobre praktyki

  • Należy upewnić się, że komponent posiada tytuł (etykietę) oraz ariaLabel.

  • ariaLabel powinno jednoznacznie opisywać zawartość komponentu, aby czytniki ekranowe mogły prawidłowo przekazać użytkownikowi informację o treści.

Sposób weryfikacji

sprawdzenie wartości title

Wybór produktu (ProductSelector)

Dobre praktyki

  • Domyślnie, po dodaniu komponentu ProductSelector, pola ariaLabel i ariaDescription są puste. Należy je uzupełnić ręcznie — szczególnie ariaLabel, jeśli komponent nie posiada widocznej etykiety.

  • Obrazki wykorzystywane w komponencie ProductSelector powinny mieć uzupełnione wartości alt — zgodne z zasadami dostępności, aby czytniki ekranowe mogły poprawnie opisać grafikę.

  • Treść HTML wykorzystywana w komponencie (ContentHTML) powinna być zweryfikowana przy pomocy narzędzia do walidacji HTML (np. Markup Validation Service) w celu eliminacji błędów i poprawy dostępności.

Sposób weryfikacji

sprawdzenie wartości alt i kodu HTML

Link wewnętrzny (PageNavigationLink) i zewnętrzny (Link)

Dobre praktyki

  • Domyślnie, po dodaniu linku pola ariaLabel i ariaDescription są puste. Należy je uzupełnić ręcznie — szczególnie ariaLabel, jeśli komponent nie posiada widocznej etykiety.

  • Nie należy stosować wyłącznie wielkich liter (caps lock) w tekstach linków, aby nie utrudniać ich czytania i rozpoznawania przez użytkowników oraz czytniki ekranowe.

  • Użytkownik powinien być poinformowany, czy kliknięcie linku spowoduje otwarcie nowej karty lub uruchomienie innej aplikacji. Można to osiągnąć poprzez:

    • ustawienie właściwości otwierania linku, np. target="_blank",

    • dodanie tekstu informującego np. w tytule (title) lub w ariaDescription.

    • czytelne oznaczenie graficzne lub tekstowe.

  • We właściwościach linku można ustawić m.in.:

    • sposób otwierania (target, np. _blank),

    • tekst wyświetlany po najechaniu kursorem (atrybut title),

    • nazwę kotwicy (fragmentu strony).

Ilustracja 8. Właściwości komponentu link

Sposób weryfikacji

sprawdzenie ariaLabel i ariaDescription

Oświadczenia (Statements)

Dobre praktyki

W zakładce Właściwości można zmienić następujące właściwości nadpisujące teksty wyświetlane w interfejsie:

  • Właściwość nadpisująca: "Zwiń treść oświadczeń"

  • Właściwość nadpisująca: "Rozwiń treść oświadczeń"

  • Właściwość nadpisująca treść: "Nie wyraziłeś zgody na wymagane oświadczenia"

  • Właściwość nadpisująca treść: "Nie dokonałeś wyboru przy wszystkich oświadczeniach, uzupełnij wymagane informacje w sekcji oświadczenia"

  • Właściwość nadpisująca treść: "Akceptuję wybrane oświadczenia"

  • Właściwość nadpisująca treść: "Akceptuję wszystkie oświadczenia"

Ilustracja 9. Właściwości komponentu oświadczenia

Załączniki (UploadFile)

Dobre praktyki

  • Domyślnie, po dodaniu UploadFile pola ariaLabel i ariaDescription są puste. Należy je uzupełnić ręcznie — szczególnie ariaLabel, jeśli komponent nie posiada widocznej etykiety.

  • W atrybutach

    • Domyślnie, po dodaniu linku pola ariaLabel i ariaDescription są puste. Należy je uzupełnić ręcznie — szczególnie ariaLabel, jeśli komponent nie posiada widocznej etykiety.

    lub ariaDescription powinny znaleźć się informacje dotyczące:

    • wymagalności załączników,

    • ilości możliwych do dodania plików.

Sposób weryfikacji

sprawdzenie ariaLabel

Mapa (MapView)

Dobre praktyki

  • Domyślnie, po dodaniu MapView pola ariaLabel i ariaDescription są puste. Należy je uzupełnić ręcznie — szczególnie ariaLabel, jeśli komponent nie posiada widocznej etykiety.

  • W atrybucie ariaLabel lub ariaDescription warto umieścić informacje istotne dla użytkownika, np.:

    • opis celu mapy,

    • wskazówki dotyczące obsługi (np. czy można wybrać lokalizację),

    • inne istotne informacje dostępnościowe.

Sposób weryfikacji

sprawdzenie ariaLabel

Potwierdzenie danych (ConfirmationSection)

Dobre praktyki

  • Domyślnie, po dodaniu confirmation section pola ariaLabel i ariaDescription są puste. Należy je uzupełnić ręcznie — szczególnie ariaLabel, jeśli komponent nie posiada widocznej etykiety.

  • W atrybucie ariaLabel lub ariaDescription warto umieścić dodatkowe informacje pomocne w kontekście potwierdzania danych, np.:

    • instrukcje dotyczące potwierdzenia,

    • informację o konieczności sprawdzenia danych przed zatwierdzeniem.

Generator kodów QR (QRCodeGenerator)

Dobre praktyki

Domyślnie, po dodaniu QRCodeGenerator pola ariaLabel i ariaDescription są puste. Należy je uzupełnić ręcznie — szczególnie ariaLabel, jeśli komponent nie posiada widocznej etykiety.

Sposób weryfikacji

sprawdzenie ariaLabel

Skaner kodów QR (QRCodeScanner)

Dobre praktyki

Domyślnie, po dodaniu QRCodeScanner pola ariaLabel i ariaDescription są puste. Należy je uzupełnić ręcznie — szczególnie ariaLabel, jeśli komponent nie posiada widocznej etykiety.

Sposób weryfikacji

sprawdzenie ariaLabel

Skaner kodów AZTEC (AztecCodeScanner)

Dobre praktyki

Domyślnie, po dodaniu AztecCodeScanner pola ariaLabel i ariaDescription są puste. Należy je uzupełnić ręcznie — szczególnie ariaLabel, jeśli komponent nie posiada widocznej etykiety.

Sposób weryfikacji

sprawdzenie ariaLabel

Przydatne strony

Czytniki ekranu

PreviousDobre praktyki WCAG - ogólne (low-code)NextDobre praktyki WCAG - szablony wydruków (low-code)

Last updated

Was this helpful?