[a11y support] MHV - Medical Records Print/Download Button

[sara-amanda]

This ticket contains the following sections:

1. Midpoint Review: Print/Download Button
2. Example Code c/o Bobby
3. Experimental Warning: WAI APG :warning:
4. aria-haspopup feedback
5. Pros, Cons and Unknowns
6. a11y Feedback
7. a11y Recommendations (a. if you use experimental and b. if you use existing pattern)

Midpoint Review: Print/Download Button

Ticket #57260

• Must: If the dropdown button is the route you decide to go for the print/download interaction, then the new component needs to go through experimental design. It sounds like you're already looking at the W3C example pattern, which is probably the best starting point. But W3C examples are sometimes theoretical ideals and browser vendors sometimes interpret standards differently than expected. My main source of anxiety here is that aria-haspopup only has partial support with Android TalkBack. This is something to test with an accessibility specialist before you get too committed to using this pattern. (Preferably an accessibility specialist with an Android device!)
  • Must: Menu items in the dropdown should have at least a 44px by 44px click/touch target. This is coming from WCAG 2.1 SC 2.5.5. Strictly speaking, the VA.gov experience standard that references 2.5.5 only says it's for buttons, but I think that's mostly because we didn't really anticipate links being used in this kind of context (there are exceptions in the WCAG standard for inline links). Regardless of link/button semantics, a 44x44 target size will help avoid accidental mis-clicks and mis-taps.
  • Should: Maintain the material honesty of the print/download actions in the dropdown menu. Elsewhere on VA.gov, printing is an action triggered by a button, while downloading a file is often (but not exclusively) a link. For voice command software users in particular, the distinction between a link and a button is important for how they interact with the page, so the visual presentation should communicate those semantics to the user. Since this is a new component that will go through experimental design you have some flexibility in establishing some new visual styling norms within the dropdown. I don't have specific design recommendations here, except that buttons and links shouldn't have identical styling in this context.
  • Consider: Maybe consider using something like the additional info component or a re-styled accordion component to collapse the print/download actions rather than creating a new component. This sidesteps the aria-haspopup issue and may provide more space to resolving the material honest issue above.

Example Code c/o Bobby

Button closed
<button type="button" id="menubutton1" aria-haspopup="true" aria-controls="menu1">
             Actions
           </button>

Button opened
<div class="menu-button-actions">
           <button type="button" id="menubutton1" aria-haspopup="true" aria-controls="menu1" aria-expanded="true">
             Actions
           </button>
           <ul id="menu1" role="menu" tabindex="-1" aria-labelledby="menubutton1" aria-activedescendant="mi1" style="display: block;">
             <li id="mi1" role="menuitem" tabindex="-1" class="focus">Action 1</li>
             <li id="mi2" role="menuitem" tabindex="-1" class="">Action 2</li>
             <li id="mi3" role="menuitem" tabindex="-1" class="">Action 3</li>
             <li id="mi4" role="menuitem" tabindex="-1" class="">Action 4</li>
           </ul>
         </div>
When the button is interacted with (opened), the focus moves to the first item on the list (<li id="mi1" role="menuitem" tabindex="-1" class="focus">Action 1</li>)

Note: Navigate to “Example” and there is a CodePen Example that Bobby is referencing.

Experimental Warning: WAI APG :warning:

Comes with warning not to use in production on the W3C Site (see: Read this First and large yellow box at the top of the page)

The WAI APG site reflects ideal implementations of ARIA, not real-world implementations by browser and AT vendors.

Read This First

The code in this example is not intended for production environments. Before using it for any purpose, read this to understand why.

This is an illustrative example of one way of using ARIA that conforms with the ARIA specification.

There may be support gaps in some browser and assistive technology combinations, especially for mobile/touch devices. Testing code based on this example with assistive technologies is essential before considering use in production systems.

The ARIA and Assistive Technologies Project is developing measurements of assistive technology support for APG examples.

Robust accessibility can be further optimized by choosing implementation patterns that maximize use of semantic HTML and heeding the warning that No ARIA is better than Bad ARIA.

Recommendations

• Alternative options: Instead of menu controls, perhaps try something that doesn't require as much aria at first, to avoid aria issues.
• Why this and not that? It introduces the potential for issues with the JavaScript and ARIA being required for something to work.

aria-haspopup feedback

<div class="menu-button-actions">
           <button type="button" id="menubutton1" aria-haspopup="true" aria-controls="menu1" aria-expanded="true">

