Qualitative evaluations

Accessibility criteria that are most often not met for websites and apps as a whole, what errors they are, why they are classified as barriers and how they can be fixed

The most commonly unfulfilled criteria

The quantitative evaluations of the individual WCAG criteria show which criteria are particularly frequently met or not met. Over all monitoring periods, there are 4 criteria that are each time among the most frequently not met:

  • Info and relations (WCAG criterion 1.3.1)
  • Non-text content (WCAG criterion 1.1.1)
  • Name, role, value (WCAG criterion 4.1.2)
  • Contrasts of texts (WCAG criterion 1.4.3)

The criteria identified as most frequently not fulfilled since the first monitoring period 2020/2021 are described on the page "The most common errors" on digitalbarrierefrei.at (external link - only in German).

Monitoring period

During the 2022 monitoring period, the following five criteria were identified as most frequently not met for websites and apps – these are not met on average on at least 90% of websites and apps.

Note: The presentation focuses on the most common accessibility issues and the individual criteria are therefore not fully described. The further links are purely additional information and are not related to the accessibility checks carried out by the FFG.

Info and relations (WCAG criterion 1.3.1)
What does the criterion mean?

IInformation and structures on websites or relationships between elements on websites should not only be visually understandable, but also programmatically correctly distinguished and can be determined. The most important aspects here are:

  • The heading hierarchy should be properly distinguished: The website should not only be visually structured and visually hierarchized with CSS, but the HTML heading levels (h1 to h6) should be used accordingly and correctly.
  • Similar/equal-ranking elements that visually resemble a list should also be programmatically marked as lists, as unordered lists (ul) or ordered lists (ol), as well as the list elements in it (li). This applies to both vertically arranged elements and horizontally arranged elements (e.g. often found in navigation bars).
  • Tables should also be programmatically marked as such. Important here is the use of table headers (th), both horizontally and vertically. More complex tables can also be implemented using scope and header¬attributes. However, it should be considered here whether dividing a complex table into several simpler tables would not make more sense.
  • Form elements should either be labelled directly or correctly linked to a label (see also criterion 4.1.2).
  • Regions of the site should be labeled, either with the appropriate HTML5 tags or with the role attribute.
Why and for whom is the criterion important?

Blind users depend on a correct programmatic labeling of the website and its elements in order to understand the website and its contents. If the headline structure is not properly excellent, the structure and structure of a website is hardly understandable. The same goes for lists. If tables are not labeled correctly and input fields or controls are not labeled correctly, they are de facto inaccessible.

What are the most common errors in this criterion and how can they be corrected or avoided?
Heading hierarchy is not structured correctly or is missing:

In general, the programmatically determinable heading hierarchy (h1 to h6) should correspond to the visual and logical. The main heading (h1) should correspond to the page title, all other headings (h2 to h6) should reflect the visual and logical structure of the website. No heading levels may be omitted. Same-level headings should be labeled with the same level, direct child elements with a level below them, direct parent elements with a level above them.

Structuring is visually present, but not marked:

In addition to headings, lists, paragraphs or tables are often visually recognizable as such, but not correctly marked. Thus, this structural information assistive technologies is not available.

Labels for input fields or controls are not correctly marked, are not identified as such, or labels and elements are not correspondingly linked in the source code:

The correct implementation guarantees that the purpose of the input fields or controls is comprehensible for blind users.

Regions of the sites are not marked:

Very frequently used and particularly helpful are navigation regions, main, header and footer. This facilitates orientation and navigation on the website. Either HTML5 or the ARIA role attribute can be used here. Currently, it is even best to use both at the same time, as different screen reader-browser combinations can master different forms of annotation. Here is a list:

Vereinfachte Darstellung des Aufbaus einer typischen WebSeite, mit schriftlich bezeichneten aria-Regionen. Oben 'banner', mittig dreigeteilt von links nach rechts 'navigation', 'main' (mit 'article', 'application' und 'section') und 'complementary' (mit 'form'). Unten 'contentinfo'.

HTML 5 ARIA Role
<header> role=„banner“
<nav> role=„navigation“
<main> role=„main“
<footer> role=„contentinfo“
<aside> role=„complementary“
<section> role=„region“
Further information

