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

Add back FDC (Fully Developed Claim) page #83339

Closed
15 tasks
christinec-fftc opened this issue May 16, 2024 · 3 comments · Fixed by department-of-veterans-affairs/vets-website#29863
Closed
15 tasks
Assignees
Labels
DBEX-TREX Disability Benefits Experience - Team T-Rex disability-experience engineering Engineering topics frontend urgent

Comments

@christinec-fftc
Copy link
Contributor

christinec-fftc commented May 16, 2024

Issue Description

screenshot of FDC page

  • Add back the page as it was before, in the same order (in the last chapter after trainingPayWaiver page)
  • This is an urgent issue and won't need a toggled roll out. We can instead use environment flags for testing on lower environments before launch
    Update: with the added schema for removing the default, we won't be able to use an environment flag either
  • Test out UX when Veteran has gone passed where the FDC page and we've added it back in. Determine redirect or any other requirements from there

previous pr for removal

Front end tasks

  • Ensure the page is styled according to design spec.
  • Ensure the back end data from API is displayed in local and review instance
  • Ensure unit tests are available.
  • Ensure your code changes are covered by E2E tests
  • Run axe checks using the Chrome or Firefox browser plugin
  • Test for color contrast and color blindness issues
  • Zoom layouts to 400% at 1280px width
  • Test with 1 or 2 screen readers
  • Navigate using the keyboard only

Acceptance Criteria

  • See PR for manual testing instructions to verify changes
  • Designer comments on this issue to approve page styling
  • Unit tests pass
  • E2E tests cover current code and regression
  • End-to-end tests show 0 violations.
  • The data returned matches API response (for given user or scenario)
  • All axe checks pass
  • All color contrast checks pass
  • All zoom testing passes
  • All keyboard checks pass
  • All screenreader checks pass

Appendix

Ensure your code changes are covered by E2E tests (expand)
  • Add E2E tests if none exist for this addition/change.

  • Update existing E2E tests if this code will change functionality.

  • Include axe checks, including hidden content

Run axe checks using the Chrome or Firefox browser plugin (expand)
  • Ensure no heading levels are skipped.

  • Ensure all buttons and labeled inputs use semantic HTML elements.

  • Ensure all buttons, labeled elements and images are identified using HTML semantic markers or ARIA roles.

  • Ensure form fields have clearly defined boundaries or outlines.

  • Ensure form fields do not use placeholder text.

  • Ensure form fields have highly visible and specific error states.

Test for color contrast and color blindness issues (expand) - All text has appropriate contrast.
Zoom layouts to 400% at 1280px width (expand) - Ensure readability and usability are supported when zoomed up to 400% at 1280px browser width - Ensure no content gets focused offscreen or is hidden from view.
Test with 1 or 2 screen readers (expand)
  • Ensure the page includes a skip navigation link.

  • Ensure all links are properly descriptive.

  • Ensure screen reader users can hear the text equivalent for each image conveying information.

  • Ensure screen reader users can hear the text equivalent for each image button.

  • Ensure screen reader users can hear labels and instructions for inputs.

  • Ensure purely decorative images are not announced by the screenreader.

Navigate using the keyboard only (expand)
  • Ensure all links (navigation, text and/or image), form controls and page functions can be reached with the tab key in a logical order.

  • Ensure all links (navigation, text and/or image), form controls and page functions can be triggered with the spacebar, enter key, or arrow keys.

  • Ensure all interactive elements can be reached with the tab key in a logical order

  • Ensure all interactive elements can be triggered with the spacebar, enter key, or arrow keys.

  • Ensure focus is always visible and appears in logical order.

  • Ensure each interactive element has visible focus state which appears in logical order.


How to configure this issue

  • Attached to a Milestone (when will this be completed?)
  • Attached to an Epic (what body of work is this a part of?)
  • Labeled with Team (product support, analytics-insights, operations, service-design, Console-Services, tools-fe)
  • Labeled with Practice Area (backend, frontend, devops, design, research, product, ia, qa, analytics, contact center, research, accessibility, content)
  • Labeled with Type (bug, request, discovery, documentation, etc.)
