Can you explain to me how this fixes #4863?
You populate the label with the same content as is already there, so that doesn't seem to do anything at a glance for screen readers?

As for #4864 this has the aria-label already on there as well, normal users don't need a label as the placeholder text serves the same purpose, so what's the rational for doing it?

as is this also borks the CSS as far as I can tell, for instance the chat input:

Can you explain to me how this fixes #4863? You populate the label with the same content as is already there, so that doesn't seem to do anything at a glance for screen readers?

One distinction is that the label associated with the input provides more of a semantic structure than what's currently there. Though, I've run a few tests on my end and realized that this code change isn't best practice taking the intentional lack of a visual label into consideration.

It might not cover all cases and there's a fallback such as wrapping the label around the input much like this code change, but to visually hide a span that contains the label name. This requires some additional code and care, so it might not the best solution, despite it covering some edge cases.

What's currently in the source of these corresponding changes currently meets WCAG 2.1 AA guidelines, so I think I'll close this PR.

As for #4864 this has the aria-label already on there as well, normal users don't need a label as the placeholder text serves the same purpose, so what's the rational for doing it?

placeholder text isn't sufficient since they're mostly inaccessible and folks with vision impairments can have problems with it. An improvement could be made to add aria-placeholder, but this should only be used as a supplement to an actual label (or aria-label).

Closing out for now! Thanks for the review @brunnre8