Design Intent - Accessibility Feedback - [VAOS, VA Online Scheduling, Appointment List Feature]

VFS acceptance criteria

[ ] 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

I appreciated the explanation for why you're moving away from the card approach. I know there's some design feedback related to this, but from an accessibility standpoint I want to make sure this change doesn't inadvertently degrade the experience for disabled and assistive technology users. My main points of concern about that are:
- The existing cards have a data structure that's fairly intuitive to navigate (especially for screen reader users), with HTML headings sectioning each appointment.
- The grid or table-like layout can be a tricky pattern to make accessible, largely for reasons of data structure. Just from looking at the current design, it's not clear what code approach might be taken and how users might navigate through the information.
I mentioned this in the meeting, but my biggest recommendation is to work with @davidakennedy, @AngelaFowler82, and @TiffanyPender as this work continues. In particular, they're going to be able to help with creating a lightweight HTML prototype to test with assistive technologies, both for use in your user research and to help refine the design work before it's committed to code.
Since we didn't have a lot of time in the meeting for accessibility feedback, please let me know if you want to meet separately to discuss any of this feedback. I'd also encourage you to include @davidakennedy, @AngelaFowler82, and @TiffanyPender too!

Feedback

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

Must:

Start thinking about the structure of the HTML in the appointment list early on. Screen reader users in particular may navigate very differently through a table versus a list, for example. with that in mind:
- The appointment list is very table-y, at least as rendered on desktop. If it's intended to be a coded <table>, it must have properly scoped headers for each column.
- If the appointment list is not intended to be a <table>, then some decision needs to be made about how the data is intended to be structured. Some possibilities:
  - As a list, with each appointment as a list item.
  - Using headings, with each date as a heading (probably an h3, with the Month YYYY heading as an h2).
When coded, the "Details" links will need to have a unique accessible name associated with them. This can be either the link text itself or, more likely, the aria-label attribute on the link. Screen reader users often navigate by just exploring a list of links without the surrounding context, so the aria-label ensures that something useful is announced (eg. "Details about your appointment on July 1"). Now is a good time to start thinking about what information is required to make each accessible name unique, and how information should be ordered or phrased to make it most useful. (This is also something that can be validated in research.)

Should:

For video appointments, the current design is displaying a link to join the call whose text is the destination URL (va.gov/heresalink). Screen readers will likely either mispronounce a link like that, or else announce each character of the URL if it doesn't contain pronounceable words. Instead, make the link text an actual word or phrase indicating the destination (eg. "Join the video call"). This also controls for the possibility of an extra-long URL messing with the design.
When including TTY 711 numbers, put the TTY inside the link text (and when coded, include the TTY in the aria label as well). See the design system for a TTY number code example.

Consider:

In the appointment list, organize information in order of what's most important to users. This benefits everyone, but is particularly helpful for screen reader users. As a screen reader user listening to each appointment being announced, you're evaluating whether or not each appointment is the one you care about or whether you want to skip ahead to the next one in the list. If what you're listening for is "Oncology" versus "Podiatry," or you're listening for a particular doctor's name, then having to listen through the modality information ("Phone call. Your doctor will call you") each time before you get to the part you care about could be tiresome. This is a good thing to ask about in user research, and/or to pay attention to comments from users as you do testing.
- Note that this may also inform design choices for sighted users. Thinking about prioritization for screen reader users may also inform how you emphasize text visually.
Similarly, consider whether the prioritization of information on the details view of an appointment matches user priorities. If you've clicked "Details" and you're assessing whether you've arrived in the place you intended to be, does the h1 heading match the most useful information for determining the content of the page? My gut reaction is that modality is less important than when or what --- but again, that's something to explore in user research!

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)

Thank you Brian! I've been talking to Angela about some of these issues, and will bring you and the other A11Y experts you mentioned together as we proceed.

Everything here makes sense, just a couple of notes to clarify:

There is a well-known difference between the appointment information that is useful to Veterans, and the data we have access to. This is covered most recently in the concept study we did ahead of collab cycle (report, presentation). Note that this study references four other studies that support these findings.

I was hoping to get deeper into this issue during our session because it is one of the first things anyone new to VAOS runs into - why don't we show type of care?

We only just recently are able to show type of care and provider name in a few cases, and the hope is that we will expand that when V2 release is complete. But it's not consistently available enough to be useful as the primary piece of information, yet. When it is, we will move it up in the hierarchy. In the designs you saw, type of care and provider name will only show when the data is available.

As for what we did choose to list first in hierarchy:

We decided that cancelation information should come first because of accessibility - folks using screen readers will often skip forward once they have relevant information, so it's important to hear first if an appointment has been canceled. Our original concept displayed it as a status toward the end of the list, where it was still strong but less disruptive.
Modality information comes next because it helps Veterans understand their travel plans at a glance when looking at the list, and we can consistently show it. We also got a good response to this in the concept test so we're continuing down that road for this iteration.

Last thing, we're very interested in testing a lightweight code prototype of this. I had an initial conversation with Angela about the possibilities there. Looking forward to talking more about that. Thanks!

department-of-veterans-affairs / va.gov-team