Non-text content (WCAG criterion 1.1.1)
What does the criterion mean?
  • Non-text content requires a textual alternative. Text alternatives are an important way to make information available to everyone, as they can be reproduced for different senses (e.g. visual, acoustic or tactile). Graphic elements should be e.g. provide an alternative text.
  • In the case of images, the alternative text should briefly and concisely reflect the relevant information that is to be conveyed with this image.
  • Logos should indicate the name of the company or institution.
  • In the case of links, the purpose of the link – i.e. where the link leads – should be specified.
  • For purely decorative elements that do not transport information for users, these should be designed in such a way that they are ignored by assistive technologies. For example, in the case of an empty alternative text (alt=„“), it is clear to screen readers for example that the element can be skipped.
Why and for whom is the criterion important?

Blind users are dependent, for example, on alternative texts for information-supporting visual elements (graphics, images, graphical controls, etc.). Audio content, for example, requires for example a textual
Alternative for deaf users. This gives all users as much information as possible about non-text elements.

What are the most common errors in this criterion and how can they be corrected or avoided?
An image or logo has no alternative text:

If an image or logo has no alternative text, it can be added with alt=‘Description of the image’. For example, decorative images can be marked as ignorable with alt=„“ for assistive technologies.

An image or logo has no meaningful alternative text:

The description should be meaningful, but still as short and concise as possible. Only the information that is important in the current context should be conveyed. This means that it is not necessary to describe purely visual details on the image, but rather the basic message of the image or image or the information conveyed through the image. For example: A portrait of a middle-aged woman with black hair and red glasses:

  • In the context of a ‘profile’ in the About page of a company, the name and position would probably be appropriate.
  • In the context of a website of a hair salon, where the photo advertises a haircut, the name of the person is irrelevant, rather, the hairstyle should be described in more detail.

For images or icons that serve as links, the primary purpose of the link should be described so that it is clear where to go when the link is selected.

A decorative image has a non-empty alternative text:

Background images or other images that have a purely decorative purpose (e.g. an article with a generic stock image that is not meaningful in itself, with a title, a description and a link below it) should be marked as ignorable for assistive technologies (e.g. with an empty alternative text). This increases usability for screen reader users and prevents unnecessary or redundant information from being communicated.

Further information

Name, role, value (WCAG criterion 4.1.2)
What does the criterion mean?

Interactive elements should include programmatic names, roles and values (if applicable, e.g. for a checkbox: ‘selected’ or ‘not selected’).

Why and for whom is the criterion important?

Standard HTML controls, such as links or buttons, have a name and role. Some controls also have values or states such as input fields or checkboxes. These properties are accessible to blind people via a screen reader – that is, they are told what they can do with the control. An example: A checkbox in a form is called ‘I would like to subscribe to the newsletter’. The role is that it's a checkbox. The value is ‘unchecked’ if it has not yet been selected. If the value is ‘checked’, this means that the checkbox is selected.

For standard HTML elements, this information is automatically supplied for screen readers. If elements not intended for this purpose (such as the div or span element) are repurposed using JavaScript and CSS to mimic the appearance and function of controls, they must be enriched with WAI-ARIA so that these properties can also be used by screenreader users. This also applies to components such as tab panels, accordions, sliders, etc. For blind users, the function of these elements is otherwise not comprehensible. If the states or for example values are also not available, they are also not operable.

What are the most common errors in this criterion and how can they be corrected or avoided?
Control (e.g. buttons, input fields, etc.) do not have a programmatically comprehensible label (no name):

Without appropriate labels, the function of controls for screen reader users is not communicated accordingly. Labels should be mentioned here, depending on the control type. In most controls, labels can either be linked (label tag and for attribute or aria-labelledby) or directly defined (aria-label).
See also: Web accessibility tutorials: Labeling Controls (external link)

Buttons (and other controls) are not labeled as such:

This occurs when inappropriate HTML elements (e.g. div or span elements) are used as controls. In order to avoid this, the semantic HTML elements intended for the corresponding controls (e.g. button etc. ). If this is not possible, improve with ARIA-roles and define the function above. Pay attention to the correct use of WAI-ARIA.
See also: WAI-ARIA Roles (external link)

Link does not have a programmatically detectable link label (no name):

