[ ] 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.
[ ] Questions? For the most timely response, comment on Slack in your team channel tagging @platform-governance-team-members.
[ ] Close the ticket when all feedback has been addressed.
Thoughts/questions
This all looks great! No real concerns at all here.
Feedback
Practice areas will document their feedback on the VFS-provided artifacts following the Must, Should, and Consider Framework. Platform Governance reviewers may also provide additional notes that don’t comment on the artifacts themselves but are important for implementation (eg. engineering/coding notes).
[x] Consider: Just noting here that you should be aware of how screen reader users may encounter (or not encounter) definitions and other helper text as they navigate through the page. In a form flow, screen reader users aren't typically going to have their computer announce all of the text on the page, instead tabbing through all of the interactive elements on the page to move through the form efficiently. If there's helper text that's not programmatically associated with an input (either via ARIA or the fieldset/legend pattern) it's not likely that they'll here that text. Alternatively, information might be included in an additional info component, whose triggering element is a separate tab stop and will be encountered when tabbing through.
Sometimes that doesn't matter! If the text isn't necessary for understanding what the question is asking, no big deal. Sometimes it's a bigger issue, like when you're using acronyms or jargon-y words that most people won't understand.
For things like assets and dependents, you currently have dependents explained in an additional info --- meaning it's likely to be encountered as a tab stop --- and assets as plain text --- meaning it's unlikely to be heard unless you associate it with an input somehow.
Does that matter? Honestly, I don't know! It's up to you, since you know your product and the user base better. But it's worth thinking about the discoverability of each term and whether they should have equivalent discoverability or if it works fine the way it is.
Governance team actions
[x] Format feedback as individual tasks (check boxes)
[ ] Assign this ticket to the VFS team member that opened the Slack request
[ ] Add the VFS team product label
[ ] Add the VFS team the feature label (if applicable)
[x] Add the touchpoint labels
[x] Add the practice area labels
[x] Add the Collaboration Cycle initiative milestone
Next Steps for the VFS team
@platform-governance-team-members
.Thoughts/questions
Feedback
Practice areas will document their feedback on the VFS-provided artifacts following the Must, Should, and Consider Framework. Platform Governance reviewers may also provide additional notes that don’t comment on the artifacts themselves but are important for implementation (eg. engineering/coding notes).
[x] Consider: Just noting here that you should be aware of how screen reader users may encounter (or not encounter) definitions and other helper text as they navigate through the page. In a form flow, screen reader users aren't typically going to have their computer announce all of the text on the page, instead tabbing through all of the interactive elements on the page to move through the form efficiently. If there's helper text that's not programmatically associated with an input (either via ARIA or the
fieldset
/legend
pattern) it's not likely that they'll here that text. Alternatively, information might be included in an additional info component, whose triggering element is a separate tab stop and will be encountered when tabbing through.Sometimes that doesn't matter! If the text isn't necessary for understanding what the question is asking, no big deal. Sometimes it's a bigger issue, like when you're using acronyms or jargon-y words that most people won't understand.
For things like assets and dependents, you currently have dependents explained in an additional info --- meaning it's likely to be encountered as a tab stop --- and assets as plain text --- meaning it's unlikely to be heard unless you associate it with an input somehow.
Does that matter? Honestly, I don't know! It's up to you, since you know your product and the user base better. But it's worth thinking about the discoverability of each term and whether they should have equivalent discoverability or if it works fine the way it is.
Governance team actions