WCAG best practices - components (low-code)

Label (Text)

Good practices

  • Headings and labels should be unambiguous and not duplicated – the user should be able to easily recognize what the given description refers to.

  • Labels not associated with a field should be set as a paragraph, using the option "Display as paragraph (<p>)".

Illustration 1. Option "Display as paragraph <p>

Associating a label with a field:

  • If a label refers to a single component – select that component from the list in the labelRef. Example: if the label Text7 is to be a description for the field TextField2, then in the WCAG label configuration Text7 you should indicate the component TextField2 as associated.

Illustration 2. Associating GesTextField1 text field with a label

  • If a label concerns multiple components – choose the first or most important in the context of the group. Example: if the postal code consists of two fields of type TextField, you should link the label to the first of them.

Label consistency:

  • The same elements on different pages should have identical labels to maintain consistency of navigation and content from the user's perspective, including users of screen readers.

Verification method

check ariaLabel and ariaDescription (if filled)

Text field (TextField)

Good practices

Filling in the label and accessibility attributes (ariaLabel, ariaDescription):

  • Each field should have an assigned label or ariaLabel (if there is no visual label).

  • By default, after adding the component TextField, the properties ariaLabel and ariaDescription are empty – they should be filled in manually. Example: instead of GesTextField1.ariaLabelKey use GesTextField1.label, which will automatically assign the label value to ariaLabel.

Illustration 3. Example of filling ariaLabelKey

Good practices for field descriptions:

Field requirement

  • Message "required field" may be too generic. It is recommended to use specific messages, e.g. "The first name field is required".

Format validation

  • If the field has format validation (e.g. PESEL, NIP), add to ariaDescription a description of the requirements, e.g.: "Require 11 digits without spaces or special characters."

Mask

  • If the field has a mask → describe in ariaDescription, e.g. which characters are allowed/disallowed.

  • If the field has a visibleMask → describe e.g.: "For the postal code enter only digits, without a dash."

Maximum length

  • If the field has a set maxLength → add to ariaDescription information about the limit, e.g.: "Up to 30 characters."

Suggester

  • If the field contains a suggester (dynamic suggestions) → describe its behavior, e.g.: "The value may be changed automatically when an incorrect number is entered."

Validator

  • When the validator error message is ambiguous, include its meaningful description in ariaDescription , e.g.: "The field may not contain special characters."

Formatter

  • If the field contains a formatter → describe how it works, e.g.: "The text will be automatically converted to uppercase."

Paste restrictions

  • If the field does not allow pasting text → this should be described in ariaDescription, e.g.: "The field does not support pasting data."

Prefix / suffix

  • If the field contains a prefix or suffix (e.g. "+48", "PLN") → add to ariaDescription, e.g.: "Field preceded by country code +48."

Verification method

check ariaLabel and ariaDescription (if filled)

Contextual help (Tooltip)

Good practices

If a tooltip has visibility conditions, make sure they match the conditions of the component to which the tooltip is assigned.

Checkbox and Checkbox Section (CheckboxSection)

Good practices

Filling ariaLabel and ariaDescription for the Checkbox and CheckboxSection component:

  • By default, after adding the component Checkbox, the ariaLabel and ariaDescription fields are empty. The value ariaLabel should be filled in manually – usually it is enough to assign its value from the text.

    field Example: Replace: GesCheckbox11.ariaLabel → GesCheckbox11.text (resulting in:)

Illustration 4. ariaLabel = text

  • Example of filling ariaLabel ariaDescription The attributeis not always required

