Uh oh!
There was an error while loading. Please reload this page.
fix(aria): treat searchbox as a textbox when computing embedded names - #42342
fix(aria): treat searchbox as a textbox when computing embedded names#42342Ayaan Gazali (ayaangazali) wants to merge 1 commit into
Conversation
Step 2C of accname returns an embedded control's value when that control is a textbox. searchbox is a subclass of textbox, but the check only matched textbox, so <input type="search"> contributed nothing. <button aria-labelledby="x"><div id="x"><input type="search" value="Q"> resolved to an empty name, while the identical markup with type="text" resolved to "Q". Two lists in the same file already pair the roles this way, kAriaReadonlyRoles and kAriaDisabledRoles.
Test results for "MCP"1 failed 8135 passed, 1341 skipped Merge workflow run. |
Test results for "tests 1"22 flaky51222 passed, 1233 skipped Merge workflow run. |
Ayaan Gazali (@ayaangazali) you'll need to accept CLA as described in #42342 (comment) so that we can merge it. |
Ayaan Gazali (ayaangazali)
commented
Aug 21, 2026
Thanks, on it. Getting the CLA accepted now and will confirm here once it goes through. Also flagging in case it saves you a look: the one red check, |
CLA is accepted now, the |
Yury Semikhatsky (yury-s)
commented
Aug 21, 2026
@microsoft-github-policy-service rerun |
Yury Semikhatsky (yury-s)
commented
Aug 21, 2026
I don't see where you accepted it. |
Ayaan Gazali (ayaangazali)
commented
Aug 21, 2026
You are right and I was wrong, sorry about that. I checked the combined status, saw it green, and did not notice that the list only contained the two HTML Report contexts and that license/cla was simply absent rather than passing. Absence is not acceptance, and I should not have told you it was done. The CLA has not been accepted. I have flagged it to be signed properly and will not claim it again until I can point at an actual passing check. |
Anton Petnitsky (Mukller)
commented
Aug 23, 2026
The behavioral fix is correct, and it matches the spec — though I'd tweak the justifying comment before merge, since as written it cites superseded semantics. In ARIA 1.1, Suggested comment rewording: // HTML-AAM: <input type="search"> contributes its value to the accessible// name like type="text" does (ARIA 1.2 makes searchbox a sibling of// textbox, not a subclass).Keeping the spec reference accurate matters here — a "subclass of textbox" note invites a future refactor into a role-hierarchy check, which would be the wrong mechanism. |
Ayaan Gazali (ayaangazali)
commented
Aug 23, 2026
Good catch, thank you. You are right that the comment should not rest on the subclass argument, and HTML-AAM is the better citation for why the value is contributed. One honest caveat: I tried to confirm the ARIA 1.2 hierarchy change against the spec myself and could not get a clean read on the searchbox role definition table, so I would rather not assert the sibling-of-textbox wording either, having just been wrong about something else on this PR. Proposing to drop the hierarchy claim entirely and state only what is not in dispute: // HTML-AAM: <input type="search"> contributes its value to an embedded// accessible name, the same as type="text".That keeps the justification accurate without me repeating a spec claim I have not verified firsthand. Happy to use your exact wording instead if you are confident in the ARIA 1.2 part, since you clearly know this corner better than I do. The behavioural change itself is unchanged either way. |
Rationale
<input type="search">contributes nothing to an accessible name computed through a label oraria-labelledby, while<input type="text">in identical markup contributes its value:The second button ends up with no name at all, so it cannot be found by
getByRole('button', { name: 'Query' }).Step 2C of accname returns an embedded control's value when the control is a textbox, and
searchbox is a subclass of textbox. The branch at
roleUtils.ts:749only matchedtextbox, whilegetAriaRolegives<input type="search">therole
searchbox(roleUtils.ts:131), so it fell through.What convinced me this is an oversight rather than a deliberate deviation is that two lists in the
same file already pair the two roles:
kAriaReadonlyRoles(line 1115) andkAriaDisabledRoles(line 1175) both list
textboxandsearchbox. This branch was the only place treating themdifferently.
One condition, plus a comment pointing at the spec.
Test
role-utils.spec.tsalready hascontrol embedded in a target element, so the search case goesthere next to the text case rather than in a new test. On current main the added assertion fails
with the name coming back empty instead of
Baz qux.Green across all three browsers:
role-utils.spec.ts87 (which includes the w3c accname cases),plus
selectors-role.spec.ts,page-aria-snapshot.spec.tsandexpect-to-have-accessible.spec.ts72 on chromium.flintclean.Fixes#42341
the bit I am least confident about is my reading of searchbox inheriting from textbox in the spec,
so please push back if that is wrong and I will close this myself. also worth flagging that my
previous PRs here have sat with the CLA check pending, so if that blocks this one just say and I
will get it handled. freshman in college, appreciate the patience :)