[Issue #1397] process roadmap accessibility

[doug-s-nava]

Summary

Fixes #1397

Time to review: 20 mins

Changes proposed

• update DOM structure on process page to follow best practices for lists (previously implemented as three invidual lists with one item each, rather than one list with three items)
• update aria labels to make high level roadmap items more readable by screen readers
• a few refactors for better readability of process page code

Context for reviewers

Test steps

1. visit localhost:3000/process
2. visit https://simpler.grants.gov/process
3. VERIFY: the "high-level roadmap" section of each page matches visually
4. turn on screen reader (cmd + fn + f5 probably)
5. ctrl + opt + cmd + h to cycle through headings until you find "the high level roadmap"
6. ctrl + opt + a to read the content
7. VERIFY: roadmap headings are read out as "Step 1: Find" etc.

Additional information

note that requirement in the ticket specifying removal of "launch" aria text for the chevron icons seems to have already been fixed

[emilycnava]

Left a few questions, haven't tested locally yet.

[emilycnava]

Might just be a me thing, but I'm not sure I understand what this section is doing, can you explain it a bit?

[doug-s-nava]

Sure!

As far as I can tell from the docs, useMessages will always return all messages in use in the app. Since we only care about the high_level_roadmap_items messages, I destructured the return value from the hook to dig into just that part of the object. That way we don't have to use a long chain to index into the object when we want to reference the high_level_roadmap items. Does that make sense? Happy to do a quick call to discuss

[acouch]

Thanks for asking and for the explanation. It looks like we could ditch useMessages() altogether and just iterate over the three roadmap items.

[doug-s-nava]

Yeah, this whole thing is kind of odd IMO. My take is we probably shouldn't be directly using the translation messages to determine this functionality. I'd rather have a concept of the roadmap item keys outside of the translation and use those to create translated text.

On the other side of things, useMessages seems to be created for the purpose of accessing next intl messages on the client side. Since this is a server component, we likely could access the messages directly as you're describing, but again, I think with a slightly bigger refactor that wouldn't be necessary. See https://next-intl-docs.vercel.app/docs/environments/server-client-components#option-3-providing-individual-messages

I'll take a crack at it.

[emilycnava]

Verified it works locally, checked out upstream branch, enabled voiceover etc. so LGTM!

[emilycnava]

Re-review post merge conflict