Accessibility - add role search and aria label sitewide if configured

Thanks, great suggestion!
The code also looks pretty good already. Since you already helpfully added the label to the test view I just went and also added assertions for that.

I do have two questions, though:

1. In the documentation you linked it is suggested that the role and aria-label attributes should actually be on the <form> (or other container) element, not on the input field. Is there a particular reason why you placed it on the input field instead?
   I do agree that it makes sense to only activate this behavior if there is an exposed “Search: Fulltext search” filter (people use the Search API to build lots of things that aren’t searches), but I think just manipulating $form['#attributes'] in SearchApiFulltext::buildExposedForm() should work fine to still put the attributes on the form itself in this case. It’s then just a bit unclear whether that filter is really the correct place to have the configuration for the ARIA label. (Otherwise, what should happen when there are multiple such filters?)
2. Speaking of the configuration: Is there a reason you put the aria_label option into the “root” options of the filter instead of nesting it within expose? As this will only take effect when the filter is exposed, having it as part of the “expose” option seems to make more sense.

Anyways, thanks a lot again for your work on this, really a very good MR already!

Please respond so I can merge.

Oh, darn, it actually seems like this is a bug in Drupal Core: I created #3503878: TypeError when having exposed form in block and setting "role" attribute on it to address it.
As this not only affects the tests, but can actually be reproduced on an actual site if you have an exposed form in a block, I fear we cannot actually merge this until the Core bug has been fixed and we depend on a version of Drupal Core that contains that fix.
I unfortunately don’t even think we can really work around this problem in this module without an unacceptable amount of code.

> In the documentation you linked it is suggested that the role and aria-label attributes should actually be on the
(or other container) element, not on the input field. Is there a particular reason why you placed it on the input field instead?

Testing this on a client website, Chrome is happy with this MR and adding aria-label to form tag, it does not report a11y error any more about missing label on input field. However when testing with Wave Evaluation Tool it is still reporting error that label is missing for the input field:

Reading above referenced mdn documentation it says that search landmarks should only be labeled if there is more then one search on the page, and if not then you do not need to provide a label:

If there is more than one search landmark role in a document, provide a label for each landmark.

But Chrome Lighhouse will flag a11y error if form only have a search role without a label on form or input element.

Clearly a11y tests and specification are a bit off here and somebody is not doing things correctly. But what should be correct solution here i am not sure for now.

One more potential problem, what would happen in a rare case when you have two search text fields in a search form for some reason - then defining a lable for both text fields would not work properly.

IMO adding aria-label definition on input field and then using in on form tag feels wrong to me. How about adding two configurations - one for form tag and then other for input text elements? With this we would cover all cases, right?
It feels to me that form aria-label config should actually go to a views module it self, because any exposed form is a in a way is a search form and it should have a search role and aria-lable describing in more detail what that form is searching.