diff --git a/articles/components/_input-field-common-features.adoc b/articles/components/_input-field-common-features.adoc index efb3e3068f..e3c5054ab8 100644 --- 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 index 67924bfbc1..bd96b73a09 100644 --- 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 index 5f5a46003d..1ca3801b3d 100644 --- 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 index a923fcba35..2fa544adce 100644 --- 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 index e342728b94..0375abb34d 100644 --- 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] +---- + +Popover popover = new Popover(); +popover.setTabFocusEnabled(false); +---- + +[source,html] +---- + + +---- + +[source,tsx] +---- + + +---- + +-- + + == 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 index 5ee1883348..00e6fd2b3b 100644 --- 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 index 8fde546455..98fd0b698f 100644 --- 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 index 7c91bab822..bf18c4ec01 100644 --- 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 index e67bc8a34e..46d2aa3778 100644 --- 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] +---- + +// 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] +---- + + + + + +---- +endif::[] + +ifdef::react[] +[source,tsx] +---- + + +---- +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 index 9a152e7fd4..531b6cb684 100644 --- 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.