Accessibility of web forms in WCAG 2.1

When striving for digital accessibility, whether due to legal requirements or market expectations, we look first to the WCAG 2.1 standard, echoed in European standards (the 2018 Web Content Accessibility Guidelines 2.1 is part of EN 301 549).

However, the division of success criteria, as this is the term used by the WCAG standard, is adopted to categorize IT issues, but not the ways in which we perceive websites.

Form errors are a good example of this problem. It is difficult to find a discussion of the digital accessibility of forms that does not refer to more than one WCAG guideline.
What set of success criteria is most often associated with form accessibility?
First, there is Principle 1.3.1: Information and Relationships. This is a guideline from the Level A success criterion within Principle 1 – Perceivability. WCAG Principles 2.1 indicates that when this guideline is met, the information, structure, and relationships between content conveyed through the presentation can be read by a computer program or exist in text form.

Second, comes rule 2.4.6: Headings and Labels. This is a guideline from the AA level success criterion within Principle 2 – Functionality. WCAG Principles 2.1 indicates that when this guideline is met, headings and labels describe the topic or purpose of the content.

Third, Principle 3.3.2: Labels or Instructions is mentioned. This is a guideline from the Level A success criterion within Principle 3 – understandability. The WCAG 2.1 principles indicate that when this guideline is met, labels or instructions are provided when user input is required in the content.

Fourth, principle 4.1.2 is indicated: name, role, value. This is a guideline with a level A success criterion and relates to principle 4 – robustness. It means that for all user interface components (including, but not limited to, form elements, links, and script-generated components), the name and role can be specified programmatically ; the state, properties, and values that can be set by the user can also be set programmatically ; notification of changes to these elements is available to user programs , including assistive technologies.

Understanding these principles in the context of form development is not easy. In simple terms, forms should be programmed in a classic and comprehensive way: contain not only sample content, but also a label, properly “focus” using the keyboard and – separately – the screen reader, equally for TAB and arrow and by using a shortcut (e.g. E by NVDA). The form should have autocomplete values set, have no hidden elements, and communicate in text (not special characters or colors) how the form is to be filled out – for example, which fields are mandatory. In the case of visual, non-textual messages, there are violations of WCAG 2.1 guidelines other than those mentioned above (e.g., guideline 1.4.1, criterion A, while special markings apply to guideline 1.3.1, indicated earlier).

A derivative of correct programming of the form is correct error communication. Such a message must be available to those who fill out the form through a screen reader (e.g., listen through NVDA, in the language of the page). This is related to guideline 3.3.1 (level A).

External resources: WCAG 2.1 https://www.w3.org/Translations/WCAG21-pl/