@christinec-fftc christinec-fftc added DBEX-TREX Disability Benefits Experience - Team T-Rex disability-experience frontend vsa Work associated with the Veteran-facing Services Applications contract needs-estimate needs refinement needs further review and discussion at a refinement session and removed vsa Work associated with the Veteran-facing Services Applications contract labels May 16, 2024
@christinec-fftc christinec-fftc self-assigned this May 16, 2024
@christinec-fftc
Copy link
Contributor Author

Discovery work summary

  • Was able to add back the FDC page locally, which turns out to be the very last page of the 526 form
  • Tested out the Veteran experience for an in progress form by doing the following
  1. Started an original claim, filling it out all the way until the review and submit page. Then clicked 'Finish this application later' to save progress
  2. Re-introduced the FDC page and resumed the in progress form
  3. I was taken to the review and submit page. There was an error on the page, saying that the FDC field was not filled out. However, the radio button was defaulted to 'Yes'. I could not submit the form until i modified the value for the FDC question. Looks like this was happening because when the page is present, it puts the default value in the redux store. When it is not present, the object is not in the store and so the page gets confused.

Because of this error/bad UX, we explored different options. We also wanted to ensure there would be no failed submissions in the back end due to adding the page back.

  1. Remove standardClaim = false default from the front end only
    UX: 👍 This makes it so the Veteran must make an intentional choice
    FE: 👍 Minimizes work needed to add the FDC page back, ship faster
    BE: 👍 Since the standardClaim field is required, we don't expect any submission issues. Also, the default is left in place in the BE just in case something may slip through (we are unsure of how that could happen at this point)

  2. Remove standardClaim = false default from vets-json-schema (front end and back end)
    UX: 👍 This makes it so the Veteran must make an intentional choice
    FE: 🤔 adds deployment complexity
    BE: 👎 adds deployment complexity, EVSS & LH require a value. this could cause submission failures

  3. make standardClaim not required and take out default in vets-json-schema
    UX: 🤔 Veteran could submit a 526 claim without intentionally choosing a claim type
    FE: 👍 feasible
    BE: 🤔 default is needed to prevent submission failure

  4. add in a page migration to reconcile missing data and potentially redirect the Veteran to the FDC page
    UX: 👍 redirecting back one page is acceptable
    FE: 🤔 additional FE work, delays deployment
    BE: 👍 no changes needed

Related slack thread with discussion and videos testing Veteran experience which were difficult to upload to GH
https://dsva.slack.com/archives/C053UDWMH7U/p1715898808116959

Proposed resolution: Option 1 provides the best UX and is most technically feasible. Remaining work left here is to rewrite FE unit tests now that there is no default. Would also be good to make these tests more robust. The changes are behind an environment flag, so once merged we can test on staging prior to prod deployment

@aurora-a-k-a-lightning
Copy link
Contributor

We did a full end-to-end test from staging.va.gov -> staging-api.va.gov -> VBMS UAT with the three scenarios outlined.

  1. FDC: jesse-gray-2019-FDC-yes.pdf
  2. Standard Claim: jesse-gray-2019-standard-claim.pdf
  3. BDD: jesse-gray-2019-BDD.pdf

Notes:

  • turned off toxic exposure feature flags for testing
  • "user 54", Jesse Gray, was used in the testing for all three scenarios
  • had to clear out pending claims in VBMS UAT for this user for testing
  • had to disable lighthouse BRD provider feature flag as this call was failing during the BDD flow. we will file a separate ticket to fix this
  • during the BDD flow, there is an issue with choosing the CFI flow as a user is able to submit a claim with no disabilities provided - this will error upon submission. we will file a separate ticket to investigate.

@christinec-fftc
Copy link
Contributor Author

Ticket for BDD + CFI only issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
DBEX-TREX Disability Benefits Experience - Team T-Rex disability-experience engineering Engineering topics frontend urgent
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants