Midpoint Review - Accessibility Feedback - Public Websites, Resources and Support, Search experience enhancements, Phase 1

[briandeconinck]

Next Steps for the VFS team

• 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.
• Questions? For the most timely response, comment on Slack in your team channel tagging @platform-governance-team-members.
• Close the ticket when all feedback has been addressed.

Thoughts/questions

• This is exciting to review! There are a lot of filter interfaces on VA.gov but this is a different take on the idea, and I'm interested to see how it performs --- and if it can eventually be the new standard across VA.gov as it moves through the experimental design process.
• With that in mind, I'm giving you a bunch of feedback labeled as "Must." It's especially important to have rock-solid accessibility practices for anything that's going to be repeated across multiple products.
• Definitely continue working with @laflannery as you move this into a coded product. Laura is a tremendous resource.

Feedback

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

• Must: The Filter by drawer should have similar accessibility functionality as a modal, and I would recommend starting with the va-modal component as the template for coding this component. That includes:

  • Announced as a modal to screen reader users (role="dialog" and aria-modal="true")
  • Trap focus inside the drawer (don't allow users to accidentally tab to something that's obscured by the drawer)
  • Close with the [esc] key

• Must: I have significant concerns about making the "Apply filters" and "Clear all" buttons sticky to the bottom of the viewport, particularly for how it may impact low vision users.

  On small viewports / at high zoom (WCAG requires support up to 400%), the sticky elements may obscure other elements.

  On large viewports for users of screen magnifiers (either software or physical devices on their monitor), sticking the buttons at the bottom right corner of the screen with a lot of white space between them and the filter options may make them difficult to find.

  In general, I would recommend keeping related controls in relatively close proximity and allowing the page to flow naturally on a user's device rather than trying to overengineer the placement of elements.

• Must: I'm very concerned about how the placement of the "Show filters" button and the planned focus management may impact screen reader users. If I'm a screen reader user who enters a search term and presses the search button, focus is moved to "Showing 1 - X of Y results." From there, I'll proceed to explore the search results --- and never once have any reason to believe that there were filter options available to me.

  I have a couple of possible suggestions for how this could be addressed (and I'm open to other solutions too!):

  • Place the "Show filters" button after the "Showing 1 - X of Y results" heading. This makes the filter options the first thing they encounter after hearing the results summary.
  • Place the "Show filters" button between the search input and the search button. This prompts users to consider their filter options before even completing their search.

• Must: When searching and when filtering, update the "Showing 1 - X of Y results" message to include more information about the current state. Thinking again about screen reader users and focus management, after you press search and/or apply filters, you get a summary message that doesn't actually tell you if what you've done happened --- you have to backtrack to either find the search term or find the active filters. A message like "Showing 1 - X of Y results for 'term' with 3 filters applied" would give all users, but especially screen reader users, a clear summary of the current state and a confirmation that the intended action occurred.

• Must: When filters are applied and the filter chips are shown, the "Clear all" button must be styled to look like a button, not a link. We try to maintain material honesty on VA.gov wherever possible, in part because the interaction patterns for links and buttons are different for various assistive technology users.

  For example, one common way for voice command/speech recognition users to interact with a link or a button is to speak the command "Click link" or "Click button," have all of the elements of that type highlighted on the page with numerical identifiers, and then select the one you want. If an element is visually styled as a link but semantically a button, you may expect "Click link" to work --- only for it to not be highlighted as an option. Then you have to guess what went wrong, and a lot of users may assume it's broken before the guess that it's secretly a button styled as a link.

  This may be a good use case for the button icon component in VADS. The component doesn't currently support "Clear all" as text but I think it's a good option to discuss with the Design System Team.

• Should: Ryan Thurlwell alluded to this in the meeting --- I'm a little worried about the color contrast for the filter chips. The text against the light blue background should be fine, but the chip background against the white background of the page has a contrast ratio of just 1.14:1. The essential information communicated by the text is still perceivable, but I think the element would be stronger if it was easier to distinguish from its surroundings. I would recommend a border around the edge of each chip that has at least a 3:1 contrast ratio against the white background. (That may also help with the next item too.)

• Must: The filter chips aren't quite like any existing element in the design system. They're close to the tag component but their shape and typography are a bit different. They're button-ish, but they don't really match any of the existing button styles.

  From their intended use, I would expect them to be semantically button elements, since clicking one performs an action on the page (removes a filter). In order to maintain material honesty and make assistive technology interactions predictable, they need to be styled to be recognizably button-y.

  I think what you have now is pretty button-y already, especially if they're given a border. But I think it's worth checking in with the Design System Team and Matt Dingee in particular to evaluate the filter chips as a new button style, and to ensure that the design system has sufficient guardrails in place for when a chip-style button is and isn't appropriate.

• Must: When viewing a details page linked from the results, the filter chips are present again to show the taxonomical labels for the page. But the chips play a different role here when clicked (navigational rather than action), and those differences need to be reflected in both the semantics and the visual presentation. Is there a reason why they couldn't just be ordinary links here?

Governance team actions

• Format feedback as individual tasks (check boxes)
• Assign this ticket to the VFS team member that opened the Slack request
• Add the VFS team product label
• Add the VFS team the feature label (if applicable)
• Add the touchpoint labels
• Add the practice area labels
• Add the Collaboration Cycle initiative milestone