Autocomplete: Assign ARIA attributes as combobox, with TinyMCE node mirroring#2789
Autocomplete: Assign ARIA attributes as combobox, with TinyMCE node mirroring#2789
Conversation
Codecov Report
@@ Coverage Diff @@
## master #2789 +/- ##
==========================================
+ Coverage 33.95% 34.06% +0.11%
==========================================
Files 191 191
Lines 5690 5703 +13
Branches 997 998 +1
==========================================
+ Hits 1932 1943 +11
- Misses 3180 3183 +3
+ Partials 578 577 -1
Continue to review full report at Codecov.
|
4ecc6a2 to
081fa8b
Compare
|
I'm not sure that I agree that putting aria attributes on the wrong element is a good idea even if you also put aria-hidden; for example quoting from https://www.w3.org/TR/wai-aria/states_and_properties#aria-owns :
|
Based on the conversation in #3106 I'd agree with your assessment. Maybe instead of a mirror node that the TinyMCE attaches an observer to, the parent Editable calls on the TinyMCE node directly with attributes from incoming prop changes. This is similar to your † I think ideally someone who renders an Editable could pass these props as the attributes they would expect to be applied, |
Related: #2771
This pull request seeks to assign attributes of the
Autocompletecloned input as a combobox, bound as "owning" thePopoverwhich it controls. To better represent the relation between the Editable and Popover search listing, props applied to the Editable have been improved using reference from thecomboboxrole specification.These changes are extracted from commits originally present in #2771, in order to simplify review there to the minimal set of changes to fix the regression introduced to autocomplete behavior after #2323.
Testing instructions:
Verify that there are no regressions in:
Verify that correct ARIA expanded / ownership / active descendant attributes are assigned to both the mirror node (
aria-hidden) and the contenteditable while using the default block slash inserter.