Accessibility Testing for BMT Team II, Benefit Letters, Fix Voice Access not clicking buttons properly

[1Copenut]

Product information

• Team name, product name, and feature name have been added to the title of this issue.
• Team label, product label and feature label (if applicable) have been added to this issue.

Who completed the use of color and color contrast test?

@1Copenut

Use of color and color contrast checks

• All text of 20px or smaller has a 4.5:1 contrast ratio to its background (or better)
• All text of 20px or larger has a 3:1 contrast ratio to its background (or better)
• Non-text elements have a 3:1 contrast ratio to their background and to neighboring elements (or better)
• Color is not the only way to distinguish links from other text (eg. links are underlined)
• Any charts, maps, infographics, and tables convey all information without only relying on color
• Content does not refer to color, especially when providing user instructions (eg. "Click the blue button")

How did color testing go?

No color contrast issues. The yellow focus halo has a 3:1 contrast ratio discrepancy to the white background, but this is a known issue and being remediated by the design system team.

Who completed the axe scans?

@1Copenut

axe checks

• Each page has been scanned using axe (results shared below)
• axe is integrated into your end-to-end testing

axe DevTools scan results

The Benefit Letters pages have no axe issues.

How did axe testing go?

The Benefit Letters pages have adequate axe checks in the Cypress end-to-end tests for good coverage and representative user states.

Who completed the content zoom and reflow test?

@1Copenut

Content zoom and reflow checks

• All page elements are readable and usable at 200% zoom
• All page elements are readable and usable at 300% zoom
• All page elements are readable and usable at 400% zoom

How did content zoom and reflow testing go?

No issues found in content zoom and reflow.

Who completed the keyboard navigation test?

@1Copenut

Keyboard navigation checks

• Each link, button, form input, checkbox, radio button, select menu, and custom element can receive keyboard focus
• Each link, button, form input, checkbox, radio button, select menu, and custom element responds to expected keys
• All elements under focus have a visible focus indicator
• The order of [Tab] stops made sense and was appropriate for completing tasks

How did keyboard testing go?

No issues found in keyboard testing.

Do you have any other results to share?

I made a change to the <VaButton> logic for the disabled attribute. This attribute is a Boolean in the HTML5 spec, and does not accept a "false" string or false Boolean value; it exists or it does not. Passing false as the prop value was causing Microsoft Voice Access to not register the click event on "View letters" and "Download letter" buttons. I could say "Click View letters" and nothing would happen. After I updated the logic for disabled to accept either true | undefined, null the buttons behaved correctly. I'll be filing an issue with the Design System team to fix the button logic too.

I tested this several times over several days with NVDA and Chrome, Edge, Firefox for the efficacy of removing the live regions. They were communicating too much information when users loaded the Letters page (step 2) and when users opened a letter accordion. The default behavior of our own <VaAccordion> and native <detail> components is to announce the state change but not read out the inner content. My change made the Benefit Letters match this experience.