, but it is worth adding in more complex contexts, e.g. when the checkbox requires additional explanation.Checkbox with formatted content ():

  • TextContent Checkbox with formatted content (If the checkbox is fed with formatted content from the Checkbox with formatted content (. component, remember that screen readers do not read ariaLabelTherefore the text content should also be assigned to

Illustration 5. to ensure its accessibility.

Verification method

check ariaLabel and ariaDescription (if filled)

Example of filling ariaLabel for a checkbox fed with content

Good practices

Filling ariaLabel and ariaDescription Date field (DatePicker)

  • Each field should have an assigned label or ariaLabel for the DatePicker component:

  • By default, after adding the component (if there is no visual label)., the properties ariaLabel and ariaDescription DatePicker ariaLabel are empty. They should be filled in manually or assigned

    field to the component's label key. Instead of GesDatePicker1.ariaLabelKey → use GesCheckbox11.text GesDatePicker1.label)

ariaLabel = label ariaDescription Good practices for filling

  • for date fields:If the field has date selection restrictions () dateRange ariaDescription, e.g.: → add a description to

  • "Select a date in the range from 01.01.2020 to 31.12.2030."If the field has a custom format set () dateFormat ariaDescription, e.g.: → describe it in

  • "Date format: month–year (MM-YYYY)."If an input mask is enabled () autoMask → it is worth adding information on how the auto-complete works, e.g.:

Verification method

"Enter digits only – the separator will be added automatically."

check ariaLabel and ariaDescription (clear information about data format)check ariaLabel and ariaDescription (if filled)

Good practices

ImageAlternative text (imageAlt

  • ) for imagesAlternative text ( or Every image should have alternative text filled in ( imageAltKey

Illustration 6. in the form source file).

  • Sample imageAltKey in the form source

    • Recommendations: Maximum text length:

    • 80 characters Maintain style and language consistency

  • of the description with the rest of the interface Empty attribute (altalt="" ) should be used, e.g.:

    • only when the image serves a decorative function

    • background

    • content-separating line

  • decorative icon without informational function Informational/Decorative presentation

  • - In the WCAG section you can set informational presentation (the image can be focused) or decorative presentation (it cannot be focused and has an empty imageAlt attribute). Image as a link Empty attribute If an image is contained within a link, it should containboth a graphic description and information about the function, e.g.: <a href="https://www.bank.com

  • "> <img src="logo-bank.png" alt="Bank XYZ Logo – Go to Bank XYZ homepage"> </a> SVG elements ariaLabel and ariaDescription

(informacje) For SVG graphics you can add the attribute More:

Verification method

Additional information

check alt values on the application

Good practices

Filling ariaLabel and ariaDescription Value selection from a list (Combobox)

  • for the Combobox component: ariaLabel (if there is no visual label).

  • By defaultEach ComboBox component should have an assigned label or ariaLabel and ariaDescription , after adding a ComboBox, the fields are empty ariaLabel – they should be filled in manually or assigned

    field to the label key. GesCheckbox11.ariaLabel GesCombobox1.ariaLabelKey GesCheckbox11.text GesDatePicker1.label)

GesCombobox1.label

  • Alternative text for the default value "Select": In the "Other" tab (in the ComboBox configuration) you can definealternative text for the default value "Select"

Illustration 7. , which improves accessibility and comprehension for screen reader users.

Verification method

Alternative text for "Select"

check ariaLabel and ariaDescription

Good practices

Radio group (RadioGroup)/ Tile Group (TileGroup)

  • Label and accessibility attributes:Each component should have a label (label ariaLabel ) or

  • By default(if a visual label is not available)., after adding the component (, RadioGroup, ComboBoxTileGroup ariaLabel and ariaDescription ), the fields are empty — they should be filled in manually or ariaLabel – they should be filled in manually or assigned

assigned

  • RadioGroup:RadioEach option (value)) should have a unique value (

  • RadioGroup , to avoid conflicts in form operation and errors for screen readers.

    • may have: one common tooltip

    • or (for the whole group),separate tooltips for each option

, if each requires additional description.

  • TileGroup:If an image wasadded in the tile content ( Tile), you should:

    • add an alternative description (Empty attribute), which clearly informs about the image content,

    • set alt for decorative graphics so they are not read by screen readers.

Verification method

check ariaLabel and ariaDescription, check alt values if they were added to images

Repeatable section (RepeatableSection)

Good practices

  • The section should have a title (Each component should have a label (label ariaLabel – this ensures that the screen reader correctly identifies its content and context.

  • In the ariaDescription attribute include information about the minimum and maximum number of possible occurrences of the section.

Verification method

check ariaDescription

Slider/Step slider

Good practices

  • By default, after adding the component Slider, the properties ariaLabel and ariaDescription , after adding a ComboBox, the fields are. They should be filled in manually — especially ariaLabel, if the component does not have a visible label.

  • In the ariaDescription it is worth including information about the range of selectable values

Verification method

check ariaDescription

Plus Minus

Good practices

  • By default, after adding a component of type Plus-Minus, the attributes ariaLabel and ariaDescription , after adding a ComboBox, the fields are. They should be filled in manually — especially ariaLabel, if the component does not have a visible label.

  • In the ariaDescription you should add information about the minimum and maximum possible value, so screen reader users are clear about the available range.

Verification method

check ariaDescription

Rollable formatted content (RollableTextContent)

Good practices

  • Ensure the component has a title (label) and ariaLabel.

  • ariaLabel should unambiguously describe the component content so that screen readers can correctly convey the information about the content to the user.

Verification method

check the title value

Product selection (ProductSelector)

Good practices

  • By default, after adding the component ProductSelector, the ariaLabel and ariaDescription are empty. They should be filled in manually — especially ariaLabel, if the component does not have a visible label.

  • Images used in the component ProductSelector should have their Empty attribute values filled in — in accordance with accessibility rules so screen readers can correctly describe the graphics.

  • HTML content used in the component (ContentHTML) should be validated using an HTML validation tool (e.g. Markup Validation Service) to eliminate errors and improve accessibility.

Verification method

check alt values and HTML code

Internal link (PageNavigationLink) and external (Link)

Good practices

  • By default, after adding a link the ariaLabel and ariaDescription are empty. They should be filled in manually — especially ariaLabel, if the component does not have a visible label.

  • Do not use all capital letters (caps lock) in link texts, to avoid making them harder to read and recognize for users and screen readers.

  • The user should be informed whether clicking the link will open a new tab or launch another application. This can be achieved by:

    • setting the link opening property, e.g. target="_blank",

    • adding informative text for example in the title (title) or in the ariaDescription.

    • clear graphic or textual indication.

  • In the link properties you can set, among others:

    • the opening method (target, e.g. _blank),

    • the text displayed on hover (attribute title),

    • the anchor name (page fragment).

Illustration 8. Link component properties

Verification method

Alternative text for "Select"

Statements

Good practices

Alternative text for the default value "Select": Properties you can change the following overriding properties for texts displayed in the interface:

  • Overriding property: "Collapse statements content"

  • Overriding property: "Expand statements content"

  • Overriding content property: "You did not consent to the required statements"

  • Overriding content property: "You did not make selections for all statements, please complete the required information in the statements section"

  • Overriding content property: "I accept the selected statements"

  • Overriding content property: "I accept all statements"

Illustration 9. Statements component properties

Attachments (UploadFile)

Good practices

  • By default, after adding UploadFile field ariaLabel and ariaDescription are empty. They should be filled in manually — especially ariaLabel, if the component does not have a visible label.

  • In the attributes

    • By default, after adding a link the ariaLabel and ariaDescription are empty. They should be filled in manually — especially ariaLabel, if the component does not have a visible label.

    or ariaDescription there should be information about:

    • whether attachments are required,

    • the number of files that can be added.

Verification method

check ariaLabel

Map (MapView)

Good practices

  • By default, after adding MapView field ariaLabel and ariaDescription are empty. They should be filled in manually — especially ariaLabel, if the component does not have a visible label.

  • In the ariaLabel or ariaDescription it is worth placing information important to the user, e.g.:

    • description of the map's purpose,

    • usage instructions (e.g. whether a location can be selected),

    • other relevant accessibility information.

Verification method

check ariaLabel

Confirmation section (ConfirmationSection)

Good practices

  • By default, after adding confirmation section field ariaLabel and ariaDescription are empty. They should be filled in manually — especially ariaLabel, if the component does not have a visible label.

  • In the ariaLabel or ariaDescription it is worth including additional information helpful in the context of data confirmation, e.g.:

    • confirmation instructions,

    • a note to check the data before submitting.

QR code generator (QRCodeGenerator)

Good practices

By default, after adding QRCodeGenerator field ariaLabel and ariaDescription are empty. They should be filled in manually — especially ariaLabel, if the component does not have a visible label.

Verification method

check ariaLabel

QR code scanner (QRCodeScanner)

Good practices

By default, after adding QRCodeScanner field ariaLabel and ariaDescription are empty. They should be filled in manually — especially ariaLabel, if the component does not have a visible label.

Verification method

check ariaLabel

AZTEC code scanner (AztecCodeScanner)

Good practices

By default, after adding AztecCodeScanner field ariaLabel and ariaDescription are empty. They should be filled in manually — especially ariaLabel, if the component does not have a visible label.

Verification method

check ariaLabel

Useful sites

Screen readers

PreviousWCAG best practices - general (low-code)NextWCAG best practices - print templates (low-code)

Last updated

Was this helpful?