# 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>`)”.**

<figure><img src="https://1082717226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2CssJT0zIo4SJQLbSZ6l%2Fuploads%2FFOjoFg4tHDkAkkpbaadl%2Fimage.png?alt=media&#x26;token=7298174d-62f4-4f31-85e1-ff6ffc1a80d4" alt=""><figcaption><p><em><strong>Ilustracja 1.</strong> Opcja "Wyświetl jako paragraf &#x3C;p></em></p></figcaption></figure>

**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.

<figure><img src="https://1082717226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2CssJT0zIo4SJQLbSZ6l%2Fuploads%2FO97BGmZnDTHHzIi4wrnc%2Fimage2024-7-19_14-58-27.png?alt=media&#x26;token=40c02ceb-b6cc-411c-9846-e2a9511f0754" alt=""><figcaption><p><em><strong>Ilustracja 2.</strong> Powiązanie pola tekstowego GesTextField1 z etykietą</em></p></figcaption></figure>

* **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`.

<figure><img src="https://1082717226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2CssJT0zIo4SJQLbSZ6l%2Fuploads%2F6eHYbLz4XSMXfJ3OPipI%2Fimage2024-7-22_12-47-20.png?alt=media&#x26;token=a2845efa-b83f-41a1-b136-87518e4c97fc" alt="" width="470"><figcaption><p><em><strong>Ilustracja 3.</strong> Przykład uzupełnienia ariaLabelKey</em></p></figcaption></figure>

**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.:\
  \&#xNAN;*"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.:\
  \&#xNAN;*"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.:\
  \&#xNAN;*"Do 30 znaków."*

**Suggester**

* Jeśli pole zawiera **suggester** (podpowiedzi dynamiczne) → opisać jego działanie, np.:\
  \&#xNAN;*"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.:\
  \&#xNAN;*"Pole nie może zawierać znaków specjalnych."*

**Formater**

* Jeśli pole zawiera **formater** → opisać sposób działania, np.:\
  \&#xNAN;*"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.:\
  \&#xNAN;*"Pole nie obsługuje wklejania danych."*

**Prefiks / sufiks**

* Jeżeli pole zawiera **prefiks** lub **sufiks** (np. „+48”, „PLN”) → dodać do `ariaDescription`, np.:\
  \&#xNAN;*"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`\
  \&#xNAN;*(w efekcie: `ariaLabel = text`)*

<figure><img src="https://1082717226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2CssJT0zIo4SJQLbSZ6l%2Fuploads%2FqaEbgKQiOAtkk6JXTntL%2Fimage2024-7-22_14-3-12.png?alt=media&#x26;token=ee6d9c56-4822-4953-a71d-e7125816f906" alt="" width="563"><figcaption><p><em><strong>Ilustracja 4.</strong> Przykład uzupełnienia ariaLabel</em></p></figcaption></figure>

* **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`):**<br>

* **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ść.**

<figure><img src="https://1082717226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2CssJT0zIo4SJQLbSZ6l%2Fuploads%2FjWoyZuBQpRCTshyXx5RW%2Fimage.png?alt=media&#x26;token=59ea3aa4-f1f4-4126-b031-949c70c03432" alt=""><figcaption><p><em><strong>Ilustracja 5.</strong> Przykład uzupełnienia ariaLabel dla checkboxa zasilanego treścią</em></p></figcaption></figure>

### 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`\
  \&#xNAN;*(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.:\
  \&#xNAN;*„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.:\
  \&#xNAN;*„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.:\
  \&#xNAN;*„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).

<figure><img src="https://1082717226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2CssJT0zIo4SJQLbSZ6l%2Fuploads%2FplWOshnCXjlIKS1iQZpP%2Fimage2024-7-22_12-10-31.png?alt=media&#x26;token=c28e8e09-1712-410f-92c4-d48802fee625" alt=""><figcaption><p><em><strong>Ilustracja 6.</strong> Przykładowy imageAltKey w źródle formularza</em></p></figcaption></figure>

* **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](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)](https://wiki.consdata.pl/s/-rvpvnr/8703/51k4y0/_/images/icons/emoticons/information.svg) Więcej: [Dodatkowe informacje](https://cwozn.ujk.edu.pl/wp-content/uploads/2020/11/Teksty-alternatywne-do-grafik-i-fotografii-na-stronach-WWW.pdf)

### 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`\
  \&#xNAN;*(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.

<figure><img src="https://1082717226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2CssJT0zIo4SJQLbSZ6l%2Fuploads%2FtiAtG3N7NQ23JdKnjjrG%2Fimage2024-7-22_12-34-36.png?alt=media&#x26;token=26180e92-bb5f-4059-bcae-763aa47139f1" alt=""><figcaption><p><em><strong>Ilustracja 7.</strong> Alternatywny tekst dla "Wybierz"</em></p></figcaption></figure>

### 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](https://validator.w3.org/)) 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).

<figure><img src="https://1082717226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2CssJT0zIo4SJQLbSZ6l%2Fuploads%2FrYKyZiBWF6Co2goweDVM%2Fimage.png?alt=media&#x26;token=0624cf93-bb0f-4550-9fa1-130a05010f8a" alt=""><figcaption><p><em><strong>Ilustracja 8.</strong> Właściwości komponentu link</em></p></figcaption></figure>

### 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"`

<figure><img src="https://1082717226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2CssJT0zIo4SJQLbSZ6l%2Fuploads%2FBLR4asO6O6za65UokDQs%2Fimage2024-7-23_14-58-37.png?alt=media&#x26;token=7d54f82b-ce38-4a92-b477-7707a876f391" alt="" width="256"><figcaption><p><em><strong>Ilustracja 9.</strong> Właściwości komponentu oświadczenia</em></p></figcaption></figure>

## **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 <a href="#dobrepraktykiwcagdlalowcodedev-przydatnestrony" id="dobrepraktykiwcagdlalowcodedev-przydatnestrony"></a>

* przewodnik po wymaganiach: [**https://wcag20.widzialni.org/index.php**](https://wcag20.widzialni.org/index.php)
* [**Wytyczne dla dostępności treści internetowych (WCAG) 2.1**](https://www.w3.org/Translations/WCAG21-pl/)
* [WAVE Evaluation Tool](https://chromewebstore.google.com/detail/wave-evaluation-tool/jbbplnpkjmmeebjpijfedlgcdilocofh)
* tryb wysokiego kontrastu - rozszerzenie: <https://chromewebstore.google.com/detail/wysoki-kontrast/djcfdncoelnlbldjfhinnjlhdjlikmph?hl=pl>

## Czytniki ekranu <a href="#dobrepraktykiwcagdlalowcodedev-czytnikiekranu" id="dobrepraktykiwcagdlalowcodedev-czytnikiekranu"></a>

* do pobrania czytnik NVDA (pod Windows): <https://www.nvda.pl/pobierz>\
  lub
* <http://trakt.org.pl/bezplatne-czytniki-ekranu/>
* Na Linuksie mamy wbudowany czytnik (uruchamianie/gaszenie Win+Alt+S)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.eximee.com/budowanie-aplikacji/interfejs-uzytkownika/wcag/dobre-praktyki-wcag-komponenty-low-code.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.