[ndeshev]

• Extracted reusable SliderHandle and SliderScale components from
  RangeSlider for better modularity and code reuse with Slider
• Refactored RangeSliderTemplate to use composition with the new
  sub-components instead of inline markup
• Added progress bar ARIA and focus properties to SliderScale to support
  RangeSlider's range selection feature
• Consolidated and cleaned up CSS theme parameters across all themes
  (Horizon, Fiori 3, HCB/HCW variants)
• Removed aria-keyshortcuts attributes from the handles to avoid duplicated speech output
• Removed the wrong aria-describedby references
• Fixes various minor issues

JIRA: BGSOFUIRILA-4268
FIXES: #13348

[ui5-webcomponents-bot]

🧹 Preview deployment cleaned up: https://pr-13316--ui5-webcomponents.netlify.app

[nikoletavnv]

There is an issue when you click on the slider track and both start and end handle get selected and you try to move the handles using Arrow Left and Arrow Right.

1. Go to the sample "Range Slider with steps, input tooltips, tickmarks and labels" in the RangeSlider.html page
2. Move the start and end handle to some values - e.g. 8 and 22.
3. Select the track somewhere in between to focus the whole range progress
4. Try to move the range progress using Arrow Left and Arrow Right keys

Most of the times the range does not move.

5. Sometimes when you move the range with the mouse and try again to move it with Arrow Left and Right it starts to work, but I can't find a pattern to reproduce the working path consistently

[nikoletavnv]

The range slider has unexpected behavior when configured in the following way:
<ui5-range-slider id="edge-with-features" min="0" max="0" start-value="0" end-value="0" show-tooltip="" show-tickmarks="" ui5-range-slider="" step="1" label-interval="0" value="0" tooltip-start-value="" tooltip-end-value="0" tooltip-start-value-state="None" tooltip-end-value-state="None" _labels-overlapping=""></ui5-range-slider>

Even though the min and max values are set to 0 , step>=1 is creating one tickmark in the middle. I would expect no tickmark to be created in case min and max values match.

[nikoletavnv]

Keyboard increase and decrease of slider start value: when the start handle reaches the end handle it goes "behind" it and the focus is visually lost. On decrease the start goes "in front of" the end handle and the focus is visible. The same happens with the end slider when increasing - it hides behind the start slider and focus is visually lost.

Screen.Recording.2026-04-20.100848.mp4

[nikoletavnv]

HOME and END buttons - if focus is on the whole range - the range is not moved to start / end position as by spec.

[nikoletavnv]

When focus is on the input (in case of editbale tooltip) the Figma specs mention that DEL deletes the whole value in the input. We can double check with the design if this is the desired behavior, because the input text is not "selected" when we focus it by pressing F2

[nikoletavnv]

By Figma spec - if a handle is focused, pressing a number on the keyboard (or several numbers in a short time interval) should move the handle to that position ( if applicable ) on the scale.

[nikoletavnv]

JAWS:

• When focus is on the end-handle , after the reader announces the current value, min and max and what to do to change the value, there is announcement "F2" at the end. It is only announced for the end-handle and not the start handle. The difference is that the end handle has aria-keyshortcuts="F2" attribute which is not present in the start handle element.
  In case the tooltip is not editable should we have this attribute at all? Also when tooltip is editable there is a separate announcement that informs the users that they should press F2 to focus the input and again at the end "F2" is announced.
• By Figma spec there should be announcements for disabled range slider. BUT the disabled slider is not not focusable at all. I think the specs should be modified.

[ndeshev]

The range slider has unexpected behavior when configured in the following way: <ui5-range-slider id="edge-with-features" min="0" max="0" start-value="0" end-value="0" show-tooltip="" show-tickmarks="" ui5-range-slider="" step="1" label-interval="0" value="0" tooltip-start-value="" tooltip-end-value="0" tooltip-start-value-state="None" tooltip-end-value-state="None" _labels-overlapping=""></ui5-range-slider>

Even though the min and max values are set to 0 , step>=1 is creating one tickmark in the middle. I would expect no tickmark to be created in case min and max values match.

This is not a valid use case, apps should prevent it.

[ndeshev]

Keyboard increase and decrease of slider start value: when the start handle reaches the end handle it goes "behind" it and the focus is visually lost. On decrease the start goes "in front of" the end handle and the focus is visible. The same happens with the end slider when increasing - it hides behind the start slider and focus is visually lost.

Screen.Recording.2026-04-20.100848.mp4

this behavior is the same in the main branch, we should discuss it and eventually raise an issue

[ndeshev]

When focus is on the input (in case of editbale tooltip) the Figma specs mention that DEL deletes the whole value in the input. We can double check with the design if this is the desired behavior, because the input text is not "selected" when we focus it by pressing F2

We have never implemented that "feature", which by itself is a bit strange imo.

[ndeshev]

By Figma spec - if a handle is focused, pressing a number on the keyboard (or several numbers in a short time interval) should move the handle to that position ( if applicable ) on the scale.

Also not yet implemented.

[niyap]

Look at the second tooltip. It does not correspond to the step precision.

[ndeshev]

Look at the second tooltip. It does not correspond to the step precision.

fixed

[ndeshev]

Look at the second tooltip. It does not correspond to the step precision.

fixed

[niyap]

Thanks for your patience! Now, everything looks correct :)

Comments are applied