Visforms and accessibility

Since the first versions of Visforms were released, we have been working continuously to implement the latest state of the art technology and measures for barrier-free use.
In collaboration with affected customers and users, we have implemented everything necessary to ensure that forms can meet the standards and legal requirements.

In particular, Visforms ensures the following:

Clear, well-structured forms can be created.
Each input field has a clearly assigned label.
Each label can also be given an icon that serves as visual support.
The form can be made more understandable by adding additional text.
The entire form is accessible and understandable for screen readers thanks to correct aria attribute labeling.
User input is validated in a user-friendly manner.
Meaningful error messages are issued that are directly and immediately assigned to the incorrect input.
The direct assignment also applies to screen readers.
Input fields that are not disabled can be reached using the keyboard.
Elements without functional meaning are marked in HTML by a corresponding role="presentation" attribute labeling.

Web standards and legal requirements

Note: With Visforms you can create forms that are barrier-free and meet international standards (WAI, WCAG), European (EAA) and German (BFSG) legal requirements.

International

The general international basis and the basis for international, European and German legal requirements for accessibility is the W3C Web Accessibility Initiative (WAI).

The W3C organization derives the following international standards from this: Web Content Accessibility Guidelines (WCAG).

The ‘Web Content Accessibility Guidelines (WCAG)’ define a total of 3 different levels of conformity: A, AA and AAA.

WCAG A

Level WCAG A is the minimum level of conformity.
It includes the most basic web accessibility features and is essential for any website that aims to be accessible.
This level requires basic accessibility features such as text alternatives for videos and images and ensuring that all interactive elements are accessible using a keyboard.
It does not guarantee a fully accessible website on its own, as barriers may still exist for certain users.

WCAG AA

The WCAG AA level is usually necessary to make a website legally accessible.
The WCAG AA level includes all the requirements of Level A, plus additional criteria that address more general issues.
This level is what most organizations aim for, as it ensures greater accessibility and usability for a wider audience.

Note: The WCAG 2.1 AA level is recognized as a legal standard by countries such as Canada, Japan, Germany, the United Kingdom, Australia and India.

Note: The level WCAG 2.1 AA is the minimum conformance level for compliance with the BFSG (see 'Germany').

WCAG AAA

The level WCAG AAA is the most comprehensive standard for digital accessibility and the ultimate goal to strive for.
However, this is not the legally required level, as some content cannot meet the AAA requirements.

Note: In particular, the levels WCAG 2.1 AA and AAA can be implemented with Visforms.

Caution: Visforms does not prevent you from creating a form that is not accessible.

Europe

In Europe, the EU Directive 2019/882 of the European Parliament and of the Council of April 17, 2019 on accessibility requirements for products and services, known as the European Accessibility Act (EAA) for short, applies.

Germany

In Germany, the new Accessibility Strengthening Act (BFSG) will apply from June 28, 2025.
The full name of this federal law is Law implementing Directive (EU) 2019/882 of the European Parliament and of the Council on accessibility requirements.
This federal law serves to implement the European directive European Accessibility Act (EAA).

Visforms and the “Web Content Accessibility Guidelines (WCAG)”

Note: With Visforms, all requirements up to and including the highest level WCAG AAA can be met.

Caution: Poor configurations in Joomla, the template and Visforms can quickly lead to a form being inaccessible and not meeting the requirements of standards and legal requirements. You must understand the impact of your configuration on accessibility in order to achieve accessibility.

Caution: Poor design decisions and technical requirements can quickly lead to a form being inaccessible and not meeting the requirements of standards and legal requirements. You must understand the impact of your decisions on accessibility in order to achieve accessibility.

It is important to know and note that only a small part of the requirements of standards and specifications relate to a form component.
In particular, the selected template plays a fundamental role in accessibility, such as the font size and contrast ratios.

Of all the many criteria of the standards and specifications, only a few relate exclusively to the Visforms form component:

Navigation via the keyboard.
Specifications for error identification.
The technical attribute labeling, which in the broadest sense belongs to ‘labels or instructions’.

Creating barrier-free forms

Even with the stated intention of creating forms that are as barrier-free as possible, there are numerous conflicting design decisions and technical requirements. It is easy for the requirements of the form to be incompatible with the accessibility requirements.

It is important to implement the right level of accessibility for the form. First of all, you have to find out what level that is. This also depends largely on the expected user group for the form.

Below you will find a list of features that are only partially accessible and for which you have to consider whether and how you want to use them.
You should avoid the features described here if one of the following cases applies:

You want to make the form completely barrier-free.
You have to implement legal requirements.

Captcha

