[ ] 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
Sorry I missed the meeting yesterday! Thank you all for the thorough presentation.
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).
[ ] Must: Allison mentioned this in the meeting, but you'll want to make sure there's sufficient color contrast in all possible states and variations in the chatbot interface. I'm thinking specifically of the alert-style responses that you're introducing here. It doesn't look like there's enough contrast between the link text and the background. The WCAG minimum here would be a 4.5:1 contrast ratio, but on VA.gov we exceed that minimum wherever possible. I'd love to see at least 7:1 or better if possible.
[ ] Must: Echoing Erin in #78550, be careful about button and link text --- looking specifically at "Click here to learn more" and (to a lesser extent) the Yes/No buttons.
As a screen reader user moves through interactive elements, they may encounter link text separate from the immediate context. When link text is something like "Click here to learn more," it's hard to parse out what that link's purpose and destination are, especially if there are multiple links with identical text. It's also not necessary to use phrases like "Click here" on links, and isn't consistent with the VA style guide.
The Yes/No buttons are less of a concern since it seems like screen reader users are more likely to encounter them immediately after being prompted by a question. But it's still possible that a user might be distracted from the workflow and confused about what they're saying Yes or No to when their focus returns to the chatbot. Rather than making screen reader users backtrack to figure out what they're doing, "Yes, [what you're saying yes to]" helps reduce that friction.
[ ] Must: With the thinking bubble loading indicators, is there something announced to screen reader users during that wait? There should be some equivalent text provided to say that information is being retrieved --- and if it's a long loading period, that message should be periodically repeated so screen reader users know the process is still active. I realize there may be technical constraints around this, but the concern would be screen reader users not getting that visual cue from the animation that something is happening and then abandoning the workflow because they think it's broken.
[ ] Must: If/when links open in a new tab, make sure you're including text to warn users. All users benefit from those warnings, but screen reader users in particular benefit --- most screen readers don't consistently notify users that they're in a new tab and blind users won't get the visual cue that something has changed on the page, and finding yourself in a new tab with a back button that doesn't work can be disorienting if you don't expect it. The easiest path is visible text, eg. <a href="...">link text (opens in a new tab)</a>, but screen reader only text, eg. <a href="...">link text<span class="sr-only"> (opens in a new tab)</span></a> is also acceptable.
[ ] Should: I'll echo Erin again for providing prompts to go to the claim status tool when there are a lot of claims. Cognitive load is a tricky thing here, since some users will be able to process information better in discrete chatbot chunks and others will be able to process better scanning the page rather than going through a repetitive "not that one... not that one... not that one..." workflow. Giving users appropriate off-ramps for getting to the equivalent information presented a different way is a big help.
[ ] Should: One last time stealing from Erin's IA feedback! They mention providing a consistent escape hatch, and I'll point to usability benefits for both assistive technology users and users with anxiety conditions. In both cases (but for different reasons), a major pain point is when you find yourself accidentally in the wrong workflow with no clear way out of the workflow. Always a good idea to give users an easy way out.
[ ] Consider: You may already have research around this, but I'd be curious to know if there are any other trigger phrases besides "claim status" that Veterans are likely to use, like "check my disability claim" or "status of my benefits" or similar. Whenever possible, try to support as broad a set as possible of plain language triggers.
Governance team actions
[x] Format feedback as individual tasks (check boxes)
[x] Assign this ticket to the VFS team member that opened the Slack request
[x] Add the VFS team product label
[x] 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).
[ ] Must: Echoing Erin in #78550, be careful about button and link text --- looking specifically at "Click here to learn more" and (to a lesser extent) the Yes/No buttons.
As a screen reader user moves through interactive elements, they may encounter link text separate from the immediate context. When link text is something like "Click here to learn more," it's hard to parse out what that link's purpose and destination are, especially if there are multiple links with identical text. It's also not necessary to use phrases like "Click here" on links, and isn't consistent with the VA style guide.
The Yes/No buttons are less of a concern since it seems like screen reader users are more likely to encounter them immediately after being prompted by a question. But it's still possible that a user might be distracted from the workflow and confused about what they're saying Yes or No to when their focus returns to the chatbot. Rather than making screen reader users backtrack to figure out what they're doing, "Yes, [what you're saying yes to]" helps reduce that friction.
<a href="...">link text (opens in a new tab)</a>
, but screen reader only text, eg.<a href="...">link text<span class="sr-only"> (opens in a new tab)</span></a>
is also acceptable.Governance team actions