Accessibility Feedback - Design Intent - eBenefits [VR&E CH31]

[jenstrickland]

Feedback framework

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

Point of Contact

VFS Point of Contact: Jennifer (VSA) & Trevor (VSP)

Description

This ticket will house accessibility feedback for the VR&E CH31.

Definition of done

1. Review and acknowledge feedback.
2. Document decisions made. See the Feedback framework for Must/Should/Consider guidelines.
3. Accessibility specialist will close ticket after reviewing documented decisions.

cc @1Copenut -- ready for your review

[jenstrickland]

1. For the wizard prototype, the clickable area must include both the radio input and the label.

2. The same treatment should apply for checkboxes, text inputs, dropdowns/selects, and accordion triggers — labels must be clickable and move focus to the related input.

[jenstrickland]

3. The accordion heading should not be repeated.

This is a common issue with the forms library. Some of the other teams are considering how the 'subtitle' might be adjusted in order not to repeat the same as the accordion label. For sighted users this is a cognitive issue, and for screen reader users it is disorienting, may not be clear that the accordion actually opened. In addition, be sure to indicate that focus is to move to the first heading within the accordion so that the user knows the accordion has opened and knows where they are if they can't see the screen or use a mouse. For the example shown below, the inner heading could be "Service member or Veteran's personal information" and another section that may have contact info (as exists in the Caregiver form, for example) would have an inner heading of "Service member or Veteran's contact information" while the accordion heading is "Service member or Veteran information".

[jenstrickland]

4. The user must confirm their email address. In the BAM2 Medical Device Ordering Tool and Caregiver 10-10CG, there are two email inputs to confirm the user doesn't make a mistake and result in sending personal information to the wrong email address. WCAG 2.0 3.3.4 – Error Prevention (Legal, Financial, Data) (Level AA)

---

Sample from BAM2 Medical Device Reordering Tool

[jenstrickland]

5. The input fields must use the same patterns used elsewhere on VA.gov. [Cognition, consistency]

---

[jenstrickland]

6. Links must have 24 pixels space between. Additionally, please use a bulleted list for this information so the context is clear to sighted and screen reader users.

[jenstrickland]

7. For the wizard, at viewports less than 600 pixels wide, consider using the radio input buttons to provide a touch-friendly target. I believe this is the direction the wizard redesign is headed.

For example, the buttons for smaller viewports might look like the following.

[jenstrickland]

8. To avoid confusion, consider placing names in Title Case rather than ALL CAPS. The ALL CAPS scenario only happens as a result of bad database formatting.

This recommendation is also applicable for the Confirmation screen.

[1Copenut]

@jenstrickland I've reviewed your design feedback and this all looks 💯

I have one question for item #3, and that's all from VSP. You stated

In addition, be sure to indicate that focus is to move to the first heading within the accordion so that the user knows the accordion has opened and knows where they are if they can't see the screen or use a mouse.

Is this a new interaction pattern we're looking to adopt? Currently the review screen accordions don't move focus when users toggle them open or closed, relying on the aria-expanded attribute to let screen readers know an interaction occurred.

[jenstrickland]

Is this a new interaction pattern we're looking to adopt? Currently the review screen accordions don't move focus when users toggle them open or closed, relying on the aria-expanded attribute to let screen readers know an interaction occurred.

This was the behavior that we documented in the fall when I reviewed the Higher-Level Review.

1. User opens accordion
2. At present, focus stays on the button that opened the accordion, there is no indication that anything happened
3. The same interaction pattern happens when a user selects the Edit button to move into the inline editable content, and our recommendation was to move to the legend/heading within to communicate the context change
4. We should communicate a context change here

[jenstrickland]

Trevor and I discussed offline to resolve the question above.

This feedback is ready for you, @jason-gcio and @sporeboy .

[jason-gcio]

@joshkimux - I am going to create a separate ticket to address this ticket as some or most of these have been addressed since this was written and I don't want to introduce new confusion. This came to us a long time ago but I want to make sure I have left no stone unturned. This is in addition to the orientation feedback you have recently helped us with.

For clarity, I am addressing:

1. through 4. would be removed as we have already done those, addressed them elsewhere
2. we still need to do
3. Not our page, but I can request from pubweb
4. We'll consider it but doubtful to be complete by launch
5. We cannot control data from CorpDB and are hesitant to manipulate data as it comes from a source of truth

We can consider closing once we have everything checked off.