> For the complete documentation index, see [llms.txt](https://docs.eximee.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.eximee.com/documentation/documentation-en/budowanie-aplikacji/interfejs-uzytkownika/wcag/dobre-praktyki-wcag-ogolne-low-code.md).

# WCAG best practices - general (low-code)

{% hint style="info" %}
WCAG - Audit tab

[WCAG - Audit](/documentation/documentation-en/budowanie-aplikacji/interfejs-uzytkownika/formularze/tworzenie-formularza/zakladka-audyt-naruszenia-wcag/wcag-audyt.md)
{% endhint %}

{% hint style="info" %}
WCAG - Page contains a form

[WCAG - page as a form](/documentation/documentation-en/budowanie-aplikacji/interfejs-uzytkownika/formularze/tworzenie-formularza/zakladka-audyt-naruszenia-wcag/wcag-strona-jako-formularz.md)
{% endhint %}

## **Audit tab**

When modifying existing applications, pay attention to the tab **Audit**. (Unfortunately, at the moment only the XML is checked - mainly labels. Errors in TextContent are not detected there, therefore when checking or modifying the application in terms of WCAG, **you should not** rely solely on the tab **Audit**).

<figure><img src="/files/9f741b1f5930b162da626c02b8b1baa23aec8fd7" alt=""><figcaption><p><em><strong>Figure 1.</strong> Example list of WCAG violations</em></p></figcaption></figure>

<figure><img src="/files/6bfb92b10684ab2b99a80e2d3a29fafb63bb991e" alt=""><figcaption><p><em><strong>Figure 2.</strong> Example of an application with no remarks in the tab <strong>Audit</strong></em></p></figcaption></figure>

### **HTML - Content (TextContents) and custom components (CustomComponents)**

When creating and modifying TextContents, it is worth **checking the HTML using a validator:** [Markup Validation Service (HTML) – https://validator.w3.org/](https://validator.w3.org/) ([additional information](http://wcag.stowarzyszenie.edu.pl/mod/page/view.php?id=149) ![(informacje)](https://wiki.consdata.pl/s/-rvpvnr/8703/51k4y0/_/images/icons/emoticons/information.svg))

<figure><img src="/files/ebc23f249553364f700dc29b0d300d9d1a043760" alt="" width="563"><figcaption><p><em><strong>Figure 3.</strong> Example of using the markup validator</em></p></figcaption></figure>

Attention should be paid to links (target), images (alt), lists, and headings (while maintaining the proper hierarchy).

### **AriaLabel and ariaDescription**

* **ariaLabel** – The value of the component label property.
* **ariaDescription** – The value of the component description property. This is text verbally describing the component, read by screen readers. Most often, it constitutes an extended description of the field (e.g. it contains the field mask, the content of a tooltip not read by a screen reader, a validator).
* **By default, ariaLabels are empty; they should be added according to the example.** (see **Text field (TextField)** and **Multiple choice field (Checkbox)** in the table below)<br>
* **ariaLabel should be added if the component has no association with a label.**
* Attribute **ariaLabel** should be used on interactive elements of the page.

<figure><img src="/files/087211d5edd82649c13d39b177a5d935f0ff56b0" alt=""><figcaption><p><em><strong>Figure 4.</strong> Additional rules regarding the use of ARIA</em></p></figcaption></figure>

Additional information: [Using ARIA](https://www.w3.org/TR/using-aria/#notes2)![(informacje)](https://wiki.consdata.pl/s/-rvpvnr/8703/51k4y0/_/images/icons/emoticons/information.svg)

### **Verification of ariaLabel and ariaDescription**

Methods of verification **ariaLabel** and **ariaDescription**:

* using **a screen reader** – you can check how the attributes are read to the user. (Links to example screen readers can be found at the end of the documentation)
* using developer tools – **DevTools** – attributes **ariaLabel** and **ariaDescription** can be checked directly in the DOM structure, in the tab **Elements**.
* using a browser plugin, e.g. [WAVE Evaluation Tool](https://chromewebstore.google.com/detail/wave-evaluation-tool/jbbplnpkjmmeebjpijfedlgcdilocofh?hl=en-US\&utm_source=ext_sidebar)

<figure><img src="/files/e75c2e1027d72df40e537aa4ee031f1e31d471e5" alt="" width="563"><figcaption><p><em><strong>Figure 5.</strong> Attribute preview <strong><code>ariaLabel</code></strong></em> <em>and <strong><code>ariaDescription</code></strong> in <strong>DevTools</strong></em></p></figcaption></figure>

### **Headings**

* **\<h1>**\
  Eximee Designer will have set by default **\<h1>** as the application title. Although using several headings **\<h1>** is allowed by HTML standards (as long as they are not nested), it is not considered good practice. As a rule, there should be one heading on the page **\<h1>**, which describes the main content of the page. When adding headings to the application, it is best to start from level **\<h2>**.
* **Section headings -** each section added to the application may have its own heading. **Section within a section** will have the next heading level (aria-level) – this also applies to a repeatable section.

<figure><img src="/files/710ff638da9e57c9d7a823625ecf10c6d1041e2d" alt=""><figcaption><p><em><strong>Figure 6.</strong> Defining headings in Eximee Designer</em></p></figcaption></figure>

* Additional information: [\<h1>–\<h6>: The HTML Section Heading elements](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Heading_Elements) ![(informacje)](https://wiki.consdata.pl/s/-rvpvnr/8703/51k4y0/_/images/icons/emoticons/information.svg)

### **Reusability of composite components (dynamic names)**

If a given **composite component** is used **multiple times** – e.g. in an application template or as an element of another composite component - it is possible to define for its fields **different values of ariaLabel and ariaDescription**, depending on the context of use.

For example: the field "**First name**" may have a different description for the applicant and a different one for the co-applicant.

To achieve this, in **the artifact containing the reused composite component** :

* Go to the tab **Translations**.
* Add the appropriate translation keys separately for each field **ariaLabel** and/or **ariaDescription**.\
  **Note: The key must be the full path to the field.**

Example:\
Field **Street** (GesTextField1), located in the composite component, was used twice in the application – with the assigned ids **GesComplexComponent2** and **GesComplexComponent3**.\
A different one can be assigned for each occurrence **ariaLabel**, e.g.:

* **GesComplexComponent2.GesTextField1.ariaLabel** : "**Street** **of residence**"
* **GesComplexComponent3.GesTextField1.ariaLabel** : "**Correspondence street**"

<figure><img src="/files/a5182483d3afed0024817640884272a5be61c75a" alt=""><figcaption><p><em><strong>Figure 7.</strong> Defining <strong>ariaLabel</strong> for composite components</em></p></figcaption></figure>

#### Verification method

Upon entering the field, the screen reader should read the appropriate ariaLabel, namely "street of residence" and "correspondence street"

### **Page as a form**

If the parameter is selected, the application page is assigned the role **`form`**. By default, this parameter is enabled.

<figure><img src="/files/682e64daa671f68c7e1372795d7c74b23d1de04c" alt=""><figcaption><p><em><strong>Figure 8.</strong> The "Page as a form" functionality</em></p></figcaption></figure>

### **Requiredness / optionality of fields**

**Fields required to be filled in should be marked** – information about their requiredness should be added in the visual layer, e.g. by the note "\*required field" or the symbol "\*". They should also **differ visually** from non-required fields so that the user can easily identify them.

### **Page title**

**The page title should clearly** **identify the current location,** without the need to read the page content.

### **Text as an image**

**Text should not be placed in the form of an image** (the exception is a logo). ([additional information](https://wcag20.widzialni.org/grafiki-tekstowe,new,mg,165,172.html,73) ![(informacje)](https://wiki.consdata.pl/s/-rvpvnr/8703/51k4y0/_/images/icons/emoticons/information.svg))

### **Text resizing (custom style)**

* After increasing the text size by **200%** there must be no loss of readability or interface functionality. ([additional information](https://wcag20.widzialni.org/zmiana-rozmiaru-tekstu,new,mg,165,172.html,72) ![(informacje)](https://wiki.consdata.pl/s/-rvpvnr/8703/51k4y0/_/images/icons/emoticons/information.svg))
* Text should meet the minimum spacing requirements to ensure its readability:
  * line height: at least 1.5 times the font size
  * spacing between paragraphs: at least 2 times the font size
  * letter spacing: at least 0.12 times the font size
  * spacing between words: at least 0.16 times the font size
* All elements **must remain readable and visible** after applying the above parameters.

### **Special characters in content**

If special characters are used in the content, e.g. arrows serving a decorative function, they should be hidden from screen readers using the attribute **aria-hidden**.\
Example: *\<span aria-hidden="true">→\</span> Continue*

### **Responsiveness**

**Content must be presented without loss of information or functionality on screens with a minimum width of 320 px and height of 256 px.**\
Additionally **horizontal scrolling must not occur**, except for two-dimensional content such as: tables, complex images, maps, and charts.

### **High contrast**

All elements should be **visible and readable after enabling high contrast mode.**\
Chrome extension: <https://chromewebstore.google.com/detail/wysoki-kontrast/djcfdncoelnlbldjfhinnjlhdjlikmph?hl=pl>

### **Navigation**

Navigation elements on subpages should be located in the same place, maintaining a consistent layout across all pages.

### **CSS - Hiding text from visual presentation + ignoring text by screen readers**

<figure><img src="/files/1c588a9ef6561d9061f1a5646baf0a98633c6ebb" alt="" width="563"><figcaption><p><em><strong>Illustration 9.</strong> Example of hiding layout elements using CSS</em></p></figcaption></figure>

Additional information: [CSS - Invisible Content Just for Screen Reader Users](https://webaim.org/techniques/css/invisiblecontent/)![(informacje)](https://wiki.consdata.pl/s/-rvpvnr/8703/51k4y0/_/images/icons/emoticons/information.svg)

**display:none or visibility: hidden → hiding the text from everyone**

### **Summary**

The form should include a page with a summary of the data – the so-called confirmation page – allowing the user to verify it, go back to earlier steps in order to make corrections, and finally confirm the correctness of the data.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://docs.eximee.com/documentation/documentation-en/budowanie-aplikacji/interfejs-uzytkownika/wcag/dobre-praktyki-wcag-ogolne-low-code.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.