What accessibility requirements apply to tooltips and overlays?

Specific accessibility requirements from WCAG 2.2 apply to tooltips and overlays, ensuring that these elements are perceivable, operable and understandable for all users. This applies in particular to keyboard operability, the use of ARIA attributes and correct focus control. The following sections answer the most important questions on this topic.

Which WCAG criteria apply specifically to tooltips?

Tooltips are small information windows that provide additional explanations about an element. They typically appear when a user hovers the mouse over an element or when an element receives focus. They are covered by several WCAG criteria, most notably Success Criterion 1.4.13 (Content on Hover or Focus), which has been in force since WCAG 2.1. It stipulates that content which appears on hover or when the keyboard focus is acquired must remain permanently visible, be closable and be operable without the user having to leave the element that triggered it.

Specifically, WCAG 1.4.13 requires that tooltip content meets three conditions:

• Persistence: The tooltip remains visible as long as the user does not move the mouse pointer or keyboard focus.
• Closability: Users can close the tooltip without losing focus, for example by pressing the Escape key.
• Accessibility via the pointer: The tooltip itself must be accessible via the mouse without disappearing, as users of screen magnification software often need to move the mouse pointer over the tooltip to read it.

In addition, Success Criterion 4.1.3 (Status Messages) applies when a tooltip communicates status changes. Criterion 2.1.1 (Keyboard) is also relevant: all functions that can be accessed via the mouse must also be accessible via the keyboard. Tooltips that appear exclusively on hover and cannot be accessed via the keyboard breach this criterion. Anyone carrying out an accessibility audit should systematically check these criteria.

What are the most common accessibility errors with overlays?

Overlays are UI components (such as pop-ups, dialogue boxes or lightboxes) that appear over the main content of a page and typically require user interaction before the underlying content becomes accessible again.
The most common accessibility errors in overlays relate to a lack of focus control, missing ARIA attributes and the inability to close them using the keyboard. These issues make overlays inaccessible to screen reader users and to people who rely exclusively on the keyboard.

In practice, the following problems occur particularly frequently:

• Missing focus trap: When a modal overlay is opened, the keyboard focus must remain within the overlay.

• If this so-called ‘focus trap’ is missing, users can navigate behind the overlay without realising it and lose their bearings.
• No focus return: After closing an overlay, focus must return to the element that opened the overlay. If this return is missing, navigation becomes disorientating for keyboard users.
• Missing Escape functionality: Modal overlays must be closable using the Escape key. If this is not implemented, users without a mouse are trapped within an overlay.
• Background content remains readable for screen readers: With modal overlays, the background content must be hidden from screen readers, typically via aria-hidden=‘true’ on the main content.
• Inadequate contrast: Overlay content, particularly text on semi-transparent backgrounds, often falls short of the required contrast ratio of 4.5:1 for normal text.
• Missing close button: Overlays without a visible and semantically correct close button are unusable for many user groups.

How do the requirements for modal and non-modal overlays differ?

Modal overlays block interaction with the rest of the page content and therefore place significantly higher demands on focus control and ARIA implementation than non-modal overlays, which remain operable alongside the rest of the page.

Requirements for modal overlays

Modal dialogues, such as confirmation windows or cookie banners requiring mandatory interaction, require a complete focus trap. Keyboard focus must not leave the overlay whilst it is open. This means that the Tab and Shift+Tab keys must cycle focus within the overlay. The background content must be made invisible to screen readers using aria-hidden=‘true’. The overlay itself is assigned the dialog role and an accessible label via aria-labelledby or aria-label. When opened, focus is placed on the overlay or the first interactive element within it.

Requirements for non-modal overlays

Non-modal overlays, such as drop-down menus, information banners or sidebars, do not require a focus trap. Users should still be able to navigate freely around the page. However, certain requirements apply: the overlay must be accessible and closable via the keyboard, and focus must flow logically across the page. Non-modal dialogues are assigned the ARIA role dialog with the attribute aria-modal=‘false’ or, alternatively, other suitable roles such as status or alert, depending on the content.

Which ARIA attributes are required for tooltips and overlays?

For tooltips, role=‘tooltip’ in combination with aria-describedby is required on the triggering element. For overlays, different roles and attributes apply depending on the type, with role=‘dialog’ together with aria-labelledby and aria-modal being the key components for modal dialogues.

