Accessibility Feedback - Usability Testing Prep - VAOS Homepage Refresh

[1Copenut]

VFS acceptance criteria

• [x] Let VSP know when the Must feedback has been incorporated
• [x] Leave any comments for feedback you decide not to take
• [x] VFS team closes the ticket

Feedback

• Must = the feedback must be applied
• Should = the feedback is best practice
• Consider = suggestions/enhancements

Must:

• Full cards must be accessible to screen readers and allow users to drag and copy text. I read this article on CSS Tricks, and agree with method 4 as the best approach: https://css-tricks.com/block-links-the-search-for-a-perfect-solution/#method-4-sprinkle-javascript-on-the-second-method
• Cards must have something to indicate they are clickable. Right now we're relying on the blue chevron that is not a strong enough indicator alone.
• The <select> to adjust users' appointment preference must announce the change to screen readers. The GOV.UK sort has a proper label as we do here, and then announces "123 results, sorted by OPTION" with OPTION being what users picked from the select menu. The VSA Decision Tools team is going to be using this pattern also. Please consider discussing your solutions; this will likely be a design system candidate in the future.

Should:

• Should recruit participants using guidelines for inclusive research
• Should have a good visual indicator for hover, focus, active states on the card links
• Should schedule additional testing with real device users before launching. InVision is not accessible to assistive technology users (screen readers like JAWS, NVDA, etc., voice navigation like Dragon Speaking Naturally)

Consider:

• The Cancel appointment action feels like a button, and the Go back to appointments feels like a link. The visuals do not convey what each UI might do. Has there been any discussion about changing these?
• What does the Cancel appointment action do? Does it have a confirmation modal/screen?

[laurenernest]

@1Copenut Do you mean visually or programmatically for screenreaders?

Cards must have something to indicate they are clickable. Right now we're relying on the blue chevron that is not a strong enough indicator alone.

[1Copenut]

@laurenernest Great question! This feedback is related to visual indicator(s). Screen readers will announce the card text, then say "Link" after a short pause.

[laurenernest]

@outerpress see notes above

[outerpress]

Thanks @1Copenut ! A couple of notes/questions:

Cards must have something to indicate they are clickable. Right now we're relying on the blue chevron that is not a strong enough indicator alone.

For indicators, on mobile we have the rounded corners of the card and chevron, and on desktop we'll have a hover state, and a link with the word "details" showing next to the chevron. Do you have some criteria or examples I can look at to get a better idea of the visual indicators needed?

The Cancel appointment action feels like a button, and the Go back to appointments feels like a link. The visuals do not convey what each UI might do. Has there been any discussion about changing these?

Good call, I'll take a look at adjusting these.

What does the Cancel appointment action do? Does it have a confirmation modal/screen?

Yep, there's a confirmation modal.

Should schedule additional testing with real device users before launching.

Just curious, do you know of a prototyping tool that works well for assistive tech users?

[1Copenut]

@outerpress Great questions!

• https://css-tricks.com/ and https://www.smashingmagazine.com/ do cool things with micro interactions and animation to denote interactivity of cards and card-like structures. I recognize those are content and design sites, so I mention them more as ideation reference than anything.
• UXPin works better for assistive tech, to a point. Coded examples that live on staging.va.gov or another development environment with a public URL are the best way for screen readers, voice navigation, and other AT to test.

[outerpress]

Closing this one at as the "must" feedback is being addressed (we're also working on some of the shoulds and considers):

Full cards must be accessible to screen readers and allow users to drag and copy text.

Addressed by #22769

Cards must have something to indicate they are clickable. Right now we're relying on the blue chevron that is not a strong enough indicator alone.

Addressed by #23478

The to adjust users' appointment preference must announce the change to screen readers.

Addressed by #22770

• © Githubissues.
• Githubissues is a development platform for aggregating issues.