MHV-65357, MHV-65365, MHV-65366: BB accessibility fixes

[mattwrightva]

Summary

• Form element added to each BB form page
• The step title in the progress bar has been changed to an h2
• The focus on each form page is now automatically set to the h2 in the progress bar
• The h2 below the progress bar has been removed (it was redundant)
• The record dates advice in the types of records form has been changed to use a legend element
• The number of records advice in the file type form has been changed to use a legend element
• I moved the form button actions out of the HTML for cleanliness and readability.
• Applied a janky fix to make the segmented progress bar focus outline yellow

Related issue(s)

https://jira.devops.va.gov/browse/MHV-65357

Should Fix: BB flow keyboard focus (GH 99402)

Description
As a user moves through the Blue Button form flow, keyboard focus is sent to the H1 when progressing to the next page of the flow. For screen reader users, the element receiving keyboard focus is the first thing announced. Since the H1 is static throughout the form flow, screen reader users hear the same thing on each page: "Select records and download report."

This doesn't provide screen reader users with useful information about where they are in the flow, and doesn't match the behavior of other forms on VA.gov. Other forms send keyboard focus to the step indicator for each page, or alternatively to the first unique heading on each page.

Link, screenshot or steps to recreate
Recommended action
I had thought the page transition focus management was included as part of the forms library, but if it's not then make sure you're matching the behavior of the mock form patterns and reach out to the forms team for implementation guidance.

Testing done

No new unit tests needed

Screenshots

What areas of the site does it impact?

MHV medical records BB download pages

Acceptance criteria

Passes accessibility audit from @BobbyBaileyRB

Quality Assurance & Testing

• I fixed|updated|added unit tests and integration tests for each feature (if applicable).
• No sensitive information (i.e. PII/credentials/internal URLs/etc.) is captured in logging, hardcoded, or specs
• Linting warnings have been addressed
• Documentation has been updated (link to documentation *if necessary)
• Screenshot of the developed feature is added
• Accessibility testing has been performed

Error Handling

• Browser console contains no warnings or errors.
• Events are being sent to the appropriate logging solution
• Feature/bug has a monitor built into Datadog or Grafana (if applicable)

Authentication

• Did you login to a local build and verify all authenticated routes work as expected with a test user

Requested Feedback

(OPTIONAL) What should the reviewers know in addition to the above. Is there anything specific you wish the reviewer to assist with. Do you have any concerns with this PR, why?