In detail, the following recommendations apply:

• Tooltips: The triggering element is assigned aria-describedby with the ID of the tooltip element. The tooltip element itself is assigned role=‘tooltip’. Tooltips should not solely convey visual information that is not accessible anywhere else.
• Modal dialogues: role=‘dialog’, aria-modal=“true”, aria-labelledby (refers to the dialogue’s heading) and, where applicable, aria-describedby for a description of the dialogue’s purpose.
• Alert dialogues: If a modal overlay contains a warning or error message that requires immediate attention, role=‘alertdialog’ is used.Non-modal notifications: Status messages that appear automatically are given role=‘status’ or role=‘alert’ so that screen readers read them out automatically.

Incorrectly used ARIA attributes can impair accessibility rather than improve it. The W3C’s WAI-ARIA Authoring Practices Guide provides detailed implementation examples for each of these pattern types.

How can the accessibility of tooltips and overlays be tested?

The accessibility of tooltips and overlays can be tested using a combination of automated tests and manual checks. Automated tools typically detect missing ARIA attributes and contrast issues, whilst manual tests cover keyboard navigability and screen reader output.

For a structured test, the following approach is recommended:

• Automated scan: An accessibility testing tool such as decareto checks the HTML code for missing ARIA attributes, contrast issues and structural errors. This step covers a significant proportion of technical errors – typically an estimated 30 to 50 per cent of all possible problems.
• Keyboard test: Navigate through the page using only the keyboard. Check whether tooltips can be accessed using the Tab key, whether overlays open correctly and can be closed using the Escape key, and whether focus returns to the correct position after closing.
• Screen reader test: Use a screen reader such as NVDA (Windows), JAWS or VoiceOver (macOS/iOS) to check whether tooltips and overlays are read out correctly and whether the ARIA attributes produce the expected output.
• Contrast check: Check that text within overlays has sufficient contrast ratios, particularly against semi-transparent backgrounds.

As not all accessibility issues can be detected automatically, manual testing is essential. However, automated tests provide a valuable initial assessment and help to quickly identify obvious errors before a time-consuming manual test is carried out.

Do these requirements also apply under the BFSG?

Yes, the requirements for tooltips and overlays also apply under the Accessibility Enhancement Act (BFSG). The BFSG, which has applied to many products and services in the private sector since June 2025, refers to the harmonised European standards, which in turn are based on the WCAG.

The BFSG transposes EU Directive 2019/882 (the European Accessibility Act) into German law. In practice, for websites and digital services, this means that compliance with WCAG 2.1 at Level AA is used as the benchmark. All the requirements described above regarding focus control, ARIA attributes and keyboard navigability are therefore also legally relevant.

Companies offering digital products or services in the B2C sector are particularly affected, including online shops, banking applications and booking portals. Public sector bodies have long been subject to EU Directive 2016/2102, which also requires WCAG compliance. The following applies to all those affected: tooltips and overlays are not peripheral issues in accessibility, but frequently used interaction patterns which, if implemented incorrectly, create significant barriers. A regular BITV audit helps to identify vulnerabilities at an early stage.

How decareto supports you in testing tooltips and overlays

At decareto, we offer automated accessibility software that systematically checks websites for accessibility issues, including typical errors in tooltips and overlays. Our platform helps agencies, compliance teams and data protection officers to significantly reduce the effort involved in testing and to document results in a traceable manner.

Specifically, decareto offers the following features:

• Automated accessibility scan based on axe-core, aligned with WCAG 2.1 and 2.2, BITV and BFSG, with detection of ARIA errors, contrast issues and structural HTML errors
• Prioritisation by severity, so that critical issues such as missing focus traps or overlays that cannot be closed are immediately identifiable
• Manual issue logging directly within the tool, to supplement and document findings from manual tests and screen reader checks
• Monitoring of hundreds of websites with automatic notifications of changes, ensuring that new accessibility barriers do not go unnoticed

Split reports with a white-label option for external service providers who wish to present results under their own logo

Would you like to check your website for accessibility whilst also systematically scrutinising tooltips and overlays? Get started for free now and carry out an initial scan.