Docs: forms accessibility cleanup (#31114)

* Expand on disabled fieldsets and faked buttons

include further advice/information on how to disable faked buttons for keyboard/AT users

* Centralise accessible name advice in forms overview

seems odd to only mention (separately) label, aria-label etc in input-group and layout. the advice is just as pertinent in other sections like select. checks only skims over this.

moving this, in expanded form, into the overview section itself. adding a specific cross-reference (just because they are easily left with no accname at all) in the checks page.

* Change warning about accessibility, modify server-side example

- paradoxically, due to our current problems with validation (see #28414) and the fact that browsers seem to have improved in this area for the most part, it's now actually better to use browser-native validation
- added explicit `id` and `aria-describedby` association to at least the server-side form error messages, to show how it should be done properly, and expanded the prose for that explaining this.

* Replace `.sr-only` with `.visually-hidden` in new addition

* Copy edits for clarity in parenthetical

* Copy and formatting tweaks

- Wordsmithing here and there
- Turns some hyphens into em dashes
- Turns a long running comma separated list into an unordered list
- Rearranges some copy just a bit

Co-authored-by: Mark Otto <markd.otto@gmail.com>

site/content/docs/5.0/forms/input-group.md

@@ -326,9 +326,3 @@ Input groups include support for custom selects and custom file inputs. Browser
   <button class="btn btn-outline-secondary" type="button" id="inputGroupFileAddon04">Button</button>
 </div>
 {{< /example >}}
-
-## Accessibility
-
-Screen readers will have trouble with your forms if you don't include a label for every input. For these input groups, ensure that any additional label or functionality is conveyed to assistive technologies.
-
-The exact technique to be used (`<label>` elements hidden using the `.visually-hidden` class, or use of the `aria-label` and `aria-labelledby` attributes, possibly in combination with `aria-describedby`) and what additional information will need to be conveyed will vary depending on the exact type of interface widget you're implementing. The examples in this section provide a few suggested, case-specific approaches.