A captcha that the user has to solve is already designed to make it more difficult to submit a form. This difficulty is necessary to distinguish people from robots.

If you activate one of the captchas in Visforms, your forms are not accessible. In addition to significant problems for people with visual impairments, for example, captchas also bother many other users.

Captchas are generally not a particularly effective spam protection. With the Visforms spam protection plugin in conjunction with a honeypot field, Visforms offers very good, effective and accessible alternatives. It is therefore often not necessary to make your forms unattractive and not accessible by displaying a captcha.

Note: In fact, many captchas are easier to solve, especially for AI-supported spam bots, than for people.

Signature field

With the Signature field type, the user draws his signature with his finger on a touchscreen or with the mouse on the desktop. The drawing takes place on the HTML Canvas Element. The HTML Canvas Element is not an elementary standard HTML element and in particular not a form HTML control in the true sense.

Using the form field and the process of signing as a whole is quite complex and complicated.

Note: It is impossible to make the use of the signature field completely barrier-free.

We have revised the Signature field type. The HTML Canvas Element on which the signature is drawn can be reached with the keyboard. The actual filling of the signature field itself still requires the use of the mouse on the desktop or the finger on the touchscreen. Unlocking and locking the field on a touchscreen as well as deleting signatures in the form’s edit mode are also extremely tedious using only the keyboard.

Hidden field labels

Displaying forms with fields without field labels is quite common. These forms seem to be quite appealing and modern minimalist for some user groups. In terms of accessibility, this design decision is not recommended for various reasons.

Every user should be able to see immediately and easily at first glance what type of information they have to enter in a form field. A field label is by far the best way to display and achieve exactly that.

Placeholders are not a real alternative. Placeholders are often much less contrasting and therefore harder to read and reduce accessibility. The placeholder disappears as soon as text input starts. The user must therefore remember exactly what type of information has to be entered in the field.

Note: We therefore generally recommend only using visible field labels in the form.

Accordion

An accordion is not a standard HTML element, it is not even an HTML element. An accordion is created solely by a mixture of special CSS and JavaScript.

An accordion implementation is a proprietary function of the underlying UI framework used. An accordion implementation therefore differs from UI framework to UI framework, for example for Bootstrap layout and UIkit layout.

Note: The accordion implementation is provided by the UI framework used and does not come from Visforms.

Both UI frameworks natively supported by Visforms, Bootstrap 5 and UIkit 3, have an accordion implementation with full screen reader support. However, both UI frameworks do not have an implementation for keyboard control for the accordion.

Note: The individual accordion tabs can only be folded in and out using the mouse.

Field type textarea and display as editor

Visforms uses the Joomla default editor TinyMCE if the display as HTML editor is activated for the field type Textarea. In this case, warnings are issued, at least in the Accessibly Checker of the Firefox web browser.

You can assign a tooltip text to each form field, which means additional visual help for the user. The tooltip text usually provides additional information on how to fill out the field correctly. The tooltip text is only displayed when the form field has the input focus. Only then is the tooltip text displayed.

On the one hand, the tooltip text is a nice way to provide additional information. The form does not become longer by using tooltip texts and appears less overloaded overall.

Note: This additional information in the tooltip texts is inaccessible to users who do not work visually.

Note: The implementation of the tooltip texts is provided by the UI framework used and does not come from Visforms.

Depending on the chosen UI framework, Bootstrap 5 or UIKit 3, the tooltip texts are implemented differently.

Bootstrap 5’s tooltip texts use the aria-describedby attribute. This can lead to an overload of the overall information added to a form field using aria attributes.

Read-Only

There are HTML control types for which no readonly attribute is provided.
These field types do not have an official HTML property Read-Only.
The W3C definition lists the following HTML control types or field types that do not officially have a readonly attribute:

Listbox,
Checkbox,
Radio Button,
Checkbox group.

It is sometimes desirable for the form creator to be able to use the Read only option for all form fields.
In Visforms we have therefore also built the Read only parameter into the field configuration for these field types.
With the help of Visforms’ own JavaScript we can ensure that these form fields can also behave as read-only.
In addition, Visforms also sets the aria-readonly attribute wherever possible.

In Visforms, these field types can be configured as Read-Only as follows:
Field configuration » General tab » Display settings group » Read only parameter = ‘Yes’.

With regard to accessibility, a problem now arises due to the general W3C standards that exclude the above HTML control types.
For example, it is not always clear to screen readers, because it is unexpected, that the above HTML control types function as read-only.
In these cases, it is difficult to understand why, for example, a checkbox cannot be activated.

Note: Avoid field configuration for 'Read-Only' for all field types listed above.

Visforms and accessibility

Visforms and accessibility