Midpoint Review - Accessibility Feedback - MHV Medications

[briandeconinck]

VFS actions

• [ ] 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.
• [ ] Close the ticket when all feedback has been addressed.

Thoughts/questions

• I'm out of office Friday so I'll be missing the meeting. If there's anything in my written feedback that's unclear and could use some live discussion, or if there's anything that comes up in the meeting that I should comment on, please let me know!
• Thank you for the accessibility annotations! Incredibly helpful and much appreciated, and you've already got a lot of stuff figured out.

Feedback

Practice areas will document their feedback on the VFS-provided artifacts following the Must, Should, and Consider Framework. Platform reviewers may also provide additional notes that don’t comment on the artifacts themselves but are important for implementation (eg. engineering/coding notes).

• Must: Per the accessibility annotations, the print/download actions are semantically buttons even though they're styled as links on desktop. This doesn't maintain material honesty. The biggest impact here is on sighted voice command software users.

  One common interaction pattern for those users goes like this: User speaks the command "Click link." Software highlights all of the links on the page and assigns each one a number. User speaks a command to select the number for the highlighted link they want, eg. "Click 5."

  That pattern breaks down when links are styled as buttons or buttons are styled as links. In this case, a user might identify "Print medication list" as a link, but that element won't be highlighted when they say "Click link." The user is left to guess what they might actually be --- and in general, making the user start guessing about the semantics of an element is a poor interaction!

  The goal here should be for users to have some intuition about what the element is supposed to be, so that they speak the right command on the first try. Something like the Additional Info component breaks the button pattern, but it's okay because the component is visually distinct from links and in use so frequently across VA.gov that users are likely to build that intuition after a few tries. But styling the print/download actions as links undermines the intuition users have already built up about what links and buttons are supposed to look like. (On mobile I think it's fine. They still look pretty button-y when the element is expanded.)

  My recommendation here would be to explore the tertiary button styles that Matt Dingee has been working on, or otherwise explore some kind of desktop component that's more consistent with what's already on mobile.

• Must: On the Medications page, there needs to be a separate button alongside the dropdown for changing the order in which medications are displayed. The sort action shouldn't be triggered just from a user selecting an option from the select dropdown, as this could be unintentionally triggered by a keyboard user arrowing through the options looking for the one they want. Instead, the sort action should be triggered by a separate button --- basically, making it a deliberate action and reducing the chance of error.
• Engineering note: This may already be planned, but after a user sorts their medications by some criteria, keyboard focus should be set to the "Showing 1 through 20..." H2. Moving focus after that action will prompt screen readers to read that heading, which means screen reader users will get a confirmation that the sort happened successfully.
  • Should: If possible, the H2 text should update to indicate the sort criteria after the sort action. Something like "Showing 1 through 20 of 51 medications - alphabetical order"

• Should: Martha passed along the Slack thread discussing alt text for medications. You're obviously limited by whatever data you have, but if possible the alt text should be a concise description of the physical appearance of the medication. Ideally this would be expressed in a complete sentence or phrase ("A round white pill with the number 235 printed on it"), but something like what Laura suggested may exist in that thread would be just fine ("Round, white, number 235"). There should be sufficient context for screen reader users to understand what something that brief means.

  If that data doesn't exist, I would recommend alt text along the lines of "A photograph of the medication for visual reference" or something like that. I don't think empty alt or role="presentation" is the right way to go here because screen reader users who open the additional info component containing the image might be confused about what happened (is there nothing in the additional info? Is it an image? Is it still loading?). Placeholder alt text isn't particularly useful or actionable, but it would help prevent that particular confusion.

• Consider: The heading structure on the medication detail page and on the PDF download version of that page might be overkill --- but I would verify this with Angela Fowler to be sure. Given how short each snippet of information is ("Reason for use: Joint pain"), a ul with each heading/paragraph consolidated into just an li might be sufficient.

[coultonbunney-usds]

@briandeconinck

I have a question about the this piece of feedback.

Must: On the Medications page, there needs to be a separate button alongside the dropdown for changing the order in which medications are displayed. The sort action shouldn't be triggered just from a user selecting an option from the select dropdown, as this could be unintentionally triggered by a keyboard user arrowing through the options looking for the one they want. Instead, the sort action should be triggered by a separate button --- basically, making it a deliberate action and reducing the chance of error.

The negative consequence of making this change is that folks can change the dropdown, forget to click sort, and then it looks as if the list has been sorted in a way that it hasn't. Actually clicking a sort button is not a common pattern in many other applications that immediately sort upon change and so Jakob's Law predicts that they won't do so here either. I also noticed that Find a Form doesn't include an actual sort button. https://www.va.gov/find-forms/?q=health

Is there a solution here that doesn't have the consequence of folks not clicking the sort button, but also doesn't have the accessibly issue you identified?

cc @alexiawunder @Hamelang

[briandeconinck]

Hi @coultonbunney-usds! Sorry for the delayed response. Thursday and Friday were packed for me and I wanted to wait until I had enough time to give a complete response. I probably should have said more in the initial feedback as well.

The concern I described was for a keyboard user accidentally triggering the sort action, and using a button to help prevent that error. I didn't call it out specifically in the original ticket, the biggest impact here is on screen reader users and low-vision users. A keyboard user with full vision may accidentally trigger the action but will probably notice the visual cues that something has changed and can correct relatively easily. Blind and low vision users are more likely to miss that something has happened, requiring them to identify that a change of context has occurred, determine what the change is, determine why it happened, and determine how to correct it.

