Accessibility feedback for Design intent Collaboration [VA form search page]

[jenstrickland]

VSP and VSA accessibility feedback

Feedback framework

• ❗️ Must for if the feedback must be applied
• ⚠️Should if the feedback is best practice
• ✔️ Consider for suggestions/enhancements

---

VSP design accessibility feedback

❗️ Must --> https://github.com/department-of-veterans-affairs/va.gov-team/issues/7097

• Manage focus when users press Search. Ideally we would move focus to the "Showing results for SEARCH TERM"

• It will be too much information read back if we use aria-live region

• Focus will need to be managed when we have pagination too. Probably set focus back to the same spot ("Showing results for SEARCH TERM") when user presses a pagination link.

• "Apply online" button will need an aria-label or SR-only text to be clear to screen readers. For instance:

  <a href="#">
  <span aria-hidden="true">Apply online</span>
  <span class="sr-only"Apply online for 10-10072 Supportive Services for Veteran Families</span>
  </a>

⚠️ Should

• Download links should follow the accessible pattern VSA/VSP accessibility specialists collaborated on
• List the number of results. Something like "Showing 5 results for 10-10"
• Ensure the horizontal rules are either lower borders on the cards or have an aria-hidden="true" attribute applied. These are stops for screen readers and generate cognitive noise.
• Current page in the breadcrumb should be bold
• Mobile version should include the back-by-one breadcrumb < Home

✔️ Consider

• Following the date format outlined in our Dates and years content section

---

Definitions of Done

• MUST feedback:
  • Focus considerations are communicated with the front-end engineers
  • Guidance is sent to front-end engineers about any screen reader enhanced labels for link text
• SHOULD feedback:
  • Download link guidance is sent to front-end engineers
  • Number of results are added to the visual designs
  • Guidance about horizontal rules sent to front-end engineers
  • Breadcrumbs are updated on visual designs
• CONSIDER feedback:
  • Update the revision dates on visual designs if applicable

No additional review needed.

---

VSA design accessibility feedback

❗️ Must

