Secondary nav wrapping issue w/ browser font settings

[sterkenburgsara]

Description

Some OCTO stakeholders noticed an issue with secondary nav links wrapping incorrectly in some browsers when fonts are enlarged / magnification is on. This is nominally an a11y issue.

Issue has been observed in:

• Mac Chrome: Version 127.0.6533.89 (Official Build) (x86_64), font size "large"
• Safari: Version 17.4 (19618.1.15.11.12) and font size 24

User story

As a Veteran who has set my minimum font size larger than normal (e.g. 24px), I want the MHV navigation bar to display as expected, so that I can navigate the portal without any usability or additional cognitive load.

Notes

• Slack thread here
• Jim created a PR, but it was rejected
• We need to figure out what a11y use cases we should be building for.

Possible tasks:

• [x] Validate frequency of these issues on various browsers
• [x] Determine what is causing strange wrapping of the last URL in the secondary nav: records when font sizes are enlarged
• [ ] Deploy fixes to remedy the problem

Acceptance criteria

• [ ] Timeboxed investigation and recommendation – is there an easy fix?
• [ ] Discussed prioritization of recommended fix
• [ ] Implemented if appropriate – the browser versions see correct wrapping of links in the secondary navigation bar when font sizes are enlarged
• [ ] QA review
• [ ] A11y review

[jzucadi]

PR: https://github.com/department-of-veterans-affairs/vets-website/pull/31188

[wesrowe]

@dcloud, I see a couple boxes checked in the possible tasks section, but no comments to support them. Can you please add anything you know in a comment here before memory fades?

[dcloud]

Just by looking at the description in Jim's PR, he had reproduced in Chrome and Safari. The proposed solution in there involved a JavaScript-heavy approach that required drawing some offscreen text and measuring text size.

I think a better approach would not require JavaScript, and we should investigate CSS-driven techniques that don't require writing a mini-rendering calculator

[wesrowe]

Because slack thread indicated a very low priority (a11y-level-4, at most), Patrick recommended putting this in the backlog and addressing later if time allows. Not worth much effort.