[fields] Refactor to use multiple elements to support a11y

[LukasTy]

The new DateField (and their sibling components) need custom a11y implementation to be accessible by screen readers.

W3 Aria has an example of date picker component with spin buttons. Their example looks and feels (functionality) very similar to our DateField component behaviour, hence, it could make a very good base for a11y support in the component.

Exploration notes

• Using spinbutton approach and augmenting input element with additional aria attributes does not work. Possibly the ever changing full value attribute as well as custom section selecting interferes with screen readers ability to announce proper aria attribute denoted data.
• Having separate element with proper aria attributes updated based on selection does not work, because that element is not focused and it's attributes are ignored

Possible exploration

• Having spinbutton divs (overlaying the underlying input element), which would intercept tabulation/click events, propagate those events to the actual field and update the spinbutton aria attributes accordingly (it seems like tedious and janky solution to achieve pretty simple result easily doable with different field implementations)
• Provide a hidden label with full current date string (updated after any section data change) at least announcing to end user the currently selected value

After exploration

Results uncovered in #7334 proved that the only logical path is to refactor the field component rendering in order to achieve the desired spinbutton behavior. Other implementations seem like hacks, without a correct tangible result.

[github-actions]

⚠️ This issue has been closed.
If you have a similar problem, please open a new issue and provide details about your specific problem.
If you can provide additional information related to this topic that could help future readers, please feel free to leave a comment.

[kylane]

Any update as to what implementation was done @LukasTy ?

[LukasTy]

@kylane We have gone with an approach of having a separate textField component, which renders a list of contenteditable elements with relevant roles.
This approach is going to be opt-in on v7. You can adopt the behavior by providing an enableAccessibleFieldDOMStructure prop on a Field or Picker component.
You can check the accessible DOM structure documentation.

If you see any potential problems with the solution or have suggestions—we are open to hearing any kind of feedback. 🙏

[kylane]

If you see any potential problems with the solution or have suggestions—we are open to hearing any kind of feedback.

Gday @LukasTy - thanks for that - sorry, been dragged in other directions since my original post.

Just testing this now - It still doesnt give at-time feedback for an invalid value (say for month) and auto corrects it without feedback at the time of typing.

I have set the textfield slot to variant "standard" but the underline styling of the input seems missing?

Also, Im not getting any of the helpertext read out, even in an error state.

Looks promising though. Any advice from here?

[LukasTy]

Thank you for the feedback @kylane! 🙏

Just testing this now - It still doesnt give at-time feedback for an invalid value (say for month) and auto corrects it without feedback at the time of typing.

The behavior of the value (section) management is mostly identical between the approaches.
Could you give an example of a flow that you think is problematic and also how would you expect it to behave? 🤔

I have set the textfield slot to variant "standard" but the underline styling of the input seems missing?

This is an actual problem that we'll address. I've created #12825 for this and other concerns.

Also, Im not getting any of the helpertext read out, even in an error state.

We'll have to explore it, maybe there is some problem with id mapping.

[kylane]

Thank you for the feedback @kylane! 🙏

Appreciate the time you guys put in :)

Just testing this now - It still doesnt give at-time feedback for an invalid value (say for month) and auto corrects it without feedback at the time of typing.

The behavior of the value (section) management is mostly identical between the approaches. Could you give an example of a flow that you think is problematic and also how would you expect it to behave? 🤔

If I type 34 in for a day value (invalid) it autocorrects to 04, but doesnt alert the user (screen reader) at that time. It only reads back the date once all 3 "fields" have been entered, then they have to go back. Look, Im likely being picky - its still "usable" but, its still not an ideal situation where the value the user has entered is changed without their knowledge (likely later then its read out).

I have set the textfield slot to variant "standard" but the underline styling of the input seems missing?

This is an actual problem that we'll address. I've created #12825 for this and other concerns.

Appreciate it!

Also, Im not getting any of the helpertext read out, even in an error state.

We'll have to explore it, maybe there is some problem with id mapping.

Appreciate that too, and you guys. Keep up the awesome work.

[kylane]

Without at all trying to appear condescending, Ive sent my dev to this resource on the regular: https://www.digitala11y.com/accessible-date-pickers-roundup/ - it has some great explanations and concepts.

[kylane]

@LukasTy Have we had any progress?