# 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)