[x] Assign this ticket to the team member(s) responsible for addressing feedback provided by Platform.
[ ] Comment on this ticket:
[ ] If the Platform reviewer has any Thoughts/Questions that require responses.
[ ] When Must feedback has been incorporated. As appropriate, link to any other GitHub issues or PRs related to this feedback.
[ ] When Should/Consider feedback has been incorporated, or if any feedback will not be addressed. As appropriate, link to any other GitHub issues or PRs related to this feedback.
[ ] Close the ticket when all feedback has been addressed.
Thoughts/questions
Thank you! I'm very much looking forward to seeing what you learn in research!
Feedback
Practice areas will document their feedback on the VFS-provided artifacts following the Must, Should, and Consider Framework. Platform reviewers may also provide additional notes that don’t comment on the artifacts themselves but are important for implementation (eg. engineering/coding notes).
Must: Depending on what you learn from research, the "No thanks" element in the modal should be...
A link, if it navigates the user to a new page.
A button, if it closes the modal and keeps the user on the same page.
If there's any uncertainty, please feel free to reach out to discuss it further!
I did a poor job of verbalizing my concerns about keyboard in the meeting, so I'm going to try again in writing! 😄
Case 1: If a user visits VA.gov, clicks the "Sign In" button, and completes the authentication process, they're redirected to My VA.
Case 2: If a user visits VA.gov, navigates to the page for some VA benefit (eg. 21-526EZ), clicks the "Sign in to start your application" button, and then goes through the authentication process, they aren't redirected to My VA. Instead, they stay in the workflow they've started.
It's important to make sure we know exactly where keyboard focus will go after closing the modal (clicking the Close X button, and potentially from the "No thanks" element too). Where keyboard focus goes after closing the modal determines what's the next thing read by screen reader software, and determines what the next tab stop is for keyboard-only users.
If the modal only appears in Case 1, then managing keyboard focus is straightforward because you're only needing to match the post-auth behavior that currently exists on My VA. (I think focus goes to the My VA H1 after authentication, but you should double-check that!)
If the modal also appears in Case 2, then you'll need to make sure you manage keyboard focus in a way that makes sense across all of the forms and workflows on VA.gov where this can happen. I think forms generally follow the same model as what happens on My VA, but I don't know that for a fact.
I don't have a strong opinion on whether or not the modal shows up for Case 2 --- that's up to you! But if it does, then you'll want to do some testing with a good sample of products across VA.gov to make sure that when the modal closes focus lands somewhere that makes sense.
It's possible that this may also be informed by comments made by users in your research sessions. I would be surprised if anyone actually shares opinions on where keyboard focus should go! But they might hint at it by commenting on what they would do next after the modal closes.
VFS actions
Thoughts/questions
Feedback
Practice areas will document their feedback on the VFS-provided artifacts following the Must, Should, and Consider Framework. Platform reviewers may also provide additional notes that don’t comment on the artifacts themselves but are important for implementation (eg. engineering/coding notes).
I did a poor job of verbalizing my concerns about keyboard in the meeting, so I'm going to try again in writing! 😄
Case 1: If a user visits VA.gov, clicks the "Sign In" button, and completes the authentication process, they're redirected to My VA.
Case 2: If a user visits VA.gov, navigates to the page for some VA benefit (eg. 21-526EZ), clicks the "Sign in to start your application" button, and then goes through the authentication process, they aren't redirected to My VA. Instead, they stay in the workflow they've started.
It's important to make sure we know exactly where keyboard focus will go after closing the modal (clicking the Close X button, and potentially from the "No thanks" element too). Where keyboard focus goes after closing the modal determines what's the next thing read by screen reader software, and determines what the next tab stop is for keyboard-only users.
If the modal only appears in Case 1, then managing keyboard focus is straightforward because you're only needing to match the post-auth behavior that currently exists on My VA. (I think focus goes to the My VA H1 after authentication, but you should double-check that!)
If the modal also appears in Case 2, then you'll need to make sure you manage keyboard focus in a way that makes sense across all of the forms and workflows on VA.gov where this can happen. I think forms generally follow the same model as what happens on My VA, but I don't know that for a fact.
I don't have a strong opinion on whether or not the modal shows up for Case 2 --- that's up to you! But if it does, then you'll want to do some testing with a good sample of products across VA.gov to make sure that when the modal closes focus lands somewhere that makes sense.
It's possible that this may also be informed by comments made by users in your research sessions. I would be surprised if anyone actually shares opinions on where keyboard focus should go! But they might hint at it by commenting on what they would do next after the modal closes.