vaadin · Artur- · Jun 12, 2026
diff --git a/articles/components/_input-field-common-features.adoc b/articles/components/_input-field-common-features.adoc
@@ -262,6 +262,13 @@ The following style variants can be applied:
 
 // end::small-variant[]
 
+// tag::filled-variant[]
+|[since:com.vaadin:vaadin@V25.2]#`filled`#
+|Uses a solid background color for hovered and active items in the overlay
+|Aura
+
+// end::filled-variant[]
+
 // tag::helper-above-field[]
 |`helper-above-field`
 |Renders the helper above the field, and below the label

diff --git a/articles/components/combo-box/styling.adoc b/articles/components/combo-box/styling.adoc
@@ -10,7 +10,7 @@ order: 50
 
 // Style Variants
 
-include::{articles}/components/_input-field-common-features.adoc[tags=styles-start;text-alignment;small-variant;helper-above-field;styles-end]
+include::{articles}/components/_input-field-common-features.adoc[tags=styles-start;text-alignment;small-variant;filled-variant;helper-above-field;styles-end]
 
 [.example,themes="lumo,aura"]
 --

diff --git a/articles/components/menu-bar/styling.adoc b/articles/components/menu-bar/styling.adoc
@@ -51,6 +51,10 @@ The following variants are supported by the Menu Bar:
 |Used to align buttons to the end of the menu bar
 |Aura, Lumo
 
+|[since:com.vaadin:vaadin@V25.2]#`filled`#
+|Uses a solid background color for hovered and active menu items
+|Aura
+
 |===
 
 

diff --git a/articles/components/multi-select-combo-box/styling.adoc b/articles/components/multi-select-combo-box/styling.adoc
@@ -9,7 +9,7 @@ order: 50
 
 // Style Variants
 
-include::{articles}/components/_input-field-common-features.adoc[tags=styles-start;small-variant;helper-above-field;styles-end]
+include::{articles}/components/_input-field-common-features.adoc[tags=styles-start;small-variant;filled-variant;helper-above-field;styles-end]
 
 
 include::../_styling-section-theming-props.adoc[tag=style-properties]

diff --git a/articles/components/popover/index.adoc b/articles/components/popover/index.adoc
@@ -205,6 +205,38 @@ popover.setAutofocus(true);
 --
 
 
+[role="since:com.vaadin:vaadin@V25.2"]
+=== Tab Focus
+
+By default, the popover's content can be reached with kbd:[Tab] from its target element. This can be disabled, so that pressing kbd:[Tab] on the target skips past the popover, and kbd:[Shift+Tab] doesn't move focus into the popover's last focusable element. Focus placed inside the popover programmatically still moves out of it on kbd:[Tab] and kbd:[Shift+Tab].
+
+This setting has no effect on modal popovers, which use their own focus trap.
+
+[.example.show-code]
+--
+
+[source,java]
+----
+<source-info group="Flow"></source-info>
+Popover popover = new Popover();
+popover.setTabFocusEnabled(false);
+----
+
+[source,html]
+----
+<source-info group="Lit"></source-info>
+<vaadin-popover no-tab-focus></vaadin-popover>
+----
+
+[source,tsx]
+----
+<source-info group="React"></source-info>
+<Popover noTabFocus />
+----
+
+--
+
+
 == Positioning
 
 By default, popovers open below their target element, horizontally centered to its midpoint, but the positioning options allow this to be changed to any edge or corner, depending on what is most appropriate for the use case.

diff --git a/articles/components/select/styling.adoc b/articles/components/select/styling.adoc
@@ -9,7 +9,7 @@ order: 50
 
 // Style Variants
 
-include::{articles}/components/_input-field-common-features.adoc[tags=styles-start;text-alignment;small-variant;helper-above-field;styles-end]
+include::{articles}/components/_input-field-common-features.adoc[tags=styles-start;text-alignment;small-variant;filled-variant;helper-above-field;styles-end]
 
 [.example,themes="lumo,aura"]
 --

diff --git a/articles/components/tabs/styling.adoc b/articles/components/tabs/styling.adoc
@@ -25,7 +25,7 @@ The following variants are supported by the Tabs:
 
 |`small`
 |Reduces the size of tabs
-|Lumo
+|[since:com.vaadin:vaadin@V25.2]#Aura#, Lumo
 
 |`minimal`
 |Reduces visual styles to a minimum
@@ -169,7 +169,7 @@ You can generally use this to reduce visual clutter. However, use it with cautio
 
 The `small` variant can be used to make the Tabs smaller. This can be good when space is limited. Compare the tabs here to previous ones. You can see these are slightly smaller.
 
-[.example]
+[.example,themes="lumo,aura"]
 --
 
 ifdef::lit[]

