[EuiFieldNumber] Default to step="any" and check native validity on blur

[cee-chen]

Summary

This PR is a follow-up to our existing EuiFieldNumber enhancement that added detection of native browser invalidity (#6741, 37c35ea).

Specifically, this PR is meant to address a comment left in a Kibana upgrade: elastic/kibana#155208 (comment).

Problem

Initially I thought the :invalid issue on EuiFieldNumbers intended for decimal usage was already a problem beforehand. As it turns out, it had not been a visual problem because

1. On blur, <input type="number">s with an undefined step update their validity status to accept the decimal as valid (default browser behavior). Screencap of said behavior:
   

2. Our :focus styles (blue underline) were taking precedence over the :invalid styles (red underline) and as such the invalid styling was never actually visible for decimal inputs. When we added the icon, the "invalid" state suddenly became visible. And then on blur, both focus and invalid styles would go away 💀

Solution

This PR smooths out UX issues around the step behavior for number inputs that contain decimals by defaulting to step="any". After discussing and talking through the default browser behavior with @ryankeairns and @1Copenut, we determined that while EUI normally prefers to stick as close to browser implementation as possible, in this case the browser implementation felt clunky and bad, and this was clearly a case where changing the default would result in significant UX improvement.

Note that with step="any", the stepper increment/decrement still defaults to 1 which is the same behavior as before.

This PR also adds the native validity check to onBlur as well, since browsers do apparently use that event (as well as change/keyup) to determine validity.

QA

• Go to https://eui.elastic.co/pr_6760/#/forms/form-controls#number-field and type in a long float/decimal
• Confirm no invalid icon appears while typing
• Use the default browser stepper arrows and confirm they still increment/decrement by 1

General checklist

• Checked in Chrome, Safari, Edge, and Firefox
• Props have proper autodocs (using @default if default values are missing) and playground toggles
• Added or updated jest and cypress tests
• Checked for breaking changes and labeled appropriately
• A changelog entry exists and is marked appropriately
  - [ ] Checked for accessibility including keyboard-only and screenreader modes

[cee-chen]

@1Copenut do you mind reviewing this since you have context from our rubber ducky session yesterday?

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_6760/

[cee-chen]

@1Copenut I should have addressed the aria-invalid always being false (even when native state was invalid). I was previously being a little hesitant & allowing consumer isInvalid={false} to take precedence/override native invalid state, but on second thought this makes no sense as the other invalid UI states don't use the same ?? vs || logic.

Also, the staging link in the PR description is fixed now 🤦

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_6760/

[1Copenut]

👍 LGTM! I did some testing with keyboard and VO and NVDA with preferred browsers. All behaved correctly. I also found some interesting tidbits about e as a shorthand for "ten to the power of..." Screen readers announce this correctly and the input is valid as long as e is followed by a number. I'll post some screenshots in a comment for posterity.

[1Copenut]

Some interesting learnings about e as a mathematical shortcut:

---

---

[cee-chen]

Very cool testing! I'll fly us all out in-person for celebratory drinks if the day ever comes that a user in Kibana needs e for their number inputs 😂