# WCAG best practices - general (low-code) {% hint style="info" %} WCAG - Audit tab [WCAG - Audit](https://docs.eximee.com/documentation/documentation-en/budowanie-aplikacji/interfejs-uzytkownika/formularze/tworzenie-formularza/zakladka-audyt-naruszenia-wcag/wcag-audyt) {% endhint %} {% hint style="info" %} WCAG - Page contains a form [WCAG - page as a form](https://docs.eximee.com/documentation/documentation-en/budowanie-aplikacji/interfejs-uzytkownika/formularze/tworzenie-formularza/zakladka-audyt-naruszenia-wcag/wcag-strona-jako-formularz) {% 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, so when checking or modifying an application for WCAG, **one should not** rely solely on the tab **Audit**).

Figure 1. Sample list of WCAG violations

Figure 2. Example application without comments in the tab Audit

### **HTML - Content (TextContents) and custom components (CustomComponents)** When creating and modifying TextContents, it is worth **checking the HTML using the 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 3. Example of using the markup validator

Pay attention to links (target), images (alt), lists, and headings (with the correct hierarchy). ### **AriaLabel and ariaDescription** * **ariaLabel** – The value of the component label property. * **ariaDescription** – The value of the component description property. This is a text description of the component, read by screen readers. It usually serves as an extended description of the field (e.g. includes the field mask, tooltip content not read by the screen reader, validator). * **By default, ariaLabel fields are empty; they should be added according to the example.** (see **Text field (TextField)** and **Multiple choice field (Checkbox)** in the table below)
* **ariaLabel should be added if the component is not associated with a label.** * Attribute **ariaLabel** should be used in interactive page elements.

Figure 4. Additional rules for using ARIA

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** Verification methods **ariaLabel** and **ariaDescription**: * using a **screen reader** – you can check how the attributes are read to the user. (Links to example screen readers are at the end of the documentation) * using developer tools – **DevTools** – the 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 5. Attribute preview ariaLabel and ariaDescription in DevTools

### **Headings** * **\

**\ Eximee Designer will have set by default **\

** as the application title. Although using several headings **\

** is allowed by HTML standards (as long as they are not nested), it is not considered a good practice. In general, there should be one heading on the page **\

**, which describes the main content of the page. When adding headings in the application, it is best to start at level **\

**. * **Section headings -** each added section in the application may have its own heading. **Section within a section** will have the next heading level (aria-level) – this also applies to a repeating section.

Figure 6. Defining headings in Eximee Designer

* Additional information: [\

–\

: 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 complex components (dynamic names)** If a given **complex component** is used **multiple times** – e.g. in an application template or as an element of another complex component - you can set **different ariaLabel and ariaDescription values**, depending on the usage context. For example: the field "**First name**" may have a different description for the applicant and another for the co-applicant. To achieve this, in the **artifact containing the reused complex component** : * Go to the tab **Translations**. * For each field separately, add the appropriate translation keys **ariaLabel** and/or **ariaDescription**.\ **Note: The key must be the full path to the field.** Example:\ Field **Street** (GesTextField1), located in the complex component, was used twice in the application – with assigned ids **GesComplexComponent2** and **GesComplexComponent3**.\ For each occurrence, a different **ariaLabel**, e.g.: * **GesComplexComponent2.GesTextField1.ariaLabel** : "**Street** **residence**" * **GesComplexComponent3.GesTextField1.ariaLabel** : "**Correspondence street**"

Figure 7. Defining ariaLabel for complex components

#### Verification method When entering the field, the screen reader should read the correct ariaLabel, i.e. "residence street" and "correspondence street" ### **Page as a form** If the parameter is checked, the application page is assigned the role **`form`**. By default, this parameter is enabled.

Figure 8. Functionality "Page as a form"

### **Required/optional fields** **Fields required to be filled in should be marked** – information about their required status should be added in the visual layer, e.g. by adding the note "\*required field" or the symbol "\*". They should also **be visually distinguished** from optional fields so that the user can easily identify them. ### **Page title** **The page title should clearly** **identify the current location,** without having to read the page content. ### **Text as an image** **Do not place text in the form of an image** (logo is an exception). ([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 size change (custom style)** * After increasing the text size by **200%** the interface must not lose readability or 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 readability: * line height: at least 1.5 times the font size * paragraph spacing: at least 2 times the font size * letter spacing: at least 0.12 times the font size * word spacing: 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 used for decorative purposes, they should be hidden from screen readers using the attribute **aria-hidden**.\ Example: *\ Continue* ### **Responsiveness** **Content must be presented without loss of information or functionality on screens with a minimum width of 320 px and a height of 256 px.**\ Additionally **there must be no horizontal scrolling**, except for two-dimensional content such as: tables, complex images, maps, and charts. ### **High contrast** All elements should be **visible and readable when high contrast mode is enabled.**\ Chrome extension: ### **Navigation** Navigation elements on subpages should be in the same place, maintaining a consistent layout across all pages. ### **CSS - Hiding text from the visual presentation + ignoring text by screen readers**

Figure 9. Example of hiding layout elements using CSS

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 text from everyone** ### **Summary** The form should contain a page with a summary of the data - the so-called confirmation page - allowing the user to verify it, go back to earlier steps to make corrections, and finally confirm the accuracy of the data.