What are the most common errors with ARIA labels on websites?

The most common ARIA errors on websites include missing or incorrectly set ARIA labels, incorrectly used roles, redundant ARIA attributes on semantically correct HTML elements, and conflicting labels resulting from the simultaneous use of aria-label and visible text. These errors often arise because ARIA attributes are used without a sufficient understanding of the underlying specification. The following article answers the most important questions about ARIA errors, their causes, and how you can systematically identify and rectify them.

Which ARIA errors occur most frequently on websites?

The most common ARIA errors on websites are empty aria-labelattributes, missing required attributes for ARIA roles, incorrectly nested ARIA landmark regions, and the use of aria-hidden=‘true’on focusable elements. Added to this is the unnecessary assignment of ARIA roles to elements that already carry native semantic meaning.

In practice, developers and accessibility testers encounter the following types of errors particularly frequently:

• Empty or meaningless labels: An aria-label=‘’ with no content or a label such as ‘Button’ or ‘Link’ provides no useful information to screen reader users.
• Missing required attributes: Certain ARIA roles such as role=‘combobox’ or role=‘slider’ require specific state attributes (e.g. aria-expanded, aria-valuenow). If these are missing, the element behaves unpredictably for assistive technologies.
• aria-hidden on focusable elements: If an element with aria-hidden=‘true’ is still accessible via the keyboard, it is skipped by screen readers but remains visible when in focus. This creates what is known as a ‘focus trap’.
• Duplicate landmark areas: Multiple <main> elements or multiple role=‘banner’ areas without unique labels confuse navigation for screen reader users.
• Redundant ARIA roles: Assigning an additional role=‘button’to a <button>element is not harmful, but it is unnecessary and indicates a misunderstanding of the ARIA specification.

In many cases, these errors can be identified by automated accessibility scans, although a comprehensive manual review remains necessary as a supplementary measure.

Why do incorrect ARIA labels lead to accessibility issues?

Incorrect ARIA labels lead to accessibility issues because screen readers and other assistive technologies rely exclusively on the information provided programmatically. For these users, an incorrect or missing label means that an element is either not described at all or is described in a misleading way, which significantly restricts or prevents them from using a website independently.

Sighted users can use visual cues such as colour, position and shape to recognise an element’s function. For screen reader users, these cues do not exist. Instead, they are read the text content or the ARIA label of an element. If this label is empty, generic or misleading, they lose the context and cannot interact with the element effectively.

A concrete example: an icon button with no visible text, to which no aria-label has been assigned, may be announced by a screen reader simply as ‘button’ or not at all. The user does not know whether this will submit a form, open a menu or delete a file. Such ambiguities are not a marginal issue, but represent real barriers to use.

Furthermore, contradictory labels can arise when visible text and aria-label convey different information. Screen readers usually read out the aria-label first and ignore the visible text. This can lead to sighted and visually impaired users perceiving the same element differently, making the user experience inconsistent and prone to errors.

What is the difference between `aria-label`, `aria-labelledby` and `aria-describedby`?

The difference lies in the source and function: `aria-label` defines a direct text label within the attribute itself, `aria-labelledby` refers to an existing visible element as the source of the label, and `aria-describedby` provides a supplementary description that is read aloud in addition to the main label.

aria-label: direct text label

aria-label=‘Search field’ directly assigns a name to an element, which is stored exclusively within the attribute. This attribute is suitable for elements without visible text, such as icon buttons or form fields without a visible label. The disadvantage is that the label is not visible in the DOM and therefore cannot be perceived by screen readers or sighted users.

aria-labelledby: reference to existing text

aria-labelledby references the ID of another element, whose text content is used as the name of the current element. The advantage of this is that the name is available both visually and to assistive technologies. Typical use: dialogues labelled by a visible heading (aria-labelledby=‘dialog-title’).

aria-describedby: supplementary description

aria-describedbyalso refers to another element, but provides not a primary label, but an additional description. Screen readers read out this information after the element’s primary name, often with a short pause. Typical use: tooltips for form fields, error messages or supplementary explanations for complex controls.

How can ARIA errors on a website be systematically identified?

ARIA errors can be systematically identified through a combination of automated tests, manual screen reader checks and code analysis. No single approach covers all types of errors, but a structured process following this sequence is practical for most websites.

