WCAG best practices - general (low-code)

WCAG - Audit tab

WCAG - Audit

WCAG - The page contains a form

WCAG - page as a form

Audit tab

When modifying existing applications, pay attention to the Audit. (Unfortunately, at the moment only the XML is checked - mainly labels. Errors in TextContent are not caught there, so when checking or modifying the application for WCAG, do not rely solely on the Audit).

Illustration 1. Sample list of WCAG violations
Illustration 2. Example application without comments in the Audit

HTML - TextContents and CustomComponents

When creating and modifying TextContents it is worth checking the HTML using a validator: Markup Validation Service (HTML) – https://validator.w3.org/ (additional information (informacje))

Illustration 3. Example of using the markup validator

Pay attention to links (target), images (alt), lists and headings (maintaining the correct hierarchy).

AriaLabel and ariaDescription

  • ariaLabel – The value of the component's label property.

  • ariaDescription – The value of the component's description property. This is a text that verbally describes the component, read by screen readers. It most often constitutes an extended description of the field (e.g., contains the field mask, tooltip text not read by the screen reader, validator).

  • By default ariaLabel are empty, they should be added according to the example. (see Text field (TextField) and Checkbox (multiple choice field) in the table below)

  • ariaLabel should be added if the component has no association with a label.

  • Example of filling ariaLabel ariaLabel should be used on interactive elements of the page.

Illustration 4. Additional rules for using ARIA

Additional information: Using ARIA(informacje)

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 – attributes ariaLabel and ariaDescription can be checked directly in the DOM structure, in the Elements.

  • using a browser plugin e.g. WAVE Evaluation Tool

Illustration 5. Attribute viewer ariaLabel and ariaDescription in DevTools

Headings

  • <h1> Eximee Designer will have set by default <h1> as the application title. Although using multiple headings <h1> is allowed by HTML standards (as long as they are not nested), it is not considered good practice. Essentially there should be one heading <h1>on a page that describes the main content of the page. When adding headings to the application it's best to start at level <h2>.

  • 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 repeatable sections.

Illustration 6. Defining headings in Eximee Designer

Reusability of composite components (dynamic names)

If a given composite component is used multiple times – e.g., in an application template or as part of another composite component - you can set 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 another for the co-applicant.

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

  • Go to the Translations.

  • For each field separately add appropriate translation keys ariaLabel and/or ariaDescription. Note: The key must be the full path to the field.

Example: Field Street (GesTextField1), located in a composite component, was used twice in the application – assigned ids GesComplexComponent2 and GesComplexComponent3. For each occurrence you can assign a different ariaLabel, e.g.:

  • GesComplexComponent2.GesTextField1.ariaLabel : "Street residence"

  • GesComplexComponent3.GesTextField1.ariaLabel : "correspondence street"

Illustration 7. Defining ariaLabel for composite components

Verification method

Upon focusing 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.

Illustration 8. "Page as a form" functionality

Required/optional fields

Fields required to be filled should be marked – add information about their requiredness in the visual layer e.g. by adding the note "*required field" or the symbol "*". They should also visually differ from optional fields so 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

Do not include text in the form of an image (except for a logo). (additional information (informacje))

Text resizing (custom style)

  • After increasing the text size by 200% there must be no loss of readability or interface functionality. (additional information (informacje))

  • Text should meet 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 decoratively, they should be hidden from screen readers using the 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 when high contrast mode is enabled. Chrome extension: https://chromewebstore.google.com/detail/wysoki-kontrast/djcfdncoelnlbldjfhinnjlhdjlikmph?hl=pl

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

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

Illustration 9. Example of hiding layout elements using CSS

Additional information: CSS - Invisible Content Just for Screen Reader Users(informacje)

display:none or visibility: hidden → hides text from everyone

Summary

The form should include a page with a summary of data – a confirmation page – allowing the user to review them, go back to previous steps to make corrections and finally confirm the correctness of the data.

Last updated

Was this helpful?