diff --git a/articles/components/time-picker/styling.adoc b/articles/components/time-picker/styling.adoc
@@ -9,7 +9,7 @@ order: 50
 
 // Style Variants
 
-include::{articles}/components/_input-field-common-features.adoc[tags=styles-start;text-alignment;small-variant;helper-above-field;styles-end]
+include::{articles}/components/_input-field-common-features.adoc[tags=styles-start;text-alignment;small-variant;filled-variant;helper-above-field;styles-end]
 
 [.example,themes="lumo,aura"]
 --

diff --git a/articles/components/tooltip/index.adoc b/articles/components/tooltip/index.adoc
@@ -261,7 +261,7 @@ Likewise, any interactive content such as links may not be accessible. For more
 
 == Accessibility
 
-Tooltips are semantically associated with their target elements using the link:https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-describedby[`aria-describedby`] attribute, and are announced by screen readers when the element gains keyboard focus.
+Tooltips are semantically associated with their target elements by default using the link:https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-describedby[`aria-describedby`] attribute, and are announced by screen readers when the element gains keyboard focus.
 
 However, tooltips on elements without dedicated tooltip APIs can't be guaranteed to be announced correctly. This is because the announcement of `aria-describedby` attributes depends on the HTML element's type and the `role` attribute. It also varies between different screen readers. Testing with screen readers is useful to ensure the accessibility of tooltips on these elements.
 
@@ -272,6 +272,62 @@ Keep in mind that Vaadin components and other UI elements don't, by default, imp
 In general, visible labels are always preferable to tooltips. A separately defined invisible link:https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-label[`aria-label`] attribute usually provides better accessibility than a tooltip.
 
 
+[role="since:com.vaadin:vaadin@V25.2"]
+=== ARIA Link Mode
+
+The ARIA attribute used to associate the tooltip with its target element can be configured. The following modes are available:
+
+`aria-describedby`::
+Links the tooltip as a _description_ of the target. This is the default mode, and the appropriate one when the tooltip provides supplementary information about an element that already has an accessible name, such as a labeled input field.
+
+`aria-labelledby`::
+Links the tooltip as the _accessible name_ of the target. Use this mode when the tooltip text acts as the target's label, such as on icon-only buttons that have no visible label or `aria-label` of their own.
+
+`none`::
+Doesn't apply any ARIA attribute to the target. Use this mode when the tooltip content is already exposed to assistive technologies by other means, to avoid redundant announcements.
+
+[.example]
+--
+ifdef::flow[]
+[source,java]
+----
+<source-info group="Flow"></source-info>
+// For components that implement HasTooltip:
+button.setTooltipText("Search");
+button.getTooltip().setAriaLinkMode(Tooltip.AriaLinkMode.ARIA_LABELLED_BY);
+
+// For other components:
+Tooltip.forComponent(icon)
+        .withText("Search")
+        .withAriaLinkMode(Tooltip.AriaLinkMode.ARIA_LABELLED_BY);
+----
+endif::[]
+
+ifdef::lit[]
+[source,html]
+----
+<source-info group="Lit"></source-info>
+<vaadin-button theme="icon">
+  <vaadin-icon icon="vaadin:search"></vaadin-icon>
+  <vaadin-tooltip slot="tooltip" text="Search" aria-link-mode="aria-labelledby"></vaadin-tooltip>
+</vaadin-button>
+----
+endif::[]
+
+ifdef::react[]
+[source,tsx]
+----
+<source-info group="React"></source-info>
+<Button theme="icon">
+  <Icon icon="vaadin:search" />
+  <Tooltip slot="tooltip" text="Search" ariaLinkMode="aria-labelledby" />
+</Button>
+----
+endif::[]
+
+--
+
+
 == Best Practices
 
 Tooltips should be used only to provide additional information, not for mission-critical information. They're not a replacement for visible labels on input fields.

diff --git a/articles/upgrading/index.adoc b/articles/upgrading/index.adoc
@@ -421,6 +421,9 @@ Note that `theme.json` and shadow-DOM styling of components through the `compone
 
 == Components
 
+=== Accordion
+Starting with Vaadin 25.2, attaching an [classname]`Accordion` to the UI no longer fires an initial [classname]`OpenedChangeEvent`. In addition, [methodname]`isFromClient()` on the event now correctly returns `false` for changes made from server-side code; previously, it always returned `true`. Adjust any listeners that rely on receiving an event when the component is attached, or that use [methodname]`isFromClient()` to distinguish user-initiated changes.
+
 === App Layout
 The `bottom` attribute was removed and can no longer be used to target the bottom navbar. Instead, use the selector `::part(navbar-bottom)` to target it with CSS.