With that feedback, what I'm thinking about is WCAG success criterion 3.2.2:

Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component.

(For reference, 3.2.2 is a Level A rule and is represented in the VA.gov experience standards in standard 11.13.)

There's definitely some nuance here that's worth discussing, and I don't think this pattern is well-defined on VA.gov. (I believe Find a Form predates the Collab Cycle, and it definitely predates me.) But on balance I think 3.2.2 does apply in a situation like this. The WCAG supporting documentation notes that not all changes of content are necessarily changes of context, which is kind of the key question to explore.

The classic failure of 3.2.2 would be something like a form that auto-submits after you finish checking the radio button on the last field. User data is submitted without giving the user a chance to verify their selections and correct any errors --- and potentially before a user even realizes they've reached the last field of the form. Context changes and an action is taken before a user is ready or even knows what's about to happen. Not a great experience.

But a clear non-failure would be something like: dropdown to select country, then after you select country the state/province dropdown updates to only show the states/provinces applicable for that country. It's a change of content on the page, but it's not a change of context. The user is still mid-task but content later in the workflow has been updated based on user input.

So from the WCAG SC, the test for this situation would be:

1. Is sorting the medications list a change in context?
2. Does the "Show medications in this order" label sufficiently advise users to expect that change of context?

For (1) I would argue that, yes, the sort action is a change of context --- and I think it's especially true for screen reader users. WCAG identifies four examples of changes of context, two of which may be relevant here: changes of focus, and content changes that change the meaning of the page.

Change of meaning is definitely the more tenuous one, so I'll start with that first! 😄 Although the sort action is just re-ordering the same set of cards, I would argue that a list of medications organized alphabetically is meaningfully different than a list of medications where refillable ones are listed first. An alphabetical list might be something you print for your records or to share with a provider, but you're likely not intending to take any actions on. A list prioritizing refillable ones is something you likely plan to navigate with the intention of refilling one or more prescriptions. To my mind, that changes the meaning of the page.

Focus is, I think, more cut-and-dry --- although Find a Form muddies that a little.

Looking at the Find a Form product and testing with NVDA:

1. Tab to the Sort By select, NVDA announces: "Sort by, combobox, Closest match, collapsed."
2. Press [enter], NVDA announces: "Expanded, list, Closest match, 1 of 5."
3. Press [down arrow], NVDA announces: "Ascending (A-Z), 2 of 5."
4. Press [enter], NVDA announces: "Sort by, combobox, Ascending (A-Z), collapsed."

Focus remains on the select element, rather than moving elsewhere on the page. But that's not really a good experience for screen reader users. After you choose your option, you hear your choice announced back to you. That's expected behavior any time you choose an option from a select element, and doesn't imply that an action has taken place any more than hearing my choice of state announced back to me when filling out my address on a form. Without visual cues, there's no clear indication that something has happened.

To my mind the better pattern for focus management (which the medications page already matches) would be something more similar to the VA.gov search tool. After searching, focus is moved to the H2 reading "Showing 1-10 of 999 results for [term]." That text is announced when receiving focus, indicating to screen reader users that something has happened and this is the result.

From the way the medications page is structured, I would expect something similar to happen. After completing the sort action, focus moves to "Showing 1 to 20 of 51 medications" --- as noted in the original feedback, with something appended to indicate the active sort criteria. Since focus is moving, that's a change of context for the user under 3.2.2.

For (2) from the WCAG test, I think my answer would be no, it doesn't sufficiently communicate the change of context. The label "Show medications in this order" implies an action but to my mind it doesn't directly indicate that an action is going to take place once your selection is made. It's definitely less explicit than other warnings that a change of context is about to take place, like link text that contains "(opens in a new tab)," for example.

But even if the label is sufficiently clear (or could be made clear with content changes), I would have concerns about this pattern. When we talk about links vs. buttons, the key distinction that we make is that links go places and that buttons do things. To my mind, buttons have a near-exclusive role in "doing things." In most contexts, inputs are things that hold user data until the user chooses to do something with that data, rather than something that initiates an action. Likewise, the design system is mostly moving away from wizard-like conditional display behavior in favor of a one-thing-per-page that requires a button click to move forward in a workflow. A sort tool without a button feels like it runs counter to those patterns.

That's a lot of text attempting to justify my feedback! But to your points:

The negative consequence of making this change is that folks can change the dropdown, forget to click sort, and then it looks as if the list has been sorted in a way that it hasn't. Actually clicking a sort button is not a common pattern in many other applications that immediately sort upon change and so Jakob's Law predicts that they won't do so here either.

That negative consequence may occur, but I would be interested in whether user research would identify it as a problem. I imagine a select followed immediately by a sort button would be a user control that's fairly identifiable for sighted users, and the sort button would be the very next tab stop after the select for screen reader users. But that's coming my intuition, not actual research.

More broadly, my feeling is that there's a limit to how Jakob's Law can be applied around accessibility. It's definitely true that many other applications out in the wild don't require that extra button click to sort. Lots of applications have lots of accessibility barriers, many of them much bigger and more consequential than this one. I believe Angela Fowler has been observing that the MHV on VA.gov project is building what may be the first and only fully accessible patient portal. That necessarily means this product will be a little different than other similar products, and that will often extend to individual interactions like this.