Links must have a programmatically comprehensible (textual) label indicating the purpose of the link. This is especially important for image or icon links, so that screen reader users can communicate where these links lead. The title attribute should not be used, which is not intended for the link purpose, but for additional information. Use the link text, which is the text that the a tag encloses. If you do not want this text to be visible visually, it can be encapsulated in a span element and hidden using CSS (do not use ‘display:none’, as this also hides the text for screen reader users).
See also: CSS in action: Invisible Content Just for Screen Reader Users (external link)

Example of an icon link:

  • Icon: FFG logo
  • Span with sr-only class: FFG – Österreichische Forschungs­förderungs­gesellschaft
  • Title: Opens a new browser window
IFrame has no name (e.g. no title attribute):

IFrames need a name (e.g. by means of title attribute) in order for their purpose to be communicated to screen reader users and they can then decide whether they want to navigate to or skip the contents of the iFrame. The name should briefly describe the content of the iFrame. Example: ‘Youtube Video: Interview with Ms XYZ’.

Further information

Contrasts of texts (WCAG criterion 1.4.3)
What does the criterion mean?
  • All texts on the website should have sufficient contrast values to the respective background:
  • for normal font (less than 18 pt for normal font thickness or less than 14 pt for bold font), the contrast ratio shall be 4.5:1;
  • for large font (18 pt or greater for normal font thickness or 14 pt or greater for bold font) the contrast ratio is 3:1

Excluded are logos (no other icons) that contain texts.

Why and for whom is the criterion important?

A sufficient contrast is important for people with different visual impairments, including color blindness and color weakness. Also for users who access websites or apps in suboptimal lighting conditions – e.g. on a smartphone in direct sunlight – a corresponding contrast ratio between text and background ensures usability.

What are the most common errors in this criterion and how can they be corrected or avoided?
Contrast values are too low

Low contrast values can be easily detected using tools such as the Colour Contrast Analyser (external link). Font color and/or background color can be adjusted to achieve the appropriate contrast ratio of 4.5:1 or 3:1.

Further information

Conclusive order in the Keyboard operation (WCAG criterion 2.4.3)
What does the criterion mean?

When users use a website or app with the keyboard, the order in which they reach information (links, form elements, etc.) by means of the tab key must be conclusive and comprehensible.

Why and for whom is the criterion important?

For users who navigate the keyboard in turn and do not use a mouse, it is essential that they reach content in a meaningfully comprehensible order. This can affect people with motor disabilities or blind people who use the web with screen readers and keyboard navigation. For this target group, the focus order is essential, for example, when filling out an online form. For users who use strong magnifications due to a visual impairment, it is also important that the focus does not jump to an unexpected place when navigating.

What are the most common errors in this criterion and how can they be corrected or avoided?
Concealed content is focused on:

Content created by an overlay (e.g. menu) are covered and therefore not visible, can still be controlled with the keyboard. Disabled buttons or elements that have no function (anymore) and are visually hidden occur in the focus order. These should also be removed from the focus order.

Focus is in an unexpected place:

The focus is placed in a place that is not expected, e.g.

  • When a page is called up, the focus is set to an interactive element at the bottom of the page. In most cases, the focus should be at the beginning of the page, otherwise the overview for screen reader users will be difficult or keyboard users will have to navigate cumbersomely.
  • When closing a dialog, the focus is not set to the trigger of the dialog again, but to a different location on the page. Here, especially for screen reader users, it is very difficult to understand where they are on the page.
  • When activating a skip link or table of contents link, only the visual viewport moved to the accessed content. The focus remains on the originally activated link and it is not comprehensible, especially for screen reader users, what happened. The focus should be programmatically set to the target element.
The order of the focused elements does not make sense:

The first time you visit a website, a cookie dialog or cookie¬banner appears. This should be the first to get the focus so that users can make their cookie settings. In many cases, the focus only jumps to the cookie dialog or banner at the end of the page content, because the dialog in the source code of the website is at the end. Or there are buttons in front of the corresponding content, for example a ‘Search’ button in front of the input option of various search options. The button should come only after the options.

Dialog or window is open, but the focus is not on:

An input window opens, but the focus is still outside the window. For screen reader users, it is difficult to understand that content is available in the open window.

Further information
https://monitoringbericht2024.digitalbarrierefrei.at/en/qualitative-evaluations