UI5 Web Components v2.26.0-rc.0: Check DatePicker Width and Input Accessibility

Sara Kim breaks down what you need to know

If you maintain any UI5 Web Components outside the standard Fiori launchpad, set aside some time this week to validate your date pickers and input fields. The v2.26.0-rc.0 release looks like routine housekeeping, but two of the changes touch areas that quietly break when you least expect it: input geometry and form association. Since this is a release candidate, the goal is not to deploy it blindly. It’s to run targeted regression tests before the stable release catches your team off guard.

What Actually Changed

The release notes list three fixes that matter for day-to-day development:

• ui5-date-picker input width was corrected for cases where the internal input did not fill the expected control width.
• ui5-input value state message no longer exposes role="dialog" on the validation message container.
• Form lookup now uses the element root node, which impacts how ui5-input finds its associated form when embedded in custom elements or shadow DOM.

Let’s unpack each one.

DatePicker Width Fix

The bug fix is straightforward: some implementations of ui5-date-picker rendered the inner input at an incorrect width, especially when placed inside a grid, flex container, or custom form layout. You might have noticed a date picker that looked narrower than its sibling inputs, even when all of them used the same CSS width. The fix should normalize that.

But here’s the catch: width fixes often depend on the control’s display mode, valueState presence, or whether a valueStateMessage slot is populated. If your team applied workaround CSS to force the date picker wider—say min-width: 220px or width: 100% !important—that workaround may now fight the corrected internal layout. I’ve seen this many times in reusable component libraries: a temporary style survives long after the root cause is patched.

Input Value State Message Accessibility

This one matters if you rely on automated accessibility tests or screen reader behavior. The container that displays validation messages for ui5-input no longer has role="dialog". That role never really belonged on an inline validation message. A dialog implies modal behavior, focus management, and a separate interaction context. Removing it is a step in the right direction.

However, accessibility changes are never just technical. If your test suite asserts that the value state message container has role="dialog", that assertion will fail after upgrading. More importantly, if your design system documented the old role for screen reader users, update that documentation. Screen reader users may now hear the message announced differently, or they may not hear it announced at all unless aria-describedby or aria-live is properly wired to the input. Test this with an actual screen reader, not just a DOM snapshot.

Form Lookup Uses Element Root Node

This is the most impactful change for teams building custom wrappers around ui5-input. Previously, the hidden input that handles form submission might have been discovered by searching from the document level. The update changes that lookup to start from the element’s root node.

Why does that matter? If you wrap ui5-input inside a custom element with Shadow DOM, the hidden input’s relationship to an outer <form> can break or start working depending on how the browser resolves form-association. If your custom element is not itself form-associated, the input’s form participation often relies on a hidden input being in the same DOM scope as the form. Root-node lookup can fix cases where the input was not being submitted, but it can also alter behavior if your component assumed document-level discovery.

What This Means for You

The main risk here is not the fixes themselves. It’s that teams treat a release candidate as a stable patch and skip regression testing.

If you are responsible for a custom design system or a set of reusable UI5 Web Components, you likely have existing tests for form submission, validation message rendering, and layout consistency. Run those tests against v2.26.0-rc.0 now, not after stable GA.

For date picker usage, pay attention to forms where the date picker sits inside a fixed-width container. A width fix can reveal incorrect CSS assumptions. For example:

<ui5-date-picker id="startDate" style="width: 100%;"></ui5-date-picker>

If the input inside #startDate previously did not fill the container, your team may have added a min-width to compensate. After upgrading, verify the actual rendered width. If your workaround still applies, the date picker may now overflow or misalign with adjacent fields.

For accessibility, update any visual regression or a11y snapshots that assert role="dialog" on the value state message. The new behavior should be cleaner, but you need to confirm that the input still references the message correctly. Check the following after upgrading:

• Does the input maintain aria-describedby pointing to the value state message?
• Is the message announced when focus returns to the input?
• Does the removed role="dialog" affect any keyboard or focus expectations your team previously documented?

For form association, create a minimal test if you have custom element wrappers:

<form id="myForm" action="/submit">
  <my-input-field name="userName"></my-input-field>
</form>

Inside my-input-field, a shadow root may contain a ui5-input. After the update, check whether the submitted form data includes userName. If you relied on form.elements from JavaScript, verify that the element is still found. The root-node lookup change is the kind of thing that fixes one integration while subtly affecting another.

Action Items

• Upgrade to v2.26.0-rc.0 in a development or staging branch, not production.
• Run visual regression tests

References

• SAP/ui5-webcomponents: v2.26.0-rc.0- SAP Community Hub
• SAP News Center

References

• SAP News Center
• SAP Community Hub
• SAP/ui5-webcomponents: v2.26.0-rc.0