• Must use semantic markup for the list of results. See previous feedback provided regarding markup. Possible options:
  • <table> - using responsive techniques (this new responsive table sample that may be of interest: https://codepen.io/aardrian/pen/VwYyVJY)
  • <ol> if the results will be weighted as indicated during our meeting
  • <dl> structure, where the list is one entire description list, and each item is a <dt> with relevant <dd> info beneath it.

⚠️ Should

• Individual buttons should include an accessible name that matches the displayed text. It may need to be populated dynamically for each button (for example, “Go to online tool” s/b “Go to {name of tool}” or “Apply online” s/b {Apply online for {name of benefit/etc}}). For speech input users, the text displayed should match the activation words. Also, for screen reader users (especially in link mode) will only hear "Go to online tool" or "Apply online" without the context of the tool/application, which could also use the method Trevor noted for sr-only, but speech input users need the accessible name visible.
• Chevron: the > right angle bracket should also have a these attributes: role="presentation" aria-hidden="true" so that screen readers do not speak the bracket aloud (Source John Foliot's post on aria-hidden & presentation role)
• The purpose of a link should be determined from the link text alone or from text together with programmatically determined link context (Source: WCAG 2.1 Success Criteria 2.4.4, WCAG 2.1 Success Criteria 2.4.4, alternate view). Cognitively, it may be unclear or overwhelming that the "Form# + Title >" goes to a detail page, while the download link downloads, and a possible button opens an app. Link text should be concise. If alternate versions are tested, I'd like to see the results of not linking the # and title, providing distinct links to view details or download, and the possible button.
• Accessibility best practices state file download links should provide file size (Source: https://accessabilly.com/proposal-for-a-more-accessible-download-link/ - scroll down to heading "File Size is important at first Glance"). Why does this matter?
  • If someone is on mobile and has a limited 3Gb data plan, they could blow their budget on overage fees.
  • It would also impact those on slow networks, providing no estimate of how long the download might take.
  • "2.2 million veteran households lack either fixed or mobile broadband connections at home."; 'Rural veterans “continuously struggle with access to medical care, demonstrating the importance telehealth could have on rural veterans,” the FCC report says. However, it points out that “veterans residing in rural areas are likely to have more limited access to fixed and mobile broadband services in the home, limiting their access to services such as telemedicine.”' (Source: https://docs.fcc.gov/public/attachments/DOC-357270A1.pdf, https://www.healthdatamanagement.com/news/lack-of-access-to-broadband-hampering-telehealth-for-veterans, and https://www.ntia.doc.gov/other-publication/2017/fact-sheet-veterans-computer-and-internet-use)

✔️ Consider

• Consider programmatically determining the file size, and automate providing file size dynamically (Source: https://stackoverflow.com/questions/55226378/how-can-i-get-the-file-size-from-a-link-without-downloading-it-in-python), responding to previous insights shared.
• Consider that the animation of the link may be distracting or trigger a vestibular disorder, resulting in nausea and headaches. This animation seems relatively benign, but would like to have the 508 Office review. Consider adding prefers-reduced-motion as a progressive enhancement.
• Consider the spacing of the links and buttons, to ensure those with keyboard and other assistive tech can easily select the item they want. Message me and I can share a couple of images of user scenarios.

👍 / 👎 Definitions of Done

• Semantic markup is validated.
• Focus management is validated.
• Recommend a spot check ahead of Staging Review, to ensure semantic markup is not only compliant but inclusive for our VA.gov users.
• Decisions documented regarding ⚠️ Should and ✔️ Consider items.

[MickinSahni]

Hey @jenstrickland, is this the extent of the feedback for the Design Intent collaboration? If so, I'd like to groom it with the team and create any additional tickets to track knocking this out.

[jenstrickland]

@MickinSahni This is the extent of the accessibility feedback for the design intent collaboration, given the project timeline. There would normally be additional tickets with feedback for the other practice areas, but they had none and used a comment.

[MickinSahni]

Must items--> https://github.com/department-of-veterans-affairs/va.gov-team/issues/7097

[jenstrickland]

@MickinSahni I just remembered this download link documentation that may be of use, if your team has download links. @1Copenut and I collaborated on defining the accessible download links, and iirc this is going to eventually be in the design system.

[MickinSahni]

@ncksllvn doublecheck that the should and consider items are not already taken care of. if not, groom and prep for prioritization (estimate, milestone, etc.)

[ncksllvn]

Going through this list, noting the ones we need to revisit. Going to follow up against boiling this down further.

VSP

musts

1. "Apply online" button will need an aria-label or SR-only text to be clear to screen readers.
   • Great suggestion; we can make sure to do this when we work on https://github.com/department-of-veterans-affairs/va.gov-team/issues/11453 (which adds that button)

should

1. Download links should follow the accessible pattern VSA/VSP accessibility specialists collaborated on
   • Great suggestion.
2. Current page in the breadcrumb should be bold
   • Not sure I follow exactly what this means (page in the breadcrumb?) but I don't think we're doing that.

consider

1. Following the date format outlined in our Dates and years content section
   • I'm guessing this means our "Form last updated" fields would have the month spelled out per https://design.va.gov/content-style-guide/dates-and-numbers#dates-and-years

VSA

musts

I think we're good here

should

1. Individual buttons should include an accessible name that matches the displayed text.
   • Do in https://github.com/department-of-veterans-affairs/va.gov-team/issues/11453
2. Chevron: the > right angle bracket should also have a these attributes
   • Do in https://github.com/department-of-veterans-affairs/va.gov-team/issues/11453
3. The purpose of a link should be determined from the link text alone or from text together with programmatically determined link context
   • Do in https://github.com/department-of-veterans-affairs/va.gov-team/issues/11453
4. Accessibility best practices state file download links should provide file size
   • Hm, not sure on the technical feasibility here

consider

1. Consider that the animation of the link may be distracting or trigger a vestibular disorder, resulting in nausea and headaches.
   • I'm not against this but I'm not sure i understand. We don't have any animations defined for Find Forms...this might be referring to the hover effect on links where the background fades in? I think this is global;
2. Consider the spacing of the links and buttons, to ensure those with keyboard and other assistive tech can easily select the item they want. Message me and I can share a couple of images of user scenarios.
   • I feel like we're okay as far as spacing goes but we should get clarity on this.

[ncksllvn]

Action items

We should implement these as part of #11453 or after.

1. "Apply online" button will need an aria-label or SR-only text to be clear to screen readers.
2. Download links should follow the accessible pattern VSA/VSP accessibility specialists collaborated on
3. Individual buttons should include an accessible name that matches the displayed text.
4. Chevron: the > right angle bracket should also have a these attributes
5. The purpose of a link should be determined from the link text alone or from text together with programmatically determined link context

Discuss

These items we need to clarify and decide on before we can move forward with technically.

1. Following the date format outlined in our Dates and years content section
   • Currently, our dates look like Form last updated: 03-22-2020. Should this be Form last updated: 03/22/2020, or Form last updated: March 22, 2020?
2. Accessibility best practices state file download links should provide file size
   • Unless the API provides the file size in the JSON data for each form, I don't think we can do this technically. I glanced at the linked StackOverflow thread, but I don't think that solution work for us.
3. Consider that the animation of the link may be distracting or trigger a vestibular disorder, resulting in nausea and headaches.
   • This may be calling for a global change - removing the "fade" effect of the background color when links are hovered over
4. Consider the spacing of the links and buttons, to ensure those with keyboard and other assistive tech can easily select the item they want. Message me and I can share a couple of images of user scenarios.
   • Need clarity

[ncksllvn]

@MickinSahni @jenniferlee-dsva I just circled back to this. Many of these I think we can do in our upcoming work for adding the additional fields into the search results in https://github.com/department-of-veterans-affairs/va.gov-team/issues/11453, but others we need to discuss a bit before implementation

[MickinSahni]

Accounted for in #11453. Archiving this to keep for our records.