fix: a11y: heading elements usage and ordering

[shkeating]

SC-2310

Proposed changes

In accordance with the Trusted Tester 10: Content Test IDs

• changes page templates and components that hold the page title to use a h1 for the heading element containing the name of the page
• removes h2 designation from the Welcome, $name Personal Data component, as well as the preview for it to not use a header element. This h2 ussage was not correct and broke the header order
• adjusts the headings on components to use the next sequential header (widget headers are now h2s, and the heading below them are h3, h4, etc.
• ensures header styling is correct and in alignment with how they were designed. Widget headers are bold, and some size corrections were made in the weather widget

TO DO: fix all the unit tests this affects :')

Reviewer notes

there are design system implications to this change. both in figma and storybook we need to make adjustments to our design tokens to reflect different font sizes being assigned to the h2/h3 elements than initally anticipates

this PR changes the semantic output of these elements, and if visual changes were made they were done in accordance with Figma designs, details I think may have been missed when they are first styles (for example Widget headers being bold)

e2e tests: https://github.com/USSF-ORBIT/ussf-portal/pull/371

Setup

Login to the portal http://localhost:3000

Start storybook

yarn storybook

Login to storybook http://localhost:6006, though the command above should open it for you

Screenshots

[shortcut-integration]

This pull request has been linked to Shortcut Story #2310: investigate header order implications of hello, $name.

[AnnaGingle]

I have a couple of heading levels I want to double-check on.

USSF documentation

The accordion header is H2 and it just looks off to me. Also, the footer H2s are smaller and visually proportional. Can we update the styling of the accordion's H2s?

My Space

The collection header is not visually an h2. I think this fails 1.3.1-heading-level.

See the failing example from the Windows course docs

A web page is displayed when individuals finish a course that is being piloted.

This would FAIL 1.3.1-heading-level. Let's take a look and see why:

If ALL of the following are TRUE, then the content PASSES:
Every programmatically identified heading level logically matches the visual heading structure on the page.
The structure outline in ANDI is:

<h4>Conclusion and Contact Information</h4>
<h3>Contact Information</h3>
<h3>OAST</h3>
<h1>Evaluation</h1>

This DOES NOT match the visual structure of the page. Conclusion and Contact Information” <h4> also needs to be at a higher level than “Contact Information” `<h3>` which is both visually smaller and contextually a subheading under it. Thus, the programmatic heading for “Conclusion and Contact Information”<h4> does not match the visual structure.
Both “Contact Information” and “OAST” are a <h3> heading level. However, contextually “Contact Information” should be a higher level than its subheading, “OAST.” We expect to see “OAST” listed as an <h4> or lower, yet it is listed at the same level as its parent heading. The programmatic heading does not logically match the visual structure.

[AnnaGingle]

Everything is good to go within the scope of this pr!

[shkeating]

I have a couple of heading levels I want to double-check on.

USSF documentation

The accordion header is H2 and it just looks off to me. Also, the footer H2s are smaller and visually proportional. Can we update the styling of the accordion's H2s?

My Space

The collection header is not visually an h2. I think this fails 1.3.1-heading-level.

re: myspace page 1.3.1 means that h2s are less visually prominent than h1s and more visaully promient than h3s. based on that, this would pass. I do think we need to update the design system docs in storybook to reflect the changes in what an h1-h5 is though.