The first step is an automated scan using an accessibility testing tool. Automated tests reliably detect structural ARIA errors such as empty labels, missing required attributes or invalid roles. Studies and practical experience suggest that automated tests can identify around 30 to 50 per cent of all accessibility issues. This is a solid starting point, but is not sufficient for a comprehensive audit.

The second step should be a manual audit using a screen reader.

During this process, you navigate the website exclusively using the keyboard and a screen reader (e.g. NVDA on Windows or VoiceOver on macOS) and check whether labels are read out clearly, whether the focus order and visibility are correct, and whether interactive elements clearly communicate their purpose.

It is also worth carrying out a direct code inspection using the browser’s developer tools. The Accessibility tab in Chrome DevTools displays the computed name and role of each element and highlights discrepancies between the visual appearance and the programmatic labelling.

For teams that monitor multiple websites on an ongoing basis, continuous automated monitoring is advisable. Changes to the code can introduce new ARIA errors at any time, which would go unnoticed without regular scans.

Which ARIA errors breach WCAG, BITV or BFSG?

ARIA errors breach WCAG success criteria in the areas of perceivability and operability, in particular criteria 4.1.2 (Name, Role, Value) and 1.3.1 (Information and Relationships). As the BITV and BFSG are based on the WCAG standards, these requirements also apply within the German legal framework.

Specifically, this means:

• WCAG 4.1.2 (Level A): All user interface components must have a programme-determinable name and role. Missing or empty aria-labelattributes on interactive elements directly breach this criterion.
• WCAG 1.3.1 (Level A): Information, structure and relationships must be programme-determinable. Incorrectly nested ARIA landmarks or missing role specifications breach this criterion.
• WCAG 2.1.1 (Level A): All functions must be operable via the keyboard. aria-hidden=‘true’ on focusable elements results in keyboard traps that breach this criterion.
• WCAG 1.4.3 / 1.4.11 (Level AA): Contrast requirements that become indirectly relevant when ARIA labels on non-visible elements are the sole source of information.

Under the Accessibility Enhancement Act (BFSG), which will apply to many digital products and services from 2025, these WCAG criteria are legally binding. An automated accessibility check can help to identify any such breaches at an early stage. However, automated testing alone cannot conclusively determine whether a website fully complies with the legal requirements. This requires a supplementary manual review and, in cases of doubt, legal advice.

When should ARIA be used, and when is it better not to?

The first rule of the ARIA specification is: do not use ARIA if native HTML is sufficient. ARIA should only be used when a control or structure cannot be adequately described using standard HTML elements. In all other cases, native HTML is the better choice because it is interpreted more reliably by browsers and assistive technologies.

Using ARIA sensibly:

• Custom widgets without an HTML equivalent, e.g. tabs, accordions, date pickers or modal dialogues
• Icon buttons without visible text that require an aria-label

Dynamically updated content intended to inform screen reader users via

aria-live

• Complex form structures where visible labels and fields must be linked programmatically

Avoid ARIA if:

• A native HTML element serves the same purpose: <button> instead of <div role="button">, <nav> instead of <div role="navigation">
• ARIA attributes override the visible text, thereby creating inconsistencies
• The ARIA role does not match the element’s actual behaviour

A common misconception is that more ARIA automatically means greater accessibility. The opposite is often the case: incorrectly used ARIA can actively impair a website’s accessibility because it overrides correct native semantics or generates conflicting information for assistive technologies.

How decareto helps detect ARIA errors

Here at decareto, we have developed a SaaS platform that automatically scans websites for accessibility issues, including common ARIA errors. Our tool checks subpages, identifies issues in accordance with WCAG, BITV and BFSG, and provides specific recommendations for action so that you can address them in a targeted and efficient manner.

What decareto specifically offers:

• Automated detection of ARIA errors such as empty labels, missing required attributes and invalid roles on all scanned subpages
• Prioritisation by severity, so you can tackle critical issues first
• Structured reports with HTML code and CSS selectors for the affected elements, enabling developers to locate errors directly in the source code
• Ongoing monitoring with automatic notifications when new accessibility issues arise due to code changes
• Manual logging of issues that cannot be detected automatically, directly within the report
• White-label functionality for agencies and law firms that pass on reports to clients under their own logo

Please note: Automated tests typically cover 30 to 50 per cent of all accessibility issues. A good scan result does not mean that no further barriers exist. For a comprehensive check, we recommend supplementary manual testing. Try decareto and check your website for ARIA errors and other accessibility issues: Get started for free now.