HTML-AAM: need string values for all HTML form elements to plug into accname-aam step 2E

[jasonkiss]

From @cyns on March 16, 2016 5:15

<input type=checkbox id=foo>
<label for=foo>Include items from <input type=date value="2016-04-01">?</label>

the accessible name of foo should be something like "Include items from April 1, 2016?"
We need to define how those values stringify for the html date, time, color, and all other form elements that aren't of one of the specified roles
If the embedded control has role textbox, return its value.
◾If the embedded control has role menu button, return the text alternative of the button.
◾If the embedded control has role combobox, return the text alternative of the chosen option.
◾If the embedded control has role range (e.g., a spinbutton or slider):

Copied from original issue: w3c/aria#307

[scottaohara]

regarding the markup from the op:

<input type=checkbox id=foo>
<label for=foo>Include items from <input type=date value="2016-04-01">?</label>

This is invalid HTML to have a label trying to name two inputs. the date input has no name as a result in both firefox and chromium browsers.

Edit: depending on the input type used within the label, AT may try to error correct and produce a name for the element. E.g., if the type were 'text' in the above example, Chrome dev tools would report the input as having no name. But VoiceOver on macOS would still announce a name for the input. However, if it were a checkbox, then the nested input would have no computed name, nor would it be announced with one if navigating to it with VO (macOS 12.4).

Safari on macOS 11.4 (so need to check newer versions) and iOS 15.4.1 do actually name the checkbox as Include items from April 1, 2016. But on macOS the date field is exposed as 3 separate unnamed groups. On iOS with the current markup, and If this were changed to a regular text field on macOS, the text field would also have a similar accessible name - including it's current value as part of the name, which doesn't seem right.

I'm thinking that it is worth adding this use case to the accName section, but specifically noting that this is for mitigating against author error.

[JAWS-test]

This has been correctly written in AccName, Step 2E for years:

Otherwise, if the current node is a control embedded within the label (e.g. the label element in HTML or any element directly referenced by aria-labelledby) for another widget, where the user can adjust the embedded control's value, then include the embedded control as part of the text alternative in the following manner: ...