Are there any repro steps for a Mac? I don't have a Win machine to reproduce this. Also looking at the HTML code, there is already a <label> pointing to the <input> field, see https://cs.chromium.org/chromium/src/ui/webui/resources/cr_elements/cr_toolbar/cr_toolbar_search_field.html?l=140-149.

+dbeam: Do you know the answer to #2?

maybe spotty shadow DOM support?

i still don't really know what this bug is about, but it doesn't seem like a huge deal

This bug is not actionable, because it is not clear what the issue is. I am un-assigning myself. Perhaps we should just close the issue instead.

Firstly, it's possible that this issue was improved by the CL from a couple of weeks ago ([1]).

I installed NVDA, and I can reproduce the behavior in the initial issue. When I navigate to MD Settings, the screen reader announces:

"Settings document. Search settings, edit, blank".

I'm not sure I understand the premise of why this behavior is a bug, though? If it just announced "edit, blank", there would be no context about what the text field is for.

Further, we match the behavior of the old options page, which when loaded announces:

"Settings document. Settings grouping, header. Search settings, edit, blank"

and it also matches the behavior/code of paper-input [2, 3]:

"text input, edit, blank"

In short, chaok@, can you please follow-up, check if this is still an issue, and if so provide some more guidance on what needs to be changed? Thanks!

[1] https://codereview.chromium.org/2759073002/
[2] https://github.com/PolymerElements/paper-input/blob/1d7c0ff82eabc486713bea7a876abd0a5a176005/paper-input.html#L119
[3] https://beta.webcomponents.org/element/PolymerElements/paper-input/demo/demo/index.html

Marking as WontFix, based off chat with dbeam@ and the fact that this behavior seems to match the old options page.