Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BUG - sev-3 - All - Claims file upload: error request screen reader callout for missing file/photo is inconsistent/less helpful #10325

Open
5 tasks
TKDickson opened this issue Dec 5, 2024 · 1 comment
Assignees
Labels
accessibility Accessibility awareness or needs for the ticket bug Used to identify a bug ticket that will be worked through the bug process front-end Ticket requires front-end work Health Tickets are tied to the Health Product Team Pms sev-3 Lowest bug severity level based on QA bug severity scale - QA to assign this

Comments

@TKDickson
Copy link
Contributor

TKDickson commented Dec 5, 2024

What happened?

During claims file request upload, if a veteran adds a photo (or a file), and then removes it and attempts to submit, we throw an error that lets them know that a file/photo is required.

However, the screen reader treatment of that error is inconsistent with, and less helpful than, the other error messages on the page. Video example.

The two missing elements are:

  • Announcing the word "error" as part of the error message
  • That the error message + element you'd need to interact with to correct the error message should be a single swipe target (not two swipes, like they are currently)

Specs:

  • Device:
  • OS:
  • User Account: +12345 (login.gov)
  • Accessibility State: screen reader on

Steps to Reproduce

Turn on screen reader for your device.
As Arfan (+12345 in login.gov), go to a claim with an open file request (Claims > [specific claim] > review file requests > [specific file request]).
Pick 'select a file', then upload a file, then delete the file, then attempt to submit the file upload. Swipe through the error messages for each field, and notice the problems with the file upload button's error message.
Back out of this workflow, then repeat the above step with the photo upload ("select a picture") workflow. Same problem.

Desired behavior

Should be a single swipe target, that announces something like "Error: file is required. Select a file, button, double-tap to activate" (for the file workflow, and similarly worded for photo workflow)

Acceptance Criteria

Bug Severity - BE SURE TO ADD THE SEVERITY LABEL

See Bug Tracking for details on severity levels

  • Impact: Low
  • Frequency: Low
  • 3 - Low

Linked to Story

Screen shot(s) and additional information

Full JSON response for services related to issue (expand/collapse)

Ticket Checklist

  • Steps to reproduce are defined
  • Desired behavior is added
  • Labels added (front-end, back-end, global, Health, relevant feature, accessibility, etc)
  • Estimate of 1 added (for front-end tickets)
  • Added either to the relevant feature epic (if found during new feature implementation), or the relevant team's bug epic (Global, Health & Benefits, API, QART)
@TKDickson TKDickson added accessibility Accessibility awareness or needs for the ticket bug Used to identify a bug ticket that will be worked through the bug process front-end Ticket requires front-end work Health Tickets are tied to the Health Product Team Pms sev-3 Lowest bug severity level based on QA bug severity scale - QA to assign this labels Dec 5, 2024
@ala-yna ala-yna added backlog and removed backlog labels Dec 10, 2024
@jennb33
Copy link

jennb33 commented Dec 19, 2024

12/19/2024 - Possible new issue for MFS?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accessibility Accessibility awareness or needs for the ticket bug Used to identify a bug ticket that will be worked through the bug process front-end Ticket requires front-end work Health Tickets are tied to the Health Product Team Pms sev-3 Lowest bug severity level based on QA bug severity scale - QA to assign this
Projects
None yet
Development

No branches or pull requests

5 participants