feat(autocomplete): add input-aria-label and input-aria-labelledby

[Splaktar]

PR Checklist

Please check that your PR fulfills the following requirements:

• The commit message follows our guidelines
• Tests for the changes have been added or this is not a bug fix / enhancement
• Docs have been added, updated, or were not required

PR Type

What kind of change does this PR introduce?

[ ] Bugfix
[x] Enhancement
[ ] Documentation content changes
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Infrastructure changes
[ ] Other... Please describe:

What is the current behavior?

applying aria-labelledby to md-autocomplete has no effect because the attribute is not forwarded on to the input.

Issue Number:
Fixes #10815

What is the new behavior?

add support for input-aria-label and input-aria-labelledby which will apply those values to the input element of the autocomplete.

Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information

It looks like the previous PR #11407 had a problem with https://github.com/GoogleChrome/accessibility-developer-tools/wiki/Audit-Rules#ax_text_01:

Error: AX_TEXT_01 (Controls and media elements should have labels) failed on the following element: #input-16

[jelbourn]

LGTM

[Splaktar]

@jelbourn I am actually going to change this once more after doing some further testing on a larger chips a11y PR. I think that applying input-aria-labelledby is more accurate. If we keep with just aria-labelledby, it seems to cause some duplication with screen readers.

I'll send over the chips PR for your initial review later today.

[Splaktar]

@jelbourn OK, this PR is updated. It also adds an input-aria-label similar to md-chips. This is useful since the placeholder and label are not always the same.

This PR also updates aria-describedby to be input-aria-describedby for md-autocomplete.

It's possible that this could solve the a11y error that was seen by Miles' presubmit. However, the changes were made for general correctness after doing some additional screen reader testing with chips.

It's still possible to apply an aria-label to the md-autocomplete and then a different input-aria-label which would apply that string to the aria-label of the embedded input.

[Splaktar]

Feedback on presubmit failures: This PR "is failing an accessibility check in one project where an element that formerly had a label now doesn't. Need to check that the change isn't overwriting an aria-label with nothing."

I'll try to reproduce this in a unit test.

• check that existing aria-labels are not lost/overwritten with nothing

[mmalerba]

I'm seeing a couple of these errors:

Error: AX_TEXT_01 (Controls and media elements should have labels) failed on the following element:
#input-0
See https://github.com/GoogleChrome/accessibility-developer-tools/wiki/Audit-Rules#ax_text_01 for more information.

[Splaktar]

@mmalerba I'll need more detailed information. As mentioned above, I've written up a lot of test cases for this. Please let me know the use case that is failing so that I can add another unit test that covers it.

[Splaktar]

Bumped this to P1 as getting this in is blocking some work on P1 issues.

[Splaktar]

Rebased.

[Splaktar]

Rebased ✅

[Splaktar]

Rebased ✔️