[SCREENREADER]: VAOS - Continue button MUST give meaningful feedback during transitions

[1Copenut]

508-defect-2

Feedback framework

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

Description

Our VA 508 office contact noticed a situation on the /choose-eye-care page where after pressing the Continue button, our gray spinner button announced itself as "unlabeled zero button unavailable" to JAWS + IE11. I've attempted to re-create it by clearing cache and throttling to slow 3G, but wasn't able to reproduce it. Looking at our code for the platform LoadingButton.jsx I have a proposed code solution. Screen shots attached below.

Point of Contact

VFS Point of Contact: Trevor

Acceptance Criteria

• [ ] Dimmed buttons read back a meaningful message in cases where users can't advanced to the next screen immediately

Environment

• Windows 10
• IE11
• JAWS 2019
• /health-care/view-va-appointments/appointments/new-appointment/choose-eye-care

Steps to Recreate

Possible Fixes (optional)

I believe we can add an SR-only span next to the spinner icon, make the icon invisible to screen readers, and wrap them in a React.Fragment to maintain the current API and introduce a new prop for loading text safely:

// Platform LoadingButton.jsx

export default function LoadingButton({
  children,
  disabled,
  isLoading,
+ loadingText,
  onClick,
  ...props
}) {
  const contents = isLoading ? (
+ <>
      <i
+       aria-hidden="true"
        className="fa fa-spinner fa-spin"
+       role="presentation"
      />
+     <span className="sr-only">{loadingText}</span>
 + </>
  ) : (
    children
  );
  return (
    <button
      className="usa-button"
      disabled={isLoading || disabled}
      onClick={onClick}
      {...props}
    >
      {contents}
    </button>
  );
}

WCAG or Vendor Guidance (optional)

• Name, Role, Value: Understanding SC 4.1.2

Screenshots or Trace Logs

[1Copenut]

@lenaecb && @jbalboni I want to reopen this issue. The Continue button text is reading out after the new page loads in IE11 + JAWS. I took a look at the code in LoadingButton.jsx, specifically the change on line 11 to poll for the loadingText prop instead of isLoading. I think if we keep other items the same and change that back to isLoading, it should read out when we expect, instead of on the next screen.

I'll retest quickly on localhost and Staging when you're ready.

[jbalboni]

@1Copenut That was made right after this PR. The current master version checks isLoading: https://github.com/department-of-veterans-affairs/vets-website/blob/master/src/platform/site-wide/loading-button/LoadingButton.jsx#L11

[1Copenut]

@jbalboni Hm, I'll have to look into it a bit more then. This issue is a tough one--I wasn't able to re-create it myself, but our 508 contact was able to re-create it several times inside the VA network. I'll log in and see if I get the same outcome, and make a new suggestion.

Thank you for the confirmation.

[jbalboni]

@1Copenut I think the issue is that we're not resetting the loading state for the Continue button until after the page change starts. So JAWS might see that text there after the url changes, and queue it up to be read?

I'll make the change in a PR to flip the order there and we can see if that works or breaks other things.

[1Copenut]

@jbalboni That sounds like a great plan! I think you're right on point there; IE11 + JAWS tends to read out first rendered state instead of final reconciled state in cases like this. I'll wait for your PR and re-test IE in staging after a quick spot check. Thank you.

[jbalboni]

@1Copenut Up now: https://github.com/department-of-veterans-affairs/vets-website/pull/13471

[jbalboni]

@1Copenut This should be ready on staging whenever you get a chance.

[1Copenut]

@jbalboni I just verified this in staging. I think we're solid now, and I'll ask the VA 508 office to confirm on their network. Thank you.