Midpoint Review - Accessibility Feedback - Digital Health Platform, MVP

[briandeconinck]

VFS acceptance criteria

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

Thoughts/questions

• Just to reiterate what I said in the meeting, thank you for providing the link to staging! We don't typically get actual HTML at midpoint reviews and it's helpful for me to see.
• This is outside the scope of a midpoint review, but I did want to flag one bug I noticed in staging. When logged in as vets.gov.user+0 and navigating through the page as a keyboard-only user, when the Fitbit "Disconnect" button receives keyboard focus any keyboard event appears to activate the button and open the modal rather than just [Enter] and [Space] --- including attempting to press [Tab] to move to the next element. I think there might be an event listener that needs some attention!

Feedback

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

Must: Unique identifiers for links/buttons. I kind of hinted at this in the meeting but realized afterwards that I didn't really describe it in detail.

Screen reader users often navigate a page by bringing up a list of all the links or buttons on the page and then jumping straight to the one whose name matches what they're looking for. That means the link or button text might be presented without any surrounding context, and so the text should communicate meaning clearly without relying on context.

This will become an issue when multiple devices are available as options. A list of links that all say "Connect" or buttons that all say "Disconnect" doesn't provide enough information for a screen reader user to decide which one to follow. The easiest option is to include extra words in the link and button text (<a href="#">Connect Fitbit</a>). The second easiest option is to include the extra words in a screen-reader-only aria-label (<a href="#" aria-label="Connect Fitbit">Connect</a>).

In the situation where you could have multiple devices of the same type (eg. multiple Fitbits), you'll want to include whatever information is required for the disconnect buttons to have unique accessible names. Something along the lines of:

<button aria-label="Disconnect [Device] [Identifier]">Disconnect</button>, or <button aria-label="Disconnect Fitbit 3">Disconnect</button>.

Should:

Consider:

Data structure. Right now, the device is coded as a card with an h3 heading indicating the device type, roughly like this:

<h3 ...>Fitbit <span ...>- Connected</span></h3>
<button ...>Disconnect</button>

This is valid HTML, and might be a good way of structuring this information. If future iterations include providing additional actions besides connect/disconnect, or include any device metadata, then definitely keep this structure.

But if the only thing being displayed about a device is type, status, and a single connect/disconnect action, then that content is simple enough that you can probably get away with an unordered list. Something like:

<li>
   <span ...>Fitbit</span> <span ...>- Connected</span><br />
   <button ...>Disconnect</button>
</li>

It can still be styled to look like a card, but it might be a smoother interaction pattern for screen reader users. The main advantage is that the list semantics provide summary information for screen reader users, eg. "list, three items" without needing to listen to the full list of device headings.

It's not a change I would insist on and it might not make sense depending on what future iterations look like. Just something to explore!

Platform directions

• Update "Issue Title"
• Link to collab cycle Request epic
• Add your feedback
• Add assignees based on collab cycle touchpoint
  • Design Intent: VFS designer, VFS PM (optional), yourself (optional)
  • Midpoint Review: VFS PM, yourself (optional)
  • Staging Review QA Only: VFS PM, yourself (optional)

[robbie1226]

Thanks for the feedback. Writing to let you know that we applied the "Must" updates to our staging environment.

[robbie1226]

Thanks for the feedback and for sharing the bug!! Writing to let you know that we applied the "Must" update to our staging environment.