[Bug]: sp-number-field Increment/Decrement button labels

[jnurthen]

Code of conduct

• I agree to follow this project's code of conduct.

Impacted component(s)

sp-number-field

Expected behavior

The Number field increase/decrease buttons should use less technical and more specific text

We should use Increase/Decrease NOT Increment/Decrement
We should also use the number fields label as part of the text

So For

<sp-field-label for="units">Package width</sp-field-label>
<sp-number-field
    id="units"
    style="width: 200px"
    value="4"
    format-options='{
        "style": "unit",
        "unit": "inch",
        "unitDisplay": "long"
    }'
></sp-number-field>

The buttons should be "Increase Package width" and "Decrease Package Width"

Actual behavior

Currently the buttons are labeled Increment/Decrement

Screenshots

No response

What browsers are you seeing the problem in?

Firefox, Chrome, Safari, Microsoft Edge

How can we reproduce this issue?

1. Go to https://opensource.adobe.com/spectrum-web-components/components/number-field/
2. Right Click on an increase/decrease button
3. Inspect the Accessible Name in the Accessibility tab of Dev Tools

Sample code that illustrates the problem

No response

Logs taken while reproducing problem

No response

[TarunAdobe]

In this case we have the label provided as "Package Width" so making the aria label as "Increase Package Width" or "Decrease Package Width" makes sense as we can just do a simple string concat however if the label was say "Choose Package Width" in that case the same aria-label value will become "Increase Choose Package Width" or "Decrease Choose Package Width" which would be weird. My point is having the aria label directly influenced by the label value might create such problems because users can put anything in the label (a sentence, a word, or a bunch of words)... Would love to know your thought son this!

[Westbrook]

I agree that an awkward label could be supplied, but I'd argue that an awkward label for the buttons is also an awkward label for the input, e.g. "Choose Package Width" implies that there are options rather than a free input field. In this way, I'd say attaching this label in multiple places would be a reasonable advance of the functionality that is being delivered today, while effecting no changes on the existing API surface.

If that felt not enough, then I'd suggest we look at this request in the context of #1975 wherein the need for internationalizing of small content pieces (like this secondary label) could be addressed in a more universal manner. The general move to an alternate API here would make expanding the Number Field API to support additional label content much less surprising.

[TarunAdobe]

Yes that made a lot of sense. Thank you for the clarifications. I'll attach the label and make a PR soon :)

[TarunAdobe]

Made a PR for this issue -> #3474

[Rajdeepc]

@jnurthen can you please test and let us know the outcome.