Welcome page: "major" accessibility issues that may not need design

[ndushay]

From https://docs.google.com/spreadsheets/d/1Fs5sY1zgpovWVdHMqpJWRu2Zvyr53jw7, here are "major" accessibility issues for the Welcome Form that we can fix without design changes.

The Welcome form can be the page for a first time user OR perhaps what we all see as the welcome page (see PR #3131, which addressed accessibility level A and AA problems noted by the SiteImprove, WAVE and Axe browser plugins).

Note that solutions may be suggested in https://docs.google.com/spreadsheets/d/1Fs5sY1zgpovWVdHMqpJWRu2Zvyr53jw7.

These can be separate PRs, and/or split into separate tickets.

Note that the first time user form is the same as the help form and issues here may address issues in #3173

• There are common input fields that lack autocomplete attributes to communicate their purpose programmatically: the "what is your name" and "what is your email address" fields in the first-time-user screen and in the Help dialog. Also in Header / Footer "major" accessibility issues that may not need design #3173. Fix in Some accessibility fixes for welcome/home page #3179
• <a href="#content">Skip to main content</a> -- although a skip link is present, the page does not contain a valid target for the skip link.
  PETER: I added a content name tag in the layout itself where the main content is added, so should ensure there is a valid target on every page. EDIT: we do not believe this is needed anymore
• When "Request access to another collection" is selected and the tooltips are visible, the controls that open the tooltips are not associated with the tooltip content. (Form field errors are not programmatically associated with the field to which they apply, and are not indicated programmatically. The error messages are not programmatically associated with the form controls to which they apply.)
  PETER: I added an aria-describedBy and adjusted the PopoverComponent, which will hopefully address this everywhere in H2. Fix in ensure all popovers have aria-describedBy #3186 https://inclusive-components.design/tooltips-toggletips/#inclusivetoggletips
• The Cancel control has no visual indication of keyboard focus when using TAB or SHIFT+TAB to navigate through website controls.
  PETER: I made a CSS change that should add a border on hover for all other buttons styled like this cancel button. Fix in Some accessibility fixes for welcome/home page #3179
• The programmatic (DOM) order does not match the visual reading order. When one of the modal dialogs is open, the content behind the dialog is still conveyed.
• (Minor level) The Welcome heading is a level 2, and when the modal dialogs are open, each is a level 3. Headings that have structural markup should accurately communicate the heading level.
  PETER: Not sure I understand this one, the "Welcome!" on the first time form is an H1 tag, not sure what the levels are referring to or what the fix would be.
• (Trivial level) The error messages appear briefly, but they do not remain visible. (filling out forms) - Also in Dashboard page: "major" accessibility issues that may not need design  #3172
  PETER: Not sure which errors we are referring to. The validation messages appearing next to input fields stay on screen for me until I take an action (move focus).