• Use with caution:
  • Typically you want to avoid using an ARIA if the HTML is sufficient. Menus, can use a nested set of links. The HTML <ul>, <li>, and <a> elementshave built-in functionality and user expectations. Avoid overriding that with role=”menu” etc.
• Why should I avoid these?
  • Popup elements can appear as a block of content on top of other content. So, we would need to validate and make certain that the role of the element that is the container for the popup is (menu, listbox, tree, grid or dialog) with the valup aria-haspopup matching the role of the popup container.

Pros, Cons and Unknowns

Pros

• Be clear they are all buttons, for voice command users
• Consistency could be used here with all the controls behaving the same way - as buttons
• One could argue that because you are downloading PDF/TXT files that are generated dynamically, based on user data, there is no expectation the browser will be navigating to some URL triggered by JavaScript action to create and download the file, so it could be a button.
• We can test compatibility (Josh has an Android device.)

Cons

• Experimental for the Platform
• Not a current design component; needs reviewed by the DST.
• Experimental/ Comes with Warning not to use in production on W3C Site (see: Read this First) The WAI APG site reflects ideal implementations of ARIA, not real-world implementations by browser and AT vendors.
• Introduces the potential for issues with the JavaScript and ARIA being required for something to work.
• Not compatible with all browsers and devices. Specifically Android/TalkBack.
• Download is traditionally (almost always) considered links and links go places. Buttons do things.
• Due to not having an expectation the browser will be navigating to some URL triggered by JavaScript, you lose the ability to add a “download” attribute like you have on a link.

Unknowns

• We don’t know yet if this will work with the USWDS V3, or if it has something similar and if its accessible.
• An recommendation would be a part of platform and design system official guidance. You will want to meet with DST.
• It will impact how other teams interpret and use the APG in the future.
• If the pattern with all the children being buttons can be validated through some device testing, that would be ideal.

a11y Feedback

There could be a lot of ways we can approach this; however, regardless of the approach, if we are working with an experimental component, the Design System Team will need to be involved to provide guidance, prior to publishing.

• They will need to let us know also if this will work with the USWDS V3.
• They will be able to identify if it has something similar, that is accessible.
• You can approach them with something along the lines of:
  • This is what we are looking to implement ...
  • Then you would share your component that doesn't currently exist. - Note: Since we don't own this, we can guide, but DST will ultimately have the final say.

a11y Recommendations

Option A: Your Experimental Design

• This will need to go through the DST.
• Rationale: This is a recommendation that would be part of platform and design system guidance because it is experimental. Also, the ARIA Authoring Practices Guide is experimental as well, and it introduces the potential for issues with the javascript and ARIA being required for something to work. The DST and Platform Teams will be able to help make a determination on this, since it will impact how other teams interpret and use the APG in the future.
• Alternative Methods: Have alternative methods been explored instead of menu controls, that would use less ARIA?
• Verification Method: Design System Council meeting needing scheduled

  Since all three have button-like behavior …

• There should be no expectation that the browser is going to navigate to a URL triggered by JavaScript to create and download the file.
• You will lose the ability to add a download attribute like you have on a link.
• Verification Method: Usability Study

  Voice command is still a challenge.

• If I say "Click button" all three of them will be highlighted."
• It will need to be very clear they are buttons, too.

  WAI APG pattern and the CodePen

• It all comes down to actual device compatibility.
• Main Concern: Android/TalkBack support.
• Caution: That APG site reflects ideal implementations of ARIA, not real-world implementations by browser and AT vendors.
  • Avoid implementing a pattern, if we find out it is not going to work for a big chunk of users.
  • Reference: Recent Context: No, APG’s Support Charts Are Not ‘Can I Use’ for ARIA'
• Children Buttons
  • If the pattern with all the children being buttons can be validated through some device testing, that would be ideal.

    Option B. Using an Existing Pattern

• You could try using the standard accordion pattern, so we aren't using the aria-haspop up attribute.
• That way we can include buttons and links as required.
• This would also need to be tested, but would likely support TalkBack, and avoid excluding that audience.

[sara-amanda]

CAIA Update

@BobbyBaileyRB @coultonbunney-usds @alexiawunder This ticket is in response to Bobby's Slack thread about print/download buttons.

• I went ahead and created a ticket in order to parse out the details, considerations and recommendations for the print/download button.
• I also included @briandeconinck 's feedback, so you wouldn't have to toggle to the Midpoint Review Ticket #57260 :smile:
• The information in this ticket includes both research and a consensus of our a11y partners, in order to provide you with the most well-rounded feedback possible, as you design your print/download solution. :raised_hands: :printer:

Let me know if you have any questions. Happy to help!

[coultonbunney-usds]

One thing I've been curious about this entire time is that the primary navigation menu for va.gov is essentially what we want to create here. It uses aria-haspopup=true and has been in wide use for some time. Can we learn from that here, so that we may not need to treat this as so experimental?

[sara-amanda]

Excellent question, @coultonbunney-usds !

I had to inquire about this one because the header was before my time, but I was able to gather the following information that should help to answer your question:

• When the header was built we did not have the a11y processes, expertise and reviews we have in place now.
• So, the best guess is that someone did this in the header, and it was a good attempt at the time. The fact that it was not fully supported by Android was just an unknown at the time it seems, and is in the live environment, today.
• In response to: “we should think about redoing the header entirely”, it’s already in the works, I am told; however, I don't have a timeline on that. The current header will be redesigned and replaced at some point, and it will go through our new and more rigorous testing and reviews at that point, that we have in place now.

I hope that helps! :slightly_smiling_face:

@artsymartha68 @laflannery @briandeconinck

[sara-amanda]

Resource Item

This post is a great resource regarding menus and menu buttons: Menus and Menu Buttons from Inclusive Components. @coultonbunney-usds

[AngelaFowler82]

This is just to note that I met with the team on Friday and clarified our recommendation concerning the download components. Since these components link to an external file, even though they don't actually take the user to another location we recommend that they still be styled and coded as links. I reitterated that the style and coding be consistent.

[sara-amanda]

Print/Download Update

Next Steps

• [x] Printing button as a PDF
• [x] Downloading as a text file
• [x] Aria-expanded (has been tested and is working)
• [x] Aria-controls to better associate the menu button with the menu options
• [x] URL for Testing: The button can be found on https://staging.va.gov/my-health/medical-records/health-history/vaccines for ones that want to see its code and test
• [ ] Documentation is currently being drafted as of 7/31/2023 update from @BobbyBaileyRB

Discussion

Slack Discussion 🧵 7/10/2023

Note: Aria-controls is not widely supported but won't hurt anything. It appears to be just in JAWS and is ignored in other SR such as VO and NVDA.

[sara-amanda]

Print/Download Update

New DST Component Proposed

• As of 8/9/2023: This component is going into the design system, guidance draft Laura, per @BobbyBaileyRB.
  • Bobby started the document for the guidance of the button.
  • Accessibility considerations (referencing other component guidance pieces) - at a stopping point as of 8/9/2023.
  • @laurwill has a ticket to write the content considerations for that component.

    Steps to Submit to DST

• Process for design.va.gov updates: This looks like the page where there is information about updating the site. https://design.va.gov/about/updating-this-site

Additional Considerations

• Print and download can we use it anywhere else?
  • Make more scalable? @BobbyBaileyRB - perhaps reach out to Joel on Secure Messaging?
• Can this be an iterative process?
  • Outstanding question: Does @BobbyBaileyRB need everything when we submit to the DST site?

[sara-amanda]

Print/Download Update

"Print and download button menu, we [Medical Records] aren’t ready to implement the text file, so we [MR] are taking that out of the button menu for now. It will be put back in by the time they get to P1."

^Per Lexi in VA.gov Weekly Design Review Meeting 8/30/2023 4-5 p.m. EST

[sara-amanda]

@rileyorr this is an old MHV ticket from our backlog

[rileyorr]

Hi @alexiawunder and @BobbyBaileyRB! I inherited some older MHV-related CAIA tickets and was wondering if either of you could help me determine if this one should remain open and if it has any status updates.

This ticket appears to be related to a print/download component that was added to the design system and appears to be blocked but I'm not sure why. Lmk if you have any questions or if another person would better know the status of this work. Thanks!

[alexiawunder]

@rileyorr Here is some information about what we've done so far for getting the print/download menu button added to the design system as of January of this year:

• So far I have completed Steps 1-3 according to the Suggest an addition or update page
• The component wasn't rejected, but they wanted us to write up more information about it before it was officially approved, which Bobby and I did, and Coulton approved. I think this is where we became blocked - I needed Laura to give her seal of approval, but everyone got busy and it fell to the back burner.
• As of now though, there have been some changes to the component, like making the buttons larger, so we may have to revisit some of our original documentation.