Repository navigation
HTML-AAM: determine right mappings for popup ui for date and time inputs #49
Description
From @cyns on May 6, 2016 21:5
The UI that pops up from date and time inputs is not reliably mapped to accessibility APIs in browsers and does not reliably work with screen readers. We need to determine the right way to map the relationship between the launcher (button or edit) and popup UI, so that screen readers can find it.
This applies to
input (type attribute in the Date state)
input (type attribute in the Date and Time state)
input (type attribute in the Local Date and Time state)
input (type attribute in the Month state)
input (type attribute in the Week state)
Where these inputs have popup UI. (time doesn't on Chrome.)
Copied from original issue: w3c/aria#364
Activity
jasonkiss commentedon Oct 12, 2016
From @cyns on May 6, 2016 22:6
@joanmarie @asurkov similar to the issues with color picker (#363) and validation errors (#360 #160)
Here's what we're doing in UIA:
Control Type: Edit
Localized Control Type: (element state name)
ControllerFor: points to the popup
The popup and its children must be present in the UIA tree, and mapped as button, slider, etc. as appropriate for the type of control.
Would it work to do something similar with ControllerFor/ControlledBy in IA2 and ATK?
jasonkiss commentedon Oct 12, 2016
From @asurkov on August 11, 2016 20:30
I would say this is a reasonable suggestion, but iirc there's a bunch of examples, where people use aria-owns relations.
jasonkiss commentedon Oct 12, 2016
From @mcking65 on August 12, 2016 2:30
aria-owns creates problems ... pls go w/controling relationship.
asurkov commentedon Oct 18, 2016
I'd say ControllerFor/ControlledBy should work out for both of IA2 and ATK in case of standard controls, but it's better to double check with Jamie and Joanie how it looks like from screen readers perspective. Note. IA2 and ATK also have POPUP_FOR relation, which may be valid for this case too.
This approach might have an implementation issue, in case if the popup is provided by OS, and not accessible to the browser.
asurkov commentedon Dec 22, 2016
For the reference:
UI Mozilla bug https://bugzilla.mozilla.org/show_bug.cgi?id=1283381
a11y Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=559762
It probably makes sense to wait until implemented before specifying the exact accessibility mapping.
asurkov commentedon Dec 23, 2016
on a second glance, since datalist and input relations are already exposed as controlled_by/controls_for relations, then it's reasonable to do same for input date types, since they are not different. At least until we have more implementations. If no objections, then I will proceed with it.
jasonkiss commentedon Feb 7, 2017
Makes sense to me. I say proceed. We can revisit again if implementations warrant.
scottaohara commentedon Feb 7, 2025
current idea for this issue: provide general guidance and recommendations on how user agents could expose such popups, but stop short of being prescriptive as we should not dictate the exact UI that a user agent might want to implement.
additionally, a "recommendations" section might be a good idea for other elements that consist of multiple UA provided elements.